OWASP Top 10 para LLM aplicado a la operación: riesgos reales, controles y evidencias que sí aguantan una auditoría

La pregunta ya no es si tu organización va a usar modelos de lenguaje. La pregunta incómoda es otra: cuando ese copiloto, agente o buscador interno meta la pata, ¿vas a poder demostrar que el fallo estaba controlado? Porque en un entorno regulado no basta con decir que había “guardrails”. Hay que enseñar registros, aprobaciones, límites técnicos, pruebas de resiliencia y responsabilidades claras. Lo demás es teatro con API.

El OWASP Top 10 for Large Language Model Applications se ha convertido en la taxonomía de referencia para ordenar riesgos en aplicaciones basadas en LLM. No porque OWASP tenga la última palabra regulatoria —no la tiene—, sino porque traduce bastante bien los fallos que los equipos ya están viendo en producción: prompt injection, divulgación de información sensible, supply chain opaca, permisos desbocados en plugins o agentes, y una dependencia excesiva de respuestas generadas que a veces suenan convincentes precisamente porque están equivocadas.

Para un CISO o un responsable de cumplimiento en Europa, el valor de esta lista no está en memorizar sus diez categorías. Está en convertirlas en controles auditables que encajen con tres marcos que sí generan consecuencias reales: NIS2, DORA e ISO/IEC 27001. NIS2, en su artículo 21, obliga a adoptar medidas técnicas, operativas y organizativas apropiadas para gestionar riesgos de seguridad. DORA, en especial sus artículos 5 a 17 sobre gestión del riesgo TIC, respuesta, continuidad y aprendizaje, no te pide que adivines el futuro de la IA, pero sí que controles dependencias, incidentes, pruebas y terceros. ISO 27001:2022, a través de su Anexo A, tampoco habla “de moda” sino de controles concretos: gestión de accesos, registros, desarrollo seguro, prevención de fuga de datos, seguridad de proveedores o clasificación de la información.

Aquí está el quid: un despliegue de LLM mal gobernado puede incumplir esos tres marcos sin necesidad de un gran ciberataque. Basta con un chatbot interno que exponga información sensible a un proveedor, un agente que invoque una acción no autorizada, o un sistema RAG que responda con datos contaminados porque nadie protegió la base documental. No hace falta un titular apocalíptico. Basta una mala arquitectura.

Este análisis toma las categorías de OWASP y las baja a operación. Qué riesgos importan de verdad, qué controles conviene implantar, qué evidencias pedirán auditoría y supervisión, y qué telemetría deberías retener para no descubrir demasiado tarde que tu “IA responsable” era una política en PowerPoint.

El error de base: tratar un LLM como si fuera otro SaaS más

Muchas organizaciones han metido los LLM en el cajón de “herramienta de productividad”. El problema es que un LLM no es solo una aplicación. Es una superficie de ataque compuesta por modelo, prompts, memoria, fuentes de datos, conectores, herramientas externas, identidades y, en no pocos casos, automatización con capacidad de ejecutar acciones. Dicho sin rodeos: el riesgo no está solo en lo que el modelo dice, sino en lo que puede leer, recordar, decidir y hacer.

Ese matiz cambia por completo el mapa de control. Un CRM clásico no suele reinterpretar instrucciones embebidas en un PDF. Un LLM conectado a una base documental, sí. Un portal corporativo tradicional no suele sintetizar respuestas a partir de varias fuentes con distinto nivel de confianza. Un sistema RAG, sí. Un workflow automatizado no siempre convierte una instrucción en lenguaje natural en una acción con privilegios. Un agente con herramientas, sí. Por eso el riesgo LLM no encaja bien en los controles heredados si estos se limitan a autenticación, hardening y revisión de proveedores.

