O modelo que você usa amanhã pode ser desligado hoje à noite

Na noite de 12 de junho de 2026, às 17h21 horário do leste americano, a Anthropic recebeu uma carta do Departamento de Comércio dos Estados Unidos. Não havia detalhes técnicos, não havia prazo de adaptação, não havia negociação. O governo americano havia emitido uma diretiva de controle de exportação suspendendo o acesso ao Claude Fable 5 e ao Claude Mythos 5 para qualquer nacional estrangeiro — dentro ou fora dos EUA — incluindo os próprios funcionários da Anthropic que não fossem cidadãos americanos.

A empresa não tinha como verificar a cidadania de centenas de milhões de usuários em tempo real. A solução encontrada foi a única possível dado o prazo: desligar os dois modelos para todo mundo. Sem aviso prévio adequado para quem tinha pipelines em produção. Sem data de retorno confirmada. A Anthropic chamou isso de "mal-entendido" e prometeu trabalhar para restaurar o acesso o mais rápido possível.

Para quem estava usando Fable 5 num agente de código, num pipeline de análise de vulnerabilidades ou num produto que tinha o modelo no core — a sexta-feira simplesmente quebrou. Isso não é ficção científica, não é cenário hipotético de uma palestra sobre risco geopolítico. Aconteceu. E o Brasil estava do lado de fora, como sempre vai estar quando o governo americano define quem é "estrangeiro".

O que é export control e por que IA entrou nessa equação

Export control é uma categoria de regulação americana com décadas de história. O EAR — Export Administration Regulations — é o conjunto de regras administrado pelo Bureau of Industry and Security (BIS), dentro do Departamento de Comércio. Originalmente pensado para controlar exportação de armas, tecnologia dual-use (civil e militar) e equipamentos sensíveis, o EAR ganhou relevância no setor de tech quando os chips de GPU entraram na mira.

Em 2023 e 2024, o governo americano bloqueou exportação de chips NVIDIA H100 e H200 para a China e outros países considerados adversários estratégicos. A lógica era direta: processadores desse nível permitem treinar modelos de IA de ponta, e modelos de ponta têm capacidade de uso militar. O chip físico virou item de lista de controle, como se fosse componente de míssil.

O passo seguinte era previsível para quem acompanha o ciclo regulatório americano: se o hardware que roda os modelos pode ser controlado, por que não o software em si? Modelos de peso aberto já vinham sendo alvo de debate regulatório intenso — o Llama da Meta, por exemplo, entrou em discussões sobre se deveria ou não ser tratado como "exportação" ao ser publicado no HuggingFace. Modelos fechados, servidos via API, até então estavam numa zona mais cinzenta. O caso Fable 5 acabou com essa ambiguidade na prática.

A Anthropic havia posicionado o Mythos 5 — o modelo subjacente ao Fable 5 — como altamente capaz em cybersecurity, encontrando bugs e vulnerabilidades em codebases complexas. O Fable 5, versão com guardrails voltada ao público geral, foi lançado dias antes do ban, em 9 e 10 de junho. A empresa havia testado os mecanismos de segurança do modelo com o próprio governo americano, com o UK AI Safety Institute e com terceiros por milhares de horas antes do lançamento. Segundo o 9to5Mac, a Mozilla chegou a resolver centenas de vulnerabilidades de software com a ajuda do Mythos Preview durante os testes.

Não adiantou. Um terceiro alegou ter encontrado uma técnica de jailbreak. O BIS agiu. A carta chegou.

O que o jailbreak alegado realmente era

Aqui vale parar e entender o que o governo americano apontou como ameaça — porque o detalhe importa muito para avaliar a proporcionalidade da resposta.

Segundo a declaração pública da Anthropic no Fortune, a evidência que o governo apresentou foi verbal, não havia nada por escrito, e consistia basicamente em: pedir para o modelo ler uma codebase e corrigir vulnerabilidades nela. O resultado demonstrado envolveu "um pequeno número de vulnerabilidades conhecidas, menores" — do tipo que outros modelos publicamente disponíveis, incluindo o GPT-5.5 da OpenAI, já conseguem encontrar sem qualquer bypass.

