A maioria dos programas de governação falha no mesmo ponto.

A policy é escrita. É aprovada. É publicada. Depois o runtime toma uma decisão sem nunca a ter avaliado.

Esse é o handoff que a governação nunca faz.

Uma policy pode estar perfeitamente escrita, revista juridicamente e ser tecnicamente sólida, e mesmo assim não governar nada se o execution path não a conseguir avaliar antes de um agente agir.

Este é o quarto artigo da série de dez partes AI Governance in an AI-Native Software Development Company. O artigo 3, Porque é que a maioria das equipas fica pelos controlos de ação, descreveu os sistemas Knowledge, Execution e Evaluation que tornam operacionais as camadas mais profundas. Este artigo entra na fronteira seguinte: transformar policy em comportamento de runtime.

Se a policy termina na documentação, não existe governação de IA. Existe formatação.

O gap da aplicação manual

A maioria das organizações já tem policies.

Existem acceptable-use rules, requisitos de data handling, approval matrices, controlos de acesso a produção, security standards e procedimentos de escalation. O problema não é falta de intenção.

O problema é tradução.

Uma pessoa consegue ler uma regra como «alterações em produção que afetem customer data exigem aprovação do service owner» e interpretá-la no contexto. Não é seguro esperar que um agente reconstrua essa interpretação a partir de prose em cada ação.

A mesma regra pode depender de factos de runtime:

  • que agente está a agir
  • que capability version está ativa
  • que utilizador delegou o pedido
  • que tool está a ser chamado
  • se a ação é read-only ou altera estado
  • qual é o ambiente alvo
  • qual é a classificação dos dados
  • qual é o blast radius possível
  • quanto budget resta
  • se existe uma exception ativa
  • que policy version está em vigor

Esses factos mudam de pedido para pedido.

Uma página wiki não os avalia.

Um system prompt não os enforce.

Uma fila de aprovação humana não escala para todas as ações de baixo risco quando os agentes operam continuamente.

É por isso que a governação morre antes do runtime. A organização tem policy intent, mas não tem uma fronteira de decisão executável entre intenção e side effect.

O que significa realmente Executable Policy

Executable Policy não significa converter todo o manual de governação em código.

Significa identificar as regras que têm de alterar o comportamento da máquina e representá-las de forma que o runtime as possa avaliar consistentemente.

Uma policy executável útil tem sete propriedades.

Externa ao modelo. O modelo pode propor uma ação, mas não deve ser a autoridade final que decide se ela é permitida.

Estruturada. A decisão opera sobre atributos explícitos e intenção tipada, não sobre um parágrafo que o modelo precisa de reinterpretar.

State-aware. A mesma intenção pode ser aceitável em staging e proibida em produção. Pode ser allow com muito budget disponível e exigir approval quando o budget está quase esgotado.

Versionada. Cada decisão deve poder ser atribuída à versão exata de policy que a produziu.

Determinística onde a fronteira exige. Um modelo probabilístico pode planear. Uma hard permission boundary não deve depender da confiança do modelo.

Enforceable. Um verdict deny tem de impedir realmente o tool call ou a alteração de estado.

Com evidência. O sistema deve registar o que foi avaliado, qual regra fez match, qual foi o verdict e o que aconteceu depois.

O objetivo não é tornar todas as decisões de governação determinísticas. Muitas decisões de negócio continuam a precisar de julgamento.

O objetivo é tornar explícita a enforcement boundary.

Probabilistic reasoning pode propor. Deterministic control decide o que pode realmente acontecer.

A arquitetura de Runtime Policy

A arquitetura é mais simples do que a linguagem de governance costuma sugerir.

Um fluxo útil:

request -> structured intent -> policy decision -> enforcement -> action -> evidence

O agente ou a orchestration layer transforma primeiro a ação pretendida em dados estruturados. O Policy Decision Point avalia essa intenção contra identity, scope, environment, runtime state e o policy bundle ativo. O Policy Enforcement Point aplica o verdict antes de acontecer o side effect.

