El Digital Omnibus de IA no da una tregua: obliga a rediseñar el cumplimiento mientras Bruselas negocia

El peor momento para desmontar un control es cuando aún no se sabe si dejará de ser obligatorio. Y ese es, precisamente, el riesgo que abre el Digital Omnibus sobre inteligencia artificial: no tanto una improbable amnistía regulatoria como una fase de transición en la que los equipos de compliance deben trabajar con dos calendarios, dos versiones de requisitos y una sola responsabilidad ante el supervisor.

El Parlamento Europeo aprobó el 26 de marzo de 2026 sus enmiendas a la propuesta de Reglamento COM(2025)0836, identificada como procedimiento 2025/0359(COD). El texto, publicado en el Diario Oficial el 2 de septiembre de 2026 como documento P10_TA(2026)0098 y referencia 52026AP0098, trata de simplificar la aplicación de reglas armonizadas de IA mediante modificaciones al Reglamento (UE) 2024/1689 —el AI Act— y al Reglamento (UE) 2018/1139 sobre aviación. La palabra decisiva es «propuesta». La posición parlamentaria de primera lectura no sustituye al AI Act ni convierte automáticamente sus enmiendas en derecho aplicable.

Esto parece una obviedad jurídica, pero no lo es en una entidad con decenas de casos de uso, proveedores de modelos, calendarios de contratación y un comité ejecutivo que ha leído la palabra simplificación en una diapositiva. La simplificación legislativa suele llegar con la promesa de retirar burocracia y, de regalo, entrega una nueva capa de control de versiones: qué obligación está vigente, cuál podría cambiar, quién toma la decisión de aplazar una inversión y cómo se prueba después que esa decisión fue razonable.

Para banca, seguros, plataformas de pagos y proveedores tecnológicos, el Digital Omnibus no elimina el problema de cumplimiento. Lo vuelve más interesante, que es una forma poco amable de decir más difícil de gobernar.

La posición del Parlamento no es la línea de meta

El procedimiento legislativo ordinario del artículo 294 del Tratado de Funcionamiento de la Unión Europea no concluye con la publicación de unas enmiendas parlamentarias. La Comisión presentó COM(2025)0836; el Parlamento ha establecido su posición en primera lectura; falta el recorrido institucional necesario con el Consejo para que exista un texto acordado y, tras ello, una norma adoptada y publicada con sus reglas de entrada en vigor y aplicación.

Conviene separar tres documentos que a menudo terminan mezclados en la misma carpeta de proyecto:

• El AI Act vigente: Reglamento (UE) 2024/1689, directamente aplicable y con un calendario propio en su artículo 113.
• La propuesta de la Comisión: COM(2025)0836, presentada en 2025, que abre la revisión denominada Digital Omnibus on AI.
• La posición del Parlamento: las enmiendas adoptadas el 26 de marzo de 2026, ahora formalmente publicadas en el Diario Oficial.

Confundir las tres piezas lleva a dos errores opuestos. El primero es continuar un programa como si no hubiese debate legislativo alguno, gastando recursos en soluciones que quizá necesiten adaptación. El segundo —más peligroso— consiste en congelar la preparación bajo la cómoda ficción de que una propuesta futura suspende el derecho vigente. No lo hace.

La publicación en el Diario Oficial aporta trazabilidad institucional y permite a los equipos jurídicos comparar texto a texto. No activa por sí sola una exención para proveedores, desplegadores o importadores de sistemas de IA. El dato que debería figurar en cualquier comité de dirección es menos vistoso que un titular sobre desregulación: hasta que el proceso legislativo termine, el inventario de obligaciones debe partir del Reglamento (UE) 2024/1689 tal como esté aplicable y de las fechas que ya han surtido efecto.

El calendario que sigue mandando: 2025 y 2026 no son intercambiables

El artículo 113 del AI Act estableció una aplicación escalonada. El Reglamento entró en vigor el 1 de agosto de 2024. Desde el 2 de febrero de 2025 se aplican las disposiciones sobre prácticas prohibidas del artículo 5 y la obligación de alfabetización en IA del artículo 4. Desde el 2 de agosto de 2025 se aplican, entre otras, las normas para modelos de IA de uso general del capítulo V, la estructura de gobernanza y el régimen sancionador, con las salvedades que el propio artículo 113 contempla.

