IA Governance: o plano de controle por trás de cada tool call dos seus agentes

Há seis meses, eu ainda acompanhava equipes demonstrando agentes. Hoje acompanho agentes que agem. Entre um momento e o outro, o centro de gravidade da infraestrutura agêntica se moveu de "o modelo dá conta da tarefa" para "você sobrevive ao instante em que a resposta deixa de ser resposta e vira ação". Uma chamada de ferramenta é uma escrita no mundo. Um email sai. Uma linha é atualizada. Um pedido é registrado. Um arquivo é excluído. Quem decide é probabilístico; quem executa não é. Todo incidente em sistemas agênticos mora nesse vão, e este post é sobre fechar esse vão.

Criei o Vinkius a partir de uma convicção: uma nuvem para agentes de IA só está pronta quando você consegue responder quatro perguntas sobre qualquer chamada de ferramenta, a qualquer momento, com evidência anexa. Quem chamou. O que estava permitido acontecer. O que cruzou o portão, e o que foi protegido a caminho. E quanto custou. A resposta para essas quatro perguntas é o plano de controle que entregamos como doze superfícies: oito que contam o que está acontecendo, e quatro que decidem o que é permitido. Tudo abaixo é o que a plataforma faz hoje. Os números são os números que o sistema aplica ou reporta, não os que eu gostaria que ele tivesse.

O momento em que os agentes param de conversar e começam a agir

Na empresa, resposta a incidente ficou quieta por anos, porque o que quebrava era construído por humanos e mudava devagar. Um serviço tem um dono, um changelog, um post-mortem e uma população fixa de chamadores. Quando o chamador é um modelo, tudo isso evapora em uma decisão de design. O mesmo agente pode agendar uma reunião pela manhã, escrever código ao meio-dia e consultar um banco de produção à tarde. Essa é a função dos sistemas agênticos: um principal, muitas ferramentas, e nenhuma memória da fronteira entre elas. As categorias de falha mudam junto.

O monitoramento clássico pergunta "a chamada falhou, e por quê". Com agentes, você precisa fazer quatro perguntas a mais, e cada um tem sua própria forma de resposta. A falha foi do agente, porque ele mandou um pedido malformado ou ficou em loop numa ferramenta quebrada? Foi do serviço de fora, porque a API que ele chamou devolveu um 500? Foi da plataforma, porque o portão se comportou mal? E tem aquela que ninguém faz até o time financeiro perguntar: quanto tudo isso custou, por chamada, por conector, por agente, em dólar?

Li reportes de incidente suficientes, nesse espaço e no meu, para conhecer o padrão de resposta. É quase sempre "não conseguimos dizer qual agente fez o quê, e soubemos depois do dano". Um chamador não-determinístico e um sistema de log a posteriori formam um par péssimo. O log é uma foto da cena do crime, e o suspeito já saiu do prédio. Governança é a arquitetura que faz o suspeito, a arma e o carimbo de tempo serem registrados no momento do ato, e não depois.

O que governança de IA realmente é

Governança de IA, no sentido que a indústria precisa, é o plano de controle que cerca o tráfego de agentes para ferramentas. Não é um motor de políticas no sentido tradicional do OPA, decidindo no deploy quais regras um serviço recebe. Não é RBAC, que decide qual humano pode entrar. Não é um SIEM, que correlaciona logs depois do fato. Todos esses sistemas foram desenhados para um mundo em que o que age é uma pessoa ou um pipeline fixo.

O que a governança de IA faz é diferente, e vale ser preciso. Ela decide, por chamada, se a ação de um principal não-determinístico pode acontecer, numa máquina, contra o sistema de um terceiro, sob um orçamento. E guarda, para cada chamada, um comprovante que responde quem, o quê e quanto. O termo "governança" está fazendo trabalho de verdade aqui, e não é só uma palavra de compliance. Compliance é a saída. A entrada é um plano de controle com duas propriedades: atribuição na granularidade de identidade, e aplicação em voo, antes que a chamada saia da sua infraestrutura.

