Reglamento de IA y RGPD: obligaciones de etiquetado para código y textos generados por IA

Investigado y redactado por ResearchRaven, el sistema de investigación con IA que he desarrollado (24 fuentes): contrasta automáticamente cada afirmación con su fuente. He revisado y aprobado el texto final desde el punto de vista técnico; la responsabilidad editorial conforme al art. 50(4) del Reglamento de IA recae en Florian Drechsler.

Desde el 2 de agosto de 2026 se aplican las obligaciones de transparencia del artículo 50 del Reglamento europeo de IA (Reglamento (UE) 2024/1689) [3][18]. Para los sistemas de IA generativa que ya estaban en el mercado antes de esa fecha corre además un período transitorio hasta el 2 de diciembre de 2026, dentro del cual debe incorporarse el marcado legible por máquina exigido por el artículo 50(2) [18][24]. En paralelo, el RGPD viene exigiendo desde hace años transparencia, base jurídica y minimización de datos allí donde se tratan datos personales, una exigencia que los sistemas de IA no suprimen, sino que complementan [6][7]. Para las empresas que utilizan IA generativa en producción, ambos marcos normativos se funden en un catálogo de obligaciones que va mucho más allá de la pregunta habitual «¿es nuestro sistema de alto riesgo?». Una de las cuestiones más urgentes en la práctica, y hasta ahora rara vez respondida con precisión, es: ¿alcanza la obligación de etiquetado también al código que generan asistentes como Copilot, Cursor o Claude Code? El borrador de directrices de la Comisión y su interpretación por parte de los despachos ofrecen ahora una respuesta provisional y matizada, y es precisamente esa respuesta la que ocupa el centro de este artículo.

Marco jurídico: el RGPD se encuentra con el Reglamento de IA

El Reglamento de IA sigue un enfoque basado en el riesgo: los sistemas de «riesgo inadmisible» están prohibidos, los de «alto riesgo» quedan sujetos a estrictas obligaciones de conformidad, y todos los demás soportan, según su finalidad, a lo sumo deberes de documentación o transparencia [1][6]. La IA generativa suele encajar en la tercera categoría: se basa mayoritariamente en modelos de IA de uso general (GPAI), para los que el Reglamento prevé un régimen propio con obligaciones de mitigación cuando existe «riesgo sistémico» [6]. El artículo 3 define los papeles centrales: el «proveedor» desarrolla un sistema de IA y lo introduce en el mercado; el «responsable del despliegue» lo utiliza bajo su propia autoridad. Ambos soportan obligaciones distintas pero complementarias [14].

Importante en la práctica: el Reglamento de IA no sustituye al RGPD, lo complementa [6]. La autoridad francesa de protección de datos, la CNIL, publicó a principios de 2026 un marco de cumplimiento por etapas que guía a las empresas durante la fase de desarrollo de sistemas de IA que tratan datos: desde la definición de la finalidad y la elección de la base jurídica (incluidas las salvaguardas en el web scraping) hasta la minimización de datos, los plazos de conservación, los derechos de los interesados y una guía específica sobre evaluaciones de impacto [7]. Cuando los responsables del despliegue utilizan sistemas de alto riesgo, el artículo 26 exige además que la información facilitada conforme al artículo 13 se emplee para cumplir la obligación de evaluación de impacto del art. 35 RGPD: en ese punto ambos marcos encajan técnicamente uno en otro [13]. Las guías de cumplimiento empresarial condensan ya esa intersección en listas de comprobación practicables y recomiendan, como enfoque de despliegue «seguro en cumplimiento», usos de IA autoalojados, con acceso restringido, íntegramente registrados y revisados por personas [8].

El artículo 50 en detalle: cuatro obligaciones de transparencia, dos destinatarios

El artículo 50 distingue con claridad entre proveedores y responsables del despliegue [16][19]. Los proveedores deben, en primer lugar, diseñar los sistemas de IA que interactúan directamente con personas —chatbots, asistentes de voz, agentes de IA, avatares— de modo que los usuarios puedan reconocer que están tratando con una IA, salvo que ello resulte evidente para una persona «razonablemente informada y atenta» o esté permitido por ley para la persecución de delitos [3][16][19]. Según los comentarios, esta obligación se aplica expresamente también a la IA agéntica en cuanto la interacción con una persona sea «razonablemente previsible» [20]. En segundo lugar, los proveedores —incluidos los de sistemas GPAI— deben marcar los contenidos sintéticos de audio, imagen, vídeo o texto con marcas legibles por máquina y detectables, y las soluciones técnicas empleadas deben ser eficaces, interoperables, robustas y fiables en la medida en que resulte técnicamente viable [3][16][19].