La fecha crítica de este año fue el 2 de agosto de 2026. Ese hito activa la parte central del régimen para sistemas de alto riesgo y otras obligaciones generales, salvo las reglas con calendario diferido. Para determinados sistemas de alto riesgo vinculados a productos regulados del artículo 6, apartado 1, el plazo llega el 2 de agosto de 2027. No es una distinción académica: un motor de selección de candidatos para un banco y un componente de IA de un producto sujeto a legislación sectorial de seguridad no recorren necesariamente el mismo carril temporal.

El artículo 6 divide el análisis de alto riesgo en dos. El apartado 1 cubre sistemas que son productos o componentes de seguridad sujetos a la normativa de armonización de la Unión incluida en el anexo I y que requieren evaluación de conformidad de terceros. El apartado 2 remite a los casos de uso del anexo III: empleo, educación, acceso a servicios esenciales, aplicación de la ley, migración o administración de justicia, entre otros. Una aseguradora que automatiza elementos sustanciales de la tarificación de seguros de vida o salud, o una entidad que usa IA para evaluar la solvencia de personas físicas, no puede tratar el anexo III como un apéndice decorativo.

El detalle incómodo es que el Digital Omnibus llega después de que varias obligaciones ya fueran aplicables y justo cuando la aplicación de buena parte del núcleo operativo del AI Act ha entrado en fase real. Los programas maduros no deberían tirar su trabajo; deberían etiquetarlo. Cada control necesita una de estas tres marcas: «obligación vigente», «medida prudencial independiente de la ley» o «elemento condicionado al resultado legislativo». Sin esa separación, cualquier cambio político acabará presentado como una razón retrospectiva para justificar una carencia previa.

Lo que debe sobrevivir a cualquier simplificación

La discusión política suele concentrarse en formularios, umbrales y cargas para empresas. Pero algunos controles tienen una vida útil que no depende de que el legislador simplifique una plantilla. En una entidad financiera, siguen siendo necesarios porque reducen errores de crédito, discriminación, fraude, pérdida de datos o indisponibilidad operativa. El compliance sensato no confunde un requisito legal revisable con una práctica prescindible.

Inventario con dueño, finalidad y versión

El punto de partida es un inventario que no se limite a la etiqueta «IA». Debe identificar el sistema, modelo o servicio; su proveedor; la versión desplegada; los datos de entrada; las decisiones o recomendaciones que produce; las personas afectadas; el responsable de negocio; el propietario técnico; la geografía de tratamiento y la integración con procesos críticos. Para un modelo de propósito general consumido por API, el objeto controlado no es únicamente el chatbot visible: es también el proveedor, la configuración, las instrucciones del sistema, la capa de recuperación de información, los conectores y las decisiones humanas que el flujo altera.

El artículo 9 del AI Act exige a los proveedores de sistemas de alto riesgo un sistema de gestión de riesgos continuo e iterativo. Los artículos 11 y 12 exigen documentación técnica y capacidades de registro. Que el Digital Omnibus pudiera modificar la mecánica de aplicación no convierte en inútil saber qué versión del modelo rechazó una solicitud de crédito, qué variables influyeron, qué alerta generó el sistema o qué operador intervino. Sin esa información tampoco se investiga un incidente, se gestiona una reclamación ni se defiende una decisión ante un supervisor prudencial.

Clasificación jurídica antes que compra tecnológica

La secuencia correcta empieza por el caso de uso, no por el contrato del proveedor. Un modelo generativo que redacta borradores internos puede activar riesgos de confidencialidad, propiedad intelectual o calidad, pero no por ello es automáticamente un sistema de alto riesgo. Un sistema aparentemente modesto que puntúa candidatos, determina acceso al crédito o influye materialmente en una decisión de seguro puede estar mucho más cerca del anexo III.

El artículo 26 impone obligaciones a los desplegadores de sistemas de alto riesgo, incluido el deber de adoptar medidas técnicas y organizativas adecuadas, asignar supervisión humana a personas con competencia, vigilar el funcionamiento a partir de los registros y, cuando controlen los datos de entrada, garantizar que sean pertinentes y suficientemente representativos en vista de la finalidad. Para ciertos usos del anexo III, el artículo 27 exige una evaluación de impacto sobre los derechos fundamentales antes del despliegue; su ámbito concreto requiere lectura cuidadosa de la disposición, no una casilla genérica de «impacto ético».

