La UE pone letra pequeña a las etiquetas de IA: el nuevo código no crea obligaciones, pero sí cambia cómo se demuestra el cumplimiento

La discusión ya no va de si conviene etiquetar contenido generado por IA. Eso quedó atrás. Desde el 2 de agosto de 2026, las obligaciones de transparencia del artículo 50 del AI Act son aplicables, y la Comisión Europea acaba de dejar algo bastante claro: quien firme el nuevo Code of Practice on Transparency of AI-Generated Content tendrá una vía reconocida a escala de la UE para demostrar cumplimiento; quien no lo haga tendrá que convencer, caso por caso, a distintas autoridades nacionales de vigilancia del mercado de que sus medidas alternativas son suficientes.

No es una diferencia menor. Es la distancia entre un marco operativo homologado y una defensa artesanal ante reguladores que, como suele ocurrir, no siempre leerán la misma norma con el mismo entusiasmo ni con el mismo criterio.

La novedad no está en que la transparencia pase a ser obligatoria. Eso ya estaba en el AI Act. La novedad real es otra: Bruselas ha convertido una obligación jurídica bastante abstracta en un itinerario de cumplimiento demostrable. Y ahí es donde CISOs, responsables de compliance, directores jurídicos y equipos de riesgo operativo deberían dejar de mirar esto como un asunto de marketing, moderación de contenidos o reputación digital. Es control interno. Es trazabilidad. Es evidencia. Y, para el sector financiero, también empieza a parecerse mucho a un problema de resiliencia operativa.

Tesis editorial

Mi tesis es simple: este código voluntario no endurece formalmente el AI Act, pero en la práctica redefine el estándar de diligencia exigible para proveedores y desplegadores de sistemas generativos en Europa. Dicho de forma menos diplomática, no firmarlo será perfectamente legal; defender después por qué tu alternativa era igual de buena puede ser bastante más incómodo.

La Comisión y el AI Board han confirmado que el código es una herramienta voluntaria adecuada para demostrar cumplimiento de las obligaciones de transparencia del artículo 50 del AI Act. Esa frase, que suena burocrática, tiene un peso operativo considerable. Si un marco ha sido validado por la Comisión y por la Junta Europea de IA, se convierte de facto en el punto de referencia frente al que se medirán las soluciones propias. En regulación tecnológica, “voluntario” muchas veces quiere decir “optativo solo para quien esté dispuesto a litigar o a justificar mucho”.

Y aquí hay una ironía bastante europea: el legislador no obliga a firmar el código, pero sí deja claro que, si no lo firmas, cada autoridad de vigilancia evaluará individualmente si tus medidas son adecuadas. Es decir, la fragmentación regulatoria que el AI Act pretendía reducir reaparece justo donde más duele: en la prueba del cumplimiento.

Qué ha aprobado exactamente Bruselas y por qué importa ahora

La página oficial de la Comisión describe el código como un instrumento de apoyo al cumplimiento de las obligaciones de transparencia relativas al marcado y etiquetado de contenido generado por IA. El anclaje jurídico es el artículo 50 del AI Act, en concreto sus apartados 2, 4 y 5, que cubren la marcación y detección de contenido generado o manipulado por IA, el etiquetado de deepfakes y determinadas publicaciones textuales generadas o manipuladas por IA.

La fecha crítica es el 2 de agosto de 2026. Desde ese día son aplicables las obligaciones de transparencia del artículo 50. No estamos hablando, por tanto, de una consulta pública ni de un borrador que pueda quedar aparcado en un cajón de Bruselas junto a otras buenas intenciones. Estamos hablando de cumplimiento vigente este año.

El código tiene dos secciones muy concretas:

La primera se dirige a providers, es decir, proveedores de sistemas generativos, y establece reglas sobre marcado y detección de contenido generado y manipulado por IA. La segunda se dirige a deployers, los sujetos que despliegan o usan esos sistemas en sus operaciones o servicios, y se centra en el etiquetado de deepfakes y de texto generado o manipulado por IA en los supuestos cubiertos por el AI Act.

