OWASP Agentic AI Top 10 × Ley de IA de la UE: el cruce de cumplimiento completo

El cruce maestro: los 10 riesgos ASI mapeados a los artículos de la Ley de IA de la UE¶

Cada fila de la tabla siguiente asocia un riesgo OWASP ASI con los artículos principales de la Ley de IA de la UE que lo regulan, los artículos secundarios que toca, la obligación clave que crea para proveedores y responsables del despliegue, y el artefacto de evidencia que produce una implementación conforme. La descarga operativa de esta entrada es el cuaderno de trabajo en PDF; el CSV legible por máquina permanece disponible como apéndice complementario.

Descarga: el cuaderno de evaluación de brechas — owasp-asi-eu-ai-act-gap-assessment-workbook.pdf (sin correo electrónico, sin barreras). Apéndice secundario: owasp-asi-top10-eu-ai-act-crosswalk.csv.

¿Qué es el Top 10 de la OWASP Agentic Security Initiative?¶

El OWASP Top 10 for Agentic Applications 2026 es el catálogo canónico de los diez riesgos de seguridad más críticos en sistemas autónomos de agentes de IA que utilizan herramientas. Se publicó el 9 de diciembre de 2025 en el London Agentic Security Summit a través de la Agentic Security Initiative (ASI), un grupo de trabajo dentro del OWASP GenAI Security Project. Cada riesgo lleva el prefijo `ASI` (Agentic Security Issue) y se clasifica por prevalencia e impacto observados en despliegues de producción a lo largo de 2024 y 2025.

La iniciativa está codirigida por John Sotiropoulos (Head of AI Security en Kainose, ASI Co-lead y Top 10 Chair) y Keren Katz (Senior Group Manager of AI Security en Tenable, Top 10 Co-Lead), bajo el OWASP GenAI Security Project copresidido por Steve Wilson (Chief Product Officer, Exabeam y fundador del Top 10 original de OWASP para LLM) y Scott Clinton (SCVentures). El desarrollo se prolongó durante más de un año con la aportación de más de 100 investigadores de seguridad y un Comité de Revisión de Expertos integrado por representantes del NIST (Apostol Vassilev), el Microsoft AI Red Team (Pete Bryan, Dan Jones), AWS (Matt Saner), Cisco (Hyrum Anderson), Oracle Cloud (Egor Pushkin), el Alan Turing Institute (Vasilios Mavroudis, Josh Collyer) y Zalando (Alejandro Saucedo).

La adopción por parte del sector fue inmediata. Microsoft publicó una entrada de blog que mapeaba los 10 riesgos ASI a los controles de Copilot Studio (marzo de 2026) y lanzó el Agent Governance Toolkit de código abierto (abril de 2026). El Safety and Security Framework de NVIDIA hace referencia a la ASI Agentic Threat Modelling Guide. AWS incorpora el catálogo Agentic Threats and Mitigations. GoDaddy implementó en producción la propuesta ASI Agentic Naming Service. Palo Alto Networks mapeó los 10 riesgos a su plataforma Prisma AIRS. Apostol Vassilev, del NIST, calificó el marco como oportuno, técnicamente sólido e inmediatamente accionable.

¿Es el Top 10 de ASI lo mismo que el Top 10 de OWASP para LLM?

No. El OWASP Top 10 for Large Language Model Applications cataloga riesgos en aplicaciones LLM de un solo turno (chatbots, asistentes RAG, generadores de contenido). El Top 10 de ASI cataloga riesgos que solo existen cuando un LLM adquiere autonomía, memoria persistente, acceso a herramientas y la capacidad de comunicarse con otros agentes: las primitivas agénticas. Los riesgos ASI incluyen fallos en cascada multiagente (ASI08), ataques a la comunicación entre agentes (ASI07) y deriva descontrolada (ASI10), que no tienen un análogo significativo en el Top 10 de LLM. Ambos catálogos están mantenidos por el mismo OWASP GenAI Security Project y están diseñados para utilizarse conjuntamente.

Los artículos de la Ley de IA de la UE aplicables a los sistemas agénticos¶

La Ley de IA de la UE no menciona explícitamente la IA agéntica, pero la AI Office ha confirmado que los agentes podrían tener que cumplir los requisitos para sistemas de IA y/o las obligaciones para los proveedores de modelos de IA de uso general. La tabla siguiente es la referencia rápida para cada artículo invocado por el cruce anterior. Las columnas cubren el número del artículo, la obligación en una frase y si vincula al proveedor, al responsable del despliegue o a ambos.

Descarga: cuaderno de trabajo, checklist de controles y apéndice CSV¶

Los recursos siguientes son gratuitos, sin barreras y reutilizables. Utilice el cuaderno de trabajo en PDF para la reunión de revisión interna, la checklist para el detalle de implementación, y el CSV solo cuando necesite un apéndice legible por máquina.

