Estado a 11 de agosto de 2026. El Artículo 50 de la Ley de IA de la UE (transparencia para ciertos sistemas que interactúan con personas, generan contenido sintético, ejecutan reconocimiento de emociones o categorización biométrica, o publican deepfakes) se aplica desde el 2 de agosto de 2026. La Comisión Europea ha comenzado a hacer cumplir esos requisitos de transparencia. Esto es la ley vigente para el código de aplicación, no una fecha límite futura.
La mayoría de los requisitos de sistemas de alto riesgo del Capítulo III (Artículos 8 al 15: gestión de riesgos, gobernanza de datos, documentación técnica, mantenimiento de registros, instrucciones para los implementadores, supervisión humana, precisión, robustez y ciberseguridad) no entraron en vigor el 2 de agosto de 2026. El Reglamento (UE) 2026/1744, el Paquete Digital sobre IA, se publicó en el Diario Oficial el 24 de julio de 2026 y entró en vigor el 27 de julio de 2026. Este reglamento aplaza la aplicación de esas obligaciones de alto riesgo al 2 de diciembre de 2027 para los sistemas clasificados como de alto riesgo según el Artículo 6(2) y el Anexo III (sistemas autónomos como herramientas de empleo, servicios esenciales y aplicación de la ley), y al 2 de agosto de 2028 para los sistemas clasificados según el Artículo 6(1) y el Anexo I (IA integrada en productos ya regulados en otros ámbitos, como dispositivos médicos o maquinaria). Los planes que aún consideran agosto de 2026 como la fecha límite de cumplimiento para alto riesgo están planificando en función de una fecha que ya se ha pospuesto.
Esta guía es para desarrolladores. No clasifica tu producto como de alto riesgo, no realiza una evaluación de conformidad ni sustituye el asesoramiento legal. Identifica el calendario, las obligaciones del Artículo 50 que ahora aparecen como texto de interfaz y metadatos en un diff, y cómo una lectura de cumplimiento de una solicitud de extracción detecta el modo de fallo común: una limpieza que elimina la divulgación.
Qué está en vigor ahora (Artículo 50)
El Artículo 50 establece cuatro categorías principales de obligaciones de transparencia, divididas entre proveedores (la organización que desarrolla el sistema) y implementadores (la organización que lo pone en uso), sujetas a excepciones, como ciertos usos de aplicación de la ley. Cada una de estas obligaciones suele manifestarse en el código en ejecución, no solo en documentación. Art. 50(1): un sistema diseñado por un proveedor para interactuar directamente con una persona debe informar a esa persona de que está hablando con una IA, a menos que sea obvio para una persona razonablemente informada; un widget de chat, un agente de voz o un bot de soporte necesita una divulgación que alguien vea realmente. Art. 50(2): un proveedor cuyo sistema genera audio, imágenes, vídeo o texto sintético debe marcar esa salida en un formato legible por máquina detectable como generado por IA. Para los sistemas ya en el mercado antes del 2 de agosto de 2026, la parte de marcado legible por máquina según el Art. 50(2) suele describirse con una transición hasta el 2 de diciembre de 2026; confirma el texto transitorio exacto en el Paquete Digital y las directrices de la Comisión para la línea de productos, ya que otras obligaciones del Artículo 50 no comparten ese plazo. Art. 50(3): un implementador que ejecute reconocimiento de emociones o categorización biométrica en personas debe informar a las personas afectadas. Art. 50(4): un implementador que publique un deepfake debe revelar que está generado o manipulado artificialmente; para contenido que forme parte de una obra claramente artística, creativa, satírica, ficticia o análoga, esa obligación de divulgación se limita a realizarse de manera que no perjudique la visualización o el disfrute de la obra, en lugar de ser eximida. Por separado, el texto generado o manipulado por IA publicado para informar al público sobre un tema de interés público necesita la misma divulgación, a menos que el contenido haya sido revisado o controlado editorialmente por una persona u organización que asuma la responsabilidad editorial de su publicación.
Cada una de esas obligaciones suele implementarse como un elemento de interfaz, una escritura de metadatos o una cadena de texto, lo que las convierte exactamente en el tipo de cosas que una refactorización puede eliminar sin que nadie las marque como un cambio de cumplimiento. A partir de agosto de 2026, esa eliminación no es "prematura"; es una brecha de transparencia en vigor.
Ejemplo práctico: una limpieza de interfaz elimina la divulgación
Supongamos que un chatbot de soporte se lanzó con una línea persistente bajo su primer mensaje: "Estás chateando con un asistente de IA." Una solicitud de extracción posterior rediseña el widget para un estado de primera apertura más limpio y, al recortar lo que un diseñador marcó como desorden en el proceso de incorporación, elimina esa línea junto con otras tres líneas de texto de introducción. El rediseño no es incorrecto en sus propios términos: el widget se ve más limpio y las otras tres líneas eran realmente relleno. Pero la divulgación del Art. 50(1) se implementó como una de esas líneas, por lo que eliminarla eliminó la divulgación, no solo el desorden. Nada en el diff parece inusual: un recorte de texto en un componente de chat no es el tipo de cosa que un escáner de errores, una revisión de control de calidad o una revisión de diseño está diseñado para detectar.
Esto es lo que una verificación de cumplimiento lee en un diff: cuando un cambio elimina o debilita un elemento vinculado a un control que el equipo está rastreando, se cita el Art. 50(1) en la propia solicitud de extracción, en lugar de enterarse por una queja o un contacto de aplicación después de los hechos.
Las obligaciones de alto riesgo se posponen, no se cancelan
Posponer los requisitos de alto riesgo del Anexo III autónomo hasta diciembre de 2027 no hace que la pregunta subyacente, si un sistema se considera de alto riesgo según el Anexo III, sea más fácil de responder más adelante que ahora. Los controles detrás de los Artículos 8 al 15 son del mismo tipo de problema "cambios en un diff" que el centro del marco ya rastrea: una mitigación de riesgos debilitada, una verificación de gobernanza de datos eliminada, una anulación humana eliminada como código muerto. Construir esos hábitos ahora es más económico que descubrir brechas bajo un plazo de 2027.
Dos grupos de fechas más no se ven afectados por este paquete y ya están en vigor: las obligaciones de prácticas prohibidas y alfabetización en IA desde el 2 de febrero de 2025, y las normas de modelos de IA de propósito general y obligaciones de gobernanza desde el 2 de agosto de 2025. Otro cambio digno de mención del mismo paquete: una nueva prohibición que cubre a los proveedores de sistemas destinados a generar o manipular material íntimo no consensuado o material de abuso sexual infantil, o sistemas para los cuales esa salida sea un resultado previsible y reproducible sin modificación técnica significativa y sin salvaguardas razonables y adecuadas contra ello, así como a los implementadores que utilicen un sistema con ese propósito, añadido a la lista de prácticas prohibidas de la Ley y aplicable desde el 2 de diciembre de 2026.
Dónde encaja heygrc y el límite de la honestidad
heygrc está diseñado para leer cada solicitud de extracción frente a los marcos que hayas seleccionado, incluyendo la Ley de IA de la UE cuando la tengas habilitada, y para nombrar el artículo que un cambio parece afectar (por ejemplo, Art. 50(1) en una divulgación de chat eliminada). El hallazgo es un comentario de revisión con el artículo adjunto para que el autor y el revisor puedan decidir con toda la información. No certifica el cumplimiento de la Ley de IA, no clasifica el estado de alto riesgo, no realiza una evaluación de conformidad, no presenta notificaciones de supervisión ni sustituye el asesoramiento legal. Una revisión verde de heygrc no es una aprobación de la Comisión; es una señal temprana, basada en el artículo, de que un cambio afectó algo que esos programas consideran importante.
Si tu equipo ya utiliza un revisor de errores o calidad en la misma solicitud de extracción, manténlo. Esas herramientas preguntan si el código es correcto y seguro. Las preguntas del Artículo 50 se refieren a si una persona aún sabe que está hablando con una IA o si el contenido sintético aún está marcado. La limpieza anterior puede ser limpia, tipada y bien probada, y aún así dejar el Art. 50(1) incompleto. Ejecuta ambas capas; ninguna reemplaza a la otra.