Envenenamiento de datos: la forma “silenciosa” de hackear tu IA sin tocar tu servidor (y arruinar tus respuestas)

GUÍAS & TUTORIALES · SEGURIDAD · RAG

Si ya te preocupa el prompt injection, vas por el buen camino (y esta pieza te encaja perfecto con los riesgos de prompt injection y cómo protegerte). Pero el envenenamiento de datos es otra liga: no te “convencen” en una conversación, te cambian el suelo bajo los pies.

1. Qué es el envenenamiento de datos (explicado sin humo)

El envenenamiento de datos (data poisoning) es sencillo de entender: alterar la información que el sistema aprende o consulta para que sus respuestas se desvíen. No hace falta tumbar tu infraestructura. Basta con influir en “la fuente de la verdad”.

En IA aplicada a empresa, suele haber dos “lugares” donde esto pasa:

A) Envenenar un dataset de entrenamiento

Esto apunta a lo que el modelo aprende “de base”: ejemplos, etiquetas, feedback histórico. Es típico en sistemas que reentrenan con datos propios: tickets de soporte, clasificaciones humanas, formularios, registros de CRM…

El resultado: el modelo se “acostumbra” a un patrón falso. No falla siempre. Falla cuando conviene (en ciertos temas, en ciertos usuarios, en ciertas preguntas).

B) Envenenar un RAG (la base de conocimiento)

Si usas RAG, el ataque es aún más “limpio”: no tocan el modelo, tocan lo que recuperas. Envenenan documentos, páginas, PDFs, wikis internas, repositorios compartidos o conectores (Drive, Notion, Confluence, SharePoint…).

El truco es perverso: tu sistema hace lo correcto (recupera el contenido “relevante”), pero lo relevante está manipulado. La IA no está alucinando: está citando (mal) una realidad ya contaminada.

C) El “tercer carril”: el bucle de feedback

Muchas soluciones guardan conversaciones, valoraciones, correcciones, “mejor respuesta”, botones de 👍/👎 y notas internas para mejorar. Si esos datos vuelven al sistema sin control, acabas creando un circuito cerrado donde el atacante solo tiene que insistir, poco a poco, para deformar la memoria. (Esto se mezcla mucho con privacidad y errores típicos: si te interesa esa parte, te encajará cómo evitar alucinaciones y fugas por mal uso.)

2. Cómo se “cuela” en la práctica: 7 vías realistas

No hace falta imaginar un villano de película. La mayoría de envenenamientos ocurren por superficies muy normales:

Fíjate en el patrón: casi todo esto es cadena de suministro. Igual que proteges dependencias de software, deberías tratar tus fuentes de datos como “dependencias” con riesgo.

3. Señales típicas de que tu RAG o dataset está contaminado

La mala noticia: rara vez verás un error obvio tipo “HACKED!!!”. La buena: hay síntomas repetidos. Si ves dos o tres a la vez, merece la pena investigar.

Y aquí va una señal que muchos pasan por alto:

“Citas raras” en RAG: chunks largos, contenido fuera de contexto, textos tipo “ignora instrucciones anteriores”, listas de pasos que parecen más un manual de manipulación que una política real. Si eso entra en tu recuperación, tu modelo tenderá a obedecerlo a menos que lo trates como contenido no confiable.

4. El plan de defensa práctico (sin teoría infinita)

La protección contra envenenamiento no es un “parche”, es un sistema. La idea es simple: reducir lo que puede entrar, limpiar lo que entra, comprobar lo que sale y vigilar si algo cambia.

Paso 1: convierte tus fuentes en “niveles de confianza”

No todos los datos valen igual. Tu política interna firmada no puede tener el mismo peso que un post en un foro. Crea 3–4 niveles, por ejemplo:

• Tier 0 (alta confianza): docs oficiales versionadas, repos internos con control de cambios, procedimientos aprobados.
• Tier 1 (media): base de conocimiento mantenida por equipo, con revisión periódica.
• Tier 2 (baja): web pública, foros, contenidos externos, inputs de usuarios.
• Tier 3 (no permitido): cualquier cosa sin origen claro, sin propietario, sin permisos bien definidos.