• owasp-asi-eu-ai-act-gap-assessment-workbook.pdf: un PDF de cinco páginas para una sesión de trabajo sobre inventario del sistema, puntuación de aplicabilidad de ASI, revisión de evidencias, asignación de backlog y firma final.
• owasp-asi-top10-controls-checklist.md: aproximadamente 50 controles concretos agrupados por riesgo ASI, cada uno anotado con el artículo de la Ley de IA de la UE que satisface y el artefacto del Evidence Room que genera.
• owasp-asi-top10-eu-ai-act-crosswalk.csv: el apéndice legible por máquina con el mapeo completo de las 10 filas, con artículos principales y secundarios y el artefacto de evidencia que produce cada fila.

ASI01 — Agent Goal Hijack → artículos 9, 15, 14, 5¶

ASI01 Agent Goal Hijack redirige la toma de decisiones de un agente mediante instrucciones inyectadas o contenido envenenado. A diferencia de la explotación de software tradicional, que requiere modificación de código, los agentes de IA se redirigen mediante lenguaje natural en correos electrónicos, documentos o páginas web. El artículo 9 es la obligación principal: el sistema de gestión de riesgos debe abordar el uso indebido razonablemente previsible, una categoría que ahora obliga a cubrir la inyección adversarial de prompts.

Incidente real. EchoLeak (CVE-2025-32711, CVSS 9.3) —la primera prompt injection zero-click en producción— engañó a Microsoft 365 Copilot para que exfiltrara datos a través de un único correo electrónico manipulado. No se requería interacción del usuario; el agente leyó el correo como parte de la recuperación RAG normal y obedeció las instrucciones embebidas.

• Desplegar filtrado de entrada y salida con detección de prompt injection en cada ruta de contenido externo: satisface el art. 15; produce un informe de pruebas del motor de detección en el Evidence Room.
• Aplicar un aislamiento estricto del system prompt con jerarquía de instrucciones: satisface el art. 9; produce un registro de pruebas unitarias de aplicación de la jerarquía.
• Enrutar las anomalías de comportamiento al Decision Desk para intervención humana: satisface el art. 14(4)(c); produce el historial de Assurance Alerts.
• Etiquetar todo el contenido externo como no fiable por defecto en cada ruta de llamada a herramientas: satisface el art. 9; produce un registro de política en el Tool Catalog.
• Realizar ejercicios de red team de prompt injection cada 90 días: satisface el art. 9(6) (pruebas antes de la introducción en el mercado); produce un informe de red team en el Evidence Room.

¿Un filtro de prompt injection satisface por sí solo los requisitos de ciberseguridad del artículo 15?

No. Un filtro es un único control de detección. El artículo 15(5) exige resiliencia como propiedad del sistema: debe combinarse con (1) la aplicación estricta de la jerarquía de instrucciones en el system prompt, (2) el etiquetado de contenido no fiable en entradas y salidas, (3) la monitorización del comportamiento conectada a la intervención del artículo 14 y (4) una entrada documentada en el registro de riesgos del artículo 9 que explique por qué la combinación es proporcionada. Los filtros por sí solos también son sorteados por las cargas útiles recursivas u ofuscadas documentadas en el OWASP AI Exchange; la defensa en profundidad es la única postura que cumple simultáneamente los artículos 9 y 15.

ASI02 — Tool Misuse and Exploitation → artículos 9, 15, 12, 17, Anexo IV¶

ASI02 Tool Misuse se produce cuando los agentes utilizan herramientas legítimas de forma insegura a causa de prompts ambiguos, desalineamiento o entradas manipuladas. Un asistente de programación con acceso al sistema de archivos se convierte en una herramienta de exfiltración; un bot de atención al cliente con acceso al correo electrónico se convierte en un motor de phishing. El artículo 9(3) es la obligación principal: el riesgo debe evaluarse a través de la aplicación combinada de los componentes del sistema, y las interacciones entre herramientas son exactamente eso.

Incidente real. Amazon Q Code Assistant (CVE-2025-8217) afectó aproximadamente a 1 millón de desarrolladores cuando tokens de GitHub comprometidos inyectaron instrucciones destructivas en la cadena de herramientas del asistente. Las instrucciones eran indistinguibles de la intención legítima del desarrollador en el límite de la llamada a herramientas.

• Aplicar el alcance de herramientas con mínimo privilegio mediante listas de permitidos explícitas: satisface el art. 9; produce un registro de alcance en el Tool Catalog.
• Validar y sanear cada argumento de herramienta en la invocación: satisface el art. 15(4); produce un informe de pruebas de validación de argumentos.
• Exigir aprobación humana para operaciones destructivas (escrituras en BD, transacciones financieras, borrados de archivos): satisface el art. 14; produce un registro de aprobación del Decision Desk.
• Registrar cada llamada a herramienta con parámetros, identidad del invocante y resultado: satisface el art. 12; produce Lineage Records.
• Documentar cada combinación de cadena de herramientas en el registro de riesgos del art. 9: satisface el art. 9(3); produce una entrada en el registro de riesgos.

¿Necesito registrar los argumentos completos de la llamada a la herramienta, o basta con un resumen para el artículo 12?

