Imagina que tienes un departamento de cuentas a pagar. Varias personas gestionando facturas de proveedor todos los días: entran documentos, se verifican contra pedido y contra entrada de mercancía, se detectan desviaciones, se escalan las que no cuadran, se contabilizan las que sí. Un proceso repetitivo, basado en reglas, con datos estructurados. El tipo de trabajo para el que los agentes de IA están hechos.
Ahora imagina que alguien en tu empresa conecta un agente de Claude o de ChatGPT directamente a las APIs de SAP desde fuera de la plataforma. El agente lee las facturas entrantes, consulta los pedidos en MM, verifica las entradas de mercancía, detecta desviaciones y contabiliza en FI lo que entra dentro de tolerancia. Sin intervención humana en el ochenta por ciento de los casos. Sin licencia. Sin pasar por BTP. Sin que SAP vea nada, mida nada ni cobre nada.
Ese escenario existe. Y SAP acaba de decir, por escrito, que está prohibido.
La SAP API Policy v.4.2026
En abril de 2026, SAP publicó una actualización de su política de uso de APIs. Sin comunicado. Sin keynote. Dos páginas en el sitio oficial que la mayoría del ecosistema no ha leído todavía.
La sección 2.2.2 establece que SAP prohíbe el uso de sus APIs para interacción o integración con sistemas de IA autónomos o generativos que planifiquen, seleccionen o ejecuten secuencias de llamadas API, salvo que se haga a través de arquitecturas expresamente endorsadas por SAP.
Traducido sin jerga legal: ningún agente externo puede orquestar tu sistema SAP libremente llamando directamente a sus APIs. Solo pueden hacerlo los agentes que operan dentro de los canales que SAP ha definido para ello.
Y aquí está el matiz que cambia todo.
SAP no prohíbe Claude, SAP prohíbe el acceso directo
Porque SAP tiene a Claude disponible en BTP AI Core. Y a GPT también. Y a Gemini. SAP no tiene ningún problema con el modelo de lenguaje que uses. No te dice con qué IA tienes que pensar.
Lo que SAP controla es por dónde tienes que pasar para tocar sus datos. Y ese canal es BTP.
Si tu agente corre sobre BTP, usa los conectores oficiales, opera dentro de la arquitectura que SAP ha definido, es perfectamente válido. Puedes usar Claude. Puedes usar GPT. Puedes usar el modelo que quieras. SAP no es el portero que te pregunta quién eres. Es el portero que te pregunta si tienes entrada.
Y la entrada se compra en BTP. Donde SAP cobra.
El modelo de negocio que esta política protege
SAP lleva décadas cobrando por usuarios. Cada persona que accede al sistema tiene una licencia. Ahora SAP está pivotando hacia un modelo de consumo por AI Units: ya no pagas solo por acceder, pagas por lo que el sistema hace.
Ese modelo solo funciona si todo lo que el sistema hace pasa por SAP.
El ejemplo de las facturas de proveedor lo ilustra con claridad. Un proceso que implica varios usuarios con licencias MM y FI queda automatizado por un agente que no tiene licencia y no genera ningún ingreso para SAP, si corre fuera de BTP. El mismo agente, con el mismo modelo por detrás, corriendo sobre BTP, consume AI Units y genera ingreso. La diferencia no es tecnológica. Es de canal.
Multiplicado por los miles de clientes SAP que tienen departamentos de cuentas a pagar, de controlling, de gestión de pedidos, de logística, en todo el mundo, el impacto potencial de dejar ese canal abierto es enorme. La API Policy v.4.2026 no es un documento de gobernanza técnica. Es la formalización jurídica de un modelo de negocio.
Lo que esto implica para clientes y partners
Para los clientes, la pregunta inmediata es qué pasa con las iniciativas que ya tienen en marcha. Muchas empresas llevan meses explorando la automatización de procesos conectando modelos de IA externos a sus sistemas SAP, a menudo porque las capacidades nativas de SAP no estaban todavía disponibles o no cubrían el caso de uso concreto. Con esta política, esas iniciativas quedan en zona de incumplimiento si no pasan por BTP.
Para los partners, la situación es parecida. Hay desarrollos construidos, conectores en producción, demos preparadas sobre la premisa de que las APIs de SAP eran un recurso accesible. La política cambia esa premisa sin un marco de transición definido.
Y la pregunta de fondo para todos es la misma: ¿a qué velocidad va a estar disponible en BTP todo lo que SAP está restringiendo fuera de BTP? Porque el gap entre lo que se prohíbe hoy y lo que SAP entrega mañana es donde va a haber más tensión.
Lo que SAP no dice pero está ahí
SAP tiene un argumento técnico legítimo que no formula con esta claridad: un agente externo que llama directamente a sus APIs escapa también a los controles de rendimiento, seguridad y estabilidad de la plataforma. Si algo falla, SAP no puede garantizar nada porque no controla nada. BTP no es solo la caja registradora. Es también la capa donde SAP puede asegurar que las cosas funcionan como deben.
Ese argumento es razonable. Pero no explica por sí solo por qué esta política aparece ahora, en este momento, cuando el modelo de AI Units empieza a tomar forma.
Lo que queda sin responder
SAP tiene derecho a establecer las condiciones de uso de su plataforma. Eso no está en discusión.
Lo que falta es el marco de transición. Qué pasa con los desarrollos existentes. Qué plazo tienen clientes y partners para adaptarse. Cómo se va a hacer cumplir en la práctica. Y cuándo va a estar disponible en BTP todo lo que esta política restringe fuera de él.
Publicar una política que cierra el perímetro sin responder esas preguntas es, como mínimo, una conversación pendiente.
Porque el agente que procesa facturas sin licencia no va a desaparecer. La pregunta es si SAP consigue que compre la entrada antes de que alguien decida que saltarse la cola es un riesgo manejable.
Jorge Ocampos 