OWASP Top 10 para LLM en producción: dónde fallan de verdad y qué controles te salvarán en auditoría

El riesgo más serio de muchos proyectos de IA en empresas reguladas no está en el modelo. Está en todo lo que le rodea: conectores, documentos, instrucciones ocultas, herramientas mal expuestas y controles de gobierno que siguen tratando al LLM como si fuera otro SaaS más. No lo es. Y OWASP, con su catálogo de riesgos para aplicaciones de IA generativa y LLM, lleva tiempo diciendo algo bastante menos exótico de lo que parece: el problema no es solo que el modelo “alucine”, sino que puede ser manipulado a través de entradas que tu organización ni siquiera percibe como comandos.

Eso cambia la conversación para banca, seguros, pagos, salud o infraestructuras críticas. Porque cuando un sistema toma contexto de un correo, un ticket, una base documental o una búsqueda externa, la pregunta deja de ser si el modelo responde bien. La pregunta pasa a ser quién controla la cadena completa de instrucciones, datos y acciones. Ahí es donde el asunto deja de ser un debate de laboratorio y entra de lleno en terreno de DORA, GDPR, NIS2, HIPAA o NIST CSF 2.0.

La tesis es sencilla: el prompt injection no es un truco ingenioso de red teaming. Es un problema de integridad, gobernanza y control de accesos con implicaciones regulatorias muy concretas. Si tu organización lo sigue tratando como una curiosidad técnica, va tarde.

El error de base: creer que solo hay riesgo en lo que el usuario teclea

OWASP ha situado prompt injection entre los riesgos principales para aplicaciones con LLM. La idea central no necesita adornos: un atacante puede influir en la salida o el comportamiento del sistema introduciendo instrucciones maliciosas que compiten con las instrucciones legítimas. A veces entran por el prompt directo del usuario. Otras, por un documento indexado, una página web rastreada, un fichero adjunto o una fuente recuperada por RAG. El detalle importa, porque desmonta una falsa sensación de seguridad bastante extendida: “nuestro usuario final no puede tocar el system prompt”. Estupendo. El problema es que quizá sí puede tocar, o contaminar, la información que el sistema acabará tratando como contexto operativo.

En entornos regulados, eso tiene dos consecuencias inmediatas. Primera: el perímetro de seguridad ya no coincide con la interfaz de usuario. Segunda: la clasificación clásica entre dato, instrucción y metadato se vuelve mucho más frágil. Un PDF puede contener contenido que el modelo interprete como mandato. Una web externa puede introducir instrucciones destinadas a desactivar controles o forzar una acción. Un repositorio interno puede propagar contenido heredado que nadie revisó pensando que solo era “documentación”.

Si esto te suena a un problema de segregación de funciones mal resuelto, acertaste. Solo que ahora la “función” afectada incluye inferencia estadística y ejecución mediada por herramientas.

Por qué esto importa de verdad bajo DORA

DORA no menciona prompt injection con ese nombre. No hacía falta. Su lógica encaja de forma bastante directa con este riesgo. El Reglamento (UE) 2022/2554 exige un marco de gestión del riesgo de las TIC sólido, documentado y gobernado al más alto nivel. El artículo 6 obliga a las entidades financieras a contar con un marco interno de gestión del riesgo de las TIC que garantice un nivel elevado de resiliencia operativa digital. El artículo 9 entra en protección y prevención, y pide mecanismos para proteger los sistemas de TIC y reducir el impacto de los riesgos. El artículo 10 trata de detección. El 11, de respuesta y recuperación. Si un flujo con LLM puede ser manipulado por entradas externas hasta alterar respuestas, decisiones o acciones, estamos ante un riesgo TIC de libro, no ante una rareza del equipo de innovación.

La parte más incómoda llega con el gobierno. DORA art. 5 deja claro que el órgano de dirección define, aprueba, supervisa y es responsable de la aplicación del marco de gestión del riesgo de las TIC. Traducido al castellano menos diplomático: si una entidad despliega asistentes internos, copilotos de atención al cliente, motores de búsqueda aumentada o automatizaciones con agentes, no basta con delegarlo al proveedor o al laboratorio de IA. Debe existir una decisión de control integrada en el marco de riesgo de la entidad.

