OWASP Top 10 para LLM en producción: dónde se rompe de verdad y cómo demostrar control ante DORA y NIS2

El problema no es que un LLM alucine. El problema serio empieza cuando ese modelo toca datos reales, llama a herramientas, consulta sistemas internos o toma decisiones que alguien acaba ejecutando. Ahí deja de ser una demo simpática y se convierte en superficie de ataque, en riesgo operacional y, para quien trabaja en banca, seguros o fintech, en material regulatorio de primera.

OWASP lleva tiempo poniendo orden en este terreno con su Top 10 for Large Language Model Applications. La lista es útil, pero se queda corta si el lector necesita algo más exigente que una taxonomía: cómo aterrizar esos riesgos en operación, qué controles sirven de verdad en un entorno regulado, qué evidencias pedir a seguridad, a ingeniería y a proveedores, y cómo conectar todo eso con obligaciones auditables bajo DORA, NIS2 e ISO 27001.

Aquí está el quid: en un entorno europeo regulado, un riesgo de LLM no se evalúa solo por su novedad técnica. Se evalúa por su impacto en confidencialidad, integridad, disponibilidad, autenticidad y trazabilidad; exactamente el lenguaje que usa DORA para la gestión del riesgo TIC y el que NIS2 traduce en medidas de gestión del riesgo de ciberseguridad. Si tu copiloto interno puede exfiltrar datos, ejecutar acciones no autorizadas o contaminar un flujo de decisión crítico, no tienes un “riesgo de IA”. Tienes un riesgo TIC de libro con un embalaje nuevo.

Y el embalaje nuevo tiene una trampa: muchas organizaciones están desplegando LLM como si fueran una capa de interfaz. No lo son. Son una capa probabilística con dependencias opacas, datos de entrenamiento difíciles de gobernar, comportamiento sensible al contexto y una tendencia muy poco tranquilizadora a obedecer al texto más reciente que reciben. Excelente para productividad. También excelente para que un atacante esconda una instrucción en una página web, un PDF, un correo o un ticket y convierta a tu agente en su becario gratuito.

Qué cambia cuando el OWASP Top 10 entra en un entorno regulado

OWASP enumera los fallos más habituales en aplicaciones LLM: prompt injection, divulgación de información sensible, gestión insegura de salidas, data poisoning, denegación de servicio del modelo, exceso de confianza, autorización insuficiente, ejecución no controlada de herramientas, dependencia de componentes vulnerables y robo del modelo, entre otros, según la versión y evolución del proyecto. La tentación habitual es leerlo como una lista de fallos de aplicación. Error. En operación regulada, cada uno de esos fallos desplaza obligaciones muy concretas:

• DORA, Reglamento (UE) 2022/2554: artículos 5 a 16 sobre marco de gestión del riesgo TIC; artículo 11 sobre detección de actividades anómalas; artículos 17 a 23 sobre gestión, clasificación y notificación de incidentes relacionados con las TIC; artículos 28 a 30 sobre gestión del riesgo de terceros proveedores de servicios TIC.
• NIS2, Directiva (UE) 2022/2555: artículo 21 sobre medidas de gestión de riesgos de ciberseguridad, incluyendo gestión de incidentes, seguridad de la cadena de suministro, seguridad en adquisición, desarrollo y mantenimiento, políticas para evaluar la eficacia de medidas y uso de criptografía y control de accesos; artículo 23 sobre notificación de incidentes significativos, con alerta temprana en 24 horas, notificación en 72 horas e informe final en un mes.
• ISO/IEC 27001:2022: no porque un auditor la vaya a venerar como si fuese un texto sagrado, sino porque el Anexo A aporta controles mapeables de forma útil: gestión de identidades, control de accesos, registro y monitorización, prevención de fuga de datos, seguridad de desarrollo, relación con proveedores, gestión de configuraciones, filtrado web, codificación segura y manejo de información.

Un detalle que muchas áreas de cumplimiento todavía subestiman: cuando un LLM se integra con correo, CRM, repositorios documentales, sistemas de pago, herramientas de soporte o RPA, el perímetro regulatorio ya no depende del modelo sino de la función. Si esa función soporta procesos críticos o importantes, DORA aprieta. Si esa función forma parte de servicios esenciales o importantes en el sentido de NIS2, también aprieta. Y si en el camino aparece dato personal, GDPR entra por la puerta principal, no por la ventana.

