La taxonomía de riesgos de agentes de IA: 12 riesgos que toda empresa debe seguir

19 de abril de 2026 · 11 min de lectura

Los agentes de IA necesitan una taxonomía de riesgos por una razón sencilla: no
solo generan texto. Pueden usar herramientas, acceder a datos, recordar contexto,
llamar API, delegar trabajo y activar procesos de negocio.

Eso cambia la pregunta de gobernanza empresarial de:

¿La salida del modelo es aceptable?

A:

¿Qué estaba autorizado a hacer el agente, qué hizo realmente, qué control
falló, quién aprobó el riesgo y podemos demostrarlo?

Este artículo empieza con una taxonomía práctica de 12 riesgos. Después amplía
esa lista hacia una visión empresarial más completa, agrupada por control de
acceso, mal uso de herramientas, gobernanza, privacidad, calidad de salida,
comportamiento del agente y fiabilidad/observabilidad.

Lo importante es la disciplina de fuentes. Algunos riesgos vienen directamente
de marcos, leyes, regulaciones o estándares reconocidos. Otros son indicadores
de riesgo de investigación de seguridad, literatura de seguridad de IA o patrones
de incidentes. Son útiles, pero no deben presentarse como requisitos legales si
ninguna ley, regulación o estándar lo exige.

La versión corta

Toda empresa que despliegue agentes de IA debería seguir estos 12 riesgos:

Esta lista es intencionadamente práctica. Es la checklist que un responsable de
negocio, líder de seguridad, equipo de cumplimiento o arquitecto de IA puede usar
antes de producción.

Pero la taxonomía empresarial completa es más amplia.

La taxonomía empresarial ampliada

Una taxonomía más completa agrupa los riesgos de IA agéntica en siete dominios.

Esta estructura encaja mejor con la forma en que las empresas gobiernan sistemas.
Seguridad reconoce control de acceso y herramientas. Privacidad reconoce
exposición y retención de datos. Cumplimiento reconoce responsabilidad y
evidencia. Ingeniería reconoce fiabilidad y observabilidad.

La taxonomía no es útil porque cree cajas perfectas. Es útil porque permite a
los equipos hacer la misma pregunta operativa:

¿Qué control de negocio falla si este agente se comporta mal?

Base de referencia

La taxonomía se apoya en estas fuentes:

• OWASP Agentic AI - Threats and Mitigations, Version 1.1, diciembre de 2025. Es la fuente directa más fuerte para amenazas específicas de agentes como memory poisoning, tool misuse, goal manipulation, untraceability, identity compromise, riesgos multiagente y human manipulation. La guía actual lista T1-T17; resúmenes antiguos pueden referirse a T1-T15.
• OWASP Top 10 for Large Language Model Applications 2025, especialmente Prompt Injection, Sensitive Information Disclosure, Supply Chain Vulnerabilities, Excessive Agency, Overreliance y Unbounded Consumption.
• NIST AI Risk Management Framework 1.0, que estructura la gobernanza del riesgo de IA con Govern, Map, Measure y Manage.
• NIST AI RMF Generative AI Profile, NIST AI 600-1, que nombra riesgos de IA generativa como confabulation, harmful bias, data privacy, information integrity, human-AI configuration e integración de componentes.
• MITRE ATLAS, base de conocimiento sobre tácticas y técnicas adversarias contra sistemas habilitados por IA.
• EU AI Act, Regulation (EU) 2024/1689, especialmente requisitos de sistemas de alto riesgo: gestión de riesgos, gobernanza de datos, documentación técnica, logging, transparencia, supervisión humana, precisión, robustez, ciberseguridad, post-market monitoring y obligaciones de deployers.
• GDPR, Regulation (EU) 2016/679, especialmente artículos 5, 32, 33 y 35 cuando los agentes procesan datos personales.
• ISO/IEC 42001:2023, estándar de sistema de gestión de IA, útil para gobernanza, responsabilidades, políticas, gestión de riesgos y mejora continua.
• NIST Cybersecurity Framework 2.0, especialmente resultados Govern y Protect para identidad, acceso, cadena de suministro, monitoreo y gestión de riesgos.

