Pular para o conteúdo principal
Direção e Sentido
Estratégia

A IA Que Você Escolheu Pode Sumir Numa Sexta-Feira às 17h

A dependência de uma única ferramenta de IA pode ser arriscada para empresas. Entenda os perigos e como se proteger.

Na terça-feira, 9 de junho de 2026, a Anthropic lançou o Fable 5, anunciado como o modelo de IA mais poderoso que a empresa já havia colocado à disposição do público. Na sexta-feira seguinte, às 17h21, ela recebeu uma ordem do governo americano para suspender o acesso ao modelo para qualquer cidadão estrangeiro, dentro ou fora dos Estados Unidos. Como a empresa não conseguia separar em tempo real quem era estrangeiro de quem não era, desligou o modelo para todos os clientes do mundo.

Três dias entre o lançamento e o desligamento. O modelo não falhou. Não teve bug, não vazou dado, não cometeu erro. Funcionou exatamente como prometido e sumiu mesmo assim, por uma decisão que não tinha nada a ver com a qualidade do produto nem com os clientes que dependiam dele.

Se a sua operação rodasse sobre o Fable 5 naquela sexta, você descobriu o desligamento junto com todo mundo. Sem aviso, sem janela de migração, sem plano B contratualmente garantido. Numa tarde de sexta-feira, antes do fim de semana, a ferramenta que executava parte do seu negócio simplesmente não respondeu mais.

Essa é uma categoria de risco que quase nenhuma análise de adoção de IA inclui. E o caso Fable 5 é o exemplo mais limpo que apareceu até agora de por que ela deveria estar em toda mesa de decisão.

O que aconteceu em 72 horas

Vale entender a sequência, porque ela é mais instrutiva do que a manchete.

A Anthropic lançou dois modelos construídos sobre a mesma base técnica: o Mythos 5, que nunca chegou ao público geral, e o Fable 5, liberado com salvaguardas adicionais. No próprio anúncio de lançamento, a empresa descreveu o Fable 5 como poderoso o suficiente para exigir proteções rígidas, citando especificamente que suas capacidades em áreas como cibersegurança poderiam causar dano sério se mal utilizadas. Em outras palavras, a empresa vendeu o modelo dizendo que ele era perigoso. Guarde esse detalhe, porque ele volta.

Na sexta-feira, o Departamento de Comércio americano emitiu uma diretiva de controle de exportação. A justificativa oficial citou segurança nacional. O entendimento da própria Anthropic, segundo seu comunicado, é que o governo acreditava ter tomado conhecimento de um método de burlar as salvaguardas do Fable 5. A empresa revisou uma demonstração da técnica e concluiu que ela identificava um número pequeno de vulnerabilidades menores já conhecidas, do tipo que outros modelos publicamente disponíveis também encontram sem precisar de burla nenhuma.

A Anthropic está cumprindo a ordem enquanto discorda dela, classificando a situação como provável mal-entendido e dizendo trabalhar para restaurar o acesso. Mas, do ponto de vista de quem usava o modelo, a discordância é irrelevante. O modelo saiu do ar. A discussão sobre se a decisão foi justa acontece depois, em algum tribunal ou alguma reunião em Washington, e enquanto ela acontece, a operação de quem dependia do Fable 5 está parada. Você não é parte dessa conversa. Você só sente o resultado dela.

Há um detalhe que torna o caso quase irônico. Um pesquisador de cibersegurança observou que a Anthropic havia, em certo sentido, cavado a própria cova: se você descreve seu produto como uma munição em todo press release, em algum momento um governo te leva a sério. A empresa passou meses construindo o argumento de que o modelo era perigoso demais para circular sem controle, e esse argumento virou o fundamento legal para tirá-lo de circulação. Eles escreveram o predicado jurídico e chamaram de marketing.

O risco que ninguém coloca na planilha