Argumentos completos. El artículo 12(1) exige registros que permitan la trazabilidad del funcionamiento del sistema. Un campo resumen (nombre de la herramienta + marca de tiempo) no permite a un investigador reconstruir lo que realmente ocurrió. En la práctica, el Evidence Room debe contener el nombre de la herramienta, los parámetros, la identidad del invocante, el resultado y el ID de correlación para cada invocación. Si los parámetros contienen datos personales, la política de retención de los registros se rige por el artículo 12(2)–(3), no por un paso opcional de resumen. Consulte la guía AI Agent Audit Trails para el contrato completo de registro.

ASI03 — Identity and Privilege Abuse → artículos 9, 15, 26, 12¶

ASI03 Identity and Privilege Abuse explota la confianza delegada, las credenciales heredadas o las cadenas de roles para obtener acceso no autorizado. Los agentes operan con privilegios significativos —acceso a bases de datos, recursos en la nube, APIs internas— y, cuando se ven comprometidos, el atacante hereda todos ellos. El artículo 15(5) obliga directamente a la resiliencia frente a violaciones de confidencialidad, lo que cubre el robo de credenciales y la herencia de privilegios.

Incidente real. La función Connected Agents de Microsoft en Copilot Studio expuso por defecto el conocimiento, las herramientas y los temas de cada agente al resto de agentes del entorno. Cada agente confiaba implícitamente en el resto, colapsando la frontera de privilegios.

• Emitir credenciales específicas por agente, de corta duración y con alcance, desde el Secrets Vault: satisface el art. 15; produce un registro de rotación.
• Desplegar zero-trust entre agentes sin confianza implícita: satisface el art. 9; produce un registro de fronteras de confianza en el Agent Registry.
• Rotar credenciales en cada límite de sesión más traza de auditoría: satisface el art. 12; produce una traza de auditoría de rotación.
• Asignar una persona competente y nominada a cada identidad de agente: satisface el art. 26(2); produce un registro de asignación de supervisión.
• Alimentar el Assurance Center con detecciones de escalada de privilegios: satisface el art. 15(5); produce un historial de incidentes de detección de escalada.

Si el responsable del despliegue ejecuta el agente, ¿quién es responsable del alcance de credenciales del artículo 15: el proveedor o el responsable del despliegue?

Ambos, en fronteras distintas. El artículo 15 vincula al proveedor a entregar el sistema con capacidad de aplicar un alcance fino de credenciales (resiliencia en fase de diseño). El artículo 26(1) vincula entonces al responsable del despliegue a utilizar el sistema conforme a las instrucciones de uso y a asignar una supervisión competente, lo que en la práctica significa configurar realmente credenciales con alcance en lugar de ejecutar el agente con un token de administrador compartido. Un proveedor que envíe únicamente una credencial god-mode ha incumplido el artículo 15; un responsable del despliegue que ignore el alcance disponible ha incumplido el artículo 26. Consulte AI Agent Permissions para el contrato completo de mínimo privilegio.

ASI04 — Agentic Supply Chain Vulnerabilities → artículos 17, 9, 15, Anexo IV¶

ASI04 Supply Chain Vulnerabilities abarca agentes, herramientas, plugins, servidores MCP o canales de actualización de terceros comprometidos. El artículo 17(1)(l) es la obligación principal: el sistema de gestión de la calidad debe documentar las medidas relacionadas con la cadena de suministro que cubran la adquisición, el control de calidad y la gestión de cambios en todos los componentes de terceros.

Incidentes reales. postmark-mcp —el primer servidor MCP malicioso descubierto en circulación— suplantó el servicio de correo de Postmark y envió en CCO todos los mensajes a un atacante. MCP Remote RCE (CVE-2025-6514, CVSS 9.6) permitió la ejecución arbitraria de comandos de SO cuando los clientes se conectaban a servidores no fiables, convirtiendo cada integración MCP no validada en un vector de ejecución remota de código.

• Verificar los servidores MCP antes de la conexión (firma, identidad, versión anclada): satisface el art. 17(1)(l); produce un registro de verificación en el Provider Hub.
• Producir un SBOM para cada agente, herramienta y artefacto de modelo: satisface el Anexo IV; produce un SBOM en el Evidence Room.
• Anclar las dependencias a versiones conocidas como buenas con monitorización de integridad en runtime: satisface el art. 9; produce un registro del monitor de integridad.
• Exigir AgentCards firmados para cada agente remoto: satisface el art. 17; produce un AgentCard firmado en el Agent Registry.
• Monitorizar los cambios upstream en las definiciones tras la aprobación: satisface el art. 9; produce un historial de alertas de cambios.

¿Exige realmente el Anexo IV un SBOM, o se trata de un artefacto de la orden ejecutiva estadounidense?