Cuando el artículo menciona preocupaciones frontier como autorreplicación,
resistencia al apagado o adquisición autónoma de recursos, trátalas como
indicadores sistémicos de investigación de seguridad de IA y evaluaciones de
sistemas avanzados, salvo que tu sistema concreto tenga realmente esas capacidades.

1. Riesgo de autonomía

El riesgo de autonomía es el riesgo de que un agente actúe sin suficiente
supervisión humana para el nivel de impacto.

Esta es la diferencia definitoria entre un asistente de IA y un agente de IA. Un
chatbot puede dar una mala respuesta. Un agente de workflow autónomo puede dar
una mala respuesta y actuar sobre ella.

Seguir:

• ¿Puede el agente actuar desde un trigger o evento de fondo?
• ¿Puede completar tareas de varios pasos sin aprobación paso a paso?
• ¿Puede afectar clientes, empleados, registros financieros, contratos,
  infraestructura, seguridad o procesos regulados?
• ¿Puede un humano interrumpir, pausar, anular o revertir la acción?

Base de fuente:

• El EU AI Act exige supervisión humana para sistemas de IA de alto riesgo en el artículo 14.
• NIST AI RMF exige gobernar, mapear, medir y gestionar riesgos de IA en contexto.
• OWASP Agentic AI analiza autonomía, planificación, comportamiento desalineado
  y sobrecarga del human-in-the-loop como patrones de amenaza.

2. Riesgo de herramientas

El riesgo de herramientas es el riesgo de que un agente use mal herramientas
internas o externas.

Las herramientas incluyen API, bases de datos, navegadores, email, ejecución de
código, acciones CRM, automatizaciones de workflow, ticketing, archivos, pagos y
herramientas de seguridad.

Seguir:

• ¿Qué herramientas puede llamar el agente?
• ¿Son llamadas de solo lectura o pueden escribir?
• ¿Puede el modelo elegir parámetros de herramientas?
• ¿Puede la salida de una herramienta convertirse en nuevo contexto de instrucción?
• ¿Las herramientas de alto impacto están protegidas por política y aprobación humana?

Base de fuente:

• OWASP Agentic AI incluye directamente mal uso de herramientas, ataques de
  ejecución de código y abuso de protocolos interagente.
• OWASP LLM Top 10 incluye Excessive Agency e Insecure Output Handling.
• NIST CSF 2.0 aporta vocabulario de controles para acceso, protección,
  detección, respuesta y recuperación.

3. Riesgo de permisos

El riesgo de permisos es el riesgo de que el agente pueda acceder o hacer más de
lo que debería.

Los agentes suelen usar permisos heredados del usuario, scopes OAuth delegados,
cuentas de servicio, identidades de conectores o permisos de plataforma. Eso
crea riesgo clásico de control de acceso con una forma nueva.

Seguir:

• ¿El agente usa una identidad nombrada?
• ¿Tiene acceso de mínimo privilegio?
• ¿Usa credenciales compartidas o cuentas de servicio amplias?
• ¿Puede ejecutar acciones que el usuario solicitante no podría ejecutar directamente?
• ¿Puede cruzar tenants, departamentos, entornos o fronteras de confianza?

Amenazas específicas incluyen privilege escalation, credential theft y confused deputy.

Base de fuente:

• OWASP Agentic AI cubre identity compromise, spoofing, confused deputy y riesgos de autorización.
• NIST CSF PR.AA cubre gestión de identidad, autenticación y control de acceso.
• GDPR artículo 32 importa cuando permisos excesivos exponen datos personales.

4. Riesgo de prompt injection

El riesgo de prompt injection es el riesgo de que el agente siga instrucciones
maliciosas, ocultas, contradictorias o no confiables.

Para agentes, prompt injection es más peligrosa que una mala respuesta porque el
agente puede convertir la instrucción maliciosa en acción.

Seguir:

• ¿El agente lee emails, páginas web, tickets, PDF, documentos o chats no confiables?
• ¿Los documentos recuperados se mezclan en el mismo contexto que instrucciones de sistema?
• ¿Un usuario, cliente, proveedor o atacante puede influir argumentos de herramientas?
• ¿Las llamadas de herramientas están restringidas por política fuera del modelo?

