Governança de agentes de IA: autonomia real exige controle real

A maioria das equipes que decide automatizar processos com agentes de IA parte de uma suposição razoável: se o agente faz o trabalho, a equipe fica livre para pensar. O problema está no que fica implícito nessa frase. "Fazer o trabalho" pode significar consultar um banco de dados. Pode significar enviar um e-mail. Pode significar registrar uma ordem de compra no ERP, alterar um cadastro de fornecedor ou cancelar uma transação. Há um intervalo enorme entre essas ações, e a maioria das arquiteturas que vemos em produção trata todas elas da mesma forma: executa e segue. Autonomia sem controle disfarça risco de eficiência. São coisas diferentes, e confundi-las tem um custo que aparece tarde demais.

O que a indústria chama de autonomia

Quando falamos de agentes autônomos, estamos descrevendo sistemas que percebem contexto, planejam uma sequência de ações e executam cada passo sem intervenção humana contínua. Isso é real, é poderoso e resolve problemas que fluxos de automação tradicionais não conseguem atacar, porque exige raciocínio sobre situações que não foram antecipadas em tempo de design.

A McKinsey e a Deloitte já documentaram que a maioria dos pilotos de IA não chega à produção. O gargalo raramente é técnico. O gargalo é confiança: a organização não consegue responder à pergunta "o que acontece quando o agente erra?" com clareza suficiente para aceitar o risco de colocar o sistema para rodar em escala.

O setor interpreta isso como problema de maturidade tecnológica. Nós interpretamos como problema de arquitetura. A questão não é se o agente vai errar. A questão é se o sistema foi desenhado para que o erro seja visível, reversível e contido antes de se tornar um incidente.

Governança de agentes de IA: design desde o início, não auditoria depois

Existe uma confusão recorrente no mercado. As equipes adicionam camadas de aprovação depois que o agente já está pronto, como se a governança fosse um formulário de conformidade aplicado sobre um sistema que já existe. O resultado é previsível: o formulário atrasa o processo sem reduzir o risco, porque as decisões críticas já estão codificadas na arquitetura e o processo de aprovação opera sobre saídas, não sobre intenções.

Governança real começa na fase de design. Significa decidir, antes de escrever a primeira linha de código, quais ações o agente pode executar de forma autônoma, quais exigem confirmação humana e quais são simplesmente proibidas. Essa taxonomia pertence ao código, com a mesma força de uma política corporativa. É o contrato entre o sistema e a organização que vai operá-lo.

Quando reconstruímos o fluxo de compras de uma mineradora sobre Protheus e TOTVS, a primeira decisão não foi sobre modelos ou prompts. Foi sobre fronteiras de ação. O agente pode consultar estoque, comparar fornecedores, redigir a ordem de compra e pré-preencher campos no ERP. Submeter a ordem acima de determinado valor exige revisão humana explícita. Essa fronteira está no código, não no manual de procedimentos. O resultado: o tempo por pedido passou de trinta para cinco minutos, com zero erros de registro no ERP.

Governança não é o freio no carro de corrida. É o desenho da pista.

Humano no ponto de decisão: nem sempre, mas sempre no lugar certo

Um dos erros mais comuns na implementação de agentes é a escolha binária: ou o humano aprova tudo, o que elimina o ganho de escala, ou o agente decide tudo, o que transfere risco inaceitável para o sistema. Nenhuma das duas abordagens sobrevive ao contato com operações reais.

O conceito que orienta nossa arquitetura é o de ponto de decisão crítico. Cada fluxo de agente tem momentos em que o custo de reverter um erro é alto: uma comunicação enviada para o destinatário errado, um pagamento processado com valor incorreto, um cadastro alterado de forma permanente. Nesses pontos, a presença humana não é burocracia. É controle de qualidade com custo justificado.

Fora desses pontos, o agente opera com autonomia total. Consulta, analisa, redige, organiza, prioriza. A velocidade é real e é onde mora o ganho de capacidade. Em um dos nossos projetos, a mesma equipe passou a operar seis vezes mais volume depois que os agentes assumiram as etapas de coleta e preparação de informação, com os analistas concentrados apenas nas decisões que exigiam julgamento.

O desafio de design é mapear esses pontos com precisão. Pontos demais e o sistema vira um formulário interativo caro. Pontos de menos e o agente opera com autonomia que a organização não está preparada para conceder. Esse mapeamento é, em grande parte, o trabalho real de implementação e o que diferencia um piloto funcional de um sistema que a organização de fato confia.

Log de ações: infraestrutura de confiança

Toda ação que um agente executa deve ser registrada. Não como log de sistema para fins de debug. Como registro permanente de intenção, contexto e resultado, legível por um humano que não participou da execução original.

