Como migrar agentes de IA para outro fornecedor, passo a passo

Para migrar agentes de IA para outro fornecedor sem interromper o trabalho do dia a dia, faça o inventário de tudo de que o agente depende, exporte o que pertence à empresa, rode a configuração antiga e a nova lado a lado em tarefas reais e só faça a virada quando as verificações combinadas antes forem cumpridas. Mantenha a configuração antiga disponível para voltar atrás até que a nova tenha passado por um ciclo normal de operação. Trate a troca como um projeto de operações com uma parte técnica, e não o contrário.

Principais pontos

• Um agente é mais do que um modelo. Identidade, instruções, memória, ferramentas, permissões e canais precisam ser migrados, e cada um se move de um jeito.
• Comece pelo inventário. A maioria das surpresas vem de dependências que ninguém registrou, como um recurso de memória hospedado ou uma tarefa agendada.
• Teste a nova configuração com um conjunto de tarefas reais da sua empresa, com critérios de aprovação definidos antes de qualquer pessoa ver os resultados.
• Durante a execução em paralelo, apenas um agente pode escrever em cada sistema por vez. Caso contrário, clientes e colegas recebem mensagens duplicadas.
• Faça a virada com um caminho de retorno definido e revogue as credenciais antigas só depois que a nova configuração provar que funciona.

O que realmente muda quando você troca de fornecedor de IA?

A palavra fornecedor cobre mudanças bem diferentes, e o trabalho depende de qual delas você está fazendo. Você pode estar trocando o modelo de linguagem por trás do agente, a plataforma que hospeda e orquestra o agente, o integrador que conecta o agente às suas ferramentas, ou os três ao mesmo tempo. Trocar o modelo preserva em boa parte seus canais e permissões, mas altera o comportamento do agente, mesmo com instruções idênticas. Trocar a plataforma deixa o comportamento do modelo mais próximo do que você conhece, mas pode quebrar a memória, os agendamentos e cada conexão ao redor.

Antes de planejar qualquer coisa, escreva uma frase dizendo o que está mudando e por quê. Por exemplo: vamos mover o agente de uma plataforma hospedada para outra e manter a mesma família de modelos. Essa frase define o escopo dos testes e mostra quais partes do agente devem continuar se comportando como antes.

Também ajuda separar o que é da sua empresa do que é do fornecedor. Instruções que você escreveu, documentos que você forneceu e contas abertas em nome da empresa devem ser suas para levar. Formatos proprietários de memória, definições de fluxo específicas da plataforma e ajustes feitos dentro do fornecedor muitas vezes não são. O artigo sobre o que manter, exportar e documentar ao sair de um fornecedor de IA trata dessa divisão com mais profundidade, e vale a leitura antes de você avisar qualquer pessoa.

Passo 1: faça o inventário do agente como um cargo, não como um prompt

O prompt é só um arquivo dentro de um arranjo maior. Faça o inventário do agente como você documentaria a função de um colega que vai mudar de equipe. Percorra cada item abaixo e registre a situação atual:

• Definição do papel: pelo que o agente é responsável, o que ele nunca deve fazer e a quem ele se reporta.
• Instruções: prompts de sistema, guias de tom, regras de escalonamento e exemplos, com uma nota sobre quais foram ajustados em torno de manias do modelo atual.
• Memória e conhecimento: documentos, anotações, histórico de conversas e índices de recuperação, e onde cada um está de fato armazenado.
• Ferramentas e integrações: cada sistema que o agente lê ou escreve, o escopo de acesso, qual credencial ele usa e quem é o dono dessa credencial.
• Canais: endereços de e-mail, espaços de chat, caixas compartilhadas e qualquer outro lugar onde as pessoas falam com o agente.
• Permissões e aprovações: quais ações rodam sozinhas, quais esperam uma pessoa e quem aprova.
• Registros e avaliações: casos de teste existentes, incidentes passados, notas de revisão e tudo o que mostra como é um bom resultado.
• Recursos exclusivos do fornecedor: agendadores embutidos, memória hospedada, formatos proprietários de ferramentas, qualquer coisa que não vai existir em outro lugar.
• Pessoas: quem usa o agente todos os dias, quem é o responsável por ele e quem vai perceber primeiro se ele se comportar mal.

Depois, marque cada linha com um de três rótulos: portável (muda como está), convertível (muda depois de reformatar ou reescrever) ou específico do fornecedor (precisa ser reconstruído). A lista de itens específicos do fornecedor é o seu risco real de migração. Em geral ela é menor do que as pessoas temem, mas quase nunca está vazia.

Passo 2: exporte o que pertence à sua empresa

