El AI Office activa la fase política del código de transparencia para IA generativa: qué se juega realmente el 22 de junio

Bruselas no va a explicar esta semana como se firma el futuro de la IA generalista. Va a explicar algo bastante mas concreto, y bastante mas revelador: como funcionara el proceso de adhesión para los posibles firmantes del code of practice sobre transparencia del contenido generado por IA. Parece un matiz menor. No lo es. En regulación europea, los matices suelen ser el sitio exacto donde empieza la obligación real.

La diferencia importa porque en torno al AI Act se ha instalado una costumbre ya cansina: llamar “código de conducta” o “código de buenas prácticas” a cualquier pieza de soft law que aparezca en el radar de la Comisión. Pero aquí no estamos ante una sesión genérica sobre gobernanza de modelos fundacionales, ni ante una presentación abstracta de principios. La convocatoria, tal y como está formulada, se centra en un código de práctica vinculado a la transparencia del contenido generado por IA y en el proceso de firma para entidades potencialmente interesadas en adherirse. Traducido al castellano llano: Bruselas está enseñando el formulario antes de que medio mercado decida si le conviene estampar la firma.

Ese detalle cambia la lectura política del movimiento. Una sesión sobre el hipotético marco completo para la IA de propósito general sería una pieza de relato institucional. Una sesión sobre transparencia de contenidos sintéticos y sobre cómo sumarse formalmente al esquema apunta a otra cosa: implementación, señal reputacional y preparación de mercado. Menos gran discurso. Más arquitectura de cumplimiento.

Lo que la Comisión sí está diciendo, y lo que no

Conviene limpiar el ruido. La referencia correcta no es un “General-Purpose AI Code of Practice” entendido como paquete omnicomprensivo para toda la IA de propósito general. Lo que la información disponible permite sostener es algo más acotado: un code of practice relacionado con la transparencia del contenido generado por IA, acompañado de explicaciones sobre el signature process para posibles signatarios. Si alguien te vende esto como la gran ceremonia de entrada al régimen completo de GPAI, te está sirviendo marketing con sabor regulatorio.

La precisión no es pedantería. El AI Act distingue entre varias capas de obligaciones y mecanismos. Algunas están en el propio reglamento. Otras se apoyarán en normas armonizadas, guías, actos de ejecución o instrumentos voluntarios de apoyo al cumplimiento. Mezclarlo todo produce exactamente el tipo de confusión que a Bruselas le viene fatal y a los proveedores les viene aún peor.

En el texto del AI Act, la transparencia aparece como una obligación normativa concreta, no como un adorno ético. El artículo 50 fija, entre otras cosas, deberes de transparencia para determinados sistemas de IA, incluido el requisito de informar cuando un usuario interactúa con un sistema de IA en ciertos casos, así como exigencias relacionadas con contenido generado o manipulado artificialmente, especialmente cuando puede inducir a error. Ese anclaje jurídico importa porque sitúa el debate donde debe estar: no en la estética del compromiso voluntario, sino en la mecánica de cómo una entidad puede organizar pruebas de cumplimiento en torno a una obligación legal que ya existe o que va a exigirse operativamente.

Si la Comisión habla del proceso de firma para potenciales signatarios, la pregunta útil no es si el código suena bien. La pregunta útil es otra: ¿qué valor tendrá adherirse cuando lleguen las comprobaciones reales, las auditorías internas, las preguntas de clientes corporativos y los requerimientos de autoridades nacionales? Ahí es donde empieza la conversación interesante.

Transparencia no significa “poner una etiqueta y seguir adelante”

Uno de los errores más persistentes en IA regulada es asumir que la transparencia se resuelve con una nota al pie. No. La obligación de transparencia, cuando baja del PowerPoint al proceso, exige diseño, trazabilidad y gobierno documental. Y eso no lo arregla un equipo de comunicación redactando una frase amable para la interfaz.

El artículo 50 del AI Act obliga a mirar varias capas a la vez. La primera es la experiencia del usuario: qué se le comunica, cuándo y con qué claridad. La segunda es la capa técnica: cómo identifica el sistema que un contenido ha sido generado o manipulado por IA y cómo se mantiene esa identificación a lo largo del ciclo de vida del contenido. La tercera es la capa de control: quién aprobó el enfoque, con qué criterios, con qué excepciones y cómo se revisa cuando el producto cambia.

