Este artigo é a décima e última parte da série AI Governance in an AI-Native Software Development Company.

É fácil sobrestimar a maturidade da governação porque documentos são mais visíveis do que o comportamento real do sistema. Uma política, um comité, um registo ou um processo de revisão podem ser úteis, mas não provam que um agente será realmente limitado, parado, atribuído ou recuperado quando o sistema estiver sob pressão.

O teste mais útil é simples: o que consegue o runtime demonstrar sem a equipa ter de explicar aquilo que pretendia fazer?

O modelo tem seis etapas, de Experimental a Autopilotado. Cada etapa é definida por evidência operacional e não por intenção.

Etapa 0: Experimental

Os agentes já estão a ser usados, mas a governação ainda não é tratada como um problema organizacional.

As ferramentas espalham-se por adoção individual. Não existe inventário fiável, responsável claro ou resposta comum a perguntas básicas sobre acesso a dados de produção e responsabilidade por alterações produzidas por agentes.

Passar à Etapa 1 é sobretudo uma mudança organizacional: alguém tem de nomear o problema, assumir a responsabilidade e tornar a utilização de IA visível.

Etapa 1: Ad hoc

A governação existe em conversas, não no sistema.

As regras aparecem em mensagens, comentários de revisão e páginas internas. As decisões dependem das pessoas presentes. A organização pode reagir bem a um incidente isolado sem conseguir reproduzir a mesma decisão entre equipas.

O passo seguinte é transformar conhecimento implícito num inventário e numa política operacional explícita.

Etapa 2: Documentado

A organização consegue descrever os agentes, skills e ferramentas que possui e as regras que espera que cumpram.

As políticas são escritas, têm owner e versão. As equipas dispõem de standards para acesso a dados, aprovações, gestão de mudança e utilização permitida.

Mas esta etapa cria um falso teto frequente: a documentação pode amadurecer enquanto o runtime permanece igual.

A passagem à Etapa 3 exige que a política se torne um artefacto avaliável pela máquina e que a aplicação das regras exista nos pontos onde o comportamento pode realmente ser alterado.

Etapa 3: Aplicado

A política faz parte da execução.

Contratos e artefactos de política são versionados. Existem gates na authoring, CI, deployment e runtime. Ações sensíveis podem ser recusadas ou escaladas. Mecanismos de stop, scope e recovery são testados. Alterações importantes podem ser rastreadas desde a intenção até ao efeito em produção.

A pergunta passa de “temos controlos?” para “os controlos funcionam bem?”.

Etapa 4: Medido

O próprio sistema de governação é observável.

A equipa acompanha bloqueios, falsos bloqueios, falsos allow, duração de exceções, tempo de containment, atribuição de incidentes e custo das ações governadas.

A mesma pergunta de auditoria deve produzir o mesmo tipo de evidência no trimestre seguinte, sem nova reconstrução manual.

A Etapa 4 pode ser um destino legítimo. Uma fleet estável e um blast radius limitado podem não justificar automatizar decisões rotineiras de governação.

Etapa 5: Autopilotado

As decisões rotineiras de governação são executadas automaticamente contra artefactos assinados e versionados. As pessoas concentram-se em exceções, riscos novos e evolução de políticas.

Novos agentes herdam controlos por deployment. As exceções expiram automaticamente. Drift conhecido pode ativar respostas predefinidas. A capacidade de governação pode crescer sem que a equipa cresça ao mesmo ritmo da fleet.

Não existe uma Etapa 6 útil chamada “sem humanos”. O autopilot muda o ponto de intervenção humana; não elimina responsabilidade.

O teto da documentação e a inflação de maturidade

O erro mais comum é medir maturidade pela atividade visível.

Uma equipa pode ter documentação excelente e continuar na Etapa 2 se uma violação de política não for realmente bloqueada. Pode ter dashboard e continuar abaixo da Etapa 4 se o dashboard medir apenas adoção.