Quando uma empresa avalia adotar IA para executar uma função relevante, a análise de risco costuma cobrir três coisas: a IA vai funcionar bem o suficiente? Quanto vai custar? Quão difícil é implementar? São perguntas corretas. E são insuficientes.

A pergunta que falta é a mais incômoda: o que acontece com a minha operação se essa IA específica deixar de existir para mim, sem aviso, por uma decisão que eu não controlo?

Essa pergunta parecia teórica até a sexta-feira passada. Agora não parece mais. Não estamos falando de uma startup que quebrou ou de um produto descontinuado por falta de mercado, casos previsíveis que dão sinais com antecedência. Estamos falando do modelo mais avançado de uma das maiores empresas de IA do mundo, removido por ordem governamental três dias depois de ser lançado com festa.

A dependência de uma IA específica é diferente, em natureza, da dependência de um fornecedor de software tradicional. Quando você adota um ERP, a migração é dolorosa, mas é previsível, e você costuma ter meses ou anos de aviso antes de qualquer descontinuação. Existe contrato, existe roadmap, existe um processo comercial com regras conhecidas. Quando você constrói um processo crítico em torno de um modelo de IA específico, você herda uma camada adicional de risco que o software tradicional não tinha: decisões regulatórias, geopolíticas e de segurança nacional que podem remover o modelo da sua operação numa velocidade que nenhum contrato comercial normal prevê.

E aqui está o que torna o caso Fable 5 particularmente desconfortável. Ao contrário do fornecedor que quebra, não houve nem a previsibilidade do declínio. O Fable 5 não estava em dificuldade financeira, não estava perdendo clientes, não estava sendo descontinuado por baixo uso. Estava no auge, recém-lançado, funcionando perfeitamente. Sumiu mesmo assim. O sucesso do produto não foi proteção nenhuma.

As três formas de uma IA sumir sem aviso

O caso que estamos discutindo é de origem regulatória, mas existem pelo menos três formas distintas de uma IA da qual você depende deixar de estar disponível. Vale conhecer as três, porque a maioria das empresas só pensa na terceira, que é a menos provável.

A primeira é regulatória ou geopolítica, que é exatamente o que aconteceu com o Fable 5. Governos podem restringir acesso a modelos por segurança nacional, controle de exportação ou disputa comercial entre países. Para empresas fora dos Estados Unidos, isso pesa especialmente, e o empresário brasileiro precisa internalizar esse ponto: a maioria dos modelos de fronteira é desenvolvida por empresas americanas, sujeitas à jurisdição americana. Uma decisão tomada numa sala em Washington, sobre uma disputa que não envolve você nem o seu país, pode desligar a ferramenta sobre a qual sua operação foi construída. Você não vota nessa decisão, não é consultado, e não recebe aviso. O Fable 5 mostrou que o intervalo entre a decisão e o desligamento pode ser de horas.

A segunda é comercial, e é a mais frequente das três, embora a menos dramática. O fornecedor pode deprecar o modelo que você usa para empurrar a adoção de um modelo mais novo e mais caro. Pode mudar os termos de uso. Pode alterar o preço de um jeito que inviabilize o seu caso de uso específico (e, como discuti no segundo artigo desta série, o preço de token está sob controle unilateral de quem vende). Pode simplesmente decidir que o seu segmento não é prioritário. Modelos de IA são deprecados com frequência muito maior do que software tradicional. O que funciona hoje pode receber aviso de fim de vida em poucos meses, e o aviso costuma vir com uma janela apertada.

A terceira é operacional, que é a única que a maioria das empresas efetivamente considera. O fornecedor sofre uma interrupção técnica, um problema de capacidade, um incidente de segurança que o force a suspender o serviço temporariamente. É o risco mais visível e, paradoxalmente, o menos perigoso, porque costuma ser curto e o fornecedor tem todo o incentivo para resolver rápido.