Por eso la pregunta correcta no es “¿estamos usando IA generativa?”. La pregunta útil es otra: ¿qué decisiones, datos y sistemas puede tocar este LLM, con qué restricciones y qué prueba objetiva tenemos de que esas restricciones funcionan?

Prompt injection: el riesgo más conocido y, aun así, el peor entendido

El prompt injection se ha popularizado porque se entiende rápido: alguien consigue que el modelo ignore instrucciones del sistema o las desborde mediante instrucciones maliciosas en la entrada o en contenido recuperado. Pero la versión de producción no se parece a los ejemplos de laboratorio tipo “ignora todas las instrucciones anteriores”. La versión de producción suele venir disfrazada de dato legítimo.

Un agente que resume correos y propone acciones puede recibir un mensaje con texto oculto, una firma manipulada o un adjunto que contiene instrucciones para extraer secretos del contexto. Un asistente con RAG puede recuperar una wiki interna “contaminada” con órdenes embebidas. Un agente que navega por webs de proveedores puede visitar una página con instrucciones diseñadas para forzar llamadas a herramientas. En todos esos casos, el atacante no necesita romper el modelo. Le basta con hablarle donde el modelo escucha.

Operativamente, el error más repetido consiste en tratar el prompt injection como si fuera un problema de filtrado semántico. No basta. Un filtro de prompts ayuda, pero no sustituye el aislamiento de privilegios. Si el agente puede ver secretos, ejecutar herramientas o modificar registros, cualquier inyección exitosa escala de “respuesta extraña” a incidente real.

El control que funciona no es uno; es una cadena:

• Separación estricta entre instrucciones, datos y herramientas. El modelo no debe decidir por sí solo cuándo una instrucción recuperada de un documento es operativa. Los documentos son datos, no órdenes. Si tu arquitectura no distingue ambas cosas, ya vas tarde.
• Permisos mínimos por herramienta. Un agente no debería heredar el acceso del usuario ni del servicio “por comodidad”. Cada acción de lectura o escritura necesita un alcance limitado y revocable.
• Confirmación fuera de banda para acciones sensibles. Transferencias, cambios de configuración, altas de usuarios, borrado de registros, extracción masiva de datos: todo eso requiere una segunda validación fuera del contexto conversacional.
• Política de confianza cero para contenido recuperado. El contenido de RAG, correo, web o tickets debe tratarse como entrada no fiable, incluso si proviene de un repositorio interno. Interno no equivale a íntegro.
• Registro estructurado del árbol de decisión. No solo el prompt final, también el origen de documentos recuperados, herramientas sugeridas, herramientas ejecutadas, parámetros, identidad, política aplicada y resultado.

Esto conecta de forma directa con NIS2 art. 21.2, que exige medidas sobre seguridad en adquisición, desarrollo y mantenimiento, gestión de incidentes y seguridad de la cadena de suministro, y con DORA art. 6, que obliga a mantener un marco sólido y documentado de gestión del riesgo TIC. Si el agente puede ejecutar acciones y no puedes demostrar qué documento desencadenó la orden, qué política la permitió y qué control la bloqueó o autorizó, no tienes control defendible. Tienes fe tecnológica. Y la fe, en auditoría, cotiza peor que nunca.

Telemetría mínima para demostrar cobertura ante prompt injection

La evidencia útil no es una política PDF de 27 páginas. Es telemetría.

• ID de sesión y de usuario o identidad de servicio.
• Versión del system prompt y hash de la política aplicada.
• Fuentes recuperadas por el motor RAG, con identificador documental, timestamp y clasificación del contenido.
• Herramientas propuestas por el modelo y herramientas realmente ejecutadas.
• Motivo de bloqueo o de aprobación según política.
• Eventos de escalado a revisión humana.
• Alertas por patrones de inyección, por ejemplo instrucciones para revelar secretos, ignorar políticas, ejecutar acciones administrativas o acceder a fuentes no relacionadas con la tarea.

Sin esa base, luego llega el incidente y todo el mundo “cree” que el agente hizo algo extraño. Magnífico. Lo que nadie puede reconstruir es cómo, cuándo y con qué impacto.

Fuga de datos sensibles: el clásico de siempre, ahora con interfaz conversacional

La fuga de datos en LLM no ocurre solo cuando el modelo “recuerda” datos de entrenamiento. Ese caso existe, pero en empresa el vector más común es mucho más prosaico: el sistema envía al proveedor más contexto del necesario, el usuario pega información sensible en un chat no segregado, el RAG recupera documentación clasificada sin necesidad, o la salida del modelo mezcla datos de varios expedientes. Nada glamuroso. Muy eficaz.

