El plazo de alto riesgo del Reglamento de IA se aplaza a 2027. El de transparencia, no.
Bruselas le ha hecho un regalo este año a los equipos de IA, y no dejo de ver equipos de producto desenvolviendo la caja equivocada. El Digital Omnibus — ya aprobado, no una propuesta — movió las obligaciones de alto riesgo del Reglamento de IA de agosto de 2026 al 2 de diciembre de 2027 para los sistemas independientes y al 2 de agosto de 2028 para la IA embebida en productos regulados. La industria oyó «el Reglamento de IA se retrasa» y se relajó. Pero las obligaciones de transparencia del artículo 50 nunca se retrasaron. Se aplican desde el 2 de agosto de 2026 — doce días después de que se publique este post — y cubren las funcionalidades de IA más corrientes que hay en producción: el chatbot, la imagen generada, la voz sintética.
Leo el Reglamento (UE) 2024/1689 como leo el changelog de una API: qué me rompe el roadmap, y cuándo. Soy ingeniero, no abogado, y esto es el mapa de un builder, no asesoramiento jurídico. El lado del deployer para los equipos de contratación ya lo cubrimos en nuestra serie sobre el EU AI Act; este post es para el otro lado de la mesa — el equipo que lanza funcionalidades de IA dentro de su propio producto.
La mayoría de tus funcionalidades no son de alto riesgo. Clasifica antes de entrar en pánico.
El Reglamento es una pirámide. En la cúspide, las prácticas prohibidas — scoring social, explotación de vulnerabilidades, reconocimiento de emociones en el trabajo — vetadas desde el 2 de febrero de 2025. Debajo, el alto riesgo: sistemas en los ámbitos del anexo III, como decisiones de empleo, scoring crediticio, evaluación educativa y acceso a servicios esenciales, más la IA embebida en productos ya regulados (anexo I). Después, un nivel de transparencia, y en la base, los sistemas de riesgo mínimo que el Reglamento apenas toca.
Haz un inventario honesto y la mayoría de las funcionalidades de IA de un SaaS — resumir, buscar, redactar, clasificar tus propios datos operativos — cae en los dos niveles de abajo. El ejercicio de clasificación lleva una tarde de trabajo por funcionalidad, y es la pieza de compliance que más rinde, porque todo lo que viene después depende de esa respuesta. Cuando construimos un motor legal consciente de la legislación para un cliente legaltech, el memorando de clasificación ocupaba dos páginas y zanjó una docena de discusiones posteriores — con la asesoría del cliente, con sus compradores enterprise y, de puertas adentro, cada vez que alguien proponía apuntar el modelo a un caso de uso más arriesgado. El modo de fallo que veo en la práctica no son equipos que clasifican mal; son equipos que no clasifican nunca, arrastrando un temor difuso que escala peor que cualquier obligación.
El matiz que merece tu atención: la condición de alto riesgo sigue al uso, no al modelo. Una funcionalidad de resumen es riesgo mínimo; el mismo resumidor ordenando solicitantes de crédito es territorio del anexo III. Si tu roadmap apunta una funcionalidad inocua hacia un ámbito del anexo III, la clasificación cambia bajo tus pies — y esa es una decisión de producto que alguien debería tomar — con la fecha de diciembre de 2027 a la vista.
Envolver el modelo de otro puede convertirte igualmente en proveedor
A los roles del Reglamento les da igual tu diagrama de arquitectura. Pon tu nombre en un sistema de IA y colócalo en el mercado de la UE — aunque sea una capa fina sobre la API de un modelo frontier — y eres el proveedor de ese sistema, con las obligaciones que corresponden a su clase de riesgo. Las obligaciones de los modelos GPAI que entraron en vigor el 2 de agosto de 2025 atan al fabricante del modelo aguas arriba; no absorben tus deberes aguas abajo. Y el artículo 25 tiene una trampa que conviene conocer: modifica sustancialmente un sistema de alto riesgo, o ponle tu marca, y las obligaciones de proveedor se transfieren a ti.
Para la mayoría de los equipos de producto la respuesta cabe en una línea: eres el proveedor de un sistema de riesgo limitado o mínimo, y tus obligaciones concretas son los deberes de transparencia de abajo. Pero «nosotros solo llamamos a una API» nunca ha sido una posición legal, y los equipos que dejan por escrito qué rol tienen por funcionalidad le dedican una hora una sola vez, en lugar de volver a discutirlo en cada llamada de procurement enterprise.
Hay una fecha dentro del régimen GPAI que también importa a los builders: los proveedores de modelos que firmaron el Código de Buenas Prácticas de la Comisión ven expirar su periodo de gracia el 2 de agosto de 2026 — el mismo día en que empiezan tus deberes de transparencia. Cuenta con que la documentación, las políticas de uso y el tooling de procedencia de tus proveedores upstream cambiarán alrededor de esa fecha, y basa tu integración en lo que publiquen ellos, no en el resumen de un blog. Su nivel de cumplimiento es un input del tuyo; trata la documentación del modelo como tratas el changelog de una dependencia.
Agosto de 2026 es un deadline de UX y metadatos, no de abogados
El artículo 50 se traduce en tres piezas de trabajo de ingeniería, todas vigentes desde el 2 de agosto de 2026:
- Revelar la interacción. La gente tiene que poder saber que habla con una máquina. Si tu chatbot podría pasar razonablemente por un agente humano, tiene que dejar claro que no lo es — una tarea de diseño, y pequeña si la planificas con tiempo.
- Marcado legible por máquinas del contenido sintético. El audio, las imágenes, el vídeo y el texto generados por IA y destinados al público necesitan un marcado en formato legible por máquinas — los metadatos de procedencia de la familia C2PA son donde está convergiendo el ecosistema. Los sistemas puestos en el mercado antes del 2 de agosto de 2026 tienen un periodo de gracia para el marcado hasta el 2 de diciembre de 2026; los nuevos, no.
- Revelar deepfakes y categorización. Los deployers de deepfakes, reconocimiento de emociones o categorización biométrica deben revelarlo a las personas afectadas.
Nada de esto es exótico. Es el tipo de trabajo que un equipo entrega en uno o dos sprints cuando está en el roadmap, y reentrega mal bajo un deadline de procurement cuando no lo está. El caso del marcado de texto merece una nota aparte: para imágenes y audio, los metadatos de procedencia tienen un estándar emergente en el que apoyarse; para el texto generado y publicado para informar al público, las opciones técnicas son más limitadas y el propio Reglamento lo reconoce — lo que convierte tu logging en la red de seguridad. Si puedes reconstruir qué salidas fueron generadas por máquina, cuándo y con qué versión de modelo, puedes responder la pregunta incluso donde una marca de agua no sobrevive a un copiar-pegar. Construye primero la reconstrucción; sirve para depurar un martes cualquiera y para los reguladores el día que pregunten.
Hay además una obligación ya en vigor que cuesta casi nada: la alfabetización en IA (artículo 4, vigente desde febrero de 2025) pide a proveedores y deployers asegurar que el personal que opera sistemas de IA los entiende. Para una organización de ingeniería esto es un módulo de onboarding y un par de sesiones internas — las mismas que tu equipo querría de todos modos.
La prórroga es real — y no son vacaciones
Le concedo al contraargumento todo su peso: diciembre de 2027 queda lejos, los estándares armonizados para sistemas de alto riesgo todavía se están escribiendo (en buena parte por eso se movió la fecha) y la capacidad de enforcement varía de un estado miembro a otro. Algunos bordes del Reglamento siguen sin asentarse — dónde empieza la «modificación sustancial», qué formatos de marcado satisfarán a qué autoridad. Quien te venda certezas sobre esos puntos te está vendiendo.
Pero esto es lo que la prórroga no cambia: si alguna funcionalidad de tu roadmap puede caer razonablemente en el anexo III, la parte cara del compliance es arquitectónica — logging capaz de reconstruir una decisión, hooks de supervisión humana que no sean decorativos, gobernanza de datos que puedas describir sin sonrojarte. Todo eso cuesta poco si se diseña desde el principio, y una reescritura entera si se añade con calzador después. Dieciséis meses extra son la ventana en la que diseñarlo desde el principio todavía sale barato.
Qué haría este trimestre si el roadmap de producto con IA fuera mío
- Inventaría cada funcionalidad con forma de IA, con un responsable. Las funcionalidades en la sombra cuentan — el script de enriquecimiento que usa marketing también está en el mercado.
- Clasifica cada una contra la pirámide, por escrito, un párrafo cada una. Anota cuáles podrían derivar hacia el anexo III con una sola decisión de producto.
- Entrega ya el trabajo del artículo 50: UX de revelación para todo lo conversacional, metadatos de procedencia para todo lo generativo. El plazo vence en unas semanas, y es trabajo pequeño.
- Guarda registros de modelos y evals — qué versión de modelo corrió cuándo, evaluada cómo. Los querrás para las cinco preguntas que cualquier auditor o comprador enterprise acabará haciendo.
- Decide tu rol por funcionalidad — proveedor o deployer — y archívalo donde ventas pueda encontrarlo antes de que llegue el siguiente cuestionario de procurement.
Los equipos que mejor sortearon el RGPD en 2018 no eran los de mayor presupuesto legal; eran aquellos cuyos ingenieros leyeron el reglamento una vez y lo proyectaron sobre sistemas que ya entendían. El Reglamento de IA premia el mismo gesto. La fecha de alto riesgo se ha movido. El hábito de leerte las reglas tú mismo, no.
Si estás construyendo funcionalidades de IA bajo reglas europeas y quieres ingenieros que ya han lanzado bajo este tipo de escrutinio, habla con un CTO.
