Los sistemas de IA agéntica están llegando a producción más rápido que los marcos de gobernanza pensados para contenerlos. En las finanzas, la sanidad y la defensa europeas, esa brecha no es teórica. Un pipeline autónomo que llama a APIs externas, reescribe sus propios prompts y encadena invocaciones de herramientas a lo largo de una sesión genera una superficie de cumplimiento que ninguna regulación anticipó por completo, y que la mayoría de los playbooks de gobernanza de IA centrados en EE. UU. sencillamente no abordan.

La Ley de IA de la UE (Reglamento (UE) 2024/1689) es el primer marco jurídico integral sobre IA en el mundo y será plenamente aplicable a partir del 2 de agosto de 2026. El ómnibus de IA, que alcanzó acuerdo político el 7 de mayo de 2026, ajustó el calendario: los requisitos para los sistemas de IA de alto riesgo independientes se aplican a partir del 2 de diciembre de 2027, y los integrados en productos regulados a partir del 2 de agosto de 2028. Las sanciones pueden alcanzar los 35 millones de euros o el 7 % de la facturación anual global. La ventana para diseñar bien la arquitectura es más corta de lo que parece.

El reglamento define cuatro niveles de riesgo: prohíbe los sistemas que representen amenazas claras para la seguridad o los derechos fundamentales, e impone las obligaciones más exigentes sobre los sistemas de IA de alto riesgo. Lo que hace especialmente difícil la gobernanza de la IA agéntica es que la Ley no contiene ninguna definición de «sistemas agénticos» ni ningún artículo que aborde el uso autónomo de herramientas o el comportamiento en tiempo de ejecución. Quince meses después de que la Ley entrara en vigor, la Oficina de IA no había publicado ninguna orientación específica sobre agentes de IA. Las empresas que construyen estos pipelines ahora están navegando por un modelo de cumplimiento diseñado para configuraciones fijas, aplicado a sistemas que no son ni fijos ni predeterminados.

Eso no significa que los sistemas agénticos queden fuera de la Ley. Están cubiertos como sistemas de IA y, si se califican como de alto riesgo, se aplica el conjunto completo de obligaciones del proveedor de los artículos 9 a 17. Los proveedores de modelos de IA de uso general que subyacen a esos agentes enfrentan obligaciones adicionales si el nivel de autonomía o el uso de herramientas del modelo activa la designación de riesgo sistémico. La lectura honesta: la mayoría de los pipelines agénticos en producción en sectores regulados rozarán el territorio de alto riesgo, y los equipos deberían asumir eso hasta que las orientaciones de clasificación indiquen lo contrario.

Qué exige realmente la Ley desde la perspectiva del pipeline

Dos artículos son los más relevantes para el diseño de pipelines. El artículo 12 exige que los sistemas de IA de alto riesgo registren automáticamente eventos a lo largo de su ciclo de vida: cuándo se usó el sistema, qué fuentes de datos consultó, qué datos coincidieron y quién verificó los resultados. No es telemetría opcional. Es un requisito legal que condiciona las decisiones sobre dónde se almacenan los logs, cuánto tiempo se conservan y quién puede acceder a ellos.

El artículo 14 sobre supervisión humana se malinterpreta con frecuencia. No exige que una persona apruebe cada decisión de la IA antes de que surta efecto. Lo que exige es que el sistema esté diseñado de modo que las personas físicas puedan supervisar su funcionamiento, detectar anomalías, interpretar correctamente los resultados y decidir no usar el sistema o ignorar su salida en cualquier situación concreta. La distinción importa enormemente para la arquitectura del pipeline: se está diseñando para la capacidad de intervenir, no necesariamente para una revisión previa en cada paso.

El artículo 14 no exige una persona en el bucle en cada inferencia. Exige que una persona siempre pueda volver al bucle y que el sistema esté construido para hacerlo posible. Son restricciones de ingeniería muy distintas.

Hay una norma armonizada en desarrollo, EN 18229-1 «AI Trustworthiness Framework: Logging, transparency and human oversight», prevista para armonización bajo la Ley. Cuando se publique, ofrecerá referencias técnicas concretas sobre cómo debe ser un registro adecuado y qué herramientas de supervisión son suficientes. Diseñar ahora teniendo en cuenta su alcance anticipado evita costosas adaptaciones posteriores.

