Aposentar um modelo é a nova depreciação de API. Só que muda o comportamento, não a sintaxe

Quando uma API REST é descontinuada, a falha faz barulho. As chamadas retornam erro, os testes quebram, alguém é acionado de madrugada. Quando um modelo é aposentado, a falha pode ser silenciosa. O endpoint é substituído, as chamadas continuam funcionando e as respostas mudam. O classificador de notas fiscais continua devolvendo uma categoria. Só que nem sempre a mesma.

Por isso, uma atualização de rotina na documentação da Databricks nesta semana merece a atenção de quem roda IA em produção.

O que aconteceu

A documentação das Foundation Model APIs da Databricks lista o Gemini 2.5 Flash e o Gemini 2.5 Pro como aposentados em 2 de outubro de 2026. A política de manutenção mostra o Gemini 2.5 Flash saindo tanto no pay-per-token quanto no provisioned throughput, e o Gemini 2.5 Pro saindo do provisioned throughput na mesma data. Os substitutos recomendados são o Gemini 3.1 Pro ou o Gemini 3.5 Flash.

O próximo da fila: o Claude Sonnet 4 no pay-per-token será aposentado em 9 de outubro de 2026, com o Claude Sonnet 4.6 como substituto recomendado. O DeepSeek V4 Pro (0813) e o Inkling, da Thinking Machine Labs, ainda em Public Preview, saem em 30 de outubro.

A política é clara sobre a mecânica. O modelo passa de legacy (não é mais oferecido a novos workspaces) para depreciado (com data de aposentadoria anunciada para 30 ou 90 dias depois) e daí para aposentado (inacessível). Quem usa provisioned throughput às vezes ganha mais prazo: o Meta Llama 3.1 405B saiu do pay-per-token em fevereiro de 2026, mas ficou disponível em provisioned throughput até maio.

Um detalhe importa mais do que as datas. Quando o fornecedor do modelo avisa com menos de um mês de antecedência, a Databricks diz que pode redirecionar temporariamente as chamadas para uma versão parecida, para dar tempo de migrar. Entre 26 de março e 7 de junho de 2026, as chamadas ao Gemini 3 Pro foram redirecionadas para o Gemini 3.1 Pro. É uma cortesia razoável. Também significa que o modelo que responde ao seu tráfego de produção pode mudar sem que uma linha do seu código mude.

Por que é mais difícil do que depreciar uma API

Depreciar uma API muda o contrato. Aposentar um modelo mantém o contrato e muda o comportamento por trás dele. O modelo novo costuma ser melhor na média, mas sistema em produção não roda na média. Roda em prompts específicos, formatos de saída específicos, limiares que alguém calibrou e código que interpreta o que volta.

O que pode mudar numa troca de modelo:

• O formato da saída: o JSON que vinha enxuto chega com comentários, um campo muda de nome, uma lista muda de ordem.
• O julgamento: os casos de fronteira de um classificador caem de outro jeito; a extração fica mais ou menos conservadora.
• Custo e latência: um substituto de categoria superior pode dobrar o custo por tarefa, cobrado em dólar, ou somar segundos a uma etapa com orçamento de latência.
• Recusas e comportamento de segurança: o modelo novo pode recusar entradas que o antigo aceitava, ou o contrário.

Nada disso gera erro. Tudo isso pode quebrar um processo de negócio.

Trate modelo como dependência com prazo de validade

1. Aviso de aposentadoria
2. Candidato a substituto
3. Evals de regressão nas suas tarefas
4. Checagem de custo e latência
5. Release aprovada
6. Caminho de rollback mantido

EvidênciaControle de release

Mantenha um inventário com datas. Todo uso de modelo hospedado em produção deve estar listado com fornecedor, plataforma, modalidade de cobrança e data de aposentadoria publicada. Quase todo time sabe quais modelos usa; poucos sabem quais vencem neste trimestre.

Abstraia o nome do modelo. Referencie modelos por configuração ou por uma rota no gateway, não por strings espalhadas pelos serviços. Na análise do C1 LLM Gateway, mostramos que o gateway está virando ponto de política; o ciclo de vida dos modelos é mais uma política que ele pode aplicar.

Tenha um conjunto de regressão próprio. O único jeito confiável de aprovar um substituto é rodá-lo nas suas tarefas, com a sua forma de pontuar. É o argumento do nosso texto sobre o Palantir AIP Evolve: a avaliação é a superfície de controle que torna a mudança segura.

Fixe a versão quando puder e saiba quando não pode. Fixar compra previsibilidade até a data de aposentadoria. Com redirecionamento, a versão fixada vira um pedido, não uma garantia.

Defina o fallback antes. Se um modelo sumir ou piorar, qual assume, a que custo e quem aprova a troca?

Passe a troca pela gestão de mudanças de sempre. Num banco, a Resolução CMN nº 4.893 já pede governança sobre serviços de processamento e nuvem contratados; um modelo trocado pelo fornecedor é exatamente uma mudança num serviço contratado. No varejo, a conta é de calendário: quem congela mudanças antes da Black Friday precisa saber agora quais modelos expiram até lá. O DeepSeek V4 Pro sai em 30 de outubro, a poucas semanas do congelamento de muitas operações.

O que fazer nesta semana

1. Procure no código e nas configurações o Claude Sonnet 4 em pay-per-token na Databricks. O dia 9 de outubro está a seis dias.
2. Liste todos os modelos hospedados de que você depende com a data de aposentadoria, e coloque essas datas no mesmo calendário dos vencimentos de certificados.
3. Monte um conjunto pequeno de regressão por caso de uso, mesmo que sejam 50 casos representativos com a saída esperada, e rode antes de qualquer troca.
4. Pergunte às plataformas como tratam aposentadorias com aviso curto: redirecionamento, erro ou fallback, e se avisam quando o tráfego é redirecionado.
5. Reserve orçamento para migrações. Cada modelo do qual você depende implica pelo menos uma migração por ano.

Para fechar

Modelos hospedados viraram dependências com data de validade publicada, e o substituto nunca é plug and play no sentido estrito. Vai lidar bem com isso quem já trata a troca de modelo como uma release: inventário, avaliação, aprovação e caminho de volta.