EU AI Act: el expediente técnico artículo por artículo sobre la arquitectura LLM on-premise del blog

Post hermano del mapeo a ISO/IEC 42001. Aquel descomponía el sistema de gestión de IA — la norma certificable. Éste descompone el reglamento legal vinculante que aplica sin certificación: el EU AI Act es ley directa en los 27 Estados miembros, sin transposición, con sanciones explícitas hasta 35 millones de euros o el 7% del volumen mundial. Las obligaciones principales para sistemas de alto riesgo entran en vigor el 2 de agosto de 2026; cada artículo aplica desde su fecha, no desde la fecha de certificación de la organización.

TL;DR

El Reglamento UE 2024/1689 (EU AI Act, “Reglamento Europeo de Inteligencia Artificial”) publicado en el Diario Oficial el 12 de julio de 2024 establece obligaciones por niveles de riesgo (prohibido, alto, limitado, mínimo) y por rol (provider, deployer, importer, distributor, authorised representative). Las obligaciones para sistemas de alto riesgo (Anexo III: biometría, infraestructura crítica, educación, empleo, servicios esenciales públicos y privados, law enforcement, migración, justicia, procesos democráticos) entran en vigor el 2 de agosto de 2026 y son la categoría que aplica a la mayoría de proyectos LLM en empresa media-grande. Este post mapea artículo por artículo las obligaciones relevantes para un sistema LLM de alto riesgo desplegado on-premise: cada artículo enuncia su exigencia, identifica qué post del blog ya describe la pieza técnica que la materializa, y cierra con un checklist auditable que un proveedor presenta a una autoridad de supervisión nacional. El expediente técnico del Anexo IV se reconstruye apuntando sus nueve apartados obligatorios a los runbooks técnicos correspondientes. Se cubren además: la clasificación del Art. 6 y cómo decidir si un sistema cae como alto riesgo, las prohibiciones del Art. 5 (qué se excluye por construcción), las obligaciones GPAI del Art. 53 que afectan a quien construye sobre modelos base (Llama, Mistral, DeepSeek, Qwen) en lugar de modelos propios, el calendario completo de fechas de aplicación (5 ago 2024 entrada en vigor, 2 feb 2025 prohibiciones, 2 ago 2025 GPAI, 2 ago 2026 alto riesgo Anexo III, 2 ago 2027 alto riesgo Anexo I y GPAI sistémico), el cuadro de sanciones del Art. 99 (hasta 35 M€ o 7% del volumen mundial para violaciones de Art. 5, 15 M€ o 3% para alto riesgo, 7,5 M€ o 1% para información incorrecta) y las cinco trampas frecuentes del cumplimiento. La tesis editorial: la arquitectura técnica descrita en el blog cubre directamente entre el 70% y el 85% de las exigencias técnicas del Reglamento; el resto es disciplina documental y procedimental (FRIA, CE marking, declaración de conformidad firmada, registro en EU database, reporting de incidentes en plazos legales) que se construye sobre artefactos técnicos ya existentes pero que tiene su propio circuito.

La analogía: el expediente de homologación de un vehículo nuevo

Un fabricante de vehículos no puede vender un coche nuevo en la UE sin pasar WVTA (Whole Vehicle Type Approval). El proceso es público y estandarizado: el fabricante prepara un expediente técnico con docenas de capítulos (frenos, emisiones, seguridad activa y pasiva, iluminación, ruido, peso, dimensiones, materiales reciclables, dispositivos de ayuda al conductor), lo presenta a una autoridad de homologación o a un servicio técnico notificado, éste audita el dossier y, si todo cuadra, emite la homologación de tipo. El fabricante entonces estampa la etiqueta E (E1 Alemania, E9 España, etc.) y la placa CE/UNECE en cada vehículo de ese tipo producido en serie. Cada vehículo lleva además un libro de mantenimiento con revisiones obligatorias, y los accidentes graves o defectos sistémicos se reportan al ministerio competente, que puede ordenar llamadas a revisión.

El EU AI Act adapta exactamente este modelo industrial al software de IA de alto riesgo. El provider prepara el expediente del Anexo IV (nueve apartados obligatorios) con la documentación técnica completa del sistema, ejecuta un conformity assessment (con autoeval para la mayoría de casos del Anexo III, con notified body para los del Anexo I más sensibles), firma la declaración de conformidad UE, registra el sistema en la base de datos europea, y aplica el CE marking al sistema cuando se pone en mercado. A partir de ahí, debe mantener un post-market monitoring system vivo y reportar los incidentes graves a las autoridades de vigilancia del mercado de cada Estado miembro en plazos legales que van de 2 a 15 días según severidad. Si no cumple, las sanciones llegan a 35 millones de euros o el 7% del volumen mundial según artículo violado.

La analogía importa porque acota expectativas: este no es un trabajo de compliance puntual ni un sello que se compra. Es un proceso de homologación industrial, con cadencias, evidencias, firmas y responsabilidades penales. Y la mayor parte de las evidencias técnicas que pide el expediente ya existen en cualquier sistema serio descrito en este blog: lineage de datos, tracing OTel, evals continuos, guardrails, retrain incident-driven, política de uso responsable. Lo que falta es ensamblarlas en el formato legal correcto.

