Política de API de SAP para IA: nuevas restricciones reavivan el miedo al lock-in
La Política de API de SAP para IA se ha convertido en el nuevo punto de fricción entre SAP y su ecosistema: el proveedor ha actualizado su documento de política para prohibir el uso de APIs en integraciones con sistemas (semi-)autónomos o generative AI que puedan planificar, seleccionar o ejecutar secuencias de llamadas, salvo que se encuadren en arquitecturas y pathways “endorsed” por SAP. El cambio es relevante hoy porque afecta de lleno a cómo clientes y partners conectan sus datos SAP con AI agents y herramientas de terceros en entornos enterprise.
El texto de la política añade además restricciones contra “scraping, harvesting” y la extracción o replicación sistemática y/o a gran escala de datos, un lenguaje que varios expertos interpretan como un endurecimiento que puede limitar integraciones legítimas si no están alineadas con los patrones oficialmente soportados.
Qué cambia con la Política de API de SAP para IA
Según el documento, SAP prohíbe el uso de sus APIs para: (a) interacción o integración con sistemas (semi-)autónomos o generative AI que planifiquen, seleccionen o ejecuten secuencias de llamadas a APIs, y (b) extracción masiva o replicación sistemática de datos, excepto cuando el acceso ocurra “through and within the limits of SAP-endorsed architectures, data services, or service-specific pathways expressly identified”. En la práctica, el matiz clave es que no basta con que una integración sea técnicamente posible: debe encajar en las rutas y arquitecturas explícitamente previstas por SAP.
La preocupación, expuesta por consultores y partners, es que el perímetro de lo “documented” o “expressly intended” no siempre está al día, lo que podría introducir incertidumbre legal y técnica sobre integraciones existentes y nuevas iniciativas basadas en AI agents.
Partners alertan de lock-in y de un giro hacia APIs no documentadas
Marian Zeis, consultor independiente de SAP en Alemania, afirmó que los cambios son más restrictivos de lo esperado por la comunidad y que pueden impactar también a clientes finales, no solo a proveedores terceros. En su lectura, si el acceso quedara acotado únicamente a APIs documentadas, SAP ganaría capacidad para “govern, monitor, throttle, and control” el desarrollo futuro sobre sistemas SAP, elevando el riesgo percibido de lock-in.
Otro efecto secundario señalado por el ecosistema es que, si el catálogo de APIs oficialmente soportadas evoluciona con lentitud, algunos proyectos podrían verse empujados hacia integraciones mediante APIs no documentadas para sostener casos de uso que el negocio considera críticos, aumentando el riesgo operativo y de mantenimiento.
Contexto: controversia, documento y FAQ oficial
La controversia fue inmediata. El periodista Christof Kerkmann (Handelsblatt) apuntó que el documento provocó debate desde su publicación y llegó a sugerir que podría haberse publicado por error, aunque el texto seguía incluyendo el lenguaje controvertido en una actualización posterior.
SAP mantiene el documento en su sección de ayuda y también publicó una FAQ asociada. Fuentes: SAP API Policy (PDF) en help.sap.com y FAQ oficial de SAP sobre data access y API policies.
La posición de SAP: estabilidad, seguridad y “throttling”
Un portavoz de SAP indicó que las actualizaciones buscan un uso “seguro, fiable y equitativo” de plataformas enterprise compartidas ante el crecimiento del acceso automatizado y AI-driven, alineándose con prácticas estándar de cloud, protegiendo la estabilidad del sistema y los datos del cliente, y aportando guías sobre patrones soportados “sin cambiar la propiedad del dato”.
En una llamada con inversores, el CEO Christian Klein defendió que los clientes no pagarán por acceder a sus propios datos y que SAP quiere mantener una arquitectura abierta, incluyendo para third-party AI agents. También justificó el “throttling” ante escenarios de millones de llamadas a APIs para evitar degradación de rendimiento, enmarcando el control de acceso como una medida para proteger estabilidad y propiedad intelectual.
Por qué importa para IT, integradores y el mercado de AI agents
La Política de API de SAP para IA aterriza en un momento en el que los AI agents empiezan a operar como capas de automatización que orquestan llamadas a APIs en cadena para ejecutar procesos end-to-end. Si esas secuencias quedan limitadas a arquitecturas “endorsed”, el impacto puede sentirse en integraciones con plataformas de AI externas, en estrategias de observabilidad y data extraction, y en proyectos de modernización donde SAP convive con stacks de terceros.
Alisdair Bach, responsable de práctica SAP en la consultora Dragon ERP, aportó además el argumento de seguridad: en un escenario de pruebas continuas y extracción automatizada, los patrones de integración laxos pueden convertirse en superficies vulnerables, y los agentes impulsados por IA pueden explorar puntos débiles más rápido que un operador humano.
A corto plazo, el foco para clientes y partners será clarificar qué entiende SAP por “SAP-endorsed architectures” y cómo se mantiene el inventario de pathways soportados, porque de ello dependerá el alcance real de esta Política de API de SAP para IA en integraciones existentes y en nuevos despliegues de AI agents sobre datos enterprise.
