Governança de Agentes de IA em Múltiplas Plataformas

A maioria das empresas não decidiu adotar agentes de IA em cinco plataformas. Isso simplesmente aconteceu. O Microsoft Copilot chegou com o pacote de produtividade. O ServiceNow lançou o Now Assist na fila de tickets. A Salesforce ativou o Agentforce dentro do CRM. Outras plataformas de dados e SaaS começaram a executar agentes ao lado dos sistemas de registro. Cada plataforma trouxe seu próprio tempo de execução de IA — e, discretamente, seu próprio modelo de governança que termina na borda da plataforma.

O resultado é uma lacuna de governança que é difícil para qualquer fornecedor de plataforma de aplicação fechar sozinho. Quando um agente dentro de uma plataforma chama uma API, quem o autorizou? Quando um agente em outra plataforma resume um documento sensível, qual política regeu a resposta? E quando um agente se comporta mal em produção, quem pode contê-lo rapidamente — sem coordenar entre múltiplos consoles de fornecedores ou filas de suporte?

Este não é um risco futuro. É a realidade operacional para qualquer organização que adotou mais de uma plataforma de IA de forma independente — o que é cada vez mais comum em grandes empresas.

A dimensão do problema

Antes de se falar em uma solução, vale a pena ser preciso sobre por que isso é realmente difícil. A dificuldade é estrutural e se manifesta em quatro pontos simultaneamente.

E há um quinto problema que só se torna visível no momento em que um usuário tenta realmente fazer algo com um agente de terceiros: o imposto de credenciais.

O imposto de credenciais oculto

Considere um prompt rotineiro enviado a um agente oficial de terceiros instalado dentro de um assistente estilo Copilot. Na primeira vez que um usuário o utiliza, o agente não consegue responder até que o usuário faça login diretamente nesse serviço de terceiros.

Isso não é um erro. É a única arquitetura segura quando cada agente é um produto vendido separadamente. Mas, quando acumulado em todo o inventário de ferramentas de uma empresa, isso tem consequências operacionais reais:

• Atrito por usuário, por ferramenta. Cada funcionário reautoriza cada agente na primeira vez que o utiliza. Multiplique pela força de trabalho e, em seguida, pelo inventário de ferramentas.
• Proliferação de tokens. Tokens OAuth para cada serviço conectado acabam espalhados pelos armazenamentos de identidade do usuário. A conformidade se torna uma questão por fornecedor, em vez de uma única trilha de auditoria.
• Nenhuma revogação central. Quando um contrato muda ou um incidente exige o corte de acesso, a organização tem que gerir isso através de cada relação com fornecedores, em vez de num único ponto de controlo.

‍