Seguridad de los modelos de lenguaje grande (LLM): protección de la pila de capas que hay detrás de una aplicación de LLM

La seguridad de los modelos de lenguaje a gran escala (LLM) consiste en proteger una aplicación basada en un modelo de lenguaje a gran escala en todas las capas que la sustentan: el modelo, las indicaciones y el contexto recuperado que consume, el servidor de inferencia que lo ejecuta, el software de orquestación que lo redirige y el código que gestiona lo que devuelve. En este contexto, «LLM» hace referencia a los modelos de lenguaje a gran escala, y no al título de posgrado en Derecho.

La mayoría de las directrices publicadas sobre este tema se limitan al modelo. Esta página empieza donde acaba el modelo. Las capas subyacentes —es decir, el servidor de inferencia, el marco de computación distribuida, el almacén de recuperación y la pasarela que las precede— son software convencional con identificadores CVE habituales, versiones corregidas y, en varios casos, plazos federales para la corrección de vulnerabilidades. Esa es la parte sobre la que un equipo de seguridad puede actuar esta misma semana.

Qué abarca la seguridad de los modelos de lenguaje grande (LLM) y en qué se centra esta página

Un modelo de lenguaje a gran escala es un modelo entrenado con corpus de texto muy extensos para predecir y generar texto. En un entorno empresarial, casi nunca funciona de forma aislada. Se encuentra detrás de una API, utiliza documentos recuperados, invoca herramientas y devuelve resultados que otros programas consumen. Cada una de esas conexiones es un punto en el que puede surgir un problema, y solo algunas de ellas tienen que ver directamente con el modelo.

Esa es la distinción que la mayoría de las guías no aclara. La seguridad del modelo y la protección del modelo se solapan, pero no son lo mismo. El análisis técnico de Red Hat sobre los riesgos de los sistemas LLM, publicado el 18 de noviembre de 2024, establece una distinción clara: «Si un sistema LLM utiliza la salida de otro LLM y ello afecta negativamente a la confidencialidad, la integridad o la disponibilidad, entonces se crea una vulnerabilidad de seguridad». Un modelo que devuelve una respuesta sesgada o errónea presenta un problema de seguridad. Un modelo cuya respuesta se pasa sin filtrar a un comando de shell, una consulta a una base de datos o una llamada a una API con privilegios presenta un problema de seguridad, y ese problema reside en el componente que confió en la salida.

Esta página aborda la pila que aloja el modelo y su alcance es deliberadamente limitado. La taxonomía completa de riesgos forma parte de la seguridad de la IA generativa. La profundidad de la inyección de prompts pertenece a prompt injection. La cobertura global pertenece a la seguridad de la IA, y las pruebas adversarias pertenecen al «red teaming» de la IA. Lo que encontrarás aquí es un inventario capa por capa, las vulnerabilidades identificadas en cada una de esas capas, la información que emite la aplicación y que el equipo de seguridad puede utilizar, y cómo interpretar las cifras que te facilita un proveedor.

La pila de aplicaciones de la LLM, capa por capa

Una aplicación de LLM tiene aproximadamente ocho capas de profundidad, y la bibliografía sobre clasificación dedicada a este tema abarca unas tres de ellas. Las capas con las que trabaja un desarrollador están muy bien documentadas. Las capas de las que se encarga el equipo de operaciones, en cambio, apenas se mencionan.

• Modelo. Los pesos y la arquitectura entrenados que generan texto.
• Solicitud y contexto. La solicitud del sistema, la entrada del usuario y todo lo demás se recopilan en la ventana de contexto.
• Recuperación y almacenamiento vectorial. El corpus de documentos y la base de datos de representaciones a las que se consulta el modelo antes de dar una respuesta. En un asistente potenciado por la recuperación, el corpus constituye el límite de seguridad, no la interfaz de chat.
• Llamadas a herramientas y funciones. Las funciones que el modelo está autorizado a invocar y los privilegios asociados a ellas.
• Servidor de inferencia. El servicio que carga el modelo en memoria y responde a las solicitudes que se le envían.
• Orquestación y computación distribuida. El software que canaliza las solicitudes, distribuye el trabajo entre los equipos y conecta los modelos con las herramientas y los datos.
• Artefacto de modelo y serialización. El formato de archivo en el que se entregan los pesos y el código que los deserializa.
• Gestión de resultados. El código que procesa lo que devuelve el modelo.

Los desarrolladores se encargan de las cuatro primeras. Los equipos de plataforma y operaciones se encargan de las tres siguientes, y la gestión de la salida suele corresponder al equipo de aplicaciones que la haya configurado. Esa división es importante, ya que las capas que contienen CVE se sitúan casi en su totalidad en el ámbito de las operaciones y, con frecuencia, se implementan sin un responsable de seguridad designado.

