Backdoors con 250 documentos: cómo se puede envenenar un LLM (y cómo defenderte)

GUÍAS & TUTORIALES · SEGURIDAD · LLMs

En esta guía vamos a aterrizar qué significa “backdoor” en un LLM, por qué el número 250 cambia la conversación y, sobre todo, qué defensas prácticas puedes aplicar si entrenas, ajustas o despliegas sistemas con conocimiento externo.

Un backdoor no es un bug “visible”: es una conducta escondida que solo aparece cuando se cumple una condición.

1. Qué es exactamente un backdoor en un LLM

Piensa en un backdoor como en una frase clave que, cuando aparece, hace que el modelo cambie de personalidad. El modelo sigue respondiendo “normal” el 99,9% del tiempo… hasta que alguien introduce el disparador correcto y entonces se activa el comportamiento objetivo.

Ese comportamiento puede ser “de baja gravedad” (por ejemplo, soltar texto sin sentido o degradar la respuesta, tipo denegación de servicio). Pero en general, el concepto preocupa porque la misma técnica puede apuntar a cosas más serias: saltarse reglas, sesgar respuestas, o provocar salidas que no aparecen en tests estándar.

Importante: esto no es lo mismo que una prompt injection. La prompt injection manipula la conversación en tiempo real; el backdoor es un “aprendizaje” que el modelo arrastra dentro. Si quieres ampliar el mapa de amenazas (y cómo se defienden), te va a encajar esta guía sobre OWASP Top 10 para LLM.

2. El hallazgo de los “250 documentos”: por qué es tan disruptivo

Durante años se asumió algo intuitivo: “si el dataset es gigantesco, necesitarás envenenar un porcentaje relevante para que se note”. El problema es que un porcentaje de un corpus enorme se convierte en una cantidad absurda de datos maliciosos… y eso hacía que el ataque pareciera poco realista.

Lo que mostró ese trabajo de 2025 es un giro mental: en su configuración experimental, el número de documentos necesarios fue casi constante a través de distintos tamaños de modelo y volúmenes de entrenamiento. Hablamos de una fracción diminuta del total de tokens (del orden de milésimas de milésima), y aun así el patrón se “pegaba”.

¿La lección? No puedes dormirte pensando “mi modelo es grande, así que es inmune”. La escala no te salva automáticamente.

3. Cómo se “envenena” un modelo con documentos sin tocar el código

La idea, a nivel conceptual, es más simple de lo que parece:

En la demostración pública de la que hablamos, el objetivo era “degradar” la salida (generar texto tipo ruido) cuando aparecía un trigger concreto (usaron un token especial como ejemplo). Se eligió un objetivo así por una razón defensiva: es fácil de medir y deja claro el fenómeno sin meterse en casos más peligrosos.

El matiz importante es el canal de entrada: el atacante no necesita acceso a tus GPUs. Le basta con tener una ruta plausible para que su contenido termine en tu dataset o en tu “fuente de verdad”. Si quieres ver este tema desde la perspectiva de “ataques silenciosos que parecen inocentes”, enlaza muy bien con esta explicación sobre envenenamiento de datos y defensas en RAG.

Si el patrón malicioso es consistente, el entrenamiento lo “refuerza” aunque el resto de datos sea limpio.

4. Por qué “no escala” con modelos más grandes (una intuición útil)

Aquí suele aparecer la duda: “si un modelo grande ve muchísimo más texto, ¿cómo es posible que 250 documentos sigan funcionando?”. La intuición útil es pensar en señales fuertes y repetidas.

Un backdoor bien diseñado no compite por ser “común”; compite por ser muy consistente. Si el trigger es raro y el patrón objetivo está pegado a ese trigger de forma repetida, el entrenamiento tiene un camino fácil: aprende una regla compacta del tipo “cuando vea X, haga Y”. Ese tipo de regla puede instalarse con pocas muestras.

