Plano de saída de fornecedor de IA: o que manter e documentar

Um plano de saída de fornecedor de IA é um conjunto mantido de exportações, documentos e procedimentos testados que permite levar seus agentes para outro fornecedor sem perder o que os torna seus: instruções, conhecimento, memória, integrações, permissões e a prova de como eles se comportam. Monte esse plano enquanto a relação está saudável, porque o material é mais fácil de reunir quando ninguém está com pressa. O objetivo não é sair. É tornar a saída possível, o que também mantém todo fornecedor honesto.

Principais pontos

• O modelo é a parte mais substituível de uma estrutura de IA. Seu investimento de verdade está nas instruções, no conhecimento, na memória, nas definições de ferramentas e nos testes.
• Contas, credenciais e repositórios de dados devem estar registrados em nome da sua empresa, e não do fornecedor, para que o acesso não dependa de boa vontade.
• Uma exportação só vale depois de ter sido restaurada em outro lugar. Ensaie a saída em pequena escala antes de precisar dela.
• Documentar as decisões (por que o agente se comporta de certo modo e o que ele nunca pode fazer) vale tanto quanto os arquivos em si.
• Revise o plano em intervalos regulares, porque um plano que estava correto na assinatura se desatualiza conforme a estrutura muda.

O que um plano de saída de fornecedor de IA realmente cobre?

A maioria das pessoas imagina a saída como copiar arquivos. Na prática, uma estrutura de IA tem várias camadas, e cada uma pode ser portátil ou ficar presa. Uma forma útil de enxergar: o modelo gera linguagem, o harness ao redor dele decide o que o modelo vê, quais ferramentas pode chamar e quando deve parar, e a sua empresa fornece o conhecimento, as regras e as contas. Se quiser o vocabulário, Modelo, agente e harness de IA: qual é a diferença? explica essa divisão.

O plano de saída precisa tratar das camadas que você perderia ou teria de reconstruir se o fornecedor desaparecesse amanhã:

• Comportamento: as instruções, as definições de tarefas, as regras de tom e as regras de escalonamento que moldam o que o agente faz.
• Conhecimento: os documentos, os registros estruturados e os índices que o agente consulta.
• Memória: o que o agente aprendeu ao longo do tempo sobre seus clientes, projetos e preferências.
• Ferramentas e integrações: as conexões com e-mail, agenda, CRM, mensagens e sistemas internos, além das permissões de cada uma.
• Identidade e canais: as contas, os números e os endereços que o agente usa para agir.
• Evidências: logs, conjuntos de testes e registros de decisões aprovadas.

A dependência de fornecedor raramente chega em uma cláusula dramática. Ela se forma por pequenas comodidades, e por isso vale ler Como evitar dependência de fornecedor de IA em agentes junto com este plano. Este artigo foca no inventário prático e na transição.

Quais ativos você deve conseguir exportar?

Comece por um inventário simples. Para cada ativo, registre onde ele está, quem tem acesso, em que formato pode ser exportado e se você já fez essa exportação de fato. A lista abaixo é um mínimo razoável para um agente de negócio.

• Instruções do agente: o texto completo das instruções de sistema, das descrições de papel e das regras de estilo, com histórico de versões, se existir.
• Contratos de tarefa: para cada fluxo, o que o agente recebe, o que deve devolver e o que conta como concluído.
• Fontes de conhecimento: os documentos originais, e não apenas a cópia processada pelo fornecedor, mais metadados como responsável, data e status de aprovação.
• Configuração do índice: como os documentos são divididos, rotulados e recuperados, para que o mesmo comportamento possa ser reproduzido em outro lugar.
• Registros de memória: os fatos e as anotações que o agente guarda, em formato legível, com origem e data de cada entrada.
• Definições de ferramentas: nomes, entradas, saídas, comportamento em caso de erro e nível de permissão de cada ferramenta (ler, preparar ou enviar).
• Configurações de integração: quais sistemas estão conectados, por qual método e quais escopos foram concedidos.
• Ativos de canais: números de telefone, contas comerciais de mensagens, caixas de e-mail e domínios que o agente usa.
• Conjuntos de testes e resultados: os exemplos que você usa para julgar a qualidade e os resultados mais recentes.
• Logs e registros de aprovação: o que o agente fez, o que uma pessoa aprovou e o que foi recusado.

A questão de quem detém os direitos jurídicos sobre esses itens merece uma leitura própria. Quem é dono dos prompts e dados na IA da empresa? Guia prático trata do assunto em detalhe. Para o plano de saída, a regra de trabalho é simples: se você não consegue exportar em um formato que uma pessoa consiga ler, trate como algo que ainda não é seu.

