El EU AI Act no es un libro blanco. Es ley.

Las normas sobre prácticas prohibidas están en vigor desde el 2 de febrero de 2025. Las obligaciones para proveedores de IA de propósito general (GPAI) son aplicables desde el 2 de agosto de 2025. Los requisitos para sistemas de alto riesgo -- los que afectan a la mayoría de la IA en producción -- llegan en etapas a lo largo de 2026 y 2027.

Si estás leyendo este artículo, probablemente te encuentras en una de dos posiciones. O estás construyendo sistemas de IA que serán clasificados como de alto riesgo bajo la ley, y necesitas entender qué significa eso para tu ingeniería. O estás construyendo sistemas basados en GPAI y necesitas entender las obligaciones que fluyen desde tus proveedores de modelos hasta ti.

Esto no es un informe jurídico. Es una guía de ingeniería. Somos arquitectos, no abogados. Pero sabemos que el cumplimiento normativo es, en última instancia, un problema de ingeniería -- el equipo legal define lo que debe ser cierto; el equipo de ingeniería lo hace cierto. Y la brecha entre «deberíamos ser conformes» y «podemos demostrar conformidad» es exactamente la brecha que aborda este artículo.

I. La línea temporal: lo que ya está en vigor

El AI Act entró en vigor el 1 de agosto de 2024. Sus disposiciones se aplican de manera escalonada:

1 ago, 2024    La ley entra en vigor
  2 feb, 2025    Se aplican las prácticas de IA prohibidas (Art. 5)
  2 feb, 2025    Se aplican las obligaciones de alfabetización en IA (Art. 4)
  2 ago, 2025    Se aplican las obligaciones para proveedores de GPAI (Capítulo V)
  2 ago, 2025    Se establece la estructura de gobernanza
  2 ago, 2026    Se aplican los requisitos de alto riesgo (Capítulo III)
  2 ago, 2027    Plazo extendido para IA de alto riesgo en
                 productos regulados del Anexo I

Dos cosas ya están activas que muchos equipos no han interiorizado:

Prácticas prohibidas (desde feb 2025). Puntuación social. Reconocimiento facial no selectivo desde CCTV. Inferencia de emociones en entornos laborales y educativos (con excepciones limitadas). Manipulación subliminal. Explotación de vulnerabilidades. Si tu sistema hace cualquiera de estas cosas, ya no eres conforme.

Alfabetización en IA (desde feb 2025). Las organizaciones que despliegan IA deben asegurar que el personal tenga «suficiente alfabetización en IA» para sus funciones. Esto es lo suficientemente vago como para ser molesto y lo suficientemente específico como para ser ejecutable. Documenta tus programas de formación.

Obligaciones de GPAI (desde ago 2025). Si proporcionas un modelo de IA de propósito general -- o construyes sobre uno -- tienes obligaciones de transparencia. Documentación técnica. Informes de consumo energético. Resúmenes de cumplimiento de derechos de autor. Si utilizas un modelo de Anthropic, OpenAI, Google o Meta, tu proveedor tiene obligaciones; tú tienes responsabilidades derivadas.

II. Qué hace que un sistema sea «de alto riesgo»

La ley define la IA de alto riesgo en dos categorías:

Anexo I: IA integrada en productos regulados. Dispositivos médicos, vehículos, aviación, juguetes, ascensores, equipos a presión, maquinaria. Si tu IA es un componente de seguridad de un producto ya regulado bajo la legislación de armonización de la UE, es de alto riesgo. El plazo extendido de 2027 se aplica aquí.

Anexo III: Sistemas de IA de alto riesgo independientes. Esta es la categoría más amplia:

  • Identificación y categorización biométrica de personas físicas.
  • Gestión y operación de infraestructura crítica.
  • Educación y formación profesional -- acceso, evaluación, monitorización.
  • Empleo -- contratación, asignación de tareas, monitorización del rendimiento, despido.
  • Servicios esenciales -- puntuación crediticia, seguros, prestaciones sociales.
  • Aplicación de la ley -- evaluación de riesgos, valoración de pruebas, elaboración de perfiles.
  • Migración y control fronterizo -- evaluación de riesgos, verificación de documentos.
  • Justicia y procesos democráticos -- interpretación jurídica, influencia electoral.