As três têm uma coisa em comum, e é essa coisa que importa. Estão fora do seu controle. Você não decide, não é avisado com antecedência garantida e não tem poder de reverter. O que você controla, o único ponto da equação que é seu, é o quanto a sua operação fica vulnerável quando uma delas acontece.

A diferença entre usar e delegar

Existe uma distinção que parece sutil mas que define todo o tamanho do risco: a diferença entre usar IA como ferramenta e delegar inteligência e execução a uma IA.

Quando você usa IA como ferramenta, um profissional continua no comando do processo, e a IA acelera ou amplia o que ele faz. Se a IA some, o profissional volta a fazer o trabalho mais devagar, com mais esforço, mas a capacidade não se perdeu. Ela está na cabeça e nas mãos de quem ficou. A operação desacelera. Não para.

Quando você delega inteligência e execução, o processo passa a depender da IA para existir. O conhecimento de como fazer aquilo migra da organização para o modelo. As pessoas que faziam aquele trabalho foram realocadas, ou desligadas, ou nunca foram contratadas porque a IA já estava lá quando o processo foi desenhado. Se a IA some nesse cenário, não há para onde voltar, porque a capacidade humana de executar a função foi desmontada, ou nunca foi construída, na expectativa de que a ferramenta estaria sempre disponível.

A pergunta que todo decisor deveria responder antes de delegar é direta, quase brutal na simplicidade: se a IA que escolhi desaparecer numa sexta-feira às 17h, quanto tempo minha operação aguenta, e qual é o plano para os primeiros dias?

Se a resposta for "não sei", a delegação foi feita no escuro. Se a resposta for "a operação para", a delegação foi feita sem rede. E o caso Fable 5 acabou de demonstrar que a rede de proteção não é paranoia de gestor conservador. É requisito básico de gestão de risco para quem construiu dependência crítica de uma tecnologia que pertence, em última instância, a outra pessoa, sob a jurisdição de outro país, sujeita a decisões que você não acompanha.

O que fazer: arquitetura de reversibilidade

Não estou argumentando contra delegar funções a IA. Seria incoerente com tudo que defendi nos artigos anteriores desta série, onde mostrei que a vantagem competitiva de usar bem a tecnologia é real e está concentrada em poucas empresas. O que defendo é delegar com uma arquitetura que permita reverter. Reversibilidade, não abstinência.

O primeiro princípio é não construir dependência crítica de um único modelo de um único fornecedor. Onde a função é crítica, a arquitetura deveria permitir trocar de modelo com esforço razoável. Na prática, isso significa evitar amarrar processos centrais a um comportamento específico de um modelo que não existe nas alternativas. Quanto mais o seu processo explora uma idiossincrasia de um modelo, mais cara e mais lenta fica a migração no dia em que a migração deixar de ser opcional. Construir pensando em portabilidade custa um pouco mais hoje e economiza a operação inteira amanhã.

O segundo princípio é preservar capacidade humana nas funções de maior risco de indisponibilidade. Não estou dizendo para manter toda a operação manual rodando em paralelo, o que seria caro, ineficiente e francamente impossível de justificar para o conselho. Estou dizendo algo mais modesto e mais factível: manter conhecimento suficiente, documentação suficiente e gente suficiente para que a função possa ser retomada de forma degradada se o modelo sumir. A diferença entre uma operação que desacelera e uma que para, lá no momento da crise, é exatamente o tamanho dessa reserva. É um seguro, e como todo seguro, parece desperdício até o dia em que não parece.

O terceiro princípio é tratar a dependência de IA como risco de fornecedor formal, com plano de contingência documentado e revisado. A mesma disciplina que uma empresa séria aplica a qualquer fornecedor crítico de outra categoria, avaliação de risco, plano B identificado, cláusulas contratuais sobre continuidade e aviso prévio, deveria se aplicar com igual rigor aos modelos de IA dos quais a operação depende. O caso Fable 5 deixou claro que nem o tamanho nem a reputação do fornecedor são garantia. O maior e mais avançado pode ser removido por uma força externa que está acima dele também.