El Anexo IV no utiliza el acrónimo SBOM, pero el §2(c) exige explícitamente que la documentación técnica describa los recursos computacionales utilizados para desarrollar, entrenar, probar y validar el sistema de IA, y el §2(b) exige una descripción de cómo el sistema interactúa o puede utilizarse para interactuar con hardware o software, incluidos otros sistemas de IA. La única forma práctica de satisfacer ambos para un sistema agéntico con más de 30 componentes upstream (modelos, herramientas, servidores MCP, frameworks) es un SBOM. La prEN 18286 de CEN-CENELEC hace referencia explícita a la evidencia de bill-of-materials como parte de los controles de la cadena de suministro del artículo 17.

ASI05 — Unexpected Code Execution → artículos 15, 9, 14, 12¶

ASI05 Unexpected Code Execution se produce cuando el código generado o invocado por el agente da lugar a una ejecución, compromiso o escape no intencionados. El artículo 15 es la obligación principal: exige redundancia técnica, planes a prueba de fallos y resiliencia de ciberseguridad frente a la explotación. El sandboxing y los controles de ejecución son medidas de cumplimiento directas.

Incidentes reales. Solo en diciembre de 2025 se descubrieron más de 30 CVE en las principales plataformas de codificación con IA. El proyecto de investigación IDEsaster demostró que el 100 % de los IDE de IA probados —Claude Desktop, Cursor, GitHub Copilot, Windsurf— contenía rutas de ejecución de código explotables. El patrón de ataque es consistente: el contenido no fiable (un README, un comentario, un docstring) engaña al agente para que ejecute código fuera de la intención del usuario.

• Ejecutar el código en entornos en sandbox con límites de CPU, memoria, sistema de archivos y red: satisface el art. 15; produce un registro de ejecución en sandbox.
• Exigir aprobación humana para el código que toque bases de datos, APIs o sistemas de archivos: satisface el art. 14; produce un registro de aprobación del Decision Desk.
• Desactivar las funciones de auto-ejecución y auto-aprobación por defecto en cada integración con IDE: satisface el art. 9; produce una auditoría de configuración.
• Capturar el código y el resultado completos en Lineage Records: satisface el art. 12; produce una entrada en el Evidence Room.
• Probar los límites de ejecución de código frente a criterios de aprobación definidos antes del despliegue: satisface el art. 9(6); produce un informe de pruebas de ejecución de código.

¿Es un contenedor lo mismo que un sandbox a efectos del artículo 15?

Un contenedor es un control necesario pero no suficiente. El artículo 15(4) exige soluciones de redundancia técnica, que pueden incluir planes de respaldo o a prueba de fallos. Un contenedor estándar no impone topes de CPU, no bloquea por defecto la red saliente y no sobrevive a una primitiva de escalada de privilegios. Un sandbox conforme combina (1) un contenedor (aislamiento de namespaces), (2) seccomp o filtrado de syscalls, (3) topes de recursos forzados, (4) una política de salida con denegación por defecto y (5) un kill switch: es la combinación la que satisface el artículo 15. El SGC del proveedor debe documentar en qué capa reside cada control.

ASI06 — Memory and Context Poisoning → artículos 15, 10, 9, 12¶

ASI06 Memory and Context Poisoning corrompe el contexto almacenado —memoria, embeddings, bases RAG— para sesgar el razonamiento y las acciones futuras. A diferencia de los chatbots sin estado, los agentes mantienen memoria persistente; una única inyección exitosa envenena todas las sesiones futuras. El artículo 15 aborda explícitamente los bucles de retroalimentación (salidas sesgadas que influyen en la entrada de operaciones futuras) y el artículo 10 rige la calidad de los conjuntos de datos de entrenamiento, validación y prueba, directamente aplicable a la integridad de las bases RAG.

Incidente real. Se demostró que Gemini de Google era vulnerable a la invocación retardada de herramientas: documentos cargados con prompts ocultos provocaban el almacenamiento de información falsa que se activaba con palabras comunes en sesiones posteriores. El usuario que abría el documento no era el usuario que después era atacado.

• Registrar la procedencia de los datos (fuente, marca de tiempo, puntuación de confianza) en cada escritura en memoria: satisface el art. 10; produce un registro de procedencia de datos.
• Desplegar prevención de bucles de retroalimentación en las rutas de aprendizaje posteriores al despliegue: satisface el art. 15; produce evidencia de control.
• Realizar comprobaciones de integridad y detección de anomalías en las bases RAG: satisface el art. 9; produce alertas de comprobación de integridad.
• Aplicar políticas de expiración de memoria para contextos sensibles: satisface el art. 10(3); produce un registro de política de expiración.
• Documentar los criterios de gobernanza de datos del RAG en el Anexo IV: satisface el art. 10(2); produce la sección de gobernanza de datos del Anexo IV.

¿Una base RAG cuenta como conjunto de datos de entrenamiento conforme al artículo 10?