A comunidade de segurança reagiu com ceticismo imediato. A análise da Snyk sobre o episódio resume o problema central com clareza: pedir a um modelo para ler um código e encontrar falhas é exatamente o que ferramentas de SAST, fuzzers e qualquer engenheiro de segurança fazem rotineiramente. É uma capacidade dual-use por definição — a mesma que serve ao defensor auditando o sistema serve ao atacante querendo explorá-lo. nmap é um scanner de rede. Wireshark analisa pacotes. GDB depura memória. Nenhuma dessas ferramentas foi banida porque pode ser usada com má intenção.

O que torna o caso ainda mais paradoxal: na semana anterior ao ban, pesquisadores de segurança reclamavam que o Fable 5 estava com guardrails restritivos demais para trabalho defensivo legítimo. Valentina Palmiotti, do IBM X-Force, disse ao TechCrunch que o modelo "rejeita qualquer pedido remotamente relacionado a cyber". Na mesma semana, o mesmo modelo foi suspenso por uma capacidade que é usada todo dia por quem defende sistemas.

A Anthropic argumentou que o processo não seguiu critérios técnicos claros e que, se esse padrão fosse aplicado consistentemente na indústria, "efetivamente paralisaria todos os novos lançamentos de modelos de todos os provedores frontier". A empresa disse concordar que governos devem ter mecanismos para bloquear deployments inseguros — mas apenas "como parte de um processo estatutário transparente, justo, claro e fundamentado em fatos técnicos". Essa ação, segundo a Anthropic, não aderiu a esses princípios.

Há contexto político relevante aqui também. O governo Trump havia tentado impedir o lançamento do modelo antes, sem sucesso. Em fevereiro, ordenou agências federais a parar de usar os modelos da Anthropic depois que a empresa recusou termos de contrato do Pentágono que permitiriam uso "para qualquer propósito legal" — inclusive sistemas de armas autônomas. Em março, o Pentágono declarou a Anthropic um "risco à cadeia de suprimentos". A empresa está contestando isso na Justiça. O ban de Fable 5 chegou poucos dias depois da Anthropic ter arquivado confidencialmente pedido de IPO avaliado em quase US$ 1 trilhão. A correlação de datas não prova causalidade, mas é difícil ignorar.

Precedentes históricos e o que eles ensinam

Para entender onde isso pode chegar, vale olhar para o histórico de controles de exportação em tecnologia.

Na década de 1990, o governo americano tratou criptografia forte como munição e restringiu sua exportação. Algoritmos acima de 40 bits de chave precisavam de licença para sair do país. O episódio ficou conhecido como "Crypto Wars". Phil Zimmermann, criador do PGP, chegou a ser investigado criminalmente por "exportar armamento" ao publicar o código-fonte do software na internet. O processo durou anos e gerou mobilização intensa na comunidade de segurança. Os tribunais americanos eventualmente reconheceram que publicar código é expressão protegida pela Primeira Emenda, e os controles foram gradualmente relaxados ao longo dos anos seguintes.

A diferença crucial com o caso Fable 5: os Crypto Wars restringiam exportação de software. O ban de Fable 5 forçou uma empresa a desligar um produto já implantado globalmente para seus próprios usuários, incluindo americanos, em questão de horas. É uma escala e velocidade de intervenção qualitativamente diferentes. A Anthropic não teve meses para contestar em tribunal — teve uma tarde para decidir se desligava os modelos ou arriscava violação de diretiva federal de segurança nacional.

O caso Huawei é outro ponto de referência. Em 2019, o governo americano adicionou a empresa à Entity List, efetivamente cortando o acesso ao ecossistema de chips e software americano. Empresas ao redor do mundo que dependiam de infraestrutura Huawei precisaram repensar estratégias de fornecedor overnight. Telecomunicações, operadoras, governos — todos pegaram um choque de realidade sobre dependência de tecnologia controlada por decisão política estrangeira. O processo de diversificação levou anos e custou bilhões.

Mas nesses casos anteriores, as empresas afetadas eram fornecedoras de hardware. No caso da IA servida via API, o produto é intangível, entregue em tempo real, e pode ser desligado com a mesma velocidade que um interruptor. O risco operacional é estruturalmente diferente — e mais imediato. Não há estoque físico de chips Huawei que continue funcionando depois da Entity List. Mas também não há processo de recall que leve semanas. A API simplesmente para de responder.