Para un responsable de cumplimiento europeo, aquí convergen tres planos distintos:

• Minimización y limitación de finalidad bajo GDPR art. 5.1.b y 5.1.c.
• Seguridad del tratamiento bajo GDPR art. 32.
• Notificación de violaciones de seguridad bajo GDPR art. 33 y, según el caso, obligaciones sectoriales o NIS2 art. 23 si el incidente afecta a la prestación del servicio.

En DORA, además, la fuga de datos no se analiza solo como privacidad. Si compromete servicios críticos, integridad de procesos o dependencia de terceros, entra en la maquinaria de incidentes TIC y de supervisión de terceros. Un asistente de operaciones que expone credenciales, claves API, runbooks de recuperación o datos de clientes puede convertirse en un incidente material aunque el volumen de datos personales no sea masivo.

El control esencial aquí es una arquitectura de datos por capas. Dicho sin liturgia:

• Clasificación previa de fuentes. No todo repositorio es apto para RAG. Debe existir una decisión explícita sobre qué colecciones se indexan, para qué casos de uso y bajo qué audiencia.
• Redacción y tokenización antes del envío al modelo. Si el uso no exige PII completa, no la envíes. Sustitúyela por identificadores efímeros y resuelve después, si procede, en una capa segura.
• Política de retención diferenciada. Logs de seguridad sí; prompts y respuestas completos, no siempre. El equilibrio entre trazabilidad y privacidad requiere diseño fino, no reflejos automáticos.
• Controles de salida. DLP semántico, detección de secretos, validación por expresiones regulares y por clasificadores antes de mostrar o exportar respuesta.
• Segregación contractual y técnica con el proveedor. Uso para entrenamiento desactivado, región de procesamiento definida, subencargados identificados, cifrado en tránsito y reposo, garantías de borrado, y evidencia de segregación tenant.

Quien crea que esto se resuelve con una cláusula estándar de proveedor probablemente no ha leído sus propios flujos. La fuga más probable no está en el contrato; está en el conector mal configurado al repositorio documental o en el desarrollador que decidió pasar la conversación completa “porque mejora la respuesta”. Sí, la mejora. También mejora el radio de explosión.

Qué evidencia pedir para fuga de datos

Si eres CISO o compliance, pide pruebas incómodas, no presentaciones:

• Matriz de fuentes indexadas para RAG con propietario, clasificación y base de autorización.
• Muestras de prompts reales pseudonimizados con prueba de redacción aplicada antes de salir a proveedor.
• Resultados de pruebas de extracción de secretos y de datos personales sobre salidas del sistema.
• Configuración de retención de prompts, respuestas y adjuntos en cada entorno.
• Inventario de subprocesadores o terceros TIC implicados en inferencia, observabilidad, vector stores y etiquetado.

Eso enlaza con DORA art. 28 sobre gestión del riesgo de terceros proveedores de servicios TIC. Si el LLM depende de un proveedor externo, el riesgo no se limita al modelo principal. También cuenta la base vectorial gestionada, la capa de observabilidad, el gateway de prompts, el servicio de embeddings y cualquier plugin que procese datos. La cadena es más larga de lo que sugiere la factura.

Envenenamiento de datos y del modelo: menos visible, más corrosivo

El data poisoning tiene menos titulares que el prompt injection porque es más aburrido de contar. También porque sus efectos suelen ser graduales. Pero en entornos regulados puede ser más dañino. Si el corpus de RAG, los datos de ajuste fino o las fuentes de etiquetado se contaminan, el sistema no solo responde mal: normaliza errores, sesgos o instrucciones nocivas como si fueran conocimiento legítimo.

Hay tres variantes operativas especialmente relevantes:

• Contaminación del corpus documental: alguien inserta contenido falso o manipulador en una wiki, base de procedimientos, tickets históricos o repositorio normativo. El agente lo recupera y lo trata como fuente autorizada.
• Contaminación de datos de entrenamiento o afinado: muestras erróneas o maliciosas alteran el comportamiento del modelo en tareas críticas, por ejemplo clasificación de incidentes, priorización de alertas o generación de respuestas regulatorias.
• Contaminación de señales de realimentación: si el sistema aprende de feedback del usuario o de resultados históricos sin control de calidad, puede consolidar atajos peligrosos.

