Como tratar a descontinuação de modelo de IA em produção

A descontinuação de modelo de IA começa antes de a API parar. Em 30/09/2026, a Anthropic informou a retirada do Claude Sonnet 4.5 para 30/11 na Claude API: são 61 dias nesse caso. A data não identifica os chamadores. Inventário, teste e conferência de uso residual transformam o aviso em uma migração verificável.

Quadro de decisão / Fatos-chave: O prazo anunciado precisa ser conferido na plataforma contratada. Cada dependência precisa de responsável e critério de aceite. Um substituto recomendado ainda exige teste da carga. Fallback protege contra falhas; não comprova a retirada da dependência.

O roteiro segue cinco passos, nesta ordem:

1. Registrar o aviso e a data aplicável à rota contratada.
2. Descobrir quais aplicações ainda chamam o modelo.
3. Priorizar dependências e atribuir prazos de decisão.
4. Avaliar substitutos com critérios da carga.
5. Migrar em etapas e preparar um retorno seguro.

Depois da mudança, a equipe verifica o uso residual por aplicação. Um modelo que ainda responde não é uma garantia de prazo disponível, e um fallback bem configurado não comprova que todos os chamadores foram migrados. O guia de fallback de LLM trata da disponibilidade durante falhas; aqui, o problema é retirar uma dependência com data marcada.

Quais pré-requisitos a descontinuação de modelo de IA exige?

A equipe precisa da documentação da rota contratada, de histórico de chamadas com janela conhecida e de acesso às configurações das aplicações. Também precisa de responsáveis de negócio e engenharia, orçamento para testes e um ambiente autorizado. Chamadas diretas entram. O levantamento deve alcançar as requisições feitas fora do gateway.

Antes de abrir a planilha, alguém precisa confirmar quem pode consultar logs, exportações e repositórios, e por quanto tempo cada fonte guarda registros. Sem registro, não há prova. Um log indisponível para o período necessário representa apenas uma lacuna de cobertura, e a equipe não pode concluir que a aplicação deixou de usar o modelo. A equipe registra a fonte, a janela disponível e a pessoa que pode confirmar o uso fora dela.

O inventário inclui ambientes de produção e outros ambientes capazes de enviar requisições relevantes, integrações, tarefas agendadas e identificadores de chaves. Identificador não é segredo. O registro não deve conter o valor da chave, e o acesso às evidências de teste deve seguir as regras internas para os dados utilizados. O responsável de negócio define o resultado aceitável; engenharia identifica a rota e organiza os testes. A equipe financeira precisa conhecer o limite disponível para a avaliação.

Passo 1: registre o aviso e a data que vale para sua rota

O registro do aviso reúne URL, modelo e versão, provedor, plataforma contratada, escopo, substituto indicado e responsável. A data de retirada precisa corresponder à plataforma usada pela aplicação. Horário e fuso podem faltar. Nesse caso, o campo permanece como GAP até confirmação com o fornecedor.

A documentação da Anthropic distingue modelos ativos, legados, descontinuados e retirados. Na definição da empresa, um modelo de IA descontinuado ainda funciona, mas deixa de ser recomendado e recebe uma data de retirada; requisições a um modelo retirado falham. Esse comportamento pertence à política citada e não deve ser atribuído automaticamente a outro provedor.

No caso do claude-sonnet-4-5-20250929, o aviso de 30/09/2026 e a retirada indicada para 30/11/2026 delimitam 61 dias de calendário. A política é específica. A Anthropic declara aviso mínimo de 60 dias para clientes com implantações ativas de modelos disponibilizados publicamente. Nenhum desses números estabelece um prazo típico universal de mercado: esse prazo é GAP.

A data também tem endereço. A documentação informa que suas datas valem para plataformas operadas pela Anthropic e que plataformas operadas por parceiros podem ter cronogramas próprios. A equipe consulta a via contratada antes de copiar o prazo para seu plano e registra um prazo interno anterior à retirada. Essa antecedência é decisão operacional da equipe, não um SLA universal.

Passo 2: descubra quem ainda chama o modelo