NIS2 lo aborda indirectamente con bastante claridad. El artículo 21.2 menciona, entre otras medidas, el análisis de riesgos, la gestión de incidentes, la continuidad del negocio, la seguridad de la cadena de suministro, la seguridad en adquisición, desarrollo y mantenimiento, y políticas para evaluar la eficacia de las medidas. Todo eso aplica de lleno a arquitecturas LLM. DORA hace algo parecido desde el ángulo financiero: el artículo 6 exige un marco interno de gestión del riesgo TIC sólido, documentado y revisado; el artículo 9 se centra en protección y prevención; el artículo 11 en detección; el artículo 15 en respuesta y recuperación; el artículo 17 en aprendizaje y evolución. Si tu asistente basado en IA tiene acceso a datos de clientes, bases de conocimiento críticas o acciones operativas, entra en ese perímetro aunque el proveedor de turno lo venda como “copilot”.

ISO 27001:2022 aporta el lenguaje de control más útil para aterrizarlo. El Anexo A incluye, entre otros, control de identidades y autenticación, gestión de acceso a la información, registros de actividad, prevención de fuga de datos, codificación segura, seguridad de servicios en la nube, monitorización, gestión de configuración y relaciones con proveedores. El regulador no te va a pedir que cites OWASP de memoria. Sí te va a pedir que expliques cómo esos controles cubren un riesgo emergente concreto. Ahí es donde muchos programas de IA se quedan en la orilla.

Prompt injection: cuando el texto deja de ser contenido y pasa a ser instrucción

Si hubiera que elegir una categoría del OWASP Top 10 que más confusión genera en equipos no técnicos, sería prompt injection. Se sigue tratando como si fuera una variante exótica del phishing. No lo es. Es una ruptura del límite entre datos e instrucciones. Y cuando un sistema LLM consume correo, web, PDFs, tickets, repositorios o documentos de terceros, esa ruptura deja de ser anecdótica.

El patrón es conocido: el atacante introduce texto diseñado para reconfigurar el comportamiento del modelo, anular instrucciones del sistema, exfiltrar contexto, o inducir a que el modelo ejecute una herramienta indebida. En un chatbot aislado, el impacto puede quedarse en una respuesta absurda. En un asistente conectado a correo, CRM, Jira, SIEM, repositorios o pasarelas de pago, el impacto escala a fuga de datos, fraude interno o sabotaje operativo. El problema se agrava en entornos RAG, donde la organización cree que el contenido indexado es “solo conocimiento” y olvida que el LLM puede tratarlo como señal prioritaria.

Desde la óptica regulatoria, prompt injection toca varias teclas a la vez. NIS2 artículo 21.2, letras b), d) y f), encaja porque hablamos de gestión de incidentes, continuidad y seguridad en adquisición/desarrollo. DORA artículo 9 sobre protección y prevención exige mecanismos que limiten el impacto de fallos de procesamiento y de accesos indebidos. ISO 27001 conecta con controles de desarrollo seguro, separación de entornos, monitorización y seguridad de aplicaciones.

¿Qué controles funcionan de verdad? Primero, separación estricta entre instrucciones del sistema, contexto recuperado y entrada del usuario. Parece obvio; no siempre se implementa. El modelo y la capa de orquestación deben etiquetar y aislar esos planos, no concatenarlos como un bloque de texto y confiar en la buena voluntad estadística del LLM. Segundo, permitir solo herramientas explícitamente autorizadas, con parámetros validados y políticas por identidad y caso de uso. Si un agente puede “hacer cosas”, necesita un motor de autorización fuera del modelo. Tercero, saneado y clasificación del contenido recuperado: reputación de fuentes, listas de confianza, límites por origen, detección de instrucciones embebidas y cuarentena de documentos no verificados. Cuarto, pruebas específicas de prompt injection antes de producción y de forma recurrente. No una demo bonita con preguntas educadas, sino escenarios hostiles: documentos con instrucciones ocultas, URLs manipuladas, cadenas de texto diseñadas para romper policy, intentos de tool hijacking y exfiltración de secretos.

