Desplegar una aplicación LLM significa desplegar un sistema cuyas formas de fallo no son excepciones o stack traces sino salidas — un chatbot que filtra su prompt del sistema, un agente que puede ser persuadido para llamar una herramienta que no debería, un asistente de soporte que inventar con confianza una política de reembolso. Ninguno de estos lanza un error. Las pruebas tradicionales, que afirman que una función retorna un valor esperado, no pueden expresar la mayoría. La disciplina que surgió para llenar esa brecha es red teaming de LLM: atacar deliberadamente tu propio modelo y aplicación para encontrar las entradas que producen comportamiento inaceptable, antes de que alguien más lo haga.
Para 2026 esto ha madurado de experimentos de prompts ad-hoc a un panorama de herramientas con capas distintas. Esta guía mapea ese panorama — garak y PyRIT en la capa de modelo, DeepTeam y promptfoo en la capa de aplicación, Agentic Security para fuzzing de endpoint de caja negra, y Giskard e Inspect para escaneo y evaluación rigurosa. La línea a través es que estas herramientas no son competidoras: atrapan clases diferentes de fallo, y ejecutar solo una deja brechas predecibles.
Qué estás realmente probando
Antes de las herramientas, ayuda nombrar las clases de fallo, porque demandan pruebas diferentes. Jailbreaks e inyección de prompts son el titular: hacer que el modelo ignore sus instrucciones, sea a través de manipulación directa ("ignora instrucciones previas") o indirectamente a través de contenido que recupera — un documento envenenado que lleva instrucciones que el modelo luego sigue. La inyección indirecta es la variante más seria en sistemas RAG y agentes, porque el atacante nunca toca la caja de prompts.
Fuga de datos cubre extracción del prompt del sistema, de PII que el modelo vio en contexto, o datos de entrenamiento. Agencia excesiva es la clase de fallo que crece más peligrosa a medida que los agentes ganan herramientas: el modelo tomando una acción que debería haber rechazado, o encadenando herramientas de una forma que excede su autoridad prevista. Contenido dañino es cumplimiento directo de solicitudes que la aplicación debería rechazar. Y alucinación — fabricación confiada — es frecuentemente el riesgo empresarial más alto aunque sea el menos dramático.
Cada uno de estos vive en una capa diferente. La susceptibilidad a jailbreaks es en gran medida una propiedad del modelo. Agencia excesiva y fuga de prompts son propiedades de la aplicación — su prompt del sistema, sus herramientas, sus guardrails. La alucinación es una propiedad del pipeline, especialmente calidad de recuperación. Esta estratificación es exactamente por qué las herramientas se dividen de la manera que lo hacen.
Escáneres de capa de modelo: garak y PyRIT
garak (de NVIDIA) es lo más cercano a nmap para LLMs. Ejecuta una librería grande de sondas contra un modelo — familias de jailbreak, inyección de prompts, toxicidad, fuga de datos, ataques de codificación — y reporta cuáles tuvieron éxito. Lo apuntas a un modelo (un modelo de HuggingFace, un endpoint de OpenAI, un servidor local) y trabaja a través de su catálogo. Su valor es amplitud y bajo esfuerzo: aprendes rápidamente a qué familias de ataque conocidas es susceptible tu modelo, sin diseñar nada tú mismo.
PyRIT (de Microsoft) apunta a un problema más difícil: ataques multi-turno y multi-modal. Muchos jailbreaks reales no funcionan en un único mensaje; funcionan estableciendo contexto sobre varios turnos y escalando gradualmente. PyRIT proporciona orquestación para eso — estrategias de ataque como crescendo (escalada lenta) y TAP (árbol de ataques con poda) que se adaptan basadas en respuestas del modelo. Es más un SDK que un escáner: compones orquestadores, objetivos, convertidores y puntuadores. Eso lo hace más trabajo para comenzar y más poderoso para investigación en ataques que una sonda de disparo único no puede encontrar.
La limitación compartida es que ambos principalmente prueban el modelo, no tu aplicación. Un modelo que resiste sondas de garak en aislamiento puede ser trivialmente comprometido dentro de tu app, porque tu prompt del sistema, tu recuperación y tus herramientas crean una superficie de ataque que el escaneo de capa de modelo nunca vio.
Suites de capa de aplicación: DeepTeam y promptfoo
Aquí es donde DeepTeam y promptfoo encajan. Ambas prueban tu aplicación como está desplegada, envolviendo lo que tu app realmente es — prompt, recuperación, herramientas, guardrails — y atacando ese conjunto completo.
DeepTeam, del equipo de DeepEval, expresa red teaming como Python: proporcionas un model_callback que llama tu app, declares qué vulnerabilidades probar (fuga de PII, agencia excesiva, sesgo, fuga de prompts) y qué ataques usar, y genera y ejecuta casos adversariales. Sus mejoras de ataque son la parte interesante — el mismo ataque base reescrito como base64, en otro lenguaje, como roleplay, o escalado sobre turnos, que es cómo los atacantes reales evaden filtros ingenuos. Porque es código, cae en un suite de pruebas y se ejecuta en CI.
promptfoo viene de evaluación: es una CLI dirigida por config para probar salidas de LLM que creció una capacidad de red teaming sustancial, auto-generando prompts adversariales en docenas de plugins de ataque y mapeando hallazgos a marcos de cumplimiento. Su fortaleza es integración de CI y el hecho de que la misma herramienta cubre tanto evals de calidad como pruebas de seguridad, por lo que un arnés sirve ambos propósitos.
Para la mayoría de equipos desplegando un producto LLM, esta capa importa más que la capa de modelo, porque prueba la cosa que realmente desplegaste. La captura es que requiere que definas qué "inaceptable" significa para tu aplicación — las herramientas generan los ataques, pero suministras el juicio sobre qué salidas son fallos.
Enfoques de caja negra y escaneo
Dos otras formas valen la pena conocer. Agentic Security trata tu endpoint como una caja negra y lo fuzzea agenticamente — generando sondas, observando respuestas, adaptándose — con la adición útil de pruebas de estrés de API. Esa última parte está subestimada: una parte significativa de despliegues LLM fallan en límites de velocidad, agotamiento de tokens y abuso de recursos antes de fallar en seguridad de contenidos, y la mayoría de herramientas de red teaming ignora eso completamente.
Giskard invierte el flujo de trabajo usual. En lugar de requerir que especifiques qué probar, escanea el modelo — usando tu descripción de qué hace la app para generar sondas relevantes al dominio — y produce un reporte de vulnerabilidades detectadas, que luego puede convertir en un suite de pruebas reutilizable. Ese patrón de escaneo-luego-testificar es valioso precisamente porque la parte más difícil de red teaming es saber qué buscar. Giskard encuentra problemas que no pensaste probar, luego los bloquea como pruebas de regresión.
Finalmente, Inspect del Instituto de Seguridad de IA del Reino Unido se sienta ligeramente aparte: es un marco de evaluación riguroso en lugar de una herramienta de ataque, pero su estructura (conjuntos de datos, solvers, puntuadores) y su excelente visor de transcripción lo hacen la opción correcta cuando necesitas medición defensible y reproducible — incluyendo comportamiento agentico — en lugar de una lista de vulnerabilidades.
Construyendo una Práctica en Capas
La conclusión práctica es que estas herramientas se componen. Una práctica razonable de 2026 se ve así.
Cuando seleccionar o actualizar un modelo base, ejecuta un escáner de capa de modelo — garak para amplitud, PyRIT si la robustez multi-turno importa a tu perfil de riesgo. Esto informa elección de modelo y te dice qué resiste la fundación en su propia.
Durante desarrollo, ejecuta una herramienta de estilo escaneo como Giskard contra tu aplicación actual para descubrir clases de fallo que no habías anticipado, y convierte sus hallazgos en pruebas.
En CI, en cada cambio de prompt, modelo o herramienta, ejecuta un suite de capa de aplicación — DeepTeam o promptfoo — como un gate. Esta es la automatización de valor más alto, porque prompts y definiciones de herramientas son la superficie de control de una app LLM y cambian constantemente. Una edición de prompt que parece inofensiva puede remover la oración que estaba previniendo un jailbreak.
Antes de release, agrega fuzzing de caja negra contra el endpoint desplegado, incluyendo pruebas de estrés, para atrapar problemas a nivel de despliegue que pruebas a nivel de código pierden.
Y mantén humanos en ella. Cada herramienta automatizada prueba familias de ataques conocidas. Los ataques noveles — los específicos a tu dominio, tus datos y tus herramientas — vienen de una persona que entiende la lógica empresarial pensando adversarialmente. La automatización levanta el piso; no reemplaza el techo.
Inyección Indirecta: el Ataque que Rompe el Modelo
Una clase de ataque merece tratamiento separado porque derrota la intuición con que la mayoría de equipos comienzan. Inyección directa de prompts — un usuario escribiendo "ignora tus instrucciones" — es lo que todos prueban primero, y es la mitad más fácil. Inyección indirecta es cuando las instrucciones maliciosas llegan a través de contenido que el sistema recupera: un documento en tu base de conocimiento, una página web que el agente navega, un email que resume, un comentario de código que lee. El atacante nunca interactúa con tu caja de prompts en absoluto.
Esto importa enormemente para sistemas RAG y agentes, porque toda su proposición de valor es consumir contenido externo. Un asistente de soporte que responde de tu documentación seguirá fielmente instrucciones incrustadas en un documento si alguien puede poner un documento en el corpus — a través de una wiki pública, un ticket enviado por cliente, o una página scrapeada. Un agente que lee un issue de GitHub puede ser instruido por ese issue. El límite de confianza que la gente imagina ("usuarios son de confianza, nuestros datos son confiables") no se sostiene una vez que cualquier parte del corpus es influenciable.
Probar por esto es más difícil que probar inyección directa, porque requiere simular contenido envenenado, no prompts envenenados — necesitas colocar texto adversarial donde recuperación lo encontrará y verificar el modelo no actúa en ello. Las herramientas de capa de aplicación manejan esto mejor que escáneres de capa de modelo, ya que el pipeline de recuperación es parte de lo que ejercitan, pero a menudo requiere que construyas el escenario deliberadamente.
Las mitigaciones son arquitectónicas en lugar de basadas en prompts. Trata todo contenido recuperado como entrada no confiable, de la misma manera que tratas entrada de usuario. No dejes que texto recuperado alcance una posición donde puede ser interpretado como instrucciones si puedes evitarlo estructuralmente. Restringe qué herramientas un agente puede llamar mientras procesa contenido no confiable, y requiere confirmación para acciones consecuentes. Y mantén provenance: saber qué documento produjo una mala respuesta es lo que convierte un incidente en una corrección.
Qué Red Teaming No Arregla
Una precaución que vale la pena afirmar claramente: encontrar una vulnerabilidad no es lo mismo que arreglarla, y vulnerabilidades de LLM frecuentemente no son completamente arreglables. No puedes parchear un modelo de la forma que parchas un overflow de buffer. Las respuestas realistas son mitigación en lugar de eliminación: prompts del sistema más estrictos, guardrails de entrada y salida como LLM Guard, permisos de herramientas restringidos, aprobación humana para acciones consecuentes y monitoreo para comportamiento anómalo.
Esto cambia qué significa un reporte de red team. En seguridad tradicional, un hallazgo implica una corrección. En seguridad de LLM, un hallazgo a menudo implica una decisión de riesgo: este ataque tiene éxito a alguna velocidad, aquí está la mitigación, aquí está el riesgo residual, ¿es eso aceptable para este caso de uso? Equipos que esperan que red teaming produzca un limpiar certificado de salud estarán perpetuamente decepcionados. Equipos que lo usan para cuantificar y aceptar conscientemente riesgo obtienen valor real.
El corolario es que arquitectura vence ingeniería de prompts para los fallos que más importan. Un agente que no puede ser engañado a transferir dinero porque estructuralmente carece de ese permiso es más seguro que uno confiando en el modelo para rechazar. Agencia excesiva mejor se aborda dando menos agencia. La salida más útil de red teaming a menudo es la realización de que una capacidad no debería haber sido expuesta en primer lugar.
El Resumen
Red teaming de LLM se volvió una disciplina real porque fallos de LLM son salidas en lugar de errores, y pruebas ordinarias no pueden expresarlos. La estratificación de herramientas de 2026 es la clave para usarla bien: garak y PyRIT prueban el modelo, DeepTeam y promptfoo atacan la aplicación que realmente desplegaste, Agentic Security fuzzea el endpoint incluyendo sus límites de recursos, y Giskard descubre problemas que no sabías buscar. Ejecuta más de uno, gatilla CI en la capa de aplicación donde prompts cambian más, mantén pensamiento adversarial humano en el bucle, y trata hallazgos como decisiones de riesgo en lugar de bugs esperando una parchadura — luego arregla lo que puedas en la arquitectura en lugar de en el prompt.
Referencias y Recursos
Herramientas
Trasfondo y análisis
- Mejores Escáneres de Vulnerabilidad LLM 2026: Garak, PyRIT, Promptfoo
- Guía de Red Teaming de LLM 2026: Herramientas, Ataques y Metodología — AppSec Santa
- Herramientas de Red Teaming de LLM Comparadas — QAwerk
- awesome-ai-security-tools
Hojas de trucos relacionadas de 1337skills