El agente de Salesforce que maneja SAP choca con la política de API del alemán

Salesforce usó su conferencia Dreamforce para enseñar un agente de IA que ejecuta el alta de proveedores dentro de SAP. La demostración, presentada por la directora de marketing de producto Katie O'Neil, muestra al agente —bautizado Marshall— trabajando en un entorno de pruebas de SAP y aprendiendo dónde hacer clic y qué campos son obligatorios, según la propia presentadora. El resultado que Salesforce vendió en el escenario es que un usuario de Slack completa el proceso en el ERP alemán, con Siemens como cliente de referencia.

El problema es qué opina SAP de todo esto. Varios consultores independientes sostienen que esa integración, llevada a producción, chocaría con la política de API que el fabricante alemán publicó en abril y que restringe cómo se conectan sistemas de IA ajenos a sus aplicaciones.

Salesforce lo niega. Un portavoz de la compañía asegura que la demostración se comunicó con SAP a través de su interfaz de usuario usando cuentas de servicio, sin emplear las API de SAP, por lo que las restricciones citadas no aplican. SAP ha declinado comentar.

Qué prohíbe la política

Mario de Felipe, VP de datos e IA en SAP de la consultora Apiphani, señaló en LinkedIn que la política veta las técnicas de suplantación y exige que cualquier IA autónoma entre en las aplicaciones de SAP por arquitecturas avaladas por el fabricante. En su opinión, la demo no se limitó a llamar a la API para actualizar un proveedor, que habría sido lo sencillo, sino que capturó la lógica de la aplicación: cómo funciona el modelo de roles de procesos de negocio, el comportamiento completo del producto. También recordó que detrás de lo que se vio en el escenario no hay ningún acuerdo nuevo entre ambas compañías.

El texto de la política prohíbe usar las API para integrarse con sistemas de IA generativa o semiautónomos que planifiquen, seleccionen o ejecuten secuencias de llamadas, salvo dentro de arquitecturas avaladas por SAP. La misma salvedad acompaña a la prohibición de extracción o replicación masiva de datos.

Marian Zeis, consultor independiente en Alemania, coincide en lo esencial pero matiza. La automatización robótica de procesos no es el problema, dice; la cosa se complica cuando un LLM o un agente autónomo empieza a planificar y ejecutar llamadas, porque entonces SAP espera rutas de acceso documentadas. No llamaría suplantación a un agente que actúa con la autorización de un usuario: en la política esa palabra aparece en el contexto de saltarse los controles de la API. Su objeción de fondo es práctica, que el documento es razonable como marco de gobernanza pero encaja mal con cómo trabajan hoy los clientes.

La lectura comercial

John Appleby, ex consejero delegado del partner de SAP Avantra, recordó en los comentarios de ese mismo post que las demos se diseñan para ser afiladas sin romper contratos de licencia, y que existía una vía limpia a través de una capa permitida como SAP Integration Suite. Que se nombre a Siemens, argumenta, sugiere que alguien revisó el cumplimiento. El asunto, dice, viene de lejos: desde las reglas de acceso indirecto de hace casi dos décadas.

Un analista senior que habló sin atribución fue más duro: calificó la política de puro proteccionismo y dijo que atar la IA a RISE with SAP fue un error, porque Joule, el primer intento de la casa en este terreno, no pasa de asistente digital. Su cifra: el 93% de los grandes clientes queda sin acceso.

SAP no ha movido ficha públicamente, y ahí está la clave para quien tenga que integrar agentes con su ERP. La pregunta que queda abierta no es si el agente de turno puede pulsar botones, sino qué rutas de acceso acepta el fabricante cuando ese agente deja de ser una demo y empieza a escribir datos de proveedores en producción.