Contas e credenciais vêm primeiro

A falha de saída mais comum não é a falta de dados. É a falta de acesso. Se o fornecedor registrou o número de mensagens, é dono do aplicativo OAuth ou guarda o único login de administrador, você negocia em posição fraca. O acesso delegado aos seus sistemas deve usar fluxos de autorização padrão, como o OAuth 2.0, em que sua organização consegue ver e revogar cada concessão. Mantenha em nome da sua empresa:

• Domínio, caixa de e-mail e contas de mensagens usadas pelo agente.
• Acesso de administrador a cada sistema conectado, com pelo menos duas pessoas nomeadas do seu lado.
• Armazenamento em nuvem ou bancos de dados onde ficam documentos e memória.
• A relação de cobrança com qualquer serviço de modelo ou de infraestrutura por baixo, quando for viável.

Que documentação torna uma estrutura portátil?

Arquivos sem contexto são apenas uma pilha. Um novo fornecedor, ou um novo time interno, precisa entender por que a estrutura é do jeito que é. Peça ou escreva os documentos a seguir e guarde-os junto com seus registros.

• Resumo da arquitetura: uma ou duas páginas descrevendo as camadas, os fluxos de dados e quais sistemas o agente pode tocar.
• Mapa de permissões: cada ferramenta, seu nível de acesso, quem aprovou e o que ela nunca deve fazer sem uma pessoa.
• Guia de escalonamento: quando o agente para e pergunta, a quem, e com quais informações anexadas.
• Histórico de mudanças: o que foi alterado, quando, por quem e por quê. Sem isso, uma equipe substituta repete erros antigos.
• Notas de falhas conhecidas: as situações em que o agente teve dificuldade e as regras criadas em resposta.
• Lista de dependências: serviços de terceiros, versões de modelo, agendamentos, webhooks e quaisquer scripts dos quais a estrutura depende.
• Calendário operacional: tarefas recorrentes, datas de revisão e datas de renovação de credenciais e certificados.

Se o seu agente se conecta às ferramentas por um protocolo compartilhado, como o Model Context Protocol (MCP), as próprias descrições das ferramentas passam a fazer parte dessa documentação, e elas circulam entre fornecedores com mais facilidade do que conectores personalizados e específicos de um fornecedor. Prefira interfaces abertas ou bem documentadas quando houver escolha.

Para o trabalho em andamento, uma nota de passagem estruturada também importa. Checkpoints de agentes de IA: como retomar o trabalho mostra o que registrar para que tarefas inacabadas não se percam numa troca.

Como ensaiar a saída antes de precisar dela?

Uma exportação que você nunca restaurou é uma esperança, não um ativo. O ensaio não exige abandonar seu fornecedor. Exige provar que outra pessoa conseguiria juntar as peças. Percorra estes passos com um fluxo pequeno e de baixo risco.

• Passo um: escolha um fluxo com finalidade clara e permissões limitadas, para que um ensaio que dê errado não prejudique clientes.
• Passo dois: peça uma exportação completa das instruções, do conhecimento, da memória e das definições de ferramentas, e anote quanto tempo leva e o que está faltando.
• Passo três: abra cada arquivo como alguém de fora do fornecedor faria. Verifique se os formatos são legíveis e se os registros trazem origem e data.
• Passo quatro: reconstrua uma versão mínima em um ambiente separado, mesmo que simples, usando apenas a exportação e a documentação.
• Passo cinco: rode seu conjunto de testes na versão reconstruída e compare os resultados com a estrutura atual. Diferenças de redação são aceitáveis. Diferenças de decisão são achados.
• Passo seis: liste cada lacuna, defina um responsável e um prazo, e peça ao fornecedor que feche as que estão do lado dele.
• Passo sete: registre a data, os achados e a data do próximo ensaio nas suas notas de governança.

O conjunto de testes é a peça que dá sentido ao ensaio. Se você ainda não tem um, Monte um conjunto de testes de referência para sua IA é o lugar para começar. Ferramentas de avaliação oferecidas por fornecedores de modelos podem ajudar a estruturar as verificações, mas uma planilha com casos realistas e resultados esperados já basta para começar.

Como isso fica na prática? Um cenário ilustrativo

Este é um cenário ilustrativo, não a descrição de uma empresa real.

Uma pequena distribuidora usa um agente de IA para preparar rascunhos de acompanhamento de clientes e atualizar uma lista de tarefas compartilhada. O fornecedor hospeda as instruções e a memória das preferências dos clientes. A empresa decide ensaiar uma saída e pede a exportação completa do fluxo de acompanhamento.