Hay otro ángulo que suele pasarse por alto. DORA art. 13 obliga a clasificar incidentes relacionados con las TIC y a determinar umbrales y criterios. Si un incidente con IA generativa provoca divulgación no autorizada de datos, ejecución indebida de una acción o degradación material de un servicio, la discusión ya no es semántica. La entidad tiene que saber si aquello es un incidente TIC, cómo lo clasifica y si desencadena notificación. El problema práctico es que muchas organizaciones todavía no han traducido fallos propios de LLM a taxonomías operativas de incidentes. Siguen en una tierra de nadie entre “error de aplicación” y “fallo de ciberseguridad”. Mala idea.

NIS2 tampoco compra la excusa de que esto es solo I+D

Fuera del sector financiero, o en grupos mixtos que combinan entidades DORA con servicios esenciales o importantes, NIS2 empuja en la misma dirección. El artículo 21 de la Directiva (UE) 2022/2555 obliga a aplicar medidas técnicas, operativas y organizativas apropiadas y proporcionadas para gestionar los riesgos que amenacen la seguridad de las redes y sistemas de información. No habla de LLM, claro. Habla de análisis de riesgos, gestión de incidentes, seguridad de la cadena de suministro, desarrollo y mantenimiento seguros, políticas de evaluación de eficacia y formación básica de ciberhigiene, entre otros elementos.

Prompt injection toca varios de esos puntos a la vez. Afecta al desarrollo seguro cuando la aplicación concatena instrucciones y contexto sin separación lógica robusta. Afecta a la cadena de suministro cuando el comportamiento depende de modelos, embeddings, orquestadores, plugins, APIs externas o bases documentales de terceros. Y afecta a la gestión de incidentes cuando la manipulación de contexto altera decisiones o expone información. La tentación habitual consiste en tratar el problema como una simple cuestión de “calidad de respuestas”. NIS2 no premia ese autoengaño. Si impacta en la seguridad o continuidad del servicio, entra en el perímetro.

Además, NIS2 eleva la responsabilidad de la dirección. El artículo 20 exige que los órganos de dirección aprueben las medidas de gestión del riesgo de ciberseguridad, supervisen su aplicación y puedan recibir formación. Dicho sin rodeos: si la alta dirección aprueba el despliegue de asistentes con acceso a procesos críticos, no puede fingir sorpresa cuando la superficie de ataque cambia.

El punto ciego de privacidad: no todo prompt injection acaba en brecha, pero puede acabar ahí

GDPR tampoco necesita aprender la jerga de Silicon Valley para ser relevante aquí. Si un ataque o manipulación del sistema lleva a una divulgación no autorizada de datos personales, o a un acceso indebido, el artículo 4.12 sobre violación de la seguridad de los datos personales puede entrar en juego. A partir de ahí, se activan los artículos 33 y 34 sobre notificación a la autoridad de control y comunicación al interesado, según el riesgo para los derechos y libertades.

El matiz importa. No todo caso de prompt injection equivale automáticamente a una brecha notificable. Pero puede ser el vector que la provoque. Por ejemplo: un asistente interno consulta bases de conocimiento con datos de clientes y, tras recibir instrucciones maliciosas a través de contenido recuperado, devuelve información que el usuario no debía ver. En ese caso, el incidente deja de ser una mera “respuesta incorrecta”. Pasa a ser un problema de confidencialidad e integridad del tratamiento.

Y hay más. El artículo 25 de GDPR exige protección de datos desde el diseño y por defecto. Si la aplicación permite que contexto externo y reglas internas compitan sin controles suficientes, cuesta defender que el tratamiento se diseñó con minimización, separación de propósitos y restricciones de acceso razonables. El artículo 32, por su parte, obliga a aplicar medidas técnicas y organizativas apropiadas para garantizar un nivel de seguridad adecuado al riesgo. No te dice cómo protegerte frente a prompt injection. Pero sí te exige que el diseño de seguridad responda al riesgo real del sistema, no al riesgo que te resultaba más cómodo documentar.