Si tu sistema de IA toma decisiones o asiste en la toma de decisiones en estos ámbitos, probablemente es de alto riesgo. La clasificación se basa en el propósito e impacto del sistema, no en la tecnología subyacente.

La prueba práctica

Hazte tres preguntas:

  1. ¿Mi sistema de IA toma o asiste significativamente en decisiones sobre personas?
  2. ¿Están esas decisiones en un ámbito del Anexo III?
  3. ¿Podrían esas decisiones afectar significativamente el acceso de alguien a servicios, empleo, educación o derechos?

Si la respuesta a las tres es sí, asume alto riesgo hasta que un análisis legal diga lo contrario. Es más barato sobre-cumplir y ajustar que sub-cumplir y descubrir.

III. Lo que los sistemas de alto riesgo deben tener

El Capítulo III, Sección 2 de la ley especifica los requisitos. Traducidos a entregables de ingeniería:

Sistema de gestión de riesgos (Art. 9)

Un proceso continuo e iterativo para identificar, analizar, estimar y mitigar riesgos. No una evaluación de riesgos puntual. Un sistema vivo que:

  • Identifica riesgos conocidos y razonablemente previsibles.
  • Estima riesgos basándose en el uso previsto y el uso indebido previsible.
  • Adopta medidas de mitigación de riesgos.
  • Prueba el sistema para asegurar que la mitigación funciona.
  • Documenta todo.

Traducción a ingeniería: Construye un registro de riesgos. Vincula los riesgos a componentes del sistema. Vincula las mitigaciones al código (tests, guardrails, restricciones). Revisa trimestralmente. Tu pipeline de CI debe incluir suites de tests relacionados con riesgos.

Gobernanza de datos (Art. 10)

Los datasets de entrenamiento, validación y pruebas deben ser relevantes, suficientemente representativos, libres de errores en la medida de lo posible y apropiados para el propósito previsto. Debes documentar:

  • Procesos de recopilación de datos.
  • Operaciones de preparación de datos (limpieza, etiquetado, enriquecimiento).
  • Suposiciones sobre lo que los datos representan.
  • Evaluación de disponibilidad, cantidad e idoneidad.
  • Medidas para detectar y abordar sesgos.

Traducción a ingeniería: Seguimiento de linaje de datos. Documentación de esquemas. Pipelines de detección de sesgos. Control de versiones para datasets. Si afinas modelos, documenta la procedencia de los datos de entrenamiento con el mismo rigor con el que documentas la procedencia del código.

Documentación técnica (Art. 11)

Antes de comercializar el sistema, prepara la documentación técnica que demuestre cumplimiento. La documentación debe incluir:

  • Descripción general del sistema (propósito, uso previsto, limitaciones).
  • Arquitectura del sistema y recursos computacionales.
  • Metodología y técnicas de entrenamiento.
  • Medidas de gobernanza de datos.
  • Métricas de rendimiento y resultados de evaluación.
  • Documentación de gestión de riesgos.
  • Descripción de las medidas de supervisión humana.
  • Vida útil esperada y plan de mantenimiento.

Traducción a ingeniería: Architecture Decision Records (ADRs). Model cards. Resultados de eval con metodología. Diagramas de infraestructura. Este es el artefacto que los auditores leerán. Si no existe, no eres conforme, independientemente de lo bueno que sea tu sistema.

Registro de actividad (Art. 12)

Los sistemas de IA de alto riesgo deben soportar el registro automático de eventos relevantes para identificar riesgos, monitorizar la operación y facilitar la vigilancia post-comercialización. Los registros deben:

  • Ser trazables a decisiones o salidas específicas.
  • Cubrir la vida operativa del sistema.
  • Ser accesibles para el operador y para las autoridades de vigilancia del mercado.

Traducción a ingeniería: Registros de auditoría estructurados y consultables. No logs de aplicación. Registros de decisiones -- qué input se recibió, qué produjo el modelo, qué acción se tomó, qué resultado se obtuvo. Piensa en ello como un libro mayor de decisiones de IA.

Esquema de registro de decisiones (conceptual):


