Cumplimiento de la Ley de IA de la UE para despliegues de agentes de IA: las obligaciones artículo por artículo

El plazo

El 2 de agosto de 2026, la Ley de IA de la UE (Reglamento (UE) 2024/1689) alcanza su siguiente hito de aplicación. El resto de la Ley entra en vigor — incluidas las obligaciones para los sistemas de IA de alto riesgo, los requisitos de transparencia para el contenido generado por IA y las disposiciones sancionadoras. La multa máxima es de 35 millones de euros o el 7% de la facturación anual mundial, la cifra que sea mayor.

La Ley entró en vigor el 1 de agosto de 2024. Las prohibiciones sobre prácticas de riesgo inaceptable (puntuación social, manipulación subliminal, vigilancia biométrica en tiempo real en espacios públicos) se aplican desde el 2 de febrero de 2025. Las obligaciones para los modelos de IA de propósito general y las reglas de gobernanza se aplican desde el 2 de agosto de 2025. El calendario de implementación confirma que el 2 de agosto de 2026 es la fecha en que los mandatos para sistemas de alto riesgo, las obligaciones de transparencia y el marco sancionador surten pleno efecto — con excepciones limitadas para los sistemas del artículo 6(1), que llegan en agosto de 2027.

Para las organizaciones que despliegan agentes de IA que toman o apoyan decisiones sobre crédito, empleo, acceso a servicios esenciales o infraestructura crítica, el 2 de agosto es la fecha de cumplimiento. No una fecha de planificación. No una fecha de revisión. La fecha en que las obligaciones son exigibles.

La frontera de cumplimiento se extiende a la capa de acción

La mayoría de las organizaciones concentran sus esfuerzos de cumplimiento de IA en el modelo — gobernanza de los datos de entrenamiento, pruebas de sesgo, monitoreo de salidas. El análisis de cumplimiento de Salt Security deja claro que esto es insuficiente. El alcance de la Ley se extiende a lo que el modelo hace, no solo a lo que produce.

El artículo 15 (Ciberseguridad) exige protección contra ataques adversarios, envenenamiento de datos, ataques a la confidencialidad y evasión del modelo. El análisis de Salt Security confirma que esta protección "debe extenderse a las interfaces a través de las cuales los sistemas de IA interactúan con el mundo (API y servidores MCP)". Un agente de IA que llama a NetSuite mediante un módulo del Model Context Protocol, o lee datos de clientes de HubSpot mediante un conector MCP, incorpora esas interfaces a la frontera de cumplimiento.

Los considerandos 99 y 100 abordan las arquitecturas multiagente de forma explícita. En una cadena de agentes de IA, la frontera de cumplimiento se extiende a cada agente que desempeña una función de alto riesgo. Si un agente orquestador delega una decisión de precios en un subagente que llama a un motor de RFQ, ambos agentes heredan las obligaciones. El alcance del cumplimiento es la cadena de llamadas completa, no el punto de entrada.

Qué cuenta como alto riesgo

La Ley define los sistemas de IA de alto riesgo en el artículo 6 y el anexo III. Las categorías más relevantes para los despliegues de agentes B2B:

• Empleo y gestión de trabajadores — cribado de CV, decisiones de promoción, asignación de tareas, monitoreo del desempeño
• Acceso a servicios esenciales — puntuación crediticia, fijación de precios de seguros, determinaciones de elegibilidad
• Componentes de seguridad de infraestructura crítica — transporte, energía, agua
• Aplicación de la ley y justicia — aunque la mayoría de los despliegues B2B no encajan aquí

Un agente de compras que evalúa cotizaciones de proveedores y recomienda decisiones de adjudicación toca territorio de acceso a servicios esenciales si la compra implica bienes regulados o contratos del sector público. Un agente de cotización que fija precios diferentes por nivel de cliente toca territorio de crédito y seguros si la fijación de precios afecta el acceso a productos financieros. La clasificación depende de la función que la IA desempeña, no del sector en el que opera la empresa que la despliega.