Prompt injection, la manipulación del comportamiento del modelo mediante entradas diseñadas específicamente, es el riesgo más conocido en la capa de prompts y contexto, y se trata en profundidad en su propia página, en lugar de aquí. Los puntos finales de inferencia no gestionados o no autorizados dentro de tu entorno son un problema de IA en la sombra antes que un problema de los modelos de lenguaje grande (LLM). Cuando se permite que el modelo actúe en lugar de responder, la capa de llamada a herramientas se convierte en un problema de seguridad relacionado con la IA agentiva.

‍

La capa de servicio y orquestación cuenta con CVE estándar que se pueden modificar.

Todo lo anterior es arquitectura. Esta es la parte sobre la que puedes actuar.

La capa de servicio y orquestación es el único ámbito en el que la seguridad de los modelos de lenguaje grande (LLM) se reduce a tres verbos conocidos: inventariar, aplicar parches y restringir. Estos componentes cuentan con identificadores CVE, versiones corregidas y registros públicos de vulnerabilidades, y varios de ellos tienen plazos federales para su corrección. Nada de esto requiere conocimientos de aprendizaje automático para ponerlo en práctica.

Capa y componente | ID de CVE | Evaluadores y puntuaciones | Versión corregida y estado | Servidor de inferencia,vLLM | CVE-2026-22778 | Dosevaluadores secundarios con una puntuación de 9,8 | CRÍTICO. Sin puntuación primaria del NVD. Afecta a las versiones desde la 0.8.3 hasta la 0.14.1 inclusive; corregido en la 0.14.1. No figura en KEV. Servidor de inferencia,Ollama. CVE-2026-7482. La misma CNA publica un 8,8 (ALTO) según CVSS 4.0 y un 9,1 (CRÍTICO) según CVSS 3.1. Sin puntuación principal del NVD. Corregido en la versión 0.17.1. No presente en el servidor KEVInference, NVIDIATriton. CVE-2026-47627. NVIDIAcomo CNA, 9,8 CRÍTICO según CVSS 3.1. Aún no evaluado por el NVD. Afecta a las versiones 0.0 a 26.05. No está en KEV. Computación distribuida,Ray. CVE-2023-48022. El NISTcomo principal del NVD, 9,8 CRÍTICO. CISA-ADP como secundario, 9,8 CRÍTICO. Etiquetado formalmente como «en disputa». Autenticación por token disponible a partir de la versión 2.52.0. No figura en KEV; prueba de concepto de explotación de SSVC. Computación distribuida,Ray. CVE-2025-62593. NISTcomo NVD principal, 8,8 (ALTO) según CVSS 3.1. GitHub como CNA, 9,4 (CRÍTICO) según CVSS 4.0. Corregido en la versión 2.52.0. Añadida a KEV el 17 de agosto de 2026, con fecha límite el 20 de agosto de 2026. Ciclo de vida del aprendizaje automático,MLflow. CVE-2026-64849. GitHubcomo CNA, 9,3 CRÍTICO según CVSS 3.1. NVD no ha publicado ninguna puntuación principal a pesar de haber marcado el registro como «Analizado». Corregida en la versión 3.15.0. Añadido a KEV el 19/08/2026, fecha límite el 02/09/2026. Pasarela LLM,LiteLLM. CVE-2026-42271. NISTcomo principal del NVD, 8,8 ALTO, vector PR:L, lo que significa un llamante autenticado. Afecta a las versiones 1.74.2 a 1.83.6, corregido en la 1.83.7. Añadido a KEV el 08/06/2026, con fecha límite el 22/06/2026.Asistentecon recuperación mejorada. CVE-2025-32711.Microsoftcomo CNA, 9,3 CRÍTICO. NIST como NVD principal, 7,5 ALTO. No figura en KEV, sin explotación de SSVC.

Leyenda: Vulnerabilidades identificadas en la capa de servicio y orquestación de los modelos de lenguaje grande (LLM), a fecha de 25 de agosto de 2026. Se trata de una muestra con fecha, no de una lista exhaustiva. Texto alternativo: Tabla con ocho vulnerabilidades de la infraestructura de los LLM en la que se muestran la capa y el componente afectados, el identificador CVE, cada organización evaluadora con su puntuación, así como la versión corregida y el estado KEV.

Hay dos aspectos que hacen que esa tabla sea útil. En primer lugar, hay que identificar quién ha otorgado la puntuación. Una puntuación de la Autoridad de Numeración CVE (CNA) no es lo mismo que una puntuación del NVD, y en esta pila suelen discrepar con frecuencia. CVE-2026-7482 tiene una puntuación de 8,8 según CVSS 4.0 y de 9,1 según CVSS 3.1, ambas de la misma CNA, y el NVD no ha publicado ninguna puntuación base independiente a pesar de haber marcado el registro como «Analizado», por lo que «9,1 según el NVD» es incorrecto. En segundo lugar, hay que leer la descripción en lugar del titular. CVE-2026-22778 no es un fallo de ejecución remota de código con un único error: el NVD lo clasifica bajo CWE-209 y CWE-532, ambas vulnerabilidades de divulgación de información, y describe una fuga de direcciones del montón que «puede encadenarse a un desbordamiento del montón con el decodificador JPEG2000 en OpenCV/FFmpeg para lograr la ejecución remota de código».