Encaje con ISO 42001, NIS2 y ENS

Antes de bajar a los artículos, recordamos la posición editorial del post sobre ISO 42001:

Implantar 42001 facilita demostrar artículos 9-17 del EU AI Act, pero no equivale a cumplimiento legal. El cuadro de obligaciones legales y la cadena de responsabilidad penal vienen del Reglamento, no de la norma. Una organización certificada en 42001 que despliega un sistema de alto riesgo sin CE marking, sin registro en EU database, sin declaración de conformidad firmada y sin FRIA documentada, incumple el Reglamento aun teniendo el certificado en la pared.

Las cuatro categorías de riesgo y la clasificación del Art. 6

El Reglamento clasifica los sistemas en cuatro niveles de riesgo. La elección de categoría es del provider y debe documentarse en el expediente, con justificación técnica y legal.

El test del Art. 6 para decidir si un sistema es de alto riesgo:

1. ¿Está en el Anexo I? (productos regulados por legislación de armonización del listado: maquinaria, ascensores, juguetes, dispositivos médicos, etc.). Si el sistema IA es componente de seguridad de un producto del Anexo I, es alto riesgo.
2. ¿Está en el Anexo III? (ocho áreas: biometría, infraestructura crítica, educación, empleo, servicios esenciales públicos/privados, law enforcement, migración/asilo, justicia/procesos democráticos). Si el sistema cae en alguna de esas áreas, es alto riesgo, excepto si se invoca la excepción del Art. 6.3 (sistemas con tarea procedimental limitada, mejora de actividades humanas previas, detección de patrones de decisión sin influir en la decisión final, tareas preparatorias).

La excepción del Art. 6.3 requiere documentación formal que justifique por qué no aplica. Es decir, ni siquiera quedar fuera es gratis: hay que demostrar por qué.

Para los sistemas LLM típicos del blog:

• Chatbot de soporte al cliente para banca / seguros / salud: probablemente alto riesgo si automatiza decisiones contractuales sobre el cliente, riesgo limitado si solo informa.
• Asistente interno para RRHH (criba de currículos): alto riesgo (Anexo III, área empleo).
• Asistente médico (apoyo a diagnóstico): alto riesgo (Anexo III, área servicios sanitarios).
• Sistema de detección de fraude: alto riesgo (Anexo III, área servicios financieros si afecta acceso a crédito).
• Copiloto de código para desarrolladores: riesgo mínimo (no afecta a derechos fundamentales de terceros).
• LLM as a service interno sin uso productivo: riesgo mínimo.

La decisión de categoría no es opinión: se documenta y se justifica en el expediente.

Calendario de aplicación

Las obligaciones entran escalonadas. Las fechas son inflexibles:

El 2 de agosto de 2026 es la fecha que importa a la mayoría de proyectos LLM empresariales. Estamos en junio 2026: queda menos de dos meses.

Mapeo artículo por artículo

Las siguientes secciones siguen la estructura del Reglamento. Para cada artículo se enuncia la exigencia, se identifica el artefacto técnico del blog que la cubre y se cierra con un checklist auditable.

Art. 5 — Prácticas prohibidas (vigente desde 2 feb 2025)

Qué exige. Prohíbe colocar en el mercado / poner en servicio / usar sistemas IA que:

• Manipulen el comportamiento mediante técnicas subliminales o engañosas que distorsionen la toma de decisiones.
• Exploten vulnerabilidades por edad, discapacidad o situación socioeconómica.
• Implementen social scoring por parte de autoridades públicas.
• Hagan policía predictiva individual basada en perfilado.
• Hagan scraping indiscriminado facial para construir bases de datos de reconocimiento facial.
• Inferencia de emociones en lugares de trabajo o educación, salvo razones médicas/seguridad.
• Categorización biométrica que infiera atributos sensibles (raza, opinión política, orientación sexual, etc.).
• Biometría de identificación en tiempo real en espacios públicos por law enforcement, con excepciones estrictas (terrorismo, secuestro, personas desaparecidas) con autorización judicial previa.

Stack del blog. Ninguna pieza del blog facilita estas prácticas; el catálogo OSS descrito está orientado a tareas legítimas. Pero el provider debe documentar explícitamente por qué el sistema no cae en estas prohibiciones. No es asumible.

Checklist.

• Análisis de prohibiciones documentado por sistema, con declaración escrita de no aplicabilidad.
• Si el sistema usa biometría facial o análisis de emociones: análisis legal específico con dictamen.
• Revisión legal anual o ante cambio de funcionalidad.

Art. 6 — Clasificación de sistemas de alto riesgo

Qué exige. Definir si el sistema es de alto riesgo por estar en Anexo I (componente de seguridad de producto regulado) o Anexo III (8 áreas). Si está en Anexo III, evaluar excepción Art. 6.3 si aplica.

Stack del blog. El post forense y el pipeline de seis etapas describen sistemas que típicamente son alto riesgo (chatbot multi-tenant que afecta a decisiones de servicio al cliente regulado).

Checklist.

• Análisis Art. 6 firmado por responsable legal de la organización.
• Si se invoca Art. 6.3: documentación formal de la excepción.
• Re-evaluación si la funcionalidad cambia (ej. el asistente pasa de informar a tomar decisiones).