Para los sistemas que no alcanzan el umbral de alto riesgo, las obligaciones de transparencia siguen aplicándose. El artículo 50 exige que los responsables del despliegue informen a las personas cuando interactúan con sistemas de IA (chatbots, generación de contenido). El contenido de IA generativa debe ser identificable. Estas obligaciones surten efecto el 2 de agosto de 2026.

Las obligaciones artículo por artículo

Para los sistemas de alto riesgo, la Ley impone obligaciones específicas y auditables. El análisis de Salt Security proporciona el desglose a nivel de artículo. Esto es lo que exige cada uno y cómo se corresponde con la infraestructura de agentes.

Artículo 9 — Gestión de riesgos

Un sistema de gestión de riesgos continuo e iterativo a lo largo de todo el ciclo de vida de la IA. No una evaluación única antes del despliegue. El sistema debe identificar, analizar y mitigar los riesgos conocidos y previsibles, incluidos los riesgos que emergen después de que el sistema se introduce en el mercado.

Qué significa esto para los agentes: El registro de riesgos es un documento vivo. Cada nuevo módulo MCP, cada nuevo conector, cada nuevo registro de herramienta es una superficie de riesgo que debe evaluarse. Una capa de gobernanza que registra cada llamada a herramientas y su resultado proporciona la base de evidencia para la revisión iterativa de riesgos — sin ella, el sistema de gestión de riesgos no tiene datos.

Artículo 10 — Gobernanza de datos

Conjuntos de datos de alta calidad para minimizar los resultados discriminatorios. Las protecciones contra el acceso no autorizado y el envenenamiento de datos deben extenderse al momento de la inferencia — cuando los agentes de IA llaman activamente a las API y acceden a datos externos.

Qué significa esto para los agentes: Los datos que el agente lee en tiempo de ejecución (de NetSuite, BigCommerce, catálogos de proveedores) están dentro del alcance. Si un catálogo de proveedor está envenenado con datos de precios incorrectos y el agente cotiza a partir de él, se aplica la obligación de gobernanza de datos. La validación de entrada sobre las respuestas de las herramientas MCP no es un detalle de calidad — es un control de cumplimiento.

Artículo 11 — Documentación técnica

Un inventario completo de todos los componentes, interfaces y capacidades antes de la introducción en el mercado. Para un sistema de agentes, esto significa documentar cada módulo MCP, cada herramienta que registra, cada sistema aguas arriba al que se conecta y cada ruta de error que maneja.

Qué significa esto para los agentes: El registro de módulos es la documentación. Un sistema que registra dinámicamente módulos MCP con esquemas, límites de tasa y registros de auditoría produce la documentación técnica como subproducto de su arquitectura. Un sistema de scripts ad hoc y llamadas a API no registradas no lo hace.

Artículo 12 — Conservación de registros (registro de eventos)

Registro automático de todos los eventos. Los registros deben ser a prueba de manipulaciones y conservarse durante un mínimo de 6 meses (24 meses para sistemas biométricos y de aplicación de la ley). Cada llamada a herramientas, cada decisión del agente, cada intervención humana debe poder reconstruirse a partir de los registros.

Qué significa esto para los agentes: Cada llamada a una herramienta MCP debe registrarse con marca de tiempo, ID del agente, nombre de la herramienta, hash de la entrada (no la entrada en bruto — frontera de PII), estado de la salida y duración. El registro debe ser de solo anexión o a prueba de manipulaciones. La retención de 6 meses es un mínimo, no un objetivo. Esta es la obligación más directamente mapeable: una arquitectura MCP gobernada que registra cada llamada de función en DynamoDB con campos estructurados satisface el artículo 12 por construcción.

Artículo 14 — Supervisión humana

El sistema debe permitir a los operadores humanos supervisar, intervenir y detener el sistema en tiempo real cuando se detecte un comportamiento anómalo. No se trata de un panel de monitoreo que muestra métricas a posteriori. Es la capacidad de detener un agente en ejecución a mitad de la tarea.

