A governança de IA está migrando do modelo para o runtime

Por muito tempo, "governança de IA" significou basicamente uma pergunta: qual modelo estamos autorizados a usar. Três papers recentes sobre agentes multiagente mostram que essa pergunta já não cobre onde o risco realmente mora. O risco migrou para o runtime - para o que acontece depois que o modelo já decidiu agir.

O argumento central: comportamento emergente não cabe em controle pré-deploy

O paper MI9, sobre governança de runtime para sistemas de IA agentic, parte de uma constatação simples: agentes que raciocinam, planejam e agem de forma autônoma exibem "comportamentos emergentes e inesperados durante a execução" que não podem ser totalmente antecipados só com governança pré-deployment. Um modelo aprovado em avaliação estática pode, em produção, encadear ferramentas, memória e contexto de um jeito que nenhum teste pré-lançamento simulou.

Seis mecanismos para vigiar o que acontece em tempo real

A resposta proposta pelo MI9 não é mais controle sobre o modelo - é instrumentação do runtime. O framework integra seis mecanismos: um índice de risco de agência (quantifica o nível de ameaça ligado à autonomia do agente), captura de telemetria semântica do agente, monitoramento contínuo de autorização (não uma checagem única no início da sessão), motores de conformidade baseados em máquina de estados finitos, detecção de desvio condicionado a objetivo, e estratégias de contenção graduais. Cada um desses seis é, na prática, uma resposta a uma pergunta que "qual modelo usar" nunca fez: o que o agente está fazendo agora, com quais ferramentas, com que permissões, e isso ainda bate com o objetivo original?

Autorização não é um evento único - é um estado que muda

O paper sobre falhas de "confused deputy" em LLMs agentic ataca diretamente o ponto mais frágil dessa migração: autorização. Um agente que recebe permissão para uma tarefa pode, em passos seguintes, ser manipulado a usar essa mesma permissão para uma ação que o usuário nunca autorizou - o clássico problema do "confused deputy", agora em escala agentic. A resposta testada nesse paper (ScopeGate) trata autorização como algo que precisa ser recomputado a cada chamada de ferramenta, não concedido uma vez e esquecido.

O custo de errar para o lado seguro também é real

O paper "The Containment Gap" mostra o outro lado dessa equação: sistemas de contenção mal calibrados não só falham em bloquear ações perigosas - também bloqueiam, em excesso, ações legítimas, com uma taxa de negação indevida que compromete a utilidade do agente. Isso muda o problema de governança: não é só "impedir o agente de fazer algo ruim", é fazer isso sem destruir a razão de o agente existir. Memory poisoning - memória de sessão contaminada por instruções maliciosas que persistem além da sessão original - é outro vetor que só aparece em runtime, nunca em avaliação de modelo isolado.

O que muda na prática para quem está implantando agentes

A convergência dessas três fontes aponta para o mesmo lugar: times de plataforma que hoje têm um processo de aprovação de modelo, mas nenhum processo de monitoramento contínuo de ferramentas, memória e permissões durante a execução, estão protegendo a porta errada. A pergunta que a governança de 2026 precisa responder não é mais "este modelo é seguro", é "o que este agente pode fazer agora, com o que ele tem acesso agora, e alguém está olhando para isso enquanto acontece".

Fontes

• Arxiv - Runtime Governance in Multi-Agent Systems - https://arxiv.org/abs/2508.03858
• Arxiv - The Containment Gap - https://arxiv.org/abs/2606.12797
• Arxiv - Authorization Confused Deputy Failures in Agentic LLMs - https://arxiv.org/abs/2606.28679