Um prompt melhor pode melhorar uma resposta.

Não consegue, por si só, definir uma fronteira operacional.

Esta diferença torna-se crítica quando um sistema de IA deixa de ser apenas um assistente e passa a agir. A partir do momento em que um agente consegue chamar ferramentas, alterar estado, gastar dinheiro, abrir pull requests, mudar configuração, criar artefactos ou acionar outro agente, a organização precisa de algo mais forte do que texto a pedir ao modelo para ter cuidado.

Este é o quinto artigo da série de dez partes AI Governance in an AI-Native Software Development Company. O artigo 4, The Executable Policy Layer, mostrou que a governação só se torna real quando a política chega ao caminho de execução. Este artigo aproxima a fronteira do próprio agente: o que pode fazer exatamente, em que condições, com que ferramentas e o que deve acontecer quando essas condições não são satisfeitas?

A resposta é um contrato.

Os prompts exprimem intenção. Os contratos vinculam comportamento.

Um prompt não é uma fronteira de controlo

Os prompts são úteis porque são flexíveis.

É também por isso que são fracos como contratos.

Um prompt pode dizer:

“Revê este deployment com cuidado. Não faças alterações arriscadas. Pede aprovação quando for necessário.”

Uma pessoa consegue inferir muita coisa a partir desta frase. Um agente tem de reconstruir as regras em falta em cada execução.

O que conta como risco?

Que ambiente está dentro do âmbito permitido?

Que ferramentas pode chamar?

Que evidência deve existir antes de aprovar?

Quanto pode gastar?

O que deve fazer quando a evidência está incompleta?

Quem pode autorizar uma exceção?

Que formato de output deve receber o sistema seguinte?

O que acontece se o modelo, o schema de uma ferramenta ou o runtime mudar?

O prompt não responde a estas perguntas. Apenas aponta para elas.

Pode ser suficiente para um assistente de baixo risco. Não é suficiente para um sistema com autoridade.

No fim, o runtime ganha sempre.

Independentemente da intenção do prompt, o comportamento real é definido pelas capacidades que o runtime expõe e pelas fronteiras que efetivamente aplica.

A stack do contrato

Uma separação útil é:

  • os prompts exprimem intenção
  • os ficheiros de instruções fornecem contexto
  • skills e regras definem o contrato de trabalho
  • os pontos de enforcement tornam o contrato vinculativo
  • a verificação em runtime produz atestação
  • a evidência e a recusa criam o registo

Os nomes podem variar entre plataformas. A separação das responsabilidades não deve variar.

Um prompt pode dizer o que o agente deve tentar alcançar.

Um contrato diz o que o agente pode fazer enquanto tenta chegar lá.

Essa é a diferença entre orientação e autoridade.

O que deve existir num contrato de agente?

Um contrato de agente não precisa de começar como um enorme schema de governação.

Precisa de tornar explícitas as suposições escondidas.

Na prática, um contrato útil cobre pelo menos estas dimensões.

Identidade e ownership

Cada agente ou capacidade em produção precisa de identidade estável, versão e responsável.

Deve ser possível responder:

  • que agente está a agir
  • que capability bundle está ativo
  • quem é o owner do contrato
  • quando foi aprovado
  • quando expira ou precisa de revisão

Um agente sem identidade clara que usa uma service account partilhada já é difícil de governar.

Objetivo e não-objetivos

Defina o que o agente existe para fazer e aquilo que explicitamente não faz.

“Ajudar com deployments” é vago.

“Avaliar evidência de deployment do serviço X e recomendar allow, deny ou human review; nunca executar deployment em produção” é um contrato.

Os não-objetivos são importantes porque a autonomia tende a expandir-se através da ambiguidade.

Âmbito de ferramentas e recursos

Liste as ferramentas que o agente pode chamar e os recursos que essas ferramentas podem alcançar.

O contrato deve distinguir:

  • leitura e escrita
  • desenvolvimento, staging e produção
  • um repositório e todos os repositórios
  • um tenant e todos os tenants
  • observação e mutação

Uma ferramenta existir no runtime não deve significar automaticamente que o agente tem autorização para a usar.

Inputs e pré-condições

Defina o que tem de ser verdadeiro antes da capacidade correr.

Exemplos:

  • campos obrigatórios do pedido
  • evidência necessária
  • versão de política exigida
  • delegação humana válida
  • estado necessário do ambiente
  • idade máxima da informação recuperada

Se faltar uma pré-condição, o sistema deve saber se deve recusar, adiar ou escalar.

Outputs e pós-condições

Os sistemas downstream não devem ter de adivinhar o que o agente quis dizer.

O contrato deve definir:

  • schema de output
  • referências de evidência obrigatórias
  • campos de incerteza quando fizer sentido
  • estados de decisão permitidos
  • efeitos laterais esperados
  • condições que devem continuar verdadeiras depois da execução