No Vinkius, esse plano de controle é o que chamamos de Governança de IA, e ele se organiza em doze superfícies. Oito superfícies de relatório contam o que está acontecendo na frota de conectores que seus agentes usam. Quatro superfícies de política decidem o que é permitido, e elas são aplicadas no runtime, no caminho da chamada, não em um dashboard que você abre às segundas. A divisão é de propósito. Um dashboard sem ação é teatro, e uma política sem comprovante é medo. As duas metades são necessárias, e o produto é a união das duas.

Por que o portão é o único lugar onde controle sobrevive

O argumento arquitetural é curto. Seus agentes não chamam suas APIs de fora diretamente. Eles chamam ferramentas, e no Vinkius essas ferramentas são conectores, servidores MCP hospedados que cada agente da frota alcança por um portão único. O portão é onde o tráfego passa, então é onde o controle precisa morar.

O lado do cliente não é um lugar seguro para isso. Guardrails no nível do prompt são frágeis por construção, porque o modelo consegue reformular sua volta por cima de uma regra, e porque um guardrail que mora no prompt está a uma janela de contexto de não existir mais. Filtros do provedor não são o seu caminho de dados, e você não consegue responsabilizar um fornecedor pelo comportamento do seu agente. Analytics a posteriori, o SIEM que você acopla depois, é um registro do que aconteceu, o que é útil, e tarde demais para impedir o que está acontecendo agora.

O portão vê tudo ao mesmo tempo: a chamada, a resposta, o token que autenticou a chamada, o conector que ela mirou, e o relógio. Esse é o único ponto do sistema em que "quem, o quê e quanto" tem resposta com um único conjunto de dados, e também o único ponto em que uma decisão ainda pode mudar o desfecho. Toda chamada da frota cruza o portão duas vezes, na ida e na volta, e os dois cruzamentos é que são a governança.

Duas outras peças da plataforma completam o argumento do portão. Cada conector roda dentro do seu próprio isolate sandboxado, um design que eu escrevi em como o Vinkius roda cada servidor MCP em um isolate V8, de modo que uma ferramenta hostil ou quebrada só age pelos efeitos que o host possui. E desde a versão 5.1.0 do nosso framework aberto, o contexto de trace distribuído do agente é carregado através do portão, então cada span de ferramenta se ancora na trace do chamador. Esse trabalho está em o post do MCP Fusion 5.1.0 sobre correlação de trace, e ele importa aqui porque um comprovante de governança que não se junta à trace do próprio agente é um comprovante que ninguém consegue ler.

Uma nota de honestidade antes do tour: no plano gratuito, o dashboard de Governança de IA abre com dados de exemplo claramente rotulados. Você explora a forma do plano de controle antes de se comprometer. A aplicação ao vivo, o disjuntor e a parada de emergência rodam em planos pagos. Prefiro dizer isso abertamente do que deixar o leitor assumir que o gratuito faz o que é pago.

Oito superfícies que contam o que está acontecendo

A metade de relatórios da Governança de IA é onde eu quero gastar mais tempo, porque é a parte que as empresas testam primeiro, e a parte em que "instrumentamos nossos agentes" costuma se revelar uma frase sobre quatro dashboards e uma oração.

Mission Control

A superfície do topo é a faixa de KPIs da frota inteira: chamadas totais, latência média, uma figura de confiabilidade que chamamos de Vinkius Reliability, tokens totais movimentados, a contagem de valores protegidos pela prevenção de perda de dados e o custo economizado pelo guarda de FinOps. Abaixo fica um heatmap de 30 dias da atividade agêntica no mês, um gráfico de volume e latência de chamadas, e um AI Briefing: um digest gerado por modelo de linguagem sobre o que mudou no seu tráfego no período. É a única superfície deliberadamente não determinística em um plano de controle determinístico, e é um recurso pago, porque o briefing é uma chamada de modelo. Um detalhe que eu exijo: a figura de confiabilidade que você vê exclui os erros do próprio Vinkius. O número responde "o quão confiável é a frota para você", não "o quão confiável somos nós". Não contamos nossos erros contra o seu tempo de disponibilidade.

