Modelo operacional de governação de IA: cinco partes em funcionamento

O que faz o nosso modelo operacional de governação de IA

Um modelo operacional de governação de IA é um sistema de direitos de decisão, responsáveis, escalamento, pontos de aprovação no fluxo de trabalho e revisões que decide o que os agentes de IA fazem sozinhos e o que espera por uma pessoa. O nosso governa agentes que agem: fazem a triagem de pedidos, escrevem código, redigem guias e despacham trabalho para outros agentes. Não é uma política de chatbot para a equipa nem uma lista de ferramentas aprovadas.

A governação de agentes não é uma comissão. São cinco coisas escritas onde o agente as lê antes de agir, e cada uma é um artefacto que pode abrir:

Corremos as cinco partes no ConvOps(abre num novo separador), que guarda as tarefas, os responsáveis, os pontos de aprovação, as notas e os agendamentos. Este guia faz parte de Loops We Run; o guia principal mostra quem decide o quê em toda a empresa.

Os exemplos usam a Copperfern, uma loja online fictícia de artigos para a casa, e a Maya, que gere as operações. Os nomes e os números são inventados; os nomes dos campos, os formatos das notas, as regras e os limiares são os reais.

Cinco partes, cinco artefactos: os direitos de decisão são uma lista de exclusões, o responsável é um nome na tarefa, o escalamento é uma nota tipificada, um ponto de aprovação é uma aprovação dentro do fluxo de trabalho, a revisão é um agendamento.

Porque é que as regras vivem dentro do fluxo de trabalho

Um documento de políticas governa as pessoas que o leem. Um agente só obedece ao que está dentro do seu fluxo de trabalho, por isso é aí que cada regra tem de viver.

Os nossos agentes começaram a fazer trabalho real: encaminhar, construir, publicar, despachar. As regras viviam numa conversa de chat e na cabeça de uma pessoa. Um agente a meio de uma execução não volta a ler uma página de políticas. Quando um trabalho descarrilava, ninguém sabia dizer que agente tinha tomado a decisão, com que motivo, nem onde devia ter parado.

Por isso, levámos cada regra para o ponto onde o agente age. A lista do que um agente nunca pode assumir passou para o passo que escolhe o trabalho. Cada aprovação tornou-se um ponto de aprovação que a execução não ultrapassa sem um sim. Cada decisão de um agente deixa agora um motivo de uma linha na tarefa. A governação é uma camada do percurso mais amplo do modelo operacional de IA.

Veja como o ConvOps coloca o ponto de aprovação dentro do fluxo de trabalho, não num ficheiro de políticas(abre num novo separador).

Como funciona

O trabalho entre pontos de aprovação corre sem nós. É nos pontos de aprovação que pomos a nossa atenção, e em mais lado nenhum.

Cada regra tem um motivo. O agente de triagem nunca muda o tipo de um trabalho para iniciativa, ou de iniciativa para outro tipo, sem o sim do operador, porque o âmbito é uma decisão de uma pessoa. Um lote de despacho tem de 1 a 10 tarefas, 5 por omissão, porque um lote pequeno mantém cada revisão genuína. A consulta de candidatos pede o triplo desse máximo, para que as exclusões ainda deixem uma lista completa.

Um agente só trava e pergunta quando é preciso juízo a sério: acesso à produção ou dados de produção, valores secretos ou rotação de credenciais, gastos, publicação para o público, alterações de âmbito e a escolha entre opções de correção. Tudo o resto decide sozinho, com o motivo escrito. Quando o operador concede autonomia para uma execução, o orquestrador decide como delegado do operador apenas nessa execução, e as notas dizem-no.

As revisões correm segundo um relógio, não segundo a memória. Na Copperfern: «Search check» (verificação da pesquisa) todos os dias às 05:00 UTC, «Product photo ideas» (ideias de fotografias de produto) todos os dias às 06:00, «Social post» (publicação nas redes sociais) todos os dias às 16:00, «Weekly planning» (planeamento semanal) todas as segundas-feiras às 06:00 e «Monthly research» (pesquisa mensal) no dia 2 de cada mês às 07:00.

Triagem, encaminhamento, redação e passagens de revisão correm sozinhos; requisitos, merge, publicação e a lista de candidatos esperam por uma pessoa; dados de produção, segredos, gastos e verificações no site em produção nunca são entregues a um agente.

