Em 29 de setembro, a Oracle lançou o Fusion Claw, um runtime de execução para agentes de IA dentro do Oracle Fusion, e 25 aplicações que rodam sobre ele. Uma delas concilia lançamentos contábeis; outra consolida fretes. A própria Oracle descreve o movimento como a passagem da assistência para a execução. Quando o agente executa dentro do sistema de registro, a pergunta muda de “a resposta está boa?” para “quem autorizou esse lançamento?”. A seguir, o que a Oracle entregou, como a governança funciona, o que Microsoft e SAP fizeram em paralelo e o que uma empresa brasileira deveria resolver antes de ligar o modo automático.
O que o Fusion Claw faz dentro do ERP
As 25 novas aplicações levam o portfólio de Fusion Agentic Applications a 75. A arquitetura separa duas funções: um modelo de fronteira (Gemini e OpenAI, rodando na OCI) raciocina e replaneja, e a execução fica com computação determinística. A Oracle vende essa divisão como vantagem de custo, porque o modelo só entra onde precisa de inteligência e o volume roda em código previsível.
Para ERP, faz sentido. Fechamento contábil não aceita resposta aproximada, e esse é o receio de quem desconfia de IA probabilística em processo transacional. Exemplos citados pela Oracle:
- Ledger, que concilia grandes volumes de lançamentos, investiga exceções e acelera o fechamento;
- Workforce Staffing, que monta escalas considerando habilidades, certificações, regras trabalhistas e custos, e replaneja quando algo muda;
- Shipping Consolidation, que compara alternativas de consolidação de frete e leva o melhor plano para execução quando autorizado;
- Account Territory Growth Plan, que simula configurações de território de vendas antes de agir.
Governança de decisão vira configuração do agente
O que mais me interessa no anúncio é como a Oracle empacotou a governança. O Enterprise Operating Envelope reúne objetivos, procedimentos, políticas, permissões, limites de risco, direitos de decisão, exigências de aprovação e regras de escalonamento da empresa. O Outcome Trust Harness aplica esse envelope a cada execução, controlando identidade, capacidades, dados e ações do agente. No fim, um Outcome Receipt registra a autoridade usada, as evidências, as decisões e as transações executadas.
O nível de autonomia é escolhido por processo, da assistência rápida à execução automática dentro da autoridade explicitamente delegada. Em entrevista à TechTarget, Natalia Rachelson, vice-presidente sênior da Oracle, resumiu o papel das pessoas: definir políticas e limites, conceder autoridade à IA e responder pelo resultado. Mark Vigoroso, CEO da The Enterprise Edge, disse à mesma publicação que as tarefas rodam isoladas, sem acesso aberto à internet ou a APIs, com permissões por papel.
Na prática, é o que uma boa controladoria já faz com pessoas, com alçadas e trilha de auditoria. A diferença é que essas regras agora precisam existir num formato que uma máquina consiga ler e aplicar.
Autonomia total ainda está longe, diz o mercado
Nem todo mundo comprou a ideia de processo inteiro rodando sozinho. Keith Kirkpatrick, vice-presidente de pesquisa da Futurum, disse à TechTarget que ainda estamos a alguma distância disso porque há muito em jogo e muito risco envolvido. Para ele, depende de a organização entender quais limites impor para operar com segurança.
Na análise da Futurum, Kirkpatrick aponta a responsabilização como a principal objeção das empresas à IA autônoma e vê no Outcome Receipt uma resposta a isso, sobretudo em setores regulados. Concordo com as duas leituras: a arquitetura é boa, e o gargalo continua sendo a empresa escrever as próprias regras.
Microsoft e SAP atacam o mesmo problema por outros caminhos
No Copilot Studio, a Microsoft documentou em preview os hooks, workflows que disparam em pontos fixos do ciclo de vida do agente. O evento Pre tool use roda antes de o agente chamar uma ferramenta e é o único capaz de bloquear a ação. O Post tool use pode mascarar dados sensíveis ou gravar registro de auditoria. A documentação é honesta num ponto: se o hook falhar, o agente segue em frente, e a Microsoft recomenda não usá-lo como única proteção de uma regra crítica.
A SAP foi pelo lado do contexto. Em 6 de outubro, anunciou acordo para comprar a TechWolf, cujo grafo de trabalho e habilidades vai servir de grounding para os agentes Joule no SuccessFactors. Segundo a CIO.com, a compra segue as de Reltio e Dremio, feitas pela SAP no mesmo ano.
Cada fornecedor ataca uma camada diferente, mas a premissa é a mesma: agente que executa precisa de cerca antes de ganhar liberdade.
O que muda para empresas brasileiras que rodam ERP
Os números locais mostram que essa cerca ainda falta na maioria das empresas. O estudo The Value of AI: Brazil 2026, da SAP com a Oxford Economics, ouviu 200 líderes, segundo o Baguete. Só 3% se dizem totalmente preparadas para implementar e escalar agentes de IA. E mais:
- 29% não têm controles de permissão e acesso para agentes;
- 35% não têm processo de human-in-the-loop nos fluxos com agentes;
- 65% não sabem dizer se estão implantando agentes mais rápido do que conseguem governá-los;
- entre as que já testam ou usam IA agêntica, 40% relatam agentes tomando ações incorretas.
Um agente com permissão para lançar no razão é tão seguro quanto as regras escritas para ele. Antes de ativar qualquer modo automático, em qualquer ERP, eu começaria por:
- mapear alçadas e aprovações por processo, com valores e responsáveis;
- definir permissões por papel para cada agente, como se fosse um novo funcionário;
- decidir o que exige escalonamento humano e a partir de qual limite de risco;
- garantir que cada execução deixe um registro auditável de quem autorizou o quê.
Conclusão
Com o Fusion Claw, a discussão sobre agentes de IA no ERP sai do modelo e vai para a política de alçadas. Empresas que já documentam bem quem pode decidir o quê vão ligar a autonomia mais cedo. As outras vão descobrir, num fechamento de mês, que nunca tinham escrito essas regras. Se você avalia agentes que executam no ERP, converse com a Luby e comece pelo envelope, antes do agente.