Texto natural pode continuar a fazer parte do output. A parte relevante para a máquina não deve depender apenas da interpretação de prosa.

Risco, blast radius e budgets

O contrato deve dizer quanta autoridade a capacidade pode exercer.

Isto vai além de permissions.

Fronteiras úteis incluem:

  • classe máxima de ação
  • blast radius máximo
  • budget financeiro
  • budget de tokens
  • budget de tempo ou número de passos
  • limite de concorrência
  • envelope de rate limit

É no contrato que “até onde é que isto pode ir?” recebe uma resposta explícita.

Recusa e escalada

Recusar não é necessariamente uma falha do modelo.

Num sistema governado, pode ser o resultado correto.

O contrato deve definir quando o agente tem de parar, quando pode degradar de forma controlada, quando precisa de pedir aprovação e quando deve colocar o output em quarentena em vez de o enviar para o caminho live.

Se o comportamento de recusa não estiver especificado, o agente é forçado a improvisar precisamente no momento em que a organização mais precisa de comportamento previsível.

Evidência

Cada ação material deve deixar evidência suficiente para reconstruir porque aconteceu.

O contrato pode exigir:

  • inputs consultados
  • referências de conhecimento ou fontes
  • tool calls
  • versão de política
  • versão do contrato
  • razão da decisão
  • aprovações
  • exceções
  • efeitos laterais resultantes

É aqui que o comportamento do agente se torna auditável em vez de anedótico.

Os prompts são lidos. Os registos têm de poder ser provados.

Um contrato pode ser pequeno

A primeira versão pode ser deliberadamente simples.

Por exemplo:

~~~yaml agent_contract: id: deployment-reviewer version: 3 purpose: review deployment evidence

allowed_tools:

  • read_repository
  • read_ci_results
  • read_runtime_health

forbidden_actions:

  • deploy_production
  • modify_secrets

preconditions:

  • deployment_evidence_present
  • active_policy_version_present

outputs: schema: deployment_review_v2 allowed_decisions:

  • allow
  • deny
  • require_approval

escalation: when:

  • evidence_incomplete
  • blast_radius_above_medium

evidence: required:

  • sources_used
  • policy_version
  • contract_version
  • decision_reason

~~~

A sintaxe não é o ponto principal.

A mudança importante é que as suposições ficaram visíveis, testáveis e versionáveis.

Uma equipa pode rever este artefacto.

Um pipeline pode validá-lo.

O runtime pode aplicar partes dele.

Um sistema de avaliação pode testar o comportamento contra o contrato.

Um reviewer de incidente pode perguntar que versão estava ativa.

Isto já é muito mais forte do que “tem cuidado”.

Skills não são contratos por si só

As plataformas modernas de agentes estão cada vez mais a empacotar capacidades como skills, regras, ficheiros de instruções, manifests ou tool bundles.

É um progresso útil.

Mas uma skill que descreve como executar uma tarefa não é automaticamente um contrato de governação.

Uma skill pode explicar como fazer deployment de um serviço.

O contrato ainda tem de responder:

  • este agente pode fazer deployment deste serviço
  • em que ambiente
  • sob delegação de quem
  • com que evidência
  • dentro de que blast radius
  • com que budget
  • com que versão da skill
  • com que requisito de rollback ou containment

A mesma skill pode ser segura para um agente e inadequada para outro.

A mesma ferramenta pode ser aceitável em staging e proibida em produção.

A mesma intenção pode ser permitida num contexto normal e exigir aprovação durante um incidente.

Capacidade e autoridade são coisas diferentes.

Uma regra útil:

Uma skill diz ao agente como. Um contrato diz ao sistema se pode, onde e em que condições.

O contrato tem de sobreviver ao drift do runtime

Mesmo um bom contrato perde valor se a superfície de comportamento mudar por baixo dele sem controlo.

O comportamento de um agente pode mudar quando muda:

  • o modelo
  • o system prompt
  • o ficheiro de instruções
  • a skill
  • o schema da ferramenta
  • a permission
  • o routing
  • a fonte de retrieval
  • o policy bundle
  • o runtime host

Por isso o contrato tem de estar ligado a versões, não a nomes que podem mudar silenciosamente.

“Usa o coding agent” não chega.

“Usa capability bundle 4.7 sob contract 3.2 e policy bundle 12” é governável.

O contrato não existe para congelar o sistema para sempre.

Cria um ponto onde a mudança se torna visível.

Quando um upgrade de modelo ou skill altera comportamento, o capability bundle muda. O contrato pode ser reavaliado, testado e aprovado novamente.

Sem esta disciplina, o contrato torna-se documentação de um sistema que já não existe.

Verificação em runtime é a outra metade

Escrever o contrato não chega.

O sistema precisa de verificar que a execução ficou dentro dele.