El error habitual es pedir al fabricante una declaración y dar el expediente por cerrado. Una entidad financiera es a menudo desplegadora, pero puede convertirse en proveedora si desarrolla un sistema de alto riesgo o lo modifica sustancialmente, conforme a las reglas de la cadena de valor del AI Act. El título del contrato no resuelve la función regulatoria. Tampoco la resuelve una presentación comercial que jura que el producto es «asistivo» mientras el gestor sigue de forma rutinaria su recomendación sin una revisión significativa.

La supervisión humana debe poder discrepar de verdad

El artículo 14 no pide colocar un nombre humano al final de una cadena automatizada. Exige que los sistemas de alto riesgo se diseñen y desarrollen de forma que puedan ser supervisados eficazmente por personas físicas durante su uso. La supervisión tiene que permitir comprender limitaciones, interpretar resultados, decidir no usar el sistema, ignorar o revertir su salida y detenerlo cuando proceda.

Eso exige indicadores operativos: porcentaje de decisiones anuladas, motivos de anulación, diferencias de resultados entre cohortes relevantes, tiempo transcurrido hasta la revisión humana y tasa de casos en los que el revisor simplemente confirma la recomendación. Si la tasa de confirmación es casi total y nadie puede explicar qué circunstancias justifican un desacuerdo, no hay supervisión humana; hay una firma humana al pie de una automatización. La diferencia importa mucho cuando la decisión afecta al acceso a un producto financiero o asegurador.

El verdadero trabajo: gobernar la incertidumbre sin inventar una moratoria

El Digital Omnibus obliga a crear una disciplina que muchas organizaciones no han necesitado con tanta intensidad: la gestión del cambio legislativo como control operativo. El equipo jurídico no puede limitarse a enviar una alerta. Debe traducir cada fase institucional en decisiones sobre diseño, evidencias, contratos y presupuestos.

Un buen registro de cambios legislativos para esta propuesta debería incluir la referencia COM(2025)0836, la posición parlamentaria P10_TA(2026)0098, la fecha de adopción de las enmiendas —26 de marzo de 2026—, la publicación de 2 de septiembre de 2026, las disposiciones internas potencialmente afectadas y un propietario por cada decisión. Cuando exista un texto acordado, esa matriz permitirá saber qué control se mantiene, qué documento se actualiza y qué capacitación debe revisarse. Sin ella, la organización descubrirá tarde que tenía políticas aprobadas contra una versión del marco que ya no era la relevante.

Hay cuatro decisiones que conviene no diferir:

1. Mantener una matriz de obligaciones vigente. Debe diferenciar los artículos ya aplicables del AI Act, los requisitos sometidos a transición y las propuestas parlamentarias. «Pendiente de negociación» no es un estado de cumplimiento.
2. Diseñar controles modulares. La documentación, la evaluación de riesgos y la trazabilidad deben poder ajustarse por caso de uso, papel en la cadena de valor y criticidad. Un programa monolítico sufre cada modificación normativa como una reimplantación.
3. Introducir cláusulas de cambio normativo en los contratos. Para proveedores de modelos, herramientas de monitorización y servicios de IA, el contrato debería exigir cooperación documental, notificación de cambios materiales, apoyo a auditorías y una asignación clara de costes ante cambios regulatorios. No basta con una promesa de «cumplimiento con la legislación aplicable»; esa frase es el equivalente contractual de una puerta sin cerradura.
4. Crear un comité de decisión con fecha de caducidad. Legal, riesgo, seguridad, protección de datos, compras, negocio y auditoría interna deben revisar las decisiones adoptadas por la incertidumbre legislativa. Cada excepción o aplazamiento necesita una fecha de revisión, una hipótesis explícita y un responsable ejecutivo.

La complejidad no viene solo de Bruselas. Un banco puede comprar un modelo de propósito general a un proveedor global, ajustarlo con datos propios, integrarlo en un flujo de atención al cliente y desplegarlo a través de un tercero de cloud. En ese recorrido aparecen obligaciones de proveedor, desplegador, encargado del tratamiento, proveedor TIC crítico o subcontratista. El Organigrama no suele reflejar esas fronteras; el incidente, sí.

