Hay dos documentos de OWASP sobre seguridad de LLM y se confunden constantemente. Uno es el OWASP Top 10 for LLM Applications, la lista de los diez riesgos técnicos, de la inyección de prompts al consumo sin límites. El otro es el LLM Applications Cybersecurity and Governance Checklist, que va por la versión 1.1 y no habla de ataques concretos, sino de qué tiene que tener montado una organización antes y durante la adopción de LLM.
El segundo es el que casi nadie ha leído. Parte de la culpa es del nombre: circula como LLM AI Security & Governance Checklist, como LLM AI Cybersecurity & Governance Checklist y ahora como LLM Applications Cybersecurity and Governance Checklist. Tres etiquetas para el mismo PDF, lo que complica hasta buscarlo.
Dos documentos, dos lectores
El Top 10 lo lees si construyes o auditas el sistema. El checklist lo lees si tienes que decidir si tu empresa adopta LLM y responder por esa decisión: dirección, seguridad, legal, cumplimiento normativo. Está pensado para acompañar una estrategia de adopción, no para pasarlo como test de penetración.
Eso cambia el tipo de pregunta. El Top 10 pregunta si un atacante puede envenenar tu corpus. El checklist pregunta si sabes qué modelos hay desplegados en tu organización, quién los aprobó y qué pasa el día que uno falle. Son preguntas de niveles distintos y ninguna sustituye a la otra.
Las trece áreas
El documento se organiza en trece bloques numerados del 1 al 13. Sobre el papel parecen una lista plana, pero caen en cuatro grupos según el trabajo que suponen y según quién lo hace.
Entender la exposición, áreas 1 y 2
El riesgo adversario mira hacia fuera: qué está haciendo la competencia con IA, qué están haciendo los atacantes y qué expone tu propio despliegue. Incluye una comprobación que casi nadie hace, que es revisar los proveedores actuales por si han metido funciones de IA en un producto que ya tenías contratado. Ahí suele aparecer más superficie nueva que en los proyectos propios.
El modelado de amenazas mira hacia dentro y es la traducción del ejercicio de siempre a un sistema que lee texto y actúa. Quién puede llegar al modelo, qué puede inyectar en su contexto, qué herramientas puede invocar y con qué credenciales. Si ya tienes un proceso de modelado de amenazas, esto es una extensión, no un proceso nuevo.
Saber qué tienes, áreas 3 y 4
El inventario de activos de IA es el área más incómoda y la que más rápido se rompe. Qué modelos, qué integraciones, qué datos entran y salen, quién es el dueño de cada pieza. La primera versión siempre sale incompleta, porque hay despliegues que nadie registró y funciones de IA dentro de herramientas SaaS que se activaron solas en una actualización.
La formación en seguridad y privacidad de IA es la otra mitad. No es un curso de concienciación genérico: es que la gente que usa y opera estos sistemas sepa qué no debe pegar en un prompt y qué significa que una salida sea plausible pero falsa. En Europa además hay una obligación detrás, el artículo 4 del Reglamento de IA, que aplica desde febrero de 2025 y no espera a ninguna de las prórrogas.
Decidir y responder, áreas 5 a 8
Los casos de negocio piden por qué se adopta, qué se espera de ello y contra qué se compara. Suena a relleno de consultora y es lo que evita el despliegue que nadie sabe justificar seis meses después, cuando toca renovar la licencia.
La gobernanza define quién decide, quién aprueba y quién responde, con políticas de uso aceptable, roles asignados y una vía para escalar incidentes. La parte legal cubre contratos, propiedad intelectual, responsabilidad por la salida del modelo, garantías con proveedores y qué pasa con los datos que le mandas a una API de terceros. Y la parte regulatoria es saber qué normativa te alcanza y desde cuándo, que en Europa significa el Reglamento (UE) 2024/1689, el RGPD y, según el sector, NIS2.
Son las cuatro que más se parecen a trabajo de comité, y también las que dejan rastro documental. Es el material que luego se reutiliza en cualquier proyecto de cumplimiento.
Construir y comprobar, áreas 9 a 13
El área de uso o implementación de soluciones LLM ordena los controles según cómo consumas el modelo, porque no es lo mismo llamar a una API pública que ajustar un modelo propio o montarlo en tu infraestructura. Cada opción mueve el riesgo de sitio en vez de quitarlo.
El TEVV (testing, evaluación, verificación y validación) insiste en que la comprobación es un proceso continuo, no una foto en el momento del lanzamiento. Métricas, umbrales y alguien que los revise cuando el modelo cambia por debajo, que en un proveedor gestionado pasa sin avisar.
Las model cards y risk cards documentan qué hace el modelo, con qué se entrenó, dónde falla y qué riesgos conocidos arrastra, en un formato que alguien de fuera del equipo pueda leer. El área de RAG lo trata como la vía habitual para mejorar respuestas sin reentrenar, con sus implicaciones propias sobre el corpus y los permisos de recuperación.
Cierra el AI red teaming: atacar el sistema a propósito y de forma estructurada. El documento avisa de que no sustituye al resto de controles, y tiene razón. Un red team sobre una organización que no sabe qué modelos tiene solo produce una lista de sorpresas. El detalle de cómo se organiza ese ejercicio está en qué es el AI red teaming.
Dónde se queda corto
Es un buen punto de partida y tiene un problema de fondo: casi todo son preguntas, no umbrales. "Ten un inventario de activos de IA" no dice cuándo un inventario es suficiente. Eso está bien para abrir la conversación en un comité y mal para cerrarla.
El otro hueco es que las áreas técnicas y las de gobierno están al mismo nivel, así que un equipo puede marcar doce casillas de proceso y no haber probado nunca si su agente ejecuta instrucciones que le llegan dentro de un documento. Por eso conviene leerlo junto al Top 10 para aplicaciones LLM, que es donde están los fallos concretos con su prueba de concepto.
Qué te sirve para el Reglamento de IA
Buena parte de lo que pide el checklist es, con otro nombre, material que el Reglamento (UE) 2024/1689 va a exigir a un sistema de alto riesgo. No es una equivalencia, pero el solape basta para que el trabajo no se tire.
Lo que no aparece por ningún lado es la parte formal: la evaluación de conformidad, la declaración UE, el marcado CE, el registro en la base de datos de la UE y el seguimiento posterior a la comercialización. Cumplir el checklist no te hace conforme al Reglamento. Lo que hace es que el proyecto de cumplimiento arranque con material real en vez de con una hoja en blanco.
Sobre plazos: el aplazamiento del Digital Omnibus movió el grueso del régimen de alto riesgo a diciembre de 2027 y agosto de 2028, y las fechas exactas están en el calendario de aplicación. Eso da margen para hacer el trabajo con calma, no para no hacerlo.
Por dónde empezar
Si tienes que elegir una sola área, la 3. El inventario de activos de IA es la que desbloquea las demás y la que más gente descubre que no tiene. En cuanto lo montas aparecen los despliegues que nadie aprobó, que es exactamente la información que hace falta antes de decidir nada.
Después, la parte técnica. Tenemos una versión operativa del Top 10 con verificaciones binarias y mapeo regulatorio en el checklist OWASP LLM: la misma que aplicamos en auditoría, para que puedas pasarla tú.
Fuente: OWASP Gen AI Security Project, LLM Applications Cybersecurity and Governance Checklist v1.1, disponible en genai.owasp.org.