Essa verificação pode incluir controlos determinísticos:

  • apenas ferramentas autorizadas foram chamadas
  • recursos proibidos não foram alterados
  • a evidência obrigatória estava presente
  • os budgets foram respeitados
  • o output correspondeu ao schema exigido
  • houve escalada quando o threshold foi ultrapassado

Também pode incluir avaliação comportamental quando os checks determinísticos não bastam.

O ponto essencial é que o resultado se torne uma atestação ligada ao execution trace.

A pergunta útil não é apenas:

“O agente terminou?”

É:

“O agente terminou dentro do contrato?”

Essa é uma definição muito mais forte de sucesso.

A recusa faz parte do produto

As equipas de agentes tendem a otimizar fortemente completion rate.

Isso cria pressão para tratar recusas e escaladas como falhas.

A governação precisa de outra perspetiva.

Um agente bem desenhado deve recusar quando:

  • falta evidência obrigatória
  • a autoridade pedida excede o seu âmbito
  • o caller não tem delegação válida
  • a ação ultrapassaria o limite de blast radius
  • o budget acabou
  • o estado da política é ambíguo
  • o runtime não consegue provar que um controlo obrigatório está ativo

Uma recusa com uma razão estruturada não é output morto.

É um resultado governado.

O mesmo vale para “require approval”, “defer” e “quarantine”.

Quando estes estados existem explicitamente no contrato, o sistema consegue encaminhá-los sem obrigar o modelo a inventar recuperação no momento.

O contrato deve ser testável

Se uma cláusula do contrato não consegue gerar um teste, provavelmente continua demasiado vaga.

Para cada cláusula importante, pergunte que evidência provaria conformidade.

Se o contrato diz que o agente não pode fazer deployment em produção, disponibilize a ferramenta de deployment num teste e confirme que o runtime a bloqueia.

Se o contrato exige escalada acima de um threshold de blast radius, teste essa fronteira.

Se o output tem de incluir referências de evidência, rejeite outputs sem essas referências.

Se um budget deve parar o workflow, leve o agente até ao limite num ambiente não produtivo e observe o resultado.

O contrato ganha valor quando fica ligado à avaliação.

Caso contrário, é apenas mais um documento destinado a ficar desatualizado.

Ordem prática de construção

Não comece por desenhar uma linguagem de contratos para toda a empresa.

Comece por uma capacidade real.

1. Escolha um agente que consiga causar um efeito lateral

Assistentes read-only são úteis, mas escondem as perguntas mais difíceis de governação.

Escolha uma capacidade que consiga alterar estado, gastar dinheiro, abrir uma PR, mudar configuração ou acionar deployment.

2. Escreva o menor contrato explícito possível

Defina identidade, objetivo, não-objetivos, ferramentas, recursos, pré-condições, outputs, limite de risco, recusa, escalada e evidência.

Mantenha o contrato suficientemente pequeno para a equipa responsável o conseguir rever de verdade.

3. Ligue o contrato às versões

Fixe o modelo, prompt, skills, ferramentas, policy bundle e pressupostos de runtime que alteram materialmente o comportamento.

Trate alterações nesses elementos como alterações da capacidade.

4. Aplique as fronteiras duras fora do modelo

Não peça ao modelo para policiar as suas próprias permissions de maior risco.

O runtime deve bloquear ações que excedam o contrato.

5. Emita evidência do contrato

Associe a versão do contrato e os principais sinais de conformidade ao mesmo trace da ação.

A execução tem de ser reconstruível.

6. Teste recusa e escalada

Não avalie apenas o happy path.

Force ausência de evidência, excesso de âmbito, pressão de budget e ambiguidade de política.

Confirme que o sistema falha exatamente da forma definida pelo contrato.

7. Reveja contratos como artefactos operacionais

Os contratos devem ter owner, versões, datas de revisão e um caminho de retirada.

Fazem parte do ciclo de produção.

Conclusão

O prompt não vai desaparecer.

Está apenas a regressar ao lugar certo.

Prompts são excelentes para expressar objetivos, contexto, tom, estratégia e raciocínio flexível.

São fracos substitutos para fronteiras de autoridade.

Uma organização AI-native precisa dos dois.

O prompt diz o que a pessoa quer.

O contrato diz ao sistema o que o agente pode fazer enquanto tenta atingir esse objetivo.

A camada de enforcement torna o contrato real.

A evidência do runtime mostra se foi respeitado.

E a recusa dá ao sistema uma forma legítima de parar quando as condições do contrato não são cumpridas.

A progressão é:

intenção -> contrato -> enforcement -> atestação -> evidência.

O contrato está a tornar-se uma especificação comportamental executável entre pessoas, agentes e ferramentas.

Não porque os agentes precisem de mais burocracia.

Mas porque autonomia sem contrato é interpretação sem limites com acesso a ferramentas.

O próximo artigo parte de uma hipótese desconfortável: o agente irá, por vezes, atuar fora do contrato na mesma.

É aí que começa o containment.

Próximo artigo: AI Governance Fails Without Containment.

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