Agent Activity

A visão por cliente. Cada token de conexão da sua organização aparece com a atividade dele: qual é o cliente, quando chamou pela última vez, quantas chamadas fez. Essa é a superfície que responde "qual agente está fazendo o quê". Um agente que deveria rodar a cada hora e está chamando a cada noventa segundos aparece aqui, e é ali que um loop descontrolado costuma ser notado, antes de virar fatura.

Connector Traffic

A mesma decomposição, por conector. Qual das suas ferramentas está quente, qual está fria, onde a latência se concentra. Quando um provedor externo degrada, é essa visão que separa o problema do provedor do problema da sua frota.

Access Tokens

A frota de tokens como inventário. Status, último uso, contagem de chamadas. Essa ganha sua existência de um jeito que surpreende: um token de conexão que não é usado há 90 dias é uma credencial permanente que você emitiu e esqueceu, e essa superfície existe para tornar esse esquecimento visível e acionável, com revogação e rotação a um clique.

AI Spend

Custo, tornado legível. Gasto estimado, as economias medidas pelo guarda de FinOps, custo por chamada, o retorno das políticas de FinOps e um livro-razão por conector. O guarda atribui custo sobre uma taxa de por milhão de tokens que você define, e o padrão é 3 dólares por milhão de tokens. O ponto da superfície não é cobrar você. É mostrar qual agente, em qual conector, está consumindo o quê, porque gasto de agente não tem a forma de nenhum custo que você já tenha gráfico antes. Não é por usuário nem por chamada. É por raciocínio, e ele se multiplica com cada retry que um loop acrescenta.

Capability Reliability

Confiabilidade no nível da ferramenta, não do serviço. Cada capacidade que um conector expõe tem seu próprio comportamento de latência e falha, e a Tool Health Matrix os plota juntos: latência contra taxa de falha, uma bolha por ferramenta. Um conector pode estar perfeitamente saudável enquanto uma ferramenta específica dentro dele falha em silêncio. Essa é a diferença entre monitorar um produto e monitorar o que os seus agentes realmente tocam.

Security Posture

Duas séries temporais e um donut. As séries acompanham quanto a camada DLP blindou e quanto a camada de FinOps truncou, ao longo do tempo. O donut é o Compliance Coverage: a fração de políticas de governança ativas na frota, contada por categoria, DLP, FinOps e aprovações. É o número que o revisor quer ver, e ele é calculado do estado das políticas, não de um questionário que você preenche.

Request Failures

A linha do tempo de erros, dividida em três caixas: erros do Agente, onde o chamador mandou algo que a ferramenta não pôde honrar, erros do Upstream, onde o terceiro por trás do conector falhou, e erros do Vinkius, onde falhamos nós. Essa é a atribuição de falhas sobre a qual o início deste post falava. Quando uma chamada falha, você sabe de quem foi a falha, na mesma visão, no mesmo período, sem reunião.

Request Detail: o comprovante

Abra qualquer chamada individual e você tem a unidade de responsabilidade pela qual o plano de controle inteiro existe. O comprovante nomeia a identidade que fez a chamada: token, cliente, e o humano ou o usuário de aplicação por trás. Lista a política em vigor naquele instante, regra por regra, agrupada pela fase do ciclo de vida da chamada a que cada regra pertence, com o veredito de cada uma: pass, fail, off ou enforced. Mostra a entrada de auditoria da chamada, selada na ingestão no ledger encadeado por hash que descrevo abaixo. Mostra a continuidade de trace, o contexto W3C que junta essa chamada à trace distribuída do próprio agente. Decompõe a latência em tempo que a API de fora levou e tempo que a camada de governança adicionou, então você sempre sabe o custo do próprio plano de controle. E termina com ações: bloquear uma capacidade para todos os chamadores, ou, no Business, a parada de emergência do conector. Uma chamada, uma tela, a história inteira.

Quatro superfícies que decidem o que é permitido

Connector Policy