O inventário cruza chamadas registradas no gateway, exportações do provedor e referências em código, configurações e agendamentos. Cada dependência recebe aplicação, ambiente, identificador seguro da chave, equipe, responsável primário, substituto e última chamada observada. A janela de coleta e as fontes precisam aparecer ao lado dos resultados.

Inventário de migração é o registro reconciliado de aplicações, identificadores de chamada, responsáveis, janela de observação e estado de substituição para cada dependência de um modelo com retirada anunciada. É uma definição editorial para orientar o trabalho, não uma classificação criada pelo provedor. Sem dono, a linha fica aberta. Atribua ou escale.

Na própria Claude API, a Anthropic orienta exportar os dados de Usage e analisar o CSV por chave e modelo. A exportação ajuda a localizar uso nessa API, mas não demonstra que todas as aplicações da empresa passam por ela. O cruzamento com logs de gateway e configurações busca as diferenças entre as fontes; o artigo sobre observabilidade de LLMs em produção detalha os sinais que apoiam essa leitura.

A janela precisa cobrir a rotina.

Uma coleta de 30 dias não cobre automaticamente tarefas mensais, trimestrais ou chamadas diretas: a equipe compara a janela com o ciclo de cada carga e pede confirmação ao responsável. Também registra volume e última chamada observados, sem transformar falta de registro em volume zero. Histórico insuficiente, retenção expirada e acesso direto desconhecido entram como GAP.

O fluxo exige reconciliação. Dependências sem responsável e acessos diretos seguem pelo ramo de exceção até que a equipe consiga resolvê-los. O diagrama não representa uma interface de produto.

Passo 3: priorize dependências e defina o prazo de resposta

A prioridade combina impacto de negócio, criticidade, frequência, permissões e esforço de mudança. Para cada dependência, a equipe registra quem aceita o resultado, quem executa a alteração, qual evidência falta e até quando a decisão deve ocorrer. Sem responsável, escale o item.

A tabela abaixo é um modelo de preenchimento. O NIST recomenda inventariar sistemas de IA conforme os riscos da organização. Não há clientes nem resultados reais. A equipe usa uma linha por dependência e substitui as instruções pelos próprios registros, preservando a fonte da informação e a data de revisão.

Frequência não define prioridade. Uma tarefa infrequente pode concentrar uma entrega que não admite repetição imediata; por isso, o dono precisa avaliar a consequência de falha, e não apenas o volume de chamadas. Permissões de acesso e esforço de adaptação também entram na decisão: se a equipe não consegue testar o substituto a tempo, precisa escalar essa restrição antes de aprovar a mudança.

O prazo de decisão antecede a retirada para permitir correção de falhas de teste e nova validação. A equipe define a margem conforme a carga e registra quem recebe o escalonamento. Não existe número autorizado para estabelecer essa margem em toda operação.

Passo 4: avalie substitutos antes de alterar a rota

O substituto sugerido pelo provedor é candidato, não aprovação. A equipe compara acesso contratado, modalidades, contexto, ferramentas, formato de saída, parâmetros, privacidade, qualidade, latência e custo em tarefas autorizadas. Campo não verificado é GAP. Registre responsável e forma de teste antes da decisão.

Na consulta de 11/11/2026, a tabela da Anthropic indicava claude-sonnet-5-5 como substituto recomendado para claude-sonnet-4-5-20250929. A indicação não demonstra compatibilidade com uma aplicação, preço contratado ou disponibilidade na plataforma escolhida. A documentação muda. Confirme os dados antes da publicação e da migração.

O dono da carga aprova critérios antes da comparação, incluindo formato esperado, conteúdo obrigatório, limites de latência e tratamento de respostas inadequadas. Engenharia executa os mesmos casos reais autorizados e casos de borda relevantes nos candidatos e, quando disponível, no modelo anterior, registra condições, entradas e resultados conforme as regras de segurança da organização e compara os resultados pelos critérios aprovados. Dados sensíveis não precisam aparecer no relatório para que a decisão seja auditável.

A compatibilidade da interface merece teste separado. A documentação da Anthropic informa que parâmetros de API podem ser descontinuados independentemente dos modelos. Por isso, a equipe verifica os parâmetros da rota contratada e corrige incompatibilidades antes de aumentar o tráfego. Um nome de modelo aceito não prova que a resposta atende à tarefa.