Uma regra prática mais rigorosa é: a etapa real é a etapa mais alta cujas capacidades críticas podem ser demonstradas de ponta a ponta no runtime.

Um controlo em falta num caminho de alto risco importa mais do que vários controlos bem apresentados em caminhos de baixo risco.

A maturidade deve ser proporcional ao risco

A Etapa 5 não é o destino de todas as organizações.

O nível necessário depende do blast radius. Um assistente interno sem acesso a dados sensíveis ou produção não necessita da mesma profundidade de controlo que um agente que altera sistemas de clientes, dados regulados ou movimenta dinheiro.

A melhor pergunta de planeamento é: qual é a etapa de maturidade mais baixa que mantém este risco específico defensável?

Governar em excesso uma superfície de baixo risco desperdiça engenharia. Governar de menos uma superfície crítica cria exposição.

Medir adoção, enforcement e outcomes em conjunto

São necessárias três camadas de métricas.

Adoção mostra alcance: agentes registados, equipas onboarded, skills publicadas e cobertura de políticas.

Enforcement mostra se os controlos executam: policy evaluations, taxa de bloqueio, false block, false allow, expiração de exceções, ações de containment e tempo para conter.

Outcomes mostram se o risco operacional mudou: taxa e severidade de incidentes, latência de respostas de auditoria, custo por ação governada, temas recorrentes de postmortem e tempo entre uma alteração feita por agente e o seu efeito em produção com provenance preservada.

Adoção sem enforcement é documentação. Enforcement sem outcomes é processo. As três camadas em conjunto mostram se a governação está realmente a melhorar o sistema operacional.

Uma disciplina semelhante a DORA para agentes

A entrega de software melhorou quando as equipas aprenderam a ler throughput e stability em conjunto. A governação de agentes precisa do mesmo hábito.

Mais alterações produzidas por agentes não são automaticamente progresso se a taxa de falha subir. Execução mais rápida não significa maior maturidade se provenance, containment ou compliance piorarem.

Throughput sem stability é exposição mais rápida.

Runtime Verification Probes

Questionários favorecem autoavaliação otimista. Probes pedem evidência ao sistema.

  • Provenance probe: escolher uma alteração recente e rastrear agente, modelo, versão da política e intenção autorizadora.
  • Containment probe: parar um agente real num ambiente seguro e provar que o stop ocorreu dentro do limite esperado.
  • Calibration probe: mostrar a tendência recente de false block e false allow por política.
  • Honesty probe: mostrar uma métrica desconfortável e a ação tomada por causa dela.
  • Autopilot probe: mostrar uma decisão rotineira executada automaticamente contra artefactos assinados, com evidência.

Uma etapa que não sobrevive ao respetivo probe continua a ser uma aspiração.

Como usar o modelo na segunda-feira

  1. Execute os probes e escolha a etapa que o runtime consegue realmente provar.
  2. Identifique a capacidade em falta com maior risco.
  3. Escolha um controlo concreto que feche essa lacuna.
  4. Defina um owner, um prazo e um artefacto demonstrável.
  5. Escolha uma métrica de enforcement ou outcome.
  6. Repita o probe da etapa seguinte no fim do ciclo.

O objetivo não é subir a escada por si só. É tornar a próxima decisão de governação mais demonstrável, repetível e defensável.

Fecho da série

Os dez artigos descrevem uma única arquitetura.

Identity diz o que está a agir. Contracts limitam o que pode fazer. Executable Policy transforma intenção em decisão de runtime. Containment limita o blast radius. Traceability liga intenção a efeito. Change Management trata alterações de capability como alterações de produção. Budgets limitam custo, tokens, capability e tempo. Measurement mostra se o conjunto funciona.

Maturidade faz a pergunta final: quanto desta arquitetura consegue o seu runtime provar hoje?

Um controlo que não pode ser demonstrado acaba por regressar a documentação. Uma organização AI-native madura força regularmente o runtime a provar que os seus controlos continuam reais.

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