El volumen en esta capa no es ni marginal ni estático. Un Censo de palabras clave de NVD ejecutado el 25 de agosto de 2026, leyendo el total de resultados campo para cada nombre de producto, devuelve 129 registros para Flowise, 70 para vLLM, 68 para LangChain, 63 para Triton Inference Server, 36 para Ollama, 35 para llama.cpp, 30 para LiteLLM, 18 para SGLang y 4 para TorchServe. Cinco días antes, tres de esas cifras eran inferiores —69, 67 y 32— y ninguna era superior. También se observa una concentración: el 18 de agosto de 2026 se publicaron cinco CVE de NVIDIA Triton Inference Server, encabezadas por CVE-2026-47627 con una puntuación de 9,8 en «CRÍTICO», y las cinco tienen puntuación secundaria, sin ninguna puntuación primaria NVD.

El caso más claro en materia de gobernanza en este ámbito es el de Ray. Dos organismos califican la vulnerabilidad CVE-2023-48022 con un 9,8 (CRÍTICO), y el NVD etiqueta formalmente el registro como «en disputa», ya que la postura del proveedor es que «Ray, tal y como se indica en su documentación, no está diseñado para su uso fuera de un entorno de red estrictamente controlado». Los registros en disputa quedan excluidos de algunos flujos de trabajo de gestión de vulnerabilidades. Ese CVE no figura en el catálogo de Vulnerabilidades Explotadas Conocidas (KEV) de la CISA, y la Categorización de Vulnerabilidades Específicas para Partes Interesadas de la CISA registra su estado de explotación como «prueba de concepto», mientras que MITRE realiza un seguimiento de una campaña que la explota con el nombre de C0045 ShadowRay. Mientras tanto, otra vulnerabilidad de Ray, no controvertida, la CVE-2025-62593, entró en el KEV el 17 de agosto de 2026 con fecha límite el 20 de agosto de 2026, y su corrección es la versión 2.52.0: la versión exacta que el registro controvertido señala como aquella en la que se habilitó la autenticación mediante token. La suposición de «seguridad por implementación» no constituye un control.

KEV es el filtro operativo más preciso en este ámbito. A fecha de 25 de agosto de 2026, el catálogo cuenta con 1.675 registros, de los cuales diez son componentes de la pila LLM: seis registros de Langflow, dos de LiteLLM, uno de Ray y uno de MLflow. Ninguna de las cuatro vulnerabilidades CVE que suele mencionar este tema figura entre ellas. Reestructura tu inventario en torno a la capa de orquestación, en lugar de basarlo en las dos o tres marcas que se repiten en la cobertura.

La exposición en esta capa es real, pero se mide de forma deficiente, y ninguno de los análisis que se muestran a continuación especifica el método utilizado. SecurityWeek, citando a Cyera en mayo de 2026, situó la cifra en «aproximadamente 300 000 servidores de Ollama expuestos actualmente en la Internet pública». Un análisis de junio de 2026 sobre recursos informáticos de IA robados informó de «aproximadamente 175 000 instancias de Ollama expuestas públicamente en más de 130 países». En un informe de análisis cuyos autores indican que corresponde a noviembre de 2024, Trend Micro encontró «más de 3.000 servidores completamente abiertos» y, en el caso de llama.cpp, «80 servidores expuestos, de los cuales 57 no parecían tener ningún tipo de autenticación». SecurityWeek, en su artículo sobre la campaña Ray de noviembre de 2025, recogió el recuento de otra empresa de «más de 230 000 servidores Ray accesibles desde la web». El propio registro de NVD para CVE-2026-7482 no ofrece ninguna cifra y solo indica que se ha «observado una gran exposición en la Internet pública». Considera el rango, las fechas y los métodos que faltan como parte del hallazgo.

La validación del parche es una tarea distinta a su aplicación, y ahí es donde entra en juego el «red teaming» con IA. Considera la tabla como algo perecedero: el contenido de CVE caduca rápidamente, el catálogo KEV cambia cada semana y se trata de una muestra, no de un inventario. Asigna un responsable y establece un intervalo de revisión definido.

Artefactos del modelo y los límites de medición del escaneo

Un artefacto de modelo es código ejecutable dentro de una envoltura de datos. Ese es todo el problema en una sola frase.

El problema radica en un fallo de secuenciación. Un escáner como «picklescan» «primero valida los archivos Pickle y, si se validan, realiza un análisis de seguridad», mientras que la deserialización de Pickle «funciona como un intérprete, interpretando los códigos de operación a medida que se leen». El análisis se lleva a cabo antes de la carga. La ejecución tiene lugar durante la carga. Cualquier elemento que haga que un archivo parezca inválido, desconocido o mal formado para el escáner, pero que siga siendo cargable por el marco de trabajo, pasa directamente por ese hueco.

‍

Esa diferencia no es teórica, y ya se ha medido de tres formas distintas.

