El calendario ha cambiado, el objetivo final no.
El 27 de julio de 2026 entró en vigor el Ómnibus Digital (Reglamento UE 2026/1744) que, efectivamente, aplaza las obligaciones de los sistemas de IA de alto riesgo: las del Anexo III pasan al 2 de diciembre de 2027 y las del Anexo I al 2 de agosto de 2028. Pero lo que no se ha aplazado es precisamente lo que toca al software que la mayoría de organizaciones ya tiene en producción: las prácticas prohibidas (vigentes desde febrero de 2025), la alfabetización en IA del Artículo 4, las obligaciones de los modelos de propósito general y, la gran novedad de este mes, las obligaciones de transparencia del Artículo 50, en vigor desde el 2 de agosto de 2026.
Transparencia: el requisito que ya está en vigor
El Artículo 50 es la obligación que más equipos técnicos ha pillado desprevenidos, porque no es un requisito jurídico abstracto: es un requisito funcional.
Si tu producto tiene un asistente conversacional, el sistema debe informar de que la persona está interactuando con una IA. Y el reglamento es específico en el cómo: al comienzo de la primera interacción, de forma clara y accesible.
Un disclaimer enterrado en los términos de uso no cumple; un mensaje visible en la primera respuesta del chatbot, sí. Diseñar ese aviso es obligación del proveedor de la herramienta; si integras una de terceros, te toca verificar que viene configurado y no suprimirlo.
Si tu sistema genera contenido sintético —texto, imagen, audio, vídeo—, el marcado técnico del contenido corresponde a quien fabrica la herramienta. Eso significa que si desarrollas productos que generan contenido, el etiquetado (marcas de agua, metadatos legibles por máquina) es ahora parte de tus requisitos de diseño, no un extra opcional.
Esto afecta directamente el definition of done: la transparencia ha dejado de ser una decisión de producto para convertirse en un requisito no funcional más, al nivel de la accesibilidad o la protección de datos.
Qué es exactamente un sistema de alto riesgo
Antes de entrar en los requisitos aplazados, conviene aclarar el concepto, porque no va de tecnología sino de contexto de uso: un sistema es de alto riesgo cuando sus decisiones pueden afectar seriamente a la seguridad o a los derechos fundamentales de las personas.
El reglamento lo concreta en dos listas. El Anexo III cubre ocho áreas sensibles: biometría, infraestructuras críticas, educación, empleo y gestión de trabajadores, acceso a servicios esenciales (crédito, seguros, prestaciones), aplicación de la ley, migración y fronteras, y administración de justicia. El Anexo I cubre la IA integrada en productos ya regulados, como dispositivos médicos o maquinaria industrial.
El ejemplo que sorprende a más de una organización: usar un SaaS que puntúa candidatos en un proceso de selección ya es alto riesgo (Anexo III, área de empleo), aunque no hayas escrito ni una línea del modelo. El criterio es el uso real del sistema, no quién lo construyó ni la antigüedad del software.
Lo aplazado pero inevitable: el alto riesgo, traducido a ingeniería
Aquí está el error estratégico que veo repetirse: interpretar el aplazamiento a diciembre de 2027 como "ya lo miraremos en 2027". Quien haya vivido una adaptación al RGPD a contrarreloj sabe cómo acaba esa película.
Estos son los cinco bloques, traducidos del lenguaje jurídico al técnico:
Gestión de riesgos (Art. 9). Un proceso continuo y documentado durante todo el ciclo de vida del sistema. En la práctica: threat modeling extendido al comportamiento del modelo, evaluación de casos de fallo y su impacto, y revisión en cada release significativa. Si tu equipo ya hace análisis de riesgos de seguridad, ya tienes la base sobre la que construir.
Gobernanza de datos (Art. 10). Los datasets de entrenamiento, validación y prueba deben ser pertinentes, representativos y trazables. Traducción: versionado de datasets y capacidad de responder a la pregunta "¿con qué datos exactos se entrenó la versión que está en producción?". Quien trabaje con MLOps maduro ya tiene medio camino hecho.
Registro de eventos (Art. 12 y 19). El sistema debe generar logs automáticos que permitan reconstruir su funcionamiento, y conservarlos. Esto es observabilidad con requisitos de retención: qué entrada recibió el sistema, qué versión del modelo respondió, qué decisión produjo y quién la supervisó. Si hoy no puedes reconstruir por qué tu sistema dio una respuesta concreta hace tres meses, tienes trabajo por delante.
Supervisión humana (Art. 14). El sistema debe diseñarse para que una persona pueda supervisarlo eficazmente, con capacidad real de intervenir — no decorativa. En otras palabras: puntos de intervención en el flujo e interfaces que muestren al supervisor lo que necesita para decidir, no solo un botón de "aprobar" que todo el mundo pulsa sin mirar.
Documentación técnica (Art. 11). Arquitectura, capacidades, limitaciones y rendimiento del sistema, documentados y mantenidos. Lo que un buen equipo ya debería tener; ahora con carácter obligatorio y formato definido.
Fíjate en el patrón: trazabilidad, observabilidad, versionado, supervisión, documentación. Ninguno de estos requisitos es exótico. Son las buenas prácticas que distinguen un sistema de IA serio de una demo con suerte. El reglamento no te pide nada que un sistema bien construido no debiera tener ya; te pide demostrar que lo tienes.
Proveedor o deployer: probablemente eres ambos
Una confusión frecuente que conviene desactivar: las obligaciones dependen del papel que juega la empresa con cada sistema, y suele jugar varios.
Si desarrollas y comercializas un sistema de IA, eres proveedor y te aplica el bloque completo. Si usas un sistema de terceros —un SaaS de cribado de CV, un módulo de scoring en tu ERP—, eres responsable del despliegue (deployer) y te aplican obligaciones propias: seguir las instrucciones del proveedor, asegurar supervisión humana competente, conservar logs y verificar que los datos de entrada son adecuados. No necesitas haber construido el modelo para tener obligaciones sobre él.
Y hay una trampa que afecta especialmente a quienes construimos sobre APIs de modelos: si personalizas sustancialmente una herramienta, cambias su finalidad o la ofreces a clientes bajo tu marca, puedes pasar a ser considerado proveedor, con todo el paquete. Es exactamente el escenario de media industria ahora mismo, construyendo productos sobre LLMs de terceros. Merece un análisis caso a caso antes de que lo haga un supervisor.
Cumplir no es papeleo: es deuda técnica que resuelves antes de que cobre intereses
El aplazamiento del Ómnibus Digital es, bien mirado, un regalo con fecha de caducidad, dieciséis meses para construir con calma lo que de otro modo habría tocado improvisar.
Desde Tieto observamos que muchas organizaciones ya disponen de parte de estas capacidades, aunque suelen estar distribuidas entre distintos equipos, procesos y herramientas. El reto no es empezar desde cero, sino convertir buenas prácticas dispersas en un modelo de gobernanza coherente, escalable y demostrable.
La estrategia sensata no es esperar a 2027, sino incorporar estos requisitos como criterios de diseño desde ya, empezando por lo que ya está en vigor (transparencia del Art. 50) y siguiendo por lo que es buena ingeniería con o sin reglamento: logs trazables, datasets versionados, supervisión humana real y documentación viva. Cada uno de esos elementos, además de acercarte al cumplimiento, hace tu sistema más depurable, más auditable y más fácil de operar. La regulación, en este caso, apunta en la misma dirección que la calidad.
Hay una forma de leer el AI Act como una carga regulatoria. Hay otra, probablemente más útil, de entenderlo como la formalización de las prácticas que distinguen los sistemas de IA preparados para producción de aquellos que nunca llegan a escalar de forma segura y sostenible.
Los equipos que lo entiendan así llegarán a 2027 con sistemas mejores.
*Este artículo tiene carácter divulgativo y no constituye asesoramiento legal.