La evidencia de control importa tanto como el control. Un auditor interno o un supervisor serio no debería conformarse con “tenemos un framework de red teaming”. Lo que necesitas conservar es otra cosa: casos de prueba versionados, resultados por release, tasa de bloqueo, reglas de enrutado de herramientas, cambios aprobados en system prompts, repositorio de fuentes confiables, y registros que muestren cuándo una petición intentó invocar una acción no permitida y cómo fue bloqueada. Si eso no existe, el control está más cerca de la fe que de la seguridad.

Telemetría mínima recomendable: logs de prompts y respuestas con redacción de datos sensibles; metadatos de origen de contexto RAG; tool calls emitidas, denegadas y ejecutadas; hash o versión del prompt de sistema; identidad de usuario y servicio; clasificación de documentos recuperados; y alertas por patrones de inyección conocidos. Ojo con la retención: si guardas prompts completos, el propio sistema de logs puede convertirse en un almacén de datos sensibles. Ahí GDPR entra por la puerta de atrás, especialmente los principios del artículo 5 sobre minimización y limitación de conservación, y el artículo 32 sobre seguridad del tratamiento.

Divulgación de información sensible: el riesgo más aburrido, y precisamente por eso el más frecuente

La mayoría de incidentes con IA generativa no necesitan una novela técnica. Un empleado pega datos de clientes en un asistente público. Un chatbot interno recupera documentos con datos personales o secretos comerciales sin filtrar por permisos. Un modelo afinado con tickets históricos memoriza fragmentos reutilizables. Y ya está. Nada glamuroso, pero perfectamente suficiente para desencadenar un incidente notificable.

OWASP lo recoge como sensitive information disclosure. En la práctica europea, este riesgo cruza cuatro planos: privacidad, secreto empresarial, resiliencia operativa y deber contractual con terceros. Si el sistema procesa datos personales, GDPR es frontal: artículo 5 sobre minimización y limitación de finalidad, artículo 25 sobre privacidad desde el diseño y por defecto, artículo 28 si interviene un encargado del tratamiento, artículo 32 sobre medidas de seguridad, y artículo 33 si hay violación de seguridad con notificación en 72 horas. Si hablamos de entidades financieras, DORA vuelve a aparecer porque una fuga de información crítica puede ser también un incidente TIC grave, con obligaciones de clasificación, gestión y, en su caso, notificación bajo el régimen sectorial aplicable y los RTS/ITS relacionados con incidentes.

El control clave aquí no es “prohibir pegar datos sensibles”, aunque media organización siga fingiendo que con una política basta. El control real es una combinación de arquitectura y gobierno de datos. Primero, segmenta casos de uso por sensibilidad. Un asistente para redactar correos comerciales no necesita tocar expedientes de clientes ni documentación de operaciones. Parece elemental. Aun así, muchas compañías abren el grifo entero y luego piden a los usuarios prudencia. Segundo, aplica filtrado y clasificación antes de que el dato llegue al modelo: DLP en prompts y archivos adjuntos, detección de PII, secretos y credenciales, etiquetado por nivel de sensibilidad y bloqueo contextual. Tercero, impón control de acceso a nivel de documento y atributo en arquitecturas RAG. El modelo nunca debería convertirse en una vía lateral para saltarse permisos que sí existen en SharePoint, Confluence o el ECM corporativo. Cuarto, utiliza técnicas de seudonimización o tokenización en flujos donde la semántica permita preservar utilidad sin exponer identidad. Quinto, decide contractual y técnicamente si los datos de entrada y salida se usan para entrenamiento, ajuste o mejora del servicio. “Depende del proveedor” no es una respuesta de gobierno; es una admisión de pereza.

ISO 27001 aquí es muy concreta: clasificación de la información, prevención de fuga de datos, control de acceso, seguridad en el uso de servicios cloud, y registros. NIS2 artículo 21 también ampara medidas de seguridad de cadena de suministro y de gestión de activos. Traducido: si no sabes qué datos entran, dónde se procesan, qué proveedor los toca y con qué finalidad adicional, no estás gestionando el riesgo. Estás externalizando la incertidumbre.

