Governança Verificável para IA Agêntica: De Princípios Consultivos a Watchdogs em Runtime

A lacuna de governança em IA agêntica é estrutural, não filosófica. A maioria da governança de IA — princípios, códigos de ética, model cards, frameworks consultivos — descreve como a IA deveria comportar-se. Nada disso impede a IA de fazer outra coisa quando ninguém está a olhar. Para modelos preditivos sem efeitos secundários no mundo real, essa lacuna é tolerável. Para agentes que actuam via tool calls — a enviar emails, executar trades, modificar dados de produção, gastar dinheiro — não é.

O paper recente Verifiable Governance Architecture (VGA) for Organisations and Teams with Human and AI Employees (Fradelos, janeiro 2026) nomeia esta lacuna directamente: "muitos princípios de governança são consultivos, enquanto os agentes modernos actuam via tool calls com consequências no mundo real." Depois propõe um padrão de engenharia para a fechar: um Watchdog em runtime que medeia as tool calls com semântica fail-close (default-deny), governança codificada como policy-as-code (OPA/Rego), e um evidence store imutável que impede a IA de alucinar a sua própria conformidade.

Este é o padrão de design que o campo precisa há algum tempo. Vale a pena entendê-lo em detalhe porque as escolhas são não-óbvias e os modos de falha das alternativas mais fracas são reais.

A Ideia Central: Fronteiras de Acção, Não Comportamento Médio

Três abordagens de governança dominam a prática actual:

1. Guardrails de prompt: adicionar instruções de segurança ao system prompt.
2. Supervisão de modelo de recompensa: treinar modelos para recusar certas acções.
3. Supervisão de processo: inserir revisores humanos nos pontos de decisão.

Os três melhoram o comportamento médio. Nenhum deles, por si só, fornece garantias de fronteira de acção para ferramentas irreversíveis.

Esta é a ideia que faz seguir o resto do padrão. Um agente que foi treinado para "não exfiltrar dados de cliente" não exfiltrará dados de cliente em média. Pode exfiltrar dados de cliente em condições adversariais, em distribuições de prompt incomuns, em sequências de tool call que ninguém antecipou, ou simplesmente porque a distribuição de treino não cobria o cenário específico. Melhorias médias não são garantias de segurança para acções irreversíveis.

O padrão VGA parte da postura oposta: não tentes tornar o agente fiavelmente bom. Faz com que as acções que o agente pode tomar sejam constrangidas por algo que o agente não consiga contornar.

O Watchdog

O Watchdog é a camada de runtime que medeia cada tool call antes que chegue à ferramenta. Cada acção que o agente quer tomar passa por ele. O Watchdog tem três propriedades que o distinguem de alternativas mais laxas:

Fail-close (default-deny)

Se o Watchdog não puder verificar positivamente que uma acção é permitida, a acção é negada. Isto é o oposto da maioria dos padrões de guardrail em produção, que são fail-open por defeito — se a regra não der match, a acção procede.

Fail-close não é negociável para IA agêntica especificamente porque o modo de falha de fail-open é "o agente fez algo que ninguém autorizou quando a política não antecipava o caso". Fail-close significa que o modo de falha é "o agente parou e perguntou", que é recuperável.

Medeia a superfície de ferramentas, não a superfície do modelo

O Watchdog não se senta entre o utilizador e o modelo. Senta-se entre o modelo e as ferramentas. Isto importa porque o raciocínio do modelo, o conteúdo do prompt e as saídas intermédias estão todos em scope para a moderação de conteúdo, mas não são a fronteira de acção. A fronteira de acção é a tool call. Pôr o Watchdog na superfície de ferramentas significa que a política aplicada é a política que realmente importa.

Autorização multi-parte para acções sensíveis

Algumas acções requerem mais do que um aprovador. O Watchdog pode expressá-lo naturalmente: uma tool call para "transferir >10k$" requer um evidence packet assinado tanto pelo agente como por um aprovador humano antes que a chamada proceda. Uma tool call para "modificar o esquema da base de dados de produção" requer um pipeline CI/CD que executou as verificações de segurança da migração. A arquitectura é a mesma; a política varia por sensibilidade.

A Matriz MVV: Ligar Leis a Artefactos Verificáveis

A segunda ideia central é a matriz de Verificação Mínima Viável (MVV). Liga cada regra de governança a um artefacto específico verificável e a uma cadência específica em que esse artefacto deve ser produzido.

Sem MVV, as regras de governança tornam-se aspiracionais. "O sistema deve ser auditável" soa bem e não verifica nada. Com MVV, "o sistema deve ser auditável" traduz-se em artefactos específicos:

• Um log imutável de cada tool call com a decisão de política anexada.
• Um evidence packet assinado a ligar intenção → tool call → resultado.
• Um relatório de atestação semanal de um auditor designado.
• Uma revisão externa trimestral com cenários red-team.

Cada artefacto tem um produtor, formato e cadência definidos. A verificação da conformidade reduz-se a "o artefacto foi produzido a tempo, no formato certo, com assinaturas válidas?" — que é algo que um pipeline CI/CD pode verificar.

Isto é o que "governança-como-código" significa realmente na prática. Não são apenas políticas em Rego. É a evidência verificável da aplicação de políticas, produzida pelo runtime, em calendário, em formatos que um regulador poderia auditar.

Porque o Evidence Store Tem de Ser Imutável

A escolha de design mais subtil é o evidence store imutável. O Watchdog produz um registo de cada decisão; esse registo vai para um store que o próprio agente não pode modificar nem retro-datar.

