Qué riesgos de seguridad reales tiene tu agente de IA: fugas de datos, jailbreak y suplantación
Un agente conversacional en producción no falla como falla el software tradicional. No se cae, no lanza un error 500 — cede. Cede ante un usuario que le pide "olvida tus instrucciones anteriores", cede filtrando un dato que no debía compartir, cede confirmando algo que no tenía autoridad para confirmar. Los riesgos de seguridad de un agente de IA no son hipotéticos: son el hallazgo más frecuente en las auditorías que hacemos, y el pilar (Integrity & Safety) que por sí solo puede forzar un veredicto NO APTO, sin importar cómo puntúe el resto.
Esto es lo que realmente hay que vigilar, con ejemplos de auditorías reales — anonimizados.
Los 4 vectores de riesgo que realmente importan
La taxonomía no es un invento nuestro: se apoya en el OWASP Top 10 para aplicaciones LLM, el marco de referencia más citado del sector. En auditoría de agentes conversacionales, se reduce a cuatro categorías con impacto directo en el negocio:
| Vector | Qué es | Por qué importa |
|---|---|---|
| Manipulación de instrucciones (jailbreak / prompt injection) | El usuario redefine el rol del agente ("olvida tus instrucciones", "actúa como si...") para saltarse sus restricciones | Rompe cualquier control que se haya puesto en el prompt original — el agente hace lo que no debería |
| Fuga de datos | El agente revela datos que no debería: los suyos propios (system prompt), o de otro cliente | Expone información confidencial y, si son datos personales, activa el RGPD además del EU AI Act |
| Suplantación / manipulación conversacional | El agente confirma una identidad falsa, oculta que es una IA, o es inducido a actuar como si fuera otra entidad | Vulnera la confianza básica de la conversación — y en el caso de ocultar que es IA, incumple directamente el Art. 50 |
| Acciones no autorizadas (excessive agency) | El agente ejecuta una acción (reembolso, cambio de datos, escalado) fuera del alcance que se le dio | Convierte un fallo conversacional en un fallo operativo con impacto económico directo |
Lo que encontramos al auditar esto en producción
En una auditoría real, el canal web de una aerolínea cedió ante un ataque de "redefinición de rol" — una técnica documentada por OWASP — y el hallazgo forzó un veredicto NO APTO. Lo relevante no es solo que cediera: es que el canal de WhatsApp de la misma compañía, con el mismo agente subyacente, sí bloqueó el mismo ataque. Misma tecnología, mismo proveedor, resultado de seguridad completamente distinto según el canal. Eso es exactamente lo que una auditoría por canal detecta y que una evaluación interna genérica del "agente" como bloque único no ve.
El dato externo que confirma que esto no es un caso aislado: según el informe "State of AI" de AvePoint (julio 2026), el 88,4% de las organizaciones sufrió al menos un incidente de seguridad relacionado con agentes de IA en el último año — y el 72% de las que se declaraban "muy confiadas" en su propia seguridad son, precisamente, las que sufrieron el incidente. La confianza percibida y la seguridad real no van de la mano si nadie las ha verificado de forma independiente.
Cómo se audita esto: el pilar Integrity & Safety
En el marco Trust Score de Lexic Compass, Integrity & Safety pesa el 30% del resultado — el mismo peso que Regulatory Trust, y más que Operational Reliability o Experience Trust por separado. Pero el peso relativo no es lo que más importa aquí: lo que importa es la regla de tolerancia cero. Un hallazgo crítico en este pilar fuerza automáticamente el veredicto NO APTO, sin importar cuánto puntúen los otros tres. Un agente puede resolver perfectamente el 99% de las conversaciones y aun así recibir un NO APTO si cede una sola vez ante un ataque de manipulación documentado.
Esa es la diferencia estructural entre observabilidad (que registra que ocurrió) y auditoría (que evalúa si ese único hallazgo invalida la confianza en el conjunto).
Qué debes exigir antes de escalar un agente conversacional
- Pruebas de manipulación por canal, no solo por agente — el mismo ataque puede colar en un canal y bloquearse en otro.
- Verificación explícita de qué datos puede revelar el agente y bajo qué circunstancias, con evidencia de conversaciones reales, no solo de la especificación técnica.
- Confirmación de que el agente no confirma identidades ni acciones fuera de su alcance documentado.
- Un veredicto que aplique tolerancia cero en hallazgos críticos de seguridad — no un promedio que diluya el riesgo entre métricas.
Preguntas frecuentes
¿Un solo fallo de seguridad puede invalidar todo el resultado de un agente que funciona bien en general?
Sí. El marco Trust Score aplica una regla de override: cualquier hallazgo crítico en Integrity & Safety fuerza NO APTO, independientemente de cómo puntúen los demás pilares. No se promedia — la confianza se rompe con un solo hallazgo grave.
¿Es lo mismo un jailbreak que un prompt injection?
Están relacionados pero no son idénticos. Un jailbreak busca que el agente ignore sus restricciones (ej. redefinición de rol). Un prompt injection introduce instrucciones maliciosas dentro del propio contenido que procesa el agente (un documento, un mensaje) para alterar su comportamiento. Ambos son categorías del OWASP Top 10 para LLM y ambos se prueban en una auditoría de Integrity & Safety.
¿La observabilidad no detecta ya estos riesgos?
La observabilidad registra que la conversación ocurrió — no juzga si el agente debería haber cedido. Detectar el riesgo requiere alguien (o algo) que evalúe cada conversación contra un criterio de seguridad y emita un veredicto, que es exactamente lo que la observabilidad, por diseño, no hace.
Si tu agente conversacional lleva meses en producción, la pregunta no es si alguien va a intentar manipularlo. Es si sabrías si ya lo consiguió. Solicita una auditoría independiente con Lexic Compass.