Las pruebas de seguridad de los LLM abarcan de extremo a extremo el modelo y la pila de aplicaciones que lo rodea. Empiece por inventariar todas las funcionalidades basadas en LLM y asociar cada una a las categorías de riesgo de OWASP. A continuación, ejecute una prueba automatizada alineada con OWASP en el entorno de preproducción y programe un ejercicio de red teaming con especialistas para detectar lo que la prueba no encuentre.
En resumen:
- Priorice la inyección indirecta de prompts a través de páginas recuperadas, correos electrónicos, PDF y respuestas de API, y compruebe si el modelo trata las instrucciones incrustadas como datos.
- Convierta cada evasión de controles confirmada por el equipo de red teaming en una prueba de regresión y repita los casos varias veces, porque las salidas del modelo varían.
- Compruebe la autorización de recuperación de datos entre clientes, valide la salida del modelo antes de que llegue a navegadores o bases de datos y limite las herramientas de los agentes mediante entornos aislados y la aprobación de cada acción.
- Condicione los lanzamientos a una tolerancia cero ante filtraciones de gravedad alta y a umbrales medidos para el resto, utilizando las tasas de éxito de los ataques por categoría de riesgo en múltiples ejecuciones.
- Ejecute análisis específicos en preproducción y análisis más amplios en los lanzamientos principales, e incorpore las alertas de producción a las pruebas de regresión; asigne a cada hallazgo un responsable y una fecha límite.
Índice
- ¿Qué debe abarcar un plan de pruebas de seguridad de LLM?
- ¿Cuándo se utilizan el red teaming manual, las evaluaciones de referencia y las pruebas automatizadas?
- ¿Cómo se prueban el modelo, los prompts, la recuperación, las herramientas y la infraestructura?
- ¿Cómo se comprueban el mínimo privilegio y las aprobaciones seguras en los agentes?
- ¿Qué herramientas y analizadores debe incorporar a su flujo de trabajo?
- ¿Qué métricas y controles deben determinar si se publica una compilación?
- ¿Cómo se mantiene el aseguramiento tras la primera prueba?
- Tres prioridades abordables en sprints para las primeras seis semanas
- Una auditoría independiente puede ayudarle a obtener evidencias más rápido
- Preguntas frecuentes
- Fuentes
¿Qué debe abarcar un plan de pruebas de seguridad de LLM?
El Top 10 de OWASP para aplicaciones LLM 2026 es una herramienta útil para definir el alcance de un plan de pruebas. Documenta los riesgos de mayor impacto y vincula las medidas de mitigación con marcos como NIST y MITRE. Convierta cada categoría en un objetivo de prueba y, después, redacte casos que intenten provocar el fallo.
- Inyección de prompts: intente anular las instrucciones mediante entradas del usuario, documentos cargados y salidas de herramientas, y compruebe si el modelo obedece texto que debería tratarse como datos.
- Divulgación de información sensible: intente obtener en las respuestas datos de entrenamiento, credenciales, datos personales y contenido de otros clientes.
- Tratamiento inadecuado de las salidas: compruebe si la salida del modelo llega a un navegador, un intérprete de comandos o una base de datos sin validación.
- Envenenamiento de datos y modelos: inserte registros manipulados en las fuentes de ajuste fino o recuperación y observe cómo cambian las respuestas.
- Debilidades de vectores y embeddings: compruebe si un documento manipulado puede dominar la recuperación en consultas no relacionadas.
- Consumo sin límites: envíe solicitudes de tamaño excesivo o recursivas y busque costes descontrolados o denegaciones de servicio.
- Filtración del prompt del sistema: pida al modelo que repita, resuma o traduzca sus instrucciones ocultas.
- Vulnerabilidades de la cadena de suministro: audite modelos, complementos y conjuntos de datos de terceros para detectar manipulaciones.
- Capacidad de actuación excesiva: enumere todas las acciones que puede activar el modelo y compruebe si puede exceder el alcance previsto.
- Información errónea: mida las respuestas expresadas con seguridad pero incorrectas sobre temas en los que su producto debe acertar.
Preste especial atención a la inyección indirecta de prompts. Llega a través de páginas recuperadas, cuerpos de correos electrónicos, PDF y respuestas de API, de modo que el atacante nunca habla directamente con su chatbot. Las directrices de OWASP describen el problema de raíz como la incapacidad del modelo para distinguir las instrucciones de los datos; por eso las defensas arquitectónicas son importantes, junto con un diseño cuidadoso de los prompts. La IMDA de Singapur también enumera cinco riesgos prioritarios para las aplicaciones LLM, entre ellos el sesgo y el contenido no deseado, que conviene añadir al alcance.
¿Cuándo se utilizan el red teaming manual, las evaluaciones de referencia y las pruebas automatizadas?
Utilice los tres, en secuencia. Microsoft aconseja empezar con red teaming manual para identificar la superficie de riesgo y utilizar después esos hallazgos para diseñar mediciones automatizadas sistemáticas y evaluaciones de referencia de las medidas de mitigación. Los especialistas encuentran nuevas formas de eludir los controles. Las evaluaciones de referencia ofrecen una cobertura repetible. Ninguno sustituye al otro.
La guía de red teaming de IA generativa de OWASP recomienda combinar evaluaciones automatizadas en CI/CD con ejercicios periódicos de red teaming dirigidos por especialistas. Un ciclo viable sería el siguiente:
- Realice un ejercicio manual de red teaming para trazar la superficie de ataque y registrar cada evasión de controles lograda.
- Convierta cada evasión confirmada en una prueba automatizada dentro de un corpus de regresión.
- Añada baterías de evaluación de referencia para cada categoría de OWASP, de modo que la cobertura se mida en lugar de darse por supuesta.
- Ejecute las pruebas automatizadas en CI ante cualquier cambio significativo en un prompt, una versión del modelo, una fuente de recuperación o una herramienta.
- Establezca umbrales por categoría que puedan bloquear una compilación.
- Repita los ejercicios de red teaming con especialistas según un calendario y después de cualquier cambio de alto riesgo, como la integración de una nueva herramienta.
Dado que la salida del modelo es probabilística, un único resultado satisfactorio o fallido constituye una evidencia débil. Las directrices de OWASP e IMDA señalan que los criterios binarios son insuficientes para estas interacciones, por lo que conviene ejecutar cada caso varias veces y evaluar la tasa de éxito.
Consejo profesional: Etiquete cada caso de regresión con la categoría de OWASP y el componente que pone a prueba, de modo que una compilación fallida indique dónde buscar antes de que nadie abra los registros.
¿Cómo se prueban el modelo, los prompts, la recuperación, las herramientas y la infraestructura?
Las pruebas eficaces recorren toda la pila tecnológica. Las directrices DevSecOps de OWASP exigen una cobertura de extremo a extremo del modelo, los prompts, el flujo de recuperación y las herramientas, con pruebas automatizadas en CI y telemetría de producción que retroalimente el ciclo. Redacte casos específicos por componente para facilitar la clasificación y priorización de los fallos.
- Modelo: realice pruebas a través de la API, compruebe la robustez y las alucinaciones, y fije la versión del modelo para que los resultados sean reproducibles. NIST recomienda utilizar tareas o modelos sustitutivos para medir capacidades que suscitan preocupación y documentar las tareas y los conjuntos de datos de evaluación.
- Prompts: intente extraer el prompt del sistema, mantenga los prompts bajo control de versiones y valide cualquier contenido que se inserte en ellos.
- Recuperación y RAG: verifique que la recuperación respeta la autorización del usuario, intente envenenar el almacén vectorial y compruebe que un cliente no puede recuperar documentos de otro.
- Herramientas y ejecución de código: ejecute el código en un entorno aislado, emita credenciales efímeras, exija la aprobación de cada acción en operaciones sensibles y muestre las diferencias de una simulación antes de aplicar los cambios.
- Infraestructura y cadena de suministro: mantenga una lista de materiales de software (SBOM) o de IA, fije las versiones de las dependencias y conserve un mecanismo de revocación de emergencia para claves, modelos y complementos.
¿Cómo se comprueban el mínimo privilegio y las aprobaciones seguras en los agentes?
Los agentes convierten un problema de texto en un problema de acciones. El Top 10 de OWASP para aplicaciones agénticas 2026 introduce medidas de mitigación como perfiles de herramientas con privilegios mínimos, autenticación y aprobación por acción, entornos aislados de ejecución, vinculaciones a la intención y registro continuo. Pruebe cada una de ellas directamente.
- Enumere todas las herramientas y sus ámbitos de permiso. Indique qué puede invocar el agente y, después, intente hacer que utilice una capacidad que no debería tener.
- Compare las acciones mostradas con las ejecutadas. Muestre la acción a quien deba aprobarla y, después, compárela con los parámetros realmente ejecutados. Esto permite detectar la introducción encubierta de caracteres invisibles, en la que caracteres Unicode ocultos modifican lo que se ejecuta.
- Pruebe la vinculación a la intención. Si utiliza cápsulas de intención firmadas, intente reutilizar o alterar una.
- Compruebe la confianza entre agentes. Valide la firma de los mensajes y la autenticación mutua entre agentes.
- Limite el alcance del impacto. Confirme que el entorno aislado restringe las conexiones salientes a destinos aprobados.
Las defensas por capas pueden complementar los controles individuales. The AI Orchestrators lo explican de forma convincente en su artículo sobre la seguridad de los agentes.
Consejo profesional: Trate la declaración de intención del propio modelo como una entrada no fiable. Autorice cada acción mediante código, fuera del prompt.
¿Qué herramientas y analizadores debe incorporar a su flujo de trabajo?
Elija por categoría en lugar de por marca y asocie cada categoría a una etapa de su flujo de trabajo.
- Analizadores de vulnerabilidades: pruebas automatizadas amplias que abarcan las categorías de OWASP, adecuadas para ejecuciones en preproducción.
- Baterías de jailbreak: colecciones seleccionadas de prompts adversarios que cubren patrones conocidos de evasión de controles.
- Herramientas de fuzzing de prompts: generan mutaciones de ataques iniciales para encontrar filtros frágiles.
- Herramientas de prueba de RAG: ponen a prueba la autorización de recuperación y los escenarios de envenenamiento.
- Complementos de CI: ejecutan un subconjunto rápido en cada solicitud de incorporación de cambios y hacen cumplir los umbrales.
- Monitores de telemetría: supervisan las conversaciones en producción para detectar derivas y nuevos patrones de ataque.
Los marcos de análisis de código abierto, las herramientas de fuzzing de prompts y los entornos de pruebas de red teaming encajan en estas categorías. Una revisión de 2025 sobre red teaming de LLM resume métodos de ataque, métricas y paquetes de software, y destaca la importancia de un sistema de extremo a extremo que alimente la medición automatizada. Vincule los hallazgos con técnicas de los atacantes mediante MITRE ATLAS.
Ejecute análisis específicos en preproducción y análisis completos en los lanzamientos principales, y mantenga la revisión humana en el proceso. Los analizadores generan falsos positivos, y una lista de fallos sin revisar acostumbra a los equipos a ignorar el informe.
¿Qué métricas y controles deben determinar si se publica una compilación?
Mida resultados, no actividad. Entre las métricas útiles figuran la tasa de éxito de los ataques por categoría de OWASP, la cobertura de evaluación, el plazo de subsanación, la tasa de regresión y el alcance de los permisos.
- Tasa de éxito de los ataques por categoría: la proporción de intentos que tienen éxito, con seguimiento entre versiones.
- Cobertura de evaluación: cuántas categorías y componentes cuentan con casos automatizados.
- Plazo de subsanación: días desde la confirmación del hallazgo hasta la verificación de la corrección.
- Tasa de regresión: con qué frecuencia reaparece un problema corregido.
- Alcance de los permisos: el número de herramientas y ámbitos de permiso de los que dispone cada agente.
Las directrices DevSecOps de OWASP recomiendan pruebas automatizadas en CI, umbrales por categoría, corpus de regresión y telemetría de producción para mantener el aseguramiento a lo largo del tiempo.
Diseñe los controles en dos niveles: tolerancia cero ante filtraciones de gravedad alta y umbrales para las categorías de menor gravedad, evaluados en múltiples ejecuciones para tener en cuenta el comportamiento no determinista. Para clasificar y priorizar los hallazgos, vincule cada uno a un componente, ordénelo por impacto y convierta cada evasión de controles confirmada en una prueba de regresión automatizada.
¿Cómo se mantiene el aseguramiento tras la primera prueba?
Las pruebas puntuales pierden vigencia el día en que cambia un prompt o un modelo. Entendemos el aseguramiento como un ciclo: la telemetría de producción alimenta el corpus de regresión, las evaluaciones continuas se ejecutan con cada cambio y los equipos humanos de red teaming vuelven periódicamente.
- Haga que los hallazgos sean reproducibles. Registre la versión del modelo, el hash del prompt del sistema, el manifiesto de herramientas y la semilla de prueba junto con cada resultado.
- Alinee las evidencias con directrices reconocidas. Estructure los informes en torno a la guía de red teaming de IA generativa de OWASP, que contempla la evaluación del modelo, las comprobaciones de implementación, la evaluación del sistema y el análisis durante la ejecución, y combínela con la práctica de NIST de documentar las tareas y los conjuntos de datos de evaluación para favorecer la transparencia.
- Mantenga las alertas auditables. Registre cada alerta, quién la revisó y qué se decidió.
- Derive los casos a personas. Defina flujos con intervención humana para los casos de alto impacto.
- Designe un responsable. Cada hallazgo necesita un responsable de subsanación y una fecha límite.
Para los equipos que también necesitan trazabilidad de auditoría de las decisiones, Conversational AI publica una guía útil sobre la auditoría de decisiones de sistemas de IA.
Tres prioridades abordables en sprints para las primeras seis semanas
La mayoría de los equipos se estancan porque el programa parece demasiado amplio. Divídalo en tres pasos que pueda completar de forma secuencial.
Sprint 0: inventaríe todas las funcionalidades LLM, vincule cada una a un riesgo de OWASP y active la telemetría básica. Sprint 1: añada pruebas automatizadas alineadas con OWASP a preproducción y establezca controles de bloqueo para las categorías de alto riesgo. Después, programe un ejercicio de red teaming con especialistas, porque las evasiones de controles que confirmen se convertirán en sus primeros casos de regresión reales. Prefiero ver un corpus pequeño que bloquee compilaciones antes que un informe extenso que nadie haga cumplir.
— Sergio Llorens
Una auditoría independiente puede ayudarle a obtener evidencias más rápido
Crear internamente un corpus, umbrales y un sistema de informes requiere un tiempo del que muchos equipos no disponen antes de un lanzamiento o de una consulta del regulador. Auditamos agentes de IA conversacional de cualquier proveedor y, como no desarrollamos ni operamos los agentes, nuestros hallazgos son independientes.
- Hallazgos de auditoría: una visión independiente de las carencias de seguridad, la gestión de las derivaciones y el cumplimiento en conversaciones reales, con medidas de subsanación priorizadas.
- Supervisión continua: nuestra plataforma Lexic Pulse mantiene actualizadas las alertas y las métricas a medida que cambian los agentes.
- Auditorías de agentes: Lexic Compass verifica el comportamiento de los agentes y genera evidencias listas para su uso en la gobernanza.
Si desea una demostración rápida de valor, contrate un Audit Sprint o una Flash Preview a través de nuestros servicios de auditoría. Los detalles de los precios vigentes están disponibles en nuestro sitio web.
Preguntas frecuentes
¿Qué significa LLM en ciberseguridad?
LLM son las siglas en inglés de gran modelo de lenguaje, el tipo de sistema de IA en el que se basan los chatbots y agentes modernos. En el ámbito de la seguridad, se refiere tanto al modelo como a la aplicación que lo rodea, ya que los ataques suelen dirigirse a los prompts, la recuperación y las herramientas, y no solo al modelo.
¿Qué son las pruebas basadas en LLM?
La expresión suele referirse a las pruebas de aplicaciones construidas sobre LLM para evaluar su seguridad, fiabilidad y protección frente a ataques. El kit de inicio de la IMDA de Singapur recomienda combinar evaluaciones de referencia, red teaming y pruebas de componentes para este fin.
¿Son ilegales las pruebas de penetración?
La legalidad de las pruebas depende de las circunstancias y de las normas del lugar donde opere. Confirme por escrito el alcance y el consentimiento, y compruebe las normas aplicables antes de realizar las pruebas.
¿Cuáles son las mejores herramientas para probar LLM?
La elección adecuada depende de la tarea: analizadores de vulnerabilidades para una cobertura amplia, baterías de jailbreak para evasiones de controles conocidas, herramientas de fuzzing de prompts para filtros frágiles y herramientas de prueba de RAG para la recuperación. Combine cualquiera de ellas con un equipo humano de red teaming, como aconseja la guía de OWASP.