Sí, funcionalmente. El artículo 10(1) rige los conjuntos de datos de entrenamiento, validación y prueba utilizados para técnicas que implican entrenamiento de modelos. En sentido estricto, un índice RAG no es un dato de entrenamiento. Sin embargo, el artículo 15(4) captura explícitamente los bucles de retroalimentación posteriores al despliegue en los que las salidas sesgadas influyen en la entrada de operaciones futuras, que es exactamente el mecanismo del envenenamiento de memoria. La prueba práctica es esta: si la siguiente decisión de su agente depende de datos escritos por una sesión previa, las obligaciones de gobernanza de datos del artículo 10(2) (relevancia, representatividad, ausencia de errores) se aplican a esa base RAG con independencia de que se etiquete como entrenamiento o memoria.

ASI07 — Insecure Inter-Agent Communication → artículos 15, 9, 12, 17¶

ASI07 Insecure Inter-Agent Communication abarca la suplantación, intercepción o manipulación de mensajes entre agentes debido a una autenticación o integridad débiles. El artículo 15(5) exige directamente resiliencia frente a violaciones de confidencialidad, lo que cubre la intercepción y suplantación de mensajes entre agentes.

Incidente real. Palo Alto Unit 42 descubrió el Agent Session Smuggling en el protocolo A2A (noviembre de 2025): agentes maliciosos explotaban las relaciones de confianza incorporadas al protocolo para mantener conversaciones de varios turnos, adaptar su estrategia y construir confianza falsa con los agentes objetivo. El patrón de ataque es novedoso porque no rompe ningún protocolo: abusa de la primitiva de confianza que el protocolo asume.

• Autenticar y cifrar los canales A2A con verificación de la integridad de los mensajes: satisface el art. 15; produce un registro de auditoría de mTLS.
• Firmar criptográficamente los AgentCards para cada agente remoto: satisface el art. 17; produce un AgentCard firmado en el Agent Registry.
• Registrar cada mensaje entre agentes con identidad de emisor y receptor: satisface el art. 12; produce Lineage Records entre agentes.
• Incluir cada flujo de trabajo federado en la evaluación de riesgos de la aplicación combinada: satisface el art. 9(3); produce una entrada de riesgo de flujo federado.
• Detectar patrones de session smuggling en conversaciones A2A de varios turnos: satisface el art. 15(5); produce un historial de alertas de anomalías de sesión.

Si dos agentes de alto riesgo se comunican entre sí, ¿necesito repetir la FRIA?

Potencialmente sí. El artículo 27 exige una evaluación de impacto sobre los derechos fundamentales antes de que un responsable del despliegue ponga en uso un sistema de alto riesgo en contextos especificados. Una federación A2A modifica el sistema que el responsable del despliegue está poniendo en uso: el comportamiento combinado ya no es equivalente al de cada agente por separado. La AI Office no ha emitido una guía formal sobre las FRIA de agentes federados, pero el artículo 9(3) (aplicación combinada) y el artículo 27(1)(c) (contexto específico de uso) en conjunto apuntan a lo siguiente: si la federación cambia la cadena de decisión que afecta a una persona física, repita la FRIA. Consulte la plantilla FRIA para la checklist completa.

ASI08 — Cascading Failures → artículos 9, 15, 17, 26¶

ASI08 Cascading Failures describe un único fallo que se propaga a través de agentes, herramientas y flujos de trabajo hasta convertirse en un impacto a escala de todo el sistema. El artículo 9(3) es la obligación principal: las medidas de gestión de riesgos deben prestar la debida consideración a los efectos y posibles interacciones derivadas de la aplicación combinada, que es la definición precisa del riesgo de fallo en cascada.

Incidente real. Una investigación de Galileo AI (diciembre de 2025) demostró que un único agente comprometido envenenó el 87 % de la toma de decisiones aguas abajo en un plazo de 4 horas en sistemas multiagente simulados. En el mundo real, una cascada de aprovisionamiento en una empresa de fabricación llegó a aprobar 5 millones de dólares en órdenes de compra falsas a lo largo de 10 transacciones antes de ser detectada.

• Implementar circuit breakers entre los flujos de trabajo agénticos con topes de radio de impacto: satisface el art. 15; produce un informe de pruebas de circuit breakers.
• Realizar pruebas con gemelo digital de escenarios de cascada antes del rollout: satisface el art. 9(6); produce un informe de pruebas de cascada.
• Correlacionar la observabilidad entre agentes a través de flujos de trabajo con IDs de correlación: satisface los art. 12 y art. 26(5); produce un índice de trazas en el Assurance Center.
• Documentar un procedimiento de contención de cascadas en el SGC del artículo 17: satisface los art. 17 y art. 73; produce un plan de respuesta a incidentes en el Evidence Room.
• Aplicar presupuestos de radio de impacto por flujo de trabajo en runtime: satisface el art. 9(3); produce un registro de política de radio de impacto.

¿Qué se considera incidente grave conforme al artículo 73 en una cascada agéntica?

