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

A política é escrita. É aprovada. É publicada. Depois o tempo de execução toma uma decisão sem nunca a ter avaliado.

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

Uma política 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 Governação da IA numa empresa de desenvolvimento de software nativa de IA. O artigo 3, Porque é que a maioria das equipas fica pelos controlos de ação, descreveu os sistemas de conhecimento, execução e avaliação que tornam operacionais as camadas mais profundas da governação. Este artigo aborda a fronteira seguinte: transformar a política em comportamento durante a execução.

Se a política 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 políticas.

Existem acceptable-use rules, requisitos de data handling, aprovação 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 responsável» 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 tempo de execução:

  • que agente está a agir
  • que capacidade version está ativa
  • que utilizador delegou o pedido
  • que ferramenta está a ser chamado
  • se a ação é só de leitura ou altera estado
  • qual é o ambiente alvo
  • qual é a classificação dos dados
  • qual é o alcance das consequências possível
  • quanto budget resta
  • se existe uma exception ativa
  • que versão das regras está em vigor

Esses factos mudam de pedido para pedido.

Uma página wiki não os avalia.

Um system instrução 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 tempo de execução. A organização tem política intent, mas não tem uma fronteira de decisão executável entre intenção e efeito secundário.

O que significa realmente Regras executáveis

Regras executáveis 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 tempo de execução as possa avaliar consistentemente.

Uma política 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.

Sensível ao estado. 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 aprovação quando o budget está quase esgotado.

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

Controlo determinístico na fronteira. Um modelo probabilístico pode planear. Uma restrição rígida de permissões não deve depender da confiança do modelo.

Enforceable. Um verdict deny tem de impedir realmente o chamada de ferramenta 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 ponto de controlo.

O raciocínio probabilístico pode propor. O controlo determinístico decide o que pode realmente acontecer.

A arquitetura de Tempo de execução Política

A arquitetura é mais simples do que a linguagem de governação costuma sugerir.

Um fluxo útil:

pedido -> structured intent -> decisão baseada nas regras -> aplicação -> action -> evidência

O agente ou a orchestration layer transforma primeiro a ação pretendida em dados estruturados. O Ponto de decisão sobre as regras avalia essa intenção contra identidade, âmbito, environment, tempo de execução state e o conjunto de regras ativo. O Ponto de aplicação das decisões aplica o verdict antes de acontecer o efeito secundário.

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

Verdicts úteis incluem:

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

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 é aplicação.

O que o Decision Point precisa de saber

Um motor de avaliação das regras 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.

Identidade e delegation

  • agent identidade
  • capacidade identidade e version
  • humano ou service que pediu
  • delegated authority
  • expiry e âmbito da delegation

Action

  • ferramenta pedido
  • operation
  • target resource
  • efeito secundário esperado
  • data classes lidas ou escritas

Environment

  • development, staging ou production
  • tenant ou customer âmbito
  • region
  • service criticality

Risk e autonomy

  • action class
  • autonomy tier
  • alcance das consequências máximo
  • evidência level exigido
  • requisitos de aprovação humana

Tempo de execução 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

Governação state

  • conjunto de regras ativo
  • exception records
  • expiry times
  • required controls
  • responsável da política

É por isso que tempo de execução governação não pode viver apenas num instrução. O instrução 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.

Instruções não são Permissão Limites

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

«Não faças colocação em produção para production sem aprovação.»

A instrução é útil. Não é um mecanismo de controlo.

O modelo pode interpretá-la mal. Outro instrução pode entrar em conflito. Um ferramenta 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 limite numa sugestão.

A separação correta é:

  • instruções e capacidades especializadas orientam comportamento
  • ferramentas expõem capacidades
  • política decide se uma capacidade pode ser usada no contexto atual
  • aplicação impede efeitos secundários 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 tempo de execução 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.

Política tem de existir em mais do que um Ponto de controlo

Tempo de execução é a última ponto de controlo, mas não deve ser o primeiro lugar onde a política aparece.