Esto conecta con NIS2 art. 21.2.d sobre seguridad de la cadena de suministro y con art. 21.2.e sobre seguridad en adquisición, desarrollo y mantenimiento de redes y sistemas de información, incluida la gestión y divulgación de vulnerabilidades. También encaja con controles de ISO 27001:2022 relativos a gestión de configuraciones, integridad de la información y seguridad en desarrollo.

La cuestión práctica es sencilla: si tu organización no trata el corpus de RAG como un activo crítico con control de cambios, revisión y trazabilidad, está dejando una puerta lateral abierta. Y las puertas laterales suelen ser las favoritas del atacante porque nadie las mira con el dramatismo del acceso privilegiado.

Controles que sí cambian el riesgo

• Versionado de corpus y datasets con hash, propietario y justificación de cambios.
• Flujo de publicación con revisión dual para fuentes que alimentan respuestas operativas o regulatorias.
• Etiquetas de confianza documental que permitan ponderar o excluir fuentes según origen, fecha, estatus y criticidad.
• Pruebas de integridad y muestreo continuo sobre documentos de alto impacto: procedimientos de continuidad, credenciales operativas, guías de atención al cliente, respuestas tipo a incidentes y contenidos normativos.
• Separación entre entornos de experimentación y corpus productivo. Obvio, sí. Cumplido siempre, no.

La evidencia, de nuevo, debe ser operativa: registro de cambios, aprobación, controles de acceso al repositorio de conocimiento, alertas por ediciones anómalas y trazabilidad de qué versión documental sustentó cada respuesta relevante. Si luego el agente recomienda una acción equivocada durante un incidente, necesitas reconstruir si el origen fue el modelo, el recuperador o el contenido. Sin esa reconstrucción, la investigación post-incidente se convierte en una disputa teológica entre equipos.

Exceso de confianza y automatización sin freno: cuando el verdadero fallo es de gobierno

OWASP acierta al incluir la dependencia excesiva o overreliance. No es un “riesgo blando”. Es uno de los fallos de control más serios porque convierte una salida probabilística en una decisión operativa con apariencia de autoridad.

En banca y seguros, el daño no siempre viene de una orden de pago mal ejecutada. A veces basta con que un analista, un operador o un agente de primera línea deje de cuestionar la respuesta del sistema. Un LLM que resume una alerta, clasifica un incidente o propone una respuesta al cliente puede arrastrar errores aguas abajo con una eficacia admirable. El ser humano en el circuito no sirve de mucho si actúa como notario del modelo.

Aquí hay una dimensión regulatoria clara. DORA art. 5 y el marco de gobernanza exigen que el órgano de dirección defina, apruebe, supervise y sea responsable de la gestión del riesgo TIC. Traducido: no basta con desplegar una herramienta y pedir a los usuarios “criterio profesional”. Hace falta diseñar umbrales de confianza, límites de automatización, casos de uso permitidos y actividades expresamente prohibidas.

El control útil no consiste en poner un aviso de “la IA puede cometer errores”. Eso sirve para cubrir expedientes de marketing, no para reducir riesgo. Lo que sirve es:

• Definir clases de decisión: informativa, recomendación, acción reversible, acción irreversible, decisión regulada. Cada clase exige un nivel distinto de revisión.
• Establecer umbrales y condiciones de bloqueo: por ejemplo, toda acción que implique salida de datos, cambio de privilegios, modificación de registros contables o contacto con cliente en contexto de reclamación requiere aprobación humana explícita.
• Medir confianza operativa de forma externa al modelo: no confiar en la autoconfianza del LLM, sino en señales como calidad de fuentes, consistencia entre recuperaciones, validaciones deterministas y reglas de negocio.
• Entrenar al usuario para identificar límites del sistema. Formación concreta, no evangelización genérica de IA responsable.

En términos de evidencia, conviene registrar cuántas respuestas fueron aceptadas sin cambios, cuántas se corrigieron, en qué tipos de tarea falla más el sistema y qué incidentes o cuasi incidentes generó. Si no mides reversión humana, correcciones y excepciones, no estás gobernando dependencia. La estás decorando.

Autorización insegura, plugins y agentes: el punto donde el LLM deja de ser texto y se convierte en operador