A exportação chega com as instruções e as definições de ferramentas, mas as anotações de memória vêm em um único arquivo sem rótulos e sem datas. A empresa não consegue saber quais preferências estão atuais. A conta de mensagens usada no contato com clientes está registrada sob o administrador do fornecedor. O conjunto de testes existe apenas como alguns exemplos numa conversa de chat.

Nada disso causa dano, porque era um ensaio. Agora a empresa tem uma lista curta e concreta: exportações de memória com data e origem, transferência da conta de mensagens para um administrador da empresa e um conjunto de testes de verdade guardado no drive próprio. Algumas semanas depois, um segundo ensaio mostra que o fluxo reconstruído produz as mesmas decisões em todos os casos de teste. A empresa não trocou de fornecedor, mas pode trocar, e as conversas com o fornecedor atual ficaram visivelmente mais tranquilas.

Como a Be Human trata a prontidão para a saída?

A Be Human desenha a estrutura para que a portabilidade faça parte da construção, e não seja um pedido de última hora. Contas, canais e repositórios de dados são configurados sob o controle do cliente, instruções e definições de ferramentas são mantidas em forma legível, e as permissões são documentadas por ferramenta, com os limites de aprovação declarados. A operação gerenciada inclui avaliações e revisões de permissões recorrentes, que mantêm o inventário e o conjunto de testes atualizados conforme a estrutura muda. O cliente pode pedir uma exportação e um pacote de transição a qualquer momento, redigido em português ou inglês.

Quando acionar o plano de fato?

Ter um plano não significa usá-lo na primeira irritação. Use este guia de decisão para separar um problema a corrigir de um motivo para mudar.

• O fornecedor descumpre repetidamente os compromissos combinados de suporte ou confiabilidade e não responde a um pedido formal de correção: prepare-se para mudar e comece por uma exportação de ensaio.
• A qualidade caiu, mas seu conjunto de testes mostra que a causa está nos seus próprios documentos ou instruções: corrija a estrutura primeiro, já que um novo fornecedor herdaria o mesmo problema.
• O fornecedor altera termos, tratamento de dados ou subprocessadores de um jeito que sua avaliação de segurança não aceita: inicie os passos de saída e envolva quem responde pela governança.
• Uma integração ou um canal necessário não é suportado e dificilmente será: compare opções antes de sair, pois uma mudança menor pode resolver.
• O fornecedor está sendo adquirido, reestruturado ou encerrando atividades: faça uma exportação completa imediatamente e só depois decida.
• Suas próprias necessidades superaram o arranjo, por exemplo ao caminhar para um time interno: use o plano como a transição e leia Time interno de IA ou parceiro externo: quem deve operar sua IA? para ver as vantagens e desvantagens.

Em todos os casos, mude um fluxo de cada vez, mantenha a estrutura antiga e a nova funcionando lado a lado por um curto período e deixe que pessoas aprovem as ações até que o conjunto de testes passe no lado novo.

Perguntas frequentes

Com que frequência devemos atualizar o plano de saída? Revise-o em um ritmo fixo e depois de qualquer mudança relevante, como uma nova integração, um novo canal ou a troca de modelo. O inventário se desatualiza em silêncio, então ligue a revisão às suas revisões regulares de permissões e avaliações, em vez de tratá-la como um projeto único.

Precisamos exportar tudo, inclusive logs antigos? Não necessariamente tudo, mas você deve decidir de forma deliberada o que manter. Registros de aprovação, notas de incidentes e logs que mostram como as decisões foram tomadas costumam valer a pena para fins de prestação de contas, enquanto o ruído técnico bruto pode ser resumido. Confirme eventuais obrigações de retenção com quem cuida da área jurídica e da proteção de dados na sua empresa.

É possível preparar a saída se o fornecedor não cooperar? Em parte. Você pode manter desde o início cópias próprias dos documentos de origem, das instruções que escreveu, dos conjuntos de testes e dos registros de contas, e pode documentar as permissões por conta própria. O que não dá para recuperar sem cooperação é a memória e a configuração que ficam do lado do fornecedor, e por isso importa pedir por escrito, antes de assinar, os direitos e os formatos de exportação.

Plano de saída é só para empresas grandes? Não. Empresas menores muitas vezes têm mais a perder, porque em geral uma única pessoa configurou o agente e o conhecimento está na cabeça dela. Um inventário curto, administradores nomeados e uma exportação ensaiada dão a uma empresa pequena a maior parte da proteção com um esforço modesto.

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