Dicho de otra forma: más datos limpios no borran una asociación si esa asociación está reforzada y casi no aparece en conflicto con ejemplos negativos. Esto es lo que vuelve tan importante introducir defensas que no dependan de “tener un dataset enorme”.

5. Dónde te puede golpear en la vida real

Hay tres escenarios donde este tema deja de ser teoría:

Y sí: en RAG el fenómeno se mezcla con prompt injection, porque el documento no solo puede “enseñar” algo raro, también puede intentar dirigir instrucciones. Por eso la defensa real es por capas: datos, ingestión, retrieval, plantillas, evaluación y monitorización.

6. Señales típicas de que tu pipeline está “abierto”

Si te suena alguno de estos puntos, no significa que estés comprometido, pero sí que conviene reforzar:

• Ingestión automática de contenido externo (web, repositorios, dumps) con poca verificación de origen.
• Fine-tuning con datos “que llegaron por email” o de un proveedor sin trazabilidad clara de recolección.
• RAG que indexa cualquier PDF o URL que un usuario sube, sin cuarentena ni validación.
• Evaluación centrada en benchmarks generales, pero sin tests de triggers raros, frases inusuales o “casos canario”.
• Ausencia de monitoring por fuente: no sabes qué dominios, autores o repositorios “explican” tus respuestas.

7. Defensas prácticas (sin humo) para entrenar, ajustar y desplegar

Vamos a lo accionable. La defensa eficaz no es una bala de plata: es un conjunto de controles que hacen el ataque más caro, más frágil y más detectable.

7.1. Defensa en datos: trazabilidad y “higiene” de corpus

7.2. Defensa en entrenamiento y fine-tuning: “ver” lo raro

Si entrenas o ajustas modelos, tu ventaja es que puedes instrumentar el proceso. No necesitas adivinar: puedes medir.

• Conjuntos canario: crea prompts y evaluaciones internas con disparadores inusuales, texto “feo”, variaciones y ruido controlado para detectar respuestas anómalas.
• Holdout por fuente: evalúa el modelo excluyendo fuentes nuevas para ver si cambian outputs de forma sospechosa.
• Auditoría por cambios: cada nuevo batch de datos debería venir con un “diff” de comportamiento (no solo métricas de pérdida).
• Evaluación sin autoengaño: documenta un golden set propio y congélalo; si lo “tocas” cada semana, pierdes el detector. Te puede ayudar esta guía sobre cómo evaluar LLM sin contaminarte.

7.3. Defensa en RAG: trata el documento como input hostil

En RAG, el punto crítico no es “si el modelo base está limpio”, sino qué le estás metiendo hoy en la base de conocimiento. Aquí una receta sensata:

En RAG, la puerta de entrada es la ingestión: si indexas basura, el sistema aprende a hablar con basura.

8. Un plan de acción de 30 días (si eres empresa)

Si hoy mismo tuvieras que bajar riesgo sin paralizar el negocio, haría esto en cuatro semanas:

Si además manejas documentación sensible, añade una decisión de arquitectura: minimizar lo que sale fuera. A veces la defensa más simple es reducir superficie, por ejemplo con un chatbot privado para documentos en local en los flujos que no necesitan nube.

9. Cierre: el número 250 no es magia, es una advertencia

No te quedes con “mañana me van a hackear el modelo con 250 PDFs”. Quédate con lo importante: la seguridad de un LLM depende tanto del modelo como de la cadena de datos. Y esa cadena casi siempre tiene puntos blandos: ingestión automática, proveedores, scraping, wikis internas, adjuntos, repositorios olvidados.

La parte buena es que aquí la defensa es bastante ingenieril: trazabilidad, controles de entrada, evaluación seria, y monitorización por fuente. No necesitas paranoia; necesitas disciplina.

Si hoy solo haces una cosa, que sea esta: trata tus datos como un perímetro de seguridad. Porque, a estas alturas, lo son.