AI, A2A e a Lacuna de Governança
Nos últimos seis meses, um padrão tem se repetido nas equipes de IA empresarial. A2A e ACP iluminam a sala durante as revisões de arquitetura — os protocolos são elegantes, as demonstrações impressionantes. Três semanas após a produção, alguém pergunta: “Espere, qual agente autorizou o pagamento de $50,000 a um fornecedor às 2 da manhã?” A empolgação se transforma em preocupação.
Esse é o paradoxo: o Agent2Agent (A2A) e o Agent Communication Protocol (ACP) são tão eficazes em eliminar a fricção de integração que removeram os “freios” naturais que costumavam forçar conversas sobre governança. Resolvemos brilhantemente o problema da infraestrutura. Ao fazê-lo, criamos uma nova classe de dívida de integração — uma onde as organizações tomam emprestado velocidade hoje à custa de responsabilidade amanhã.
Os protocolos técnicos são sólidos. Os protocolos organizacionais estão ausentes. Estamos rapidamente passando da fase de “Esses sistemas podem se conectar?” para a fase de “Quem autorizou este agente a liquidar uma posição às 3 da manhã?” Na prática, isso cria uma lacuna de governança: nossa capacidade de conectar agentes está superando nossa capacidade de controlar o que eles nos comprometem.
A Evolução do “Stack de Agentes”
Para entender por que essa mudança está ocorrendo tão rapidamente, é útil observar como o “stack de agentes” subjacente está evoluindo. Estamos vendo o surgimento de uma estrutura em três camadas que substitui silenciosamente a conectividade tradicional baseada em API:
- Ferramentas: MCP (Model Context Protocol) – conecta agentes a dados locais e ferramentas específicas — funciona como caixa de ferramentas de um trabalhador.
- Contexto: ACP (Agent Communication Protocol) – padroniza como objetivos, histórico do usuário e estado se movem entre os agentes — funciona como a memória e briefing de um trabalhador.
- Coordenação: A2A (Agent2Agent) – gerencia descoberta, negociação e delegação entre fronteiras — funciona como um contrato ou aperto de mão.
Esse stack torna os fluxos de trabalho multi-agentes um problema de configuração em vez de um projeto de engenharia personalizado. É exatamente por isso que a superfície de risco está se expandindo mais rápido do que a maioria dos CISOs percebe.
A Lacuna de Governança
Pense assim: A2A é o aperto de mão entre os agentes (quem fala com quem, sobre quais tarefas). ACP é o documento de briefing que eles trocam (qual contexto, histórico e objetivos se movem nessa conversa). MCP é a caixa de ferramentas que cada agente tem acesso localmente. Uma vez que você veja o stack dessa forma, também verá o próximo problema: resolvemos a proliferação de APIs e silenciosamente a substituímos por algo mais difícil de ver — proliferação de agentes, e com isso, uma lacuna de governança crescente.
A maioria das empresas já luta para governar centenas de aplicativos SaaS. Uma análise coloca a média em mais de 370 aplicativos SaaS por organização. Os protocolos de agentes não reduzem essa complexidade; eles a contornam. Na era das APIs, os humanos abriam tickets para acionar ações do sistema. Na era A2A, os agentes usam “Cartões de Agente” para descobrir uns aos outros e negociar sobre esses sistemas. O ACP permite que esses agentes troquem contextos ricos — significando que uma conversa iniciada no suporte ao cliente pode fluir para o cumprimento e a logística de parceiros sem transferências humanas.
O que costumava ser proliferação de APIs está se tornando dezenas de processos semiautônomos atuando em nome da sua empresa em uma infraestrutura que você não controla totalmente. A fricção da integração manual costumava agir como um freio natural ao risco; A2A removeu esse freio.
Essa lacuna de governança geralmente não aparece como uma única falha catastrófica. Ela aparece como uma série de pequenos incidentes confusos onde tudo parece “verde” nos painéis, mas o resultado comercial está errado. A documentação do protocolo foca em criptografia e apertos de mão, mas ignora os modos de falha emergentes da colaboração autônoma. Essas não são falhas nos protocolos; são sinais de que a arquitetura circundante não acompanhou o nível de autonomia que os protocolos permitem.
Modos de Falha Emergentes
- Desvio de Políticas: Uma política de reembolso codificada em um agente de serviço pode interagir tecnicamente com o agente de cobranças de um parceiro via A2A, mas sua lógica de negócios pode ser diametralmente oposta. Quando algo dá errado, ninguém é responsável pelo comportamento de ponta a ponta.
- Excesso de Compartilhamento de Contexto: Uma equipe pode expandir um esquema ACP para incluir “Sentimento do Usuário” para melhor personalização, sem saber que esses dados agora se propagam para cada agente terceirizado na cadeia. O que começou como enriquecimento local se torna exposição distribuída.
- A Armadilha do Determinismo: Ao contrário das APIs REST, os agentes são não determinísticos. A lógica da política de reembolso de um agente pode mudar quando seu modelo subjacente é atualizado de GPT-4 para GPT-4.5, mesmo que o Cartão de Agente declare capacidades idênticas. O fluxo de trabalho “funciona” — até que não funcione, e não há rastreio de versão para depurar. Isso cria o que chamamos de “quebras fantasma”: falhas que não aparecem na observabilidade tradicional porque o contrato da interface parece inalterado.
Esses modos de falha não são casos extremos. Eles são o que acontece quando damos mais autonomia aos agentes sem atualizar as regras de engajamento entre eles. Esses modos de falha têm uma causa raiz comum: a capacidade técnica de colaborar entre agentes superou a habilidade da organização de dizer onde essa colaboração é apropriada e sob quais restrições.
A Necessidade de um Tratado de Agentes
Por isso, precisamos de algo além dos próprios protocolos: uma camada explícita de “Tratado de Agentes”. Se o protocolo é a linguagem, o tratado é a constituição. A governança deve passar de “documentação lateral” para “política como código”.
A governança tradicional trata as violações de políticas como falhas a serem prevenidas. Uma abordagem antifrágil as trata como sinais a serem explorados. Quando um agente faz um compromisso que viola uma restrição comercial, o sistema deve capturar esse evento, rastrear a cadeia causal e alimentar isso tanto no treinamento do agente quanto no conjunto de regras do tratado. Com o tempo, a camada de governança se torna mais inteligente, não apenas mais rigorosa.
- Definir restrições em nível de tratado: Não apenas autorizar uma conexão; autorizar um escopo. Quais campos ACP um agente pode compartilhar? Quais operações A2A são “somente leitura” versus “legalmente vinculativas”? Quais categorias de decisões exigem escalonamento humano?
- Versionar o comportamento, não apenas o esquema: Tratar Cartões de Agente como superfícies de produto de primeira classe. Se o modelo subjacente mudar, a versão deve ser atualizada, acionando uma nova revisão do tratado. Isso não é uma sobrecarga burocrática — é a única maneira de manter a responsabilidade em um sistema onde agentes autônomos fazem compromissos em nome da sua organização.
- Rastreabilidade entre organizações: Precisamos de rastreios de observabilidade que não mostrem apenas latência, mas que mostrem intenção: Qual agente fez esse compromisso, sob qual política? E quem é o proprietário humano? Isso é particularmente crítico quando os fluxos de trabalho atravessam fronteiras organizacionais e ecossistemas de parceiros.
Projetar essa camada de tratado não é apenas um problema de ferramentas. Muda quem precisa estar na sala e como eles pensam sobre o sistema. A restrição mais difícil não é o código; são as pessoas. Estamos entrando em um mundo onde engenheiros devem raciocinar sobre teoria dos jogos multi-agentes e interações de políticas, não apenas integração de SDK. As equipes de risco devem auditar “compromissos máquina-a-máquina” que podem nunca ser traduzidos em linguagem humana. Os gerentes de produto devem possuir ecossistemas de agentes onde uma mudança na função de recompensa ou esquema de contexto de um agente altera o comportamento em toda uma rede de parceiros. Funções de conformidade e auditoria precisam de novas ferramentas e modelos mentais para revisar fluxos de trabalho autônomos que executam em velocidade de máquina. Em muitas organizações, essas habilidades estão em silos diferentes, e a adoção de A2A/ACP está progredindo mais rápido do que as estruturas interfuncionais necessárias para gerenciá-las.
Conclusão
Tudo isso pode parecer abstrato até que se observe onde as empresas estão em sua curva de adoção. Três tendências convergentes tornam isso urgente: a maturidade dos protocolos significa que as especificações A2A, ACP e MCP se estabilizaram o suficiente para que as empresas estejam passando de pilotos para implantações em produção. A orquestração multi-agente está mudando de agentes únicos para ecossistemas de agentes e fluxos de trabalho que abrangem equipes, departamentos e organizações. E a autonomia silenciosa está borrando a linha entre “assistência de ferramenta” e “decisão autônoma” — frequentemente sem reconhecimento organizacional explícito. Estamos passando de integração (fazer as coisas conversarem) para orquestração (fazer as coisas agirem), mas nossas ferramentas de monitoramento ainda medem apenas a conversa. Os próximos 18 meses determinarão se as empresas conseguem se antecipar a isso ou se veremos uma onda de falhas de alto perfil que forçarão uma governança retroativa.
O risco não é que A2A e ACP sejam inseguros; é que eles são muito eficazes. Para as equipes que estão testando esses protocolos, pare de focar no “caminho feliz” da conectividade. Em vez disso, escolha um fluxo de trabalho multi-agente e instrumentalize-o como um produto crítico:
- Mapear o fluxo de contexto: Cada campo ACP deve ter uma etiqueta de “limitação de propósito”. Documente quais agentes veem quais campos e quais requisitos comerciais ou regulatórios justificam essa visibilidade. Isso não é um exercício de inventário; é uma maneira de expor dependências de dados ocultas.
- Auditar os compromissos: Identifique cada interação A2A que representa um compromisso financeiro ou legal — especialmente aquelas que não passam pela aprovação humana. Pergunte: “Se o comportamento deste agente mudasse da noite para o dia, quem notaria? Quem é responsável?”
- Codificar o tratado: Prototipe um agente “guarda” que faça cumprir as restrições comerciais sobre o tráfego bruto do protocolo. Isso não é sobre bloquear agentes; é sobre tornar a política visível e executável em tempo real. Comece de forma mínima: uma política, um fluxo de trabalho, uma métrica de sucesso.
- Instrumentar para aprendizado: Capture quais agentes colaboram, quais políticas invocam e quais contextos compartilham. Trate isso como telemetria, não apenas registros de auditoria. Alimente padrões de volta nas revisões de governança trimestrais.
Se isso funcionar, você terá um padrão repetível para escalar implantações de agentes sem sacrificar a responsabilidade. Se falhar, você aprendeu algo crítico sobre sua arquitetura antes que ela quebre na produção. Se você conseguir fazer um fluxo de trabalho se comportar dessa maneira — governado, observável e aprendendo ao longo do caminho — você terá um modelo para o restante do seu ecossistema de agentes.
Se a última década foi sobre tratar APIs como produtos, a próxima será sobre tratar fluxos de trabalho autônomos como políticas codificadas no tráfego entre agentes. Os protocolos estão prontos. Sua estrutura organizacional não está. A ponte entre os dois é o Tratado de Agentes — comece a construí-lo antes que seus agentes comecem a assinar acordos sem você. A boa notícia: você não precisa redesenhar toda a sua organização. Você precisa adicionar uma camada crítica — o Tratado de Agentes — que torna a política executável por máquina, observável e aprendível. Você precisa de engenheiros que pensem sobre composição e teoria dos jogos, não apenas conexão. E você precisa tratar as implantações de agentes como produtos, não como infraestrutura.
Quanto mais cedo você começar, mais cedo essa lacuna de governança se fechará.