El salto de riesgo más brusco ocurre cuando el LLM deja de limitarse a generar texto y adquiere capacidad de actuar: llamar APIs, consultar bases de datos, abrir tickets, reconfigurar sistemas, enviar correos o interactuar con herramientas de terceros. Ahí aparece una mezcla bastante tóxica de dos mundos: la inseguridad clásica de APIs y privilegios, y la imprevisibilidad de un motor generativo que decide cuándo usar esas capacidades.

La mayoría de incidentes serios que veremos en entornos corporativos no vendrán del “modelo rebelde”, sino de permisos mal diseñados alrededor del modelo. Un agente con acceso amplio a sistemas internos es, en esencia, una cuenta privilegiada con interfaz conversacional. Y las cuentas privilegiadas con decisiones probabilísticas no suelen ser el sueño húmedo del auditor.

OWASP lo enfoca como autorización insegura y uso inseguro de plugins o herramientas. Traducido a controles empresariales:

• Cada herramienta debe tener una política propia de autorización, independiente del hecho de que la llamada la origine un usuario humano o un agente.
• El agente no debe encadenar herramientas libremente en procesos sensibles. Las secuencias permitidas deben estar acotadas por caso de uso.
• Las acciones de escritura necesitan validación determinista previa: parámetros permitidos, formatos, destinatarios, ámbitos y límites de volumen.
• Las credenciales del agente deben ser distintas de las del usuario y con permisos mínimos. Nada de “delegación plena” por conveniencia de producto.
• Las herramientas externas son terceros TIC a efectos de riesgo operativo, aunque alguien las venda como simple integración.

Esto enlaza de forma muy directa con DORA art. 28 y 30. Si el caso de uso depende de herramientas o servicios de terceros que soportan funciones críticas o importantes, la organización debe identificar dependencias, evaluar concentración de riesgo, asegurar condiciones contractuales adecuadas y mantener capacidad de supervisión. Un agente que llama a cinco servicios de terceros puede crear una cadena operacional mucho más frágil de lo que muestra el diagrama de arquitectura de ventas.

Desde la óptica de NIS2 art. 21, además, la autorización insegura afecta a control de accesos, seguridad del desarrollo y gestión de vulnerabilidades. Si un plugin permite acciones amplias sin validación contextual, el problema no es “de IA”. Es de diseño de seguridad básico, solo que ahora viaja en una envoltura nueva y cara.

Qué registros debes conservar si un agente toca sistemas reales

• Identidad del usuario solicitante y del agente ejecutor.
• Herramienta invocada, versión, proveedor y endpoint.
• Parámetros de entrada antes y después de sanitización.
• Política de autorización aplicada y resultado.
• Justificación de negocio o contexto de la acción.
• Respuesta del sistema destino, incluidos errores y reintentos.
• Referencia a aprobación humana cuando exista.

Si esta trazabilidad no está disponible de forma correlacionable, cualquier post mortem será un ejercicio de arqueología creativa.

Dependencias opacas y componentes vulnerables: la cadena de suministro de los LLM no termina en el proveedor principal

Una aplicación LLM en producción rara vez depende de un único componente. Suele incluir modelo base, servicio de inferencia, librerías de orquestación, motor de embeddings, vector store, pasarela de observabilidad, filtros de seguridad, herramientas conectadas y a veces un segundo modelo para clasificación o moderación. La superficie de terceros se multiplica.

OWASP lo recoge al hablar de componentes vulnerables y de la cadena de dependencias. El ángulo regulatorio es evidente: NIS2 art. 21.2.d exige abordar la seguridad de la cadena de suministro, incluidas las relaciones entre cada entidad y sus proveedores directos o prestadores de servicios; DORA art. 28 exige una estrategia sobre el riesgo de terceros TIC y un registro de acuerdos contractuales relativos al uso de servicios TIC prestados por terceros.

El error recurrente consiste en evaluar solo al hyperscaler o al proveedor del modelo y olvidar el resto. Pero la fuga, indisponibilidad o alteración puede nacer en la capa vectorial, en una librería con vulnerabilidad conocida, en una herramienta de prompt management o en un conector de datos. Esto no es teórico. En 2023 y 2024 se han multiplicado los avisos de seguridad y CVEs en ecosistemas de IA y MLOps; no todos son críticos, pero bastan para recordar que “innovador” no significa “maduro”.

El control mínimo aceptable debería incluir:

• SBOM o inventario equivalente de componentes relevantes de la aplicación LLM, incluidas librerías de orquestación y herramientas de terceros.
• Proceso de gestión de vulnerabilidades con priorización específica para componentes que procesan prompts, secretos, documentos internos o acciones automatizadas.
• Evaluación de concentración de proveedores para funciones críticas: inferencia, embeddings, almacenamiento vectorial, observabilidad y herramientas.
• Pruebas de resiliencia ante caída o degradación del proveedor: límites, degradación controlada, circuit breakers, colas y mecanismos de fallback.
• Cláusulas contractuales que cubran notificación de incidentes, subcontratación, localización de datos, derecho de auditoría o equivalentes, y soporte a investigaciones.

La ironía aquí es fina: muchas organizaciones despliegan IA para ganar eficiencia operativa mientras añaden una cadena de suministro técnica mucho más densa, menos visible y a menudo menos gobernada que la de sus aplicaciones tradicionales. Productividad, sí. También concentración de riesgo, si nadie la mide.

Denegación de servicio y abuso de costes: no siempre te tumban, a veces te facturan

Los LLM introducen una variante curiosa del viejo DoS: no hace falta tumbar el servicio; basta con disparar consumo, latencia o complejidad de inferencia. Solicitudes gigantes, bucles de herramientas, consultas recursivas, abuso de contexto o extracción masiva pueden degradar servicio y presupuesto a la vez. En sistemas de atención interna o externa, ese deterioro se traduce rápidamente en indisponibilidad operativa.

Para entidades sometidas a DORA, la disponibilidad y resiliencia del servicio no son adornos. DORA art. 11 exige mecanismos para detectar actividades anómalas, y los artículos sobre respuesta y recuperación exigen capacidad real para contener y restaurar. Si tu arquitectura LLM no tiene límites de tokens, cuotas por usuario, control de fan-out de herramientas y observabilidad de coste/latencia, la pregunta ya no es si sufrirás abuso, sino cuánto tardarás en verlo.

Controles concretos:

• Rate limiting por identidad, canal, caso de uso y herramienta.
• Límites de contexto, tamaño de adjuntos y profundidad de encadenamiento.
• Presupuestos de coste y alertas por aplicación, equipo y proveedor.
• Abortos automáticos cuando se detecten bucles de herramienta, repeticiones, patrones de scraping o extracción a gran escala.
• Modos degradados: pasar a respuestas limitadas, desactivar herramientas o enrutar a flujos deterministas cuando el servicio esté bajo presión.

La evidencia útil aquí son series temporales: latencia, tokens de entrada/salida, número de llamadas a herramientas, errores por tipo, bloqueos por política, consumo por tenant o unidad de negocio, y correlación con eventos de seguridad. Un SIEM que no ingiere esta telemetría está ciego para una parte relevante del riesgo.

Mapeo práctico: del riesgo OWASP al artículo regulatorio y a la evidencia que te van a pedir

La tabla no pretende canonizar un único enfoque. Sirve para recordar algo mucho más simple: un riesgo de LLM solo está controlado cuando puedes unir cuatro piezas sin titubear —riesgo, obligación, control y evidencia—. Si una de esas piezas falta, la cobertura regulatoria se deshace enseguida.

Checklist de evidencias para auditoría: lo que sí merece la pena recopilar

Esta es una de esas raras ocasiones en las que una checklist sí aporta valor. No porque los auditores adoren las listas, sino porque los despliegues LLM fallan mucho en documentación verificable.

• Inventario de casos de uso LLM en producción y preproducción, con propietario, finalidad, sistemas conectados y clasificación de criticidad.
• Data flow diagram por caso de uso: origen de prompts, documentos recuperados, proveedor de inferencia, herramientas conectadas, destinos de salida y retención.
• Evaluación de riesgo específica del caso de uso, no una evaluación genérica de “IA”.
• Políticas de acceso para usuarios, cuentas de servicio y agentes, con evidencia de privilegio mínimo.
• Versionado de prompts de sistema, políticas y corpus, con control de cambios y aprobaciones.
• Resultados de pruebas adversariales: inyección, extracción de secretos, abuso de herramientas, desbordamiento de contexto, fuga inter-tenant si aplica.
• Telemetría de seguridad integrada en SIEM o plataforma equivalente: bloqueos, anomalías, herramientas invocadas, latencia y consumo.
• Inventario de terceros TIC implicados en el servicio, con revisión contractual y operativa alineada con DORA art. 28.
• Procedimiento de respuesta a incidentes que contemple específicamente incidentes en aplicaciones LLM.
• Evidencia de formación para usuarios y operadores sobre límites del sistema, datos prohibidos y escalado de errores.

