Modelos de IA têm data para serem desligados: o que isso significa para a automação da sua empresa

Em 5 de agosto deste ano, a Anthropic desligou o Claude Opus 4.1. Não é figura de linguagem: o modelo saiu do ar e qualquer chamada para ele passou a retornar erro. Em 26 de agosto, daqui a uma semana, a OpenAI faz o mesmo com a Assistants API, a interface em que muita gente construiu assistente de atendimento entre 2024 e 2025. Depois dessa data, as chamadas para /v1/assistants e /v1/threads retornam erro, sem modo degradado e sem prorrogação.

Nada disso é notícia de capa. É rodapé de documentação técnica. E é exatamente o tipo de coisa que derruba a automação de uma empresa pequena numa quinta-feira de manhã, sem que ninguém entenda o motivo.

Como funciona o ciclo de vida de um modelo

Todo fornecedor grande de IA usa alguma variação do mesmo esquema. O modelo nasce ativo, em algum momento vira legado, depois é marcado como descontinuado (ainda funciona, mas já tem data de morte publicada) e por fim é aposentado, quando para de responder de vez.

A Anthropic publica isso numa página aberta e se compromete a avisar com pelo menos 60 dias de antecedência quem tem uso ativo daquele modelo. A OpenAI trabalha com prazos maiores para modelos em disponibilidade geral e prazos curtos, de poucas semanas, para versões em prévia. As tabelas públicas de hoje já mostram as próximas datas: o Claude Sonnet 4.5 tem aposentadoria prevista para não antes de 29 de setembro de 2026, o Haiku 4.5 para não antes de 15 de outubro, o Opus 4.5 para não antes de 24 de novembro.

Duas informações desse cronograma costumam passar batido.

A primeira: o aviso vai por e-mail para a conta que possui a chave de API. Se essa chave está numa conta criada pelo fornecedor de automação, o dono da empresa nunca vê o e-mail. Ele descobre pelo cliente reclamando.

A segunda: quando o modelo roda em nuvem de terceiro, como AWS ou Google Cloud, o calendário de aposentadoria é outro, definido pela nuvem. Duas empresas usando "o mesmo modelo" podem ter prazos diferentes.

O que isso muda para uma PME

O primeiro reflexo de quem lê essa notícia é achar que não tem nada a ver com ele, porque quem lida com modelo é o fornecedor. É verdade em parte, e é justamente aí que mora o problema: a consequência cai no seu negócio, a decisão está com outra pessoa.

Pense numa corretora de seguros com quatro pessoas no comercial e uma automação de WhatsApp que faz três coisas: responde dúvidas de cobertura, faz a triagem inicial de aviso de sinistro e coleta os dados básicos antes de passar para o corretor. Essa automação foi ajustada durante semanas. A instrução foi reescrita várias vezes até a IA parar de prometer cobertura que a apólice não tem. A base de conhecimento tem as exceções de cada seguradora parceira.

Quando o modelo por trás disso é desligado, existem dois cenários.

No cenário ruim, ninguém migrou nada e a automação simplesmente para. Toda mensagem entra e nada sai. Dependendo do volume, isso é meio dia de sinistro sem triagem.

No cenário aparentemente bom, alguém trocou o nome do modelo na configuração, viu que voltou a responder e considerou resolvido. Só que instrução não é portátil entre modelos: a mesma frase pesa diferente no modelo novo, que costuma ser melhor em raciocínio e mais solto no formato. Aquele "responda em no máximo três linhas" que era obedecido à risca vira uma sugestão. A recusa que funcionava ("se não estiver na apólice, não confirme") passa a vir acompanhada de uma explicação simpática que soa como confirmação.

Ninguém percebe isso pelo painel. Resolução sozinha continua na mesma faixa, transferência estável. O que mudou foi a qualidade da resposta, e qualidade de resposta não aparece em métrica de fluxo.

Há ainda um detalhe mais fino que apareceu recentemente na documentação da Anthropic: parâmetros de configuração também são descontinuados. temperature, top_p e top_k passaram a retornar erro nos modelos mais novos quando enviados com valor diferente do padrão. Ou seja, mesmo um código que só troca o nome do modelo pode quebrar por causa de um parâmetro que estava lá desde o primeiro dia.

Onde a gente discorda do discurso do setor

A leitura comum é que aposentar modelo antigo é sinal de evolução rápida e que quem reclama está preso ao passado. Do lado de quem escreve o código, faz sentido: manter modelo velho no ar custa capacidade de máquina.

Do lado de quem opera um negócio pequeno, isso significa uma coisa incômoda: o software que atende os seus clientes tem prazo de validade definido por uma empresa com a qual você nunca falou, num calendário que você não controla e que pode mudar. É a mesma lógica que já existia em sistema operacional e navegador, só que com um ciclo bem mais curto. Entre a versão 4 e a aposentadoria da versão 4 do Claude passaram-se pouco mais de doze meses.

A conclusão prática que tiramos disso é simples: automação é um sistema em operação, com custo de manutenção previsto em orçamento, e não um móvel que se compra uma vez e fica no canto.

As quatro perguntas antes de assinar

Nenhuma proposta comercial de automação que a gente já viu no mercado brasileiro menciona ciclo de vida de modelo. É pergunta que o comprador precisa fazer.

1. A chave de API está no nome de quem? Se a conta é do fornecedor, peça que o e-mail administrativo inclua também alguém da sua empresa. Aviso de aposentadoria e aviso de mudança de preço chegam pelo mesmo canal.

2. Quem paga a migração quando o modelo for desligado? Não existe resposta certa: pode estar incluída na mensalidade de manutenção ou ser cobrada à parte. O que não pode é ficar sem combinar, porque a data vai chegar de qualquer jeito.

3. Existe um teste de comparação registrado? Um conjunto de perguntas reais do seu negócio, com a resposta considerada certa. Trocou de modelo, roda o conjunto de novo e compara. Sem isso, a validação vira "abri o WhatsApp e mandei um oi, respondeu".

4. A troca de modelo é uma configuração ou uma reescrita? Se o fornecedor amarrou o projeto inteiro numa interface específica de um único fabricante, como aconteceu com quem construiu na Assistants API, a migração não é troca de nome. É reconstrução, e o orçamento é outro.

O que a gente faz internamente

Manter um conjunto de perguntas de aceitação por projeto, com resposta esperada escrita, é o mecanismo mais barato que existe para isso. Duas dúzias de perguntas resolvem, incluindo as três ou quatro que a IA já errou alguma vez na vida. Toda troca de modelo passa por elas antes de ir para produção.

O calendário de aposentadoria dos modelos que usamos fica anotado com a data prevista, e a migração é agendada com folga em vez de esperar o e-mail de aviso. Modelo novo entra em paralelo primeiro, respondendo junto sem publicar a resposta, para comparar saída antes de assumir o canal.

Nada disso é sofisticado. É a diferença entre trocar um pneu na garagem e trocar na beira da estrada.