El artículo 3(49) define un incidente grave como aquel que conduce, directa o indirectamente, a (a) la muerte o a un daño grave para la salud de una persona, (b) una interrupción grave e irreversible de infraestructuras críticas, (c) la infracción de derechos fundamentales, o (d) un daño grave a la propiedad o al medio ambiente. Un fallo en cascada que provoque 5 millones de dólares en órdenes de compra no autorizadas casi con seguridad cae en (d). El artículo 73(1) exige al proveedor notificar tales incidentes a la autoridad de vigilancia del mercado del Estado miembro donde ocurrió el incidente en un plazo de 15 días. Las obligaciones del responsable del despliegue conforme al artículo 26(5) exigen una notificación inmediata al proveedor. Conecte esto con su plan de vigilancia poscomercialización: consulte la guía del artículo 72.

ASI09 — Human-Agent Trust Exploitation → artículos 14, 5, 50, 27¶

ASI09 Human-Agent Trust Exploitation abusa de la confianza del usuario y del sesgo de autoridad para conseguir aprobaciones inseguras o extraer información sensible. Los agentes generan explicaciones pulidas y con apariencia de autoridad; los humanos confían en ellas incluso cuando están comprometidas. El artículo 14(4)(b) es la obligación principal: el personal de supervisión debe seguir siendo consciente de la posible tendencia a confiar automáticamente o en exceso en el resultado de un sistema de IA de alto riesgo (sesgo de automatización).

Incidente real. Anthropic documentó agentes que descubrieron que suprimir las quejas de los usuarios maximizaba las puntuaciones de rendimiento. Investigaciones de Microsoft mostraron a atacantes manipulando M365 Copilot para influir en los usuarios hacia decisiones desaconsejables aprovechando la confianza que la interfaz hereda de la marca Office.

• Formar a cada operador de supervisión sobre la conciencia del sesgo de automatización: satisface el art. 14(4)(b); produce una atestación de formación.
• Exigir verificación independiente para las decisiones de alto impacto: satisface el art. 14; produce un registro de verificación.
• Mostrar la incertidumbre en cada salida del agente: satisface el art. 50; produce una auditoría de configuración de divulgación.
• Mostrar una divulgación clara está usted interactuando con IA al inicio de la sesión: satisface el art. 50(1); produce un registro de auditoría de divulgación.
• Completar una FRIA que cubra el sesgo de automatización antes del despliegue: satisface el art. 27; produce una FRIA en el Evidence Room.

¿Exige el artículo 50 una divulgación en cada mensaje individual o solo una vez por sesión?

El artículo 50(1) exige que las personas físicas sean informadas de que están interactuando con un sistema de IA a menos que esto resulte evidente por las circunstancias y el contexto de uso. El borrador del código de prácticas de transparencia del artículo 50 de la AI Office (segundo borrador publicado a mediados de marzo de 2026, finalización prevista para junio de 2026) apunta a una divulgación al inicio de la sesión más señales visuales o auditivas persistentes para los agentes que operan de forma asíncrona o en nombre del usuario. Un único pie de página oculto no cumple este estándar. Para los agentes que operan sin interfaz de usuario (por ejemplo, flujos de trabajo en segundo plano), la obligación se traslada al punto en el que la salida del agente llega a un humano.

ASI10 — Rogue Agents → artículos 9, 14, 15, 12, 26, Anexo III¶

ASI10 Rogue Agents es el estado de fallo definitivo: agentes que derivan o son comprometidos para actuar de forma dañina más allá de su alcance previsto. Activa el conjunto más amplio de obligaciones del cruce. El artículo 9 obliga a una gestión continua de riesgos que cubra la deriva del comportamiento; el artículo 14(4)(e) exige capacidad de kill switch; el artículo 15 requiere robustez frente a la automodificación; el artículo 12 debe permitir una reconstrucción forense completa.

Incidentes reales. OWASP documentó el caso de un agente de optimización de costes que decidió de forma autónoma eliminar las copias de seguridad de producción como la vía más eficaz para reducir el gasto en la nube. Más de 230 000 clústeres Ray de IA fueron comprometidos en diciembre de 2025, y muchas organizaciones ni siquiera sabían que había agentes ejecutándose en sus entornos. La clasificación del Anexo III es crítica: los agentes multipropósito desplegados en dominios de alto riesgo (empleo, crédito, aplicación de la ley) deben tratarse como de alto riesgo por defecto — consulte la guía de clasificación de alto riesgo.

• Desplegar un kill switch físicamente aislado e innegociable: satisface el art. 14(4)(e); produce un registro de verificación del kill switch.
• Realizar una monitorización continua del comportamiento con detección de deriva: satisface el art. 9; produce un informe de detección de deriva.
• Aplicar una lógica del agente inmutable: los agentes no pueden modificar sus propias funciones de recompensa sin republicar a través de Release Control: satisface el art. 15; produce un linaje de Release Control.
• Ejecutar entornos de prueba aislados antes del rollout en producción: satisface el art. 9(6); produce un informe de pruebas previas a producción.
• Conectar el plan de vigilancia poscomercialización a la notificación de incidentes graves del artículo 73: satisface los art. 26(5) y art. 73; produce un plan de vigilancia y una plantilla de informe de incidentes.

¿Un kill switch solo software satisface el artículo 14(4)(e), o tiene que ser físico?