Base de fuente:

• OWASP LLM Top 10 lista Prompt Injection como riesgo central de aplicaciones LLM.
• OWASP Agentic AI lo extiende a tool misuse, goal manipulation y agent-communication poisoning.
• Muchas advertencias de prompt injection vienen de investigación de seguridad y
  reportes de campo. Trátalas como evidencia de riesgo, no como requisitos legales por sí solas.

5. Riesgo de memoria

El riesgo de memoria es el riesgo de que un agente almacene, filtre, envenene o
reutilice contexto de forma inapropiada.

La memoria hace más útiles a los agentes. También crea una capa persistente que
atacantes y accidentes pueden explotar.

Seguir:

• ¿Qué recuerda el agente?
• ¿Quién puede escribir en memoria?
• ¿Quién puede leer memoria?
• ¿La memoria puede influir el uso futuro de herramientas?
• ¿La memoria se elimina cuando expira el propósito original?
• ¿Se filtra información sensible antes de almacenarla?

Amenazas específicas incluyen memory poisoning y filtración de largo plazo de
contexto personal, confidencial o privilegiado.

Base de fuente:

• OWASP Agentic AI incluye Memory Poisoning como amenaza nombrada.
• NIST AI 600-1 cubre riesgos de data privacy e information integrity.
• GDPR artículos 5 y 32 aplican cuando datos personales se almacenan, retienen o reutilizan.

6. Riesgo de exposición de datos

El riesgo de exposición de datos es el riesgo de que el agente recupere, revele,
resuma, transforme o transmita datos sensibles de forma insegura.

El agente quizá no filtre una tabla de base de datos directamente. Puede resumir
partes sensibles en un chat, borrador de email, ticket de soporte, archivo
exportado o payload API.

Seguir:

• ¿A qué fuentes de datos puede acceder el agente?
• ¿Qué datos puede combinar?
• ¿Puede mover datos a canales con menor protección?
• ¿Puede enviar datos a herramientas de terceros o usuarios externos?
• ¿Hay datos personales, credenciales, contratos, código fuente, RR. HH.,
  finanzas o logs de seguridad en alcance?

Base de fuente:

• OWASP LLM Top 10 incluye Sensitive Information Disclosure.
• OWASP Agentic AI incluye escenarios de exfiltración vía herramientas, rogue
  agents y sistemas multiagente.
• GDPR artículos 5, 32 y 33 aplican donde se procesan o vulneran datos personales.
• EU AI Act artículo 10 aplica a gobernanza de datos para sistemas de IA de alto riesgo.

7. Riesgo de planificación

El riesgo de planificación es el riesgo de que un agente cree un plan de varios
pasos defectuoso que parece razonable localmente pero falla globalmente.

No es solo alucinación. Un plan puede tener pasos individualmente plausibles y
seguir violando políticas, perder dependencias, crear coste, sobrecargar un
equipo o activar el proceso equivocado.

Seguir:

• ¿Puede el agente descomponer objetivos en subobjetivos?
• ¿Puede revisar planes según outputs intermedios?
• ¿Optimiza terminar la tarea sobre política, seguridad, presupuesto o límites de negocio?
• ¿Los planes se revisan antes de ejecución de alto impacto?

Base de fuente:

• OWASP Agentic AI incluye intent breaking, goal manipulation y comportamiento
  desalineado o engañoso.
• NIST AI 600-1 cubre confabulation, information integrity y human-AI configuration.
• EU AI Act artículos 9, 13 y 14 importan en sistemas de alto riesgo porque risk
  management, transparencia y supervisión humana deben diseñarse en el sistema.

8. Riesgo de delegación

El riesgo de delegación es el riesgo de que el agente entregue trabajo a otros
agentes, tareas, herramientas o workflows sin control claro.

Los sistemas multiagente dificultan la responsabilidad. Un agente coordinador
puede crear una tarea, un especialista llamar una herramienta, otro resumir el
resultado y un cuarto comunicarse con el usuario.

Seguir:

• ¿Qué agentes pueden comunicarse?
• ¿Las identidades de agentes están autenticadas?
• ¿Los mensajes están firmados, acotados, logueados y filtrados?
• ¿Un agente puede hacer que otro exceda su autoridad?
• ¿Quién posee el workflow end-to-end?

Base de fuente:

• OWASP Agentic AI incluye agent communication poisoning, rogue agents in
  multi-agent systems, human attacks on multi-agent systems e insecure inter-agent protocol abuse.
• EU AI Act artículo 25 es relevante para responsabilidades a lo largo de la cadena de valor de IA.
• ISO/IEC 42001 es relevante para responsabilidades de sistema de gestión y controles de ciclo de vida.

9. Riesgo de observabilidad

El riesgo de observabilidad es el riesgo de que la organización no pueda
reconstruir lo ocurrido.

Para agentes, los logs del output final no bastan. Se necesita la traza
operativa: trigger, usuario, versión de instrucciones, retrievals, llamadas a
herramientas, argumentos, decisiones de política, aprobaciones, outputs,
acciones, errores, reintentos y handoffs.

Seguir:

• ¿Los equipos de incidente pueden reconstruir toda la ejecución?
• ¿Se registran llamadas a herramientas y argumentos?
• ¿Se registran aprobaciones?
• ¿Se registran denegaciones de política?
• ¿Puede detectarse comportamiento anómalo?
• ¿Existe kill switch o procedimiento de pausa?

Base de fuente:

• OWASP Agentic AI incluye Repudiation and Untraceability.
• EU AI Act incluye logging, documentación técnica, monitoring, post-market
  monitoring y acciones correctivas para sistemas de alto riesgo.
• NIST AI RMF y NIST CSF apoyan medición, monitoreo, respuesta y recuperación como funciones de gestión de riesgo.

10. Riesgo de responsabilidad

El riesgo de responsabilidad es el riesgo de que nadie posea claramente
decisiones, aprobaciones, operación, incidentes o remediación.

Este riesgo es fácil de perder porque un agente puede estar entre equipos.
Producto posee el caso de uso. IT posee el conector. Seguridad posee access
control. Legal posee la política. Un proveedor posee la plataforma. El negocio
posee el resultado.

Seguir:

• ¿Quién es business owner?
• ¿Quién es technical owner?
• ¿Quién aprueba producción?
• ¿Quién aprueba categorías de acción de alto impacto?
• ¿Quién maneja incidentes?
• ¿Quién acepta riesgo residual?

Base de fuente:

• EU AI Act artículos 16-27 definen responsabilidades de provider, importer,
  distributor, deployer y otros roles de la cadena de valor.
• ISO/IEC 42001 exige accountability de sistema de gestión y mejora continua.
• La función Govern de NIST AI RMF enfatiza roles, políticas, procesos y oversight.

11. Riesgo de cumplimiento

El riesgo de cumplimiento es el riesgo de que el agente viole requisitos
legales, regulatorios, contractuales, sectoriales o internos.

No es solo una pregunta de AI Act. Según el caso de uso, el riesgo de agentes
puede tocar privacidad, derecho laboral, servicios financieros, salud, protección
al consumidor, ciberseguridad, contratos, retención de registros, regulación
sectorial y política interna.

Seguir:

• ¿El caso de uso es de alto riesgo o regulado?
• ¿El agente procesa datos personales?
• ¿Afecta derechos, acceso, empleo, crédito, educación, salud, safety, security o resultados legales?
• ¿Hay documentación para gestión de riesgo, testing, monitoring, supervisión humana e incident response?
• ¿Se cumplen obligaciones de transparencia?

Base de fuente:

• EU AI Act artículos 9-15, 17-20, 26-27 y 50 son especialmente relevantes para
  obligaciones high-risk y transparencia.
• GDPR artículos 5, 32, 33 y 35 importan cuando hay datos personales.
• ISO/IEC 42001 y NIST AI RMF aportan estructuras de gobernanza y evidencia.

12. Riesgo de proceso de negocio

El riesgo de proceso de negocio es el riesgo de que el agente cause daño
operativo directo.