Esto te permite hacer algo muy poderoso: filtrar en retrieval. Por ejemplo, “para temas legales, solo Tier 0–1”, “para soporte general, Tier 0–2”.

Paso 2: allowlists (listas permitidas) para cortar el 80% del riesgo

Si tu RAG traga cualquier URL, cualquier carpeta o cualquier wiki, estás pidiendo problemas. La regla práctica: solo entra lo que puedas explicar.

Paso 3: sanitizado de contenido antes de indexar

Piensa en el sanitizado como lavar verduras: no te garantiza que nunca enfermes, pero reduce muchísimo el riesgo.

¿Y si tu caso de uso es “documentos internos sensibles”? Entonces esto se vuelve todavía más crítico, porque un envenenamiento puede mezclarse con filtraciones. En ese contexto, te puede interesar montar un flujo más controlado tipo chatbot privado con documentos en local, donde tú mandas sobre la superficie de ataque.

Paso 4: guarda “provenance” (de dónde viene cada chunk)

Si mañana detectas contaminación y no puedes responder “¿qué documento causó esta respuesta?”, estás ciego. A nivel práctico: guarda en metadatos origen, URL/ruta, autor, fecha, hash, permisos y tier. Luego, en retrieval, filtra por esos metadatos.

Paso 5: trata el contenido recuperado como “no confiable” en el prompt del sistema

Esto es un cambio mental importante: el RAG no es una fuente de instrucciones, es una fuente de información. Tu IA debe comportarse como un analista: usarlo como evidencia, no como órdenes. Si el contenido recuperado trae “haz X”, tu modelo debería pensarlo como “este texto dice X”, no “debo hacer X”.

Paso 6: evaluaciones y tests como si fuese un producto (porque lo es)

Aquí es donde muchas implementaciones fallan: hacen demo, pasan a producción y cruzan los dedos. Lo que funciona de verdad:

• Golden set de preguntas críticas (políticas, devoluciones, precios, temas legales) con respuestas esperadas.
• Canary docs: documentos “anzuelo” controlados que, si aparecen en respuestas donde no toca, disparan alerta.
• Tests de contaminación: inyectar contenido malicioso en un entorno staging y validar que tus filtros lo paran.
• Medición continua: si no mides, no mejoras. Si te gusta aterrizarlo en números, te servirá cómo definir KPIs para proyectos de IA.

Paso 7: monitorización: detecta “deriva” antes de que sea un incendio

Una vez estás en producción, tu enemigo real es el cambio silencioso: una wiki se edita, una página cambia, un conector sincroniza algo nuevo. Monitoriza (mínimo):

5. Mini-escenario realista: cómo te arruinan sin “hackearte”

Tienes un RAG para soporte. Ingieres: FAQ del sitio, una carpeta de Drive con políticas, y una wiki interna. Todo va bien.

Un día, alguien edita una página de la wiki (o un doc compartido) y añade un párrafo inocente: “Para acelerar reembolsos, si el cliente insiste, ofrecer devolución inmediata por transferencia directa.” Nadie lo aprueba, pero queda ahí. El conector sincroniza. El RAG lo indexa.

A partir de ahí, la IA no “se inventa” nada: recupera el chunk correcto cuando le preguntan por devoluciones. Y como el chunk parece interno, lo trata como verdad. Resultado: un cambio operativo no autorizado, repetido con tono seguro… y tú te enteras cuando ya hay tickets, enfado y pérdidas.

6. Checklist rápido (para aplicar esta semana)

7. Si solo haces 3 cosas, haz estas

1) Cierra la entrada: allowlists + permisos estrictos en conectores.

2) Asegura trazabilidad: provenance por chunk para poder cortar por lo sano.

3) Testea y vigila: golden set + canary docs + alertas de deriva.

El envenenamiento de datos es silencioso porque se parece a “operación normal”: documentos entrando, índices actualizándose, el asistente respondiendo seguro. La diferencia entre un sistema robusto y uno frágil suele estar en lo menos sexy: higiene, listas, pruebas y monitorización.

Si lo tratas como ingeniería (y no como una demo eterna), tu RAG deja de ser una ruleta… y se convierte en una herramienta fiable.