A decisão não deve devolver apenas sim ou não.

Verdicts úteis incluem:

  • allow: prosseguir dentro do scope aprovado
  • deny: bloquear a ação com uma razão estruturada
  • require approval: pausar até aprovação por uma autoridade definida
  • defer: não executar agora porque falta uma condição runtime
  • degrade: prosseguir por um caminho de menor risco ou custo quando a policy permite
  • quarantine: produzir o artefacto mas mantê-lo fora do live path até review

A terminologia pode variar. O importante é que o comportamento de cada verdict esteja definido antes do incidente.

Um verdict que existe apenas em logs não é enforcement.

O que o Decision Point precisa de saber

Um policy evaluator só é tão bom quanto o estado que consegue observar.

Para ações materiais de agentes são normalmente necessários vários grupos de atributos.

Identity e delegation

  • agent identity
  • capability identity e version
  • humano ou service que pediu
  • delegated authority
  • expiry e scope da delegation

Action

  • tool pedido
  • operation
  • target resource
  • side effect esperado
  • data classes lidas ou escritas

Environment

  • development, staging ou production
  • tenant ou customer scope
  • region
  • service criticality

Risk e autonomy

  • action class
  • autonomy tier
  • blast radius máximo
  • evidence level exigido
  • requisitos de human approval

Runtime state

  • cost e token budget restante
  • time ou step budget restante
  • rate-limit headroom
  • estado de incident ou maintenance
  • sinais recentes de refusal ou anomaly

Governance state

  • policy bundle ativo
  • exception records
  • expiry times
  • required controls
  • owner da policy

É por isso que runtime governance não pode viver apenas num prompt. O prompt não possui todo este estado de forma fiável e, mesmo que o veja, não deve poder dispensar a sua própria fronteira.

Prompts não são Permission Boundaries

Uma implementação comum começa com uma instrução:

«Não faças deploy para production sem approval.»

A instrução é útil. Não é um enforcement mechanism.

O modelo pode interpretá-la mal. Outro prompt pode entrar em conflito. Um tool pode expor um caminho que a contorna. Retrieved content pode manipular o agente. Uma atualização do host pode alterar a precedência das instruções.

Nenhum desses eventos deve transformar uma production boundary numa sugestão.

A separação correta é:

  • prompts e skills orientam comportamento
  • tools expõem capacidades
  • policy decide se uma capability pode ser usada no contexto atual
  • enforcement impede side effects não autorizados

Esta separação facilita também os testes.

É possível avaliar se o modelo normalmente respeita a instrução.

Separadamente, é possível provar que o runtime bloqueia uma ação proibida mesmo quando o modelo não respeita a instrução.

São garantias diferentes, e a governação precisa das duas.

Policy tem de existir em mais do que um Gate

Runtime é a última enforcement boundary, mas não deve ser o primeiro lugar onde a policy aparece.

Um sistema maduro reutiliza policy ao longo do delivery lifecycle.

Authoring

A policy deve influenciar o que o agente pode propor.

Um coding agent deve saber que não pode adicionar uma dependência não aprovada, aceder a um restricted data domain ou alterar um production secret path. Feedback cedo reduz trabalho desperdiçado.

Pull Request e CI

O pipeline deve avaliar policy machine-checkable antes do merge.

Architecture boundaries, dependency restrictions, evidence requirements, security controls e required reviewers pertencem aqui.

Deployment

A policy deve decidir se o artefacto pode entrar num ambiente.

Risk classification, test evidence, rollout strategy, owner approval e rollback readiness podem ser inputs.

Runtime

O runtime avalia a ação concreta contra o estado atual.

É aqui que identity, target, budget, environment, tool, exception e live conditions convergem.

A policy language não tem de ser idêntica em todas as layers, mas o policy model tem de ser coerente.

Se authoring proíbe uma ação e runtime a permite, existe um policy conflict.