¿Qué evidencia debería existir? Inventario de casos de uso con base legal y categorías de datos; decisión documentada de si cada flujo admite datos personales o secretos; evaluaciones de impacto cuando proceda; contratos y anexos de tratamiento; configuración de opt-out de training si el proveedor la ofrece; políticas DLP aplicadas a prompts, archivos y salidas; matrices de permisos del RAG; pruebas que demuestren que un usuario no puede recuperar documentos fuera de su scope; y revisión periódica de logs para detectar exposición accidental. Si operas en varios países, añade localización de procesamiento y transferencias internacionales. Ahí la discusión deja de ser técnica y pasa a ser jurisdiccional, que suele ser el momento en que la sonrisa del equipo de producto desaparece.

Envenenamiento de datos y modelo: el problema no es solo que el LLM se equivoque, sino por qué se equivoca

Data poisoning y model poisoning son categorías menos visibles para el usuario final, pero más peligrosas a medio plazo. Un sistema RAG que consume documentación no verificada, un pipeline de fine-tuning alimentado con datos internos contaminados, o una base de conocimiento mantenida por múltiples áreas sin control de integridad puede terminar produciendo respuestas sesgadas, manipuladas o inseguras. Y el peor detalle es este: el error parece “plausible”. No grita. Se infiltra.

En un banco, una aseguradora o una fintech, el impacto no se limita a desinformar al usuario. Puede traducirse en decisiones operativas erróneas, fraude, tratamiento incoherente de clientes, incumplimientos contractuales o degradación de controles internos. Si el agente recomienda saltarse una verificación porque su corpus contiene un procedimiento obsoleto o manipulado, el incidente ya no es de calidad documental. Es de control interno.

NIS2 artículo 21.2, letras d), e) y f), encaja otra vez: continuidad, seguridad de la cadena de suministro y seguridad en adquisición, desarrollo y mantenimiento. DORA refuerza la necesidad de controlar integridad, disponibilidad y resiliencia de activos TIC críticos. ISO 27001 ofrece un arsenal bastante útil: gestión de cambios, protección contra malware y alteraciones, seguridad del desarrollo, segregación de funciones, registros y validación de datos de entrada cuando aplica al sistema.

Los controles efectivos empiezan mucho antes del modelo. La fuente documental de un sistema LLM necesita gobierno de contenido, no simple indexación. Eso implica flujos de aprobación para documentos de alto impacto, versionado, firma o al menos hashing de integridad, trazabilidad de autoría, fechas de vigencia, reglas de expiración y estados de confianza. Un procedimiento de 2021 no debería competir en igualdad semántica con una política aprobada la semana pasada. Tampoco un PDF subido por un tercero sin verificación debería alimentar respuestas sobre procesos críticos. La recuperación debe ponderar confianza, actualidad y autoridad documental, no solo similitud vectorial.

En fine-tuning o entrenamiento adicional, los controles son aún más exigentes: dataset lineage, validación de procedencia, deduplicación, pruebas de toxicidad y sesgo operativo, revisión legal de categorías de datos, y entorno segregado para experimentación. Si una organización no puede responder qué datos se usaron para ajustar el modelo, cuándo, por quién y con qué criterio de exclusión, no está en condiciones de defender la fiabilidad del sistema. Ni ante auditoría, ni ante su consejo, ni ante un juez si la cosa se tuerce.

La telemetría útil aquí incluye: inventario de fuentes de entrenamiento y recuperación, huellas de integridad de documentos, cambios en datasets, métricas de drift en calidad de respuesta, alertas por variación anómala en citación de fuentes, y resultados de pruebas comparativas por versión. Un buen indicador operativo es la trazabilidad de respuesta: qué documentos se usaron, con qué score, en qué versión del índice y con qué política de ranking. Si tu aplicación no puede explicar eso, hablar de “IA fiable” queda bastante ornamental.

Plugins, herramientas y agentes: donde el riesgo deja de ser conversación y se convierte en ejecución