Art. 9 — Sistema de gestión de riesgos

Qué exige. Sistema iterativo, planificado y ejecutado durante todo el ciclo de vida. Identificar riesgos previsibles, estimar riesgos en uso normal y previsible mal uso, evaluar riesgos emergentes en post-market monitoring, adoptar medidas de mitigación, comunicar riesgos residuales. Las pruebas de eficacia se hacen en condiciones realistas.

Stack del blog.

• Pipeline LLMOps de seis etapas — el ciclo de vida iterativo.
• Evals: la capa después del tracing — pruebas en condiciones realistas con golden sets.
• Guardrails y safety en LLMs — medidas de mitigación operativas.
• Retrain: cerrar el bucle — gestión de riesgos emergentes via incident-driven retrain.

Checklist.

• Documento de gestión de riesgos por sistema, con identificación, mitigación, riesgos residuales aceptados y firmados.
• Procedimiento de revisión periódica (mínimo anual o ante cambio sustancial).
• Vinculación con el bucle de mejora documentado.

Art. 10 — Datos y gobernanza de datos

Qué exige. Datasets de entrenamiento, validación y testing relevantes, representativos, lo más libres de errores y completos posible, considerando características del propósito previsto. Documentar:

• Recogida y selección de datos.
• Procesamiento y anotación.
• Sesgos identificados con probabilidad de afectar derechos fundamentales o causar discriminación; medidas para prevenirlos.
• Identificación de lagunas en datos y cómo se aborda.

Stack del blog.

• Data versioning con DVC y lakeFS — los cuatro artefactos data + lineage end-to-end.
• RAG corpus curation: el bibliotecario activo — cinco capas: schema, dedup, PII, anti-contaminación, lineage.
• LLM Guard: Vault y Anonymize — anonimización runtime con restitución.

Checklist.

• Documento de gobernanza de datos por dataset (training / RAG corpus / golden eval / enriched retrain).
• Análisis de sesgos por categoría protegida con métricas (parity ratio, equalized odds, calibration).
• Procedimiento de PII / anonimización / pseudonimización con F1 medido.
• Justificación de representatividad para el contexto previsto.
• Lineage chunk→trace verificable.

Art. 11 + Anexo IV — Documentación técnica

Qué exige. Expediente técnico con los nueve apartados del Anexo IV, redactado antes de poner el sistema en el mercado, mantenido durante operación, disponible para autoridades diez años tras la última operación. Los nueve apartados:

1. Descripción general del sistema: nombre, versión, propósito, integrador, hardware previsto, instrucciones de uso.
2. Descripción detallada del diseño y desarrollo: arquitectura, modelos base, métodos de entrenamiento, decisiones de diseño con justificación.
3. Información sobre monitoreo, funcionamiento y control: capacidades, limitaciones, precisión esperada, comportamiento en uso normal y mal uso previsible.
4. Información sobre datos: datasets usados, fuentes, métodos de preparación, sesgos abordados.
5. Descripción del sistema de monitoreo y métricas: trazas, logs, dashboards.
6. Descripción del QMS y procedimientos del Art. 17.
7. FRIA si aplica (Fundamental Rights Impact Assessment, Art. 27).
8. Logs automáticamente generados que el sistema almacena (Art. 12).
9. Declaración de conformidad UE del Art. 47 incluida.

Stack del blog. Sirve como insumo directo para cada apartado:

Checklist.

• Expediente Anexo IV completo, versionado, fechado, firmado.
• Acceso retención 10 años garantizado (storage inmutable / WORM).
• Procedimiento de actualización ante cambio sustancial.

Art. 12 + Art. 19 — Record-keeping (logs)

Qué exige. El sistema de alto riesgo debe ser técnicamente capaz de generar logs automáticos durante su operación. Estos logs deben permitir:

• Trazar el funcionamiento del sistema a lo largo del tiempo.
• Facilitar el post-market monitoring (Art. 72).
• Permitir investigación de incidentes graves (Art. 73).
• Soportar auditorías.

El provider debe conservar los logs durante al menos seis meses (o más si lo exigen leyes nacionales o el QMS). Para sistemas biométricos de identificación remota, requisitos específicos adicionales.

Stack del blog.

• Tracing LLM con OpenTelemetry GenAI — el sustrato canónico. Cada request emite un span con trace_id, atributos gen_ai.*, costes, latencias, decisiones de guardrail.
• Prompt versioning — prompt_id + version viajan como atributos.
• Guardrails y safety en LLMs — atributos gen_ai.guardrail.* registran cada decisión.
• LLM Guard — spans por scanner con risk_score y action.
• Data versioning — dataset_hash y model_version propagados.

Checklist.

• OTel + backend (Tempo, Jaeger) operativos en producción.
• Retención mínima 6 meses (sugerido 24-36 meses para regulación financiera).
• Almacenamiento WORM / inmutable.
• PII en logs redactada (vía LLM Guard Vault o equivalente) — los logs no son excepción de RGPD.
• Procedimiento de consulta forense con permisos auditados.

Art. 13 — Transparencia a los deployers