A primeira superfície de política é sobre como um conector entra na sua frota. Deploys podem exigir aprovação antes de ficarem ativos, e o produto amarra essa configuração ao princípio dos quatro olhos que o AI Act da UE espera de sistemas de alto risco no Art. 14(5): uma pessoa não decide sozinha que uma ferramenta nova com consequências reais chega aos agentes. A mesma superfície controla como as capacidades são expostas ao modelo, a plano ou agrupadas, com um agrupamento automático quando a lista de ferramentas do conector cresce, porque o que o modelo vê é área de superfície, e área de superfície é decisão de design.

E tem a zona de perigo, que eu prefiro que você entenda do que descubra. O Global Emergency Halt para todos os conectores ativos da sua organização. Ele os desativa, revoga todos os tokens e termina todas as sessões abertas, em uma única ação síncrona, e a confirmação exige digitar HALT ALL, porque esse é o botão que você aperta quando algo deu muito errado e você prefere a frota inteira morta a errada. Depois da parada dá para restaurar, mas os tokens revogados continuam revogados. Você os reemite com intenção. Essa é uma decisão de design que quero deixar explícita: a recuperação é uma relação de confiança nova, não um replay da antiga.

DLP Protection

Prevenção de perda de dados, desenhada para o caminho do modelo. Você nomeia padrões de campos sensíveis, um email em qualquer lugar da árvore de resposta, um número de cartão, um campo em um caminho específico que você decide proteger, e o runtime os aplica no caminho de saída, mascarando o valor antes que a resposta chegue ao agente. A blindagem acontece em memória, no caminho entre o serviço de fora e o modelo, que é a diferença entre dados que foram mascarados e dados que nunca estiveram no contexto do modelo. O KPI que você vê no Mission Control, DLP Protected, conta os mascaramentos por período, então a camada não existe só, ela é medida.

FinOps Guard

Guardarails de custo, pelos motivos da seção de AI Spend. O guarda faz três coisas. Ele trunca arrays além de um número máximo de itens, porque uma resposta que devolve dez mil registros é uma fatura de tokens, não uma resposta. Ele comprime as descrições de ferramentas que o modelo lê antes de agir, a configuração de Toon compression do dashboard. E atribui custo sobre a taxa que você define, para que o guarda conte, por período, quanto economizou, em bytes e em dólar, contra a taxa. A saída não é uma fatura. É a medida do vão entre o que a ferramenta devolveu e o que o agente precisava, que é o número que decide se o seu agente pode continuar chamando essa ferramenta.

Circuit Breaker

Um orçamento de chamadas em janela deslizante por conector, com padrão de 5.000 chamadas a cada 5 minutos e resfriamento de 15 minutos, números que você ajusta. Quando o orçamento de um conector estoura, o disjuntor dispara, e o disparo faz o que a maioria dos guardrails nunca faz: ele avisa o agente, em uma recusa legível por máquina escrita para um modelo, que o recurso está aberto e que ele deve recuar. Um agente bom respeita isso. Um loop que não lê a recusa é parado pelo mesmo disparo, que é o ponto. O estado do disjuntor é compartilhado entre as instâncias do portão, então um orçamento é um orçamento, não um limite por processo que reseta quando o tráfego muda de instância. Depois do resfriamento ele reseta sozinho, ou você aprova a retomada no dashboard. O disjuntor é o que impede um agente descontrolado de levar a API de um terceiro, e a sua fatura junto. A camada de sessões que mantém o enxame sob controle é o assunto do post sobre sessões do SwarmGateway.

Os alicerces: tokens com escopo, cofre selado, ledger encadeado

As doze superfícies assentam em alicerces, e é nos alicerces que muita "governança" é na verdade fina.

A camada de identidade é o token de conexão. Cada conector tem os próprios tokens, gerados por organização, mostrados uma única vez, assinados, e com escopo apenas para aquele conector. O token do conector de email não toca o conector de pagamentos. Cada comprovante nomeia o token que fez a chamada, então identidade não é teoria, é uma coluna dos dados de auditoria.

