🤖 AI

From Governance Norms to Enforceable Controls: A Layered Translation Method for Runtime Guardrails in Agentic AI

Este artigo propõe um método de tradução em camadas que conecta objetivos de governança derivados de padrões internacionais a quatro camadas de controle (objetivos, restrições de projeto, mediação em tempo de execução e feedback de garantia), distinguindo claramente entre diretrizes de governança e guardrails executáveis para sistemas de IA autônoma.

Autores originais: Christopher Koch

Publicado 2026-04-08

📖 5 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Christopher Koch

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine que você contratou um assistente virtual superinteligente (uma IA Agente) para gerenciar as compras da sua empresa. Esse assistente não apenas responde perguntas; ele navega na internet, compara preços, negocia com fornecedores e até assina contratos sozinho.

O problema é: e se esse assistente, passo a passo, parecer inofensivo, mas no final do dia comprar 10.000 unidades de um produto que ninguém precisa, gastando todo o orçamento da empresa?

É aqui que entra o artigo "De Normas de Governança para Controles Executáveis". O autor, Christopher Koch, explica que as regras atuais de segurança (como as normas ISO e o NIST) são como leis de trânsito: elas dizem o que devemos fazer (dirigir com segurança, não beber), mas não explicam como construir o freio de emergência do carro para que ele pare sozinho se o motorista ficar tonto.

Aqui está a explicação simplificada, usando analogias do dia a dia:

1. O Problema: Leis vs. Freios de Emergência

As normas de governança de IA são documentos grandes e importantes. Eles dizem: "Seja justo", "Proteja os dados", "Tenha responsabilidade".

O erro comum: As empresas tentam transformar essas leis complexas diretamente em "freios automáticos" para a IA.
A realidade: Nem toda lei pode virar um freio automático. Você não pode programar um carro para "ser justo" se a definição de justiça depende de um julgamento humano complexo. Tentar fazer isso cria sistemas que travam ou ignoram as regras.

2. A Solução: O Método de "Camadas" (Tradução)

O autor propõe um método para traduzir essas leis vagas em ações práticas, dividindo a segurança em 4 camadas, como se fosse um castelo medieval:

Camada 1: A Arquitetura (O Muro do Castelo)
- Analogia: Antes de deixar o cavaleiro entrar, você decide que ele só pode andar no pátio interno, não no celeiro dos cavalos.
- Na prática: Limitar o que a IA pode fazer antes mesmo dela começar. Se ela é um agente de compras, ela não deve ter senha para acessar o servidor de RH. Isso é feito no design, não durante a execução.
Camada 2: O Design (O Manual de Instruções)
- Analogia: Definir que o cavaleiro só pode usar a espada para defender, nunca para atacar o rei.
- Na prática: Criar regras claras sobre como a IA deve se comportar e quais ferramentas ela pode usar.
Camada 3: O Runtime (O Guarda-Costas no Local)
- Analogia: É aqui que o guarda está de olho. Se o cavaleiro tentar pular o muro, o guarda o segura na hora.
- Na prática: São os "guardrails" (travas de segurança) que funcionam em tempo real. Eles só devem ser usados para coisas óbvias e rápidas.
- Exemplo: "Se o valor da compra for maior que 5.000 euros, pare e peça aprovação humana." Isso é fácil de medir e bloquear na hora.
Camada 4: A Garantia (O Juiz e o Arquivo)
- Analogia: Depois da batalha, o juiz revisa os registros para ver se as regras foram seguidas e pune quem errou.
- Na prática: Gravar tudo, auditar depois e ter humanos revisando decisões complexas que a máquina não consegue julgar sozinha (como "ser justo").

3. A Regra de Ouro: "O que pode ser parado na hora?"

O artigo introduz um critério simples para decidir se uma regra deve ser um "freio automático" (Runtime) ou um "julgamento posterior" (Garantia):

Use o Freio Automático (Runtime) se:
- O erro é visível antes de acontecer (ex: tentar acessar um arquivo proibido).
- A regra é clara e matemática (ex: "não passar de 5.000 euros").
- Parar a ação agora evita um desastre irreversível.
Use o Julgamento Humano (Garantia) se:
- A regra é subjetiva (ex: "ser justo" ou "ser ético").
- Você precisa de contexto que só aparece depois.
- Tentar bloquear automaticamente poderia atrapalhar o trabalho útil.

