Pruebas de seguridad de LLM para desarrolladores: crea pruebas de CI/CD en seis semanas

Las pruebas de seguridad de LLM abarcan de extremo a extremo tanto el modelo como la pila de aplicaciones que lo rodea. Empiece por inventariar todas las funcionalidades basadas en LLM y vincular cada una con las categorías de riesgo de OWASP. A continuación, ejecute una prueba automatizada alineada con OWASP en preproducción y programe una evaluación con un equipo humano de red teaming para detectar lo que la prueba automatizada pasa por alto.

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 confirmada por el equipo de red teaming en una prueba de regresión y repita los casos varias veces, ya que las salidas del modelo varían.
• Compruebe la autorización de recuperación entre organizaciones cliente, valide la salida del modelo antes de que llegue a navegadores o bases de datos y restrinja las herramientas de los agentes mediante entornos aislados y la aprobación de cada acción.
• Condicione los lanzamientos a una tolerancia cero frente a filtraciones de gravedad alta y a umbrales medidos en los demás casos, 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 las versiones 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 red teaming manual, evaluaciones comparativas y 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 escáneres debe añadir a su flujo de trabajo?
• ¿Qué métricas y controles deben determinar si se publica una compilación?
• ¿Cómo se mantiene el aseguramiento después de la primera prueba?
• Tres prioridades abordables en sprints para sus 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 de 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 redacte casos que intenten provocar el fallo.

• Inyección de prompts: intente anular las instrucciones mediante entradas de usuario, documentos cargados y salidas de herramientas, y observe si el modelo obedece texto que debería tratar como datos.
• Divulgación de información sensible: intente obtener en las respuestas datos de entrenamiento, credenciales, datos personales y contenido de otras organizaciones cliente.
• 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 diseñado para el ataque puede dominar la recuperación en consultas no relacionadas.
• Consumo sin límites: envíe solicitudes sobredimensionadas o recursivas y busque costes descontrolados o denegaciones de servicio.
• Filtración del prompt de 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.
• Autonomía 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 incorrectas expresadas con seguridad 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, por lo que el atacante nunca habla directamente con su chatbot. Las directrices de OWASP describen la raíz del problema 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 de LLM, entre ellos los sesgos y el contenido no deseado, que conviene añadir al alcance.

¿Cuándo se utilizan red teaming manual, evaluaciones comparativas y pruebas automatizadas?

Utilice los tres, de forma secuencial. 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 comparativas de mitigación. Las personas encuentran nuevas formas de eludir los controles. Las evaluaciones comparativas proporcionan 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 personas. Un ciclo viable sería el siguiente:

1. Realice un ejercicio manual de red teaming para cartografiar la superficie de ataque y registrar cada evasión exitosa.
2. Convierta cada evasión confirmada en una prueba automatizada dentro de un corpus de regresión.
3. Añada baterías de evaluación comparativa para cada categoría de OWASP, de modo que la cobertura se mida y no se dé por supuesta.
4. Ejecute las pruebas automatizadas en CI ante cada cambio significativo en un prompt, una versión del modelo, una fuente de recuperación o una herramienta.
5. Establezca umbrales por categoría que puedan bloquear una compilación.
6. Repita el ejercicio de red teaming humano de forma programada 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 y la IMDA señalan que los criterios binarios son insuficientes para estas interacciones, por lo que debe ejecutar cada caso varias veces y evaluar la tasa de resultados.

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 alguien 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 de 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 alimente 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 las capacidades que suscitan preocupación y documentar las tareas y los conjuntos de datos de evaluación.
• Prompts: intente extraer el prompt de 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 una organización cliente no puede obtener documentos de otra.
• 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 para las 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 de intención y registro continuo. Pruebe cada una de ellas directamente.

• Enumere todas las herramientas y sus ámbitos de permisos. Liste lo que 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 la persona encargada de aprobarla y compárela después con los parámetros realmente ejecutados. Así se detecta la introducción encubierta de caracteres invisibles, en la que caracteres Unicode ocultos modifican lo que se ejecuta.
• Pruebe la vinculación de intención. Si utiliza cápsulas de intención firmadas, intente reutilizar una o alterarla.
• Compruebe la confianza entre agentes. Valide la firma de mensajes y la autenticación mutua entre agentes.
• Limite el alcance del impacto. Confirme que el entorno aislado restringe el tráfico saliente a destinos aprobados.

