Portabilidade de agentes de IA: plano SAÍDA

A demonstração funciona: o agente consulta o CRM, lê documentos, prepara uma proposta e avisa o vendedor. Seis meses depois, a empresa descobre que as regras estão escondidas em uma interface do fornecedor, os registros de execução não podem ser exportados, as credenciais pertencem a uma conta compartilhada e trocar o modelo exige reconstruir todas as integrações.

O problema não é ter fornecedor. É não saber o que fica com a empresa se preço, qualidade, estratégia, suporte ou tecnologia mudarem. Em IA, a dependência raramente está apenas no modelo. Ela se acumula em conectores, prompts, regras, memória, avaliações, permissões, logs e no conhecimento informal de quem mantém o fluxo vivo.

Este artigo entrega o plano SAÍDA: cinco blocos para avaliar portabilidade antes da contratação, uma matriz de dependência, um teste de troca controlado e perguntas que transformam “integra com tudo” em evidência operacional.

Por que interoperabilidade virou assunto de gestão

Em fevereiro de 2026, o NIST lançou uma iniciativa específica para padrões de agentes de IA. O órgão apontou que, sem confiança em confiabilidade e interoperabilidade entre agentes e recursos digitais, o mercado pode se fragmentar e limitar a adoção. Não é apenas uma discussão de arquitetura: fragmentação aumenta custo de integração, dificulta mudança e concentra decisões operacionais em poucas plataformas.

Dois padrões aparecem com frequência nessa conversa. O MCP organiza como aplicações de IA acessam ferramentas, recursos e prompts. O A2A organiza como agentes descobrem, comunicam e delegam tarefas entre si. Em abril de 2026, a Linux Foundation informou apoio de mais de 150 organizações ao A2A, além de integrações em grandes plataformas de nuvem.

Esse avanço é relevante, mas precisa ser interpretado com precisão. Um protocolo comum pode diminuir trabalho ponto a ponto. Ele não transfere automaticamente sua regra comercial, histórico de decisões, conjunto de testes, identidade, contrato ou rotina manual. Conseguir conectar é diferente de conseguir substituir.

O que MCP e A2A resolvem — e o que fica com a empresa

MCP ajuda a padronizar a conexão: ferramentas podem expor funções e dados por uma interface conhecida. Ainda cabe à empresa decidir quais ferramentas são confiáveis, quais campos podem ser enviados, quem autoriza e como comprovar o resultado.
A2A ajuda a padronizar a conversa: agentes de plataformas diferentes podem descobrir capacidades e coordenar tarefas. Ainda cabe à empresa definir responsabilidade, estado final, alçada, exceção e reconciliação quando dois agentes discordam ou um deles falha.
Padrões reduzem uma camada de dependência: não eliminam extensões proprietárias, versões incompatíveis, serviços administrados, formatos de memória nem custos de migração.

A própria agenda de 2026 do MCP lista trilhas de auditoria, autenticação integrada, comportamento de gateways e portabilidade de configuração entre os desafios de prontidão empresarial. Em julho, a nova especificação trouxe mudanças amplas, autorização reforçada e política formal de depreciação. O sinal para o gestor não é “evite padrões novos”; é registre versão, dependências e teste de compatibilidade como parte da operação.

Matriz de dependência: impacto × substituibilidade

Antes do plano SAÍDA, classifique cada componente em duas dimensões:

impacto: se ficar indisponível ou mudar, afeta cliente, receita, dado, prazo ou obrigação relevante?
substituibilidade: existe alternativa testada que outra equipe consegue ativar com documentação e artefatos disponíveis?

O quadrante mais perigoso combina alto impacto e baixa substituibilidade. Pode ser um conector proprietário que grava pedidos, uma memória de clientes sem exportação, uma regra de aprovação escondida no prompt do fornecedor ou uma credencial que só o consultor externo controla. Esses itens precisam de cláusula, documentação, controle técnico ou alternativa antes de ampliar a automação.