Se runtime bloqueia algo que CI aprovou, a evidência deve explicar qual estado mudou.

Behavior é uma Deployment Surface

A policy também tem de reconhecer que código não é a única coisa que altera comportamento.

Num agentic system, todos estes elementos podem mudar production behavior:

  • model version
  • system prompt
  • instruction files
  • skills
  • rules
  • tool schemas
  • tool permissions
  • routing logic
  • retrieval configuration
  • knowledge sources
  • policy bundles
  • runtime host version

Um model swap muda comportamento.

Uma skill update muda comportamento.

Uma nova tool permission muda comportamento.

Um policy bundle muda comportamento.

Se o comportamento mudou, alguma coisa foi deployed.

Por isso os próprios policy artifacts precisam de release discipline.

Precisam de versions, owners, tests, promotion stages, rollback e traceability.

Uma policy change que altera runtime behavior é uma production change.

Skills, Rules e Instructions são Artifacts, não o sistema de Governance

Os frameworks de agentes expõem cada vez mais objetos chamados skills, rules, instructions, guardrails ou policies.

São úteis porque transformam human intent em guidance consumível pela máquina.

Mas chamar «policy» a uma instruction não a transforma numa enforcement boundary.

A pergunta útil não é:

«Temos um rules file?»

As perguntas úteis são:

  • quem é o owner
  • está versionado
  • como é testado
  • o agente pode ignorá-lo
  • um tool pode fazer bypass
  • runtime avalia-o antes do side effect
  • deny pára realmente a execução
  • conseguimos provar que version estava ativa
  • podemos fazer rollback

Skills, rules, agent instructions e tool constraints fazem parte da behavior surface.

Governance é o operating system à volta destes artefactos.

Exceptions têm de ser First-Class

Todo o policy system sério precisa de exceptions.

O erro é tratá-las como overrides informais.

«Dá acesso temporário para este incident» vira uma mensagem no Slack.

«Permite este tool para a migration» vira uma alteração de config.

«Salta a approval desta vez» vira um bypass impossível de explicar mais tarde.

Uma governed exception deve ser um objeto explícito com:

  • requester
  • approver
  • reason
  • policy afetada
  • scope exato
  • start time
  • expiry time
  • allowed action class
  • evidence requirements
  • revocation path

A exception deve ser mais estreita do que a regra que substitui.

Deve expirar automaticamente.

O runtime deve avaliá-la como qualquer outro policy input.

Uma exception sem expiry é uma policy change disfarçada de temporária.

Policy Changes precisam de Progressive Delivery

Uma má runtime policy pode quebrar production tão depressa como mau código.

Uma deny rule demasiado ampla pode parar workflows críticos.

Uma condição em falta pode permitir uma ação perigosa.

Um threshold alterado pode inundar humanos com approvals.

Por isso policy não deve passar diretamente de authoring para full enforcement.

Uma sequência mais segura:

  1. test com cenários conhecidos
  2. replay sobre traces recentes
  3. shadow da nova policy sem enforcement
  4. compare verdicts antigo e novo
  5. canary enforcement num scope limitado
  6. promote quando a evidência é aceitável
  7. rollback se refusal, escalation ou incident signals piorarem

É progressive delivery aplicado à governação.

Mudou o artefacto, não o princípio de engenharia.

Cada Verdict deve deixar Evidence

Policy sem evidence cria outra forma de mistério.

O runtime deve emitir um decision record compacto para ações materiais.

Um record útil inclui:

  • root trace ID
  • policy decision ID
  • agent e capability identity
  • structured intent
  • state attributes relevantes
  • policy bundle e version
  • matched rule ou reason
  • verdict
  • enforcement result
  • human approval reference quando aplicável
  • exception reference quando aplicável
  • timestamp

Não é preciso registar todo o contexto.

Registe o suficiente para reconstruir porque a ação foi allowed, blocked ou escalated.

