Plano de saída para fornecedor de IA: guia prático

O contrato termina, mas a operação precisa continuar

Uma empresa pode decidir trocar o fornecedor de IA por custo, qualidade, segurança, suporte, mudança de estratégia ou encerramento do caso de uso. A decisão comercial parece simples até a equipe descobrir que instruções, logs, memória, avaliações, integrações e credenciais ficaram espalhados entre a plataforma e o parceiro.

Sem preparação, a saída vira um projeto de reconstrução. A empresa sabe qual serviço comprou, mas não consegue descrever todos os ativos necessários para manter o processo funcionando.

Um plano de saída para fornecedor de IA define como preservar a capacidade operacional durante a transição ou o desligamento. Ele cobre inventário, exportação, transferência de conhecimento, continuidade, revogação de acesso, exclusão de dados e aceite final.

O plano deve existir antes da contratação. Esperar o conflito ou a urgência reduz alternativas e aumenta o poder de quem controla os componentes críticos.

Quais situações pedem um plano de saída

O plano serve para diferentes cenários:

substituição de uma plataforma SaaS;
troca de consultoria ou equipe de desenvolvimento;
migração para outro provedor de modelos;
internalização de operação antes terceirizada;
encerramento de um agente sem substituição;
fusão, aquisição ou mudança de política corporativa;
falha grave de segurança ou continuidade;
descontinuação de recurso, modelo ou conector;
aumento de preço que altera a viabilidade;
fornecedor sem capacidade de suporte.

Cada cenário muda o prazo e a estratégia. Uma migração planejada pode usar execução paralela. Um incidente pode exigir bloqueio imediato e operação manual. Um encerramento definitivo precisa retirar gatilhos, dados e acessos sem deixar tarefas órfãs.

O plano de contingência para agentes de IA organiza a continuidade durante indisponibilidade. O plano de saída trata a separação permanente ou a transferência para outra arquitetura.

Comece pela unidade operacional que será preservada

A empresa deve declarar o que precisa continuar entregando. Pode ser um chamado triado, uma proposta preparada, um documento analisado ou um pedido validado.

Para cada unidade, registre:

evento que inicia o trabalho;
fontes consultadas;
etapas executadas;
decisões e alçadas;
sistemas alterados;
resultado considerado válido;
evidência de conclusão;
prazo tolerado;
volume normal e de pico;
caminho manual disponível.

Esse mapa evita confundir portabilidade técnica com continuidade. Exportar prompts e arquivos ajuda pouco se ninguém souber reconstruir a identificação do cliente, as regras de exceção, a confirmação no sistema oficial e o encaminhamento humano.

Faça o inventário dos ativos e dependências

A saída precisa responder onde está cada parte do serviço e quem tem autoridade sobre ela.

Dados de entrada e fontes

Liste documentos, cadastros, históricos, bases vetoriais, arquivos temporários e integrações. Registre origem, formato, volume, classificação, responsável e regra de retenção.

A empresa deve saber quais dados foram copiados para o fornecedor e quais permanecem apenas nos sistemas oficiais.

Instruções e procedimentos

Inclua prompts, instruções de sistema, políticas, exemplos, critérios de escalonamento, regras determinísticas e formatos de saída. Registre versão e finalidade.

Uma sequência de prompts sem o procedimento operacional correspondente preserva sintaxe, mas perde a razão das decisões.

Memória e estado

Identifique memória de conversas, estado de tarefas em andamento, preferências, resumos, registros de decisões e checkpoints. Defina o que precisa ser migrado, convertido em histórico ou descartado.

O guia sobre memória de agentes de IA ajuda a separar informação útil de resíduos que não deveriam sobreviver à transição.

Integrações

Mapeie APIs, webhooks, filas, automações, conectores, contas de serviço e rotinas por arquivo. Para cada integração, documente operações de leitura e escrita, autenticação, limite, ambiente e confirmação de sucesso.

Configuração técnica

Registre modelos, parâmetros, esquemas, ferramentas, ambientes, versões, dependências, domínios, certificados e infraestrutura. Quando houver código, confirme repositório, histórico, licença, documentação de implantação e processo de atualização.

Avaliações e critérios de aceite

Casos de teste, resultados esperados, erros impeditivos, amostras de regressão e métricas pertencem à capacidade de operar. Sem esse conjunto, o novo fornecedor começa do zero e a empresa perde a referência do que funcionava.

Logs e evidências

Defina quais registros precisam ser exportados para auditoria, incidentes, medição ou obrigação contratual. Evite copiar tudo sem critério. Logs podem conter dados sensíveis e elevar o risco da transição.

Conhecimento operacional

Inclua decisões arquiteturais, limitações conhecidas, incidentes, soluções temporárias, tarefas manuais, calendário de manutenção e contatos responsáveis.

Grande parte da dependência vive nesse conhecimento informal. A documentação deve permitir que outra equipe entenda o sistema sem depender de uma conversa específica com quem o construiu.

Propriedade contratual precisa virar capacidade prática