En salud, el razonamiento se parece bastante. HIPAA Security Rule, en 45 CFR Part 164 Subpart C, exige salvaguardas administrativas, físicas y técnicas para proteger la información sanitaria electrónica protegida. Si un flujo con IA expone ePHI por manipulación de entradas o contexto, el problema no desaparece porque el atacante no haya explotado una CVE clásica. A ojos de compliance, el resultado operativo manda.

Lo que OWASP sí aporta, y lo que algunas empresas han querido escuchar de más

Conviene distinguir entre lo que OWASP afirma con claridad y las extrapolaciones que el mercado añade para vender seguridad “LLM-native” con diapositivas muy limpias y poca evidencia. OWASP alerta sobre prompt injection, indirect prompt injection, exfiltración de información sensible, inseguridad en la salida y exceso de confianza en la aplicación. También insiste en que los modelos no interpretan el texto con una separación de privilegios comparable a la de un sistema operativo. Esa es la clave técnica y conceptual.

Lo que no conviene hacer es atribuir a OWASP un recetario único, cerrado y normativamente obligatorio al nivel de detalle que a veces se lee en piezas comerciales. OWASP describe riesgos, patrones de abuso y líneas de mitigación. No sustituye una arquitectura de seguridad, una evaluación de impacto ni una política interna formalmente aprobada.

Por eso hay que ser precisos. Resulta razonable defender que una organización debe separar, en la medida de lo posible, las instrucciones de alto privilegio del contenido recuperado y limitar las acciones accesibles al sistema. Resulta razonable también que trate el contenido externo o dinámico con cautela y que establezca controles antes de permitir que una salida desencadene operaciones sensibles. Pero presentar un conjunto muy específico de controles técnicos como si viniera literalmente impuesto por la fuente sería inflar la evidencia. Y en compliance, inflar la evidencia suele acabar mal: primero en la revisión interna, luego quizá delante del supervisor.

La cuestión técnica de fondo no es nueva: confianza mal asignada

Si quitamos la capa de marketing, prompt injection es una variante moderna de un problema viejo: otorgar confianza excesiva a entradas mezcladas en un flujo automatizado. La novedad es que el sistema afectado no ejecuta instrucciones de forma determinista como un parser clásico. Las interpreta probabilísticamente y puede combinar señales contradictorias. Eso complica la validación, la trazabilidad y el testing.

En software tradicional, si mezclas datos no confiables con comandos, sabes que estás fabricando una avería. SQL injection enseñó esa lección hace décadas. Con LLM, muchas organizaciones han retrocedido varios casilleros y vuelven a concatenar piezas heterogéneas —prompt del usuario, contexto documental, mensajes del sistema, resultados de búsqueda, salidas de herramientas— confiando en que “el modelo entenderá la prioridad”. A veces sí. Otras no. Y un regulador no suele quedar impresionado por la defensa basada en la esperanza.

El reto práctico es que los controles clásicos no se trasladan de manera uno a uno. Un firewall no arregla una jerarquía de instrucciones mal diseñada. Un DLP genérico puede no ver que el verdadero problema está en cómo el modelo interpreta texto aparentemente inocuo. Una revisión contractual de proveedor tampoco soluciona por sí sola el modo en que tu aplicación orquesta contexto y acciones. De ahí que este riesgo exija una gobernanza híbrida: seguridad de aplicación, ciber, privacidad, legal, arquitectura y negocio. Sí, lo sé. Suena poco glamuroso. Precisamente por eso suele llegar tarde.

Qué puede exigirse con fundamento, aunque la norma no diga “prompt injection”

El error habitual en regulación tecnológica consiste en esperar a que una ley nombre exactamente el problema para actuar. Eso no funciona. Ni con cloud funcionó, ni con ransomware, ni va a funcionar con IA generativa. La obligación jurídica suele formularse en términos de gestión del riesgo, seguridad adecuada, resiliencia, gobernanza y control de terceros. El trabajo serio consiste en traducir esa obligación al riesgo emergente concreto.