4. O Exemplo Prático: O Agente de Compras

O autor usa um exemplo de um agente que faz compras:

Regra: "Só comprar de fornecedores aprovados."
- Solução: Freio Automático. O sistema verifica a lista de aprovados antes de deixar a compra acontecer. É fácil e rápido.
Regra: "A classificação de fornecedores deve ser justa."
- Solução: NÃO é um freio automático. "Justo" é difícil de definir em código. A solução é deixar o agente fazer a classificação, mas ter um humano revisando o resultado depois e auditando se houve viés.

Conclusão Simples

O artigo diz: Não tente transformar todas as leis da empresa em robôs que vigiam a IA 24 horas.

Em vez disso, use uma abordagem em camadas:

Projetar a IA para que ela não tenha acesso ao que não precisa.
Bloquear automaticamente apenas o que é óbvio e perigoso (como gastar muito dinheiro).
Deixar humanos julgarem o que é complexo e subjetivo.
Gravar tudo para provar depois que tudo foi feito corretamente.

É como dirigir um carro: você tem o cinto de segurança (design), o freio ABS (runtime para emergências claras), e você confia no seu julgamento para decidir quando fazer uma ultrapassagem arriscada (humano), tudo enquanto o painel registra sua velocidade (auditoria).

Título: De Normas de Governança a Controles Executáveis: Um Método de Tradição em Camadas para Guardrails de Runtime em IA Agêntica

1. O Problema

Os sistemas de IA Agêntica diferem fundamentalmente dos modelos generativos tradicionais (como LLMs de turno único). Enquanto estes últimos podem ser avaliados principalmente em nível de prompts e saídas, os agentes:

Planejam tarefas, utilizam ferramentas, mantêm estado e coordenam com serviços externos.
Geram trajetórias de ação de múltiplos passos com efeitos externos.
Apresentam riscos que emergem durante a execução (runtime), e não apenas no desenvolvimento ou implantação.

Existe uma lacuna crítica entre as normas de governança existentes (como ISO/IEC 42001, ISO/IEC 23894, ISO/IEC 42005, ISO/IEC 5338, ISO/IEC 38507 e o NIST AI RMF) e a implementação prática de guardrails executáveis.

A Falha: As normas fornecem intenção de governança, estrutura de risco e baselines de responsabilidade, mas não definem linguagens de política, esquemas de ação ou modelos de execução.
O Risco: Tentar compilar diretamente essas normas em guardrails de runtime leva a um "deslocamento de camada" (control-layer misplacement). Alguns requisitos (como justiça ou aceitabilidade humana) exigem julgamento contextual que não pode ser reduzido a regras determinísticas de execução sem simplificação normativa perigosa.

2. Metodologia Proposta

O artigo propõe um método de tradução em camadas para conectar objetivos de governança derivados de padrões a quatro camadas de controle distintas. O método é intencionalmente leve para servir como ferramenta de revisão de design.

A. Distinção de Artefatos

O método separa quatro conceitos frequentemente confundidos:

Objetivo de Governança: Meta normativa (ex: responsabilidade, menor privilégio).
Controle Técnico: Mecanismo para operacionalizar o objetivo (ex: credenciais escopadas, logs).
Guardrail de Runtime: Subconjunto de controles que intervêm durante a execução (permitir, negar, atrasar, escalar ou reescrever ações).
Evidência de Garantia: Artefatos para demonstrar o que os controles fizeram (logs, atestados, trilhas de auditoria).

B. As 5 Etapas do Método