Qué exige. El provider entrega al deployer instrucciones de uso claras, completas y accesibles, en lenguaje comprensible, con:

• Identidad del provider.
• Características, capacidades, limitaciones (precisión por categoría, especificaciones técnicas).
• Cambios previstos al sistema y sus métricas.
• Medidas de supervisión humana (Art. 14).
• Recursos computacionales y hardware previstos.
• Cuándo aplica, expectativa de vida del sistema y de mantenimiento.

Stack del blog.

• Catálogo OSS para LLMOps — qué componentes y con qué función.
• OSS vs hyperscalers — análisis del lock-in y dependencias documentadas.
• Anatomía petición LLM — capacidades y limitaciones forenses.

Checklist.

• Manual del usuario en lenguaje no técnico para deployer + manual técnico detallado.
• Métricas de precisión por categoría con thresholds.
• Procedimiento de cambio con notificación previa.

Art. 14 — Supervisión humana

Qué exige. Sistema diseñado para permitir supervisión humana efectiva durante el periodo de uso, con interfaces y procedimientos que faciliten:

• Comprender capacidades y limitaciones.
• Detectar disfunciones (automation bias awareness).
• Decidir no usar la salida del sistema, anularla, revertirla.
• Para biometría de identificación remota: verificación humana antes de actuar, al menos dos personas.

Stack del blog.

• Guardrails y safety — Línea 3 (Tool GR) con human-in-the-loop para acciones destructivas.
• Evals — métricas en dashboard humano accesibles.
• Tracing OTel — Langfuse con sessions humanas auditables.

Checklist.

• Interfaz de supervisión documentada con casos de uso.
• Capacidad de override / abort sin restricciones técnicas.
• Formación documentada al personal de supervisión.
• Métricas de efectividad de la supervisión (override rate, false-negative rate de la supervisión).

Art. 15 — Precisión, robustez y ciberseguridad

Qué exige. Sistemas de alto riesgo se diseñan y desarrollan para alcanzar un nivel apropiado de precisión, robustez y ciberseguridad, y para funcionar consistentemente durante todo su ciclo de vida. Las métricas relevantes de precisión se declaran en las instrucciones de uso. Resistencia a:

• Errores, fallos, inconsistencias dentro del entorno de uso.
• Sesgos de retroalimentación durante operación (feedback loops).
• Ataques que intenten explotar vulnerabilidades del sistema (data poisoning, model poisoning, model evasion, confidentiality attacks).
• Medidas técnicas y organizativas para detectar, responder, resolver vulnerabilidades.

Stack del blog.

• Quantization fundamentos — precisión vs eficiencia con métricas reportadas.
• Continuous batching + KV cache — robustez operativa.
• Guardrails: línea 1 input + línea 2 retrieval — defensa frente a prompt injection y data poisoning vía RAG.
• LLM Guard: PromptGuard 2 + scanners injection — mitigación adversarial directa.
• Evals: jailbreak resistance + adversarial — métricas de robustez evaluadas en CI.

Checklist.

• Métricas de precisión declaradas: F1 por categoría, accuracy, calibración, faithfulness RAG, hallucination rate.
• Plan de robustez frente a adversarial inputs (suite Garak / Promptfoo redteam / PyRIT ejecutada periódicamente).
• Plan ciberseguridad: gestión vulnerabilidades, patching del stack (vLLM, sus deps, cuda), secrets rotation.
• Análisis de feedback loops potenciales con monitoreo de drift.

Art. 17 — Sistema de gestión de calidad (QMS)

Qué exige. El provider tiene un QMS escrito, sistemático y proporcionado, que cubra (sin limitarse a):

• Estrategia de cumplimiento regulatorio.
• Diseño, verificación, control de calidad del sistema.
• Procedimientos de testeo, validación.
• Gestión de datos.
• Sistema de gestión de riesgos (Art. 9).
• Post-market monitoring (Art. 72).
• Reporting de incidentes (Art. 73).
• Comunicación con autoridades, deployers, otros stakeholders.
• Registros: documentación, mantenimiento de logs.
• Gestión de recursos.
• Accountability: responsabilidades de management.

Stack del blog. El QMS no es código pero se apoya en código.

• ISO/IEC 42001 implantada (post anterior) cubre prácticamente todo el contenido del Art. 17.
• Pipeline LLMOps 6 etapas como procedimiento operativo de referencia.

Checklist.

• Manual del QMS escrito, fechado, firmado, versionado.
• Plan anual de auditorías internas con criterios y registros.
• Agenda de revisión por dirección con minutas firmadas.
• Si hay 42001 implantada: mapping QMS-42001 documentado.

Art. 26 — Obligaciones de los deployers

Qué exige. Quien despliega el sistema (lo usa en su nombre, no necesariamente el desarrollador) tiene obligaciones propias:

• Usar el sistema conforme a las instrucciones (Art. 13).
• Asignar supervisión humana competente y formada (Art. 14).
• Asegurar que los datos de entrada que controla son apropiados.
• Monitorear el funcionamiento y notificar al provider si detecta problemas o incidentes graves.
• Mantener logs bajo su control durante al menos 6 meses.
• Informar a las personas afectadas cuando el sistema se use sobre ellas para tomar decisiones (en el contexto laboral, además, consultar a sus representantes).
• Para algunos casos del Anexo III: completar un FRIA (Art. 27).