En DORA, esa traducción pasa por varias capas. El marco de gestión del riesgo TIC del artículo 6 debe incluir los activos, dependencias y procesos basados en IA que tengan relevancia operativa. La protección y prevención del artículo 9 exige medidas acordes a la exposición del sistema. La detección del artículo 10 obliga a identificar actividades anómalas. La respuesta y recuperación del artículo 11 exige continuidad y restauración. Y si el sistema depende de terceros proveedores de servicios TIC, los artículos 28 y siguientes sobre gestión del riesgo de terceros ICT obligan a inventariar, gobernar y controlar esa dependencia.

En GDPR, la traducción se hace vía artículos 25, 32, 33 y, cuando proceda, 35 sobre evaluación de impacto relativa a la protección de datos. Si el uso del sistema implica tratamiento que pueda entrañar un alto riesgo para los derechos y libertades, la DPIA deja de ser una opción decorativa. Y una DPIA seria para un asistente con acceso a datos sensibles no puede pasar por alto la posibilidad de manipulación de contexto, divulgación improcedente o uso desviado.

En NIS2, el artículo 21 sirve como bisagra: análisis de riesgos, seguridad en adquisición y desarrollo, gestión de vulnerabilidades, políticas para evaluar la eficacia de las medidas, seguridad de la cadena de suministro y autenticación segura. No hace falta retorcer mucho la lectura para ver que una aplicación con LLM y acceso a procesos o información crítica encaja en varios de esos apartados.

Lo que una empresa regulada debería revisar ya, sin esperar a la próxima moda del mercado

Hay una pregunta que separa a las organizaciones que están entendiendo el problema de las que siguen en fase de demo: ¿tu inventario de sistemas críticos incluye de verdad los flujos con IA generativa, sus conectores, sus fuentes de contexto y sus acciones habilitadas? Si la respuesta es “más o menos”, no está incluido.

El primer paso útil no es comprar otra herramienta. Es mapear la cadena de decisión. Qué instrucciones de sistema existen. Qué entradas recibe el modelo. De dónde vienen. Qué fuentes son internas y cuáles externas. Qué datos personales, financieros, estratégicos o sanitarios pueden aflorar. Qué acciones puede disparar el sistema, aunque sea a través de un intermediario. Qué proveedor aloja el modelo o la capa de orquestación. Qué registros existen para reconstruir un incidente. Qué equipo puede parar el servicio si algo sale mal. Parece básico. Lo es. También suele faltar.

Después viene lo difícil: decidir qué usos merecen controles reforzados o directamente una limitación de alcance. No todos los despliegues tienen el mismo perfil. Un asistente aislado de productividad con contenido sintético no equivale a un agente con acceso a correo, CRM, base documental regulada y capacidad para ejecutar acciones. Mezclar ambos en la misma matriz de riesgos es la manera más eficiente de engañarse a uno mismo.

Desde el punto de vista regulatorio, hay al menos cinco frentes que conviene revisar:

• Clasificación del caso de uso. Determina si el sistema apoya una función crítica o importante en el sentido operativo de la entidad. En DORA, esa distinción cambia la severidad del análisis sobre continuidad, incidentes y terceros.
• Base documental de diseño y control. Si el sistema trata datos personales o información regulada, documenta arquitectura, finalidades, flujos de datos, accesos y restricciones. Luego enlázalo con tu análisis de riesgos y, si procede, con una DPIA bajo GDPR art. 35.
• Gobierno de terceros. Revisa contratos, subprocesadores, localización de tratamiento, medidas de seguridad, derechos de auditoría y dependencia tecnológica. DORA art. 28 y siguientes no están para adornar el expediente de outsourcing.
• Respuesta a incidentes. Define qué constituye incidente en estos sistemas: exposición de datos, acción no autorizada, degradación del servicio, manipulación de contexto, error sistemático con impacto operativo. Si no hay taxonomía, el día del incidente habrá debate; y el debate consume el tiempo que deberías dedicar a contenerlo.
• Controles de acceso y minimización. Un modelo no necesita ver todo para ser útil. GDPR art. 25 y 32, y la lógica básica de seguridad, empujan en la misma dirección: menos datos, menos superficie, menos problema.