Los responsables del despliegue soportan dos obligaciones propias: deben informar a las personas expuestas a sistemas de reconocimiento de emociones o de categorización biométrica, y deben etiquetar las ultrafalsificaciones así como los textos generados o manipulados por IA sobre asuntos de interés público. Esto último decae cuando el contenido ha sido sometido a revisión humana con responsabilidad editorial, o es manifiestamente artístico, creativo, satírico o ficticio [3][16][19]. Para los sistemas generativos que ya estaban en el mercado antes del 2 de agosto de 2026, la Comisión prevé una regla transitoria limitada: la obligación de marcado legible por máquina les será exigible solo a partir del 2 de diciembre de 2026, sin que haya que marcar retroactivamente los contenidos ya publicados [18][20]. La Comisión Europea ha concretado estas obligaciones mediante directrices propias, actualmente en fase de borrador, que acotan provisionalmente el ámbito de aplicación sin delimitarlo aún de forma definitiva, y que complementan el «Code of Practice on Transparency of AI-Generated Content», de carácter voluntario [2][5][19].

Código generado por IA: qué cubre el artículo 50(2) y qué no

Para las empresas que usan Copilot, Cursor, Claude Code o asistentes de programación comparables, la pregunta práctica apremiante es si el código fuente generado debe marcarse como «contenido generado artificialmente». El borrador de directrices de la Comisión sobre el artículo 50 responde de forma matizada [19], y los comentarios de los despachos —en particular de William Fry y Conventus Law— trazan la línea divisoria con precisión [20][21].

La respuesta breve: el código fuente como tal no queda sujeto a la obligación de marcado del artículo 50(2). Según los comentarios, las directrices contienen un supuesto de excepción para las salidas de código fuente (apartado 64), una exclusión deliberada dirigida precisamente a herramientas agénticas de desarrollo como Claude Code, Cursor y Copilot, cuya función central es la generación automatizada de código [21]. Conforme a la lectura coincidente, esa excepción se extiende al código en sentido estricto y también a los comentarios en línea y los docstrings, en la medida en que formen parte integrante del artefacto de código [19][20][21]. A ello se suma una excepción B2B/industrial de alcance estrecho: las salidas puramente técnicas, accesibles solo a un público profesional limitado, pueden quedar asimismo exentas de la obligación de marcado bajo determinadas condiciones [20].

La reserva llega inmediatamente después, y ahí está la trampa tanto para los proveedores como para las empresas usuarias: la excepción no cubre la documentación generada de forma independiente. Los archivos README, las descripciones de producto de estilo comercial o los textos explicativos en lenguaje natural que la misma herramienta produzca por separado son «texto en sentido ordinario» y vuelven a quedar plenamente sujetos al artículo 50(2) [20][21]. Los sistemas generativos construidos sobre modelos GPAI siguen igualmente obligados al marcado en la medida en que generen ese tipo de salidas de texto [20]. Los comentarios advierten de que no debe deducirse de la exclusión del código fuente una exención general del tipo «nosotros solo generamos código»; los proveedores de agentes de programación deberían diseñar sus mecanismos de divulgación siguiendo deliberadamente esa línea divisoria, en lugar de confiar en una exención en bloque [21]. Esta delimitación fina —advierten los comentarios— no está aún definitivamente resuelta y solo se consolidará con las directrices finales o con la práctica supervisora [21].

En términos concretos para las empresas: una norma interna que diga «el código generado por IA está exento de todos modos» no basta. Quien emplee herramientas de desarrollo asistidas por IA y genere con ellas, de forma automatizada, documentación de acompañamiento, archivos README o descripciones de producto, debe examinar esas salidas de texto por separado en cuanto a su obligación de marcado, con independencia de que el código subyacente siga exento. Quien opere asistentes de programación como herramienta interna con un círculo de usuarios muy restringido puede apoyarse además en la excepción B2B, pero debería documentar sus estrictas condiciones [20].