Stack del blog. En el caso del chatbot multi-tenant, el deployer es la aseguradora cliente. Esta debe:

• Aceptar las instrucciones del provider (la consultora) y firmar términos.
• Configurar supervisión humana en su lado.
• Notificar al provider cuando detecta drift o queja seria.
• Conservar logs propios además de los del provider.

Checklist (para el deployer).

• Contrato con provider con SLAs, responsabilidades, plan de salida.
• Programa de formación a personal supervisor.
• Procedimiento de notificación de incidentes hacia provider.
• Política de información a afectados (en ámbito laboral, notificación a representantes).
• FRIA si aplica.

Art. 27 — Fundamental Rights Impact Assessment (FRIA)

Qué exige. Aplicable a deployers que sean cuerpos públicos o entidades privadas que provean servicios públicos, o que usen sistemas para evaluar credit score / life insurance. Antes del primer uso, el deployer hace un FRIA documentando:

• Descripción del uso previsto.
• Periodo y frecuencia de uso.
• Categorías de personas afectadas.
• Riesgos específicos de daño identificados.
• Medidas de supervisión humana.
• Medidas de mitigación si los riesgos se materializan.

El FRIA se notifica a la autoridad de vigilancia del mercado. Cambios sustanciales obligan a actualizar.

Stack del blog. El FRIA es un documento de gobierno, no un artefacto técnico. El blog no lo cubre directamente. Pero el insumo técnico es:

• Los análisis de impacto del post sobre ISO 42001 — sección A.5 son el punto de partida natural.
• Las métricas del post sobre evals sobre fairness por categoría y groundedness alimentan la sección de riesgos del FRIA.

Checklist.

• Procedimiento FRIA documentado, alineado con AIIA ISO 42005 (publicada como complemento).
• FRIA ejecutado por sistema antes del primer uso.
• Notificación a autoridad de vigilancia del mercado.
• Revisión periódica + ante cambio sustancial.

Art. 47 — Declaración UE de conformidad

Qué exige. El provider redacta una declaración de conformidad escrita por sistema de alto riesgo, indicando:

• Identificación del sistema y provider.
• Declaración de que cumple los Arts. 8-15 + Art. 17.
• Referencia a normas armonizadas y especificaciones comunes aplicadas.
• Si aplica, notified body y certificado.
• Lugar y fecha, firma y nombre del firmante autorizado.

Debe estar disponible para autoridades diez años. Se mantiene actualizada.

Stack del blog. Documento legal puro. Plantilla del Anexo V.

Checklist.

• Declaración de conformidad firmada por persona autorizada antes de mercado.
• Idiomas: al menos UE oficial donde se ponga el sistema en mercado.
• Procedimiento de re-firma ante cambio sustancial.

Art. 48 — Marcado CE

Qué exige. Sistema de alto riesgo lleva el marcado CE de manera visible, legible e indeleble. Para sistemas digitales sin parte física, el marcado se incluye en la documentación / interfaz. Si participó un notified body, su número va a continuación.

Stack del blog. El marcado CE en un sistema software se materializa típicamente en:

• Página de información del producto / “Acerca de”.
• Documentación oficial del producto entregada al deployer.
• Metadata del API exposed (header HTTP custom, OpenAPI info).

Checklist.

• CE marking visible en interfaz del producto o documentación oficial.
• Número notified body adjunto si aplicó.
• Procedimiento de actualización ante cambio sustancial.

Art. 49 — Registro en la base de datos europea

Qué exige. Antes de poner en mercado / poner en servicio un sistema de alto riesgo del Anexo III (excepto el área 2 — infraestructura crítica), el provider lo registra en la base de datos UE de sistemas IA de alto riesgo gestionada por la Comisión. Los deployers que sean autoridades públicas también registran su uso. Los datos del registro son públicos en su mayoría (transparencia hacia el público).

Stack del blog. Procedimiento administrativo puro. Sin parte técnica más allá de tener el dossier preparado.

Checklist.

• Registro completado antes del primer uso productivo.
• Actualización ante cambio sustancial.
• Acceso al portal mantenido (credenciales, contacto).

Art. 50 — Transparencia a los usuarios finales

Qué exige. Aplica a sistemas de riesgo limitado (y también a algunos de alto riesgo, complementariamente):

• Chatbots y asistentes IA: la persona que interactúa debe saber que está hablando con una IA, salvo que sea obvio del contexto.
• Contenido sintético generado (texto, audio, imagen, video): marcar como contenido AI-generated en el output, en formato machine-readable.
• Deepfakes: declarar explícitamente que el contenido es artificialmente generado o manipulado.
• Detectores de emociones o categorización biométrica: informar a las personas afectadas.

Stack del blog. Materialización técnica:

• Banner UI en el chatbot indicando “Estás conversando con un asistente IA”.
• Disclaimer en cada respuesta exportable (PDF, email): “Generado por IA”.
• Watermarking del output (perplexity-based, model-fingerprint) — opcional pero útil para deepfakes.
• Para audio/imagen/video generado, metadatos C2PA estándar.