Por que isso é especialmente crítico para o Brasil

Nós somos estrangeiros. Isso parece óbvio, mas as implicações práticas merecem ser explicitadas sem rodeios.

Do ponto de vista do Export Administration Regulations, "foreign national" não é um conceito de localização geográfica — é de cidadania. Um brasileiro que mora em São Paulo, trabalha para uma empresa americana e acessa a API do Claude via datacenter americano continua sendo um foreign national. Um funcionário brasileiro da própria Anthropic, trabalhando no escritório de San Francisco, estava coberto pela diretiva e perdeu acesso junto com todo mundo.

Isso significa que qualquer produto ou serviço construído no Brasil, por brasileiros, usando modelos de IA americanos via API, tem exposição ao mesmo tipo de risco. Não é questão de estar no país certo. É questão de ter o passaporte certo — e não temos controle sobre isso.

O Collabnix, comunidade de mais de 17 mil desenvolvedores com maioria fora dos EUA, documentou a perda de acesso naquela noite com precisão. O autor do post está em Bengaluru e descreve exatamente a mesma sensação que qualquer tech lead brasileiro teria: toda a sua audiência são foreign nationals pela definição que importa aqui.

O mercado de tech brasileiro adotou Claude, GPT-4, Gemini e similares com velocidade impressionante. Times de produto, startups de IA, consultorias, bancos, healthtechs — todos têm algum grau de dependência dessas APIs. A maioria tratou isso como risco de uptime (o modelo pode ficar fora por falha técnica) ou risco de preço (o provider pode mudar a tabela de cobrança). Risco geopolítico de acesso não estava no radar operacional da maior parte dos times.

A fricção não é abstrata. É que você pode ter um produto em produção, com SLA acordado com cliente, com arquitetura construída em cima de um modelo específico — e uma decisão tomada a milhares de quilômetros, por razões que você não controla e que podem não ter nada a ver com o seu uso, pode derrubar isso de madrugada. Sem janela de manutenção. Sem changelog. Sem issue tracker público.

Vale dizer: não estou sugerindo que devemos parar de usar modelos americanos. A qualidade técnica é real, o ecossistema é maduro, a produtividade que eles entregam é genuína. O ponto é que essa dependência precisa ser tratada com o mesmo rigor que tratamos outras dependências de terceiros de alto impacto — com SLAs entendidos, planos de contingência desenhados e testes de fallback feitos enquanto está tudo funcionando, não depois que o incêndio começou.

Estratégias de resiliência para tech leads

O risco não desaparece porque tomamos conhecimento dele. O que muda é a forma como arquitetamos nossas dependências. Algumas estratégias práticas para considerar agora, antes do próximo incidente:

Abstração da escolha de modelo. Nunca hard-code o nome do modelo em produção. Uma configuração por variável de ambiente, um parâmetro em banco ou um arquivo de config é a diferença entre um swap de emergência que leva 5 minutos e um hotfix que acorda o time às 3h. Se sua codebase tem "claude-fable-5" literal em dezenas de lugares, você tem dívida técnica de resiliência que precisa ser paga antes do próximo susto.

Fallback multi-model documentado e testado. Defina hierarquias de fallback explícitas: se o modelo primário não responde — por qualquer razão, rate limit, outage, ban por export control — qual é o próximo? A Anthropic tinha o Opus 4.8 como substituto imediato para quem usava Fable 5. Quem tinha o fallback configurado passou pela noite de 12 de junho com impacto mínimo. Quem tinha dependência rígida precisou fazer deploy de emergência no fim de semana. A diferença estava na arquitetura, não na sorte.

Diversificação de providers. Um sistema crítico que depende exclusivamente de um único provider de IA tem o mesmo problema de um sistema que depende de um único datacenter sem disaster recovery. Claude para raciocínio, GPT-4 como backup, Gemini para casos de uso específicos — não é over-engineering, é hygiene de disponibilidade. A lógica é idêntica à que usamos para bancos de dados, filas de mensagens e provedores de pagamento.