Además, la UE ha publicado un conjunto de iconos que los desplegadores pueden utilizar para etiquetar contenido generado por IA. No es un detalle estético. Es un intento de homogeneizar la señal visual de transparencia entre Estados miembros y plataformas. Quien haya visto cómo han evolucionado los banners de cookies en Europa sabe que la estandarización visual puede ahorrar litigios, pero también crear una falsa sensación de cumplimiento si no hay sustancia técnica detrás.

La Comisión insiste en que el código no sustituye ni al AI Act ni a las directrices sobre el alcance del artículo 50. Correcto. Pero sí añade algo que las normas de alto nivel no suelen resolver bien: una expectativa común sobre medidas prácticas aceptables. En otras palabras, traduce el “qué” jurídico al “cómo” operativo.

La trampa semántica de “transparencia”: no basta con una etiqueta bonita

Si eres CISO o responsable de compliance y has pensado que esto se resuelve con un aviso del tipo “contenido creado con ayuda de IA”, toca enfriar expectativas. El código gira alrededor de tres verbos mucho más exigentes de lo que parecen: marcar, detectar y etiquetar.

Marcar implica incorporar señales al contenido generado o manipulado. Detectar supone ser capaz de identificar, de forma fiable y defendible, si ese contenido procede de un sistema de IA o ha sido alterado por uno. Etiquetar exige mostrar esa información al usuario final en los supuestos previstos por la ley. Las tres capas son distintas. Y si una falla, el castillo de cumplimiento se tambalea.

El artículo 50 del AI Act está diseñado para reducir riesgos de engaño y manipulación y proteger la integridad del ecosistema informativo. Eso suena abstracto hasta que uno lo aterriza en operaciones reales. Pensemos en una aseguradora que usa IA generativa para producir vídeos explicativos de pólizas, una entidad de pago que sintetiza mensajes de voz para su atención al cliente o un banco que automatiza publicaciones financieras para canales digitales. El riesgo regulatorio ya no se limita a que el contenido sea inexacto. También afecta a si el destinatario puede reconocer que ese contenido ha sido generado o manipulado por IA en los términos exigidos por la norma.

Y no, decir “esto lo lleva marketing” ya no sirve. Si la etiqueta no aparece donde debe, si el marcado interno no permite una detección posterior, o si el proceso no deja evidencia de quién decidió qué se etiqueta y con qué criterio, el problema deja de ser comunicativo y pasa a ser de gobernanza.

Para CISOs y compliance officers, el cambio real es la carga de la prueba

La frase más relevante del anuncio de la Comisión no es la que habla de confianza, ni la que menciona la reducción de carga administrativa. Es esta idea: los firmantes del código pueden apoyarse en sus medidas para demostrar cumplimiento, mientras que quienes opten por otros medios tendrán que demostrar que esas medidas son adecuadas, con evaluaciones individuales por distintas autoridades de vigilancia del mercado.

Aquí está el quid. La obligación legal puede ser la misma para todos, pero la carga de la prueba ya no lo será.

Para un proveedor de IA generativa o para una gran organización usuaria, eso cambia el diseño del control. Si firmas el código, tu tarea pasa a ser principalmente de implementación y evidencia. Si no lo firmas, debes añadir una capa de justificación metodológica: por qué tu mecanismo alternativo de marcado, tus umbrales de detección, tus decisiones de interfaz y tus excepciones interpretativas cumplen con el artículo 50 igual o mejor que el marco avalado por Bruselas.

Eso tiene tres consecuencias prácticas.

La primera es documental. Tu expediente interno necesitará algo más que políticas generales de uso responsable de IA. Harán falta decisiones de arquitectura, criterios de clasificación de contenidos, mapas de casos de uso, pruebas de funcionamiento, incidencias, revisiones y trazabilidad de excepciones.