En febrero de 2025, se detectaron exactamente dos modelos maliciosos en una plataforma pública de modelos mediante una técnica denominada «nullifAI», que eludió el escáner al comprimir el archivo con 7z en lugar del formato ZIP que utiliza habitualmente el marco de trabajo. Dos, no son muchos. Lo relevante de este caso es el mecanismo, no el volumen.

Entre febrero y marzo de 2025, se asignaron identificadores CVE a cuatro casos distintos de elusión de escáneres. La discrepancia entre las puntuaciones es mayor que en cualquier otro caso de la sección anterior.

Puntuación CVE IDCNA (CVSS 4.0) Puntuación primaria del NVD (CVSS 3.1) Qué medidas de seguridad se eludieronCVE-2025-17165,3 MEDIO 9,8 CRÍTICOpip no se consideró una variable global insegura, por lo que un modelo que utilizaba un paquete a través de ella superó el análisisCVE-2025-18895.3 MEDIO 9,8 CRÍTICO: Solo se tuvieron en cuenta las extensiones de archivo «pickle» estándar, por lo que nunca se analizaron las extensiones no estándar.CVE-2025-19445,3 MEDIO 6,5 MEDIO: una cabecera ZIP modificada provocó un fallo en el escáner mientras el marco de trabajo aún cargaba el modeloCVE-2025-19455.3 MEDIO 9,8 CRÍTICO: La inversión de los bits del indicador ZIP ocultaba el archivo «pickle» al escáner, pero no al cargador.

Leyenda: Cuatro vulnerabilidades de elusión de un escáner de modelos muy utilizado, registradas en la base de datos CVE, todas ellas publicadas entre febrero y marzo de 2025, con una diferencia de 4,5 puntos en la puntuación de tres de las cuatro. Ninguna figura en el catálogo KEV a fecha de 25 de agosto de 2026. Texto alternativo: Tabla con cuatro vulnerabilidades de elusión de un escáner de modelos en la que se compara la puntuación CNA CVSS 4.0 de 5,3 con las puntuaciones NVD Primary CVSS 3.1 de 9,8, 9,8, 6,5 y 9,8, junto con la técnica de elusión correspondiente a cada una.

En julio de 2026, un preprint cuantificó estos datos. ShadowPickle describe tres ataques sigilosos de deserialización de Pickle e informa de que esta familia «elude diez escáneres de última generación y cuatro centros de modelos». Su variante «Overwritten», por su parte, «tiene una tasa de evasión del 63 % entre los escáneres y tasas de evasión hasta un 50 % superiores a las de los ataques existentes». El artículo no especifica el número de escáneres ni de centros de análisis a los que se refiere ese 63 %. Se trata de un preprint, no revisado por pares, de una única fuente y sin replicación independiente, por lo que hay que considerar esa cifra como un motivo de preocupación más que como un dato fiable. Lo importante es la tendencia: el control de escaneo en el que confían la mayoría de los equipos tiene una tasa de evasión publicada, en lugar de una supuesta.

La cadena de suministro también es más amplia que el archivo del modelo. Una notificación de incidente publicada el 16 de julio de 2026 por el propio centro de modelos indica que la brecha comenzó con un conjunto de datos malicioso, y no con un modelo malicioso: «Un conjunto de datos malicioso aprovechó dos vías de ejecución de código en nuestro procesamiento de conjuntos de datos (un cargador de conjuntos de datos con ejecución remota de código y una inyección de plantillas en la configuración de un conjunto de datos) para ejecutar código en un nodo de procesamiento». A partir de ahí, según las propias palabras del centro, «el atacante amplió sus privilegios hasta obtener acceso a nivel de nodo, recopiló credenciales de cloud y del clúster, y se desplazó lateralmente a varios clústeres internos a lo largo de un fin de semana».

Las medidas de control que se aplican aquí no son nada llamativas. Es preferible utilizar «safetensors» en lugar de «Pickle» para cualquier formato que controles, exigir la procedencia de los artefactos que no controles y cargar los modelos no fiables dentro de un entorno aislado, partiendo de la premisa de que la carga equivale a la ejecución.

Lo que genera una aplicación de LLM y lo que un SOC puede procesar

Una barrera de seguridad te indica lo que ha detenido. Casi nada te indica lo que se le ha escapado.

Esa asimetría constituye el problema de visibilidad en esta capa, y hay que hacer una advertencia antes de presentar la tabla: aún no existe ningún inventario público oficial de datos de telemetría de las aplicaciones de modelos de lenguaje a gran escala (LLM), por lo que la tabla que figura a continuación se ha elaborado a partir de los componentes, en lugar de basarse en datos extraídos de la práctica. Úsala como punto de partida para el diseño de la arquitectura, no como norma.