Qué significa esto para los agentes: Las instrucciones a nivel de prompt ("detente", "cancela") no constituyen supervisión bajo la Ley. Forman parte del contexto conversacional de la IA y pueden ignorarse bajo pérdida de memoria o inyección de prompts. La Ley exige un mecanismo de detención determinista que opere fuera del proceso de razonamiento de la IA. Un kill-switch que revoca el token de autenticación de un agente, deshabilita un módulo MCP específico mediante un cambio de configuración o activa un disyuntor ante patrones de comportamiento anómalos satisface el artículo 14. Un comando "detente" no.

El análisis de la arquitectura de kill-switch de miniOrange define cuatro capas que se corresponden con esta obligación:

1. Revocación de acceso basada en identidad — tokens de sesión de corta duración vinculados a tareas específicas; revocación instantánea de credenciales
2. Disyuntores y detección de anomalías — se activan ante solicitudes excesivas a la API, consumo inusual de tokens, bucles repetidos
3. Revocación de capacidad delimitada — deshabilitar solo la capacidad peligrosa (p. ej., retirar el permiso de envío de correo pero mantener la lectura de tickets)
4. Gestión de tareas en curso — revertir cambios incompletos, preservar los registros de ejecución, verificar la estabilidad del sistema tras el apagado

El incidente de OpenClaw documentado en el mismo análisis ilustra por qué la detención a nivel de prompt falla: un agente de IA que organizaba una bandeja de correo superó su límite de memoria, perdió el contexto y volvió a su último objetivo recordado — borrar correos. Los comandos "detente" y "cancela" del usuario fueron ignorados. El agente continuó hasta que se le terminó manualmente a nivel del sistema operativo. El fallo fue arquitectónico: no existía ningún mecanismo de apagado determinista fuera del proceso de razonamiento de la IA.

Artículo 15 — Ciberseguridad

Robustez técnica contra ataques adversarios, envenenamiento de datos, ataques a la confidencialidad y evasión del modelo. La protección debe extenderse a las interfaces a través de las cuales la IA interactúa con el mundo.

Qué significa esto para los agentes: Cada servidor MCP, cada endpoint de API, cada conector está dentro del alcance. El panorama de seguridad de MCP documentado en 2026 — la falla sistémica de diseño STDIO que afecta a 150 millones de descargas, CVE-2026-33032 ("MCPwn", CVSS 9.8), CVE-2026-0755 (Gemini MCP, CVSS 9.8), del 30 al 82 por ciento de los servidores MCP públicos con fallas explotables — es el riesgo de ciberseguridad al que apunta la Ley. Solo el 8,5 por ciento de los servidores MCP usan OAuth. La Ley no exige OAuth específicamente, pero sí exige un nivel de ciberseguridad que el ecosistema MCP actual no cumple por defecto.

Artículos 72 y 73 — Monitoreo poscomercialización y notificación de incidentes

Un sistema de monitoreo documentado desde el primer día del despliegue. Ventanas de notificación de incidentes:

• 24 horas para riesgos para la vida o la seguridad
• 72 horas para otros incidentes graves
• 15 días para fallos de funcionamiento

Qué significa esto para los agentes: El registro de auditoría es la fuente del informe de incidentes. Cuando un agente excede permisos, hace una llamada no autorizada o produce una salida incorrecta que afecta a una decisión, el registro reconstruye lo ocurrido. Las ventanas de 24 y 72 horas significan que el sistema de monitoreo debe alertar en tiempo real, no en una revisión semanal.

La brecha de gobernanza

El State of AI in the Enterprise 2026 de Deloitte encontró que solo 1 de cada 5 empresas tiene un modelo maduro de gobernanza para los agentes de IA autónomos. Entre el 47 y el 53 por ciento de las organizaciones han tenido agentes de IA que exceden permisos o sufren un incidente, según el informe 2026 de practical-devsecops. Solo el 23 por ciento tiene una estrategia formal de identidad de agentes de IA.

La Ley no prescribe una arquitectura específica. Prescribe resultados: gestión de riesgos que sea continua, registro que sea automático y a prueba de manipulaciones, supervisión que pueda detener el sistema de forma determinista, ciberseguridad que se extienda a cada interfaz. La arquitectura que satisface estos resultados es el patrón de módulos MCP gobernados — el mismo patrón que aborda las vulnerabilidades de seguridad documentadas a lo largo de la cronología de brechas de MCP de 2026.