Las defensas por capas pueden complementar los controles individuales. The AI Orchestrators expone bien este argumento en su artículo sobre la seguridad de los agentes.

Consejo profesional: Trate la propia declaración de intención del modelo como una entrada no fiable. Autorice cada acción mediante código, fuera del prompt.

¿Qué herramientas y escáneres debe añadir a su flujo de trabajo?

Elija por categoría, no por marca, y asigne cada categoría a una fase de su flujo de trabajo.

• Escáneres 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.
• Herramientas de fuzzing de prompts: generan mutaciones de ataques iniciales para encontrar filtros frágiles.
• Herramientas de pruebas 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 escaneo 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 subraya la importancia de un sistema de extremo a extremo que alimente la medición automatizada. Vincule los hallazgos con las técnicas de los atacantes mediante MITRE ATLAS.

Ejecute análisis específicos en preproducción y análisis completos en las versiones principales, y mantenga la revisión humana en el proceso. Los escáneres producen 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 los resultados, no la actividad. Entre las métricas útiles se incluyen 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 la huella de permisos.

• Tasa de éxito de los ataques por categoría: la proporción de intentos exitosos, registrada a lo largo de las versiones.
• Cobertura de evaluación: cuántas categorías y componentes cuentan con casos automatizados.
• Plazo de subsanación: días transcurridos desde la confirmación del hallazgo hasta la verificación de la corrección.
• Tasa de regresión: frecuencia con la que reaparece un problema corregido.
• Huella de permisos: el número de herramientas y ámbitos de permisos de cada agente.

Las directrices de 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 frente a 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, asigne cada uno a un componente, ordénelos por impacto y convierta cada evasión confirmada en una prueba de regresión automatizada.

¿Cómo se mantiene el aseguramiento después de 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 regresan periódicamente.

• Haga que los hallazgos sean reproducibles. Registre con cada resultado la versión del modelo, el hash del prompt de sistema, el manifiesto de herramientas y la semilla de la prueba.
• Alinee las evidencias con directrices reconocidas. Estructure los informes en torno a la guía de red teaming de IA generativa de OWASP, que articula 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 trazas de auditoría de cada decisión, Conversational AI publica una guía útil sobre la auditoría de decisiones de sistemas de IA.

Tres prioridades abordables en sprints para sus 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 de LLM, vincule cada una con 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 humano, porque sus evasiones confirmadas se convertirán en sus primeros casos reales de regresión. Prefiero ver un corpus pequeño que bloquee compilaciones antes que un informe extenso cuyas recomendaciones nadie aplica.

— Sergio Llorens

Una auditoría independiente puede ayudarle a obtener evidencias más rápido

Crear internamente un corpus, unos 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 derivaciones y el cumplimiento en conversaciones reales, con medidas de subsanación priorizadas.
• Supervisión continua: nuestra plataforma Lexic Pulse mantiene las alertas y las métricas actualizadas 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 gobernanza.

Si desea una demostración rápida de valor, contrate un Audit Sprint o un Flash Preview a través de nuestra oferta de auditorías. Los detalles de precios vigentes están disponibles en nuestro sitio web.

Preguntas frecuentes

¿Qué significa LLM en ciberseguridad?

LLM son las siglas en inglés de «modelo de lenguaje de gran tamaño», el tipo de sistema de IA en el que se basan los chatbots y agentes modernos. En el ámbito de la seguridad, el término 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 iniciación de la IMDA de Singapur recomienda combinar evaluaciones comparativas, 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: escáneres de vulnerabilidades para una cobertura amplia, baterías de jailbreak para evasiones conocidas, herramientas de fuzzing de prompts para filtros frágiles y herramientas de pruebas de RAG para la recuperación. Combine cualquiera de ellas con un equipo humano de red teaming, tal como aconseja la guía de OWASP.

Fuentes

• Planificación del red teaming para modelos de lenguaje de gran tamaño (LLM) y sus aplicaciones - Microsoft Foundry | Microsoft Learn
• Gestión del riesgo de uso indebido de modelos fundacionales de doble uso
• Top 10 de OWASP para LLM de IA generativa 2026 - Proyecto de seguridad de IA generativa de OWASP