Componente de emisión de eventos. Por qué es relevante para la seguridad. Qué oculta su ausencia. Registro de la solicitud y la respuesta. Aplicación o pasarela. El único registro de lo que se preguntó y lo que se respondió. Exfiltración de datos a través del modelo, y el uso indebido de una cuenta legítima. Veredicto de Guardrail y regla coincidente. Guardrail: muestra qué se bloqueó y en virtud de qué regla. Todo lo que pasó por Guardrail. Consulta de recuperación e identificadores de documentos devueltos. Recuperación y almacén vectorial: vincula una respuesta a un corpus de origen y a un conjunto de permisos. Si un usuario accedió a documentos que no debía ver. Invocación de herramientas o funciones con argumentos. Capa de orquestación: el punto en el que el texto generado se convierte en acción. Uso indebido de privilegios, y el alcance de una inyección exitosa. Evento de carga de un artefacto del modelo con hash y fuente. Servidor de inferencia. Establece la procedencia en el momento de la carga. Qué artefacto se ejecutó realmente, y si fue el aprobado. Respuestas de error del servidor de inferencia. Servidor de inferencia: las respuestas de error constituyen una superficie de ataque y revelan el estado interno. Reconocimiento contra la capa de servicio. Decisión de autenticación y autorización en el punto final. Pasarela o servidor de inferencia: distingue entre un solicitante autorizado y un punto final abierto. Acceso no autenticado a una ruta de carga de modelos o de envío de trabajos. Anomalías en el token, coste y tasa. Puerta de enlace: detecta el abuso de recursos y el robo de recursos informáticos mediante credenciales sustraídas. Consumo ilimitado y ataques silenciosos basados en los costes.

Leyenda: Un inventario fundamentado de lo que puede emitir una aplicación LLM, derivado de los componentes de la pila en lugar de una norma citada, ya que no existe ningún inventario público oficial. Texto alternativo: Tabla con ocho eventos de telemetría de aplicaciones LLM en la que se enumeran el componente emisor, la relevancia para la seguridad de cada evento y lo que pierde un equipo de seguridad cuando no se recoge el evento.

La única referencia fidedigna disponible se refiere al caso de la IA agentiva. El Centro Nacional de Ciberseguridad del Reino Unido, en un documento del 20 de agosto de 2026 sobre la gestión del riesgo cibernético de la IA agentiva, afirma que «la actividad de la IA agentiva debe tratarse como una forma de actividad del usuario. Por lo tanto, debe incluirse en la supervisión operativa de seguridad 24/7 y en las respuestas ante incidentes». La formulación es importante: esa directriz se refiere a la supervisión operativa de seguridad las 24 horas del día, los 7 días de la semana, y no utiliza en ningún momento ni el término «LLM» ni el de «SOC». También especifica qué datos deben recopilarse mientras un agente está en funcionamiento, mencionando los rastros de la cadena de pensamiento y las transcripciones del agente, además de los eventos registrados en el entorno de pruebas más amplio, como los registros de acceso, los proxies y el tráfico de red, y ordena que dichos registros se protejan contra cualquier modificación o eliminación.

Esa última cláusula es el mecanismo de detección. La manipulación de las barreras de seguridad y los registros se asigna a T1685 Desactivar o modificar herramientas, que se encuentra en la sección TA0112 «Defense Impairment» (Deterioro de la defensa) de MITRE ATT&CK y abarca a los adversarios que «desactivan, degradan o manipulan herramientas o aplicaciones de seguridad» con el fin de «mermar o reducir la visibilidad de las capacidades defensivas». Es la única técnica de ATT&CK que se menciona en esta página.

La detección es una vertiente reconocida de este campo, aunque casi ningún profesional le dedique atención. Un estudio académico de 2025 sobre seguridad en LLM clasifica las defensas en «dos categorías principales: defensas basadas en la prevención y defensas basadas en la detección», que es precisamente el mismo eje sobre el que ya se articula cualquier programa de seguridad consolidado.

Esta sección se centra deliberadamente en lo que emite la aplicación. La integración con SIEM, el desarrollo de reglas de detección y el flujo de trabajo del SOC para la IA generativa se tratan en la sección sobre seguridad de la IA generativa, mientras que la aplicación de análisis a esta señal se aborda en la sección sobre detección de amenazas de IA. Cuando la aplicación actúa en lugar de responder, consulta la sección sobre seguridad de la IA agentiva.

Barreras de seguridad, cortafuegos, pasarelas y escáneres, y las cifras que citan

Define estas herramientas en función de su finalidad, ya que tanto los nombres de las categorías de los proveedores como la titularidad de los proyectos de código abierto cambian más rápidamente que las propias funciones.