La parte incómoda: proveedores, contratos y falsa transferencia de responsabilidad

Una parte del mercado ha vendido la idea de que los riesgos de IA se resuelven “trabajando con un proveedor enterprise”. Ojalá fuera tan simple. No lo es. DORA ha sido bastante insistente con esto: externalizar una función o depender de un proveedor TIC no transfiere la responsabilidad regulatoria de la entidad. La arquitectura del servicio, las condiciones contractuales, la gestión de subcontratación, el acceso a datos, la capacidad de auditoría y la reversibilidad importan. Mucho.

Si el flujo con LLM utiliza un modelo alojado por un tercero, una capa de observabilidad adicional, un motor de embeddings y conectores a aplicaciones internas, tienes una cadena de terceros, no un único proveedor mágico. Y cada eslabón puede afectar confidencialidad, integridad, disponibilidad y trazabilidad. DORA art. 28 obliga a gestionar el riesgo derivado de terceros proveedores de servicios TIC como parte integrante del marco de riesgo TIC. Los artículos 30 y 31, además, detallan elementos contractuales y disposiciones sobre subcontratación para servicios que apoyen funciones críticas o importantes.

La pregunta correcta para procurement y legal no es “¿el proveedor dice que cumple?”. La pregunta es otra: ¿qué control real conservas tú sobre los datos, la configuración, la supervisión del servicio, la notificación de incidentes y la salida ordenada si el experimento sale mal? Los folletos de ventas suelen ser muy elocuentes sobre innovación responsable y bastante más discretos sobre dependencia técnica.

También conviene revisar el ciclo de vida de registros y evidencias del servicio contratado. No porque exista una regla universal idéntica para todos los proveedores, sino porque la entidad necesita saber qué capacidad tendrá para investigar incidentes, responder a requerimientos y alinear la operación con sus obligaciones de retención, seguridad y privacidad. Si ese punto no está claro en contrato o documentación técnica, el problema no aparecerá el día de la compra. Aparecerá el día del incidente.

Donde muchas políticas internas fallan: hablan de IA ética y callan sobre seguridad operativa

Durante los últimos dos años han proliferado políticas corporativas de IA con grandes palabras: transparencia, supervisión humana, no discriminación, uso responsable. Todo eso está bien. Pero una parte de esos documentos evita el barro operativo: quién aprueba conectores, quién valida fuentes de contexto, qué usos quedan prohibidos, qué pruebas mínimas debe superar un caso antes de pasar a producción, qué incidentes deben escalarse a seguridad o privacidad, y bajo qué criterio puede retirarse un sistema.

Una política útil para entornos regulados no debería quedarse en principios abstractos. Debería bajar a decisiones concretas: qué tipo de información puede introducirse en sistemas externos, qué categorías de datos quedan excluidas salvo autorización expresa, qué funciones pueden apoyarse en IA generativa y cuáles no, qué revisión jurídica y de seguridad se exige según el nivel de riesgo, y qué evidencias deben conservarse. Si no aterriza ahí, sirve para la foto del comité y poco más.

NIST CSF 2.0 ayuda precisamente por eso: no se obsesiona con la tecnología de moda y vuelve a las funciones de gobierno, identificación, protección, detección, respuesta y recuperación. Para un despliegue con LLM, esa estructura sigue siendo más útil que muchas guías brillantes pero vaporosas. Gobernar antes de desplegar. Identificar dependencias. Proteger accesos y datos. Detectar anomalías. Responder con playbooks reales. Recuperar servicio y confianza. No tiene misterio. Tiene trabajo.

La objeción habitual: “pero no hay un estándar definitivo”

Correcto. No hay un estándar único y cerrado que resuelva por sí solo prompt injection en todos los contextos. Tampoco lo hubo durante mucho tiempo para cloud misconfiguration, ransomware o software supply chain. Aun así, nadie con dos dedos de frente sostuvo que la ausencia de una norma específica eximiera de controlar el riesgo.