Um sistema maduro reutiliza política ao longo do ciclo de entrega.

Authoring

A política 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.

Pedido de integração e CI

O canal de entrega deve avaliar política verificável automaticamente antes do merge.

Architecture limites, dependency restrictions, evidência requirements, security controls e required reviewers pertencem aqui.

Implantação

A política deve decidir se o artefacto pode entrar num ambiente.

Risk classification, test evidência, lançamento progressivo strategy, responsável aprovação e reversão readiness podem ser entradas.

Tempo de execução

O tempo de execução avalia a ação concreta contra o estado atual.

É aqui que identidade, target, budget, environment, ferramenta, exception e live conditions convergem.

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

Se authoring proíbe uma ação e tempo de execução a permite, existe um política conflict.

Se tempo de execução bloqueia algo que CI aprovou, a evidência deve explicar qual estado mudou.

Comportamento é uma Implantação Surface

A política 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 comportamento:

  • model version
  • system instrução
  • instruction files
  • capacidades especializadas
  • rules
  • ferramenta schemas
  • ferramenta permissões
  • encaminhamento logic
  • retrieval configuration
  • knowledge sources
  • política bundles
  • tempo de execução host version

Um model swap muda comportamento.

Uma capacidade especializada update muda comportamento.

Uma nova ferramenta permissão muda comportamento.

Um conjunto de regras muda comportamento.

Se o comportamento mudou, alguma coisa foi deployed.

Por isso os próprios política artefactos precisam de lançamento discipline.

Precisam de versions, responsáveis, tests, promotion stages, reversão e traceability.

Uma alteração às regras que altera tempo de execução comportamento é uma alteração em produção.

Capacidades especializadas, Rules e Instructions são Artefactos, não o sistema de Governação

Os frameworks de agentes expõem cada vez mais objetos chamados capacidades especializadas, rules, instructions, proteções ou políticas.

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

Mas chamar «política» a uma instruction não a transforma numa ponto de controlo.

A pergunta útil não é:

«Temos um rules file?»

As perguntas úteis são:

  • quem é o responsável
  • está versionado
  • como é testado
  • o agente pode ignorá-lo
  • um ferramenta pode fazer bypass
  • tempo de execução avalia-o antes do efeito secundário
  • deny pára realmente a execução
  • conseguimos provar que version estava ativa
  • podemos fazer reversão

Capacidades especializadas, rules, agent instructions e ferramenta constraints fazem parte da comportamento surface.

Governação é o operating system à volta destes artefactos.

Exceptions têm de ser De primeira ordem

Todo o sistema de regras 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 ferramenta para a migration» vira uma alteração de config.

«Salta a aprovação desta vez» vira um bypass impossível de explicar mais tarde.

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

  • requester
  • approver
  • reason
  • política afetada
  • âmbito exato
  • start time
  • expiry time
  • allowed action class
  • evidência requirements
  • revocation path

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

Deve expirar automaticamente.

O tempo de execução deve avaliá-la como qualquer outro política entrada.

Uma exception sem expiry é uma alteração às regras disfarçada de temporária.

Alterações às regras precisam de Progressive Delivery

Uma má tempo de execução política pode quebrar production tão depressa como mau código.

Uma deny rule demasiado ampla pode parar fluxos de trabalho críticos.

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

Um threshold alterado pode inundar humanos com aprovações.

Por isso política não deve passar diretamente de authoring para aplicação integral.

Uma sequência mais segura:

  1. test com cenários conhecidos
  2. replay sobre traces recentes
  3. observar sem aplicar da nova política sem aplicação
  4. compare verdicts antigo e novo
  5. lançamento-piloto aplicação num âmbito limitado
  6. promote quando a evidência é aceitável
  7. reversão 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 Evidência

Política sem evidência cria outra forma de mistério.

O tempo de execução deve emitir um decision record compacto para ações materiais.