Por eso la idea de un código de práctica sobre transparencia del contenido generado por IA tiene lógica regulatoria. No porque sustituya al reglamento, que no lo hace, sino porque puede estandarizar comportamientos, lenguaje y evidencias. En otras palabras: puede ayudar a que distintas empresas no inventen veinte maneras incompatibles de demostrar lo mismo. Bruselas lleva años intentando eso en varios frentes. A veces le sale bien. A veces produce documentos larguísimos que nadie recuerda salvo el abogado que tiene que citarlos en una reunión. Aquí todavía estamos por ver en qué categoría cae.

Lo relevante, de momento, es que la Comisión parece querer convertir la transparencia en algo firmable, visible y potencialmente comparable entre actores del mercado. Eso tiene una ventaja clara: reduce ambigüedad. También tiene un riesgo evidente: si el contenido del código se queda en formulaciones de salón, la adhesión servirá para relaciones públicas y poco más.

La obsesión europea por la “demostrabilidad” está detrás de todo esto

Hay una idea que conecta buena parte del paquete regulatorio digital europeo: no basta con decir que cumples; tienes que poder enseñarlo. Esa lógica no nace con el AI Act y, de hecho, atraviesa normas muy distintas. En protección de datos, el GDPR lo formula con claridad en el artículo 5.2, el principio de accountability: el responsable no solo debe cumplir los principios del artículo 5.1, sino ser capaz de demostrar ese cumplimiento. En ciberseguridad, NIS2 empuja en la misma dirección al exigir medidas técnicas, operativas y organizativas apropiadas y proporcionadas en su artículo 21. En finanzas, DORA construye gran parte de su andamiaje alrededor de marcos documentados, pruebas, gestión de incidentes, terceros TIC y gobernanza verificable, con artículos como el 5 sobre marco de gestión del riesgo TIC, el 17 sobre clasificación y notificación de incidentes y el 28 sobre gestión del riesgo de terceros proveedores de servicios TIC.

Esa convergencia regulatoria merece atención porque desmonta una excusa muy usada en los equipos de producto: “ya redactaremos algo cuando llegue el regulador”. No funciona así. Si el AI Act y sus instrumentos de apoyo van empujando hacia mecanismos de transparencia verificables, la carga práctica recae en diseñar procesos que produzcan evidencia. Evidencia reutilizable, además. Si no, cada obligación nueva se convierte en un proyecto distinto, con su comité, su excel y su crisis de última hora. Europa no está regulando solo conductas; está regulando la capacidad de probarlas.

La sesión informativa sobre el proceso de adhesión encaja precisamente en esa lógica. Firmar un código de práctica, por sí solo, no equivale a cumplir el AI Act. Pero sí puede convertirse en una pieza de un expediente de cumplimiento: una señal de compromiso, una referencia metodológica y, si el contenido es suficientemente concreto, un marco interno para alinear diseño de producto, legal y compliance. Dicho de otro modo: la firma no te salva. La ausencia de proceso, desde luego, tampoco.

Qué está en juego para proveedores y desplegadores

La conversación sobre códigos voluntarios suele dividir al mercado en dos bandos igual de simplistas. Unos creen que firmar cualquier esquema lanzado desde Bruselas otorga ventaja competitiva inmediata. Otros lo desprecian como teatro regulatorio. Ambas posturas se quedan cortas.

Para un proveedor de sistemas o herramientas que generan contenido sintético, adherirse a un código de práctica sobre transparencia puede tener varios usos concretos. Primero, puede facilitar la interlocución comercial con clientes que necesitan garantías mínimas sobre etiquetado, divulgación y controles internos. Segundo, puede ordenar equipos internos que siguen discutiendo cuestiones básicas —qué se etiqueta, dónde, con qué excepciones— como si siguieran en fase de laboratorio. Tercero, puede servir como puente provisional mientras aterrizan guías adicionales, prácticas de mercado o criterios supervisores más maduros.