Um contrato pode dizer que os dados pertencem à empresa e ainda deixar a exportação inutilizável. A cláusula precisa indicar formato, prazo, escopo, custo e assistência necessária.

Verifique pelo menos:

propriedade de dados, instruções, código e artefatos;
direito de exportação durante e após o contrato;
formatos abertos ou documentados;
acesso a logs e avaliações;
tratamento de componentes de terceiros;
licença de código e bibliotecas;
entrega de documentação atualizada;
apoio durante transição;
prazo de disponibilidade após rescisão;
custo de saída e horas incluídas;
destino de backups e réplicas;
comprovação de exclusão;
obrigação de revogar subfornecedores;
continuidade em caso de encerramento do fornecedor.

A RFP para agentes de IA ajuda a pedir essas evidências antes de comparar propostas.

Escolha o tipo de saída

Migração para outro fornecedor

A operação passa para uma plataforma ou parceiro diferente. O trabalho inclui conversão de dados, adaptação de integrações, testes comparativos e transferência gradual.

Internalização

A empresa assume infraestrutura, suporte e evolução. Antes de decidir, deve confirmar equipe, observabilidade, segurança, plantão, documentação e orçamento de manutenção.

Substituição por automação simples

Alguns casos deixam de justificar um agente. Regras, formulários, relatórios ou automações determinísticas podem entregar o resultado com menor custo e risco.

Encerramento definitivo

O processo deixa de usar aquela capacidade. Tarefas em andamento precisam de destino, integrações devem ser removidas e usuários precisam saber qual rotina passa a valer.

Saída emergencial

Um incidente ou bloqueio contratual exige interrupção rápida. A prioridade é conter acessos e preservar evidências, seguida de continuidade manual ou alternativa já preparada.

Definir o tipo de saída evita tratar todo encerramento como migração tecnológica.

Planeje a transição por fases

1. Declare o escopo e o responsável

Nomeie um dono da saída. Registre serviços, ambientes, processos, clientes e dados incluídos. Decida também o que ficará fora e por quê.

2. Congele mudanças desnecessárias

Durante a transição, alterações sem urgência criam versões diferentes nos dois lados. Estabeleça uma janela de controle e um processo para aprovar correções indispensáveis.

3. Gere um snapshot verificável

Exporte configurações, dados autorizados, documentação, testes e registros na mesma data de referência. Use checksums, contagens ou outros controles adequados para confirmar integridade sem expor conteúdo sensível.

4. Prepare o destino

Configure identidades, ambientes, integrações, políticas, monitoramento e responsáveis. O destino precisa estar pronto antes de receber tráfego real.

5. Converta e valide ativos

Teste formato, completude, relacionamentos, histórico, permissões e capacidade de recuperação. Uma exportação que abre em uma planilha pode ainda perder identificadores, versões e vínculos entre eventos.

6. Rode casos históricos

Use o conjunto de regressão para comparar comportamento. Inclua situações comuns, exceções, falhas de integração e ações proibidas.

7. Execute em paralelo

Quando o risco justificar, o sistema novo processa cópias das entradas sem comprometer sistemas oficiais. Compare resultado, tempo, custo, escalonamento e uso de fontes.

O artigo sobre modo sombra para agentes de IA mostra como organizar essa comparação sem permitir ações externas concorrentes.

8. Migre uma parcela controlada

Direcione classes de caso, unidades ou usuários de menor risco para o destino. Preserve o caminho de retorno durante a janela definida.

9. Conclua tarefas em aberto

Toda execução iniciada precisa terminar em um único sistema ou receber transferência explícita de estado. Duplicar processamento pode gerar mensagens repetidas, registros conflitantes e compromissos indevidos.

10. Faça o corte

Interrompa novos eventos no serviço anterior, confirme filas vazias ou transferidas, atualize rotas e acompanhe indicadores com maior frequência.

11. Revogue acessos e gatilhos

Remova contas, chaves, tokens, webhooks, agendas, filas, permissões administrativas e acessos de suporte. Faça a revogação em cada sistema oficial, não apenas no painel do fornecedor.

12. Confirme exclusão e encerramento

Depois do prazo contratual, obtenha evidência sobre dados ativos, backups, logs, subfornecedores e cópias usadas para suporte. Registre exceções legais ou técnicas que impeçam exclusão imediata.

Critérios de aceite da saída

A saída termina quando a capacidade foi preservada ou encerrada com evidência. O fim do contrato, sozinho, não prova isso.

Monte um termo de aceite com critérios como:

ativos previstos foram entregues;
formatos foram abertos e validados;
contagens e relações principais conferem;
documentação corresponde à versão final;
casos de regressão atingiram o limite aprovado;
tarefas em andamento possuem destino;
integrações antigas deixaram de receber eventos;
credenciais e acessos foram revogados;
usuários receberam orientação sobre a nova rotina;
suporte de transição foi concluído;
exclusão de dados recebeu evidência;
custos e faturas finais foram reconciliados;
riscos residuais possuem dono e prazo.