{
    "decision_id": "uuid",
    "timestamp": "iso8601",
    "system_version": "v2.3.1",
    "input_hash": "sha256",
    "model_id": "claude-opus-4-20250514",
    "model_output_hash": "sha256",
    "action_taken": "approved | rejected | escalated",
    "human_override": true | false,
    "outcome_recorded_at": "iso8601 | null",
    "outcome": "correct | incorrect | disputed | null"
  }

Supervisión humana (Art. 14)

Los sistemas de alto riesgo deben diseñarse para permitir una supervisión humana eficaz. Esto incluye:

  • La capacidad de que los humanos comprendan las capacidades y limitaciones del sistema.
  • La capacidad de interpretar correctamente las salidas.
  • La capacidad de anular o desestimar la salida del sistema.
  • La capacidad de interrumpir o detener el sistema (el «botón de emergencia»).

Traducción a ingeniería: Dashboard que muestre el razonamiento del sistema. Mecanismos de anulación en la interfaz. Botón de emergencia accesible para operadores autorizados. Materiales de formación para operadores. No aspiracional. Desplegado y probado.

Precisión, robustez, ciberseguridad (Art. 15)

Los sistemas deben alcanzar niveles apropiados de precisión, robustez y ciberseguridad. Deben ser resilientes ante errores, fallos e inconsistencias. Deben resistir intentos de explotar vulnerabilidades.

Traducción a ingeniería: Suites de eval con líneas base de precisión. Pruebas adversarias (inyección de prompts, envenenamiento de datos, evasión). Auditorías de seguridad. Planes de respuesta a incidentes. Monitorización continua con alertas.

IV. La brecha de las normas armonizadas

La ley se apoya en normas armonizadas -- especificaciones técnicas desarrolladas por CEN/CENELEC que proporcionan una «presunción de conformidad». Si cumples con una norma armonizada, se presume que cumples con el requisito correspondiente de la ley.

El problema: estas normas aún no existen. CEN/CENELEC las solicitó en mayo de 2024. El plazo estimado para su desarrollo y publicación en el Diario Oficial es de 2-3 años. Algunos procedimientos acelerados podrían adelantar esto, pero incluso las estimaciones optimistas sitúan la disponibilidad generalizada a finales de 2026 o en 2027.

Esto crea un vacío de cumplimiento. Las obligaciones se aplican en agosto de 2026. Las normas que te dicen exactamente cómo demostrar cumplimiento pueden no estar finalizadas hasta después.

La respuesta práctica: Construye tu propia evidencia documental ahora. Usa los marcos existentes como andamiaje:

  • NIST AI Risk Management Framework (AI RMF 1.0) -- el marco de riesgo de IA de propósito general más maduro disponible.
  • ISO/IEC 42001:2023 -- estándar de sistema de gestión de IA. Certificable.
  • ISO/IEC 23894:2023 -- guía de gestión de riesgos de IA.
  • ALTAI (Assessment List for Trustworthy AI) -- la lista de autoevaluación de la Comisión Europea.

Ninguno de estos es una norma armonizada del EU AI Act. Pero demuestran esfuerzo de buena fe y pensamiento de cumplimiento estructurado. Cuando lleguen las normas armonizadas, mapea tu documentación existente a ellas. Estarás por delante de cada equipo que esperó.

V. Patrones de arquitectura para el cumplimiento

El cumplimiento es caro cuando se atornilla al final. Es barato cuando se integra desde el inicio. Estos son los patrones que hacen del cumplimiento un subproducto natural de una buena arquitectura.

Patrón 1: Auditoría de decisiones

Cada decisión asistida por IA fluye a través de un servicio de auditoría que registra el contexto completo: input, versión del modelo, salida del modelo, estado de revisión humana, acción final y resultado.

Request --> [AI Service] --> [Audit Service] --> [Action]
                                    |
                                    v
                             [Decision Store]
                                    |
                                    v
                             [Compliance Dashboard]

El servicio de auditoría es el generador de documentación técnica. Produce los registros requeridos por el Art. 12, los datos de monitorización requeridos por el Art. 9 y la visibilidad de supervisión requerida por el Art. 14.

Patrón 2: Versionado de modelos y reproducibilidad

Cada modelo desplegado tiene un identificador de versión, un model card y resultados de eval archivados. Cuando se reemplaza una versión del modelo, la versión anterior y su documentación se retienen durante toda la vida operativa del sistema.