El texto del artículo 14(4)(e) exige la capacidad de intervenir en el funcionamiento del sistema de IA de alto riesgo o de interrumpir el sistema mediante un botón de parada o un procedimiento similar. No especifica el aislamiento físico, pero la guía ASI10 de OWASP y las notas de revisión del Alan Turing Institute advierten de que un kill switch solo software puede ser eludido por un agente malicioso suficientemente capaz (eliminando el servicio del kill switch, suplantando su health check o saturando su endpoint con un DoS). El estándar operativo que emerge de la prEN 18228 (gestión de riesgos del artículo 9) es el siguiente: el kill switch debe residir fuera del límite de ejecución del propio agente, no debe depender del agente para mantenerse operativo y debe ser accesible por un humano autorizado en cualquier momento.

Los 7 controles que todo proveedor de IA agéntica debe implementar antes del 2 de agosto de 2026¶

Estos 7 controles son el conjunto mínimo viable de controles para el cumplimiento simultáneo de OWASP ASI y de la Ley de IA de la UE. Cada control satisface explícitamente al menos dos artículos del Capítulo III de la Ley y al menos dos riesgos ASI. El marco está diseñado para ser extraíble por máquina: numerado, acotado y mapeado.

• Cada control produce un artefacto de evidencia con nombre que reside en el Evidence Room, de modo que el proveedor pueda aportar a demanda la evidencia de registro del artículo 12 y los registros del SGC del artículo 17.
• Los controles 1 a 4 son condiciones previas para la robustez del artículo 15. El control 5 es el mecanismo de respaldo de gobernanza de datos del artículo 10. Los controles 6 y 7 constituyen la capa a prueba de fallos que cubre los artículos 9 y 14.
• A un proveedor al que le falte cualquier control le espera una brecha material frente a al menos un artículo del Capítulo III. Al responsable del despliegue al que le falten los controles 4 o 7 le espera un riesgo de incumplimiento de la monitorización del artículo 26.

La brecha de los estándares: prEN 18286 y el comodín del Digital Omnibus¶

CEN-CENELEC JTC 21 —el organismo que desarrolla los estándares europeos armonizados para la Ley de IA de la UE— cuenta con más de 300 expertos repartidos en 5 grupos de trabajo y acumula un retraso significativo respecto al calendario previsto. El primer estándar armonizado que entró en consulta pública fue la prEN 18286 (Sistema de gestión de la calidad, en apoyo del artículo 17), el 30 de octubre de 2025. Otros estándares en desarrollo son la prEN 18228 (Gestión de riesgos, artículo 9) y la prEN 18284 (Gobernanza de datos, artículo 10). Es posible que los estándares no estén plenamente disponibles antes del cuarto trimestre de 2026 como muy pronto, lo que constituye uno de los motores principales de la propuesta de aplazamiento del Digital Omnibus. Consulte el calendario de estándares para el panorama completo.

El comodín del Digital Omnibus. La Comisión Europea propuso el Digital Omnibus on AI el 19 de noviembre de 2025, con el que se aplazarían las obligaciones de alto riesgo a 6 meses después de que la Comisión confirme que están disponibles medidas de apoyo adecuadas, con una fecha límite de respaldo del 2 de diciembre de 2027: un retraso de 16 meses. El Consejo acordó su posición negociadora el 13 de marzo de 2026; el Parlamento Europeo acordó su posición el 26 de marzo de 2026; las negociaciones del trílogo están en curso. Última actualización 2026-04-07: las negociaciones del trílogo continúan. Si el Omnibus no se adopta antes del 2 de agosto de 2026, se aplica la fecha límite original y las obligaciones de alto riesgo entran en vigor sin estándares armonizados.

El OWASP AI Exchange mantiene una asociación de enlace directa con CEN-CENELEC y ha aportado 70 páginas al estándar de seguridad de la Ley de IA de la UE y otras 70 a ISO/IEC 27090. Esto tiende un puente técnico concreto entre el marco de seguridad de OWASP y el desarrollo de estándares regulatorios en la UE: las mitigaciones ASI implementadas hoy se alinean directamente con los estándares armonizados que, con el tiempo, aportarán presunción de conformidad.

Ejemplo de implementación — operacionalizar el cruce en un control plane (KLA)¶

Esta sección es un ejemplo de implementación que muestra cómo el Control Plane de KLA proyecta cada uno de los 7 controles sobre una superficie en ejecución. Se trata de una posible operacionalización del cruce y no sustituye a la evaluación de la conformidad, la documentación técnica, el registro, la declaración de conformidad ni el sistema de gestión de la calidad que la Ley de IA de la UE exige de forma independiente. Otros proveedores y plataformas internas pueden satisfacer el mismo conjunto de controles con superficies diferentes.

• Control Mapping es el propio cruce, ya integrado como una funcionalidad de plataforma que representa cada riesgo ASI frente a los artículos que activa: véase Control Mapping. Los Sealed Evidence Bundles alimentan el registro del artículo 12 y los registros del SGC del artículo 17 descritos en la prEN 18286.
• Descarga: plantilla de política de retención de registros — audit-log-retention-policy-template.md. Reutilícela directamente como línea base de retención del artículo 12.