La categoría de autorización insegura en plugins, herramientas o agentes es probablemente la más subestimada por equipos de compliance. Se sigue pensando en el LLM como interfaz. Pero cuando el sistema puede consultar correo, crear tickets, aprobar operaciones, modificar calendarios, lanzar scripts o invocar APIs internas, el modelo pasa de charlatán a operador. Y un operador con privilegios ambiguos es una vieja pesadilla con envoltorio nuevo.

OWASP lleva razón al señalar el riesgo, pero se queda corto si no se añade una regla de oro: el modelo nunca debe ser el decisor final de autorización. Puede proponer una acción. No debe decidir si está autorizada. Esa decisión debe recaer en un motor de políticas externo, con identidad fuerte, contexto, segregación de funciones y registro verificable.

Esto conecta de forma muy directa con DORA. El artículo 6 exige gobernanza interna clara; el artículo 9 pide medidas de protección y prevención adecuadas; el artículo 13 habla de gestión de continuidad y recuperación; y el artículo 28 abre todo el capítulo de gestión del riesgo de terceros TIC. Si el agente usa herramientas de un proveedor SaaS, una plataforma de automatización o APIs externas, la cadena de dependencia ya no es una nota al pie. Es parte del riesgo operativo. NIS2 también lo cubre de forma explícita con la cadena de suministro en el artículo 21.2, letra d).

Los controles que sí marcan diferencia son bastante concretos. Uno: identidad por workload y por herramienta, con credenciales separadas y rotadas, no un token maestro compartido por “el agente”. Dos: autorización granular por acción, recurso y contexto, idealmente con just-in-time permissions y aprobación humana para operaciones irreversibles o de alto impacto. Tres: allowlists de herramientas y esquemas de parámetros estrictamente validados; si una tool acepta texto libre sin validación, has abierto una autopista a abuso indirecto. Cuatro: segregación entre funciones de lectura, recomendación y ejecución. Cinco: límites transaccionales y circuit breakers. Un agente no debería poder enviar 500 correos, abrir 300 tickets o modificar reglas críticas sin umbrales, alertas y capacidad de parada inmediata.

La prueba de madurez está en la evidencia. Querrás ver catálogos de herramientas autorizadas, matrices RACI por caso de uso, logs de invocación con identidad y resultado, reglas de aprobación humana, límites configurados, revisiones de privilegios y simulaciones de abuso. Si además tienes registros de acciones propuestas frente a acciones ejecutadas, mejor aún: permiten demostrar que el sistema no actúa por libre. Sin eso, “human in the loop” puede significar cualquier cosa, incluida ninguna.

Hay una ironía regulatoria aquí. Muchas entidades llevan años afinando segregación de funciones en ERP, pagos o administración de sistemas. Luego llega un agente de IA y se le otorgan permisos horizontales porque “solo ayuda a automatizar”. Ayuda, sí. También ayuda a saltarse controles si nadie pone freno.

Dependencia excesiva y alucinaciones: cuando el mayor fallo no está en el modelo, sino en la pereza humana

OWASP incluye overreliance porque sabe algo que las demos comerciales prefieren callar: cuanto más fluida y segura parece la respuesta, más fácil es que el usuario delegue criterio sin darse cuenta. Ese riesgo no se arregla con un banner que diga “la IA puede cometer errores”. Se arregla rediseñando el proceso.

En entornos regulados, la dependencia excesiva no es un asunto filosófico. Es un fallo de control interno. Si un analista usa un LLM para resumir alertas del SOC, clasificar reclamaciones, redactar comunicaciones regulatorias o proponer decisiones de fraude, necesitas determinar qué tareas admiten automatización asistida y cuáles exigen validación humana sustantiva. No nominal. Sustantiva. Un clic de “aceptar” sin revisión real no es supervisión; es outsourcing cognitivo barato.