Baixo impacto e baixa substituibilidade pode ser aceitável durante um experimento. Alto impacto e alta substituibilidade exige teste periódico, porque “temos backup” não prova que a troca funciona. A matriz não exige independência absoluta; ela torna a dependência uma decisão consciente.

Plano SAÍDA: cinco blocos antes de contratar

S — Sistemas e dependências catalogados

Desenhe o caminho completo: canal de entrada, orquestrador, modelo, base de conhecimento, servidor MCP ou API, sistema alterado, fila de exceção e destino do log. Para cada componente, registre fornecedor, versão, proprietário, formato, limite, custo, SLA e efeito de indisponibilidade.

Não aceite “integra com o ERP” como resposta. Pergunte se a conexão é API oficial, conector do fornecedor, automação de tela ou exportação periódica; quem mantém o mapeamento de campos; como mudanças são avisadas; e o que acontece quando só metade da transação termina.

A — Artefatos sob controle da empresa

Liste instruções, regras, exemplos, esquemas de ferramentas, fluxos, testes, critérios de aceite e configurações. Defina quais artefatos podem ser exportados em formato legível, com versão e sem depender da interface original. Captura de tela ajuda na documentação, mas não substitui um arquivo que possa ser revisado, comparado e reutilizado.

O objetivo não é exigir código aberto de todo fornecedor. É preservar o conhecimento do negócio. A empresa deve conseguir explicar como um lead é classificado, por que uma cobrança é pausada ou quando uma pendência de obra é escalada sem depender da memória de uma única pessoa.

I — Identidades e acessos separáveis

Credenciais devem pertencer à empresa, ter escopo por função e permitir revogação sem paralisar outros serviços. Separe identidade do agente, do integrador e do colaborador. Registre quem concede, revisa e retira acesso, além de quais ações cada identidade pode executar.

O NCCoE do NIST destacou em 2026 identificação, autorização, auditoria e não repúdio como questões ainda abertas para agentes. Usar um protocolo interoperável não autoriza a ação. A permissão continua sendo uma decisão do negócio, aplicada nos sistemas e verificável nos registros.

D — Dados, estado e histórico exportáveis

Defina qual é a fonte oficial e quais dados precisam voltar: conversas, classificações, tarefas, aprovações, versões, avaliações, custos, erros e confirmações dos sistemas. Especifique formato, frequência, retenção, chaves de relacionamento e prazo de entrega na saída.

A migração mais difícil não é copiar um prompt; é reconstruir o estado. Qual cliente aguarda resposta? Qual pedido foi apenas preparado e qual foi gravado? Qual exceção recebeu aprovação? Sem identificadores e confirmações, a nova solução pode duplicar ações ou abandonar itens no meio do caminho.

A — Alternativa testada e acordo de transição

Escolha o modo de continuidade: outro modelo, outro orquestrador, execução manual, exportação para fila ou operação assistida. Registre prazo, responsáveis, ordem de prioridade e capacidade máxima. No contrato, trate acesso aos artefatos, assistência de transição, eliminação ou devolução de dados, custos de exportação e responsabilidades. Questões jurídicas específicas devem ser revisadas por profissional qualificado.

Plano de saída não é desconfiança do parceiro. É condição para uma relação madura: o fornecedor sabe o que precisa entregar, e a empresa não transforma qualquer mudança comercial em incidente operacional.

Teste de troca em 90 minutos

Antes de ampliar o piloto, faça um ensaio controlado. Não é uma migração completa; é uma prova de que os elementos críticos são recuperáveis e compreensíveis.

Escolha um fluxo estreito: por exemplo, classificar dez leads e criar a próxima tarefa, sem disparar mensagens externas.
Congele a versão: registre modelo, instruções, ferramenta, esquema, dados de teste e resultado esperado.
Exporte os artefatos: obtenha regras, configurações, dez casos, logs e estados em formatos legíveis.
Troque uma camada: use outro modelo, cliente MCP, agente A2A ou execução manual, mantendo o mesmo contrato de resultado.
Reexecute os casos: compare conclusão, qualidade, ação no sistema, tempo, custo e rastreabilidade.
Meça o esforço real: anote horas, conhecimento necessário, ajustes proprietários e itens que não puderam ser recuperados.

