Hay una diferencia fundamental entre un agente IA que funciona en demo y un agente que pasa una auditoría regulatoria. La demo la ganas con un modelo bueno y un prompt cuidado. La auditoría la pierdes, o la ganas, en la arquitectura que eligió tu equipo seis meses antes.
El 2 de agosto de 2026 entran en aplicación las obligaciones centrales de la EU AI Act para sistemas de alto riesgo. A esa fecha — a poco más de tres meses de hoy — los agentes desplegados en banca, seguros, salud, pharma, selección de personal, scoring crediticio o educación tienen que cumplir requisitos formales: gestión de riesgos, documentación técnica, logging automático, supervisión humana, robustez, ciberseguridad y vigilancia post-mercado. Las multas por incumplimiento llegan hasta 15 millones de euros o el 3% de la facturación global anual, la cifra que sea mayor.
La mayoría de equipos con los que hablamos tiene agentes funcionales desplegados en entornos regulados. Casi ninguno los ha diseñado pensando en cómo se reconstruye una decisión concreta delante de un auditor. Ese gap no se cierra con una capa de logging añadida encima. Se cierra diseñando el agente como un sistema auditable desde la primera spec.
EU AI Act 2026: la ventana de cumplimiento
Fuentes: Reglamento (UE) 2024/1689 · Comisión Europea · AI Act Service Desk
Qué significa compliance-first (y qué no)
Compliance-first AI design es exactamente lo contrario de retrofit compliance. En retrofit compliance, el equipo construye el agente, lo despliega, alguien del lado legal descubre tres meses después que falta documentación técnica y trazabilidad, y se abre un sprint para "añadir los logs que pide el auditor". En ese momento, ya es tarde: los datos de entrenamiento no están versionados, las decisiones pasadas no se pueden reconstruir y la arquitectura no permite bloquear acciones sensibles sin reescribir la orquestación.
Compliance-first significa que cada requisito regulatorio se traduce en una decisión de arquitectura antes de escribir la primera línea de código. Qué se loguea, con qué granularidad y dónde. Qué acciones requieren validación humana y cómo se aplican los circuit breakers. Qué documentación técnica se genera automáticamente cada vez que una versión del agente se promueve a producción. Qué criterios de aceptación tiene que cumplir un output para considerarse válido — y cómo se evidencia que los cumple.
Es la misma disciplina que aplicamos en DevSecOps: la seguridad no se añade al final, se diseña desde el inicio. Con la EU AI Act, el principio se extiende al gobierno del agente. Governance-first no es overhead adicional; es el único patrón que escala cuando el regulador pregunta.
Los 9 requisitos de la EU AI Act que se traducen a arquitectura
El Capítulo III de la EU AI Act define los requisitos para sistemas de alto riesgo. Leídos con lente de arquitectura de software, se traducen en nueve decisiones técnicas concretas que un CTO tiene que tomar antes de desplegar el agente. No son nueve documentos legales: son nueve componentes de sistema.
Proceso documentado, iterativo y actualizado para identificar, evaluar y mitigar riesgos a lo largo del ciclo de vida del agente. En arquitectura: un registro de riesgos versionado en el repo, revisado en cada release, con medidas de mitigación trazables a componentes del sistema.
Datasets de entrenamiento, validación y prueba relevantes, representativos, libres de errores y completos. Para agentes con retrieval, incluye los corpora indexados. En arquitectura: data lineage trazable, hashes de datasets por versión, procedimientos de bias assessment.
Descripción del sistema, su desarrollo, tests, métricas de rendimiento y medidas de mitigación. Tiene que estar lista antes de poner el sistema en el mercado. En arquitectura: docs generadas desde el código (specs, model cards, ADRs) con un pipeline que las actualiza en cada release.
Registro automático de eventos durante el funcionamiento, con un nivel de detalle suficiente para identificar situaciones de riesgo y permitir vigilancia post-mercado. En arquitectura: event log estructurado, inmutable, con correlación por sesión y decisiones trazables al prompt, tool calls, datos recuperados y output final.
Instrucciones de uso claras: capacidades, limitaciones, riesgos, rendimiento esperado por contexto de uso. En arquitectura: model card versionada, expuesta por API, consultable por el operador humano en tiempo de inferencia.
Mecanismos efectivos para que una persona pueda entender el output, decidir no usarlo, intervenir o detener el sistema. En arquitectura: human-in-the-loop graduado por riesgo, botón de kill switch, UI de explicación de decisiones, registro de overrides humanos.
Métricas de accuracy declaradas, resistencia a inputs adversariales y ataques de prompt injection, medidas de fail-safe. En arquitectura: suite de evaluación automática, red-teaming continuo, detección de anomalías y degradación del modelo.
Políticas, procedimientos e instrucciones escritas para el diseño, verificación, validación y gestión de cambios. En arquitectura: el CI/CD y la gobernanza del repo son parte del QMS. Cada cambio en el agente deja traza en un sistema de control de versiones auditado.
Recolección activa de datos de funcionamiento tras el despliegue y notificación de incidentes graves a la autoridad en plazos definidos. En arquitectura: telemetría continua, dashboard de quality monitoring, runbook de incident response con canal hacia la autoridad competente.
Un equipo que construye el agente pensando primero en estos nueve componentes no va a pasar la auditoría por suerte. La va a pasar porque el agente está diseñado para ser auditable. El que no — por mucho modelo premium que use — va a llegar al 2 de agosto con el mismo problema que describimos en el gap de calidad de los agentes IA en producción: observabilidad sin gobernanza.
Arquitectura de referencia: las 5 capas de un agente audit-ready
La forma limpia de organizar estas responsabilidades es una arquitectura de cinco capas donde cada capa tiene una pregunta del auditor asociada. Cuando la capa existe y está bien diseñada, la pregunta se contesta con evidencia; cuando falta, la pregunta se contesta con nerviosismo.
Specification layer — specs y criterios de aceptación
Para cada caso de uso, una spec con input esperado, output esperado, criterios de calidad, modos de fallo y acciones ante excepción. Pregunta del auditor: "¿Cómo sabéis que el agente cumple con su propósito declarado?"
Execution layer — orquestación y guardrails
El motor que ejecuta el agente (Managed Agents, LangGraph, harness propio) con políticas de scope aplicadas antes de cada tool call, validación de output y circuit breakers automáticos. Pregunta del auditor: "¿Qué impide que el agente haga algo que no debe?"
Evidence layer — logging estructurado e inmutable
Cada interacción genera un evento trazable: prompt, contexto recuperado, tool calls, outputs intermedios, decisión final, intervención humana. Logs append-only, firmados y retenidos por el plazo regulatorio. Pregunta del auditor: "Reconstruye la decisión X del 14 de julio."
Oversight layer — supervisión humana y post-market
UI que permite a un operador entender, aprobar, rechazar o detener el agente. Dashboard de quality monitoring, proceso de revisión de incidentes y canal al regulador. Pregunta del auditor: "¿Cómo sabe el operador humano cuándo y cómo intervenir?"
Esta arquitectura no es una arquitectura nueva que hay que inventar para la EU AI Act. Es la arquitectura que los equipos que ya han pasado auditorías en sectores regulados (banca, seguros, salud) usan desde hace tiempo, adaptada a la naturaleza no determinista del agente. Lo que cambia es que a partir de agosto deja de ser buena práctica y pasa a ser obligación por ley.
Por qué Spec-Driven Development es la base natural del compliance-first
Como desarrollamos en Spec-Driven Development: IA en código controlado, SDD eleva la especificación a fuente de verdad por encima del código. Cuando el agente se construye contra una spec estructurada — constitución, templates de spec, playbook de prompts, flujo de review — los nueve requisitos de la EU AI Act dejan de ser artefactos separados y pasan a ser subproductos del proceso de desarrollo.
Mapeo SDD → Requisitos EU AI Act
Lo importante de este mapeo no es que SDD sea la única forma de cumplir la EU AI Act. Es que si ya estás aplicando SDD en serio, tienes la mayor parte del trabajo hecho: los artefactos de la metodología son la documentación técnica que exige el Anexo IV. Los equipos que no tienen esa disciplina van a descubrir que su "documentación" es un Notion desordenado y un backlog de prompts sin versionar — material insuficiente para un conformity assessment.
Este patrón es idéntico al que explicamos en SDD + Agentic Orchestration: la spec es la policy layer, el motor de ejecución es sustituible. Con compliance-first, esta separación gana además una propiedad regulatoria — la spec es el artefacto que el auditor revisa.
Tres casos donde compliance-first cambia el resultado
Para bajar la conversación al terreno, tres escenarios concretos en los que un agente diseñado compliance-first sobrevive a la auditoría y uno retrofit no.
1. Scoring crediticio automatizado
Un agente que rechaza o aprueba una solicitud de crédito cae de lleno en Anexo III, área 5(b). El auditor puede pedir la reconstrucción completa de cualquier decisión: qué features se usaron, qué pesos tuvieron, qué alternativas evaluó el modelo, qué supervisión humana hubo antes de comunicar el resultado al cliente. Sin Evidence layer desde el día uno, esa reconstrucción no es posible: los logs de app standard no capturan tool calls, tokens consumidos ni versiones del prompt. Con compliance-first, cada decisión tiene un event ID y una cadena completa reproducible.
2. Clasificación de reclamaciones en seguros
Un agente que categoriza y prioriza siniestros — salud, auto, hogar — toca datos personales y tiene consecuencias directas para el asegurado. El riesgo principal no es que la categorización sea errónea aislada; es que sistemáticamente perjudique a ciertos perfiles. El Art. 10 exige gobierno de datos y evaluación de sesgo. Un agente retrofit descubre el sesgo cuando llega la denuncia. Un agente compliance-first lo detecta en la Evidence layer antes de que escale, porque la suite de evaluación continua está monitorizando la distribución de outputs por segmento protegido.
3. Apoyo clínico en pharma/healthtech
Un agente que ayuda a un médico a interpretar imágenes, proponer dosificaciones o resumir historia clínica es alto riesgo por definición. La supervisión humana tiene que ser efectiva, no meramente declarada. Si el médico aprueba con un click sin contexto, la supervisión falla como control. En compliance-first, la Oversight layer obliga a mostrar la evidencia — qué pasajes del historial, qué guías clínicas, qué nivel de confianza — antes de permitir aprobación. Hace la supervisión real y la deja registrada.
Stack mínimo para llegar al 2 de agosto: 8 semanas de trabajo honesto
Si hoy tienes un agente en producción en sector regulado y no lo has diseñado compliance-first, el camino realista no es reescribirlo entero. Es instrumentar por capas en un orden que maximice el valor regulatorio de cada sprint.
Clasificar el sistema (alto riesgo / limitado / mínimo) según Anexo III. Abrir el risk register y documentar los riesgos identificados. Este paso es lo que justifica (o no) todo el resto del esfuerzo.
Escribir la constitución del agente y las specs por caso de uso. Declarar capacidades, limitaciones y modos de fallo. Esta es la base del Art. 13 (transparencia) y del Anexo IV (documentación técnica).
Añadir logging estructurado e inmutable a nivel de evento: prompt, contexto, tool calls, output, overrides. Retención por el plazo regulatorio. Si este paso no existe hoy, es el de mayor impacto legal.
UI de supervisión humana efectiva, kill switch, procedimiento de escalado, canal a la autoridad competente. Cubre Art. 14 y Art. 73.
Revisión interna con checklist de Anexo IV, corrección de gaps, preparación del dossier técnico. Idealmente validado por un auditor externo antes del 2 de agosto.
Ocho semanas bien organizadas son un plan realista si el equipo tiene el criterio técnico para priorizar. Deja de serlo si la conversación de compliance empieza en junio. Por eso los 90 días previos a la fecha de aplicación son la ventana que importa.
El insight estratégico: compliance-first no es un coste extra sobre el agente. Es la única arquitectura que permite desplegar agentes IA en Europa con la misma velocidad con la que los desplegaste antes de la EU AI Act. Sin ella, cada release nueva es un riesgo legal no cuantificado.
Dos escenarios para el 2 de agosto
A 105 días de la fecha de aplicación, cada equipo con agentes en sectores regulados tiene dos escenarios realistas por delante. No son escenarios teóricos: son la diferencia entre poder seguir entregando valor al negocio o tener que parar a arreglar el sistema.
Escenario A · llegar compliance-first. Los agentes pasan auditoría sin parones, el dossier del Anexo IV se genera automáticamente desde las specs y cada feature nueva se desarrolla ya dentro del marco regulatorio. La conversación con legal y con el regulador se sostiene con evidencias en lugar de con PowerPoints. Operativamente, nada cambia: el roadmap sigue.
Escenario B · retrofit compliance en verano. Entre junio y agosto, el equipo descubre que faltan logs estructurados, datos de entrenamiento sin trazabilidad, procesos de supervisión humana solo de boquilla y documentación técnica incompleta. Se abren sprints para taparlo. El roadmap se bloquea. En el peor caso, el agente se apaga hasta que el dossier esté listo — y el área de negocio, que ya había integrado el agente en su flujo, pierde capacidad operativa. A esto se suma la exposición a multas de hasta el 3% de la facturación global si un incidente o una inspección llega antes de cerrar el gap.
El coste de llegar al escenario A son ocho semanas de trabajo técnico bien dirigido. El coste de llegar al escenario B es más alto en tiempo, en roadmap perdido y en exposición legal. Por eso la ventana importa: en los 90 días previos a la fecha de aplicación, cada semana que se retrasa la conversación técnica de compliance es una semana que luego cuesta el doble recuperar.
La EU AI Act no prohíbe desplegar agentes IA. Exige poder explicar, demostrar y reconstruir lo que hace cada uno. Ese es un problema de arquitectura, no de cumplimiento formal. Y es exactamente el problema que Spec-Driven Development lleva resolviendo desde antes de que fuera obligatorio.
Fuentes principales: Reglamento (UE) 2024/1689 del Parlamento Europeo y del Consejo ("EU AI Act"), artículos 5, 6, 9-17, 72-73 y Anexos III-IV; "Implementation Timeline" (AI Act Service Desk, Comisión Europea); "Guidelines for providers of general-purpose AI models" (European Commission Digital Strategy); "EU AI Act Compliance: a technical audit guide for the 2026 deadline" (Raconteur); "The EU AI Act: 6 Steps to Take Before 2 August 2026" (Orrick, 2025); "High-Risk AI Systems Under the EU AI Act" (DLA Piper, ISACA White Paper 2024).
Lectura complementaria: SDD + Agentic Orchestration | Spec-Driven Development: IA en código controlado | Agentes IA en producción: el gap de calidad | DevSecOps: seguridad integrada desde el inicio
Metodología onext: onext AI Engine integra compliance-first AI design en la metodología SDD con la que los Centros de Excelencia de IA de onext construyen agentes para sectores regulados: fintech, seguros, pharma y healthtech. Specs, evidence layer y oversight layer como parte del flujo de entrega — no como un proyecto aparte de compliance. Sin paralizar entregas.