Impacto regulatorio cruzado: cinco marcos, una misma evidencia mal coordinada

El atractivo retórico del Digital Omnibus es la simplificación. Su límite práctico se llama solapamiento regulatorio. Aunque cambie la forma de implementar partes del AI Act, una entidad financiera europea sigue respondiendo a obligaciones de resiliencia digital, protección de datos, ciberseguridad y gobierno sectorial. La buena noticia es que una arquitectura de evidencias bien diseñada puede servir a varios marcos. La mala es que una misma carpeta no demuestra automáticamente el cumplimiento de todos.

AI Act y GDPR: una evaluación no reemplaza a la otra

Un sistema que perfila clientes o apoya decisiones sobre crédito, seguros o fraude puede requerir análisis simultáneo bajo el AI Act y el Reglamento General de Protección de Datos. El artículo 35 del GDPR obliga a realizar una evaluación de impacto relativa a la protección de datos cuando sea probable que un tratamiento entrañe alto riesgo para los derechos y libertades de las personas físicas. El artículo 22 restringe las decisiones basadas únicamente en tratamiento automatizado que produzcan efectos jurídicos o afecten significativamente de modo similar a una persona, con excepciones y salvaguardas específicas.

La evaluación de impacto en derechos fundamentales del artículo 27 del AI Act, cuando aplique, no sustituye una DPIA del artículo 35 del GDPR. Cambian el objeto, el umbral y las preguntas. La DPIA analiza, entre otros elementos, necesidad, proporcionalidad y riesgos del tratamiento de datos personales. La evaluación del AI Act se orienta a impactos sobre derechos fundamentales derivados del uso del sistema. Compartir el inventario del caso de uso, los grupos afectados, el flujo de datos y los controles es eficiente; fundir ambos análisis en un documento indistinto es una forma excelente de no satisfacer del todo ninguno.

También sobreviven las obligaciones de seguridad y notificación de brechas del GDPR. El artículo 32 exige medidas técnicas y organizativas apropiadas; el artículo 33 fija, en general, 72 horas para que el responsable notifique una violación de seguridad a la autoridad de control cuando sea probable que suponga un riesgo para los derechos y libertades. Un asistente de IA que expone datos de clientes a un destinatario no autorizado no se vuelve menos incidente porque su modelo tenga documentación impecable.

AI Act, DORA y NIS2: la resiliencia no es explicabilidad

Desde el 17 de enero de 2025, DORA es aplicable a las entidades financieras dentro de su perímetro. Sus artículos 5 a 16 sitúan la gestión del riesgo TIC bajo responsabilidad del órgano de dirección; el artículo 17 regula el proceso de gestión de incidentes relacionados con las TIC; y los artículos 28 a 30 endurecen la gestión de riesgos de terceros proveedores de servicios TIC.

Si una entidad usa un proveedor externo de IA en una función crítica o importante, la pregunta no termina en si el modelo es conforme al AI Act. Hay que determinar si el servicio forma parte de una función crítica o importante a efectos de DORA, aplicar la estrategia sobre riesgo de terceros del artículo 28 y revisar que el contrato contenga las cláusulas exigidas por el artículo 30. La dependencia de una API, de un proveedor de alojamiento, de una plataforma de datos y de un subcontratista puede crear una concentración que ningún análisis de sesgo va a detectar.

NIS2, por su parte, exige medidas de gestión de riesgos de ciberseguridad en su artículo 21 para las entidades esenciales e importantes incluidas en su ámbito y articula deberes de notificación de incidentes en el artículo 23. La evaluación de robustez y ciberseguridad de un sistema de IA conversa con esos controles, pero no desplaza el análisis de cadena de suministro, continuidad de negocio, gestión de vulnerabilidades o autenticación multifactor. Un modelo puede ser preciso y, a la vez, estar integrado de forma insegura. La precisión no cifra secretos ni sustituye una arquitectura de recuperación.

La convergencia útil está en la prueba, no en los eslóganes