Para los desplegadores, la utilidad es distinta. No compran el código como quien compra una póliza. Lo usan como criterio de diligencia en la cadena de suministro. Si un proveedor quiere vender soluciones que generan texto, audio, imagen o vídeo sintético, el cliente serio querrá saber cómo cumple las obligaciones de transparencia relevantes, qué controles técnicos utiliza y qué documentación puede enseñar. Un proceso de adhesión claro no sustituye la due diligence, pero introduce una señal. En mercados saturados de promesas, una señal ordenada ya es algo.

Ahora bien, cuidado con la trampa habitual. La adhesión voluntaria no elimina el trabajo contractual ni el trabajo de integración. La entidad que despliega la herramienta sigue necesitando mapear responsabilidades, revisar instrucciones de uso, entender limitaciones, definir supuestos de interacción con usuarios y documentar cómo se aplican las medidas de transparencia en su caso concreto. El AI Act no funciona como un seguro mágico que el proveedor contrata y el cliente disfruta. Esa fantasía dura exactamente hasta la primera incidencia.

La tensión de fondo: voluntario en la forma, casi obligatorio en la práctica

Europa conoce bien este mecanismo. Llama voluntario a un instrumento que, sin imponer por sí mismo una obligación nueva, termina siendo muy difícil de ignorar para quien quiere operar con comodidad regulatoria y reputacional. Pasó con estándares, con códigos sectoriales y con esquemas de certificación que, sin ser universalmente exigibles, se convierten en referencia de mercado. No porque lo diga un eslogan institucional, sino porque compradores, socios, auditores y abogados empiezan a preguntar por ellos.

Eso puede ocurrir aquí. Si el proceso de firma se diseña de forma visible y el código ofrece un mínimo de concreción técnica, veremos una presión competitiva rápida. Nadie querrá ser el proveedor que responde al cuestionario comercial con un vago “seguimos las mejores prácticas internas” mientras su competidor enseña adhesión formal, documentación de controles y lenguaje armonizado con el ecosistema europeo. En cumplimiento, la voluntariedad tiene a veces una vida útil muy corta.

La clave estará en el nivel de detalle. Un código de práctica útil necesita bajar a decisiones operativas: cómo informar al usuario, cómo tratar excepciones, cómo abordar distintos formatos de contenido, cómo registrar el cumplimiento y cómo gestionar actualizaciones de producto que alteran el modo en que se genera o presenta el contenido. Si se queda en declaraciones aspiracionales sobre “fomentar la confianza”, servirá para eventos y discursos. Para mucho más, no.

Donde el AI Act se cruza con DORA, GDPR y NIS2 sin necesidad de forzar la comparación

Aquí conviene evitar un vicio frecuente: meter todas las normas en la misma batidora y llamarlo “enfoque holístico”. Horrible palabra. Y peor práctica. Las normas europeas no dicen lo mismo ni persiguen exactamente lo mismo. Pero sí generan puntos de fricción concretos cuando una organización usa IA para producir contenido, automatizar interacciones o integrarla en procesos críticos.

El cruce con GDPR es claro cuando el contenido generado por IA incorpora o puede inferir datos personales. En ese escenario no basta con pensar en transparencia bajo el AI Act. También entran en juego los principios del artículo 5 del GDPR, las bases jurídicas del artículo 6 si hay tratamiento de datos personales, la obligación de protección de datos desde el diseño y por defecto del artículo 25, y la seguridad del tratamiento del artículo 32. Si además hay violación de seguridad, el artículo 33 activa la notificación a la autoridad de control en determinadas circunstancias. No hace falta inflar la comparación con grandes frases; el solapamiento jurídico ya es suficientemente serio por sí solo.

El cruce con NIS2 aparece cuando hablamos de gestión del riesgo y seguridad de redes y sistemas de información. El artículo 21 exige medidas apropiadas y proporcionadas que incluyen, entre otras, políticas de análisis de riesgos, gestión de incidentes, continuidad, seguridad de la cadena de suministro y uso de criptografía cuando proceda. Si una organización integra generación de contenido por IA en servicios esenciales o importantes, no puede tratar la transparencia como un asunto de simple etiquetado visual. La seguridad, la resiliencia y la gobernanza del proveedor forman parte del mismo problema.