A camada de segredos é o cofre. As credenciais dos conectores são criptografadas em repouso com AES-256, e a garantia que fazemos é que nem os próprios operadores da plataforma conseguem lê-las em repouso. Elas são injetadas apenas em runtime, no isolate onde o código da ferramenta roda, e o agente nunca vê o segredo. Essa separação é a que mais me preocupa no design: o que decide, o modelo, e o que prova autoridade, a credencial, nunca devem compartilhar contexto. Um modelo que lê a sua senha de cima não é um problema de governança que auditoria resolve. É o problema.

A camada de auditoria é o ledger. Cada hash de chamada é selado na ingestão, e o ledger é encadeado por hash: cada registro carrega o hash anterior e a posição na sequência, e a cadeia é assinada, SHA-256 com Ed25519, então uma manipulação não é um problema de privacidade, é um evento detectável, e o dashboard diz se a cadeia é válida ou comprometida. A auditoria de deploy é estruturada sobre o Art. 73 do GDPR, o direito de acesso do titular de dados, então quando um regulador ou um cliente pede o histórico completo de um conector, a resposta é uma única cadeia exportável e verificável, não um projeto.

E mais uma camada, da qual tenho mais orgulho. Alguns conectores do nosso marketplace são iscas monitoradas. Eles parecem ferramentas reais. Não são, e eles são vigiados. Quando uma isca é tocada, a plataforma isola a ferramenta, revoga o token, mata as conexões abertas e congela o caminho de pagamento, automaticamente. Se uma ferramenta vira hostil, ou um token vaza, a contenção não espera você perceber.

Lá embaixo de tudo, a camada de organização: single sign-on, papéis e equipes customizadas, contas de serviço para as identidades não humanas que rodam em CI e workloads OIDC, chaves de API de organização, e um log de auditoria de segurança para as ações sobre a própria organização. O plano de controle assenta sobre um modelo de identidade que conhece a diferença entre pessoa e máquina, que é uma diferença em que cada uma das doze superfícies confia.

O que a governança muda para os próprios agentes

Quase toda conversa sobre governança de agentes trata o agente como risco a conter, e eu não vou fingir o contrário, porque ele é. Mas a metade do argumento que eu colocaria em um deck de vendas é a que acho que define a década: governança é o que transforma o agente de demo em funcionário.

Confiança é concedida na proporção da evidência. Um operador vai passar o turno da noite ao agente, a query de produção, a conciliação de pagamento, na proporção exata em que cada ação que ele tomou pode ser atribuída, orçada, blindada e verificada depois. O comprovante não é um fardo sobre o agente. É a credencial que dá a ele a sala maior.

O envelope de um agente governado é conhecível. Uma política determinística ao redor de um modelo não-determinístico é a única forma sã para produção: o modelo planeja dentro de uma caixa, e a caixa é estável. A recusa do disjuntor está escrita na linguagem do modelo, então o agente aprende o orçamento, e o respeita, em vez de descobri-lo em forma de fatura. O truncamento do guarda de FinOps faz o modelo receber uma resposta com tamanho, em vez de um blob de 200 quilobytes, que é um problema de inteligência, não só de custo.

E o agente ganha, ele mesmo, a capacidade que nenhum sistema autônomo teve na prática: mostrar o trabalho. Para um agente que vai operar em fluxos regulados, a trilha de auditoria não é overhead, é o produto. O agente governado é o único tipo de agente ao qual dá para dar autoridade real, e o agente sem governança é, para sempre, uma demo.

Observabilidade que finalmente fala a língua dos agentes

Se o seu time já roda Datadog ou Grafana, a forma das superfícies de Governança de IA vai parecer familiar, e isso é de propósito. Faixas de KPIs, heatmaps, drill-downs, comprovantes por chamada. O que não é familiar é o que o tráfego de agentes faz ao modelo para o qual essas ferramentas foram construídas.

O Datadog mede um mundo em que os chamadores são sistemas que alguém escreveu. A carga tem forma fixa, o custo escala com usuários ou chamadas, e uma falha tem um dono. O tráfego de agentes quebra as três premissas ao mesmo tempo. O chamador é probabilístico. A carga tem a forma do raciocínio, e um loop de retry a multiplica. E uma falha tem três donos candidatos, agente, upstream e plataforma, por isso a linha do tempo de falhas se divide em três caixas em vez de uma.

