En corto, para quien decide
El Digital Omnibus sobre IA ya es ley. El Reglamento (UE) 2026/1744 entró en vigor el 27 de julio de 2026 y aplaza las obligaciones de alto riesgo al 2 de diciembre de 2027 (anexo III) y al 2 de agosto de 2028 (anexo I).
La mayoría del trabajo técnico es difícil de añadir al final. Registros, supervisión y linaje de datos condicionan el diseño del sistema.
La primera tarea es clasificar. Lo que un sistema hace exactamente determina si es de alto riesgo: puntuar a un solicitante de crédito entra, detectar fraude financiero queda fuera.
Las normas armonizadas están llegando con retraso. Solo una ha sido citada en el Diario Oficial, y conviene diseñar por requisitos sin esperar al resto.
El calendario vigente
| Fecha | Qué aplica | Situación |
|---|---|---|
| 2/2/2025 | Definiciones, alfabetización en IA y prohibiciones | Aplicable |
| 2/8/2025 | Obligaciones de modelos de propósito general y gobernanza | Aplicable |
| 2/8/2026 | Aplicación general, transparencia del art. 50 e inicio de la ejecución | Aplicable |
| 2/12/2026 | Nuevas prohibiciones y fin de la transición del art. 50.2 para sistemas previos | Aprobado |
| 2/8/2027 | Un sandbox nacional operativo por Estado y modelos de propósito general previos a agosto de 2025 | Aprobado |
| 2/12/2027 | Requisitos de alto riesgo del anexo III | Aprobado |
| 2/8/2028 | Requisitos de alto riesgo del anexo I, sección A (la sección B se rige por su legislación sectorial) | Aprobado |
| 2/8/2030 | Alto riesgo destinado a autoridades públicas ya en el mercado | Aprobado |
Las fechas proceden del texto publicado en el DOUE y del calendario de la Comisión. Desde el 2 de agosto de 2026 la Oficina de IA y las autoridades nacionales están en fase de ejecución. Otro expediente distinto, el Omnibus de datos, RGPD y ciberseguridad (2025/0360), sigue en tramitación y no debe confundirse con este.
Clasificar antes de diseñar
El anexo III incluye, entre otros, selección y gestión laboral, solvencia y calificación crediticia de personas físicas, salvo la detección de fraude financiero, y riesgo y precio en seguros de vida y salud. El artículo 6.3 permite excluir ciertos sistemas sin riesgo significativo, siempre que encajen en uno de sus cuatro supuestos, nunca si elaboran perfiles, documentando la evaluación y registrando el sistema en la base de datos de la UE.
El borrador de directrices de la Comisión, de mayo de 2026, aún no es definitivo ni vinculante, pero aporta ejemplos útiles.
| Ámbito | Dentro, según el borrador | Fuera o exento, según el borrador |
|---|---|---|
| Crédito | Puntuación numérica para préstamos o hipotecas | Marketing que no intervenga en la solvencia, seguimiento de exposición tras la concesión solo con fines prudenciales internos |
| Seguros | Revisión de solicitudes de seguro de vida que orienta aceptación y condiciones, predicción del coste médico de un grupo que fija su prima | Gestión de siniestros en salud |
| Empleo | Ranking de candidatos, asignación de turnos por rendimiento | Exentos por el art. 6.3, con documentación y registro: verificación de credenciales, programación de entrevistas |
De ahí se deriva una consecuencia arquitectónica: la clasificación se aplica a la finalidad, y un mismo componente puede servir a varias. Un asistente que resume expedientes puede pasar de apoyo administrativo a influir en una decisión de crédito con un cambio en el flujo de trabajo. El inventario debe registrar cada caso de uso por separado y disparar una revisión cuando cambie.
De artículo a componente
La columna derecha es una propuesta técnica de allrework. El reglamento fija el resultado y deja a cada organización la manera de lograrlo.
| Artículo | Exigencia | Componente |
|---|---|---|
| 9 | Gestión de riesgos iterativa, con métricas y umbrales predefinidos | Registro de riesgos versionado y conectado a CI/CD y a la monitorización |
| 10 | Prácticas de gobernanza sobre origen, preparación, sesgos y lagunas | Linaje de datos y versiones de datasets |
| 11 y anexo IV | Documentación técnica de arquitectura, datos, validación y cambios | Documentación generada desde el pipeline |
| 12 | Registro automático de eventos durante toda la vida útil | Telemetría con esquema definido y almacenamiento a prueba de manipulación |
| 13 | Instrucciones con métricas de exactitud, límites y uso de los registros | Ficha del sistema por versión |
| 14 | Comprender, ignorar, revertir y detener | Interfaz de revisión, anulación auditada y parada segura |
| 15 | Exactitud, solidez y ciberseguridad | Evaluación continua, pruebas adversarias y control de bucles |
| 26 | Monitorizar, suspender, notificar, conservar registros | Alertas, procedimiento de suspensión y retención mínima |
| 27 | Evaluación de impacto en derechos fundamentales | Plantilla ligada al inventario de casos de uso |
Registros: un esquema, varios destinatarios
El artículo 12 pide que el sistema sea técnicamente capaz de registrar eventos que sirvan para detectar riesgos y modificaciones sustanciales, alimentar la vigilancia poscomercialización y permitir la monitorización de quien despliega. Los logs de aplicación rara vez cumplen esa función, porque se diseñan para depurar y se rotan con criterios de coste.
Un evento útil identifica la versión del sistema, del modelo y del prompt, la procedencia de los datos de entrada o su huella, la salida, la confianza si existe, la intervención humana y la decisión final. El artículo 26 exige a quien despliega conservar los registros bajo su control al menos 6 meses, y el artículo 18 impone 10 años a la documentación del proveedor. El proveedor conserva sus logs al menos 6 meses según el artículo 19, salvo otra norma aplicable, y las entidades financieras los integran en su documentación sectorial. Esos registros contendrán datos personales con frecuencia, y su diseño debe conciliar la retención con el RGPD: seudonimización, separación de claves y borrado por interesado cuando proceda.
Supervisión humana: una función de diseño
El artículo 14 exige que el diseño, incluida la interfaz, permita, según proceda y de forma proporcionada, comprender los límites del sistema, detectar anomalías, advertir del sesgo de automatización, interpretar resultados, ignorar o revertir la salida y detenerlo de forma segura. Una casilla de aprobación no cubre esa lista.
Hay indicios de fatiga de aprobación en herramientas de agentes, y es previsible en cualquier cola de revisión. El diseño puede combatirla con varias medidas: mostrar la evidencia antes que la recomendación, medir tasas de anulación por revisor, introducir casos de control con respuesta conocida y asignar volumen compatible con una revisión real. El artículo 26 añade que la persona designada debe tener competencia y autoridad, de modo que el requisito alcanza también a la organización del trabajo.
Datos: linaje y un cambio importante
El artículo 10 pide prácticas de gobernanza sobre origen, preparación, supuestos, sesgos, lagunas y representatividad para el contexto de uso. El Omnibus suprime su apartado 5 y crea un artículo 4a, que permite tratar categorías especiales para detectar y corregir sesgos solo cuando sea estrictamente necesario y con salvaguardas. Quien trate categorías especiales para medir sesgos deberá probar que otros datos no bastan, limitar técnicamente la reutilización, restringir y registrar los accesos, impedir el acceso de terceros, borrar los datos al terminar y justificar por escrito la necesidad. Un entorno separado es una forma razonable de lograrlo. En sistemas con recuperación documental, el concepto se extiende al corpus, tal como se detalla en RAG en sectores regulados.
Exactitud y ciberseguridad
El artículo 15 exige rendimiento sostenido durante el ciclo de vida, control de bucles de retroalimentación en sistemas que siguen aprendiendo y, cuando proceda, defensa frente a envenenamiento, ejemplos adversarios y ataques de confidencialidad. Las métricas declaradas en las instrucciones deben corresponder a lo medido, así que la evaluación continua puede servir como evidencia para sostenerlas. El Omnibus incorpora al artículo 42.3 la presunción que ya preveía el artículo 12 del Reglamento (UE) 2024/2847, sobre ciberresiliencia: los sistemas de alto riesgo dentro de su ámbito que cumplan sus condiciones se consideran conformes con la ciberseguridad del artículo 15, algo que conviene coordinar con los equipos de seguridad de producto.
Control de cambios: la cláusula que afecta a lo que ya funciona
Según el artículo 111, los sistemas de alto riesgo introducidos antes de la fecha de aplicación del capítulo III (2/12/2027 o 2/8/2028, por tipo y modelo según el considerando 39) solo quedan sujetos si desde entonces sufren cambios significativos de diseño, salvo los destinados a autoridades públicas, que deben cumplir antes del 2/8/2030. La norma no dice que cambiar de modelo o reentrenar lo sea automáticamente, pero esa decisión rutinaria pasa a ser una pregunta con efecto jurídico. Un sistema de gestión de cambios debería clasificar cada modificación y dejar constancia del razonamiento, además de separar los cambios predeterminados y documentados, previstos en el anexo IV para sistemas que siguen aprendiendo, de los que pueden ser una modificación sustancial. En un sistema heredado, un cambio así activa el cumplimiento completo.
Proveedor, responsable del despliegue y cadena de modelos
Una organización que construye un sistema sobre un modelo de terceros y lo comercializa o pone en servicio bajo su nombre para un uso de alto riesgo será proveedora de ese sistema, según el artículo 3.3. También lo será quien cambie la finalidad de un sistema existente hasta hacerlo de alto riesgo, y el artículo 25 exige un acuerdo escrito con el suministrador sobre la información y el acceso técnico necesarios. Conviene exigir al proveedor del modelo la documentación prevista para modelos de propósito general. El Código de buenas prácticas es voluntario y cuenta con 22 firmantes según la página de la Comisión actualizada en octubre de 2026, y el artículo 53 lo admite como forma de demostrar cumplimiento hasta que existan normas armonizadas. La Comisión puede imponer multas a estos proveedores desde el 2 de agosto de 2026, y los modelos comercializados antes del 2 de agosto de 2025 tienen hasta el 2 de agosto de 2027 para cumplir.
El artículo 27 obliga a evaluar el impacto antes del primer uso a los responsables del despliegue de sistemas de alto riesgo que sean organismos de Derecho público o entidades privadas que presten servicios públicos, salvo en infraestructuras críticas, y a quienes desplieguen los sistemas de crédito y seguros de los puntos 5.b y 5.c. El Omnibus permite remitir a la evaluación de impacto de protección de datos para lo que ya cubra, y no nos consta que la plantilla de la Oficina de IA se haya publicado.
Normas: diseñar sin esperar al resto
EN 18286:2026, sobre sistema de calidad, es la primera norma armonizada citada en el Diario Oficial, y su presunción de conformidad cubre solo los requisitos del artículo 17 que abarca. Las normas de riesgos, registros, supervisión, exactitud, ciberseguridad y datos continúan en elaboración, tras las medidas excepcionales aprobadas por CEN y CENELEC en 2025. ISO/IEC 42001 ordena la gestión de la IA en la organización y sirve de buen punto de partida, sin que su certificación otorgue por sí sola presunción de conformidad con el reglamento.
La arquitectura por requisitos permite absorber esas normas cuando lleguen. Cada control se vincula a un artículo y a una evidencia, y el mapeo se actualiza sin rehacer el sistema.
España
El Real Decreto 729/2023 aprobó el Estatuto de AESIA, que ha publicado 16 guías no vinculantes y anuncia su actualización tras el Omnibus. El proyecto de ley de desarrollo, que designaba, entre otras, a AESIA, Banco de España, CNMV y DGSFP en sus respectivos ámbitos, no consta aprobado antes de la disolución de las Cortes de octubre de 2026. El reglamento europeo sigue aplicándose, y conviene seguir qué autoridad y qué régimen sancionador acaban fijándose para cada sector.
Plan de trabajo razonable
Inventariar sistemas y casos de uso, y clasificarlos con la decisión documentada.
Determinar el papel en cada uno: proveedor, responsable del despliegue o ambos.
Definir un esquema común de eventos y empezar a capturarlo en lo que ya está en producción.
Montar evaluación continua y control de cambios.
Rediseñar los puntos de supervisión con quienes van a ejercerla.
Renegociar contratos con proveedores de modelos y plataformas.
Vincular cada control a su artículo y a la norma correspondiente cuando se publique.
La Revisión AI Act de allrework cubre las tres primeras etapas: inventario, clasificación y plan de adecuación.
Información consultada a 8 de noviembre de 2026. Este artículo ofrece una lectura técnica y no constituye asesoramiento jurídico.