En el sector financiero, DORA añade otra capa especialmente incómoda para quien todavía vea la IA como juguete de productividad. El reglamento obliga a un marco sólido de gestión del riesgo TIC en su artículo 5, impone disciplina en la gestión y notificación de incidentes en los artículos 17 y siguientes, y dedica el artículo 28 y siguientes a la gestión del riesgo de terceros proveedores de servicios TIC. Si una entidad usa herramientas de IA provistas por terceros para procesos relevantes, el análisis no puede quedarse en “el proveedor firma un código de transparencia”. Tendrá que mirar dependencias, subcontratación, acceso a datos, resiliencia operativa, salidas contractuales y capacidad de supervisión. Menos entusiasmo de laboratorio, más contrato y más inventario.

Lo prudente, por tanto, no es afirmar que toda organización examine la IA del mismo modo o con una misma lista universal. Lo que sí puede sostenerse con base regulatoria es que, cuando la IA se inserta en operaciones sometidas a obligaciones sectoriales, la evaluación rara vez se limita a una única norma. El problema no es solo qué genera la herramienta, sino en qué proceso se usa, qué datos toca, de qué proveedor depende y qué obligaciones documentales se activan en paralelo.

El verdadero valor de la sesión: enseñar cómo Bruselas quiere ordenar el mercado

Las sesiones informativas de la Comisión suelen tener dos niveles de lectura. El primero es el literal: explicar un documento, un proceso o una convocatoria. El segundo, bastante más interesante, es cultural: mostrar qué espera Bruselas del mercado sin necesidad de lanzar todavía una batería completa de decisiones coercitivas. Esta entra de lleno en la segunda categoría.

Si el foco está en la transparencia del contenido generado por IA y en el proceso de firma para potenciales signatarios, la Comisión está haciendo tres cosas a la vez. Está delimitando el perímetro de una expectativa de conducta. Está creando una vía de alineamiento temprano para proveedores y otros actores. Y está insinuando que la conversación regulatoria ya no gira solo alrededor de riesgos abstractos de modelos avanzados, sino alrededor de controles visibles para productos y servicios concretos.

Esto tiene consecuencias prácticas inmediatas. La primera es de lenguaje. Las empresas harían bien en dejar de hablar de “IA responsable” como paraguas retórico y empezar a describir medidas específicas: avisos al usuario, marcadores de contenido, políticas de revisión, logs, gobernanza de cambios, validación jurídica de casos de uso. La segunda es de procurement. Los equipos de compras deberían incorporar preguntas precisas sobre transparencia de contenido generado por IA en cuestionarios de proveedores. No preguntas genéricas sobre ética, sino cuestiones verificables sobre funcionamiento y prueba documental. La tercera es de producto. Si tu sistema necesita que la transparencia se añada al final, probablemente llegas tarde.

Qué deberían hacer ahora las empresas, sin esperar al siguiente seminario de Bruselas

La reacción sensata no es correr a firmar cualquier cosa sin leer la letra pequeña. Tampoco es esperar meses a que aparezca un FAQ milagroso. Hay trabajo útil que puede hacerse ya, incluso con información parcial.

• Mapear casos de uso: identifica dónde tu organización genera, transforma o distribuye contenido sintético con IA. Separa texto, audio, imagen y vídeo. No todo activa los mismos riesgos ni las mismas obligaciones de transparencia.
• Vincular cada caso a una base regulatoria: si hay datos personales, ancla el análisis también al GDPR, especialmente a los artículos 5, 25 y 32. Si el servicio entra en perímetros críticos o esenciales, revisa NIS2 art. 21. Si eres entidad financiera o proveedor TIC relevante para el sector, cruza el caso con DORA art. 5 y art. 28, como mínimo.
• Definir cómo se materializa la transparencia: dónde aparece el aviso, qué lenguaje usa, quién lo aprueba, cómo se registra, qué excepciones existen y cómo se revisa tras cada cambio de producto.
• Revisar contratos y due diligence: si dependes de terceros, no te quedes en la promesa comercial. Pide documentación, responsabilidades claras, control de cambios y soporte para evidencia de cumplimiento.
• Preparar un expediente de prueba: políticas, capturas de interfaz, registros de decisiones, evaluaciones internas y documentación técnica mínima. La pregunta útil no es si “cumples”; es si puedes enseñarlo sin improvisar.