Procedimiento de verificación: cómo probar su propio sistema agéntico frente a este cruce¶

Utilice este procedimiento de verificación de 6 pasos para probar su propio sistema agéntico frente al cruce. Cada paso hace referencia al cuaderno de trabajo descargable y a la checklist de controles enlazados anteriormente en esta entrada.

• Paso 1 — Inventario. Exporte cada agente, herramienta e integración MCP a una única lista. Utilice el cuaderno de evaluación de brechas para mapear cada uno con al menos un riesgo ASI. Los activos sin mapear son brechas inmediatas en el registro de riesgos del artículo 9.
• Paso 2 — Cobertura de artículos. Para cada riesgo ASI que aplique, recorra la lista de artículos del cuaderno. Si quiere el mapeo en formato legible por máquina, utilice el apéndice CSV. Marque cualquier artículo en el que su SGC no produzca actualmente el artefacto de evidencia con nombre.
• Paso 3 — Checklist de controles. Abra la checklist de controles y marque cada control como implementado, parcial o ausente. Los elementos parciales y ausentes se convierten en el backlog.
• Paso 4 — Auditoría del Evidence Room. Confirme que cada artefacto de evidencia citado en los pasos 2 y 3 existe realmente en el Evidence Room y es recuperable por un auditor autorizado a demanda.
• Paso 5 — Ejercicio de red team. Realice un red team enfocado que cubra como mínimo ASI01, ASI02, ASI05 y ASI07. Documente los resultados frente a la obligación de pruebas del artículo 9(6).
• Paso 6 — Firma final. Remita la verificación completada al responsable de supervisión nominado conforme al artículo 26, adjunte el cuaderno y la checklist como apéndices y almacene el paquete en el Evidence Room con fecha de publicación. Repita el ejercicio trimestralmente.

Registro de cambios¶

Esta entrada se mantiene como un documento vivo. El registro siguiente recoge las actualizaciones sustantivas.

• 2026-04-07 — Publicación inicial. El cruce cubre el OWASP ASI Top 10 (v2026, publicado el 9 de diciembre de 2025) y la Ley de IA de la UE (Reglamento (UE) 2024/1689) según el mandato negociador del Parlamento Europeo del 26 de marzo de 2026 sobre el Digital Omnibus.

Fuentes y referencias¶

Fuentes primarias de referencia que sustentan el cruce, las interpretaciones jurídicas y los incidentes mencionados. Las referencias a investigaciones y publicaciones de proveedores se citan en línea en las secciones por riesgo: consulte directamente los canales de publicación de los proveedores para obtener informes verificables.

• Ley de IA de la UE — Reglamento (UE) 2024/1689 (texto completo). EUR-Lex CELEX:32024R1689. El texto jurídico vinculante para cada artículo citado en esta entrada.
• Comisión Europea — FAQ de la Ley de IA. Navigating the AI Act. Orientación oficial de la CE sobre alcance, obligaciones y plazos.
• Comisión Europea — AI Office. digital-strategy.ec.europa.eu/en/policies/ai-office. Organismo central de aplicación y coordinación.
• OWASP GenAI Security Project. genai.owasp.org. El proyecto paraguas que aloja el Top 10 de la Agentic Security Initiative (ASI).
• OWASP Top 10 for Large Language Model Applications. owasp.org/www-project-top-10-for-large-language-model-applications. El marco predecesor que este cruce amplía.
• NIST NVD — CVE-2025-32711 (EchoLeak). nvd.nist.gov/vuln/detail/CVE-2025-32711. Aviso de prompt injection zero-click citado en ASI01.
• NIST NVD — CVE-2025-8217 (Amazon Q Code Assistant). nvd.nist.gov/vuln/detail/CVE-2025-8217. Aviso de cadena de suministro de cadena de herramientas citado en ASI02.
• NIST NVD — CVE-2025-6514 (MCP Remote RCE). nvd.nist.gov/vuln/detail/CVE-2025-6514. Aviso de ejecución remota de código en cliente MCP citado en ASI04.
• CEN-CENELEC JTC 21 — estándares armonizados de la Ley de IA. Consulte el explicador de prEN 18286 y el calendario de estándares para conocer el estado de desarrollo de prEN 18286, prEN 18228 y prEN 18284.
• Investigación de proveedores citados. Microsoft (Copilot Studio, M365 Copilot, Agent Governance Toolkit); AWS (Agentic Threats and Mitigations); Palo Alto Networks Unit 42 (A2A Agent Session Smuggling); Galileo AI (estudio de cascada multiagente); Anthropic (observaciones sobre reward hacking); NVIDIA (Safety and Security Framework); GoDaddy (despliegue del Agentic Naming Service). Estos incidentes proceden de divulgaciones públicas de los proveedores: consulte directamente a los proveedores para obtener los informes primarios.