Por qué las marcas de agua son más difíciles en texto que en audio e imagen

La exigencia legal suena sencilla: «legible por máquina, detectable, eficaz, interoperable, robusta y fiable» [3]. Técnicamente no lo es, y la dificultad es incomparablemente mayor en el texto que en el audio, la imagen o el vídeo. Entre las expectativas regulatorias y los límites técnicos de los métodos de marca de agua existentes se abre una brecha creciente; sin normas exigibles, infraestructura de auditoría y mecanismos de ejecución, se corre el riesgo de un «cumplimiento simbólico» en lugar de una supervisión efectiva [17].

La investigación revisada por pares aporta ya evidencia sólida al respecto. Ningún método de marca de agua para LLM disponible en el mercado es igualmente robusto frente a toda la gama de pasos de posprocesado realistas, como acredita el examen de diez métodos que el banco de pruebas unificado «WaterPark», del trabajo «Watermark under Fire», enfrenta a doce ataques de eliminación representativos —desde la paráfrasis hasta manipulaciones adversarias dirigidas— para deducir sistemáticamente cómo influyen las decisiones de diseño en la robustez y qué prácticas operativas resisten en entornos hostiles (aceptado en EMNLP 2025) [22]. La eficacia depende en gran medida del vector de ataque concreto y de las decisiones de configuración [22].

El trabajo de Kirchenbauer et al. (ICLR 2024) resulta aún más concreto para el texto: las marcas de agua textuales sobreviven en muchos casos tanto a la paráfrasis humana como a la automática, porque las paráfrasis dejan «filtrarse», estadísticamente, n-gramas o fragmentos más largos del texto original; una detección fiable con alta confianza es por tanto posible en principio, como muestra su estudio sobre la robustez frente a la reescritura humana, la paráfrasis automática y la inserción en documentos más largos escritos a mano [23]. El precio, sin embargo, es alto: bajo una paráfrasis humana intensa hacen falta unos 800 tokens observados para lograr una detección fiable con una tasa de falsos positivos de 1e-5 [23]; para respuestas breves de chat, comentarios de código o publicaciones en redes sociales ese umbral resulta a menudo sencillamente inalcanzable. Las marcas de agua en imagen, audio y vídeo, en cambio, pueden apoyarse en métodos de procesamiento de señal más robustos, que resisten mejor la compresión y la recodificación; al texto en lenguaje natural le falta en gran medida ese depósito de señal redundante, lo que convierte la fiabilidad exigida por el legislador «en la medida en que sea técnicamente viable» en un auténtico reto de ingeniería [17][22][23].

Qué significa en concreto «eficaz, robusto, interoperable y documentado»

El Reglamento de IA no exige una solución perfecta, sino una acorde al estado de la técnica, y hace verificable el cumplimiento de ese deber. El Code of Practice on Transparency of AI-Generated Content, de carácter voluntario y cuya versión final se publicó el 10 de junio de 2026, concreta en su sección 1 las obligaciones de los proveedores conforme al artículo 50(2): las soluciones de marcado y detección legibles por máquina empleadas deben ser eficaces, interoperables, robustas y fiables en la medida en que sea técnicamente viable, ajustadas al tipo de contenido, al estado de la técnica, a las normas técnicas pertinentes y a la proporcionalidad del esfuerzo [24]. La sección 2 regula de forma simétrica las obligaciones de los responsables del despliegue conforme al artículo 50(4): diseño, ubicación y presentación de las etiquetas para ultrafalsificaciones y textos de IA de relevancia pública, incluido un icono europeo opcional [24].