Esta lista no sustituye asesoramiento jurídico ni técnico. Pero evita el error más caro en cumplimiento digital: descubrir demasiado tarde que la obligación era demostrable y tú solo tenías discurso.

La objeción obvia: “todo esto sigue siendo demasiado blando”

La crítica tiene parte de razón. Un código de práctica, incluso bien diseñado, no equivale a una obligación directamente sancionable por sí mismo en todos sus extremos. El mercado europeo está lleno de documentos que orientan más de lo que obligan. Y sí, existe el riesgo de que algunos actores conviertan la adhesión en una insignia reputacional sin transformar de verdad sus procesos.

Pero descartarlo por “blando” sería leer mal la película. El cumplimiento europeo rara vez se construye solo con el martillo. Se construye con una mezcla de texto legal, guías, estándares, expectativas supervisoras y presión contractual. El resultado puede ser más difuso de lo que le gustaría a un ingeniero y menos elegante de lo que presume un jurista, pero suele terminar moldeando conductas reales. A veces con desesperante lentitud. A veces de golpe, cuando una exigencia de cliente o una revisión interna hace visible el vacío documental.

Además, la transparencia del contenido generado por IA es uno de esos temas donde la tolerancia social y regulatoria a la ambigüedad va disminuyendo. Durante años, el contenido sintético podía presentarse como novedad llamativa o como curiosidad tecnológica. Ese margen se estrecha. Cuando el riesgo es confusión, manipulación o engaño, la paciencia institucional se acorta. Y cuando Bruselas empieza a ordenar mecanismos de adhesión y firma, conviene asumir que está preparando algo más que una foto de familia.

Mi lectura: menos épica sobre la IA generalista, más ingeniería de cumplimiento

La noticia interesante no es que la Comisión organice otra sesión informativa. Hace eso constantemente. La noticia interesante es el objeto concreto de esta: transparencia del contenido generado por IA y proceso de firma para potenciales signatarios. Ahí hay una pista bastante nítida sobre cómo quiere disciplinar el mercado en esta fase.

Durante meses, buena parte del debate sobre IA en Europa se ha quedado atrapado entre dos exageraciones. Una, la que presenta cada movimiento de Bruselas como si fuera la Constitución definitiva de la inteligencia artificial. Otra, la que reduce cualquier instrumento no legislativo a puro humo. Ninguna ayuda a las empresas que tienen que operar mañana. Lo que ayuda es distinguir entre relato y mecanismo.

Y el mecanismo aquí apunta a algo muy concreto: hacer que la transparencia sea menos abstracta, más visible y más fácil de convertir en criterio de compra, de revisión interna y de escrutinio regulatorio. Eso no resuelve todos los problemas del AI Act. Ni de lejos. Tampoco responde por sí solo a las cuestiones más espinosas sobre modelos de propósito general. Pero sí toca una zona donde el cumplimiento puede empezar a tomar forma práctica, con decisiones que afectan producto, legal, procurement y riesgo operativo.

Si yo fuera proveedor, no trataría esta sesión como un simple trámite institucional. La usaría para entender qué espera Bruselas que pueda firmarse, mostrarse y sostenerse con evidencia. Si fuera comprador corporativo, empezaría a preparar preguntas más finas para mis proveedores. Y si fuera responsable de cumplimiento, dejaría de preguntar si esto va “de IA” y empezaría a preguntar qué obligación concreta activa, en qué artículo y con qué prueba interna.

Porque al final va de eso. No de la grandilocuencia sobre la IA del futuro, sino de algo bastante menos glamuroso y bastante más determinante: quién puede demostrar, con un proceso reconocible, que la transparencia del contenido generado por IA no depende de la buena voluntad del departamento de marketing.

Bruselas, una vez más, no está escribiendo poesía. Está diseñando casillas para marcar, documentos para firmar y expectativas que luego aparecerán en contratos, auditorías y cuestionarios de clientes. Quien siga leyendo estas señales como si fueran mera escenografía regulatoria quizá descubra demasiado tarde que el decorado era, en realidad, el edificio.