Avaliação séria de on-premise e modelos abertos. Para casos de uso onde o modelo é crítico e o dado é sensível, vale a análise de modelos que rodam na sua própria infraestrutura. Llama, Mistral, Qwen e similares não estão sujeitos a export controls aplicados via API — você controla a disponibilidade. Perde a conveniência do serverless e ganha controle sobre uptime. Não é bala de prata — tem custo de infra, manutenção e geralmente capacidade inferior nos modelos menores — mas pode ser a escolha certa dependendo do contexto e do nível de criticidade.

Inventário de dependências de IA. Você sabe exatamente quais sistemas da sua empresa dependem de qual modelo, de qual provider, via qual contrato e chave de API? Muita empresa não sabe de forma centralizada. Inventariar isso antes de uma crise é infinitamente mais fácil do que reconstruir no meio de um incidente. É o equivalente ao SBOM (Software Bill of Materials) para dependências de IA — e assim como o SBOM virou requisito em muitos contextos de segurança, o AI dependency map vai virar padrão de maturidade nos próximos anos.

Antena em política de tecnologia. Ninguém esperava que o EAR chegasse em modelos de IA servidos via API com essa velocidade. A regulação está se movendo rápido, e os próximos 12-24 meses vão trazer mais legislação tanto nos EUA quanto na UE (o AI Act está em fase de implementação, com requisitos que afetam sistemas de IA de alto risco). Ter alguém no time com visibilidade em policy de tech não é mais luxo de grandes empresas — é inteligência operacional que pode salvar um sprint inteiro de retrabalho e, em casos extremos, evitar interrupção de serviço para clientes.

Runbook de incidente para "modelo indisponível". Assim como você tem playbook para banco de dados fora, para falha de provider de pagamento e para CDN caído, precisa ter um runbook específico para o cenário "modelo de IA principal indisponível". O que acontece? Quem é acionado? Quais features degradam graciosamente, quais param de funcionar? Quais clientes precisam ser notificados? Ter essas respostas escritas antes do incidente é a diferença entre gerenciar uma crise e ser gerenciado por ela.

A conversa mais ampla sobre soberania tecnológica

Tem uma questão maior embaixo de tudo isso, e prefiro ser direto: usar modelos de IA americanos como infraestrutura crítica sem plano de contingência é uma decisão de risco que muitas empresas brasileiras ainda não conscientizaram plenamente.

Não é paranoia antiamericana. É a mesma lógica que leva empresas a manter backup em nuvem diferente do primary, a não depender de um único banco para processar pagamentos, a não ter apenas um fornecedor de hardware crítico. Quando a dependência é de um recurso controlado por lei de outro país, o risco tem uma camada adicional que está fora do seu controle operacional e do seu modelo de risco tradicional.

A publicação alemã Heise enquadrou o episódio com precisão em sua cobertura: "US government forces shutdown of Anthropic's AI Fable 5 and Mythos 5". Não foi a Anthropic que escolheu desligar. Foi forçada. E os usuários ao redor do mundo — incluindo todos nós no Brasil — foram collateral damage de uma disputa entre uma empresa e seu próprio governo.

O precedente está aberto. Se funcionou com Fable 5 e Mythos 5, a estrutura jurídica existe para funcionar com outros modelos, outros providers, em outros contextos políticos. A única certeza é que a interseção entre regulação de segurança nacional e IA não vai diminuir. Vai crescer, vai se sofisticar, vai chegar em mais camadas da stack do que imaginamos hoje.

Eu continuo usando Claude. Continuo achando que os modelos da Anthropic estão entre os melhores disponíveis para raciocínio e código. Não tem nada nesse episódio que mude minha avaliação técnica dos produtos.

O que muda é a forma como trato a dependência. Não como utilidade com disponibilidade garantida — mas como fornecedor com risco de disponibilidade que precisa de contingência documentada, fallback testado e revisão periódica. É o mesmo rigor que aplicamos a qualquer outra dependência crítica de sistema, e não tem razão para ser diferente com IA.

A noite de 12 de junho foi um stress test não planejado para a indústria. Serve como lembrete de que "disponível agora" e "disponível quando você precisar" são propostas diferentes quando se trata de infraestrutura controlada por terceiros — especialmente quando esses terceiros incluem governos com interesses próprios e agendas que podem mudar de um mês para o outro. A resiliência não é sobre não usar IA de terceiros. É sobre nunca depender exclusivamente deles sem um plano claro para quando o acesso acabar.