Descontinuação de modelo de IA: o que fazer com seus agentes

A descontinuação de um modelo de IA é um evento de negócio, não apenas técnico. O fornecedor avisa que uma versão do modelo vai parar de funcionar em uma data definida, e todo agente construído sobre ela precisa de um substituto testado antes disso. Para se preparar, liste onde cada modelo é usado, monte um conjunto de testes a partir do trabalho real, escolha um substituto principal e um reserva, e avise as pessoas que dependem do agente sobre o que vai mudar. Feita com antecedência, a descontinuação vira uma mudança agendada em vez de uma parada.

Principais pontos

• O aviso de descontinuação é um prazo, não um sinal de largada. Comece o inventário e o conjunto de testes no dia em que o aviso chegar.
• Saiba cada lugar em que um modelo é usado, inclusive ferramentas e produtos de terceiros que embutem um modelo sem avisar com destaque.
• Avalie o substituto nas suas próprias tarefas, com um conjunto de testes feito de casos reais, e não pela descrição que o fornecedor faz do sucessor.
• Escolha um substituto principal e um reserva, e registre o motivo, para que a decisão sobreviva a trocas de equipe.
• Diga aos usuários o que vai mudar, o que não vai e como reportar qualquer comportamento estranho. Mudanças silenciosas corroem a confiança mais rápido que mudanças anunciadas.

O que o aviso de descontinuação muda e onde o modelo é usado?

Um aviso de descontinuação informa que uma versão específica do modelo deixará de responder a requisições depois de uma data declarada. Às vezes o fornecedor indica um sucessor, às vezes apenas uma família de modelos. Em qualquer caso, o comportamento do seu agente está ligado àquela versão: o tom, o quanto ela segue instruções, como formata a saída, quando decide chamar uma ferramenta e quando se recusa a agir.

Um modelo mais novo costuma ser capaz, mas capaz não é o mesmo que idêntico. Instruções ajustadas para um modelo podem gerar respostas mais longas, recusas diferentes ou outras escolhas de ferramenta em outro. Por isso o trabalho é uma mudança controlada, e não uma simples edição de configuração.

Os riscos para o negócio são concretos:

• A qualidade muda sem alarde, e ninguém percebe até que um cliente ou um colega do financeiro perceba.
• O agente para de funcionar na data de descontinuação porque ninguém era responsável pelo aviso.
• A velocidade e o custo por tarefa concluída mudam, o que afeta níveis de serviço e orçamentos.
• Os termos de tratamento de dados diferem entre modelos ou fornecedores, o que importa se você trocar de provedor.

Comece por um inventário. Para cada agente, rotina agendada, script interno e ferramenta de terceiros, registre:

• O identificador do modelo que ele chama, e se está fixado em uma versão ou aponta para um alias, como um rótulo de última versão.
• Onde essa configuração fica e quem pode alterá-la.
• A tarefa que ele executa, e se a saída chega ao cliente ou aciona ações em outros sistemas.
• A pessoa responsável pelo fluxo de trabalho e a pessoa que primeiro notaria uma mudança de qualidade.
• Como uma falha apareceria: um erro, uma resposta errada, uma resposta lenta ou uma etapa pulada em silêncio.

Procure usos escondidos. Uma automação sem código, um plugin ou um produto de terceiros pode chamar um modelo em seu nome. Pergunte diretamente a esses fornecedores qual modelo usam e o que pretendem fazer diante do aviso. Versões fixadas param na data de descontinuação. Aliases podem mudar sozinhos, o que é mais cômodo e também mais arriscado, porque a mudança chega sem a sua revisão.

Como montar um conjunto de testes que mostre se o substituto é seguro?

Um conjunto de testes é uma coleção de situações reais que o agente precisa resolver, cada uma com uma definição clara de bom resultado. É a coisa mais útil que você pode preparar, porque transforma a pergunta "o novo modelo está bom?" em algo que você pode verificar. O método é detalhado em Monte um conjunto de testes de referência para sua IA, e o que segue é a versão curta para uma descontinuação.

Tire os casos do histórico real do agente. Com autorização e com dados pessoais ocultados, escolha exemplos que cubram:

• Pedidos típicos, que formam a maior parte do trabalho diário.
• Pedidos incômodos, mas legítimos, como informação faltando, idiomas misturados ou instruções contraditórias.
• Casos em que o comportamento certo é parar e passar para uma pessoa.
• Casos em que o agente deve recusar ou não pode revelar algo.
• Casos com uso de ferramentas, em que a ação correta e seus argumentos importam, não só o texto.
• Erros passados. Todo erro que o agente cometeu e você corrigiu merece um lugar permanente no conjunto.

Para cada caso, escreva a entrada, o contexto que o agente teria e o resultado esperado na forma de verificações, não de texto exato. Duas boas respostas raramente são iguais, então teste o que importa: os fatos certos foram usados, a ferramenta certa foi chamada com os valores certos, a escalada aconteceu quando devia, o formato é válido, o tom segue suas diretrizes e nada foi revelado indevidamente.