La conexión con NIS2 es menos textual, pero sigue siendo sólida: políticas de análisis de riesgos, formación, higiene de seguridad y evaluación de eficacia de controles en el artículo 21. DORA, desde la lógica de resiliencia, obliga a que los procesos críticos mantengan integridad y capacidad de respuesta ante fallos tecnológicos. ISO 27001 también encaja mediante competencia, procedimientos operativos, revisión, segregación y control de cambios.

Operativamente, hace falta un mapa de decisiones. Qué salidas del LLM son informativas, cuáles son recomendacionales y cuáles podrían desencadenar una acción. Para cada nivel, define umbral de confianza, necesidad de cita a fuente, obligatoriedad de doble revisión, tolerancia al error y mecanismo de escalado. Un generador de borradores para políticas internas puede tolerar bastante. Un asistente para comunicaciones a clientes sobre productos financieros, bastante menos. Un agente que apoye investigación de fraude o ciberincidentes, menos todavía.

Las evidencias relevantes son menos vistosas, pero decisivas: procedimientos de revisión humana por caso de uso, métricas de aceptación frente a corrección de respuestas, muestreos de calidad, listas de tareas prohibidas para automatización autónoma, formación específica a usuarios y pruebas de competencia. Si el sistema genera recomendaciones en ámbitos sensibles, conviene registrar la fuente citada, la intervención humana y la justificación de decisiones cuando se apartan del procedimiento estándar. Eso ayuda tanto a auditoría como a defensa jurídica posterior.

Un detalle útil: medir el ratio de correcciones humanas por tipo de tarea da una señal temprana de dos problemas distintos. Si es demasiado bajo, quizá la gente está confiando de más. Si es demasiado alto, el caso de uso probablemente no compensa el riesgo ni el coste operativo. Ambas conclusiones sirven. Una evita un incidente. La otra evita una inversión absurda.

Supply chain de IA: el tercero crítico no siempre es quien firma el contrato principal

Uno de los puntos más flojos en programas de IA generativa está en la cadena de suministro. La organización cree contratar “un modelo” y en realidad depende de una constelación de servicios: proveedor base, hosting cloud, embeddings, bases vectoriales, filtros de seguridad, herramientas de observabilidad, datasets externos, servicios de anotación y conectores. Si falla uno, filtra uno o cambia sus condiciones uno, el riesgo operativo cambia para todos.

Esto no es una sutileza jurídica. DORA dedica su capítulo V a la gestión del riesgo de terceros TIC, empezando por el artículo 28. Las entidades financieras deben gestionar el riesgo derivado de proveedores TIC, mantener un registro de acuerdos contractuales y evaluar dependencias, concentración y criticidad. Si el caso de uso LLM apoya funciones críticas o importantes, el estándar sube. Mucho. NIS2, por su parte, exige tener en cuenta vulnerabilidades específicas de cada proveedor y la calidad general de sus productos y prácticas en la cadena de suministro dentro del artículo 21.2, letra d).

El control correcto no es pedir un SOC 2 y darlo por bueno. Necesitas mapear la cadena técnica real: quién hospeda el modelo, dónde se procesan prompts y salidas, si hay retención, si se usan para entrenamiento, qué subencargados intervienen, qué mecanismos de cifrado y segregación existen, qué opciones de residencia regional hay, cómo se notifican incidentes, qué SLAs cubren degradación de servicio y qué derecho de auditoría o al menos de evidencia puedes exigir. Si el proveedor cambia de modelo, versión, región o política de uso de datos sin un proceso de change management consumible por tu organización, tienes un problema de gobierno, no solo de procurement.

Aquí conviene ser pragmático. No todos los proveedores van a darte transparencia perfecta. Pero sí puedes elevar el listón en funciones críticas: evaluación de criticidad, due diligence técnica y legal, pruebas de salida, clauses contractuales sobre uso de datos, requisitos de notificación, opciones de desactivación, portabilidad razonable y planes de contingencia. El mito de la “comodidad cloud” se lleva mal con los artículos de DORA cuando la dependencia se vuelve estructural.

