A sua governação de TI foi feita para software que não muda. Os agentes mudam todos os dias.

Já tem governação de TI, e ela é boa naquilo para que foi construída: software determinístico, entregas com controlo de alterações, o mesmo input a produzir o mesmo output. Serviu-o bem durante décadas, e o instinto de a estender aos agentes é razoável.

Só que um agente não é nada daquilo que essa governação pressupõe. É probabilístico, desvia-se a cada atualização de modelo, e atua sobre contexto em tempo real que nenhuma nota de versão capta. Adaptar a um sistema que muda todos os dias um controlo de alterações desenhado para código fixo não aguenta, e fingir o contrário é a forma de um projeto com ar governado produzir um sistema ingovernável.

O erro não é a governação de TI ser fraca. É estar a pedir-lhe que responda a uma pergunta que nunca foi desenhada para fazer. O controlo de alterações pergunta "o que mudou, quem aprovou, e quando entregámos?". Essa pergunta não tem resposta quando a mudança é uma atualização de modelo que não entregou e o comportamento se moveu sozinho.

A unidade de governação tem de mudar

A governação determinística governa entregas. A governação de agentes tem de governar decisões.

Parece uma subtileza. É tudo. Num mundo centrado na entrega, depois de uma build ser testada e entregue, todas as execuções dessa build são assumidas como corretas porque a build é correta. A unidade que se aprova é a entrega, e a entrega é estável.

Um agente não tem entrega estável para aprovar. Duas execuções do mesmo agente sobre o mesmo documento podem divergir, e o modelo por trás pode ser outro na semana seguinte. Por isso o que se governa não pode ser a build. Tem de ser cada decisão que o agente toma: o que decidiu, sob que autoridade, sobre que dados, contra que política. A governação passa de um gate que se atravessa uma vez a uma disciplina que corre continuamente, a cada decisão, durante toda a vida do sistema.

Isso não é um PDF de política. É controlo de engenharia com um dono e um trilho de auditoria.

Os agentes conquistam autonomia, não começam com ela

O mecanismo central é a autonomia graduada. Um agente não entra em produção autónomo. Sobe uma escada, e os evals, os testes que medem se ultrapassa uma fasquia, são o gate de confiança em cada degrau.

Leia a escada com atenção, porque duas propriedades fazem dela mais do que um quadro de maturidade.

Primeiro, um degrau conquista-se, não se agenda. O agente sobe apenas quando ultrapassa a fasquia de evals do nível seguinte, e a fasquia é fixada à partida, sobre a linha de base do próprio processo. É o contrário de um plano de lançamento apressado para cumprir uma data.

Segundo, um degrau perde-se automaticamente. Se a monitorização de drift detetar que o desempenho saiu da fasquia, o agente é despromovido sem esperar que uma pessoa repare. A autonomia não é uma permissão que se concede uma vez e se esquece. É um estado que o sistema tem continuamente de justificar.

À medida que o agente se prova, as pessoas passam de aprovadores a tratadores de exceções. É um ganho de eficiência real, e é limitado pela responsabilidade por desenho. A matriz de autonomia e o kill-switch são documentados, testados e trazem um registo imutável de intervenções. O raio de ação de um agente "Total" não é "o que ele decidir fazer". É um âmbito escrito e delimitado, com as decisões com consequência sempre encaminhadas para uma pessoa.

Os evals são a fasquia de confiança, não uma caixa de lançamento

A palavra "eval" é usada com ligeireza, por isso vale a pena ser concreto sobre o que faz aqui.

Um eval não é um teste de aceitação único que se corre antes de entrar em produção e depois se arquiva. É a medição permanente que decide, continuamente, se o agente merece a autonomia que detém neste momento. É o que converte "achamos que está a funcionar" em "ultrapassou a fasquia às 09:14 de hoje, e esta é a pontuação que autorizou este degrau".

Isto importa porque os sistemas probabilísticos degradam-se em silêncio. Uma atualização de modelo melhora um comportamento e regride outro. Uma mudança na distribuição dos dados de entrada, novos formatos de documento, um novo padrão de fraude, afasta o agente dos casos em que foi validado. Sem um eval em contínuo e monitorização de drift, nada disso é visível até chegar a um cliente ou a um regulador. Com eles, a despromoção é automática e o registo mostra exatamente quando e porquê.

Evals mais monitorização de drift são o que lhe permitem dizer a frase que um comité de risco precisa de ouvir: a autoridade do agente não é assumida, é medida, e é revogada no momento em que a medição desce.

Isto fica ao lado da sua governação de TI, não por cima

O objetivo não é substituir o ITIL. É nomear responsabilidades com clareza suficiente para que ninguém assuma que a outra camada está a cobrir uma lacuna.

A sua governação de TI continua a fazer aquilo em que é excelente: infraestrutura, acessos, entregas determinísticas. A camada de governação de agentes fica ao lado e assume aquilo que a governação determinística nunca foi construída para segurar: drift, evidência por decisão e a escada de autonomia. Dois sistemas, costuras limpas, nenhuma cobertura assumida.

O modo de falha a evitar é o silencioso: um projeto que parece governado porque passou pelo comité de alterações normal, e é ingovernável na prática porque o comité não tem forma de ver uma atualização de modelo nem de medir drift. Passou no gate errado.

Por isso, a pergunta a levar à próxima revisão não é "isto passou pelo controlo de alterações?". É para um sistema que muda todos os dias, quem é dono do drift, onde está a evidência por decisão, e conseguimos despromover um agente automaticamente assim que sai da sua fasquia? Se a resposta honesta for "o nosso processo de entregas assume que continua testado", ainda não tem governação de agentes. Tem governação determinística apontada a um sistema probabilístico, e as duas não encaixam.

Se quiser ver o que é autonomia conquistada num dos seus processos, marque uma reunião.