Cuatro principios de diseño para pipelines agénticos auditables

1. Trata cada acción del agente como un evento de log de primer nivel

Cada llamada a una herramienta, reescritura de prompt, invocación de API externa y bifurcación de decisión debe emitir un evento de log estructurado con marca de tiempo, la identidad del agente que llama, el estado de entrada y la salida. Los IDs de correlación deben atravesar toda la sesión para que un responsable de cumplimiento o un auditor pueda reconstruir cualquier cadena de acciones de principio a fin. Almacenar estos logs en la misma jurisdicción que los datos a los que hacen referencia no es opcional bajo el principio de responsabilidad proactiva del RGPD; es el punto de partida.

2. Separa el plano de control del plano de inferencia

La supervisión humana tal como la define el artículo 14 exige que la intervención sea siempre posible. Eso significa que el sistema que ejecuta los pasos del agente debe ser arquitectónicamente distinto del sistema que puede detener, redirigir o revertir esos pasos. Si tu capa de orquestación y tu kill-switch viven en el mismo runtime, tienes un único punto de fallo tanto para la capacidad como para el control. Construye el plano de control como un servicio de primer nivel, no como una ocurrencia tardía.

3. Define y aplica límites de autonomía de forma explícita

Los sistemas agénticos tienden a ampliar su propio alcance de forma incremental. Un pipeline diseñado para resumir documentos empieza a llamar a APIs de búsqueda; un pipeline diseñado para redactar correos empieza a enviarlos. Los límites de autonomía deben declararse como política, aplicarse en la capa de infraestructura y registrarse cuando se aproximan o se ponen a prueba. Aquí es también donde las obligaciones de los modelos GPAI se vuelven relevantes: si las capacidades autónomas del modelo subyacente activan la designación de riesgo sistémico, el proveedor enfrenta obligaciones de gestión de riesgos que incluyen esos patrones de uso agéntico.

4. Diseña para una exposición a múltiples regulaciones, no para el cumplimiento de una sola

Un pipeline sanitario que maneja datos de pacientes está sujeto simultáneamente a los requisitos de minimización de datos y limitación de finalidad del RGPD y a las obligaciones de registro de la Ley de IA. Un pipeline de servicios financieros también puede estar bajo el marco de gestión de riesgos TIC de DORA. Los contextos de defensa e infraestructura crítica añaden NIS2. Estos marcos no se contradicen, pero sí se acumulan: una decisión de diseño que satisface el registro del artículo 12 puede incumplir los requisitos de residencia de datos del RGPD si los logs salen de la UE. La arquitectura de cumplimiento debe componerse, no apilarse.

La infraestructura no es neutral en este contexto

El lugar donde se ejecuta un pipeline agéntico determina qué afirmaciones de cumplimiento puedes hacer sobre él. Los logs que salen de la UE, aunque sea de forma transitoria, generan exposición bajo Schrems II. Las llamadas de inferencia enrutadas a través del plano de control de un hyperscaler bajo jurisdicción estadounidense crean vacíos de responsabilidad que las obligaciones de supervisión del artículo 14 no pueden cubrir.

Ejecutamos infraestructura de inferencia y entrenamiento GPU en nuestros centros de Múnich (MUC1) y Helsinki (HEL1), ambos bajo jurisdicción europea, sin ninguna empresa matriz extranjera en ámbito. Nuestro peering directo con AWS, Azure, GCP, Oracle y Cloudflare en todos los centros significa que los pipelines agénticos que necesitan llamar a servicios externos pueden hacerlo sin que el tráfico salga de una ruta de red controlada. Los logs estructurados de esos pipelines permanecen en la misma jurisdicción que los datos que describen. No es un argumento de marketing; es lo que el artículo 12 y el principio de responsabilidad proactiva del RGPD exigen conjuntamente, y es para lo que está construida la infraestructura.

Los equipos que construyen sistemas agénticos en sectores regulados están tomando ahora decisiones fundacionales: dónde se ejecuta la inferencia, cómo se estructuran y conservan los logs, cómo se separan los planos de control y cómo se aplican los límites de autonomía. Esas decisiones definirán qué es auditable, qué es defendible y qué es conforme cuando las obligaciones de la Ley aterricen plenamente. Diseñar bien la arquitectura antes del plazo es más barato que explicarle a un regulador por qué se diseñó de otra manera.