Checklist.

• Banner UI obligatorio.
• Disclaimer en outputs exportables.
• Si genera contenido visual: marcado C2PA o equivalente.
• Procedimiento ante uso del sistema sobre persona sin su conocimiento (ej. evaluación automática de CV).

Art. 53 — Obligaciones de los proveedores de GPAI (vigente desde 2 ago 2025)

Qué exige. Los proveedores de GPAI (modelos de propósito general entrenados con vasto cómputo, típicamente fundacionales: Llama 4, Mistral, DeepSeek, Qwen, Gemma) deben:

• Mantener documentación técnica del modelo, accesible a la AI Office y autoridades nacionales.
• Hacer disponible información para los proveedores downstream que vayan a integrarlo.
• Cumplir con copyright UE (Art. 4 Directiva 2019/790): mecanismo opt-out para titulares de derechos.
• Publicar un resumen del contenido del training (Anexo XI - copyright summary).

Si el modelo tiene riesgo sistémico (umbral 10^25 FLOPs o designado por la Comisión), obligaciones adicionales (Art. 55): model evaluation, adversarial testing, reporting incidentes, cybersecurity.

Stack del blog. Para una organización que usa modelos GPAI (Llama 4, Mistral) y no los entrena desde cero:

• No es provider GPAI; es downstream provider que integra GPAI en su sistema.
• Debe disponer de la documentación técnica del GPAI (Llama paper, Mistral docs) y referenciarla en su propia documentación Anexo IV.
• Análisis de licencia GPAI específica (Llama Community License, Apache 2.0, etc.).
• El post sobre alignment moderno y fine-tuning continuo describen cómo el adapter LoRA sobre el GPAI no convierte al downstream en provider GPAI siempre que no entrene un modelo nuevo desde cero.

Checklist (downstream provider).

• Inventario de GPAI usados con versión, fuente, licencia, documentación referenciada.
• Análisis de cumplimiento copyright EU (Art. 4 Dir. 2019/790).
• Mapping responsabilidades upstream provider GPAI vs nosotros como downstream.

Art. 72 — Post-market monitoring

Qué exige. Sistema documentado de monitoreo post-mercado proporcional al riesgo, que recoja datos sobre el funcionamiento durante todo el ciclo de vida, incluyendo interacción con otros sistemas IA. Permite al provider:

• Evaluar cumplimiento continuo de Arts. 8-15.
• Adoptar medidas correctivas necesarias.
• Detectar tendencias en uso real (drift, abuso).

El plan de monitoreo es parte del Anexo IV y se mantiene durante toda la vida del sistema. La Comisión publica plantilla en 2026.

Stack del blog.

• Tracing OTel + Langfuse — la base.
• Evals continuos — métricas operativas como gates online.
• LLM-as-judge — judges sobre sampling de producción para detectar degradación.
• Retrain incident-driven — el bucle de mejora cerrado.

Checklist.

• Plan de monitoreo post-mercado documentado por sistema.
• Métricas operativas definidas con thresholds y revisión periódica.
• Procedimiento de acción correctiva ante alerta.
• Integración con Art. 73 (cuando alerta = incidente grave).

Art. 73 — Reporting de incidentes graves

Qué exige. Definición de incidente grave (Art. 3(49)):

• Muerte o daño grave a la salud.
• Disrupción grave de infraestructura crítica.
• Infracción de obligaciones legales destinadas a proteger derechos fundamentales.
• Daño grave a la propiedad o al medio ambiente.

El provider reporta a la autoridad de vigilancia del mercado del Estado miembro donde ocurrió el incidente. Plazos:

El primer informe puede ser preliminar; el completo sigue después. Investigación interna obligatoria; cooperación con autoridades. Acción correctiva proporcional.

Stack del blog. El flujo técnico:

• Tracing OTel provee la trazabilidad para investigación forense.
• Guardrails y safety emite el incident_event canónico (categoría, severity, trace_id).
• Retrain incident-driven materializa la acción correctiva.

Checklist.

• Procedimiento de incident reporting documentado con plazos y plantillas.
• Persona designada (típicamente DPO + AI Risk Owner) con responsabilidad y formación.
• Dry-run anual del procedimiento (simulacro).
• Integración técnica entre la capa de guardrails / tracing y el canal de notificación.

El expediente Anexo IV ensamblado: SVG del dossier completo

El gráfico muestra la asimetría editorial del blog: siete de nueve apartados del Anexo IV los cubre el stack técnico directamente. Solo el FRIA (apartado 7) y la declaración de conformidad firmada (apartado 9, no representado en el SVG por ser un documento de una página) son huecos documentales que necesitan trabajo administrativo expreso. El esfuerzo principal de cumplimiento es ensamblar y firmar, no construir desde cero.

Caso aplicado: el chatbot multi-tenant evaluado contra el AI Act

Tomamos el sistema del post forense — chatbot multi-tenant de atención al cliente para aseguradoras — y lo recorremos como provider del sistema.