Itens pendentes precisam aparecer como exceções formais. Uma promessa por e-mail sem responsável e data deixa o encerramento aberto.

Como tratar dados durante a saída

Portabilidade aumenta a movimentação de dados justamente quando equipes e fornecedores estão mudando. Defina um procedimento específico.

Minimize a exportação

Transfira somente o necessário para continuidade, obrigação ou auditoria. Históricos sem utilidade conhecida ampliam custo e exposição.

Preserve classificação e acesso

A exportação mantém a mesma classificação do sistema de origem. Limite quem pode baixar, transportar, converter e validar.

Use local temporário controlado

Evite anexos de e-mail e pastas pessoais. O local de transição deve ter criptografia, acesso restrito, registro e prazo de eliminação.

Registre cadeia de custódia

Documente quem gerou, recebeu, validou, transformou e excluiu cada pacote relevante.

Verifique backups e subfornecedores

Excluir a conta principal pode não remover cópias em backup, observabilidade, suporte ou processadores secundários. O contrato e a confirmação final devem cobrir essas camadas.

A política de retenção de dados para agentes de IA oferece critérios para prazos, bases, registros e descarte.

Revogação de acesso precisa ser completa

Uma saída pode deixar caminhos ativos por meses. Monte uma matriz com:

pessoa ou serviço;
sistema;
tipo de acesso;
ambiente;
credencial associada;
responsável pela revogação;
data prevista;
evidência de conclusão.

Revise contas de serviço, chaves de API, usuários administrativos, acesso ao repositório, VPN, nuvem, banco, observabilidade, domínio, automação, CRM, e-mail e arquivos.

Também procure identidades compartilhadas. Se o fornecedor usava uma conta genérica, trocar a senha pode afetar outras rotinas e ainda impedir atribuir ações históricas. O guia sobre identidade e credenciais de agentes de IA mostra como evitar esse desenho desde a implantação.

Continuidade durante a troca

Defina como o processo funcionará se o destino atrasar ou falhar:

operação manual temporária;
automação determinística de escopo reduzido;
fila durável para processar depois;
limite de volume;
prioridade por cliente ou impacto;
bloqueio de ações sensíveis;
comunicação para usuários;
critério para voltar ao fornecedor anterior;
prazo máximo de convivência entre sistemas.

A capacidade manual precisa ser real. Um runbook sem equipe disponível e sem acesso aos sistemas oferece conforto documental, não continuidade.

Métricas da transição

Acompanhe a saída como um projeto operacional:

percentual de ativos inventariados;
percentual exportado e validado;
casos de regressão aprovados;
divergências abertas por severidade;
tarefas em andamento sem destino;
volume processado no sistema novo;
retrabalho durante a transição;
incidentes e duplicidades;
acessos revogados;
dados com exclusão confirmada;
custo de transição;
atraso em relação ao corte;
disponibilidade do processo.

Essas métricas ajudam a decidir se o corte pode avançar, se precisa de correção ou se deve ser adiado.

Sinais de dependência perigosa

Alguns sinais merecem atenção antes mesmo de existir intenção de saída:

a empresa não possui cópia das instruções e procedimentos;
somente o fornecedor consegue executar os testes;
logs ficam presos em painel sem exportação;
memória e histórico usam formato fechado sem documentação;
integrações dependem de contas pessoais;
código relevante não está em repositório acessível;
ninguém conhece as tarefas manuais ao redor do sistema;
a empresa não consegue pausar o agente sem abrir chamado;
o contrato omite exclusão, subfornecedores ou apoio de transição;
o processo pararia imediatamente com a indisponibilidade do parceiro.

Dependência pode ser uma escolha econômica válida. Ela precisa ter preço, limite e alternativa conhecidos.

Checklist antes de assinar ou renovar

A unidade operacional está documentada?
Dados, instruções, memória, testes e logs têm propriedade definida?
Formatos e prazos de exportação estão no contrato?
O custo de transição aparece na proposta?
Componentes de terceiros foram identificados?
A empresa tem acesso ao repositório e à documentação necessária?
Existe suporte previsto para migração?
Backups e subfornecedores entram na exclusão?
O procedimento de revogação está mapeado?
Há contingência para interrupção abrupta?
Critérios de aceite da saída foram definidos?
Um responsável interno responde pela continuidade?

A empresa precisa conseguir sair antes de entrar

Um fornecedor pode oferecer excelente tecnologia e suporte. O plano de saída protege a relação porque torna responsabilidades, ativos e limites visíveis desde o começo.

Quando dados, procedimentos, avaliações e evidências permanecem acessíveis, a empresa consegue trocar componentes sem perder a capacidade que construiu. Também consegue encerrar um agente de forma limpa quando o resultado deixa de justificar custo ou risco.

A saída bem desenhada preserva continuidade durante a mudança e remove dependências depois dela. Esse trabalho pertence à arquitetura do serviço desde a contratação, não ao improviso do último mês de contrato.