O Elefante na Sala × governança × agentes × mundo físico
O ESSENCIAL
O Google DeepMind publicou um framework rigoroso de governança de agentes — elegante, tecnicamente sólido, e assume um ambiente que a maioria das empresas não tem. Para funcionar, agente precisa de dado verificável, critério de aceite definido e fronteiras de autoridade claras. Em empresas não-tech, pelo menos um dos três está ausente na maioria dos processos críticos. O projeto de dados são dois anos sem cerimônia. O projeto de agentes vai no slide pro board. O incentivo aponta sempre para o segundo — e é isso que derruba rollouts depois do PoC.
DECISÃO EM JOGO: Implementar agentes de IA vs. construir a fundação de dados e processos que agentes exigem
O Google DeepMind publicou em fevereiro um paper sobre governança de agentes de IA. É rigoroso, elegante, tecnicamente sólido. E assume um ambiente que a maioria das empresas não tem.
Esse é o problema.
Um processo de supply chain. Treze anos rodando no SAP. Não no SAP moderno — no SAP ECC, aquele que nasceu da junção de dois SAP R/3 sem saneamento, com tabelas de customização que ninguém mais entende, campos Z que um consultor criou em 2011 e foi embora, e um plano de migração pro S/4HANA que está “em avaliação” desde 2019.
Ao redor desse núcleo: dados de produção chegando de PLCs que ninguém documenta há anos. Um MES que, em metade das plantas, não existe. Os dados de produção chegam no SAP via planilha, digitados por um auxiliar no turno da manhã.
Mais ao redor: um SaaS de logística que a área operacional comprou sem passar pelo TI. Um painel de BI que puxa de quatro fontes diferentes e onde nenhuma área concorda qual é o número correto.
Agora imagina um agente de IA tomando decisão autônoma em cima disso.
O que o DeepMind propõe — e o que assume
O paper Intelligent AI Delegation parte de um diagnóstico correto: sistemas atuais de delegação entre agentes são frágeis, funcionam em ambiente controlado e quebram quando o mundo real aparece. A proposta é um framework robusto — accountability transitiva, verificação criptográfica de resultados, decomposição contratual de tarefas.
A ideia central, chamada de Contract-First Decomposition, é elegante: você só pode delegar uma tarefa a um agente se conseguir especificar como vai verificar o resultado de forma independente. Se a tarefa é ambígua demais, o sistema a decompõe até encontrar algo verificável — um teste que passa ou falha, um schema que se valida.
É o framework certo. Para o ambiente certo.
O ambiente que o paper assume: APIs documentadas, dados com dono definido, processos com critério de aceite claro. Um ambiente onde “verificar automaticamente o resultado” é uma pergunta que tem resposta.
Em boa parte das empresas não-tech — manufatura, varejo, logística, saúde, construção — essa pergunta não tem resposta. Não por incompetência. Por estrutura.
O dilema do tamanho
A lógica intuitiva seria: empresa grande tem orçamento, empresa pequena não tem. Grande resolve, pequena sofre.
Não é assim que funciona.
A empresa menor não tem budget para a senioridade de arquitetura que faria o diagnóstico correto, nem para os sistemas enterprise que dariam uma base mais sólida. Roda no que tem: ERP mid-market com customizações acumuladas, integrações feitas por consultor que saiu há três anos, documentação que existe só na cabeça de quem está na empresa há uma década.
A empresa maior tem o orçamento, mas é grande demais para se reorganizar de uma vez. Qualquer iniciativa de qualidade de dados vira programa plurianual. Antes de terminar a primeira onda, a empresa adquiriu outra — com o próprio ERP, os próprios sistemas legados, os próprios dados sujos. Débito técnico não é acidente na empresa grande. É consequência estrutural do crescimento.
E no meio existe uma categoria que raramente aparece na análise: a empresa que passou de pequena mas ainda não chegou a grande. Complexidade de grande, budget de pequena. O pior dos dois mundos sem as vantagens de nenhum.
A empresa pequena não consegue se organizar. A grande não consegue se reorganizar de uma vez. O meio mistura os dois problemas com metade do orçamento. O problema de base não tem solução de tamanho.
O que o agente precisa — e o que não encontra
Para funcionar com a confiabilidade que o DeepMind descreve, um agente precisa de três coisas que raramente existem juntas.
Dado verificável. Numa arquitetura onde o mesmo campo tem três fontes com três valores diferentes, o agente não tem base para decidir. Ele escolhe um, e a escolha vai estar errada em algum contexto que ninguém mapeou.
Critério de aceite definido. Se a resposta para “como sabe que o agente completou corretamente?” é “um humano olha e aprova” — você não tem critério de aceite. Tem uma etapa de validação humana sendo chamada de outra coisa.
Fronteiras de autoridade claras. Em ambientes onde as fronteiras de responsabilidade entre áreas são nebulosas para os próprios humanos, esse mapeamento não existe para ser passado ao agente.
A ausência de qualquer um dos três não impede o agente de rodar. Impede o agente de rodar corretamente.
O humano que ninguém documentou
Quando existe um humano verificando o resultado hoje — e em quase todo processo não-tech existe —, esse humano está exercendo três funções que raramente são reconhecidas como distintas.
Execução: faz a tarefa, preenche o campo, aciona o sistema. Um RPA cobre. Um BAPI automatiza.
Verificação: confere se o resultado está tecnicamente correto. Uma regra de negócio bem documentada resolve.
Contextualização: interpreta o que “correto” significa naquele caso específico. Com aquele cliente que tem um acordo comercial não documentado. Naquele mês de fechamento com critério diferente por uma decisão do board em 2021. Com aquela exceção que todo mundo conhece, está em vigor há oito anos, e nunca entrou em nenhum sistema porque “é só um caso” que acontece toda semana.
RPA não contextualiza. BAPI não contextualiza. O agente vai tentar — mas vai aprender de dados que contêm a exceção sem documentar a regra. O resultado vai parecer certo na maior parte do tempo e estar errado nos casos que mais importam.
A contextualização mora na cabeça do especialista que está prestes a se aposentar. Não está em nenhum sistema. Não vai estar disponível para o agente a menos que alguém a elicite e documente antes que a pessoa saia.
Isso não é projeto de AI. É projeto de gestão do conhecimento. Quase ninguém tem orçamento para ele — e é exatamente ele que determina se o agente vai funcionar.
FinOps como sintoma
FinOps matura não é só problema financeiro. É sinal de que a empresa não tem governança de consumo. Empresa que não sabe quanto gasta por workload não vai saber quanto custa um agente rodando errado.
A diferença importa: agente que falha explicitamente para e gera alerta. Agente que falha silenciosamente continua rodando, continua registrando transações — até que alguém percebe que os números não fecham.
Em ambiente com dados questionáveis, distinguir “o agente errou” de “o dado estava errado” de “o processo tem uma exceção não documentada” vira um exercício forense que consome mais tempo do que o agente economizou.
Governança de consumo é o pré-requisito para monitorar se o agente está operando dentro dos limites esperados. Sem ela, o sinal de que algo está errado chega tarde — depois que o dano está feito.
A velocidade de substituição depende da velocidade de instrumentação do mundo físico
A narrativa dominante é que AI vai substituir empregos em escala e velocidade sem precedente. Em empresa de software, em operação 100% digital, em processo que existe só como dado — essa substituição já está acontecendo.
Mas a maioria das empresas não-tech opera no mundo físico. Tijolo, caminhão, prateleira, galpão, obra, prontuário, nota fiscal com prazo que depende de um motorista que conhece o trajeto.
Nesse mundo, o agente não substitui o trabalho — ele precisa orquestrar o trabalho físico. Para orquestrar, precisa enxergar. Para enxergar, precisa de dado confiável. Para ter dado confiável, precisa de processo estruturado e sistema que capture esse processo com integridade.
A consequência de erro no mundo físico não é um bug que se reverte com rollback. Se o agente erra uma ordem de compra, a empresa não paga o fornecedor. Se erra um pedido, não entrega pro cliente. Se erra o fechamento contábil, não fecha o mês. Se erra uma requisição de manutenção numa planta, tem risco de parada de linha.
Para o agente substituir trabalho humano numa operação física, essa operação precisa estar suficientemente digitalizada, com dados suficientemente confiáveis, com processos suficientemente documentados. Em muitas empresas não-tech, esse patamar levará anos — não por resistência cultural, mas por complexidade técnica e restrição de financiamento.
A substituição vai acontecer. Na velocidade em que o mundo físico permite ser instrumentado. Mais lenta do que o hype anuncia. Mais inevitável do que o negacionismo defende.
Tem chão ainda.
A sequência importa
O projeto de agentes é o mais visível, o mais moderno, o que vai no slide pro board. O projeto de qualidade de dados é dois anos de trabalho chato sem cerimônia de lançamento. O incentivo estrutural aponta sempre para o primeiro — e é exatamente por isso que tantos rollouts encontram o ambiente real depois do PoC.
Isso não é argumento contra agentes. É argumento por sequência.
Antes de governança de agentes, governança de dados. Antes de delegação automática entre sistemas, dono de processo definido entre humanos. O framework do DeepMind é a arquitetura certa — Contract-First Decomposition, verificação independente, resiliência sistêmica. O que o paper não resolve, e não se propõe a resolver, é o ambiente que a maioria das empresas não-tech precisará construir antes de implementá-lo com segurança.
A pergunta prática para o CIO pressionado pelo board não é “qual framework de delegação escolhemos?” É: “em quantos dos nossos processos críticos conseguimos hoje definir automaticamente o critério de aceite de um resultado?”
Nenhum vendor vai fazer essa pergunta. A resposta atrasa o projeto — e o vendor não tem incentivo para atrasar o projeto.
Agente inteligente num ambiente estúpido não fica inteligente. Ele fica rápido.