Para la práctica del cumplimiento resulta determinante la vía probatoria que describen las directrices de la Comisión: quien firma el Code of Practice y lo cumple puede demostrar por esa vía, principalmente, la observancia de las obligaciones de marcado y etiquetado. Quien no se adhiere debe acreditar el cumplimiento por otros medios igualmente idóneos, y asume así íntegramente la carga documental [19]. Para las demás obligaciones de transparencia las empresas pueden, en todo caso, determinar por sí mismas las medidas adecuadas, si bien deben tener en cuenta las directrices [19]. Igualmente importante es la calificación jurídica del propio Code of Practice: es expresamente voluntario y no crea obligaciones que vayan más allá del Reglamento de IA; solo pretende favorecer una aplicación coherente, practicable y proporcionada de las reglas de transparencia ya existentes, sin sustituir al Reglamento ni a las directrices de la Comisión [24]. En la práctica esto significa: adherirse al Code of Practice reduce considerablemente la carga propia de documentación y prueba, pero no sustituye el análisis de fondo de las obligaciones subyacentes. Quien opte por medidas técnicas propias —por razones de arquitectura de producto, por ejemplo— debería documentar desde el principio su eficacia, robustez y adecuación de forma que resistan, llegado el caso, ante las autoridades de vigilancia del mercado, la Oficina de IA o el Supervisor Europeo de Protección de Datos [19].

En cuanto a la claridad conceptual, conviene además separar limpiamente tres conceptos que a menudo se mezclan: la marca de agua técnica (marcado en el propio contenido), el etiquetado (aviso visible para los usuarios) y el deber general de divulgación, cada uno con responsabilidades distintas entre proveedor y responsable del despliegue [3][19].

Puntos de contacto con el RGPD: cuando el contenido generado por IA incluye datos personales

Las obligaciones de etiquetado del artículo 50 no resuelven automáticamente las cuestiones de protección de datos. En cuanto un sistema de IA se emplea para el reconocimiento de emociones o la categorización biométrica, el artículo 50(3) exige informar a las personas afectadas y remite al mismo tiempo al tratamiento conforme al RGPD, al Reglamento (UE) 2018/1725 y a la Directiva (UE) 2016/680 [3]. Las recomendaciones de la CNIL muestran hasta qué punto esa imbricación alcanza a la fase de desarrollo: desde la fijación de la finalidad del tratamiento y la determinación de la responsabilidad y el encargo, pasando por la elección de la base jurídica (con guía específica sobre interés legítimo y salvaguardas frente al web scraping), el examen de la licitud de la reutilización de datos, la minimización y los plazos de conservación, hasta la garantía de los derechos de los interesados a través de conjuntos de datos y modelos [7]. Las obligaciones del responsable del despliegue conforme al artículo 26 remiten a su vez a la evaluación de impacto: deben usar la información facilitada conforme al artículo 13 para cumplir sus deberes del artículo 35 RGPD o del artículo 27 de la Directiva (UE) 2016/680 [13]. Quien utilice IA generativa para tratar datos personales —por ejemplo en chatbots de atención al cliente o en la generación automatizada de textos con datos de clientes— debe pensar, por tanto, las bases del RGPD y las obligaciones de transparencia del Reglamento de IA conjuntamente desde el principio, y no de forma sucesiva [6][8].

También la cuestión de la responsabilidad sigue en movimiento. Un análisis publicado en el Cambridge Forum on AI: Law and Governance examina si el Reglamento de IA, el borrador de Directiva sobre responsabilidad en materia de IA (AILD) y la Directiva revisada sobre responsabilidad por productos defectuosos (revPLD) cubren suficientemente la responsabilidad por daños de la IA generativa. No lo hacen del todo: persisten lagunas —ambigüedades en el ámbito de aplicación y problemas de encaje con el carácter genérico e independiente de la tarea de los modelos fundacionales— y los futuros escenarios de responsabilidad se reparten entre las fases de entrenamiento, uso y generación de salidas [9]. Para las empresas esto significa que ni siquiera el cumplimiento íntegro del artículo 50 excluye por sí solo los riesgos de responsabilidad civil derivados de salidas de IA defectuosas o lesivas.

Sanciones, calendario y la cuestión de los plazos

Las infracciones del Reglamento de IA salen caras. El artículo 99 escalona las multas en tres niveles: las infracciones de prácticas prohibidas pueden sancionarse con hasta 35 millones de euros o el 7 por ciento del volumen de negocio anual mundial; las de otras obligaciones de proveedores, responsables del despliegue u organismos notificados con hasta 15 millones de euros o el 3 por ciento; y facilitar información falsa o engañosa con hasta 7,5 millones de euros o el 1 por ciento, beneficiándose las pymes en cada caso del importe menor de los dos [15]. La cuantía depende de factores como la naturaleza de la infracción, el tamaño de la empresa y las infracciones previas; los Estados miembros deben informar anualmente a la Comisión sobre las multas impuestas [15].