La segunda es organizativa. El control ya no puede estar encapsulado solo en legal o solo en IT. El artículo 50 afecta a producto, canales digitales, comunicación, fraude, ciberseguridad, protección de datos y, en sectores regulados, a segunda línea de defensa. Si esas funciones no comparten inventario de casos de uso y criterios de etiquetado, el cumplimiento se volverá incoherente antes de la primera auditoría interna.

La tercera es geográfica. Las evaluaciones individuales por autoridades nacionales introducen un riesgo clásico de la UE: divergencia de criterio. Sobre el papel hay armonización. En la práctica, cualquier multinacional con operaciones en varios Estados miembros sabe que la interpretación uniforme es una aspiración noble, no siempre un hecho consumado.

Article 50 AI Act: dónde están de verdad las obligaciones que te afectan

Conviene precisar el terreno jurídico, porque el debate público sobre el AI Act ha estado tan dominado por los modelos de propósito general y por los sistemas de alto riesgo que las obligaciones de transparencia han quedado a veces en segundo plano.

La Comisión vincula expresamente este código al artículo 50(2), 50(4) y 50(5) del AI Act. Aunque la lectura completa debe hacerse sobre el texto legal consolidado y las directrices de la Comisión, el mensaje operativo es nítido: proveedores y desplegadores de sistemas generativos deben gestionar obligaciones específicas de marcado, detección y etiquetado en relación con contenido generado por IA, deepfakes y determinadas publicaciones textuales.

Eso importa porque no todas las obligaciones recaen sobre el mismo sujeto. Un proveedor del sistema puede ser responsable de habilitar funciones de marcado o detección; un desplegador puede ser responsable del etiquetado visible al usuario en un caso de uso concreto. En las organizaciones complejas, el fallo suele aparecer justo en esa costura: cada parte asume que la otra se ocupa.

Si tu entidad contrata soluciones de terceros para generar audio, imagen, vídeo o texto, necesitas saber con precisión qué parte del artículo 50 descansa sobre el proveedor y cuál no se puede externalizar sin más. El contrato ayuda, claro. Pero si la interfaz final que ve el cliente es tuya, el regulador también te mirará a ti.

La frontera difusa entre proveedor y desplegador complica el cumplimiento

Una de las razones por las que este código importa tanto para el sector financiero es que muchas entidades desempeñan ambos papeles a la vez. Compran modelos o herramientas a terceros, sí, pero luego los afinan, los integran en flujos internos, cambian la experiencia de usuario y producen contenido que se distribuye bajo su marca. A efectos prácticos, dejan de ser un mero consumidor pasivo de tecnología.

Piensa en tres escenarios muy corrientes en 2026.

Primero, un banco usa un proveedor externo para generar resúmenes de mercado personalizados y enviarlos por app a clientes de banca privada. Segundo, una aseguradora usa herramientas generativas para crear vídeos de prevención de fraude y piezas de onboarding. Tercero, una fintech produce asistentes conversacionales con voz sintética para explicar comisiones, límites o riesgos de inversión.

En los tres casos hay un proveedor tecnológico aguas arriba. Pero la decisión sobre qué se publica, cómo se muestra, qué se etiqueta y cómo se conserva la evidencia suele estar en manos de la entidad financiera. Si el diseño de control no distingue entre capacidad técnica del proveedor y responsabilidad regulatoria del desplegador, llegarán las sorpresas. Y no de las agradables.

Por eso, el código no debería leerse como una guía solo para laboratorios de IA o plataformas sociales. Afecta de lleno a sectores donde el contenido no es entretenimiento, sino parte del servicio regulado.

Impacto regulatorio cruzado

El AI Act no vive en una urna de cristal. Para una entidad financiera europea, las obligaciones de transparencia sobre contenido generado por IA se cruzan de forma incómoda, y a veces bastante interesante, con DORA, GDPR, NIS2 y marcos de control como NIST CSF 2.0. En menor medida, también con eIDAS 2.0 cuando hablamos de confianza en la procedencia y la integridad del contenido digital.