Clasificación Art. 6: el chatbot ayuda a clientes a entender productos, consultar estado, abrir incidencias. No automatiza decisiones contractuales (no aprueba siniestros, no calcula primas). Cae en Anexo III área 8 (servicios privados esenciales)? — depende del uso. Si la aseguradora lo usa solo para soporte informativo, riesgo limitado (aplica Art. 50). Si lo usa para evaluar declaraciones de siniestros, alto riesgo. Documentación obligatoria del análisis.

Asumimos alto riesgo para el recorrido completo:

• Art. 5 prohibiciones: declaración escrita de no aplicabilidad. ✓
• Art. 9 risk management: documento por sistema con riesgos identificados (alucinación, sesgo por dialecto, fuga PII, jailbreak), mitigaciones aplicadas (RAG con corpus curado, guardrails con 4 líneas, LLM Guard Vault, evals continuos), residuales aceptados firmados. ✓ (insumo: pipeline + guardrails + evals).
• Art. 10 data governance: gobernanza de los cuatro datasets (training adapter, RAG corpus aseguradora, golden eval, enriched retrain) con sesgos analizados, PII anonimizada, lineage. ✓ (insumo: data-versioning + rag-corpus-curation + LLM Guard).
• Art. 11 + Anexo IV: expediente con 9 apartados redactado, firmado, accesible 10 años en bucket WORM. ✓ (7 apartados de blog, 2 nuevos).
• Art. 12 + Art. 19 logs: OTel + Tempo + Langfuse con retención 24 meses, PII redactada por Vault. ✓.
• Art. 13 transparencia deployers: manual de usuario para aseguradora + manual técnico. ✓ (insumo: catálogo OSS + anatomía request).
• Art. 14 supervisión humana: dashboard Langfuse + Grafana + protocolo de escalado humano para casos críticos + formación al personal de la aseguradora. ✓.
• Art. 15 precisión, robustez, ciberseguridad: métricas F1 por categoría declaradas, suite adversarial Promptfoo redteam ejecutada mensualmente, plan ciberseguridad del stack (vLLM patching, secrets rotation). ✓.
• Art. 17 QMS: ISO 42001 implantada y certificada. ✓.
• Art. 26 deployer: contrato con aseguradora incluye obligaciones del deployer. ✓.
• Art. 27 FRIA: la aseguradora ejecuta FRIA antes de primer uso (es entidad privada de servicio esencial). ✓ (responsabilidad del deployer, provider asiste).
• Art. 47 declaración conformidad: firmada por el CTO de la consultora antes de mercado. ✓.
• Art. 48 CE marking: visible en la interfaz del chatbot y en documentación oficial. ✓.
• Art. 49 registro EU DB: completado antes del primer uso productivo. ✓.
• Art. 50 transparencia usuarios: banner UI “Estás hablando con un asistente IA”, disclaimer en respuestas exportables. ✓.
• Art. 53 GPAI: documentación de Llama 4 (modelo base) referenciada + análisis copyright EU + mapping de responsabilidades. ✓.
• Art. 72 post-market monitoring: plan documentado, OTel + evals continuos + retrain ya operativos. ✓.
• Art. 73 reporting incidentes: procedimiento + responsable designado + dry-run anual. ✓.

Resultado: certificable y desplegable en mercado UE el 2 de agosto de 2026. Los huecos clave (FRIA, CE marking, registro EU DB, declaración conformidad) son trabajo documental sobre artefactos técnicos ya existentes, no proyectos técnicos nuevos.

Sanciones (Art. 99)

El cuadro de sanciones es proporcional al volumen mundial o a un tope absoluto, el que sea mayor:

Para PYMEs y startups, los topes son el menor de las dos cifras (no el mayor) — la mitigación de proporcionalidad existe pero requiere demostración formal.

Adicionalmente, las autoridades nacionales pueden ordenar:

• Suspensión inmediata del sistema en el mercado.
• Llamada a revisión (recall) obligatoria.
• Comunicación pública obligatoria de la sanción.

Las cinco trampas frecuentes del cumplimiento

Trampa 1 — Asumir que el modelo GPAI usado ya cubre las obligaciones. El downstream provider sigue siendo responsable del sistema integrado: ni Meta ni Mistral ni DeepSeek asumen las obligaciones de quien construye sobre sus modelos. La trampa se descubre cuando la autoridad pide el expediente y el equipo apunta al model card de Llama como si bastara.

Trampa 2 — Confundir ISO 42001 con conformidad EU AI Act. Tener 42001 certificado no implica conformidad: la certificación no es FRIA, no es CE marking, no es registro en EU database, no es declaración de conformidad firmada. La normalización avanza pero hasta que ISO 42001 se publique como norma armonizada (no lo era al cierre de 2025), no hay presunción de conformidad. El cuadro de obligaciones legales tiene su propio circuito.

Trampa 3 — Olvidar el reporting de incidentes en plazo legal. 15 días suena largo hasta que un incidente coincide con vacaciones de verano. 2 días para infra crítica no es negociable. Sin procedimiento documentado y simulacro anual, el plazo se incumple en silencio. Sanción por información engañosa (1% volumen mundial) si el reporting incompleto se descubre.