Extrair o Objetivo Normativo: Identificar a declaração derivada de padrões (ex: "garantir que o acesso seja autorizado e auditável").
Normalizar em uma Tupla de Controle ( $\kappa$ ): Reescrever o controle candidato em uma estrutura formal:
$\kappa = \langle a, x, r, \phi, \delta, \epsilon, o \rangle$
Onde:
- $a$ : Agente principal (quem age).
- $x$ : Classe de ação.
- $r$ : Recurso protegido ou efeito externo.
- $\phi$ : Pré-condição ou contexto relevante.
- $\delta$ : Decisão de controle (permitir, negar, escalar, logar, reescrever).
- $\epsilon$ : Artefato de evidência a ser produzido.
- $o$ : Proprietário responsável.
Avaliar a Aplicabilidade em Runtime (Rubrica): Utilizar uma tabela de critérios para decidir se um controle deve ser executado em tempo real. Critérios de alta aplicabilidade incluem:
- O dano deve ser prevenido antes da execução.
- O estado e contexto são observáveis por máquina.
- A regra é determinística (não requer interpretação aberta).
- O erro é difícil de reverter (intervenção urgente necessária).
- A evidência é clara e atribuível.
Atribuir a Camada Primária de Controle:
- Camada de Governança: Intenção normativa e exceções.
- Camada de Design-time: Arquitetura, escopagem de privilégios, limites de sandbox.
- Camada de Runtime: Validação de ação, políticas, gateways de aprovação.
- Camada de Garantia: Telemetria, auditorias, monitoramento de deriva.
- Escalada Humana: O destino padrão para decisões ambíguas, de alto impacto ou baixa determinabilidade.
Especificar Evidência e Propriedade: Todo controle traduzido deve nomear o artefato de evidência e o proprietário responsável.

3. Contribuições Principais

Distinção Conceitual: Clarifica a diferença entre objetivos de governança, controles técnicos, guardrails de runtime e evidências de garantia, evitando a confusão entre intenção normativa e mecanismo técnico.
Método de Tradução: Introduz uma estrutura prática baseada em tuplas de controle e uma rubrica de aplicabilidade em runtime para atribuir controles às camadas corretas da arquitetura.
Estudo de Caso Aplicado: Demonstra o método em um agente de compras corporativo, mostrando como requisitos complexos são mapeados para camadas específicas (design, runtime, garantia).
Agenda de Avaliação: Define critérios para avaliar a eficácia da tradução, incluindo fidelidade da política, qualidade da intervenção, cobertura de trajetória e trade-off segurança-utilidade.

4. Resultados e Estudo de Caso (Agente de Compras)

O estudo de caso de um agente de compras ilustra a aplicação do método:

Requisitos de Alta Aplicabilidade em Runtime:
- Apenas fornecedores aprovados: Controlado via lista de permissões (allowlist) no runtime, pois o estado é observável e a regra é determinística.
- Aprovação humana para valores > €5.000: Gate de aprovação no runtime com verificação de limite.
Requisitos de Baixa Aplicabilidade em Runtime (Não devem ser guardrails puros):
- Classificação de fornecedores justa e contestável: Não pode ser codificada como uma regra determinística pré-execução. Deve ser tratada no Design-time (design do algoritmo) e na Camada de Garantia (auditoria periódica e revisão humana de exceções).
Conclusão do Caso: Guardrails de runtime funcionam melhor quando o escopo de design (ex: credenciais de menor privilégio) já restringiu o espaço de ação.

5. Significado e Implicações

Reavaliação do Papel dos Padrões: O artigo argumenta que padrões como ISO e NIST não devem ser compilados diretamente em código de guardrail. Eles devem guiar a colocação dos controles na arquitetura (design, runtime, humano, auditoria).
Foco na Intervenção Correta: Guardrails de runtime devem ser reservados apenas para controles que são observáveis, determinísticos e sensíveis ao tempo, onde a intervenção antes do dano é justificada.
Segurança Holística: A segurança de agentes não é resolvida apenas por filtros de runtime. Requer uma abordagem em camadas que inclui isolamento de rede, design de fluxo de trabalho humano e garantia contínua.
Limitação Reconhecida: O método não é uma prova formal de conformidade, mas uma ferramenta de design para traduzir intenção em controles executáveis, reconhecendo que leis setoriais e julgamento humano permanecem indispensáveis.

Em suma, o artigo oferece uma estrutura pragmática para organizações que buscam implementar governança de IA agêntica, evitando a armadilha de tentar automatizar tudo o que é normativo e focando a automação de runtime onde ela é tecnicamente viável e segura.