Comece as exportações cedo, porque alguns fornecedores demoram para atender e alguns formatos precisam de limpeza antes de serem úteis. Peça as exportações em formatos legíveis e documentados e confirme que você consegue abrir e usar o que recebeu. Uma exportação que ninguém tentou restaurar é uma esperança, não um backup.

Cada tipo de material pede um tratamento diferente:

• Instruções e documentos de papel: guarde em seu próprio repositório ou sistema de documentos, com histórico de versões, e não apenas no painel do fornecedor.
• Fontes de conhecimento: mantenha os documentos originais como fonte de verdade. Os índices de recuperação normalmente são reconstruídos no destino, e não copiados.
• Memória: decida o que merece ser levado. Faça uma curadoria. Fatos desatualizados, preferências antigas e detalhes sensíveis que não têm mais finalidade é melhor deixar para trás.
• Histórico de conversas: leve o que sustenta o trabalho em andamento, como casos abertos, e arquive o restante conforme suas regras de retenção.
• Credenciais: não reutilize chaves que pertencem às contas do fornecedor antigo. Crie novas em contas da empresa e aproveite a troca para restringir o escopo.

É na questão da propriedade que as migrações costumam travar, então verifique agora, e não na hora da virada. Se você não tem certeza do que o contrato permite levar, o guia sobre quem é dono dos prompts, da memória e dos dados da IA apresenta as perguntas certas.

Uma observação estrutural sobre ferramentas: padrões como o Model Context Protocol existem para descrever, de forma consistente, como um agente se conecta a sistemas externos. Quando suas ferramentas já seguem uma interface compartilhada, reconectá-las a uma nova plataforma dá muito menos trabalho do que reescrever cada integração.

Passo 3: reconstrua e teste com trabalho real

Espere ter de ajustar as instruções. Um prompt afinado durante meses para os hábitos de um modelo não será transferido perfeitamente, porque os modelos diferem em quão literalmente seguem regras, quantos detalhes oferecem por conta própria e como lidam com ambiguidade. Parta da definição do papel, em vez de copiar os prompts antigos palavra por palavra, e depois reintroduza as regras específicas que mostraram seu valor.

Revise ferramentas e permissões ao mesmo tempo:

• Reescreva as descrições das ferramentas se a nova plataforma as interpreta de outro modo e teste se o agente escolhe a ferramenta certa para cada tarefa.
• Dê ao agente uma identidade própria em cada sistema conectado, com o acesso mais restrito que ainda permita fazer o trabalho. As orientações da OWASP sobre autorização são uma boa referência para o princípio do menor privilégio.
• Confirme que as etapas de aprovação continuam disparando. Uma ação que exigia uma pessoa ontem não pode rodar sem supervisão hoje porque uma configuração não foi transferida.

Em seguida, monte um conjunto de testes com o seu próprio trabalho. Separe uma amostra representativa de tarefas passadas, incluindo as comuns, os casos de borda incômodos, os pedidos que o agente deve recusar e os que ele deve escalar. Para cada uma, registre como é um resultado aceitável em termos do trabalho, e não da redação. O texto da Anthropic sobre avaliação de agentes de IA é um bom guia para estruturar isso. Combine os critérios de aprovação antes de rodar qualquer coisa, para que ninguém ajuste a régua depois de ver os resultados.

Passo 4: como conduzir a execução em paralelo?

Execução em paralelo significa que o agente antigo e o novo recebem as mesmas entradas reais por um período, enquanto pessoas comparam os resultados. Faça por etapas e só avance quando a etapa anterior estiver limpa:

• Etapa de sombra: o novo agente recebe cópias de pedidos reais e produz respostas, mas nada sai da empresa. Revisores comparam o trabalho dele com o do agente antigo.
• Etapa supervisionada: o novo agente redige e uma pessoa aprova cada ação externa. O agente antigo continua sendo o que realmente age.
• Etapa de operação limitada: o novo agente age em uma fatia pequena e de baixo risco do trabalho, e o antigo segue disponível para o restante.

Uma regra pesa mais do que as outras: em qualquer momento, apenas um agente deve ter acesso de escrita a determinado sistema ou canal. Se os dois puderem enviar e-mails ou atualizar registros, você terá mensagens duplicadas e alterações conflitantes, e limpar isso é mais lento do que a própria migração.

Registre os dois agentes com os mesmos campos para facilitar a comparação: a entrada, as ferramentas chamadas, a saída, o tempo gasto e se uma pessoa alterou algo. O guia introdutório de observabilidade do OpenTelemetry explica como rastros e registros se encaixam, caso você queira um vocabulário comum para isso.