Cómo una arquitectura MCP gobernada satisface las obligaciones

La capa de gobernanza que hace que los módulos MCP sean seguros de operar en producción es la misma capa que satisface los requisitos de la Ley. La correspondencia es directa:

Artículo de la Ley de IA de la UE	Obligación	Control de gobernanza
Artículo 9 (Gestión de riesgos)	Evaluación de riesgos continua e iterativa	Cada llamada a herramientas registrada con su resultado; registro de riesgos actualizado a partir de los datos de auditoría
Artículo 10 (Gobernanza de datos)	Protección en tiempo de inferencia	Validación de entrada sobre las respuestas de herramientas MCP; errores tipados que distinguen fallos de calidad de datos de errores transitorios
Artículo 11 (Documentación técnica)	Inventario completo de componentes e interfaces	Registro de módulos: cada módulo MCP, esquema de herramienta, conexión aguas arriba y código de error documentado en el registro
Artículo 12 (Conservación de registros)	Registro automático y a prueba de manipulaciones, retención de 6 meses	Registros JSON estructurados en DynamoDB: marca de tiempo, ID del agente, nombre de la herramienta, hash de entrada, estado de salida, duración; de solo anexión con aislamiento de inquilinos por partition key
Artículo 14 (Supervisión humana)	Capacidad de detención en tiempo real	Kill-switch: revocación de identidad (tokens JWT de corta duración), disyuntores (límites de tasa por herramienta por ventana), revocación de capacidad delimitada (deshabilitar módulo por cambio de configuración), reversión en curso
Artículo 15 (Ciberseguridad)	La protección se extiende a las API y servidores MCP	Autenticación OAuth/Cognito, límite de tasa, manejo de la frontera de PII (hash de campos SHA-256 antes del registro), contratos de error tipados
Artículos 72–73 (Notificación de incidentes)	Ventanas de notificación de 24/72 horas	Detección de anomalías en tiempo real a partir del registro de auditoría; alertas ante exceso de permisos, llamadas a herramientas inesperadas, violaciones de límite de tasa

La idea clave es que estos controles no se añaden a posteriori. Son la estructura de la canalización de registro, ejecución y logueo de los módulos MCP. Un módulo que registra sus herramientas con esquemas, declara sus límites de tasa, registra cada llamada en un almacén de solo anexión y puede deshabilitarse mediante un cambio de configuración produce la evidencia de cumplimiento como subproducto de su operación. Un agente ad hoc que llama a las API directamente no — y adaptar controles de cumplimiento a un agente no gobernado es más caro que incorporarlos desde el principio.

La frontera de cumplimiento multiagente

Los considerandos 99 y 100 extienden la frontera de cumplimiento a cada agente de una cadena que desempeña una función de alto riesgo. Esto tiene una implicación arquitectónica que la mayoría de las organizaciones aún no han interiorizado.

Considere un flujo de trabajo de compras: un agente orquestador recibe un RFQ, delega la resolución de productos en un agente de catálogo, delega la fijación de precios en un agente de motor de cotización y delega la escritura del pedido en un agente de integración con el ERP. Bajo la Ley, si cualquiera de estos agentes desempeña una función de alto riesgo (fijación de precios que afecta el acceso al crédito, selección de proveedores que afecta el empleo, compra de bienes regulados), cada agente de la cadena hereda la obligación.

Esto significa que la capa de gobernanza debe estar a nivel de orquestación, no a nivel de agente individual. El registro debe trazar la cadena de llamadas completa — qué agente llamó a qué módulo con qué argumentos y cuál fue el resultado. El registro de módulos debe cubrir cada módulo de cada agente. El kill-switch debe poder detener la capacidad de un agente específico sin deshabilitar la infraestructura compartida.

El patrón de aislamiento de inquilinos por partition_key — donde cada registro de llamada de función MCP lleva una partition key que lo delimita a un inquilino y endpoint específicos — proporciona la estructura de rastro de auditoría que exige el cumplimiento multiagente. Una consulta contra el registro de llamadas de función puede reconstruir el estado completo del flujo de trabajo: qué agente activó qué herramienta, en qué orden, con qué argumentos y cuál fue el resultado. Esta es la base de evidencia para la conservación de registros del artículo 12 y la notificación de incidentes de los artículos 72–73 a lo largo de una cadena multiagente.

