Os agentes enterprise mais valiosos podem nunca sair do sistema de transação. A aposta da SAP no Joule

O lugar mais seguro para um agente de IA enterprise pode ser justamente o único lugar que a maioria das arquiteturas de agentes evita: dentro do sistema de registro.

O desenho comum funciona na direção oposta. Um agente lê dados por uma API, raciocina sobre eles em outro lugar e escreve um resultado de volta. Cada salto é um ponto onde regras de negócio, permissões e trilhas de auditoria precisam ser reconstruídas, e cada regra reconstruída é uma cópia que pode se desviar do original.

O keynote da SAP no SAP Connect, em 7 de outubro, é a aposta pública mais forte até agora nessa alternativa.

Regras que não precisam ser copiadas

Quando um agente propõe um pedido de compra dentro da aplicação de compras, valem os mesmos limites de aprovação, a mesma segregação de funções e as mesmas checagens de lançamento que valem quando uma pessoa faz isso. Nada precisa ser reimplementado em uma camada de orquestração, porque o agente nunca sai do lugar onde essas regras já rodam.

A trilha de auditoria segue a mesma lógica. Em finanças e compras, a primeira pergunta de um auditor é quem mudou o quê, quando e sob qual autoridade. Se a ação do agente é uma transação normal no sistema de registro, ela cai no mesmo log que a de todo mundo. Vimos o mesmo princípio no sistema de contas a pagar da Snowflake, que mantém determinísticos os passos determinísticos.

O significado vem junto. Um pedido de compra, um centro de custo ou um bloqueio de fornecedor significam algo preciso em um ERP. Um agente que trabalha sobre esses objetos não precisa reconstruir o significado deles a partir de documentos, assim como uma ontologia fez o trabalho no Genie One da Databricks para fundos.

O que a SAP de fato colocou na mesa

A SAP diz que o Joule Work está fazendo rollout neste mês como uma nova interface para IA, para que as pessoas peçam resultados em linguagem natural em vez de aprender as telas da SAP, e que ele alcança todos os seus mais de 400 milhões de usuários. Ela conta mais de 20 Joule Assistants e mais de 200 Joule Agents em finanças, compras, supply chain, RH e experiência do cliente, e mira mais de 400 agentes até o fim do ano.

A afirmação arquitetural é explícita: os agentes rodam dentro de workflows determinísticos da aplicação, com os mesmos dados, regras e trilhas de auditoria da aplicação de negócio. A SAP contrasta isso com um modelo de linguagem sozinho, que dá a resposta mais provável em vez de uma verificada. Um grafo de conhecimento e o SAP Business Data Cloud dão aos agentes uma visão mapeada dos campos, tabelas, APIs e produtos de dados da SAP, com a lógica de negócio anexada.

A SAP cita a Novartis pilotando agentes de sourcing para análise de propostas, e relata ganhos de produtividade de mais de 20% nas suas próprias funções de RH, finanças e compras. As duas coisas são afirmações da própria SAP. Meça nos seus próprios processos antes de planejar em cima delas.

De onde vêm os controles do agente

Dentro do sistema de registro

• Limites de aprovação
• Segregação de funções
• Checagens de lançamento
• Trilha de auditoria
• Significado do objeto de negócio

Herdados pelo agente, não reconstruídos

Além da fronteira do ERP

• CRM
• E-mail
• Portal do fornecedor
• Outro SaaS

Identidade, política e logging precisam ser desenhados de novo

Onde o argumento para

A tese se sustenta para trabalho transacional dentro de um sistema. Ela enfraquece nas bordas.

Muitos processos reais atravessam o ERP, um CRM, e-mail e um portal de fornecedor. Um agente que fica dentro da SAP é seguro dentro da SAP; no momento em que ele age em outro lugar, as questões de integração, identidade e política voltam, e alguém tem que decidir qual plataforma governa o agente além da fronteira.

O lock-in cresce a cada agente construído sobre a lógica de aplicação de um fornecedor. Isso pode ser uma troca justa pelos controles ganhos, mas deve ser feita de propósito e contabilizada quando as plataformas são comparadas.

E um workflow determinístico só protege o que ele modela. Se um limite de aprovação estiver configurado errado, um agente vai respeitar o limite errado mais rápido do que qualquer pessoa. Antes que agentes herdem autorizações, limites de aprovação e regras de lançamento, essas configurações merecem uma revisão, junto com uma resposta clara para como a ação de um agente vai aparecer no log de auditoria: qual identidade, qual agente, qual requisição.

Esse é o formato prático da aposta da SAP. Dentro do sistema que já conhece as regras, os agentes podem ser úteis e controlados ao mesmo tempo. O trabalho de design mais difícil começa na borda desse sistema, onde a maioria dos processos ponta a ponta de fato vive.