DORA: terceros ICT, pruebas y gobernanza, no solo continuidad

DORA no regula el etiquetado de contenido generado por IA. Pero sí exige, entre otras cosas, una gobernanza clara del riesgo TIC, gestión de incidentes, pruebas de resiliencia y control de terceros. El cruce más evidente está en DORA art. 28, que establece el marco sobre gestión del riesgo derivado de terceros proveedores de servicios TIC. Si una entidad financiera depende de un proveedor generativo para crear, marcar o detectar contenido, esa dependencia entra en la conversación de terceros críticos aunque la función de IA no parezca, a primera vista, una “infraestructura” clásica.

Además, los requisitos contractuales de DORA sobre funciones, niveles de servicio, cooperación con autoridades y acceso a información pueden volverse muy relevantes si el cumplimiento del artículo 50 del AI Act depende de capacidades técnicas del proveedor. Si el contrato no obliga al proveedor a preservar trazas, ofrecer explicabilidad básica sobre el mecanismo de marcado o notificar cambios materiales en la funcionalidad, el área de compliance se quedará vendida en cuanto pida evidencia.

La lectura inteligente es esta: el control de transparencia de IA debe incorporarse al inventario de dependencias TIC y al marco de terceros, no quedarse como una política separada de IA responsable hecha para tranquilizar al consejo.

GDPR: si puedes detectar o trazar, probablemente tratas datos

El cruce con protección de datos es más obvio de lo que a veces se reconoce. Los mecanismos de detección, registro de procedencia, metadatos de marcado y conservación de evidencias pueden implicar tratamiento de datos personales. Ahí entran de lleno el GDPR art. 5 sobre principios de tratamiento, el art. 25 sobre protección de datos desde el diseño y por defecto, el art. 32 sobre seguridad y, si hay brechas, el art. 33 sobre notificación de violaciones de seguridad.

Hay un problema práctico delicado. Para demostrar cumplimiento del AI Act querrás retener logs, decisiones de clasificación y pruebas sobre qué contenido fue generado, marcado o etiquetado. Para cumplir con GDPR, no puedes convertir esa trazabilidad en una aspiradora indiscriminada de datos. La solución no es renunciar a la evidencia, sino diseñarla con minimización, controles de acceso, periodos de retención definidos y separación clara entre datos operativos y evidencias de cumplimiento.

Si tu sistema usa voz sintética, avatares o personalización de mensajes, la cuestión se complica aún más. Cuanta más proximidad haya entre contenido generado y datos identificables del cliente, más probable será que la evaluación de impacto relativa a protección de datos deje de ser una opción prudente y pase a ser una necesidad operativa.

NIS2: la transparencia de IA también roza la ciberseguridad

NIS2 se suele invocar para casi todo, a veces con entusiasmo excesivo. Aquí sí tiene una conexión razonable. El art. 21 de NIS2 obliga a las entidades esenciales e importantes a adoptar medidas técnicas, operativas y organizativas adecuadas para gestionar riesgos de ciberseguridad. Si el contenido generado por IA puede utilizarse para fraude, ingeniería social, suplantación o desinformación sobre servicios críticos, la ausencia de marcado y etiquetado deja de ser solo un problema de transparencia y se convierte en vector de riesgo operativo y de seguridad.

En banca y seguros esto no es teórico. Un audio sintético mal controlado, un vídeo corporativo manipulado o un mensaje textual generado sin etiquetas claras pueden facilitar campañas de fraude, erosión de confianza o suplantación de identidad. La coordinación entre los equipos que gobiernan IA y los que gestionan riesgo ciber bajo NIS2 debería ser mucho más estrecha de lo que suele verse hoy.

eIDAS 2.0 y confianza en origen: una conexión prometedora, todavía inmadura