Rode o conjunto primeiro no modelo atual e guarde os resultados como referência. Sem essa linha de base, não dá para saber se uma falha é nova ou sempre existiu. Peça a uma pessoa que revise a primeira rodada de avaliação, pois um critério que parece claro no papel costuma precisar de ajuste quando as saídas reais aparecem. Depois disso, você pode automatizar as verificações confiáveis e deixar os julgamentos para um revisor. Os guias de avaliação da OpenAI e da Anthropic listados nas fontes são boas referências para estruturar isso. Para a questão mais ampla de medir agentes em trabalho real, veja Como avaliar agentes de IA em tarefas de negócio neste jornal.

Um hábito prático facilita tudo isso: registre a versão do modelo em cada execução do agente. Se seus registros mostram qual versão produziu qual saída, comparar antes e depois vira uma consulta, e não uma escavação arqueológica. As convenções do OpenTelemetry para IA generativa descrevem uma forma comum de nomear esses campos.

Como escolher um modelo reserva?

Escolha com base nas evidências do seu conjunto de testes e nas restrições de operação, não pela reputação. Um modelo que lidera um ranking público ainda pode ser pior para a sua tarefa de conciliação de notas do que um modelo menor. Siga este guia de decisão, nesta ordem:

• Comece pelo sucessor indicado pelo fornecedor. É o caminho de menor mudança, então teste-o primeiro e ajuste as instruções se necessário.
• Se o sucessor passa, mas é mais lento ou mais caro do que a tarefa exige, teste uma faixa menor ou mais rápida da mesma família. Julgue pelo custo por tarefa concluída, não pelo custo por mensagem.
• Se o sucessor falha em casos que importam e ajustes de instrução não resolvem, teste um modelo de outro fornecedor. Aceite que isso traz trabalho de migração: formatos de ferramentas, limites de uso, termos de dados e registros precisam de atenção. Os passos de saída estão em Plano de saída de fornecedor de IA: o que manter e documentar.
• Se a tarefa é estreita e estável, pergunte se ela precisa mesmo de um modelo. Algumas etapas funcionam melhor como regras fixas, e retirar a dependência de um modelo elimina o risco de descontinuação nessa etapa.
• Mantenha um reserva. Nomeie um segundo modelo que também passou no conjunto de testes, para que uma queda ou um novo aviso não force uma escolha apressada. O raciocínio por trás disso está em Plano de continuidade de negócios para agentes de IA: como agir em quedas.

Ao comparar candidatos, verifique mais do que a qualidade das respostas:

• Confiabilidade das chamadas de ferramentas e da saída estruturada.
• A quantidade de contexto que a tarefa exige e como o modelo lida com entradas longas.
• O tempo de resposta frente ao que o fluxo de trabalho tolera.
• Disponibilidade regional e os termos do fornecedor sobre reter ou treinar com os seus dados.
• O comportamento nos casos de escalada e recusa, que é onde pequenas diferenças mais machucam.

Registre a decisão em uma página: candidatos testados, resultados, a escolha, o reserva e os motivos. Quando alguém perguntar meses depois por que o agente roda nesse modelo, a página responde.

Qual é um plano prático de preparação, do aviso à troca?

Esta rotina serve para a maioria dos agentes de negócio. Ajuste a profundidade ao risco do fluxo: um resumidor interno pede menos cerimônia do que um agente que redige compromissos com clientes.

• Registre o aviso: o modelo, a data de descontinuação, o sucessor indicado, se houver, e um responsável único.
• Conclua o inventário descrito acima e confirme que nada ficou de fora perguntando a cada fornecedor e a cada equipe que cria automações.
• Congele uma linha de base rodando o conjunto de testes no modelo atual e salvando os resultados.
• Rode cada candidato no conjunto de testes com as instruções atuais sem alteração. Isso mostra a diferença bruta.
• Ajuste instruções, descrições de ferramentas ou contexto, mudando uma coisa por vez, e rode de novo. Anote o que ajudou.
• Com o responsável pelo negócio, classifique as falhas restantes em três grupos: aceitáveis, corrigíveis e impeditivas. Não avance enquanto houver falhas impeditivas.
• Rode o candidato em paralelo no trabalho real, sem dar autoridade a ele. Ele redige, uma pessoa compara. É a mesma ideia do modo de observação usado antes de confiar em qualquer agente.
• Decida com o roteiro de O que fazer quando o modelo de IA muda: adotar, ajustar ou reverter e agende a troca bem antes da data de descontinuação.
• Troque primeiro os fluxos de menor risco, mantenha um caminho de volta ao modelo antigo enquanto ele ainda estiver disponível e preserve exatamente as regras de aprovação e as permissões.
• Acompanhe de perto o primeiro período: correções dos revisores, escaladas, erros de ferramentas, tempo de resposta. Compare com a linha de base.
• Atualize o runbook com o novo modelo, os resultados dos testes, o reserva e a data da próxima revisão.