Vou ser honesto sobre o trade-off, porque vender ilusão aqui seria pior do que não escrever o artigo. Reversibilidade tem custo. Manter capacidade de migração e reserva de competência humana é menos eficiente, no curto prazo, do que delegar tudo e otimizar a operação para o cenário em que a IA está sempre lá. Quem escolhe a reversibilidade abre mão de uma parte do ganho de eficiência máxima. Mas esse custo é o preço de não deixar a operação refém de uma decisão tomada numa sala onde você não tem cadeira, nem voz, nem aviso.

"Mas isso é um caso extremo"

A objeção é previsível, e eu a faria também se estivesse do outro lado. O caso Fable 5 envolveu o modelo mais poderoso do mercado, questões de segurança nacional, cibersegurança, uma combinação rara de fatores. Não vai acontecer com o modelo genérico que a minha empresa usa para resumir relatório e responder e-mail. É um evento de cauda, dirá o gestor cético, e gestor não gerencia para a cauda.

Há dois problemas em descartar isso como caso extremo, e os dois importam.

O primeiro é que casos extremos são exatamente o que a gestão de risco existe para cobrir. Ninguém compra seguro contra o que acontece todo dia. Compra contra o evento raro de alto impacto, aquele que tem baixa probabilidade em qualquer dia específico mas consequência severa quando se materializa. A dependência crítica de uma IA que pode sumir é o exemplo de manual desse tipo de risco. Baixa chance hoje. Operação parada no dia em que acontecer. Tratar isso como improvável demais para planejar é confundir probabilidade baixa com impacto baixo, e essa confusão é cara.

O segundo problema é mais sutil e talvez mais importante. O caso Fable 5 é só a versão visível e dramática de um risco que se manifesta em versões menores o tempo todo, sem manchete. Modelos são deprecados toda semana em algum lugar. Preços mudam. Termos de uso se alteram. Acesso a recursos é restringido por região sem grande comunicado. A forma extrema apareceu nos jornais porque envolveu governo e segurança nacional, mas a forma cotidiana já está acontecendo na sua operação ou na do seu concorrente, com o mesmo princípio embaixo: a IA que você escolheu está sob controle de quem não é você.

Quem entender o princípio a partir do caso extremo vai construir a proteção antes de precisar dela na versão cotidiana. Quem esperar a versão cotidiana doer para só então agir vai aprender a mesma lição, mais devagar e mais caro.

Por onde continuar

O segundo artigo desta série tratou do custo imprevisível de trocar salários por tokens. Este tratou de uma dimensão vizinha e mais aguda: a disponibilidade imprevisível da própria IA. Os dois apontam para o mesmo princípio de gestão, que vale a pena dizer sem rodeio. Delegar para IA é, antes de tudo, uma decisão de terceirizar uma função crítica. E terceirização de função crítica sempre exigiu plano de contingência. Isso não mudou porque a terceirizada agora é um modelo de linguagem em vez de uma empresa de call center.

Na mentoria da Direção e Sentido, a análise de risco de dependência é parte do trabalho de decidir o que delegar e como. Não para desencorajar o uso de IA, que seria o conselho errado num momento em que a vantagem está com quem usa bem, mas para que a delegação seja feita com a arquitetura que permite dormir tranquilo mesmo sabendo que a ferramenta está sob controle de outro. Onde construir reversibilidade. Onde preservar capacidade humana. Como estruturar a operação para que uma sexta-feira às 17h não vire uma segunda de operação parada e telefone tocando.

Se você já delegou, ou está pensando em delegar, funções críticas a uma IA, o melhor momento para conversar sobre o que acontece no dia em que ela não estiver lá é antes desse dia chegar.


Arnaldo Auad é consultor em gestão, BI e estratégia de dados na Direção e Sentido. Trabalha com executivos e gestores na construção de estratégias de IA que geram retorno mensurável.