A razão é o que o paper chama de alucinações de governança: o modo de falha onde o agente produz um relatório de conformidade com aparência plausível que não corresponde ao que realmente aconteceu. Se o evidence store é modificável por qualquer coisa ao alcance do agente, o agente (deliberadamente ou como comportamento emergente) pode produzir evidência de conformidade que não reflecte as acções tomadas.

A correcção é estrutural: a conformidade depende do evidence store, o evidence store é modificável apenas pelo Watchdog, o Watchdog está fora da superfície de ferramentas do agente. Mesmo que o agente produza um resumo de conformidade perfeito, a auditoria pode compará-lo com o store imutável e detectar a divergência.

Este é o mesmo princípio que separar a autoridade de escrita da base de dados do código de aplicação em qualquer sistema sério de produção. A novidade é aplicá-lo à evidência de governança de IA.

Direitos de Decisão Dependentes de Antiguidade

A quarta ideia é operacionalmente importante: os agentes têm antiguidade. Um agente "júnior" tem acesso a ferramentas estreito e requer autorização multi-parte para a maioria das acções não triviais. Um agente "profissional" tem acesso mais amplo. Um agente "sénior" pode autorizar acções de scope mais estreito em nome de outros.

Isto soa como o controlo de acesso empresarial porque é. O ponto é aplicá-lo especificamente a agentes de IA, com o mesmo rigor e auditabilidade que o controlo de acesso baseado em papéis humanos. Na prática isto significa:

• Os agentes novos começam como júniores com acesso a ferramentas constrangido. Ganham (ou são configurados para) scope mais amplo apenas após passarem verificação específica.
• O acesso a ferramentas é a fronteira, não "o treino do modelo" ou "o system prompt". Dois agentes a usar o mesmo modelo podem ter direitos de decisão muito diferentes consoante as suas políticas de acesso.
• As promoções são explícitas e auditadas. Quando um agente passa de scope profissional a sénior, a mudança é registada, a evidência é retida, o rollback é directo.

Esta é a parte que a maioria dos sistemas agênticos em produção em 2026 ainda erra. Têm um único papel de agente com todas as ferramentas, e a fronteira é um system prompt. O padrão de antiguidade é uma representação mais honesta do que é realmente necessário.

Mapeamento para Regimes de Conformidade Reais

O padrão é explicitamente desenhado para mapear nas obrigações de manutenção de registos e robustez do EU AI Act. O evidence store satisfaz a manutenção de registos. O Watchdog fail-close satisfaz a robustez. A matriz MVV satisfaz os requisitos de auditabilidade. A autorização multi-parte satisfaz os requisitos de supervisão humana para sistemas de alto risco.

Isto não é acidental. A arquitectura é desenhada para que a conformidade se torne uma propriedade dos artefactos produzidos, não uma questão de "o agente comportou-se bem". Esta é a única maneira durável de cumprir regulamentos que requerem evidência em vez de confiança.

O Que Significa Se Estás a Construir Sistemas Agênticos Agora

Acções práticas para qualquer equipa que entrega IA agêntica em 2026:

1. Move a aplicação de políticas para a superfície de ferramentas. Se os teus guardrails vivem no system prompt, tens governança consultiva. Põe um mediador fail-close entre o modelo e as ferramentas.

2. Adopta policy-as-code. OPA/Rego é a escolha mais madura; a ferramenta específica importa menos do que a disciplina. As políticas em código podem ser revistas, versionadas, testadas em CI e auditadas. As políticas em prompts não.

3. Constrói o evidence store antes de escalar. Um log imutável e assinado de acções de agente é muito mais difícil de retrofitar do que desenhar de início. Mesmo que ainda não precises da auditoria, o valor de debugging operacional sozinho justifica o custo.

4. Aplica antiguidade aos agentes. Os agentes novos obtêm scope estreito. A expansão de scope é explícita, auditada e reversível. Não corras todos os teus agentes ao mesmo nível de autorização.

5. Executa autorização multi-parte em acções irreversíveis. Qualquer coisa financeira, qualquer coisa que toque em dados de cliente, qualquer coisa que modifique produção. O custo de performance da autorização multi-parte é muito menor do que o custo de uma má acção.

O Que VGA Não Faz

Dois limites honestos valem a pena nomear.

Não torna o modelo melhor. VGA limita o que o agente pode fazer; não muda quão bem o agente raciocina dentro desses limites. Melhorar o comportamento do modelo continua a ser importante — mas é agora um problema de optimização dentro de limites de segurança conhecidos, não o mecanismo de segurança em si.

Custa latência. Cada tool call passa por avaliação de política. Com bundles OPA bem afinados isto são milissegundos, mas não é zero. Para caminhos sensíveis à latência, terás de engenhar com cuidado — tipicamente com decisões em cache para caminhos quentes e avaliação por pedido para os sensíveis.

O custo é real. O custo de não o ter é muito mais alto, e aparece como manchetes.

A mudança de governança consultiva para verificável para IA agêntica está a acontecer; a única questão é se a tua organização está à frente ou atrás da curva. O padrão de arquitectura está aqui. Adoptá-lo já não é um projecto de investigação.

---

Fonte: Fradelos, G. Verifiable Governance Architecture (VGA) for Organisations and Teams with Human and AI Employees (Genebra, 9 de janeiro de 2026). SSRN 6306840.

A construir sistemas agênticos e precisas de capacidade de engenharia que já constrói com policy-as-code, watchdogs fail-close e evidence stores imutáveis? Fala com um CTO sobre desplegar um squad nearshore com a disciplina certa para governança de IA verificável.