Dois cuidados. Primeiro, não combine a troca de modelo com outras mudanças, como novas ferramentas ou novas permissões. Se algo der errado, você precisa saber a causa. Segundo, deixe margem. Modelos substitutos podem exigir mais de uma rodada de ajustes, e descobrir um problema impeditivo perto da data de descontinuação deixa apenas opções ruins.

O que dizer aos usuários e à equipe, e quando?

As pessoas que trabalham com o agente devem saber da mudança por você, antes de notarem sozinhas. O silêncio é a causa mais comum de perda de confiança: um revisor vê rascunhos um pouco diferentes, supõe que algo quebrou e então para de usar o agente ou para de conferir o que ele faz.

Avise estes grupos:

• Usuários diários e revisores, que precisam saber o que pode parecer diferente e como sinalizar.
• Gestores que dependem do fluxo, que precisam do cronograma e do plano de reversão.
• Clientes, apenas se o agente atende o público e a mudança afeta o que eles percebem. Na maioria das vezes um aviso é desnecessário se a qualidade se mantém, mas a equipe de suporte deve estar pronta para perguntas.
• Quem cuida de jurídico, segurança ou proteção de dados, se o substituto envolve outro fornecedor ou outros termos de dados.

Uma mensagem curta funciona melhor, com estas partes:

• O que está mudando e a data.
• O que não está mudando: o papel do agente, suas permissões e as regras de aprovação.
• O que você pode notar, como frases ou tamanhos diferentes, no primeiro período.
• Como reportar algo estranho e a quem.
• Quem é o responsável pela mudança.

Cenário ilustrativo: uma distribuidora usa um agente que redige respostas sobre o status de pedidos para a equipe de atendimento. O aviso de descontinuação chega, e a equipe monta um conjunto de testes a partir de chamados antigos, incluindo casos em que o agente deve passar a conversa para uma pessoa. O sucessor indicado passa nas verificações de fatos, mas escreve respostas bem mais longas e às vezes oferece previsões de entrega que o sistema de pedidos não sustenta. A equipe reforça as instruções, adiciona uma verificação no campo de previsão e roda o conjunto de novo. Antes da troca, o atendimento é avisado de que os rascunhos podem soar um pouco diferentes e de que qualquer resposta com promessa sem respaldo deve ser marcada para revisão. Como os casos de escalada faziam parte do conjunto, a equipe entra em operação confiante de que as regras de transferência continuam valendo. Para situações assim, vale ler junto Escalonamento humano em IA: entregue a decisão necessária.

Como a Be Human lida com descontinuações de modelo?

Em um serviço gerenciado, a Be Human mantém o registro de qual modelo cada agente usa como parte das suas notas de operação e acompanha os avisos dos fornecedores, de modo que uma descontinuação seja percebida assim que chega. Quando surge uma, a equipe roda o conjunto de testes já existente do agente contra os candidatos a substituto, ajusta instruções e ferramentas quando isso ajuda e apresenta os resultados com uma recomendação para aprovação do cliente. A mudança é feita de forma controlada, com caminho de volta, os limites de aprovação e as permissões do cliente permanecem como definidos, e as notas de operação são atualizadas depois. O papel do cliente é decidir sobre a recomendação e avisar as pessoas que usam o agente.

Perguntas frequentes

Com que antecedência devemos começar a nos preparar para a descontinuação de um modelo? Comece no dia em que o aviso chegar e trate a data de descontinuação como o último dia possível, não como a data de planejamento. O inventário e o conjunto de testes levam mais tempo, e as rodadas de ajuste também precisam de prazo. Se você já mantém um conjunto de testes e um inventário de modelos, a preparação é bem mais curta.

Precisamos testar de novo se o fornecedor diz que o sucessor é uma troca direta? Sim. Um fornecedor pode descrever com razão o sucessor como compatível no nível da interface, mas o seu agente depende de comportamento, como tom, seguimento de instruções e escolhas de ferramentas. Uma rodada curta do seu próprio conjunto de testes é a única forma de saber se o seu fluxo é afetado.

E se usamos um alias que sempre aponta para o modelo mais recente? Um alias tira a pressão do prazo, mas também tira a chance de revisar cada mudança, então a qualidade pode variar sem aviso. Para qualquer coisa que afete clientes ou sistemas, fixe uma versão específica, teste as novas versões de forma deliberada e mova a fixação você mesmo. Em usos internos de baixo risco, um alias pode ser aceitável se você monitorar as saídas.

Podemos continuar usando o modelo antigo depois da data de descontinuação? Planeje como se não fosse possível. Os fornecedores definem seus próprios termos, e requisições a modelos descontinuados normalmente falham. Se o fornecedor oferecer uma extensão, trate-a como margem extra para testes, não como motivo para adiar o trabalho.

Orientação editorial Be Human. Exemplos são ilustrativos, salvo atribuição explícita. Fontes oferecem contexto; a implementação depende do seu processo.