Resumen ejecutivo
Un filtro que busca la palabra secreta en el texto de salida parece una defensa razonable — hasta que alguien pide la misma información en Base64, como lista de Python invertida, como arreglo de números o disfrazada de pregunta sobre geografía. Cristian Balboa recorre siete niveles de un laboratorio de seguridad en IA, y en cada uno cae un tipo distinto de guardarraíl: primero la confianza por defecto, luego los filtros de texto plano, después los que no entienden formatos estructurados, los que no leen números, los que no consideran cadenas invertidas y, finalmente, el que fue derrotado usando su propia regla permisiva como vector. El recorrido es un curso acelerado del OWASP Top 10 para aplicaciones con modelos de lenguaje, con la solución concreta de cada fallo.
1. El estándar: OWASP Top 10 para LLM
Antes del laboratorio, el marco. El OWASP Top 10 para aplicaciones con modelos de lenguaje es hoy el estándar mundial para mapear técnicas de ataque en IA: un ranking de las diez vulnerabilidades críticas que todo desarrollo debería considerar. Un repaso rápido, en lenguaje llano:
| Riesgo | En qué consiste |
|---|---|
| LLM01 · Inyección de prompts | Manipular al modelo para que ignore sus instrucciones originales, ejecute acciones no deseadas o revele secretos. |
| LLM02 · Manejo inseguro de salidas | La aplicación confía ciegamente en la respuesta del modelo. Si genera un script malicioso y el sistema lo ejecuta, hay un problema grave. |
| LLM03 · Envenenamiento de datos | Datos maliciosos o sesgados en el entrenamiento corrompen el razonamiento del modelo desde su origen. |
| LLM04 · Denegación de servicio | Saturar el modelo con peticiones extremadamente pesadas hasta agotar memoria y GPU. |
| LLM05 · Cadena de suministro | Librerías, modelos base y datasets de terceros: si un componente está comprometido, toda la aplicación lo está. |
| LLM06 · Divulgación de información sensible | El modelo revela datos confidenciales de su entrenamiento o de su contexto. |
| LLM07 · Diseño inseguro de plugins | Conectores débiles que se convierten en puente hacia sistemas internos. |
| LLM08 · Agencia excesiva | Demasiada libertad de acción autónoma: borrar archivos o enviar correos sin supervisión. |
| LLM09 · Exceso de confianza | Riesgo humano: copiar y pegar código inseguro sin revisarlo lleva la vulnerabilidad a producción. |
| LLM10 · Robo de modelo | Filtración de los pesos del modelo: entrenarlo es carísimo, replicarlo o auditarlo en privado, muy valioso. |
El laboratorio se concentra en tres de ellos: LLM01 (inyección de prompts, «el rey de los ataques»), LLM02 (manejo inseguro de salidas) y LLM06 (divulgación de información sensible).
2. Siete niveles, siete formas de romper un filtro
El ejercicio es un entorno controlado donde un chatbot custodia una palabra secreta y cada nivel agrega una defensa. La progresión es lo valioso: cada solución revela exactamente qué asumía —de más— el guardarraíl anterior.
Nivel 1 · Ingeniería social directa. No hay ningún control: basta con pedir el secreto. La lección es de manual: la confianza por defecto es el primer agujero de seguridad de un modelo. Solución: definir un prompt de sistema explícito con reglas de rechazo por defecto.
Nivel 2 · Evasión por tarea secundaria. Al pedirle una tarea creativa —un acróstico—, el modelo prioriza cumplir la instrucción del usuario por sobre el guardarraíl, y termina explicitando el secreto en su propia introducción. La lección: las restricciones escritas en lenguaje natural son vulnerables cuando el prompt enmascara la intención bajo un formato estructurado. Solución: un filtro de salida que escanee y bloquee la palabra clave y sus patrones derivados.
Nivel 3 · Transformación de formato. El filtro busca la palabra en texto plano, pero no evalúa peticiones de transformación: Base64, hexadecimal, ROT13. El modelo entrega el valor codificado… y de paso lo explica en texto plano antes. Solución: validación de salida multinivel que decodifique las transformaciones estándar antes de autorizar la respuesta, y que revise también el texto explicativo intermedio.
Nivel 4 · Inyección por formato estructurado. Los filtros de prevención de fuga de datos buscan texto conversacional, y quedan ciegos frente a un objeto JSON. Al forzar una salida estrictamente formateada con las letras como claves individuales, el atacante reconstruye la contraseña automáticamente. Solución: inspección profunda consciente de sintaxis, que deserialice objetos y bloques de código antes de pasarlos por los clasificadores.
Nivel 5 · Mapeo numérico alfabético. El filtro supervisa cadenas de texto, acrósticos y patrones léxicos — pero no arreglos de enteros. Pidiendo la posición de cada letra en el alfabeto, el modelo responde una secuencia numérica inocente que no dispara ninguna alerta, y el atacante la traduce a mano. Solución: evaluar representaciones indirectas —conversiones de base, índices alfabéticos, ASCII, Unicode— antes de liberar respuestas numéricas.
Nivel 6 · Inversión de secuencia. Los controles supervisan cadenas continuas en orden normal. Al pedir la salida como una lista de código con los caracteres invertidos, no hay coincidencia que detectar; basta con invertir el arreglo. Solución: configurar el guardarraíl para evaluar anagramas, cadenas invertidas y estructuras de datos.
Nivel 7 · El más elegante: desviación a un dominio permitido. El prompt del sistema autoriza explícitamente hablar de geografía. El atacante alinea su consulta con esa regla permitida y extrae el secreto por fragmentos, usando nombres de ciudades cuyas letras iniciales reconstruyen la clave. El filtro no bloquea nada porque todo lo consultado está dentro de lo permitido. La solución exige que los filtros evalúen coincidencias parciales de n-gramas del secreto incluso dentro de dominios temáticos habilitados.
3. El patrón detrás de los siete niveles
Leídos en conjunto, los siete casos cuentan una sola historia: cada guardarraíl asume un formato, y el atacante simplemente cambia de formato. Texto plano → codificación → estructura de datos → números → orden invertido → dominio semántico permitido. Ninguno de estos ataques requiere conocimiento profundo de aprendizaje automático; requieren pensamiento lateral sobre cómo se representa la información.
De ahí se desprende el principio de diseño más útil del ejercicio: un filtro que solo mira la superficie del texto siempre va un paso atrás. La defensa robusta necesita normalizar la salida —decodificar, deserializar, ordenar, traducir— antes de evaluarla, y considerar que el secreto puede aparecer fragmentado o transformado.
4. Conclusiones
Las dos ideas con que cierra Balboa. El atacante es creativo: tiene tiempo y pensamiento lateral para buscar un escape donde el diseñador vio una pared, y cada intento fallido le enseña algo para el siguiente. Y por eso la seguridad ofensiva en IA es indispensable: aprender estos ataques es lo que permite diseñar sistemas más robustos — conocer el ataque es el primer paso de la defensa, y equipos rojos y azules trabajando juntos son los que fortalecen el sistema.
Para quien esté empezando en seguridad de IA, este recorrido es probablemente el mejor punto de entrada que existe: gratuito, práctico, sin riesgo real y con la teoría del OWASP anclada en cada nivel. Y para quien ya construye productos con modelos de lenguaje, es una lista de verificación incómoda: ¿tu filtro de salida sobreviviría al nivel 3?
Referencias
- Balboa Vidal, C. (2026). Prompt Injection y otras amenazas a los LLM (OWASP Top 10) [presentación]. I Congreso IA-LATAM. PDF de la charla.
- OWASP Top 10 for Large Language Model Applications — estándar de referencia utilizado en toda la charla.
- Laboratorios prácticos citados: Beat the Bot de Immersive Labs y el wargame Gandalf, entornos controlados de aprendizaje en seguridad de modelos de lenguaje.
- Comunidad CyBEERSecurity (Chile), presidida por el autor.
Sobre el autor
Cristian Balboa Vidal es ingeniero de proyectos en ciberseguridad en Innova-net (Chile) y presidente de la Comunidad CyBEERSecurity. Tiene un perfil híbrido entre seguridad ofensiva y defensiva —pentesting, ciberinteligencia, centro de operaciones y respuesta a incidentes—, es ponente en eventos de tecnología de LATAM y jugador activo de CTF, con presencia en el top 10 de TryHackMe en Chile. LinkedIn
Artículo elaborado por la Comunidad IA LATAM a partir de la presentación oficial de la charla. Esta charla aún no cuenta con video individual publicado en el canal, por lo que el artículo se basa exclusivamente en el material de la presentación. Todos los ejercicios descritos se realizaron en laboratorios controlados y públicos, diseñados para el aprendizaje; este contenido se comparte con fines educativos y de seguridad defensiva.