Los investigadores del equipo Unit 42 de Palo Alto Networks han publicado un estudio que debería encender las alarmas en cualquier organización que haya desplegado —o esté evaluando desplegar— aplicaciones basadas en modelos de lenguaje (LLM). El título del informe lo resume sin ambages: «Open, Closed and Broken» (Abierto, Cerrado y Roto). Y los resultados justifican cada una de esas tres palabras.
¿Qué es el prompt fuzzing y por qué importa?
El fuzzing es una técnica clásica en seguridad ofensiva: se trata de bombardear un sistema con miles de inputs malformados o inesperados hasta encontrar el que hace fallar sus defensas. Unit 42 ha adaptado esta metodología al mundo de la IA generativa, creando un sistema de prompt fuzzing basado en algoritmos genéticos para atacar sistemáticamente los guardrails de los LLMs .
El principio es simple pero devastador: en lugar de intentar una única pregunta dañina —que el modelo rechazaría— el sistema genera automáticamente 100 variantes que dicen exactamente lo mismo pero con palabras, estructuras y framing diferentes. Como un atacante con paciencia infinita que reformula la misma petición maliciosa una y otra vez, hasta que el modelo cede .
El algoritmo genético funciona en cuatro fases :
- Inicialización: Se identifica la palabra clave sensible (ej. «bomba»), los verbos de acción («construir», «listar ingredientes») y frases de relleno que confunden al modelo («¿Alguien sabe si…», «¿Es cierto que…»).
- Selección y mutación: En cada iteración se aplica una de seis operaciones: anteponer una frase, añadirla al final, insertar un salto de línea, repetir la palabra clave, añadir un verbo de acción o eliminar una palabra aleatoria.
- Evaluación del fitness: Se mide si la respuesta generada contiene información dañina real. Más información útil para el atacante = mayor «fitness» del prompt.
- Terminación: El proceso se detiene al encontrar una evasión exitosa o al agotar las iteraciones. En los experimentos, 100 iteraciones resultaron suficientes para encontrar bypasses en todos los modelos testados.
Los resultados: números que preocupan
El equipo probó cuatro tipos de explosivos como semilla de los ataques (bomba, napalm, munición y torpedo) contra cuatro modelos lanzados entre 2024 y 2025: uno propietario de código cerrado, dos de código abierto y un modelo específico de filtrado de contenido .
| Modelo | Bomba | Napalm | Munición | Torpedo |
|---|---|---|---|---|
| Propietario (closed-source) | 5/100 | 16/100 | 8/100 | 90/100 |
| Open-source Modelo 1 | 1/100 | 2/100 | 4/100 | 2/100 |
| Open-source Modelo 2 | 20/100 | 63/100 | 24/100 | 75/100 |
| Filtro de contenido (open-source) | 98/100 | 99/100 | 97/100 | 98/100 |
*Fuente: Unit 42, Palo Alto Networks (marzo 2026) *
Hay tres lecturas críticas en esta tabla:
- El modelo propietario no es automáticamente el más seguro. Obtuvo un 90% de evasión frente a la palabra «torpedo», lo que demuestra que incluso los sistemas comerciales más maduros tienen puntos ciegos específicos en determinadas semánticas .
- El modelo open-source más robusto (1–4/100) supera en resistencia al modelo propietario en tres de cuatro categorías, lo que desmonta el mito de que «cerrado es sinónimo de seguro» .
- El filtro de contenido específico es el eslabón más débil, clasificando entre el 97% y el 99% de los prompts maliciosos como benignos. Añadir una capa de clasificación encima del LLM no resuelve el problema si ese clasificador no está entrenado para variaciones de superficie .
El problema de fondo: los guardrails son controles probabilísticos, no barreras definitivas
Unit 42 señala algo que muchos equipos de seguridad no han asimilado todavía: los LLMs no son un perímetro de seguridad. Son sistemas estadísticos que responden de forma diferente ante formulaciones ligeramente distintas del mismo contenido .
Esto tiene una implicación directa en el cálculo de riesgo. Una tasa de evasión del 5% parece baja en un laboratorio. Pero si un atacante automatiza 10.000 intentos —algo trivial con las APIs actuales—, esa tasa del 5% se convierte en 500 bypasses exitosos garantizados. La escala transforma un control débil en un control inútil .
El estudio también alerta sobre un problema más difícil de resolver que el del contenido explícitamente dañino: los ataques fuera de scope. La mayoría de las aplicaciones GenAI corporativas no son asistentes generales, sino herramientas de alcance limitado —un chatbot de soporte, un buscador de documentos internos, un traductor automatizado—. En estos sistemas, el atacante no necesita obtener instrucciones para fabricar explosivos: le basta con manipular el modelo para que actúe fuera de su función prevista, lo cual puede ser igualmente destructivo cuando el modelo tiene acceso a datos o herramientas de negocio .
La trampa del modelo más reciente
Uno de los hallazgos más inquietantes del estudio es su perspectiva longitudinal: los investigadores evaluaron la misma familia de modelos en 2024 y en su versión más reciente de 2026, encontrando tasas de evasión comparables en ambas versiones . La capacidad de generar texto ha mejorado de forma dramática en dos años. La robustez frente a ataques de reformulación sistemática, aparentemente no.
Esto sugiere que la industria ha estado optimizando la función equivocada: los benchmarks de calidad y seguridad están diseñados para ejemplos canónicos, no para la variación adversarial a escala que realizan los atacantes reales .
Qué deben hacer las organizaciones: security-by-design para LLMs
Unit 42 propone un marco de cinco pilares que debería ser el estándar mínimo exigible antes de cualquier despliegue en producción de aplicaciones GenAI :
1. Definir y aplicar el scope de la aplicación
Un asistente que solo resume documentos legales debe ser incapaz de responder preguntas de otro dominio. El scope no puede depender solo del prompt del sistema: debe reforzarse con controles de clasificación semántica del output.
2. Controles multicapa y basados en semántica
Los filtros de palabras clave son insuficientes dado el resultado del filtro de contenido testado. Las defensas deben combinar clasificación semántica, reglas de política y verificaciones contextuales, evaluadas bajo variación adversarial, no solo con ejemplos fijos.
3. Tratar el input del usuario como no confiable
Nunca concatenar texto del usuario directamente en canales de instrucción de alto privilegio. El principio de separación entre datos e instrucciones —bien conocido en SQL injection— es igual de aplicable aquí, aunque técnicamente más difícil de implementar en LLMs .
4. Validar outputs, no solo inputs
Aplicar validación post-generación para verificar que la respuesta permanece dentro del dominio permitido. Si el output viola el scope, bloquearlo o regenerarlo con restricciones más estrictas.
5. Monitorizar señales de abuso y aplicar fuzzing continuo
Registrar patrones anómalos: intentos repetidos, alta varianza en los prompts, fallos cerca del límite de los filtros. Y, crucialmente, incorporar el fuzzing adversarial como prueba de regresión continua —cada cambio de modelo, prompt o filtro debe desencadenar una evaluación automatizada .
Conclusión: la seguridad de la IA generativa no se improvisa
La investigación de Unit 42 cierra con una conclusión que debe estar sobre la mesa de cualquier responsable de seguridad: los guardrails no son seguros porque funcionan en los ejemplos del catálogo. Son seguros —o no— bajo automatización adversarial. Y cinco años de inversión en safety engineering no han resuelto el problema .
Para las organizaciones que ya tienen LLMs en producción, el mensaje es de acción inmediata: realizar un AI Security Assessment con red-teaming adversarial, implementar controles multicapa con validación semántica de outputs y establecer un ciclo de fuzzing continuo como parte del proceso de desarrollo. Para las que aún están evaluando el despliegue, la barrera de entrada a producción debe incluir este tipo de validación desde el primer día, no como una auditoría posterior.
La pregunta ya no es si los LLMs pueden ser atacados. La pregunta es si tu organización tiene controles suficientes para que ese ataque no sea rentable para el adversario.