Gobernanza de la IA en SAP: cumplimiento, seguridad y responsabilidad

La gobernanza de la IA en SAP abarca cada función de IA que se ejecuta en S/4HANA, SuccessFactors, Ariba, Concur o en SAP BTP. De cada una necesita saber quién responde de sus decisiones, qué datos usa, cómo se registra y cuándo se revisa. El calendario regulatorio se movió en 2026: las obligaciones de la Ley de IA de la UE para los sistemas de alto riesgo independientes, como la IA usada en contratación, se aplican ahora desde el 2 de diciembre de 2027. Las obligaciones de transparencia sobre el contenido generado por IA ya se aplican. Esta guía es para CIO, responsables de cumplimiento y propietarios de programas SAP. Recorre dónde aparecen primero las brechas de gobernanza, qué cambió en 2026, las normas que se aplican y un registro con el que puede empezar esta semana. Empiece nombrando a un responsable por cada función de IA.

Empiece con una pregunta sencilla: cuando un modelo entrega un resultado, ¿quién da la cara? Si la respuesta no está clara, tiene una brecha de gobernanza.

Los entornos SAP están abarrotados: S/4HANA en el núcleo, CRM en la nube, analítica complementaria, sistemas heredados que nadie quiere tocar. Un ingeniero puede desplegar un modelo en minutos. Rastrear su efecto en la contratación, el crédito o la planificación del suministro puede llevar semanas.

Los datos lo complican más. La nómina, los pedidos de compra, el inventario y las valoraciones de proveedores llegan en formatos distintos y bajo responsables distintos. Un equipo enmascara los identificadores personales; otro los deja expuestos. Antes de que se ejecute cualquier modelo, decida qué datos puede usar, quién aprueba los cambios y cuánto tiempo se conservan los registros. Póngalo por escrito, revíselo y hágalo cumplir.

Vi un despliegue en el que la previsión de inventario funcionaba casi demasiado bien. Se hacían pedidos por adelantado a la demanda, algo que en el panel parecía eficiente. Entonces llamó finanzas. La caja se había resentido y nadie sabía quién tenía la última palabra sobre el comportamiento del modelo. La lógica estaba enterrada. Ahí es cuando la gobernanza se vuelve real, y no una diapositiva en una presentación.

Los patrones que sigo viendo:

Finanzas. La IA en S/4HANA Finance ayuda con el procesamiento de facturas, la previsión de caja y la detección de anomalías. Es útil hasta que deja de serlo: un pago legítimo bloqueado, uno dudoso aprobado, una previsión basada en datos obsoletos. La solución es una pista de auditoría en cada decisión influida por la IA y una persona con nombre que la revise.

Compras. La IA recomienda proveedores, señala riesgos y revisa contratos. Si los datos históricos de compras arrastran un sesgo, como proveedores preferidos por motivos que nadie ve, el modelo lo repite. Alguien tiene que revisar las preselecciones en lugar de aceptarlas.

RR. HH. La IA en SuccessFactors puede ayudar a filtrar candidatos y analizar el compromiso de los empleados. Entrenada con datos de contratación que ya se inclinaban hacia ciertos perfiles, sigue inclinándose. Pruebe el sesgo antes del despliegue y de nuevo tras cada reentrenamiento.

Manufactura. Los modelos de mantenimiento predictivo y de programación se degradan cuando se reconfigura una planta. Haga seguimiento de la precisión a lo largo del tiempo y programe reentrenamientos. No espere a una parada de línea para notar la desviación.

La IA en las aplicaciones en la nube de SAP tiende a llegar sin hacer ruido: conciliación de facturas en Ariba, aprobaciones en Concur, puntuación de leads en CRM. Funciona en segundo plano, que es lo que la hace atractiva. También dificulta la supervisión.

Recuerdo a un cliente que usaba inteligencia embebida en SAP Ariba. El sistema empezó a señalar proveedores duplicados de forma automática. Útil, pero nadie se dio cuenta de que las alertas se disparaban a veces por nombres inconsistentes en los datos maestros. Sin mala intención, solo registros que no coincidían. Compras no tenía ningún proceso para validar las alertas, y eso causó retrasos y confusión. La solución es un paso de validación de las alertas y una convención de nombres coherente en el maestro de proveedores.

SAP BTP. BTP permite a los equipos construir y desplegar su propia IA en todo el entorno SAP. He visto un modelo aprobar proveedores malos porque se entrenó con datos de compras incompletos. El problema de datos vino antes que el problema de IA, y limpiar la entrada lo arregló más rápido que ajustar el modelo.

SAP Concur. La IA de gastos detecta duplicados e incumplimientos de la política. También genera falsas alertas de fraude en reclamaciones legítimas, y cuando los empleados dedican tiempo a disputar los rechazos la ganancia de productividad desaparece. Mantenga la revisión humana para los casos dudosos y actualice las reglas cada vez que cambie la política de gastos.