Então o plano de controle para agentes é observabilidade com camada de aplicação, e a camada de aplicação é a propriedade que sistemas agênticos precisam e que as plataformas construídas para mundos feitos por humanos não têm. Cada chamada de ferramenta é atribuída a uma identidade, o custo é atribuído na granularidade do token, as falhas são atribuídas a um lado responsável, e a camada de política age em voo, antes que a chamada saia do portão. Essa é a elevação que eu queria neste post: pegar a disciplina de instrumentação das plataformas que você já confia, e somar as duas propriedades que sistemas agênticos exigem, atribuição por chamada e aplicação em voo. O resultado não é uma nova categoria de ferramenta. É a mesma categoria, na resolução que sistemas agênticos exigem.

Perguntas frequentes

Governança de IA é RBAC com passos extras?

Não, e a diferença é a unidade da decisão. RBAC decide qual humano, com qual papel, alcança um sistema. É uma porta na identidade, avaliada uma vez. A governança de IA decide o que uma ação, tomada por um principal não-determinístico através de uma ferramenta específica, pode fazer, a cada chamada, sob um orçamento, com a resposta registrada. Uma é uma porta. A outra é o tribunal do trânsito, onde cada ação dos seus agentes é julgada.

O Vinkius lê os prompts dos meus agentes?

Não. O portão vê a chamada de ferramenta: o nome da ferramenta, os argumentos que ela enviou, a resposta que recebeu, a identidade por trás, e o relógio. As quatro superfícies de política são camadas determinísticas de regra e orçamento, não um juiz de linguagem. Se você quer que um modelo inspecione o modelo, isso é outro produto, e eu não chamaria isso de governança, chamaria de segunda opinião.

O que acontece quando o disjuntor dispara?

O tráfego do conector é recusado com um aviso legível por máquina que diz ao agente que o orçamento está aberto e que ele deve recuar, por um período de resfriamento. Depois do resfriamento o disjuntor reseta sozinho, ou um operador aprova a retomada no dashboard. O estado é compartilhado entre as instâncias do portão, então o orçamento se mantém independentemente de qual instância serve a chamada.

Dá para exportar e verificar a cadeia de auditoria?

Sim. A auditoria de deploy exporta como documento, e a cadeia é verificável de ponta a ponta: cada registro carrega o hash anterior e a posição, a cadeia é assinada, e o dashboard declara se ela está válida ou comprometida. Ela é estruturada sobre o Art. 73 do GDPR, então um pedido de acesso do titular de dados mapeia em um único artefato.

O que eu recebo no plano gratuito?

O dashboard completo, com dados de exemplo claramente rotulados, para você aprender a forma do plano de controle. A aplicação ao vivo, o disjuntor e a parada de emergência estão nos planos pagos, e o AI Briefing é um recurso pago. Prefiro ser o fornecedor que diz isso em um post do que o que faz você descobrir na página de preços.

O plano de controle é o produto

O vão entre a demo de agente e o agente que você deixaria agir enquanto dorme não é o modelo. É o plano de controle. Doze superfícies, oito que contam e quatro que decidem, assentando em tokens com escopo, um cofre selado, um ledger encadeado, e uma camada de iscas que contém o dano antes de você. Toda chamada ganha um comprovante, e o comprovante responde quem, o quê e quanto, na ordem que um regulador, um time financeiro ou um chamado às 3 da manhã faria.

Se os seus agentes já agem sobre os seus sistemas, a pergunta não é mais se você dá conta de governança. É se você dá conta do dia em que descobrir que não tinha.

Para uma conta mais profunda de como o Vinkius construiu o runtime que torna essa governança possível para agentes de IA, veja Agentes de IA são os novos consumidores.

As doze superfícies de governança definidas aqui são aplicadas com código-fonte e números de linha em Perguntas sobre AI Empresarial.