EIDAS 2.0 no resuelve el problema del contenido generado por IA, pero su lógica de servicios de confianza apunta en una dirección útil: reforzar la verificabilidad del origen y la integridad de la información digital. Si la industria evoluciona hacia mecanismos estandarizados de procedencia, sellado o atestación que interactúen con las exigencias de marcado del AI Act, podríamos ver un ecosistema más robusto. Hoy, sin embargo, esa convergencia está más en fase de posibilidad técnica y regulatoria que de práctica generalizada.

NIST CSF 2.0: buen mapa, insuficiente como escudo legal

NIST CSF 2.0 sigue siendo un marco excelente para ordenar gobernanza, identificación de riesgos, protección, detección, respuesta y recuperación. Pero quien crea que un control mapeado en NIST basta para satisfacer el artículo 50 del AI Act se está engañando. Sirve para estructurar procesos internos. No sustituye obligaciones legales específicas de etiquetado, marcado y evidencia. La traducción entre marcos de ciber y obligaciones del AI Act hay que hacerla de forma explícita.

Lo que cambia en banca y seguros: de riesgo reputacional a riesgo regulatorio demostrable

Durante los dos últimos años, muchas entidades financieras han tratado la IA generativa como una mezcla de oportunidad comercial y riesgo reputacional. La lógica era comprensible: si el asistente alucina, si el texto parece demasiado robotizado o si un vídeo provoca rechazo, corregimos, pedimos disculpas y ajustamos el modelo. El nuevo código empuja el asunto a otra categoría. Ya no basta con que la experiencia sea aceptable. Debe ser defendible.

Eso afecta, al menos, a cinco áreas de uso muy concretas.

La primera es el marketing regulado: contenidos de captación, vídeos de producto, simulaciones educativas, comparadores, newsletters personalizadas. Si parte del material es generado o manipulado por IA, hay que analizar cuándo entra en los supuestos de etiquetado y cómo se mantiene consistencia entre canales.

La segunda es la atención al cliente: chatbots, asistentes por voz, respuestas automáticas y sistemas híbridos humano-IA. El artículo 50 no se agota en un simple “estás hablando con una IA”, aunque ese tipo de transparencia sigue siendo relevante en otros apartados del AI Act. Cuando el sistema produce texto, audio o material manipulado, la cadena de evidencia importa.

La tercera es el fraude y la suplantación. Paradójicamente, las entidades que usan IA para defenderse también pueden ampliar su superficie de ataque si publican o distribuyen contenido sintético sin controles robustos de marcado y etiquetado. El atacante aprende rápido.

La cuarta es la comunicación corporativa en incidentes. Si una entidad genera borradores o piezas audiovisuales con IA durante una crisis operativa, cualquier error de etiquetado en un momento sensible puede agravar la percepción de opacidad. Y nadie quiere explicar transparencia defectuosa en mitad de una caída de servicio.

La quinta es la documentación interna y formación. Aquí hay más zona gris, pero conviene no minusvalorarla. Si el contenido generado por IA se usa en decisiones con impacto en empleados, agentes o mediadores, la gobernanza debería anticipar cómo se clasifica, conserva y revisa ese material.

El verdadero trabajo empieza en el inventario: qué contenido generas, manipulas o redistribuyes

La reacción más peligrosa frente a este código sería delegarlo en el proveedor tecnológico o en el equipo de comunicación. El punto de partida serio es otro: inventariar casos de uso y flujos de contenido.

Tu organización sabe hoy, con precisión, qué contenido genera IA, cuál se manipula con IA, qué proveedor interviene, qué metadatos se añaden, dónde se publica, quién aprueba la salida final y qué evidencia se conserva? Si la respuesta es “más o menos”, no tienes un programa de cumplimiento; tienes una corazonada.

Ese inventario debería separar al menos cinco variables operativas: tipo de contenido (texto, audio, imagen, vídeo), finalidad del uso, rol de la entidad (proveedor, desplegador o ambos), canal de distribución y base técnica del marcado o etiquetado. Sin eso, no hay forma razonable de aplicar de manera consistente el artículo 50 ni de decidir si adherirse al código aporta valor real.