Um cenário ilustrativo: uma equipe de operações tem um agente que faz a triagem de e-mails de fornecedores, redige respostas e atualiza uma planilha compartilhada. Na etapa de sombra, o novo agente acompanha o antigo nas dúvidas rotineiras sobre pedidos, mas trata de forma generosa demais os pedidos de crédito por atraso na entrega, oferecendo soluções que deveria escalar. A equipe adiciona uma regra explícita de escalonamento, reexecuta os casos de crédito do conjunto de testes e só então passa para a etapa supervisionada. Nada chegou a um fornecedor enquanto o problema era encontrado.

Classifique as diferenças encontradas em três grupos: regressões que bloqueiam a virada, diferenças aceitáveis ou até melhores, e lacunas que podem ser corrigidas depois da virada. Escrever os grupos mantém a decisão sobre a virada baseada em evidências, e não em impressão.

Passo 5: faça a virada com um caminho de retorno

A virada é o momento em que o acesso de escrita e os canais passam para a nova configuração. Bem feita, ela é sem graça. Um roteiro que funciona para a maioria das equipes:

• Primeiro: escolha uma janela tranquila e avise as pessoas que usam o agente o que vai mudar, o que não vai e a quem recorrer. A orientação sobre como engajar a equipe no uso de agentes de IA vale aqui tanto quanto no lançamento.
• Segundo: congele mudanças em instruções e ferramentas nos dois lados até o fim da virada.
• Terceiro: confirme que os critérios de aprovação do conjunto de testes e da última etapa em paralelo foram atendidos e registre quem deu a aprovação.
• Quarto: mova o acesso de escrita e o roteamento dos canais para o novo agente e retire-os do antigo na mesma sessão.
• Quinto: acompanhe os primeiros dias de perto, com uma pessoa nomeada revisando as saídas e uma forma simples de os colegas sinalizarem problemas.
• Sexto: mantenha a configuração antiga intacta, porém inativa, com um gatilho escrito para reverter, até que a nova tenha passado por um ciclo normal de trabalho, incluindo os momentos de pico e os mais complicados.

Só depois disso desative o antigo. Revogue as credenciais antigas, apague ou arquive os dados exportados conforme suas regras de retenção, peça ao fornecedor anterior que confirme a exclusão por escrito e encerre as contas. Depois, atualize o inventário para que ele descreva a nova realidade. Os princípios de como atualizar um agente de IA em produção sem quebrar nada cobrem a mesma disciplina de mudança em etapas e retorno seguro, que a troca de fornecedor apenas aplica em escala maior.

Como a Be Human conduz migrações de fornecedor

A Be Human opera agentes em uma infraestrutura em que identidade, memória, canais, ferramentas e permissões são documentados e ficam sob o controle da empresa. Assim, a troca de fornecedor parte de um inventário existente, e não de uma página em branco. Em uma migração, classificamos cada componente como portável, convertível ou específico do fornecedor, reconstruímos o papel no novo ambiente, testamos com um conjunto de tarefas da própria empresa e rodamos o antigo e o novo em paralelo, com apenas um deles com acesso de escrita. A virada acontece com um gatilho de retorno combinado e com os limites de aprovação inalterados, e as credenciais antigas são encerradas depois, como parte da operação gerenciada.

Perguntas frequentes

Quanto tempo leva a migração de fornecedor? Depende de quantas ferramentas o agente usa, de quanto da memória é portável e de quanto tempo a execução em paralelo precisa para cobrir um ciclo normal de trabalho. Um agente enxuto, com poucas integrações, pode ser movido rápido, enquanto um com muitos sistemas conectados exige mais testes. Planeje com base nas evidências da execução em paralelo, e não em uma data fixa.

O agente vai se comportar exatamente igual depois da mudança? Não necessariamente, principalmente se o modelo mudar. Os modelos interpretam instruções de maneiras diferentes, então espere ajustar a redação, as regras de escalonamento e as descrições das ferramentas. Por isso um conjunto de testes feito com as suas tarefas reais vale mais do que qualquer promessa de equivalência.

Devemos migrar tudo de uma vez ou um agente por vez? Um agente ou um papel por vez costuma ser mais seguro. A primeira migração mostra quais partes do inventário estavam incompletas, e esse aprendizado deixa cada mudança seguinte mais barata. Comece por um papel em que os erros sejam fáceis de perceber e de reverter.

E se o fornecedor antigo não liberar nossos dados? Confira o contrato e as cláusulas de propriedade antes de começar, porque é muito mais fácil tratar isso cedo. Mantenha os documentos originais e as instruções em sistemas seus, para que o material mais importante nunca dependa de uma exportação. Se algo estiver de fato preso, trate como específico do fornecedor, planeje reconstruir e use a lição para definir os termos do próximo fornecedor.

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