Em 14 de abril de 2026, a Anthropic avisou os desenvolvedores que usavam Claude Sonnet 4 e Claude Opus 4: essas versões seriam desligadas em 15 de junho. Dois meses de janela. Quem tinha uma rotina apoiada especificamente naquela versão precisou testar, ajustar e trocar antes da data — ou parar de funcionar no dia seguinte.
Não é um episódio isolado. Segundo a própria documentação da Anthropic, toda vez que uma versão de modelo é aposentada, os pedidos enviados a ela depois da data de retirada simplesmente falham. A OpenAI segue uma lógica parecida: modelos com disponibilidade geral recebem no mínimo 6 meses de aviso, versões especializadas 3 meses, e modelos ainda em teste podem sair do ar com apenas 2 semanas.
Para quem decide onde a IA vai rodar na empresa, o fato relevante não é a data em si. É que a rotina que funcionava ontem pode simplesmente parar de responder amanhã — e o aviso, quando vem, chega para times que já tratam aquele fluxo como parte da operação.
Aposentar é só metade do problema
A Anthropic classifica cada modelo em quatro estágios: ativo, legado, descontinuado e aposentado. No estágio "descontinuado", o modelo ainda funciona, mas já não é recomendado — e ganha uma data de aposentadoria. No estágio final, a chamada de API falha por completo. A tabela pública de modelos mostra versões inteiras do Claude 3, do Claude Sonnet 4 e do Claude Opus 4 já fora do ar em 2026, cada uma com uma data de aviso e uma data de corte registradas.
A OpenAI descreve o mesmo ciclo com prazos próprios: seis meses para um modelo de uso geral, três para uma variante especializada, duas semanas para algo em fase de teste. Em alguns casos, a empresa oferece capacidade dedicada mediante contrato para quem precisa manter acesso a uma versão específica depois do desligamento — uma opção, não uma garantia.
O calendário público da Anthropic mostra o padrão se repetindo ano após ano: Claude Opus 4.1 foi avisado em 5 de junho de 2026 e saiu do ar em 5 de agosto — exatamente os 60 dias mínimos que a política promete. Antes dele, Claude 2, Claude 2.1 e outras versões passaram pelo mesmo ciclo. O prazo é público e previsível. O problema é que raramente alguém na empresa está de olho nele até o e-mail de aviso chegar.
O segundo problema, menos falado, é que o comportamento muda mesmo quando o modelo não é aposentado. Um estudo de pesquisadores de Stanford e Berkeley comparou o mesmo serviço de IA em duas datas, com três meses de intervalo, em sete tipos de tarefa: matemática, perguntas sensíveis, opiniões, raciocínio em várias etapas, geração de código, prova de licenciamento médico e raciocínio visual. Em uma das tarefas — identificar se um número é primo ou composto — a taxa de acerto caiu de 84% em março para 51% em junho, com o rótulo de versão continuando o mesmo.
Os autores do estudo resumem o achado numa frase direta: o comportamento do "mesmo" serviço de IA pode mudar de forma substancial num intervalo curto de tempo, o que exige monitoramento contínuo. Ou seja: nem esperar o aviso de aposentadoria é suficiente. A versão pode continuar no ar e ainda assim responder diferente do que respondia há três meses.
Por que o aviso raramente chega a tempo de quem decide
O aviso de descontinuação normalmente chega para quem administra a conexão técnica com o modelo de IA — não para quem desenhou a rotina que depende dele. Um comunicado por e-mail sobre uma data de corte em dois meses circula entre poucas pessoas, e o registro de "por que fazemos assim" e "o que essa rotina precisa entregar" quase nunca está escrito em lugar nenhum.
Quando a data chega, a pergunta que devia ser simples — "o que essa rotina faz e o que ela precisa continuar fazendo?" — não tem resposta pronta. Alguém vai ter que reconstruir a partir do resultado que a rotina produzia, sem saber quais instruções, quais exemplos e quais ajustes chegaram a esse resultado. É trabalho de reconstrução, não de troca.
O mesmo vale para a mudança silenciosa que o estudo de Stanford e Berkeley descreve. Sem um jeito de comparar a resposta de hoje com a de três meses atrás, ninguém percebe a queda até um erro aparecer em produção — e, quando aparece, o primeiro instinto costuma ser desconfiar da pessoa que operou a rotina, não da versão do modelo por trás dela.
Para uma empresa brasileira ou latino-americana, o efeito costuma ser mais duro, não mais leve. O time que monta a rotina de IA quase nunca é o mesmo que acompanha o calendário de versões de cada fornecedor — normalmente é uma área de negócio, não uma equipe de infraestrutura dedicada a isso. Quando o aviso chega em inglês, com uma data de corte em dois meses, a mensagem compete com a operação do dia a dia e, com frequência, só é lida depois que algo já parou de funcionar.
O que precisa existir na prática
O roteiro da rotina pertence à empresa, não a uma conversa avulsa. O que a rotina deve fazer, com quais instruções, para qual resultado — isso precisa estar registrado num lugar central, não apenas na memória de quem montou a primeira versão.
Cada tarefa é roteada para o modelo de IA adequado, não fixada num só. Trocar o modelo por trás de uma rotina deveria ser uma decisão de configuração, feita em minutos, e não uma reconstrução do zero quando o fornecedor manda o aviso de desligamento.
Testar antes de trocar é parte do processo, não um passo extra. Antes de uma rotina crítica passar a rodar num modelo novo, o resultado da versão nova é comparado com o da versão anterior nos mesmos casos — a mesma disciplina que o estudo de Stanford e Berkeley recomenda para qualquer mudança de comportamento.
Trilha de auditoria mostra o que mudou e quando. Quando um resultado sai diferente do esperado, dá para checar se a causa foi uma troca de modelo, um ajuste na instrução ou outra coisa — em vez de investigar às cegas.
É assim que a Skyller foi desenhada: o roteiro e o histórico de cada rotina ficam registrados na plataforma, com roteamento automático para o modelo de IA mais adequado a cada tarefa, e trilha de auditoria mostrando cada mudança.
O ganho de não amarrar a operação a um único modelo
Quando o roteiro pertence à empresa e não a uma versão específica de modelo, o aviso de descontinuação vira um evento operacional — configuração revisada, resultado comparado, rotina liberada — em vez de uma crise que exige reconstruir do zero em semanas.
O mesmo vale para a queda silenciosa de qualidade. Uma equipe que monitora o resultado de uma rotina crítica percebe a variação antes de um cliente ou um auditor perceber por ela. E o histórico de quem aprovou cada versão do roteiro fica disponível para qualquer revisão futura.
Isso não elimina o trabalho de acompanhar o mercado de modelos de IA — nenhuma empresa evita isso. O que muda é onde mora o conhecimento sobre a própria rotina: na plataforma que a empresa controla, não apenas na cabeça de quem a criou nem preso a um fornecedor específico.
Perguntas para levar à próxima reunião de tecnologia
Antes que o próximo aviso de descontinuação chegue, vale responder a estas perguntas com quem administra as rotinas de IA da empresa:
- Se o modelo por trás da rotina mais crítica saísse do ar amanhã, quem sabe reconstruí-la e em quanto tempo? Se a resposta depende de uma pessoa específica, o roteiro não pertence à empresa — pertence a ela.
- Existe um jeito de comparar o resultado de hoje com o de três meses atrás? Sem essa comparação, uma queda de qualidade só aparece quando já causou um problema visível.
- A troca de modelo por trás de uma rotina é uma configuração ou um projeto? Se for um projeto, cada aviso de descontinuação vira uma crise evitável.