Aquí la gobernanza de agentes se vuelve real. Una mala respuesta es un problema.
Una mala respuesta que cierra un caso de cliente, aprueba un reembolso, cambia un
registro de empleado, modifica infraestructura, escribe a un regulador o
actualiza un workflow legal es otra cosa.

Seguir:

• ¿Qué proceso puede afectar el agente?
• ¿La acción puede revertirse?
• ¿El agente puede operar a escala?
• ¿Puede actuar fuera de horario laboral?
• ¿Puede influir humanos que toman decisiones consecuenciales?
• ¿El proceso tiene controles existentes que el agente evita?

Base de fuente:

• OWASP Agentic AI incluye human manipulation, overwhelming the human in the
  loop, misaligned behavior y tool misuse.
• NIST AI 600-1 cubre human-AI configuration, confabulation, harmful bias e information integrity.
• EU AI Act artículos 14 y 26 importan cuando el agente es parte de un despliegue
  high-risk y aplican supervisión humana u obligaciones del deployer.

Amenazas específicas para incluir en el registro

Los 12 riesgos son el lenguaje empresarial simple. Un registro de riesgos también
debe seguir la clase de amenaza más específica.

Qué deben seguir las empresas

El paso práctico es seguir ambos:

1. La clase de amenaza.
2. El control de negocio que falla.

Por ejemplo:

• "Prompt injection" es una clase de amenaza.
• "El agente de soporte puede emitir reembolsos sin validación de política" es
  un control de negocio fallido.

Esa segunda frase vuelve operativa la taxonomía.

Como mínimo, cada entrada del registro debe capturar:

• Nombre y owner del agente
• Proceso de negocio
• Nivel de agente y nivel de autonomía
• Herramientas, fuentes de datos, memorias y agentes delegados
• Dominio de riesgo y clase de amenaza específica
• Fuente de referencia
• Escenario de amenaza
• Control faltante o fallido
• Scores de probabilidad, impacto, autonomía, sensibilidad de datos, criticidad
  de herramientas y brecha de observabilidad
• Puntos de aprobación humana requeridos
• Ubicación de evidencia
• Owner del riesgo residual
• Trigger de revisión y próxima fecha

Vigilar indicadores sistémicos

La mayoría de los agentes empresariales actuales no tiene autonomía frontier.
Aun así, algunos indicadores sistémicos merecen seguimiento porque muestran
cuándo un agente de workflow ordinario puede derivar hacia una categoría más peligrosa.

Vigila:

• Persecución de objetivos no intencionada
• Escalada de privilegios no autorizada
• Adquisición autónoma de recursos
• Intentos de preservar acceso o resistir apagado
• Autorreplicación o creación no autorizada de agentes
• Bucles de desinformación multiagente
• Tormentas de reintentos, llamadas repetidas a herramientas, picos de coste o agotamiento de cuota
• Nuevas vías inesperadas de exfiltración de datos

Estos indicadores no vienen todos de un único marco legal. Es mejor entenderlos
como señales de riesgo de investigación de seguridad de IA, pruebas adversarias
y evaluaciones de agentes avanzados. Si aparecen en un sistema empresarial real,
deben activar una revisión inmediata.

La regla práctica

No te quedes en "este agente tiene riesgo de autonomía" o "este agente tiene
riesgo de prompt injection".

Escribe la versión operativa:

Este agente puede leer emails de proveedores, extraer cambios de contrato y
enrutar aprobaciones. Un email malicioso de un proveedor podría inyectar
instrucciones que hagan que el agente clasifique mal un cambio contractual y
evite la revisión legal.

Ahora puedes gobernarlo.

Puedes asignar un owner. Puedes exigir un control. Puedes probar el fallo.
Puedes registrar evidencia. Puedes decidir si el riesgo residual es aceptable.

Para eso sirve una taxonomía de riesgos de agentes.

Recurso práctico

El framework complementario en GitHub incluye:

• AI Agent Risk Taxonomy
• Risk Scoring Model
• Risk Register Template CSV

Usa la taxonomía para nombrar el riesgo. Usa el registro para asignar ownership.
Usa el modelo de scoring para decidir qué controles deben existir antes de producción.