La falta de estandarización completa no impide exigir diligencia. De hecho, en regulación casi nunca la impide. Lo que se espera de una entidad seria es algo menos heroico y bastante más terrenal: que identifique el riesgo, lo evalúe según su contexto, adopte medidas proporcionadas, documente decisiones, pruebe controles, revise dependencias de terceros y sepa reaccionar cuando falle algo. Si tu organización está esperando la checklist definitiva para empezar, en realidad está esperando una excusa para no empezar.

Esto vale también para la supervisión interna. Auditoría, compliance, riesgo operacional y seguridad no deberían pedir “certeza científica” absoluta para plantear restricciones o condiciones de despliegue. Les basta con algo mucho más estándar: evidencia suficiente de que existe un riesgo plausible con impacto en información, procesos o servicios, y de que el sistema requiere controles acordes. Esa evidencia existe. OWASP la describe desde la perspectiva de seguridad aplicada. DORA, NIS2 y GDPR dan el marco jurídico para convertirla en obligación de gestión.

Qué lenguaje conviene usar internamente para que el asunto no se banalice

Un detalle práctico: si presentas prompt injection dentro de la empresa como un problema “de prompt engineering”, mucha gente lo archivará mentalmente como ajuste fino del producto. Error. Si lo presentas como riesgo de integridad de instrucciones, exposición de información y activación indebida de acciones en sistemas con IA, la conversación cambia. Y debe cambiar.

Los comités de riesgo, privacidad o continuidad no tienen por qué dominar la taxonomía de OWASP para LLM. Sí necesitan entender el efecto de negocio y control. Qué puede pasar. Qué activos toca. Qué obligaciones regulatorias puede activar. Qué dependencia de tercero introduce. Qué evidencias faltan. Qué umbral de tolerancia acepta la entidad. Ese es el idioma que mueve decisiones.

También ayuda evitar dos extremos igual de inútiles. Uno: el apocalipsis grandilocuente, como si cualquier LLM fuera una bomba regulatoria esperando estallar. Dos: la trivialización de pasillo, como si esto se resolviera “poniendo una nota en el prompt para que ignore instrucciones maliciosas”. No. El modelo puede recibir la nota. El atacante también. Y ya sabemos quién suele ser más insistente.

Mi lectura: el riesgo no está sobrevalorado; lo que está inflado es la confianza de algunos despliegues

Después de revisar cómo encajan OWASP, DORA, NIS2, GDPR y los marcos de seguridad más clásicos, la conclusión no es que haya que frenar toda iniciativa con IA generativa. Tampoco que prompt injection sea un cisne negro regulatorio. La conclusión es más sobria y bastante menos cómoda: muchas organizaciones están desplegando capacidades con acceso a información o procesos sensibles sin haber madurado aún la disciplina de control que ese acceso exige.

Eso no convierte cada proyecto en incumplimiento automático. Sí convierte en temerario el argumento de que “como la ley no menciona esta técnica concreta, ya lo resolveremos más adelante”. La regulación tecnológica relevante rara vez funciona así. Lo que exige es gestión del riesgo proporcionada, documentada y gobernada. Y ese listón ya está aquí.

OWASP ha hecho su parte al poner nombre y estructura a una familia de fallos que algunos seguían tratando como anécdota. Ahora toca la parte menos vistosa: inventario serio, gobierno de terceros, diseño de controles, criterios de incidente, pruebas, documentación y límites de uso donde corresponda. Nada de eso sale en una demo. Todo eso sale en una inspección.

Si tu entidad está desplegando asistentes, RAG corporativo, agentes o automatizaciones con modelos y todavía no ha conectado ese mapa con DORA art. 6, art. 9, art. 13 y art. 28; con NIS2 art. 21; y con GDPR art. 25, 32, 33 y 35 cuando proceda, el problema no es la falta de innovación. El problema es que el control va por detrás del sistema.

Y cuando el control va por detrás, la tecnología suele acabar enseñando la factura. A veces en un post-mortem. A veces ante el regulador. Ninguna de las dos opciones tiene especial encanto.