Las fechas de alto riesgo de la Ley de IA de la UE se movieron. El Ómnibus Digital sobre IA, Reglamento (UE) 2026/1744, entró en vigor el 27 de julio de 2026. Las obligaciones para los sistemas de alto riesgo independientes del Anexo III, que incluyen la IA usada en contratación y gestión de trabajadores y en las comprobaciones de solvencia de personas físicas, se aplican ahora desde el 2 de diciembre de 2027. La IA de alto riesgo integrada en productos regulados llega el 2 de agosto de 2028. Las prácticas prohibidas y la alfabetización en IA se aplican desde febrero de 2025, y las obligaciones de transparencia del artículo 50 sobre el contenido generado por IA, desde el 2 de agosto de 2026. El aplazamiento es margen de maniobra, no un alivio. La evaluación de conformidad y la documentación técnica son trabajo lento.

1. 2025Prácticas prohibidas y alfabetización en IADesde febrero de 2025
2. 2026Ómnibus Digital en vigor27 de julio, Reglamento (UE) 2026/1744
3. 2026Obligaciones de transparencia sobre el contenido generado por IA2 de agosto, artículo 50
4. 2027Sistemas de alto riesgo independientes (Anexo III)2 de diciembre. Contratación, gestión de trabajadores, comprobaciones de solvencia de personas físicas
5. 2028IA de alto riesgo integrada en productos regulados2 de agosto

Fuente: Reglamento (UE) 2026/1744, Ómnibus Digital sobre IA

El registro de Joule depende de una decisión que quizá ya tomó. Los registros de conversaciones de Joule recogen el usuario, la marca de tiempo, la conversación, los prompts y las respuestas. Solo existen si se activó el almacenamiento al incorporar Joule. La retención predeterminada documentada por SAP para esos registros es de 365 días, y puede solicitar un periodo distinto. Compruebe el ajuste y si la retención cubre su ciclo de auditoría.

SAP restringió los agentes de IA en sus API. La política de API de SAP (versión 4.2026a) restringe el uso de las API de SAP con sistemas de IA semiautónomos o generativos que planifican, seleccionan o ejecutan secuencias de llamadas a API. Ese uso solo se permite a través de arquitecturas y vías respaldadas por SAP. Si un agente o copiloto de terceros llama directamente a S/4HANA, ahora es una cuestión contractual además de una cuestión de seguridad. Haga un inventario de esas integraciones.

Los controles de BTP existen, pero hay que configurarlos. El generative AI hub de SAP ofrece enmascaramiento de datos, filtrado del contenido de entrada y de salida, grounding, un registro de prompts y registro de auditoría. Son controles, no un programa de gobernanza. Un registro activado sin política de retención se borra antes de que una revisión trimestral pueda leerlo.

Si un proveedor no puede aportar la documentación técnica de alto riesgo de una función de IA, esa función no puede seguir en un uso de alto riesgo. El plazo se ha movido. El requisito de documentación no.

Se aplican a las organizaciones que ejecutan IA en SAP, con independencia de dónde aloje SAP el software.

Normativa	Qué exige en la práctica
Ley de IA de la UE	Obligaciones basadas en el riesgo. Los usos de alto riesgo (contratación y gestión de trabajadores, solvencia de personas físicas y otros del Anexo III) requieren gestión de riesgos, documentación, registro, supervisión humana y evaluación de conformidad desde el 2 de diciembre de 2027. Las obligaciones de transparencia ya se aplican
RGPD	Base jurídica y minimización de datos. Para las decisiones basadas únicamente en el tratamiento automatizado con efectos jurídicos o similares, las salvaguardas del artículo 22, incluida la intervención humana e información significativa sobre la lógica aplicada
ISO/IEC 42001:2023	Un sistema de gestión de IA auditable: roles, proceso de riesgos, controles y mejora continua
Marcos nacionales	Los estados del Golfo, Singapur y otros publican principios éticos y marcos de gobernanza de la IA. Revise cada año los de los países donde opera

La clasificación de alto riesgo importa en el caso concreto de SAP. La IA en SuccessFactors que influye en la contratación, la promoción o el despido entra en el ámbito. Las comprobaciones de solvencia de clientes empresariales en S/4HANA, por lo general, no, porque la categoría del Anexo III abarca la solvencia de las personas físicas. Clasifique cada función en lugar de dar nada por supuesto.

El punto de partida práctico es un registro. Una fila por cada función de IA, completada.

Columna	Qué registrar
Función de IA	Por ejemplo, la coincidencia de candidatos en SuccessFactors o la detección de proveedores duplicados en Ariba
Sistema y responsable	La aplicación y una persona responsable con nombre
Categoría según la Ley de IA	Prohibida, alto riesgo (Anexo III), solo transparencia o mínima
Datos utilizados	Fuentes, datos personales, enmascaramiento aplicado
Revisión humana	Quién revisa qué resultados y cuándo puede anularlos
Registro y retención	Dónde se registran las decisiones y durante cuánto tiempo
Cadencia de revisión	Trimestral para funciones de alto impacto, semestral para el resto
Última revisión	Fecha y resultado