Passo 5: migre em etapas e prepare retorno seguro

A migração começa depois da confirmação de acesso, orçamento e critérios de aceite. A equipe revisa interface e parâmetros, envia uma amostra autorizada para a nova rota e acompanha o resultado antes de aprovar aumentos graduais. O controle é proposta de engenharia. Não se presume esse recurso no Router.

A mudança de rota deve ter um responsável identificado, uma forma de interromper o avanço e um registro das condições que permitem continuar. A equipe acompanha erros, latência, consumo e qualidade na amostra, comparando os resultados com os limites aprovados. Se o critério falhar, suspende a ampliação e investiga antes de enviar mais tráfego.

O retorno depende do calendário. Enquanto o modelo anterior ainda estiver disponível, a equipe pode manter um plano de retorno a ele, desde que essa rota continue autorizada e o prazo permita usá-la. Depois da retirada, não se deve prometer retorno ao modelo extinto. A alternativa é outra rota previamente testada ou a interrupção com encaminhamento definido pelo responsável da operação.

O fallback complementa a proteção. A alternativa deve atender à carga. Ele não identifica todos os chamadores nem substitui o aceite. Mesmo quando a alternativa atende chamadas, a equipe precisa remover da configuração da rota a dependência do modelo com data de encerramento e verificar a mudança aplicada.

Como verificar que a migração foi concluída?

A conclusão da migração de modelos de IA exige reconciliar chamadas recentes por aplicação e chave, cobrir a periodicidade das cargas e confirmar acessos fora do gateway. Cada responsável aceita a mudança e aponta a evidência correspondente. Exceções, testes, janela analisada e data de revisão ficam registrados junto ao estado de cada dependência.

A mudança precisa aparecer. A equipe compara o inventário original com as fontes e procura o modelo antigo em configuração, código e agendamentos. Se houver uma chamada residual, identifica o responsável e devolve aquela dependência para tratamento. Uma alteração anunciada em reunião não é uma alteração aplicada na rota.

O relógio da métrica importa. Um agregado de 30 dias pode conservar chamadas anteriores à migração; ele não precisa zerar imediatamente para que uma mudança recente tenha ocorrido. Em sentido inverso, zero chamadas recentes em uma janela curta não demonstra ausência de uma tarefa trimestral. Para cada carga, a equipe documenta a janela adequada e confirma o ciclo com seu dono.

Se uma fonte não cobre o período necessário ou se uma aplicação faz acesso direto sem registro reconciliado, a conclusão permanece condicionada à resolução desse GAP. O aceite final reúne a mudança aplicada, o teste aprovado e a verificação de uso residual nas fontes e janelas cobertas, com exceções e limites de observação documentados. O fechamento sem essas evidências troca um prazo do provedor por uma pendência sem data.

Quanto custa migrar sob pressão?

A estimativa reúne esforço medido por função, consumo incremental medido e outros custos comprovados. Entram inventário, adequação, validação, homologação, observabilidade e revisão de segurança, além do acesso ao substituto e de eventual operação degradada. Onde faltar tarifa ou medição, o valor permanece como GAP.

A fórmula de trabalho é: custo estimado = horas por função multiplicadas pelo custo aplicável + consumo incremental multiplicado pelas tarifas aplicáveis + outros custos comprovados, sem dupla contagem. Para aplicar a fórmula, a equipe associa horas às funções envolvidas, registra a base de cálculo dessas horas e separa o consumo de teste do consumo que já ocorreria sem a migração. Também anota despesas adicionais que consiga comprovar. Valores previstos e observados ficam em campos diferentes.

O preço do substituto é GAP enquanto a tarifa aplicável não for conferida. O custo médio de migração, as perdas evitadas e o percentual de tráfego afetado também são GAP neste guia; não há base autorizada para preenchê-los com um número de mercado. Uma rota aceita pela qualidade pode ter consumo e preço diferentes da anterior, mas a direção e a magnitude dessa diferença exigem medição da carga.

O estudo sobre custo por tarefa trata de outro tema. Compara custos. Na migração, a pergunta anterior à conta é se o candidato cumpre a tarefa e se a equipe consegue alterá-la antes do prazo. Sem esses dois registros, uma tarifa menor não resolve o custo da dependência que continua ativa.