A publicação espera por uma pessoa, a não ser que uma pessoa já tenha decidido outra coisa para esse trabalho. Conteúdo de rotina, como notícias e traduções, é publicado depois da revisão de outro agente, porque alguém escolheu essa coluna para o trabalho antes de ele alguma vez correr (que trabalhos esperam por um sim).

Algumas regras não precisam de ponto de aprovação, porque um hook bloqueia a ação logo à partida: veja como impedimos o Claude Code de apagar ficheiros. Os pontos de aprovação servem para decisões que precisam de uma pessoa, e é esse o cerne dos sistemas de IA com uma pessoa no circuito (human in the loop).

Um responsável por trabalho, não uma matriz RACI

Uma matriz RACI reparte um trabalho por quatro papéis. Num trabalho de um agente registamos dois nomes: o responsável que faz o trabalho, registado como o único executor na tarefa, e a pessoa que aprova no ponto de aprovação. Um trabalho recusado fica recusado: nunca o voltamos a tentar com outro executor e nunca o despachamos de novo enquanto uma execução anterior ainda possa estar ativa. Andar a passar um trabalho de executor em executor esconde porque foi recusado. Cada agente tem também uma linha no nosso inventário de agentes de IA, onde a coluna do responsável fica ao lado do interruptor que o para.

Uma execução, passo a passo: uma alteração, dois sins

A parte útil de uma alteração governada não é o código. São os dois momentos em que uma pessoa diz sim e a linha de raciocínio que o agente deixa para trás.

A Maya pede «uma opção de embrulho para oferta na finalização da compra». Eis esse pedido, do gatilho ao veredito:

O congelamento no passo 5 é rigoroso. Os passos seguintes nunca acrescentam, retiram nem reinterpretam um requisito. Uma alteração de âmbito volta ao passo de requisitos para uma nova aprovação, por isso as regras do jogo nunca mudam depois do sim.

A verificação vermelha no passo 7 nunca chega à Maya como pergunta. O fluxo de correção corre e o veredito volta a ser acompanhado no novo pipeline. Um agente nunca certifica a sua própria correção, e um pipeline vermelho bloqueia o ponto de aprovação do merge.

No passo 9, o merge precisa de um pipeline verde e de uma aprovação explícita. A aprovação vem da Maya, ou da sua delegação escrita quando ela concedeu autonomia para essa execução. Sem ela, a tarefa fica bloqueada no ponto de aprovação e o quadro mostra-a à espera de uma pessoa. Os vereditos de aceitação que ela lê vêm de uma execução de testes no browser, descrita no nosso guia de testes de aceitação.

A tarefa guarda o motivo da rota, os dois pontos de aprovação ultrapassados e o histórico de CI.

Uma alteração, dois sins: o agente encaminha a tarefa do embrulho para oferta, a Maya aprova os requisitos congelados, uma verificação vermelha passa por uma correção e depois a Maya, ou a sua delegação escrita, aprova o merge.

A lista de exclusões e o registo do trabalho

Escreva a lista do que um agente nunca pode assumir antes da lista do que pode fazer. É na lista de exclusões que a governação realmente vive.

A lista de despacho

Uma execução de despacho começa com uma linha de critérios:

criteria: horizon=now; complexity=S; executor=coding-agent; max=5; project=shop; type=task,bug

Depois, o agente constrói duas tabelas. As tarefas mantidas indicam porque cada uma serve. As tarefas excluídas indicam a regra que as excluiu. Uma tarefa é excluída quando:

• já existe uma execução ativa ou despachada para ela
• está à espera de um ponto de aprovação do operador
• precisa do operador ou de acesso direto à produção
• tem a etiqueta manual-qa, production-release, mr-review ou ui-review
• não tem um critério de conclusão concreto
• está bloqueada, ou é filha de uma tarefa bloqueada
• o executor não consegue aceder àquilo de que precisa

Na Copperfern, «Rotate the payment provider key» (rotação da chave do fornecedor de pagamentos) é excluída por envolver valores secretos, e «Check the Spanish checkout on the live site» (verificar a finalização da compra em espanhol no site em produção) é excluída por ser QA manual. O ponto de aprovação pergunta «Approve the candidate list (or trim it) before anything is dispatched.» (aprove a lista de candidatos, ou reduza-a, antes de qualquer despacho). Uma rejeição devolve a execução aos critérios.