Se a troca só funciona com a presença do fornecedor atual, o processo ainda não é portátil. Se o resultado muda porque a regra estava implícita, o problema é de processo. Se a conexão abre, mas a ação não pode ser auditada, o protocolo resolveu transporte, não controle.

Perguntas para levar à demonstração comercial

Quais componentes usam padrão aberto e quais dependem de extensão proprietária?
Qual versão do protocolo é suportada e como são tratadas mudanças incompatíveis?
Prompts, regras, esquemas, casos de teste e configurações podem ser exportados em formato legível?
Quem é titular das contas, chaves, servidores e integrações criados no projeto?
Como exportamos conversas, estados, aprovações, avaliações e logs com identificadores consistentes?
Qual parte da solução continua funcionando se o modelo ou a plataforma principal ficar indisponível?
Quanto tempo e quais serviços são necessários para transição, encerramento e eliminação de dados?
O fornecedor aceita executar um teste de troca com casos reais anonimizados antes da expansão?

Como a dependência aparece em cada setor

v7 Obras: ocorrências, fotos e responsáveis precisam manter vínculo com etapa, frente e data. Exportar apenas o relatório final perde o histórico que permite reconstruir atraso e decisão.
v7 Carteira: carteira, promessa, baixa e mensagem devem compartilhar identificadores. Na troca, separar títulos já tratados dos pendentes evita cobrança duplicada.
v7 Agro: histórico de visitas, propriedades, safras e janelas comerciais não pode ficar preso ao resumo gerado. O dado operacional precisa permanecer no CRM ou sistema oficial.
v7 Imob: origem, consentimento, perfil, imóveis apresentados e handoff ao corretor devem ser recuperáveis para preservar contexto e atribuição.
v7 Clínicas Retorno: a agenda oficial e os registros autorizados devem continuar no sistema da clínica; o agente não pode virar o único lugar onde existe confirmação ou tentativa de contato.
v7 Custom: regras internas, esquemas de ferramentas e testes de aceite são ativos da operação. Mantê-los versionados reduz o custo de trocar modelo, integração ou equipe.

Sinais de alerta antes da assinatura

a demonstração fala em “qualquer sistema”, mas não nomeia método, limite e responsável pela integração;
o fornecedor promete ausência de lock-in apenas porque usa MCP ou A2A;
as contas e chaves ficam em nome de pessoa ou parceiro, sem administração da empresa;
existe exportação de conversa, mas não de estado, aprovação, versão e confirmação de ação;
o preço de entrada é claro e o custo de volume, suporte, exportação e transição não é;
ninguém consegue executar o modo manual ou assistido com a plataforma suspensa;
não há bateria de testes que permita comparar a solução atual com uma alternativa.

O ponto de vista operacional

Portabilidade não significa trocar de fornecedor toda semana. Significa preservar poder de decisão. Padrões como MCP e A2A tornam o ecossistema mais componível, mas o ativo mais importante continua sendo a operação: processo definido, dados sob controle, responsável nomeado, critérios de aceite, registros e rotina de revisão.

IA gera ROI quando sobrevive à demonstração, à mudança de versão e à evolução do negócio. Uma empresa IA Ready não evita toda dependência; ela sabe onde depende, quanto custa, como controla e como continua trabalhando se precisar mudar.

Fontes consultadas

Quer avaliar uma solução de IA antes de criar dependência operacional?

O V7 IA Ready mapeia processo, dados, integrações, responsáveis, riscos e critérios de aceite para escolher uma arquitetura que possa evoluir sem prender a operação a promessas ou interfaces.

Conhecer o V7 IA Ready Solicitar diagnóstico

Seu agente de IA tem plano de saída?