Quais erros impedem a continuidade?

Para preservar a continuidade de produção de IA, a equipe deve corrigir dependências sem dono, fontes que deixam de registrar chamadas e substitutos aceitos sem teste. A resposta é associar cada sintoma a uma verificação e a uma ação, com prazo de resolução e escalonamento para a pessoa responsável.

A tabela não encerra a investigação. Se o histórico estiver incompleto, a equipe registra o limite da fonte e procura confirmação em outra evidência; se o substituto falhar no critério de qualidade, preço ou latência, a mudança não recebe aceite. No guia de critérios de fallback no atendimento, a decisão é tratada no nível da interação; aqui, ela precisa ser acompanhada até a retirada da dependência de cada aplicação.

Perguntas frequentes

A descontinuação de modelo de IA exige tratar separadamente o aviso, a mudança de rota e a comprovação de que as aplicações deixaram de depender do modelo. As respostas abaixo delimitam o que a política citada afirma e o que continua dependendo de teste e confirmação da equipe responsável.

O que é a descontinuação de um modelo de IA?

Na política da Anthropic citada, é a fase em que o modelo ainda funciona, mas deixa de ser recomendado e recebe uma data de retirada. A consequência varia por plataforma. Na documentação da Anthropic, requisições a modelos retirados falham.

Como descobrir quem ainda usa um modelo?

A equipe cruza logs, exportações do provedor e configurações de aplicações, buscando relacionar cada chamada observada a um identificador seguro e a um responsável; chaves compartilhadas e aliases exigem reconciliação adicional. Inclua acessos diretos e tarefas infrequentes. Cubra o ciclo completo da carga, da entrada em produção até o último fluxo sazonal, e registre a lacuna quando a cobertura faltar.

O substituto recomendado é compatível?

A recomendação indica um candidato. Não garante equivalência. O responsável precisa confirmar acesso contratado e testar formato de saída, parâmetros, qualidade, privacidade, latência e custo na própria carga. Sem medição, registre GAP. A equipe precisa obter evidências antes de decidir.

Fallback resolve uma descontinuação?

Fallback pode proteger a rota quando o modelo falha, desde que exista alternativa configurada e apta para a carga. Não substitui o inventário, o teste do substituto nem a confirmação da retirada de cada dependência. O retorno tem limite. Ele deixa de ser opção quando a plataforma usada pela aplicação retira o modelo antigo.

Quando encerrar a migração?

O encerramento vem após a reconciliação das fontes, a verificação em janela adequada à frequência de cada carga e o aceite dos responsáveis. Registre exceções, testes e revisão. Ausência de chamadas em uma janela curta, isoladamente, não comprova ausência de dependências.

Referências e Leitura Complementar

A documentação oficial da Anthropic sustenta o caso datado e os limites da política atribuída ao provedor. Os artigos internos citados tratam de disponibilidade, observabilidade, critérios de fallback e custo por tarefa em recortes distintos. Consulte novamente antes de publicar.

A página de descontinuações da Anthropic foi consultada em 11/11/2026. A data depende da plataforma. Os procedimentos de inventário e aceite apresentados neste guia são recomendações editoriais para a equipe responsável, não uma descrição de ferramentas específicas oferecidas pelo provedor ou uma promessa de compatibilidade.

Qual é o próximo passo para a equipe?

A equipe deve abrir o inventário pela rota contratada e atribuir um responsável a cada dependência antes de escolher a sequência dos testes. O registro precisa sobreviver à troca de modelo: ele guarda a decisão, a fonte da data e a evidência usada para encerrar a migração.

O Nexforce Router é um gateway de modelos com regras de roteamento por chave, limites de gasto, logs, métricas, rastreamento, alertas e painéis, além de fallback de modelo configurável e failover de provedor. Esses recursos apoiam o acompanhamento das chamadas que passam pelo Router. Acessos diretos exigem outra verificação. Os recursos não aceitam a mudança em nome do responsável. A equipe continua responsável por testar substitutos, confirmar donos e retirar as dependências antes da data aplicável.