— 12 min de lectura
Desde el 2 de agosto de 2026, las obligaciones de transparencia del Artículo 50 del Reglamento europeo de Inteligencia Artificial son aplicables y las autoridades nacionales pueden exigir su cumplimiento. En España, esa autoridad es la AESIA.
Durante los meses previos al verano hubo algo de confusión, porque el AI Omnibus retrasó parte del calendario del reglamento y bastantes empresas dieron por hecho que la prórroga también iba con ellas. A la mayoría no les afecta la prórroga.
Este artículo aclara qué entró en vigor, qué se retrasó, y qué implica en términos de arquitectura para un equipo que ya tiene funcionalidades de IA en producción.
Qué se retrasó y qué no
El Reglamento (UE) 2026/1744, conocido como AI Omnibus, entró en vigor el 27 de julio de 2026 y movió al 2 de diciembre de 2027 las obligaciones de los sistemas de alto riesgo del Anexo III. Ese es el retraso del que se habló en verano.
El Artículo 50 quedó fuera de ese aplazamiento y se aplica desde su fecha original. También siguen su calendario las prácticas prohibidas del Artículo 5 y las obligaciones de los modelos de propósito general.
Esto es importante porque el Artículo 50 tiene un alcance mucho más amplio que el resto del reglamento. No depende de que tu sistema sea de alto riesgo: se aplica a cualquier sistema que caiga en alguno de los cuatro supuestos que cubre, aunque el caso de uso sea trivial.
Hay una única excepción temporal que comentaremos más adelante.
Los cuatro supuestos del Artículo 50
El artículo cubre cuatro situaciones distintas, cada una con obligaciones propias:
- Sistemas que interactúan con personas. Chatbots, asistentes de voz, agentes conversacionales. El usuario tiene que saber que habla con una máquina, salvo que resulte evidente por el contexto.
- Generación de contenido sintético. Texto, imagen, audio o vídeo generado o modificado con IA. El contenido debe llevar un marcado legible por máquina que permita a terceros detectar su carácter artificial.
- Reconocimiento de emociones y categorización biométrica. Hay que informar a las personas expuestas al sistema y tratar los datos conforme a la normativa de protección de datos.
- Deepfakes y textos de interés público. El contenido hiperrealista que representa personas, lugares o hechos reales debe ir etiquetado de forma visible. Lo mismo ocurre con los textos publicados para informar sobre asuntos de interés general cuando no ha habido revisión editorial humana.
Qué queda fuera
El reglamento excluye los sistemas que cumplen funciones auxiliares de edición y no alteran de forma sustancial el contenido de entrada. Un corrector ortográfico, un traductor o una herramienta de formato quedan fuera.
ambién quedan fuera los procesos que no producen contenido dirigido a personas: un pipeline que clasifica tickets internos, un extractor de entidades de contratos o un sistema de scoring que alimenta un panel interno.
La frontera se vuelve borrosa cuando hay revisión humana de por medio. Si una persona edita, valida y asume la autoría de un texto generado con ayuda de IA, la obligación de etiquetado del Artículo 50(4) decae. La clave está en si esa revisión es real y está documentada, o si es un trámite formal sobre un contenido que se publica tal cual sale del modelo.
Proveedor o responsable del despliegue
Esta es la distinción que más problemas está dando, porque determina qué obligaciones te tocan.
Eres proveedor si desarrollas el sistema de IA y lo pones en el mercado bajo tu nombre. La obligación técnica de marcado del Artículo 50(2) aplica principalmente a este caso.
Eres responsable del despliegue (deployer) si utilizas un sistema de IA bajo tu propia autoridad. Aquí caen las obligaciones de información y de etiquetado visible: avisar de que se interactúa con una IA, etiquetar deepfakes, informar a quien queda expuesto a un sistema de reconocimiento de emociones.
La mayoría de las empresas que integran IA en su producto son responsables del despliegue y no proveedores, porque consumen modelos de terceros a través de una API. Eso simplifica bastante el trabajo técnico, aunque no lo elimina.
Existe un matiz relevante: si modificas sustancialmente un sistema de IA de terceros o lo comercializas bajo tu propia marca, puedes pasar a ser considerado proveedor con todas las obligaciones que eso conlleva. Merece una revisión jurídica si tu producto envuelve un modelo ajeno o has hecho cambios sustanciales a un modelo existente.
La fecha del 2 de diciembre de 2026
Los sistemas de IA generativa que ya estaban en el mercado europeo antes del 2 de agosto de 2026 disponen de un periodo transitorio hasta el 2 de diciembre para cumplir la obligación de marcado del Artículo 50(2). Los sistemas introducidos a partir del 2 de agosto deben cumplir desde el primer día.
El periodo transitorio cubre únicamente la obligación de marcado legible por máquina que corresponde al proveedor. Las obligaciones del responsable del despliegue —informar, etiquetar deepfakes, avisar en reconocimiento de emociones— se aplican desde agosto sin transición alguna.
El contenido publicado antes del 2 de agosto no hay que etiquetarlo de forma retroactiva.
El Código de Buenas Prácticas
La Comisión publicó el 10 de junio de 2026 el Código de Buenas Prácticas sobre Transparencia del contenido generado por IA, elaborado por la Oficina Europea de IA con expertos independientes y parte de la industria. Tanto la Comisión como el AI Board lo han validado como instrumento adecuado para demostrar cumplimiento.
La adhesión es voluntaria y las obligaciones del Artículo 50 siguen siendo exigibles con independencia de que firmes o no. Su utilidad práctica está en que convierte un artículo de reglamento en medidas concretas, con un marco común europeo en lugar de veintisiete interpretaciones nacionales.
Para una empresa que genera contenido con IA de forma habitual, alinearse con el código es la vía más rápida de acreditar diligencia ante una autoridad, un cliente o un auditor.
La Comisión adoptó además el 20 de julio sus Directrices sobre la aplicación del artículo, que aclaran alcance, definiciones y excepciones. Es el documento de referencia para decidir si un caso de uso concreto entra o no.
Qué significa en tu arquitectura
Separamos en tres partes la implementación:
1. El aviso en la interfaz
Es la más fácíl de implementar. Un chatbot de soporte necesita indicar que la respuesta viene de un sistema automático, y ese aviso tiene que estar donde el usuario lo vea antes de escribir, no en los términos de uso. Si el sistema escala a un agente humano en algún punto, el cambio debe ser perceptible. El usuario tiene derecho a saber en qué momento deja de hablar con la máquina.
2. La procedencia en la capa de datos
No podemos dejar el etiquetado solo en manos del frontend. Cuando la información de origen vive solo en la interfaz, se pierde en cuanto ese contenido viaja a otro consumidor: una API pública, un feed, una integración con un cliente.
La condición de sintético debería viajar con el dato desde que se genera. En una arquitectura desacoplada con Symfony y API Platform, se resuelve extendiendo el esquema de tus recursos y propagando esos metadatos con serializers y event listeners que intercepten los objetos de dominio antes de persistirlos o exponerlos:
{
"@context": "/api/contexts/Article",
"@id": "/api/articles/42",
"@type": "Article",
"title": "Optimización de bases de datos relacionales",
"provenance": {
"isSynthetic": true,
"generationSystem": "internal-llm-v1",
"humanReviewed": false,
"reviewedBy": null,
"generatedAt": "2026-09-01T10:30:00Z"
}
}El campo humanReviewed es el que determina si el Artículo 50(4) te obliga a etiquetar un texto de interés público, y tenerlo modelado desde el principio evita revisiones manuales caras más adelante.
Para integraciones B2B conviene además exponerlo en cabeceras, de modo que un consumidor automatizado pueda leerlo sin parsear el cuerpo de la respuesta:
X-AI-Generated: true
X-AI-Provenance: system=internal-llm-v1; reviewed=false3. La traza auditable
Si una autoridad pregunta por el origen de un contenido publicado, necesitas poder recorrer el camino inverso: qué prompt lo generó, con qué modelo y versión, con qué parámetros, y quién lo revisó.
El patrón que mejor funciona sin penalizar el tiempo de respuesta es escribir la traza de forma asíncrona. La aplicación publica el evento en una cola —Pub/Sub, por ejemplo— y un consumidor lo persiste en PostgreSQL con campos JSONB o en almacenamiento de objetos.
Cuando el sector lo requiere, esas trazas se guardan con políticas de retención inmutables, de modo que nadie pueda alterarlas durante el periodo de conservación, ni siquiera con permisos de administración.
Un aviso sobre las herramientas de observabilidad de LLM. Langfuse y similares resuelven bien el tracing, pero conviene revisar dónde acaban los prompts: contienen información corporativa y a veces datos personales. Langfuse se puede desplegar en tu propia infraestructura, y en entornos regulados esa suele ser una mejor opción frente al servicio gestionado.
Sobre el marcado técnico del contenido
Si consumes modelos a través de APIs cerradas, no puedes intervenir en la generación para insertar una marca de agua en el texto. Esa obligación recae en el proveedor del modelo (OpenAI, Anthropic y similares), y tu trabajo consiste en propagar y conservar la información de procedencia que sí controlas.
Si despliegas modelos propios, entras en el terreno del marcado probabilístico sobre los logits. Funciona razonablemente en texto largo y de alta entropía, y se degrada en respuestas cortas, estructuradas o con vocabulario restringido, donde sesgar la elección de tokens perjudica la calidad. Conviene medir ese impacto antes de decidir si compensa.
Qué pasa si no cumples
Las sanciones por incumplir el Artículo 50 alcanzan los 15 millones de euros o el 3% del volumen de negocio anual mundial, la cifra que resulte mayor.
Antes de llegar ahí, el riesgo más probable en el día a día es otro: un cliente corporativo que incluye el cumplimiento del AI Act en su cuestionario de proveedores y descarta a quien no sabe responder. Está ocurriendo ya en procesos de compra, y llega antes que cualquier inspección.
Por dónde empezar
Un orden razonable para las próximas semanas:
- Inventario. Qué sistemas de IA tenéis en producción, cuáles generan contenido, cuáles hablan con personas y cuáles trabajan solo hacia dentro.
- Clasificación. Para cada uno, si actuáis como proveedor o como responsable del despliegue, y en qué supuesto del Artículo 50 cae.
- Los avisos primero. Son la obligación más inmediata, la más visible y la más barata de implementar.
- Modelo de procedencia. Añadir los campos al esquema y propagarlos por la API antes de que el volumen de contenido lo haga costoso.
- Trazabilidad. Ingesta asíncrona y persistencia, con inmutabilidad si vuestro sector lo exige.
- Documentar. Las decisiones y sus motivos. Una autoridad valora la diligencia demostrable tanto como el resultado.
Cómo lo abordamos en Softspring
Trabajamos con equipos que llevan años con software en producción y que ahora tienen que encajar estas obligaciones sin rehacer su arquitectura.
Nuestro criterio es proporcionar el nivel de gobernanza que corresponde a cada escala. Un sistema de trazabilidad sobredimensionado dispara los costes de cómputo y almacenamiento sin aportar garantías adicionales, y un marcado mal ajustado degrada la calidad del producto que estabas intentando proteger.
Si estáis diseñando la arquitectura de vuestros servicios de IA o necesitáis adaptar aplicaciones y APIs que ya están funcionando, podemos revisar vuestro caso y proponer un plan de adaptación realista.
Este artículo describe obligaciones técnicas y no constituye asesoramiento jurídico. Para determinar el alcance exacto de vuestras obligaciones, consultad con vuestro equipo legal o con un despacho especializado.