A evidence deve ligar-se ao mesmo trace model usado para execution e change.

Assim um incident reviewer passa de:

«O que aconteceu?»

para:

«Que policy permitiu esta ação, sob que estado e porquê?»

É uma pergunta muito melhor.

Failure Modes repetem-se

Quando executable policy está em falta, os erros são familiares.

Policy-in-a-wiki. A regra existe e todos concordam, mas o runtime nunca a lê.

Policy-in-a-prompt. A regra existe, mas o mesmo sistema constrained é responsável por a interpretar e obedecer.

Split enforcement. Um tool verifica policy e outro caminho chega ao mesmo side effect sem check.

Stale state. A decisão é logicamente correta contra estado incompleto ou desatualizado.

Silent exception. Um override existe sem owner, expiry ou trace.

Mutable policy. Uma regra muda in-place e ninguém consegue provar que version governou a decisão de ontem.

Evidence-free deny. O sistema bloqueia trabalho mas não explica qual rule disparou.

Evidence-free allow. A ação sucede mas ninguém consegue provar porque foi autorizada.

O padrão é simples.

A policy existia como intenção.

Não existia como controlo executável.

Ordem prática de construção

Não comece por codificar todo o governance manual.

Escolha um action path importante e torne o controlo real.

1. Definir Structured Intent

Escolha uma ação material como deploy, escrever customer data, rodar um secret ou invocar um production tool.

Represente a ação com typed fields, não com prose.

2. Colocar o Policy Decision Point fora do Model

O modelo propõe.

O evaluator decide.

Mantenha a enforcement authority fora do componente probabilístico.

3. Colocar um Enforcement Point antes do Side Effect

Um deny tem de impedir execução.

Não dependa de cooperative refusal.

4. Adicionar o mínimo Runtime State

Identity, action, target, environment, autonomy tier, budget state, policy version e exception state chegam para começar.

Adicione atributos quando uma decisão real precisar deles.

5. Emitir Decision Evidence

Dê um ID a cada verdict material e ligue-o ao execution trace.

Allow, deny e approval devem ser explicáveis.

6. Versionar e testar o Policy Bundle

Execute deterministic policy tests e replay de traces recentes.

Trate o bundle como production artifact.

7. Shadow, Canary e Promote

Observe o que a nova policy faria antes de controlar tudo.

Faça rollout progressivo e mantenha o rollback simples.

Esta ordem é deliberadamente pequena.

O objetivo não é construir um império de policies.

O objetivo é estabelecer um handoff fiável entre governance intent e runtime behavior, e depois expandi-lo.

Conclusão

A parte mais difícil de AI Governance não é escrever a regra.

É fazer a regra sobreviver ao contacto com execution.

Policies, princípios, review boards e approval matrices importam. Mas só se tornam governação quando o sistema as consegue avaliar contra a ação que está prestes a acontecer, enforce o verdict e preservar a evidência.

Essa é a Executable Policy Layer.

Fica entre probabilistic behavior e side effects reais.

Dá voz ao runtime state.

Torna exceptions visíveis.

Torna policy changes deployable e reversible.

E permite à organização responder à pergunta que importa durante um incident:

«Porque é que esta ação foi autorizada?»

Se a resposta for «porque instruímos o agente a comportar-se bem», a policy layer ainda falta.

Se a resposta aponta para uma regra versionada, avaliada contra estado registado, enforced antes do side effect e ligada a uma trace, a governação finalmente chegou ao runtime.

Governance não é o que a policy diz. É o que o runtime consegue enforce e provar.

O próximo artigo aproxima-se ainda mais do agente: prompts são demasiado vagos para transportar toda a relação entre humanos, agents e tools.

Próxima parte: AI Agents Need Contracts, Not Better Prompts.

Publicado originalmente por Reza Arani no Medium em 18 de maio de 2026. Adaptado para Aipolix como quarta parte da série AI Governance in an AI-Native Software Development Company.