Categoría Lo que inspecciona Dónde se ubica Lo que no puede hacer Barrera de seguridad Texto de la solicitud y la respuesta Dentro de la aplicación, en el límite del modelo No puede ver la infraestructura subyacente y solo informa de lo que ha bloqueado Cortafuegos LLM Texto de la solicitud y la respuesta Inline en la ruta de la solicitud de red, delante de la aplicación Comparte el punto ciego de la barrera de seguridad y no aporta visibilidad sobre las llamadas en curso Puerta de enlace de IA Solicitudes, enrutamiento, cuotas y credenciales. Entre la aplicación y uno o más proveedores de modelos. No inspecciona los artefactos del modelo ni comprueba su comportamiento. Escáner de modelos. El artefacto del modelo serializado, antes de su carga. En el proceso de compilación o en el centro de modelos. Tiene una tasa de evasión medida y no ve nada en tiempo de ejecución. Arnés de equipo rojo. Comportamiento del modelo y de la aplicación ante entradas adversas. Fuera de línea o en un entorno de preproducción. Genera hallazgos en lugar de controles, y sus puntuaciones son específicas del arnés.

Leyenda: Las cinco categorías funcionales de herramientas de seguridad para LLM, definidas en función de lo que inspecciona cada una y de su ubicación, más que por el nombre de la categoría del proveedor. Texto alternativo: Tabla en la que se comparan «guardrail», «cortafuegos LLM», «pasarela de IA», «escáner de modelos» y «harness de equipo rojo» según lo que inspecciona cada uno, su posición en la ruta de la solicitud y su principal limitación.

Un «guard» de LLM, para responder directamente a esta pregunta tan habitual, es una barrera de seguridad: un mecanismo de control que inspecciona las peticiones o respuestas en el límite de la aplicación y las bloquea, las censura o las reescribe. Se trata de una medida preventiva, no de detección, y actúa sobre el texto que cruza ese límite, en lugar de sobre la infraestructura subyacente.

Vale la pena definir el término «cortafuegos LLM», pero no merece la pena dedicarle demasiado tiempo. Se trata del nombre que da un proveedor a una barrera de seguridad situada en la red, y describe una opción de ubicación concreta: en línea en la ruta de la solicitud, en lugar de dentro del proceso de la aplicación.

La elección entre categorías es una cuestión de cobertura, no de clasificación. Hay que preguntarse qué capa cubre realmente una herramienta, en qué punto de la ruta de la solicitud se sitúa, qué hace cuando falla, si genera datos de telemetría o solo resultados, y si es el único control en esa capa. Una barrera de seguridad y un escáner de modelos no compiten entre sí, porque cubren capas diferentes. Los sistemas de simulación de ataques con IA no sustituyen a ninguno de los dos, sino que los ponen a prueba a ambos. Y nada en esa tabla impide prompt injection por completo.

‍

Cómo interpretar un informe comparativo sobre la seguridad de los modelos de lenguaje grande (LLM)

La tasa de éxito de los ataques (ASR) es la proporción de intentos que un conjunto de pruebas ha calificado como exitosos frente a un modelo objetivo. Es relevante dentro de su propio conjunto de pruebas y prácticamente en ningún otro contexto.

Hay tres variables que influyen en esa cifra de forma independiente: el conjunto de indicaciones, el protocolo de evaluación y la definición de éxito. Basta con cambiar cualquiera de ellas para que la cifra varíe, razón por la cual dos tasas de éxito de ataques publicadas rara vez son comparables, incluso cuando describen la misma clase de ataque. El artículo de referencia sobre StrongREJECT señala explícitamente esta tendencia, indicando que «quizá sea más habitual que los desarrolladores de jailbreaks exageren sustancialmente la eficacia de sus jailbreaks» y que «los métodos de evaluación existentes sobreestiman significativamente la eficacia de los jailbreaks en comparación con los juicios humanos». Hay que tener en cuenta esta tendencia y observar que el artículo no asigna ningún porcentaje a dicha sobreestimación. Cualquiera que cite uno está citando otra cosa.

Así que haz cuatro preguntas sobre cualquier cifra que te dé un proveedor: qué sistema de evaluación, qué evaluador, qué conjunto de indicaciones y qué se consideró un éxito. Si no se dispone de esas cuatro respuestas, la cifra es un recurso de marketing más que una medición.

Análisis del marco normativo y la normativa, versión fijada

La mayoría de los marcos de trabajo que aparecen en esta página han cambiado en los últimos trece meses, por lo que la versión y la fecha son más importantes que el nombre.

2025 ID y título 2026 ID y título Movimiento Nota LLM01:2025 Inyección de prompts LLM01:2026 Inyección de prompts Sin cambios Mantuvo la primera posición en ambas ediciones LLM02:2025 Divulgación de información sensible LLM02:2026 Divulgación de información sensible Sin cambios Ocupó el segundo puesto en ambas ediciones LLM03:2025 Cadena de suministro LLM04:2026 Cadena de suministro Baja 1 Abarca la sección de artefactos del modelo anterior LLM04:2025 Envenenamiento de datos y modelos LLM05:2026 Envenenamiento de datos y modelos Baja 1 Renumerado, por lo que un identificador «2025» ahora induce a error. LLM05:2025 Manejo inadecuado de la salida. LLM10:2026 Manejo inadecuado de la salida. Baja 5. El mayor cambio individual de la lista. LLM06:2025 Agencia excesiva. LLM03:2026 Agencia excesiva. Subió 3 puestos. Refleja el cambio hacia implementaciones con agencia. LLM07:2025 Fuga de indicaciones del sistema. LLM08:2026 Exposición de contexto oculto. Bajó 1 puesto, renombrado y ampliado. El alcance se amplió desde las indicaciones del sistema únicamente a todo el contexto oculto, incluyendo el texto de las políticas recuperadas y los esquemas de las herramientas que la aplicación expone al modelo. LLM08:2025 Debilidades de vectores e incrustaciones LLM09:2026 Debilidades de vectores e incrustaciones Baja 1 La capa de recuperación y almacenamiento de vectores LLM09:2025 Desinformación LLM07:2026 Desinformación Sube 2 LLM10:2025 Consumo ilimitado LLM06:2026 Consumo ilimitado Sube 4