Evidencias a conservar: inventario de proveedores y subproveedores asociados al caso de uso, evaluación de criticidad, análisis de concentración, cuestionarios de seguridad, anexos contractuales, decisión sobre residencia de datos, reportes de incidentes del proveedor, pruebas de continuidad y registro de cambios de versión o arquitectura. Si nadie ha unido esas piezas en un expediente coherente, el día que pregunten por el riesgo de terceros de tu despliegue LLM la reunión se va a alargar bastante más de lo deseable.

Lo que un auditor querrá ver: evidencias, no promesas

Hablar de “gobernanza de IA” es fácil. Demostrar que existe, bastante menos. Si el despliegue de LLM toca datos sensibles, procesos críticos o servicios regulados, la conversación de auditoría va a bajar rápido del PowerPoint al registro. Y con razón.

La forma más útil de preparar esa conversación es agrupar evidencias por familias de control, no por tecnología. Eso permite reutilizar el trabajo entre seguridad, cumplimiento, auditoría interna y, si hace falta, supervisión externa.

Checklist de evidencias para auditoría

• Gobernanza y alcance: inventario de casos de uso LLM; clasificación por criticidad; propietario de negocio y propietario técnico; decisión documentada sobre datos permitidos; aprobación del comité correspondiente.
• Arquitectura y diseño seguro: diagramas actualizados de flujo de datos; separación entre prompt de sistema, input de usuario y contexto RAG; catálogo de herramientas habilitadas; matrices de permisos por caso de uso.
• Protección de datos y confidencialidad: evaluación de impacto si procede; contratos de encargado o subencargado; configuración sobre uso de datos para entrenamiento; políticas DLP en entrada y salida; pruebas de redacción o bloqueo.
• Seguridad del desarrollo y pruebas: resultados de pruebas de prompt injection; test de fuga de datos; validación de parámetros de herramientas; revisiones de código y cambios; entornos segregados para experimentación y producción.
• Operación y monitorización: logs de prompts y respuestas con minimización; trazabilidad de documentos recuperados; registros de tool calls y acciones bloqueadas; alertas por anomalías; cuadro de mando de métricas de calidad y seguridad.
• Cadena de suministro: inventario de proveedores y subproveedores; evaluación de criticidad; SLAs; condiciones de notificación de incidentes; residencia de datos; evidencias de revisión periódica.
• Continuidad y respuesta: procedimiento de desconexión o degradación segura; runbooks de incidente; pruebas de conmutación o fallback; lecciones aprendidas incorporadas en cambios de control.
• Supervisión humana y formación: procedimientos de revisión por caso de uso; tareas vetadas para ejecución autónoma; formación específica a usuarios; métricas de corrección humana y excepciones.

Ningún auditor razonable te pedirá perfección. Sí pedirá coherencia entre riesgo, control y evidencia. Si un caso de uso es crítico y tu prueba principal es una política genérica de IA responsable, el diagnóstico será severo. Y merecido.

Implicaciones para entidades financieras españolas

Para banca, seguros, gestoras, entidades de pago y proveedores TIC que dan soporte al sector financiero en España, el asunto tiene dos capas. La primera es europea: DORA es aplicable desde el 17 de enero de 2025. A partir de ahí, la conversación sobre resiliencia digital ya no admite demasiadas excusas juveniles. La segunda es supervisora: Banco de España, CNMV y DGSFP no necesitan publicar una “circular de moda sobre LLM” para preguntar por gobierno TIC, terceros críticos, registro de incidentes, continuidad o outsourcing encubierto. Les basta con usar el marco que ya tienen.

Eso cambia la prioridad. Un asistente interno para productividad general quizá se gestione con controles estándar reforzados. Un caso de uso LLM en operaciones, atención al cliente, prevención del fraude, cumplimiento normativo o soporte a funciones críticas o importantes merece tratamiento de riesgo TIC formal dentro del marco DORA. Eso implica inventario, clasificación, pruebas, gestión de terceros, trazabilidad y capacidad de desconexión controlada. Si además procesa datos personales a escala o categorías delicadas, GDPR aprieta por su lado.