En cuanto al calendario: las disposiciones generales y las prohibiciones se aplican desde el 2 de febrero de 2025, y las reglas sobre GPAI y las estructuras de gobernanza desde el 2 de agosto de 2025 [18]. Desde el 2 de agosto de 2026 se aplican las reglas de transparencia del artículo 50 y la mayor parte de las demás disposiciones, con inicio de la ejecución a nivel nacional y europeo para modelos GPAI, prohibiciones, reglas de transparencia y obligaciones de alfabetización en IA [18]. El 2 de diciembre de 2026 marca además nuevas prohibiciones (ultrafalsificaciones sexuales no consentidas, material de abuso) y el fin del período transitorio del artículo 50(2) para los sistemas preexistentes [18]. Tras el paquete de acuerdo «Digital Omnibus», los plazos para los sistemas de alto riesgo del anexo III se trasladaron al 2 de diciembre de 2027 y los de la IA de alto riesgo en productos regulados del anexo I al 2 de agosto de 2028 [18]. Ese aplazamiento afecta, no obstante, solo a las obligaciones más estrictas de alto riesgo: el artículo 50 se aplica ya con independencia de ello, y las multas son reales [11][18].

Aplicación práctica en la empresa

¿Qué se sigue de todo esto para la práctica del cumplimiento? Primero: aclarar los papeles. Quién actúa como proveedor y quién como responsable del despliegue en el sentido del artículo 3 determina cuáles de las cuatro obligaciones del artículo 50 resultan aplicables [14][16]. Segundo: inventariar todos los usos de IA generativa, incluida la «IA en la sombra» que emplean los departamentos sin autorización central, ya que el mero uso de herramientas de terceros convierte a una empresa en responsable del despliegue con obligaciones propias [10]. Tercero: examinar caso por caso si las salidas quedan sujetas a la obligación de marcado, con especial cuidado en los asistentes de programación, cuya salida de código puede estar exenta mientras que su documentación de acompañamiento no lo está [20][21]. Cuarto: decidir sobre la adhesión al Code of Practice, dado que reduce sensiblemente la carga documental para acreditar el cumplimiento [19][24]. Quinto: documentar las medidas técnicas y organizativas: qué método de marcado se eligió, por qué se considera estado de la técnica y qué límites de robustez se conocen [19][22][23]. Sexto: unir organizativamente los procesos del RGPD y las obligaciones de transparencia del Reglamento de IA, por ejemplo mediante un órgano de gobernanza transversal con representantes de las áreas jurídica, de seguridad, de producto y de ingeniería, responsable de los hitos de diseño, prueba y lanzamiento [8][12]. Las guías prácticas sobre el artículo 50 recomiendan para ello listas de comprobación concretas con plazos, responsabilidades y procesos de aprobación [4].

Conclusión

El artículo 50 del Reglamento de IA no exige a las empresas un «etiquetado de IA» indiscriminado, sino una arquitectura de cumplimiento diferenciada, dependiente del papel y del tipo de contenido. Para el código generado por IA rige que el código en sí —incluidos comentarios y docstrings— queda exento de la obligación de marcado, pero esa excepción termina allí donde esas mismas herramientas generan texto autónomo en lenguaje natural: archivos README, descripciones de producto, textos explicativos [19][20][21]. Para el texto en general rige además que la robustez que la ley exige a las marcas de agua es técnicamente más ardua que en audio o imagen, porque los ataques de paráfrasis solo resultan detectables con fiabilidad a partir de varios cientos de tokens [22][23]. Quien ignore estos matices y confíe en exenciones generales se expone a multas de hasta 15 millones de euros o el 3 por ciento del volumen de negocio anual [15] y, más allá, a riesgos de responsabilidad que exceden el propio Reglamento [9].

El plazo del 2 de agosto de 2026 ha vencido: el artículo 50 se aplica. Lo que queda es la regla transitoria hasta el 2 de diciembre de 2026 para los sistemas que ya estaban en el mercado antes, y para todos los demás la pregunta de si su implementación resistiría un examen. Quien no haya empezado a estas alturas ya no trabaja con vistas a un plazo, sino en una situación que resulta sancionable [18][24].