Leyenda: Tabla de correspondencias entre los «Top 10» de OWASP de 2025 y 2026 para aplicaciones de LLM. La columna de 2026 procede del repositorio canónico, la de 2025 de la página de la lista sustituida y el cambio de nombre de la cobertura de Help Net Security; todo ello consultado el 25 de agosto de 2026. Texto alternativo: Tabla de correspondencias que asocia cada identificador de la lista «OWASP Top 10 para LLM» de 2025 con su identificador de 2026, en la que se muestran dos entradas sin cambios y las otras ocho desplazadas, habiéndose renombrado y ampliado una de esas ocho.

Dos entradas mantienen su posición y las otras ocho se han modificado. Una de esas ocho también ha cambiado de nombre y se ha ampliado: la cobertura de Help Net Security sobre la publicación señala que «System Prompt Leakage pasó a denominarse Hidden Context Exposure y se amplió». No se ha eliminado nada ni hay nada totalmente nuevo, lo cual es importante si se están adaptando los controles de 2025 a la lista de 2026. La edición de 2026 se publicó el 4 de agosto de 2026 y combina el criterio de la comunidad con datos de incidentes: el mismo informe señala que «la votación siguió teniendo un peso del 75 %, pero el 25 % restante se vio influido por los datos de 6.639 incidentes reales extraídos de bases de datos públicas de vulnerabilidades y de una base de datos sobre daños causados por la IA». La lista no se vuelve a enumerar aquí. Las descripciones de cada riesgo se encuentran en GenAI Security, y la lista de 2026 está disponible de forma agregada en la página de recursos de OWASP. La divergencia entre versiones es real, no hipotética: veintiún días después de su publicación, la página de la lista anterior aún mostraba solo los identificadores de 2025, razón por la cual la tabla de correspondencias remite cada columna a su propia fuente.

Versión del marco | Fecha | A qué se corresponde en esta página | OWASP Top 10 para aplicaciones LLM | Edición de 2026, publicada el 4 de agosto de 2026 | 25 de agosto de 2026 | La taxonomía de riesgos, con la correspondencia indicada más arriba | MITRE ATT&CK Enterprise v19.2, 15 tácticas 25 de agosto de 2026 La correspondencia de una única técnica en la sección de telemetría MITRE ATLAS 2026.07: 1 matriz, 16 tácticas, 101 técnicas, 77 subtécnicas, 37 medidas de mitigación, 68 casos prácticos, 25 de agosto de 2026. Comportamiento adversario específico de la IA y el conflicto de nomenclatura que se indica a continuación: Marco de gestión de riesgos de IA del NIST 1.0, publicado el 26 de enero de 2023, en proceso de revisión, 25 de agosto de 2026. Gobernanza de programas a través de «Gobernar, Mapear, Medir y Gestionar. NIST AI 100-2 E2025 (definitiva), marzo de 2025. 25 de agosto de 2026. Taxonomía y terminología del aprendizaje automático adversario. Ley de IA de la UE. Reglamento (UE) 2024/1689, consolidado el 27 de julio de 2026, modificado por el Reglamento (UE) 2026/1744; 25 de agosto de 2026. Transparencia y obligaciones de alto riesgo, y sus fechas de aplicación: ISO/IEC 42001; texto base de 2023, adopción europea de la norma EN ISO/IEC 42001:2026; 25 de agosto de 2026. Certificación del sistema de gestión de la IA, fechas (solo de fuentes secundarias).

Leyenda: Asignación de marcos fijados a una versión para esta página, verificada a fecha de 25 de agosto de 2026. MITRE ATLAS publica las versiones en un calendario mensual, por lo que se recomienda volver a comprobar la versión antes de basarse en el recuento de elementos. Texto alternativo: Tabla que asocia siete marcos a una versión específica y una fecha de verificación, con una nota sobre a qué corresponde cada uno en este artículo.

Hay una trampa en la asignación que conviene conocer. MITRE ATT&CK Empresa La versión 19.2 cuenta exactamente con 15 tácticas y ninguna se llama «Evasión defensiva»: la TA0005 ahora se llama «Sigilo» y la TA0112, «Deterioro defensivo». MITRE ATLAS comunicado 2026.07 todavía mantiene una táctica llamada AML.0007 «Evasión de defensa», y el propio campo de referencia de ataque de ese registro de ATLAS apunta a TA0005. Ambos marcos están formalmente relacionados entre sí, aunque discrepan en cuanto al nombre del mismo concepto mapeado, por lo que cualquier afirmación sobre la «Evasión de defensa» debe especificar a qué marco pertenece.