Model Registry
  +------------------------------------------+
  | model_id: credit-scoring-v2.3            |
  | base_model: claude-opus-4-20250514       |
  | fine_tune_data: dataset-v7 (sha256)      |
  | eval_results: eval-2026-03-15.json       |
  | risk_assessment: risk-v2.3.md            |
  | deployed_at: 2026-03-20T14:00:00Z        |
  | retired_at: null                         |
  +------------------------------------------+

Esto no es infraestructura aspiracional. Esto es el Art. 11 (documentación técnica) y el Art. 17 (gestión de calidad) en código.

Patrón 3: Pipeline de detección de sesgos

Para sistemas que afectan a personas (empleo, crédito, educación), ejecuta detección de sesgos como parte del pipeline de eval. Comprueba la paridad demográfica, las odds equalizadas o la calibración entre grupos protegidos -- las métricas que sean apropiadas para tu dominio.

# Eval de sesgos (simplificado)
for group in protected_groups:
    group_results = [r for r in eval_results if r.group == group]
    group_rate = positive_rate(group_results)
    baseline_rate = positive_rate(eval_results)
    disparity = abs(group_rate - baseline_rate) / baseline_rate


if disparity > threshold:
        alert(f"Disparity for {group}: {disparity:.2%}")
        block_deployment()

Esto es el Art. 10 (gobernanza de datos) y el Art. 9 (gestión de riesgos) operacionalizados. El código es el artefacto de cumplimiento.

Patrón 4: Dashboard de supervisión humana

Construye un dashboard que muestre a los operadores:

  • Estado actual del sistema y niveles de confianza.
  • Decisiones recientes con resúmenes de razonamiento.
  • Historial de anulaciones (quién anuló, cuándo, por qué).
  • Cola de escalamiento para casos inciertos.
  • Botón de emergencia con confirmación.

Esto es el Art. 14 en una pestaña del navegador. Si tu mecanismo de supervisión es «alguien puede conectarse por SSH al servidor y matar el proceso», no eres conforme.

VI. GPAI: las obligaciones de tu proveedor de modelos y tus responsabilidades

Si utilizas modelos de Anthropic, OpenAI, Google u otros proveedores de GPAI, esos proveedores tienen obligaciones bajo el Capítulo V de la ley (aplicables desde el 2 de agosto de 2025):

  • Mantener y poner a disposición la documentación técnica.
  • Proporcionar información y documentación a proveedores posteriores.
  • Cumplir con la legislación de derechos de autor de la UE.
  • Publicar un resumen suficientemente detallado del contenido de los datos de entrenamiento.

Tu responsabilidad como operador: Asegúrate de que el modelo que integras tiene documentación adecuada de su proveedor. Si construyes un sistema de alto riesgo sobre un modelo GPAI, heredas la obligación de demostrar que el sistema en su conjunto cumple los requisitos de alto riesgo -- incluso si el modelo en sí es responsabilidad del proveedor.

En la práctica: solicita model cards, resultados de eval y documentación de cumplimiento a tu proveedor de modelos. Si no puede proporcionarlos, eso es un riesgo en la cadena de suministro. Documenta la carencia y mitiga (con tus propios evals, guardrails y supervisión).

VII. La realidad de la aplicación

El AI Act contempla sanciones significativas:

  • Prácticas prohibidas: Hasta 35M EUR o el 7% de la facturación anual global.
  • Incumplimiento de alto riesgo: Hasta 15M EUR o el 3% de la facturación anual global.
  • Información incorrecta a las autoridades: Hasta 7,5M EUR o el 1,5% de la facturación anual global.

Se designarán autoridades nacionales competentes (una por estado miembro) para la vigilancia del mercado. La EU AI Office supervisa los modelos GPAI directamente.

La aplicación se centrará inicialmente en las prácticas prohibidas y los casos de alto perfil. Pero los requisitos de documentación y registro crean una trazabilidad documental que hace que la aplicación futura sea directa. Si no tienes la documentación cuando te la soliciten, la evaluación de la sanción es simple.

VIII. El sprint de cumplimiento de 90 días

Si estás leyendo esto en la primavera de 2026 y tu sistema de alto riesgo aún no es conforme, esta es la ruta mínima viable:

Días 1-30: Clasificar y documentar

  • Clasifica tus sistemas de IA contra el Anexo III. Obtén la aprobación legal de la clasificación.
  • Crea model cards para cada componente de IA. Documenta los modelos base, los datos de afinación, el uso previsto y las limitaciones conocidas.
  • Produce documentación de arquitectura: diagramas de sistema, diagramas de flujo de datos, descripciones de componentes.
  • Inicia el registro de riesgos. Identifica los 10 riesgos principales para cada sistema de alto riesgo.

Días 31-60: Construir la infraestructura

  • Despliega la auditoría de decisiones. Cada decisión asistida por IA se registra con el contexto completo.
  • Despliega el dashboard de supervisión humana. Los operadores pueden ver decisiones, anular y detener.
  • Implementa la detección de sesgos en el pipeline de eval. Ejecútala contra datos de producción.
  • Configura el versionado de modelos. Cada cambio de modelo se rastrea, documenta y es reversible.

Días 61-90: Probar y demostrar

  • Ejecuta una auditoría simulada. Imagina que una autoridad de vigilancia del mercado ha solicitado tu documentación técnica. ¿Puedes producirla en 48 horas?
  • Realiza pruebas adversarias. Inyección de prompts, envenenamiento de datos, evasión. Documenta los resultados y las mitigaciones.
  • Revisa tu cadena de suministro de GPAI. Solicita documentación a los proveedores de modelos. Documenta las carencias.
  • Informa a tu equipo directivo. Presenta el estado de cumplimiento, las brechas restantes y el calendario para cerrarlas.

IX. Cumplimiento como arquitectura

El EU AI Act es la primera regulación integral de IA que se convierte en ley. No será la última. La AIDA de Canadá, el marco de IA de Brasil y diversas propuestas a nivel estatal en EE.UU. están en curso. Los requisitos específicos diferirán. Los requisitos estructurales -- documentación, registro, supervisión humana, pruebas de sesgo, gestión de riesgos -- no.

Los equipos que construyen estas estructuras ahora no solo están cumpliendo con una regulación. Están construyendo la infraestructura para operar IA de manera responsable en un mundo donde la regulación es la norma, no la excepción.

Una buena arquitectura hace del cumplimiento un subproducto. Auditorías de decisiones, registros de modelos, pipelines de eval, detección de sesgos, dashboards de supervisión humana -- estos no son costes de cumplimiento. Son herramientas de ingeniería que hacen tu sistema mejor, más seguro y más mantenible.

El EU AI Act no te pide que dejes de construir IA. Te pide que demuestres que tu IA funciona como se pretende, falla de manera controlada y trata a las personas con equidad. Si eres un equipo de ingeniería competente, deberías querer eso de todos modos. La ley simplemente lo hace no-opcional.

Construye la infraestructura. Escribe la documentación. Ejecuta los evals. La fecha límite es el 2 de agosto de 2026. La arquitectura debería haber existido ayer.

Referencias

  1. European Parliament & Council. Regulation (EU) 2024/1689 (AI Act). eur-lex.europa.eu
  2. EU AI Act Explorer. Full Text and Analysis. artificialintelligenceact.eu
  3. European Commission. AI Act Timeline and Implementation. digital-strategy.ec.europa.eu
  4. NIST. AI Risk Management Framework (AI RMF 1.0). nist.gov
  5. ISO/IEC 42001:2023. Artificial Intelligence -- Management System. iso.org
  6. ISO/IEC 23894:2023. AI Risk Management Guidance. iso.org
  7. European Commission. ALTAI: Assessment List for Trustworthy AI. digital-strategy.ec.europa.eu
  8. CEN-CENELEC. Standardisation Request for AI Act. cencenelec.eu
  9. Anthropic. Claude Model Card. docs.anthropic.com
  10. EU AI Office. General-Purpose AI Code of Practice. digital-strategy.ec.europa.eu
  11. Veale, M. & Zuiderveen Borgesius, F. (2021). Demystifying the Draft EU Artificial Intelligence Act. Computer Law Review International.
  12. Smuha, N.A. (2021). From a 'Race to AI' to a 'Race to AI Regulation'. Law, Innovation and Technology.