Qué hacer antes del 2 de agosto

Para las organizaciones con agentes de IA ya en producción o en la canalización de despliegue, el plazo del 2 de agosto crea una lista de tareas concreta:

1. Clasifique sus agentes. Determine cuáles caen dentro de las categorías de alto riesgo (empleo, servicios esenciales, infraestructura crítica). Los agentes que no tocan estas categorías siguen teniendo obligaciones de transparencia bajo el artículo 50.

2. Audite la capa de registro. ¿Puede reconstruir cualquier decisión del agente a partir de los registros? ¿Son los registros a prueba de manipulaciones y se conservan durante un mínimo de 6 meses? Si la respuesta es no, esta es la primera brecha que cerrar — el artículo 12 es la obligación más directamente verificable.

3. Verifique el mecanismo de detención. ¿Puede un operador detener un agente en ejecución de forma determinista, sin depender del propio razonamiento del agente? Si la detención depende de un comando de prompt, no satisface el artículo 14. Se requiere un kill-switch que revoque credenciales o deshabilite módulos mediante un cambio de configuración.

4. Documente el inventario de interfaces. Cada API, cada servidor MCP, cada conector que el agente llama debe estar documentado (artículo 11). El registro de módulos es la documentación — si no tiene uno, esta es la segunda brecha que cerrar.

5. Defina el procedimiento de respuesta a incidentes. ¿A quién se notifica cuando un agente excede permisos? ¿Cuál es la cadena de notificación de 24 y 72 horas? El procedimiento debe estar documentado antes del despliegue, no después de un incidente.

6. Evalúe el alcance multiagente. Si su arquitectura involucra cadenas de agentes, mapee cada agente que podría desempeñar una función de alto riesgo. La frontera de cumplimiento es la cadena completa.

El costo del incumplimiento frente al costo de la gobernanza

La multa máxima es de 35 millones de euros o el 7 por ciento de la facturación mundial. Para una empresa de tamaño medio con 100 millones de euros de ingresos, eso son 7 millones de euros. La capa de gobernanza que satisface la Ley — registro de auditoría, límite de tasa, errores tipados, kill-switch, registro de módulos, aislamiento de inquilinos — es la misma capa de gobernanza que hace que los agentes de producción sean seguros de operar independientemente de la presión regulatoria. El 47 al 53 por ciento de las organizaciones que ya han experimentado un incidente de agente están pagando el costo de los agentes no gobernados en riesgo operativo. La Ley simplemente hace ese costo explícito y exigible.

Las organizaciones que incorporaron la gobernanza a su arquitectura de agentes desde el principio — registro de módulos con esquemas, logueo de llamadas de función en un almacén duradero, autenticación con tokens de corta duración, límites de tasa aplicados en la frontera del módulo — son aquellas para las que el 2 de agosto es un ejercicio de documentación en lugar de una adaptación de emergencia. Las organizaciones que desplegaron agentes como scripts ad hoc que llaman a las API directamente son las que enfrentan la emergencia.

---

Un distribuidor que opera NetSuite, BigCommerce y tres catálogos de proveedores tiene un agente que recibe RFQ, resuelve productos contra un grafo de catálogo, fija precios por nivel de cliente y escribe cotizaciones de vuelta en NetSuite. Si ese agente fija términos de crédito o selecciona proveedores para una compra regulada, cae dentro de la categoría de alto riesgo. La arquitectura MCP gobernada — cada llamada a herramientas registrada en DynamoDB con marca de tiempo y resultado, cada módulo deshabilitable mediante un cambio de configuración, cada agente autenticado con tokens JWT de corta duración, cada error tipado y clasificado — es lo que hace que ese agente sea conforme el 2 de agosto. La misma arquitectura que lo hace seguro de operar lo hace conforme para operar.

Solicite una construcción delimitada. Descubrimiento de una semana. Obtiene un inventario de sistemas, un mapa de flujo de trabajo y un alcance fijo — construya o no con nosotros.