Um record útil inclui:

  • root trace ID
  • decisão baseada nas regras ID
  • agent e capacidade identidade
  • structured intent
  • state attributes relevantes
  • conjunto de regras e version
  • matched rule ou reason
  • verdict
  • resultado da aplicação
  • aprovação humana 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 evidência deve ligar-se ao mesmo trace model usado para execution e change.

O responsável pela análise do incidente pode então passar de:

«O que aconteceu?»

para:

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

É uma pergunta muito melhor.

Failure Modes repetem-se

Quando regras executáveis está em falta, os erros são familiares.

The policy-in-a-wiki failure: A regra existe e é consensual, mas nenhum componente do sistema a consulta quando a ação vai ser executada.

The policy-in-a-prompt failure: A regra está presente, mas o mesmo sistema que deve ser limitado também é responsável por a interpretar e cumprir.

The split enforcement failure: Uma ferramenta verifica a regra, enquanto outro caminho permite obter o mesmo efeito sem essa verificação.

The stale-state failure: A decisão é coerente, mas assenta num estado incompleto ou desatualizado.

The silent exception failure: Existe uma derrogação sem responsável, prazo ou rasto.

The mutable policy failure: Uma regra é modificada diretamente, pelo que ninguém consegue provar qual versão regia a decisão do dia anterior.

The evidence-free deny: O sistema impede o trabalho sem explicar qual regra foi aplicada, criando pressão para contornar o controlo.

The evidence-free allow: A ação é concluída, mas ninguém consegue demonstrar porque foi autorizada.

O padrão é simples.

A política existia como intenção.

Não existia como controlo executável.

Ordem prática de construção

Não comece por codificar todo o governação manual.

Escolha um action path importante e torne o controlo real.

1. Definir Structured Intent

Escolha uma ação material como colocação em produção, escrever customer data, rodar um secret ou invocar um production ferramenta.

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

2. Colocar o Ponto de decisão sobre as regras fora do Model

O modelo propõe.

O evaluator decide.

Mantenha a aplicação authority fora do componente probabilístico.

3. Colocar um Ponto de controlo antes do Efeito secundário

Um deny tem de impedir execução.

Não dependa de cooperative refusal.

4. Adicionar o mínimo Tempo de execução State

Identidade, action, target, environment, autonomy tier, budget state, versão das regras e exception state chegam para começar.

Adicione atributos quando uma decisão real precisar deles.

5. Emitir Decision Evidência

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

Allow, deny e aprovação devem ser explicáveis.

6. Versionar e testar o Conjunto de regras

Execute deterministic política tests e replay de traces recentes.

Trate o bundle como production artefacto.

7. Observar sem aplicar, Lançamento-piloto e Promote

Observe o que a nova política faria antes de controlar tudo.

Faça lançamento progressivo progressivo e mantenha o reversão simples.

Esta ordem é deliberadamente pequena.

O objetivo não é construir um império de políticas.

O objetivo é estabelecer um handoff fiável entre governação intent e tempo de execução comportamento, e depois expandi-lo.

Conclusão

A parte mais difícil da governação de IA não é escrever a regra.

É fazer a regra sobreviver ao contacto com execution.

Políticas, princípios, revisão boards e aprovação 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 Regras executáveis Layer.

Fica entre probabilistic comportamento e efeitos secundários reais.

Dá voz ao tempo de execução state.

Torna exceptions visíveis.

Torna alterações às regras 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 camada de regras ainda falta.

Se a resposta aponta para uma regra versionada, avaliada contra estado registado, enforced antes do efeito secundário e ligada a uma trace, a governação finalmente chegou ao tempo de execução.

Governação não é o que a política diz. É o que o tempo de execução consegue enforce e provar.

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

Próxima parte: AI Agents Need Contracts, Not Better Instruções.

Publicado originalmente por Reza Arani no Medium em 18 de maio de 2026. Adaptado para a Aipolix como quarta parte da série sobre governação da IA numa empresa de desenvolvimento de software nativa de IA.