El dato curioso, y algo incómodo, es que muchas organizaciones conocen mejor su inventario de activos de software que su inventario de salidas de IA. Tiene lógica histórica. Durante años hemos gobernado sistemas; ahora toca gobernar resultados. Y eso requiere otra disciplina.

Firmar el código o ir por libre: una decisión menos filosófica de lo que parece

Habrá empresas tentadas de no firmar el código por razones estratégicas: evitar rigidez técnica, preservar soluciones propietarias, no someterse a dinámicas colectivas o mantener libertad para diseñar controles distintos. Todo eso puede ser legítimo. La cuestión es si compensa.

La Comisión subraya tres ventajas para los firmantes: menor carga administrativa, previsibilidad y seguridad jurídica en todos los Estados miembros. Traducido al lenguaje de operaciones, eso significa menos energía invertida en defender la suficiencia abstracta del control y más foco en ejecutarlo de forma consistente.

Ir por libre tiene sentido solo si se cumplen al menos una de estas dos condiciones. Primera, que tu organización disponga de una solución técnica claramente superior y perfectamente documentada. Segunda, que tu perfil de riesgo y exposición regulatoria sea lo bastante reducido como para asumir el coste de justificación adicional. Para grandes bancos, aseguradoras, plataformas o proveedores paneuropeos, ninguna de las dos premisas será habitual.

Además, los firmantes participarán en Signatory Taskforces para compartir prácticas y avanzar en la implementación del marcado y etiquetado. Eso no es una formalidad menor. En entornos regulatorios nuevos, formar parte del circuito donde se sedimentan interpretaciones prácticas puede ser más útil que cualquier memo externo de 80 páginas.

Qué evidencias van a pedir de verdad los equipos de segunda línea y los auditores internos

Aunque el código es una herramienta voluntaria, su utilidad práctica dependerá de algo muy poco glamuroso: la capacidad de producir evidencia coherente. No una presentación bonita. Evidencia.

En organizaciones maduras, la segunda línea y auditoría interna acabarán pidiendo, como mínimo, cuatro familias de pruebas.

Una, gobernanza: políticas aprobadas, asignación de roles, criterios sobre cuándo etiquetar, procedimientos de excepción y supervisión por comités relevantes. Dos, técnica: descripción de mecanismos de marcado y detección, pruebas de funcionamiento, gestión de cambios y dependencias de proveedor. Tres, operativa: inventario de casos de uso, registros de contenido afectado, validaciones de publicación y conservación de evidencias. Cuatro, contractual y de terceros: cláusulas que aseguren cooperación, acceso a información, notificación de cambios y soporte ante requerimientos regulatorios.

Si la entidad está bajo DORA, ese cuarto bloque adquiere todavía más peso. Si además maneja datos personales, el segundo y el tercero deberán cuadrar con el esquema de retención y minimización exigido por GDPR. Lo bonito de la convergencia regulatoria es que, cuando se hace bien, un mismo control sirve a varias normas. Lo feo es que, cuando se hace mal, una misma brecha alimenta varios problemas a la vez.

Riesgos de adopción de IA en entidades financieras y controles recomendados

La banca y los seguros llevan tiempo aprendiendo que la IA generativa no falla solo por sesgo o alucinación. Falla por integración apresurada, por gobierno ambiguo y por contratos optimistas. El nuevo marco europeo sobre transparencia vuelve más visibles varios riesgos que ya estaban ahí.

El primero es el riesgo de atribución falsa de origen: contenido que parece humano pero es generado o manipulado por IA sin etiquetado suficiente. Control recomendado: reglas de clasificación por tipo de salida, etiquetas consistentes por canal y revisión legal de supuestos fronterizos.

El segundo es el riesgo de trazabilidad insuficiente: la entidad no puede reconstruir después cómo se generó una pieza, con qué herramienta o bajo qué versión de modelo. Control recomendado: registros mínimos de procedencia, gestión de cambios y conservación limitada pero verificable de metadatos.