La evidencia reutilizable tiene una forma bastante concreta: un inventario de sistemas y proveedores; una clasificación de criticidad; registros de cambios de modelo y de datos; resultados de pruebas; actas de aprobación; análisis de impacto; ejercicios de respuesta a incidentes; y contratos que describan derechos de acceso, auditoría, información y salida. DORA, GDPR, NIS2 y AI Act pedirán esa evidencia desde ángulos distintos. La solución no es crear cuatro repositorios idénticos, sino establecer un repositorio maestro con metadatos que indiquen qué obligación respalda cada elemento y durante qué periodo.

El Consejo de Administración tampoco puede delegar este choque de marcos a una oficina de innovación. DORA atribuye al órgano de dirección responsabilidad última sobre el marco de gestión de riesgo TIC en su artículo 5. El AI Act atribuye obligaciones según el rol de operador económico. GDPR identifica responsabilidades de responsable y encargado. El cruce no disminuye la rendición de cuentas: multiplica las preguntas que llegarán después de una decisión automatizada errónea o de un incidente.

Banca y seguros: donde la IA deja de ser un copiloto

La prudencia es particularmente necesaria en crédito, seguros y prevención del fraude. En esos entornos, una salida algorítmica puede modificar un precio, denegar acceso a un servicio esencial, priorizar una investigación o condicionar una relación contractual. La etiqueta comercial de «herramienta de apoyo» debe ser sometida a una prueba sencilla: ¿cambiaría materialmente la decisión humana si el sistema no existiera? Si la respuesta es sí, el control debe ser mucho más exigente.

Para una entidad española o europea, la secuencia operativa debería incluir una clasificación del uso frente al artículo 6 y anexo III del AI Act; un análisis de la función bajo DORA; una DPIA cuando se alcance el umbral del artículo 35 del GDPR; y una revisión de los deberes de información y derechos vinculados a decisiones automatizadas. En seguros, la calidad y representatividad de datos históricos merece escrutinio especial: las bases de siniestralidad pueden reproducir sesgos geográficos, socioeconómicos o de acceso que no desaparecen porque un modelo los procese con mayor elegancia matemática.

Los controles que ofrecen valor ahora no dependen de adivinar el resultado de la negociación del Omnibus: validación independiente previa al despliegue; límites de uso definidos por política; pruebas de degradación y de comportamiento fuera de distribución; umbrales de escalado a revisión humana; monitoreo de deriva; segregación de datos de producción y de prueba; controles contra inyección de instrucciones y exfiltración de datos; y un mecanismo para desactivar el sistema sin detener un proceso crítico entero.

En modelos generativos, la gobernanza debe incluir el contenido recuperado por sistemas RAG, no solo el modelo base. Una respuesta incorrecta que cita una política interna obsoleta puede generar una recomendación comercial o regulatoria equivocada aunque el modelo funcione tal como fue diseñado. Esto es menos glamuroso que debatir sobre inteligencia artificial general, pero es el tipo de fallo que produce reclamaciones reales el lunes por la mañana.

Qué vigilar después de la publicación de septiembre

La publicación del documento 52026AP0098 permite por fin una comparación jurídica ordenada entre la propuesta de la Comisión y la posición del Parlamento. El siguiente seguimiento debe centrarse en el texto que pueda resultar de las negociaciones interinstitucionales, en cualquier acuerdo político que se formalice y, sobre todo, en la redacción definitiva de disposiciones transitorias y fechas de aplicación. Ahí se decide si una simplificación es cosmética, si cambia un plazo, si modifica categorías de operadores o si aligera una carga documental concreta.

Hasta entonces, la reacción responsable no es ni el pánico ni el inmovilismo. Es conservar controles esenciales, evitar inversiones irreversibles basadas únicamente en un texto no final y documentar de forma disciplinada cada decisión de transición. Las organizaciones que saldrán mejor paradas no serán las que anuncien antes que «ya cumplen con la IA», una afirmación que suele envejecer deprisa. Serán las capaces de demostrar qué aplicaba el 2 de agosto de 2026, qué cambió cuando cambió y por qué sus sistemas seguían bajo control mientras los colegisladores discutían cómo simplificar el papel.

El Digital Omnibus puede acabar reduciendo carga administrativa. Ojalá. Pero hasta que exista una norma final, su efecto inmediato es recordar una verdad poco popular: en regulación tecnológica, la incertidumbre también se gobierna. Y se gobierna con fechas, versiones, responsables y pruebas; no con titulares tranquilizadores.