Trampa 4 — Subestimar el deployer. El AI Act asigna obligaciones tanto al provider como al deployer. Una empresa que usa un LLM hospedado integrado en su servicio (sin desarrollarlo) sigue siendo deployer con obligaciones propias (Art. 26): supervisión humana, FRIA si aplica, notificación a personas afectadas. La trampa se descubre cuando el deployer asume que “la responsabilidad es del proveedor del modelo” — no lo es del todo.

Trampa 5 — Dejar el FRIA para el final. El FRIA (Art. 27) requiere análisis de impacto sobre derechos fundamentales con dimensiones cualitativas (discriminación, privacidad, derechos sociales). No es un documento de una tarde. Se ejecuta antes del primer uso, no después de detectar un problema. Los deployers públicos y los proveedores de servicios esenciales privados que lo dejan para “cuando lo pidan” tardan 4-8 semanas en producir uno creíble — tiempo que típicamente no se tiene cuando llega la inspección.

Lo que no hemos cubierto (próximos posts)

• Plantillas concretas de cada documento: declaración de conformidad UE (Anexo V), expediente Anexo IV completo apartado por apartado, FRIA, plan de post-market monitoring, informe inicial de incidente grave. Material para un post tipo “Carpeta del cumplimiento EU AI Act en 12 plantillas”.
• Códigos de práctica voluntarios publicados por la Comisión bajo Art. 56 — útiles para sistemas de riesgo limitado que quieran demostrar buen comportamiento sin obligación legal.
• Análisis comparativo de notified bodies para sistemas que requieran conformity assessment de tercero (Anexo I principalmente).
• Cómo cambia el cumplimiento para agentes LLM — sistemas con autonomía gradúa, tool calling, capacidad de acción. La SC 42 y la AI Office trabajan en guidance específica.
• El cuadro completo de autoridades nacionales designadas bajo Art. 70 + autoridades sectoriales que mantienen jurisdicción (AEPD para privacidad, CNMV para servicios financieros, Banco de España para banca, AESA para aviación).

Referencias

• Regulation (EU) 2024/1689 (EU AI Act) — Texto consolidado en EUR-Lex: https://eur-lex.europa.eu/eli/reg/2024/1689. Diario Oficial L 1689/12.7.2024.
• EU AI Act Explorer (AI Act Service Desk, Comisión Europea): https://ai-act-service-desk.ec.europa.eu/en/ai-act-explorer.
• AI Act Text portal (artificialintelligenceact.eu): artículos individuales con anotaciones.
• Anexo IV — Technical documentation: estructura de los nueve apartados obligatorios.
• Anexo V — EU declaration of conformity: plantilla obligatoria.
• Anexo III — High-risk AI systems: las ocho áreas que clasifican un sistema como alto riesgo.
• Anexo XI — Copyright training summary template: para GPAI providers.
• NIST AI RMF 1.0 (2023) — https://www.nist.gov/itl/ai-risk-management-framework.
• ISO/IEC 42001:2023 — sistema de gestión, complemento facilitador.
• ISO/IEC 42005 — Impact assessment AI (publicada 2025 como guía técnica para FRIA).
• Draft Commission guidance on serious incident reporting (2025) — borrador en consulta para Art. 73.

Ver también

• ISO/IEC 42001: el manual de operaciones del sistema de IA — el post hermano sobre el sistema de gestión que facilita demostrar Arts. 9, 10, 11, 17 del Reglamento.
• El pipeline LLMOps de seis etapas — el ciclo de vida que materializa los Arts. 9 (risk management) y 17 (QMS) operativamente.
• Anatomía de una petición LLM en producción — el caso forense usado como checklist del cumplimiento en este post.
• Data versioning con DVC y lakeFS y RAG corpus curation — Art. 10 data governance.
• Tracing LLM con OpenTelemetry GenAI — Arts. 12 + 19 (record-keeping) con OTel canónico.
• Guardrails y safety en LLMs — Arts. 14 (supervisión humana) y 15 (ciberseguridad/robustez).
• LLM Guard: el traductor jurado con cuaderno de equivalencias — Art. 10 + Art. 12 con PII redactada en path runtime.
• Evals: la capa después del tracing — Art. 15 (precisión) y Art. 72 (post-market monitoring).
• Retrain: cerrar el bucle feedback → dataset → adapter — Art. 72 mejora continua + Art. 73 acción correctiva tras incidente.
• El catálogo paralelo: OSS vs hyperscalers — Art. 53 (GPAI obligations) y análisis de proveedores GPAI integrados.
• El catálogo OSS para LLMOps — Art. 13 (transparencia a deployers) con inventario completo de componentes.
• Alignment moderno: DPO, KTO, ORPO y SimPO — diseño responsable del adapter (Art. 9 mitigación + Art. 15 robustez).
• Controles técnicos: el mapeo cruzado ENS × ISO 42001 × EU AI Act — el zoom técnico al solapamiento de los tres marcos. Una sola pieza de tracing, una sola pieza de guardrails, una sola pieza de versionado materializa las exigencias técnicas de ENS + 42001 + AI Act simultáneamente cuando se etiqueta con vocabulario común.
• Runbooks de incident response para LLM con Keep + Kafka — la operacionalización del Art. 73 (reporting of serious incidents) con plazos 2/10/15 días según severity, workflows Keep YAML y topic Kafka audit.actions WORM como evidencia para autoridad competente.