1. Nombre a un responsable por cada sistema de IA antes del go-live. Una persona, no un comité. Todos los demás cumplen un papel de apoyo.
2. Mantenga una pista de auditoría de las decisiones influidas por la IA. En la aprobación de facturas, la selección de proveedores o la clasificación de candidatos, registre los datos utilizados, el resultado y cuándo lo revisó una persona.
3. Programe revisiones de los modelos. Los modelos se degradan a medida que cambian los datos. Trimestral es un buen punto de partida para los sistemas críticos. No espere a la queja de un usuario para descubrir tres meses de respuestas erróneas.
4. Implante primero la gobernanza de datos y conecte después la gobernanza de la IA. Las reglas de acceso, los estándares de calidad y el enmascaramiento tienen que existir antes de que la gobernanza de la IA pueda funcionar. Los equipos que construyen ambas a la vez suelen acabar sin ninguna.
5. No confunda gobernanza con documentación. Las políticas en SharePoint no son gobernanza. La gobernanza cambia cómo se toman las decisiones: quién revisa, quién escala y quién puede detener un modelo.

La regulación no deja de moverse. Los cambios de 2026 en la Ley de IA muestran con qué rapidez se desplazan las fechas. Asigne a una persona el seguimiento de los cambios legales y que cada año los traduzca a requisitos específicos de SAP.

Privacidad entre módulos. SAP guarda la nómina, las transacciones de clientes y los registros de empleados. La seguridad basada en roles de SAP no se aplica automáticamente a los datos de entrada de los modelos de IA. Compruébelo de forma explícita.

Sesgo en los datos de entrenamiento. Si un modelo de SuccessFactors aprendió de cinco años de datos de contratación sesgados, repetirá el sesgo. Mire los resultados por grupos antes del despliegue, no solo la precisión.

Sistemas heredados en el flujo de datos. Cuando la IA en BTP extrae datos de un ERP heredado o de una plataforma de terceros, la calidad de datos del sistema más débil se convierte en su límite. Mapee las fuentes antes de que el modelo entre en producción. Mi marco de gestión de riesgos de IA cubre los pasos de evaluación, y mi guía del marco de gobernanza de la IA cubre el modelo operativo más amplio.

¿Qué es la gobernanza de la IA en las implementaciones de SAP?

Es el conjunto de responsables, políticas y controles que hacen que las funciones de IA en SAP operen de forma responsable, transparente y lícita. Abarca qué datos pueden usar los modelos, cómo se aprueban y despliegan las funciones, cómo se registran y revisan las decisiones y quién puede detener un modelo. Se aplica en S/4HANA, SuccessFactors, Ariba, Concur y todo lo que construya sobre SAP BTP.

¿Cuándo se aplican las normas de alto riesgo de la Ley de IA de la UE a los sistemas SAP?

Tras el Ómnibus Digital (Reglamento (UE) 2026/1744), las obligaciones para los sistemas de alto riesgo independientes del Anexo III se aplican desde el 2 de diciembre de 2027. La IA de alto riesgo integrada en productos regulados llega desde el 2 de agosto de 2028. Las prácticas prohibidas y la alfabetización en IA se aplican desde febrero de 2025, y las obligaciones de transparencia sobre el contenido generado por IA, desde agosto de 2026. En SAP, el área de alto riesgo más común es la IA usada en contratación y decisiones sobre la plantilla.

¿Quién es responsable de la gobernanza de la IA en los proyectos SAP?

Un grupo multidisciplinar: cumplimiento sigue la regulación, TI y seguridad gestionan los accesos y el registro, los equipos de datos responden de la calidad de los datos de entrenamiento, los responsables de proceso de negocio validan los resultados y el área jurídica revisa la responsabilidad. La decisión más importante es nombrar a un responsable por cada sistema de IA. Cuando algo falla a las dos de la madrugada, hay que saber a quién se llama.

¿Joule mantiene una pista de auditoría?

Los registros de conversaciones de Joule pueden recoger el usuario, la marca de tiempo, la conversación y los prompts y respuestas, pero solo si se activó el almacenamiento de registros durante la incorporación. SAP documenta una retención predeterminada de 365 días para los clientes que lo activaron, y puede solicitarse un periodo distinto. Los cambios de configuración relevantes para la seguridad en Joule Studio van al servicio SAP Audit Log de BTP. Compruebe el ajuste de su tenant en lugar de darlo por supuesto.

¿Cómo se gestiona el sesgo en los modelos de IA de SAP SuccessFactors?

Revise con qué se entrenó el modelo. Si los datos históricos de contratación perjudicaron a ciertos grupos, el modelo también lo hará. Pruebe los resultados por grupos antes del go-live, supervise las tasas de selección después y reentrene según un calendario a medida que cambien los datos de su plantilla. Si candidatos cualificados de un mismo perfil son filtrados de forma sistemática, trátelo como una señal, no como una coincidencia.

¿Con qué frecuencia deben revisarse los modelos de IA en SAP?

Cada trimestre para los sistemas de alto impacto, como las aprobaciones financieras, las decisiones de RR. HH. o la selección de proveedores, y cada seis meses para las herramientas de menor riesgo. Active una revisión adicional siempre que cambie una fuente de datos, una integración o un proceso de negocio, porque cualquiera de ellos puede alterar el comportamiento del modelo sin que cambie el código.