El tercero es el riesgo de dependencia opaca del proveedor: el cumplimiento depende de funciones de marcado o detección que el proveedor modifica unilateralmente. Control recomendado: cláusulas contractuales alineadas con DORA art. 28 y gobierno de terceros específico para funciones de IA generativa.

El cuarto es el riesgo de colisión con privacidad: se almacenan más evidencias de las necesarias o se mezclan logs técnicos con datos personales sin base ni límites claros. Control recomendado: minimización de datos, separación de capas de logging, controles de acceso y revisión con DPO.

El quinto es el riesgo de uso fraudulento del propio contenido sintético: actores maliciosos reutilizan o imitan piezas generadas por la entidad para estafas o suplantaciones. Control recomendado: coordinación entre IA, marca, antifraude y ciberseguridad, con monitorización de abuso externo y planes de respuesta.

Lo que la Comisión no dice, pero el mercado ya entiende

La comunicación oficial presenta el código como un marco práctico, proporcionado y consistente. Todo cierto. Lo que no dice de forma frontal, porque no suele hacerlo, es que el mercado de la conformidad va a tratar este documento como una referencia casi obligada.

Veremos, previsiblemente, cuatro efectos durante este año. Uno, proveedores incorporando funciones de marcado y etiquetado “AI Act-ready” en sus ofertas comerciales. Dos, departamentos de compras pidiendo adhesión al código o equivalencia funcional en RFPs y anexos contractuales. Tres, auditoría interna y compliance usando el código como línea base para evaluar controles, incluso en empresas no firmantes. Cuatro, autoridades nacionales mirando con especial atención a quienes aleguen métodos alternativos sin una defensa técnica impecable.

No hace falta dramatizar. No adherirse no te convierte automáticamente en incumplidor. Pero sí te coloca en una posición argumental más frágil. Y en regulación, la fragilidad argumental suele salir cara antes o después.

Qué deberían decidir ahora los equipos de cumplimiento y seguridad

Las decisiones urgentes no son veinte. Son pocas, pero tienen que ser concretas.

Primero, determinar si la organización entra materialmente en el ámbito del artículo 50 por sus casos de uso actuales, no por sus proyectos de laboratorio. Segundo, identificar si actúa como proveedor, desplegador o ambos en cada flujo relevante. Tercero, comparar sus controles actuales con la lógica del código y con las directrices de la Comisión sobre el alcance de las obligaciones. Cuarto, revisar contratos con proveedores generativos y su encaje con requisitos de evidencia, cambios y cooperación. Quinto, decidir si adherirse al código reduce riesgo regulatorio neto frente a la alternativa de diseñar un esquema propio.

Eso debería hacerse ya, porque la fecha de aplicación de las obligaciones, 2 de agosto de 2026, no es una amenaza remota sino una realidad inmediata. Quien llegue a septiembre todavía discutiendo definiciones internas habrá confundido gobernanza con procrastinación elegante.

La conclusión incómoda: la transparencia de IA ha dejado de ser branding ético

El nuevo código europeo no convierte por sí solo a la IA generativa en confiable, ni arregla las ambigüedades del artículo 50, ni evita que cada autoridad nacional quiera dejar su huella interpretativa. Pero sí hace algo decisivo: transforma una obligación de transparencia en un problema de cumplimiento demostrable y comparable.

Eso cambia la conversación dentro de las empresas. La pregunta ya no es solo si tus clientes sabrán que una pieza fue generada por IA. La pregunta es si podrás demostrar, ante reguladores, auditoría, consejo y quizá un juez, que diseñaste y operaste ese control de forma consistente, proporcionada y trazable.

Para CISOs y compliance officers, esa es la noticia de verdad. La etiqueta visible es solo la punta del iceberg. Debajo hay arquitectura, contratos, inventario, evidencia y gobernanza. Lo demás, por decirlo con cariño, es decoración normativa.