En materia de regulación, las obligaciones de transparencia del artículo 50 de la Ley de IA de la UE entraron en vigor el 2 de agosto de 2026 y no se aplazaron. El Reglamento (UE) 2026/1744 modificó las obligaciones relativas a los sistemas de alto riesgo: los sistemas de alto riesgo del anexo III se aplicarán a partir del 2 de diciembre de 2027 y los del anexo I, a partir del 2 de agosto de 2028. Según el texto consolidado, los proveedores de sistemas que generen contenido sintético y que ya se encuentren en el mercado deben cumplir lo dispuesto en el artículo 50, apartado 2, a más tardar el 2 de diciembre de 2026, y los artículos 102 a 110 se aplicarán a partir del 27 de julio de 2026. Estas son las fechas más sujetas a cambios de esta página, por lo que conviene volver a verificarlas en EUR-Lex, junto con cualquier herramienta de gobernanza de la IA que utilices para realizar su seguimiento.

Hay otros dos puntos de referencia importantes para el trabajo a nivel de programa: el Marco de Gestión de Riesgos de IA del NIST, publicado el 26 de enero de 2023 y que ahora «se está revisando como parte del Plan de Acción sobre IA de la Casa Blanca», y el NIST AI 100-2 E2025, la taxonomía definitiva de marzo de 2025 sobre ataques adversarios al aprendizaje automático y sus medidas de mitigación. La norma ISO/IEC 42001 es la norma de sistemas de gestión para la IA, y la norma EN ISO/IEC 42001:2026 es la adopción europea actual del mismo texto base, que sustituye a una adopción nacional de 2025 que ha sido retirada. Las fechas de publicación que figuran aquí proceden de fuentes secundarias, ya que las páginas del organismo de normalización no son de acceso público.

Enfoques modernos para garantizar la seguridad de la pila de modelos de lenguaje grande (LLM)

El presupuesto se está orientando hacia este ámbito. El informe «State of Security 2026» de Enterprise Technology Research, basado en 517 líderes tecnológicos especializados en seguridad y publicado sin indicar las fechas de realización de la encuesta, reveló que «más de la mitad (59 %) de las organizaciones tiene previsto aumentar el gasto en esta categoría», mientras que «una quinta parte (20 %) de las organizaciones afirma no contar con controles de seguridad específicos para agentes, y solo el 3 % los ha implementado de forma generalizada en los entornos de producción».

La tesis de diseño que los responsables del proyecto OWASP plantean para la edición de 2026 se centra en el control del «radio de impacto» en lugar de en la prevención perfecta. Tal y como recoge la cobertura de Help Net Security sobre el lanzamiento, estos comienzan diciendo: «Dejad de intentar crear un modelo que no pueda ser engañado». En la práctica, esto se traduce en tres capacidades: la gestión de la postura de seguridad en todo el entorno de IA, incluida en la gestión de la postura de seguridad de la IA; la detección en tiempo de ejecución en la capa de servicio; y la procedencia del artefacto del modelo. El programa más amplio se detalla en las Directrices del NCSC para el desarrollo seguro de sistemas de IA, que abarcan el diseño seguro, el desarrollo seguro, la implementación segura y el funcionamiento y mantenimiento seguros. El trabajo con visión de futuro es más específico: aplicar la misma disciplina de inventario y parches a los componentes de orquestación que hoy en día carecen de un responsable de seguridad.

La visión de « Vectra AI » sobre la seguridad de los modelos de lenguaje grande (LLM)

Vectra AI Parte de la premisa de que la red moderna constituye una única superficie de ataque, y que la pila de servicios de los modelos de lenguaje grande (LLM) forma ahora parte de ella. La postura de «asumir el compromiso» se aplica aquí exactamente igual que en el caso de la identidad, cloud y la infraestructura local. La prevención en el límite inmediato es necesaria, pero insuficiente. Lo que importa desde el punto de vista operativo es la observabilidad sobre el segmento de infraestructura de IA, una señal que distinga el comportamiento real de un atacante del ruido del modelo, y la capacidad de actuar en función de esa señal. Esa es la metodología que subyace a Attack Signal Intelligence, aplicada a un segmento que la mayoría de los entornos aún no han inventariado, y es hacia donde se dirigen los programas de seguridad de IA.

La seguridad de LLM es una disciplina basada en la pila. Haz un inventario de las capas de las que eres responsable, aplica parches a los componentes que tengan identificadores CVE y plazos KEV, monitoriza lo que emiten tus aplicaciones y remite cada número de proveedor al sistema que lo generó. El modelo es la parte sobre la que todo el mundo escribe. La pila que hay debajo es la parte que puedes arreglar.

‍