Hay otro ángulo muy español: la fragmentación tecnológica. Muchas entidades medianas están desplegando IA generativa mediante capas añadidas sobre plataformas documentales, suites colaborativas, automatización low-code y proveedores cloud globales. El riesgo no suele venir del modelo en abstracto, sino del mosaico. Un conector mal configurado en Microsoft 365, una base vectorial montada deprisa, un flujo de Power Automate con permisos excesivos o un bot de atención con conocimiento heredado sin limpiar pueden crear un incidente igual de serio que una brecha clásica. Solo que con más confusión interna cuando toque explicarlo.

¿Tu entidad ya tiene esto resuelto? La prueba es sencilla: intenta reconstruir, para un caso de uso concreto, qué datos entraron, qué documentos se recuperaron, qué reglas de permiso aplicaban, qué proveedor procesó la petición, qué versión del prompt o del modelo estaba activa, y si una acción ejecutada requirió aprobación humana. Si responder lleva más de una tarde y media docena de equipos, la gobernanza aún no está madura.

Qué controles priorizar primero si ya tienes LLM en producción

No hace falta rehacer toda la arquitectura para mejorar de verdad. Pero sí conviene evitar la tentación de desplegar “capas éticas” abstractas mientras los riesgos operativos básicos siguen abiertos.

La prioridad uno es descubrir el alcance real. Qué aplicaciones usan LLM, con qué proveedores, qué datos tocan, qué herramientas invocan y qué procesos soportan. Sin ese inventario, cualquier programa de control está cojo. La prioridad dos es contener los flujos sensibles: DLP, clasificación, permisos efectivos en RAG y bloqueo de acciones de alto impacto sin aprobación externa al modelo. La prioridad tres es instrumentar telemetría útil. Lo que no se registra no se puede probar, ni mejorar, ni defender. La prioridad cuatro es someter cada caso de uso a pruebas hostiles, no solo funcionales. Y la quinta es ordenar la cadena de terceros antes de que la dependencia sea irreversible.

Todo esto debería integrarse en tus mecanismos existentes de gestión del riesgo TIC, no en una isla de “IA”. Ese es el error más caro: crear una gobernanza paralela, simpática y decorativa, mientras seguridad, procurement, privacidad y continuidad siguen operando por separado. DORA y NIS2 no te piden un comité exótico. Te piden control efectivo.

La lección de fondo: el riesgo LLM no es nuevo; lo nuevo es la velocidad con la que se vuelve operativo

OWASP ha hecho un favor útil al poner nombre a los fallos más comunes en aplicaciones LLM. Pero el verdadero trabajo empieza después de leer la lista. Prompt injection es, en esencia, un problema de separación de confianza y validación. La fuga de datos, de gobierno de información y arquitectura. El envenenamiento, de integridad y procedencia. La autorización insegura, de IAM y segregación de funciones. La dependencia excesiva, de diseño de proceso y supervisión humana. Es decir: los viejos problemas de siempre, reempaquetados en una interfaz que parece inteligente y acelera tanto la adopción como el accidente.

La ironía es bastante transparente. El discurso comercial sobre IA promete quitar fricción. El regulatorio exige añadirla en los puntos correctos: permisos, revisión, trazabilidad, pruebas, límites, evidencias. Y por una vez el regulador tiene razón. La fricción bien puesta no mata el caso de uso; evita que acabe en comité de crisis.

Si eres CISO o responsable de cumplimiento, no necesitas convertirte en evangelista ni en agorero. Necesitas hacer algo más sobrio y bastante más útil: tratar cada aplicación LLM como un sistema socio-técnico con datos, identidades, terceros, decisiones y capacidad de impacto operacional. Luego mapear el riesgo a controles existentes, exigir evidencia verificable y cerrar el hueco entre la demo y la realidad. Parece menos brillante que hablar de agentes autónomos. También es mucho más eficaz cuando llegue la auditoría. O el incidente. O, con un poco de mala suerte, ambos a la vez.