La pregunta clave no es si una herramienta de terceros queda automáticamente prohibida por conectarse a SAP. El cambio importante es más concreto: desde la actualización de abril de 2026, SAP está acotando el uso de APIs sobre datos y procesos centrales del ERP a APIs publicadas, documentación de producto, arquitecturas avaladas por SAP, servicios de datos o rutas específicas de servicio. [1][
7][
10]
Para una empresa que está probando agentes de IA sobre SAP, esto cambia el diseño de pruebas de concepto, plataformas de datos, RPA, iPaaS, ETL y automatizaciones propias. [1][
13]
Qué cambia realmente
Según CIO, SAP indicó que solo las interfaces incluidas en SAP Business Accelerator Hub —su catálogo oficial para encontrar APIs y contenido de integración— o en la documentación del producto correspondiente se consideran APIs publicadas. [7] The Register también informó de que la nueva política exige usar las APIs dentro de los límites de arquitecturas avaladas por SAP, servicios de datos o rutas específicas de servicio. [
2][
10]
La consecuencia práctica es clara: una empresa ya no debería asumir que cualquier interfaz SAP que pueda invocar técnicamente es una base segura para una integración a largo plazo. La política enumera controles de API como límites funcionales y técnicos de uso, cuotas, calendarios de obsolescencia, cuotas de entrada y salida de datos, condiciones para extracción o réplica masiva y otros requisitos técnicos o de seguridad. [9]
SAPinsider añade otro punto sensible: muchas integraciones siguen usando APIs no documentadas, pero con la actualización quedan fuera de los límites de soporte, lo que aumenta el riesgo operativo y de mantenimiento a largo plazo. [1]
En otras palabras, no se trata solo de una cláusula sobre IA. Es un problema más amplio de gobierno de integración ERP: qué API está publicada, qué uso está soportado, qué extracción requiere condiciones previas y qué automatización debe pasar por una ruta reconocida por SAP. [7][
9][
13]
Por qué los agentes de IA son el punto más delicado
La parte que más atención ha generado es la cláusula sobre IA. Varios reportes citan la política en el sentido de que SAP prohíbe el uso de APIs para interactuar o integrarse con sistemas de IA generativa o semiautónomos que planifican, seleccionan o ejecutan secuencias de llamadas API, salvo mediante arquitecturas, servicios o rutas expresamente avaladas por SAP. [5][
10]
Ahí está la diferencia entre una integración tradicional y la llamada IA agéntica. Una integración clásica suele seguir un flujo predeterminado: un sistema llama a una API concreta bajo reglas fijas para completar una tarea. Un agente de IA, en cambio, puede decidir pasos sobre la marcha: consultar un proveedor, revisar inventario, generar una recomendación de compra y después preparar una aprobación o actualizar un registro.
Si el agente selecciona y encadena varias llamadas a APIs de SAP, puede entrar en el ámbito de la política sobre secuencias de llamadas API; la conformidad dependerá de las APIs usadas, la arquitectura, el servicio de datos y el modo de aprobación de SAP. [5][
10]
La misma restricción también alcanza prácticas como scraping, harvesting y extracción o réplica sistemática o a gran escala de datos. [5][
10] Por eso el impacto no se limita a agentes que escriben en SAP: también obliga a revisar diseños que leen grandes volúmenes de datos SAP para alimentar una plataforma externa de IA, un lakehouse o una capa de orquestación. [
9][
13]
Innovación: las pruebas no se acaban, pero se vuelven más formales
Para equipos de innovación, integradores e ISV, el cambio introduce una puerta de gobierno antes del experimento. Antes, un agente de IA podía conectarse con relativa rapidez para probar conciliación financiera, apoyo a compras, análisis de inventario o automatización de atención al cliente. Con la nueva política, el equipo debe comprobar primero si la API está en SAP Business Accelerator Hub o en la documentación del producto, si la arquitectura está avalada por SAP, si el uso activa cuotas o límites de extracción y si el agente planifica por sí mismo llamadas API en varios pasos. [5][
7][
9]
Eso no significa que las pruebas de concepto de IA sean imposibles. Sí significa que se parecen más a un proyecto formal de integración: inventario de APIs, diseño de permisos, estimación de uso, revisión del flujo de datos y confirmación de cumplimiento. ERP Today señala que la política convierte un asunto técnico de integración en una cuestión más amplia de arquitectura ERP, porque algunas integraciones existentes dependen de interfaces no documentadas mientras las aplicaciones emergentes de IA necesitan acceso controlado a datos empresariales y flujos transaccionales. [13]
La incertidumbre también puede ralentizar proyectos. The Register informó de que DSAG, el grupo de usuarios de SAP de habla alemana, criticó la incertidumbre generada por la política; el mismo reporte recoge críticas sobre una lista de interfaces aprobadas que podría no estar suficientemente bien gestionada o actualizada. [2]
Control de datos: no basta con preguntar quién es el dueño
El debate no se limita a la propiedad formal de los datos. La cuestión práctica es si el cliente puede usar la plataforma de IA, el stack de datos y las herramientas de automatización que elija para acceder de forma directa, continua y en tiempo real a los datos y procesos de SAP. The Register planteó el problema como el posible bloqueo de herramientas de IA de terceros frente a los datos SAP de los clientes, mientras ERP Today lo sitúa en el plano de la arquitectura de integración ERP, la réplica de datos y el acceso de IA. [10][
13]
Si una empresa quiere sincronizar datos SAP con un lakehouse externo, una plataforma de IA, una capa de orquestación de agentes o un sistema de automatización de terceros, tendrá que revisar especialmente las cuotas de entrada y salida de datos, las condiciones para extracción o réplica masiva, el alcance de las APIs publicadas y si debe usar una ruta avalada por SAP. [7][
9][
10]
Este tipo de controles puede reforzar rendimiento, seguridad, auditoría y gobierno. El coste es que la autonomía de una arquitectura de IA multiplataforma puede reducirse, sobre todo en casos de uso que necesitan leer y escribir grandes volúmenes de datos transaccionales de SAP. [9][
13]
Dependencia del proveedor: más riesgo, pero no un desenlace inevitable
El riesgo de lock-in nace de una consecuencia práctica: si un agente de IA de terceros no puede interactuar libremente con APIs de SAP, el cliente tenderá a depender más de arquitecturas avaladas por SAP, servicios oficiales de datos o mecanismos de integración expresamente permitidos. The Register describió la cláusula de IA como una fuente de preocupación por lock-in, porque podría dejar fuera a algunas herramientas de IA de terceros del acceso a datos SAP del cliente. [10]
La reacción de DSAG muestra que la inquietud no es solo técnica. E3 Magazine informó de que, para DSAG, resulta inaceptable que SAP restrinja de forma severa el uso de APIs para fines no documentados, extracciones masivas sistemáticas y la interacción con sistemas autónomos de IA generativa de terceros. [11]
Aun así, el lock-in no es el único resultado posible. Mucho dependerá de si SAP define con claridad las rutas avaladas, mantiene completo y actualizado el catálogo de APIs publicadas, ofrece procesos auditables de excepción o aprobación y permite que los proveedores externos sigan innovando bajo reglas claras. Las críticas sobre la gestión y actualización de la lista aprobada son precisamente el punto que los equipos de arquitectura y compras deberían exigir por escrito. [2][
7]
Cinco pasos que las empresas deberían dar ahora
-
Inventariar todas las integraciones con SAP. Clasificar cada conexión como API publicada, API documentada en producto, interfaz no documentada, extracción masiva, lectura y escritura en tiempo real, RPA, iPaaS o llamada desde un workflow o agente externo. [
1][
7][
13]
-
Separar los casos de IA agéntica. Todo flujo en el que un modelo o agente planifique, seleccione o ejecute varias llamadas API de SAP debería pasar por una evaluación específica de riesgo de política. [
5][
10]
-
Auditar extracción y réplica de datos. La extracción a gran escala, la réplica, el scraping y el harvesting entran en el área restringida; data lakes, lakehouses, BI, entrenamiento de IA y sincronizaciones externas deben revisar cuotas, condiciones y rutas permitidas. [
5][
9][
10]
-
Pedir confirmación escrita a SAP o al socio implantador. Para escenarios de más riesgo —IA agéntica, actualización automática de transacciones, orquestación entre sistemas o exportaciones masivas— no conviene basarse solo en interpretaciones verbales. La crítica de DSAG sobre la incertidumbre subraya la importancia de fijar límites por escrito. [
2]
-
Diseñar con margen de sustitución. Aunque se adopte una ruta avalada por SAP, conviene mantener la orquestación de IA, el gobierno de datos, los permisos, los registros de auditoría y las reglas de negocio lo más modulares posible, para evitar que toda la lógica de innovación quede atada a un único camino técnico.
Conclusión
El efecto de la política API de SAP para 2026 no es que la IA ya no pueda usarse con SAP. El cambio es que un agente de IA de terceros ya no debería asumir que puede organizar libremente llamadas API sobre el ERP. La política eleva el listón de seguridad, rendimiento y gobierno, pero también aumenta los costes de cumplimiento, puede ralentizar pruebas y hace más visible el riesgo de dependencia del proveedor. [10][
13]
A corto plazo, la respuesta más pragmática es inventariar integraciones, identificar los flujos de IA agéntica, confirmar las rutas avaladas por SAP y diseñar nuevas arquitecturas con opciones reales de salida.