Si solo puedes reunir la mitad de esta lista, no pasa nada dramático de inmediato. Pero al menos ya sabes qué mitad de tu confianza estaba sostenida por esperanza.

Implicaciones para entidades financieras españolas: dónde aprieta más de lo que parece

Para entidades financieras en España, la combinación de DORA y despliegues LLM tiene una derivada muy concreta: la presión no viene solo del incidente consumado, sino de la capacidad de demostrar gobierno, trazabilidad y control de terceros antes de que ocurra nada visible. DORA es aplicable desde el 17 de enero de 2025. Eso significa que cualquier caso de uso LLM en procesos de atención, operaciones, fraude, soporte TI, continuidad o gestión documental debería estar ya incorporado al inventario de riesgo TIC y, si depende de terceros, al esquema de supervisión de proveedores.

En la práctica, veo cuatro puntos ciegos bastante españoles, por decirlo con cariño:

• Copilotos internos desplegados por áreas de negocio sin que seguridad tenga visibilidad real sobre fuentes, retención y conectores.
• RAG montado sobre SharePoint, Confluence o repositorios similares con permisos heredados o replicados de forma imperfecta.
• Agentes para soporte o productividad conectados a herramientas SaaS con contratos fragmentados entre distintas áreas, lo que complica el mapa de terceros TIC.
• Confianza excesiva en la marca del proveedor. Si lo vende un gran hyperscaler o un actor muy conocido, algunos dan por hecho que el riesgo está “industrializado”. No. Está externalizado en parte, que no es lo mismo.

La conexión con supervisión financiera es evidente aunque no siempre explícita. Si un LLM participa en funciones críticas o importantes, el análisis de impacto operativo no puede quedarse en el proveedor principal del modelo. Debe incluir dependencias asociadas, recuperabilidad del servicio, capacidad de sustitución y controles de salida. Quien no haya empezado a tratar estos casos de uso como parte del riesgo TIC transversal se encontrará, más pronto que tarde, con una conversación incómoda entre CISO, cumplimiento, compras y negocio. Nadie disfruta de esas reuniones. Menos cuando ya hay una herramienta en producción y demasiados usuarios encantados con ella.

Lo que un CISO debería exigir antes de dar por “controlado” un caso de uso LLM

Hay una tendencia comprensible a buscar una solución única: un gateway de IA, un filtro mágico, una plataforma de observabilidad, un proveedor que “ya cumple”. Ojalá. La realidad es menos elegante. Los riesgos del OWASP Top 10 para LLM no se mitigan con una pieza aislada, sino con disciplina de arquitectura, IAM, logging, validación y gobierno de terceros.

Si tuviera que reducirlo a criterios de aprobación serios para producción, serían estos:

• El caso de uso tiene una finalidad definida y una clasificación de criticidad aprobada.
• Se sabe qué datos entran, qué datos salen y qué datos jamás deben entrar.
• Las herramientas conectadas tienen permisos mínimos y validaciones deterministas.
• Existe telemetría suficiente para reconstruir una sesión, una acción y un incidente.
• Se han ejecutado pruebas adversariales específicas del caso de uso, no genéricas.
• Los terceros TIC implicados están inventariados y evaluados.
• La organización puede degradar o desconectar el servicio sin colapsar el proceso que soporta.

Si falta una de esas piezas, lo sensato no es prohibir toda IA generativa. Eso sería tan torpe como desplegarla sin control. Lo sensato es acotar el caso de uso al nivel de riesgo que realmente puedes gobernar. Un asistente de búsqueda documental con fuentes limitadas y sin capacidad de acción puede ser perfectamente razonable. Un agente semiautónomo con acceso amplio a sistemas, datos sensibles y proveedores externos exige otro nivel de rigor. La diferencia entre ambos no es marketing. Es supervivencia operativa.

OWASP ha hecho su parte al ordenar los fallos más probables. Ahora le toca a seguridad y cumplimiento hacer la suya: dejar de tratar los LLM como una categoría exótica y empezar a evaluarlos como lo que ya son en muchas organizaciones, una capa más de tecnología crítica con peculiaridades propias. La novedad técnica impresiona. El regulador, en cambio, suele hacer una pregunta bastante menos romántica: enséñeme el control y enséñeme la prueba.