A diferença importa. Um log de sistema diz que uma chamada de API foi feita às 14h32 e retornou status 200. Um log de governança diz que o agente escolheu o fornecedor X em vez do fornecedor Y porque o prazo de entrega era três dias menor e a diferença de custo estava abaixo do limiar de aprovação automática configurado pela equipe de compras. São dois registros completamente diferentes em termos de utilidade operacional.

Esse nível de rastreabilidade cumpre três funções distintas. A primeira é auditoria: qualquer decisão pode ser revisada depois, com o contexto completo em que foi tomada. A segunda é aprendizado: padrões de erro ou de desvio ficam visíveis antes de se tornarem problemas sistêmicos. A terceira, e talvez a mais importante, é confiança: a equipe que opera o sistema consegue entender o que o agente fez e por que, sem precisar abrir o código.

Na nossa infraestrutura própria de build e deploy de agentes, o log é tratado como dado de produto, não como dado operacional. Cada bloco de raciocínio, cada ferramenta chamada, cada decisão de roteamento fica registrado de forma estruturada e consultável. Isso não é overhead. É o que torna possível expandir a autonomia do agente de forma incremental, porque a organização tem evidência do comportamento antes de ampliar o escopo.

Reversibilidade como princípio de engenharia

Um agente que não pode ser desfeito é um agente que não pode ser confiado. Esse é um princípio de engenharia antes de ser uma diretriz de governança, e ele precisa estar presente desde as primeiras decisões de design.

Reversibilidade não significa que toda ação é cancelável: algumas têm efeitos no mundo real que não se desfazem. Significa que o sistema foi projetado para minimizar o custo de correção quando algo sai do planejado. Significa preferir ações que podem ser revisadas antes de ações que não podem. Significa construir fluxos com pontos de parada naturais, onde o estado do processo é legível e o próximo passo ainda pode ser alterado.

Na prática, isso se traduz em padrões concretos. Agentes que redigem e-mails antes de enviá-los. Agentes que preparam ordens de compra antes de submetê-las. Agentes que propõem alterações em cadastros antes de confirmá-las. Em cada caso, há uma janela entre a intenção e a execução. Essa janela é onde a correção ainda é barata.

O custo dessa janela é latência. Em alguns fluxos, a latência é aceitável. Em outros, não. A decisão sobre onde abrir essa janela e onde fechá-la é outra dimensão do design de governança que não pode ser feita depois que o sistema está pronto, porque mudar essas fronteiras em produção exige renegociar o contrato com toda a operação.

O custo de não governar agora

A tendência que estamos observando no mercado é de implementações rápidas seguidas de crises lentas. O piloto funciona, a liderança aprova a expansão, o escopo cresce, e em algum momento o agente opera em um contexto que ninguém antecipou durante o design. O erro que acontece não é catastrófico, mas é visível o suficiente para criar desconfiança. E desconfiança, uma vez instalada, é difícil de remover.

A governança de agentes de IA existe para garantir que o erro seja detectável, contenível e corrigível. Para que a organização consiga aprender com ele em vez de ser paralisada por ele. Não é sobre impedir falhas, porque falhas em sistemas complexos são inevitáveis. É sobre garantir que a estrutura ao redor da falha seja mais forte do que ela.

Isso exige uma mudança de mentalidade que vai além das equipes de tecnologia. Exige que as áreas de negócio participem do design das fronteiras de ação. Exige que a liderança entenda que colocar o humano no ponto certo do processo não é um sinal de que a IA não funciona: é um sinal de que a organização sabe onde confia no sistema e onde prefere manter julgamento.

A pergunta que todo time deveria responder antes de colocar um agente em produção: o que acontece quando ele faz algo que não deveria? Se a resposta demorar mais de trinta segundos, o sistema ainda não está pronto.

Governança como vantagem competitiva

As organizações que constroem governança como parte da arquitetura desde o início ganham algo que as outras não têm: capacidade de expandir com segurança. Cada novo caso de uso pode ser adicionado sobre uma infraestrutura que já tem logs estruturados, já tem fronteiras de ação definidas, já tem reversibilidade projetada. O custo marginal de expansão cai. A velocidade de implementação sobe.

As organizações que tratam governança como etapa posterior, ou como requisito de compliance a ser satisfeito no papel, constroem sobre areia. Cada expansão carrega o risco acumulado de todas as decisões de design que não foram tomadas no momento certo. E em algum ponto, a dívida técnica de governança se converte em incidente operacional.

Autonomia e controle não são opostos. São dimensões complementares de um sistema bem projetado. A equipe que entende isso constrói agentes que a organização consegue confiar. E confiança, no final, é o único ativo que transforma um piloto em operação real, e uma operação real em vantagem duradoura.

Quer ler a sua operação a fundo?