A lista de despacho mantém três trabalhos com o motivo por que cada um serve e exclui dois com os respetivos motivos; a Maya aprova a lista antes de qualquer agente começar.

O registo do trabalho

Cada evento governado é uma linha tipificada no trabalho:

Leia o registo de cima para baixo. O revisor lê o artefacto, não o resumo do executor: cada bloco do diff, com os testes afetados executados de novo. Uma linha changes requested (alterações pedidas) trava a execução, e a mesma sessão retoma com a constatação. Uma recusa sem motivo conhecido, como um erro desconhecido, torna-se uma tarefa de bug, por isso o escalamento termina num trabalho registado e não numa mensagem de chat.

Quatro linhas de nota num só trabalho: despachado, alterações pedidas, aprovado, concluído com o merge request 14.

O que corre mal

As falhas que vale a pena contar são as silenciosas. Um trabalho que deixa de correr e um filtro que não devolve nada parecem ambos «está tudo bem».

Um trabalho diário que deixou de disparar

Um dos nossos trabalhos diários deixou de disparar. O histórico de execuções só mostrava sucessos, porque uma execução que nunca começa não pode falhar.

A camada de agendamentos detetou-o. Um agendamento é assinalado como missed, com o motivo «No run for too long» (sem execução há demasiado tempo), quando o tempo desde a última execução ultrapassa 1,5 vezes o maior intervalo normal da sua regra. Num trabalho diário, são 36 horas. Um disparo saltado não conta como execução. O alerta indica a data em que o silêncio começou e uma ligação «Open schedule» (abrir agendamento) para a correção. A cadência de revisão assinala a sua própria lacuna em vez de ficar calada.

A página de agendamentos do ConvOps assinala Product photo ideas com «No run for too long», enquanto a secção Up next (próximas execuções) ainda o mostra para hoje.

Um filtro que não devolveu nada

Na nossa primeira execução de despacho, a consulta de candidatos pedia tarefas ainda não despachadas através da negação de um campo de estado. Esse campo está vazio em todas as tarefas que nunca foram despachadas. Um filtro negado sobre um campo vazio deixa a linha de fora, por isso a consulta devolveu uma lista vazia enquanto tarefas que cumpriam os critérios esperavam no backlog. Nada deu erro, e uma lista vazia lê-se exatamente como «não há nada para fazer».

A regra que daí saiu: nunca negar um campo que pode estar vazio; filtrar pelo que se quer, não pelo que não se quer. Está escrita no passo que escolhe os candidatos: «Nunca filtrar execution_status, executor ou qualquer outro campo que possa ser nulo com ne / nin / NOT.» O defeito em si foi registado como tarefa de bug. A regra vive no passo, por isso mantém-se seja o que for que o motor de consultas faça. É assim que uma falha se torna uma regra em todos os nossos ciclos.

Construa o seu

A governação de agentes de IA numa pequena empresa começa com uma página e um ponto de aprovação. Uma pequena empresa não precisa de um comité de governação. Precisa de um responsável em cada trabalho.

A versão de uma página para copiar:

AI governance operating model: <company>
Reviewed: <date>    Page owner: <name>

1. Decision rights
   Runs alone:          triage, routing with a one-line reason, drafting, review passes
   Waits for a person:  frozen requirements, merge, publish, the dispatch list
   Never delegated:     production data, secret values, spend, live-site checks
   Stop and ask:        production, secrets, spend, publishing, scope, a choice of fixes

2. Owners
   <job>   owner: <one agent or person>   approver: <person>

3. Escalation
   refused: <job>: <message, verbatim>    unknown reason: open a bug task
   stalled: <job>: <reason>               tell <person>; never dispatch again while alive

4. Gates
   Requirements: <person> approves, list frozen
   Merge or publish: green check AND <person> or their written delegation

5. Reviews
   <job>   <cadence>   missed after 1.5 times the longest normal gap

Preencha-a com os trabalhos que os seus agentes já fazem. O primeiro ponto de aprovação a acrescentar é o que vem antes de qualquer coisa entrar em produção.

Coloque o seu primeiro ponto de aprovação dentro de um fluxo de trabalho com uma conta ConvOps grátis(abre num novo separador). Quer isto montado dentro da sua empresa? Marque uma Discovery Session gratuita.