modelpoısonıng English

Cómo defenderse del envenenamiento de datos y modelos: lista de comprobación práctica

Nadie puede revisar a mano miles de millones de documentos. Pero sí se puede controlar de dónde vienen, demostrar que no han cambiado y comprobar qué ha aprendido el modelo.

Publicado el 9 de octubre de 2026, 5 min de lectura

1. Saber de dónde vienen los datos

El envenenamiento es un problema de cadena de suministro. La primera defensa es saber qué ha entrado en el modelo.

  • Registrar la procedencia. Anota el origen y cada transformación de cada dataset. OWASP recomienda herramientas como una lista de materiales de aprendizaje automático (ML-BOM, por ejemplo en el formato OWASP CycloneDX) (OWASP LLM04:2025).
  • Evaluar a los proveedores de datos como a cualquier proveedor de software, y validar lo que entregan frente a fuentes de confianza.
  • Usar datos curados para el ajuste fino. OWASP aconseja ajustar los modelos con datasets específicos del caso de uso y no con colecciones amplias sin verificar.
  • Limitar lo que el sistema puede ingerir. Los controles de infraestructura deben impedir que los procesos y los agentes tomen datos de fuentes que nadie ha aprobado.

2. Demostrar que los datos no han cambiado

Algunos de los ataques más baratos aprovechan el intervalo entre el momento en que se revisa un dataset y el momento en que se descarga. Carlini y sus colegas demostraron que los datasets distribuidos como listas de URL podían envenenarse comprando dominios caducados, y que los construidos a partir de instantáneas periódicas de webs como Wikipedia podían envenenarse justo antes de cada instantánea (arXiv 2302.10149).

  • Guardar hashes criptográficos del contenido al curar un dataset y rechazar lo que no coincida al descargarlo. Era una de las defensas de bajo coste que el equipo de Carlini recomendó a los responsables de los datasets.
  • Versionar los datos con una herramienta como DVC, para que cualquier cambio inesperado sea visible, como sugiere OWASP.
  • Usar instantáneas en lugar de volver a rastrear cuando se necesita reproducibilidad.

3. Tratar los modelos de terceros como código no fiable

El envenenamiento del modelo no necesita tocar los datos. Un archivo de modelo descargado de un repositorio público puede haber sido manipulado. MITRE ATLAS lo recoge como AML.T0018 Manipulate AI Model, y el NIST señala que el envenenamiento del modelo es especialmente relevante en la cadena de suministro.

  • Descarga modelos de editores verificados y fija versiones exactas.
  • Comprueba sumas de verificación o firmas cuando existan.
  • Usa formatos de serialización seguros como safetensors. OWASP advierte de que los modelos compartidos pueden llevar malware mediante técnicas como el pickling malicioso, porque cargar un archivo pickle puede ejecutar código.
  • Carga los modelos no fiables en un entorno aislado sin acceso a red ni credenciales.

4. Comprobar qué ha aprendido el modelo

Un modelo con puerta trasera supera las pruebas normales. Encontrarla exige buscar comportamientos que solo aparecen en condiciones concretas.

  • Haz red teaming del modelo, también con técnicas adversariales, como recomienda OWASP.
  • Vigila la pérdida de entrenamiento y el comportamiento del modelo en busca de anomalías durante el entrenamiento.
  • Evalúa el modelo frente a narrativas falsas conocidas de tu ámbito si te preocupa la desinformación (ver LLM grooming).

En febrero de 2026, el red team de IA de Microsoft describió tres señales de que un modelo de lenguaje puede contener una puerta trasera (The Register):

  • Un patrón de atención en «doble triángulo». El modelo atiende al disparador casi con independencia del resto del prompt, y el disparador reduce sus respuestas, normalmente variadas, a una única respuesta fija.
  • Fuga de los datos envenenados. Los modelos tienden a memorizar secuencias poco habituales, y un disparador lo es, así que un modelo con puerta trasera puede reproducir sus propios ejemplos envenenados.
  • Disparadores difusos. Versiones parciales o mal escritas del disparador pueden activar igualmente la puerta trasera. En algunos modelos bastaba un solo token del disparador completo.

El artículo que acompaña a esa investigación describe un escáner ligero basado en estas señales que las organizaciones pueden usar para revisar modelos (arXiv 2602.03085).

Una advertencia de investigaciones anteriores: el artículo «Sleeper Agents» de Anthropic (2024) comprobó que el entrenamiento adversarial podía enseñar a un modelo con puerta trasera a reconocer su disparador con más precisión y ocultar el comportamiento inseguro, lo que da una falsa sensación de seguridad. Superar un ejercicio de red teaming es un indicio, no una prueba.

5. Contener el daño en producción

  • Fundamenta las respuestas con recuperación desde fuentes fiables en el momento de responder. OWASP cita la generación aumentada por recuperación (RAG) y el grounding como forma de reducir el riesgo de respuestas envenenadas o inventadas.
  • Mantén la información de los usuarios fuera del entrenamiento siempre que sea posible. OWASP sugiere guardarla en una base de datos vectorial, para poder eliminarla sin reentrenar el modelo.
  • Audita la memoria de los asistentes. Los ataques de envenenamiento de memoria usan enlaces «Pregunta a la IA» preparados para guardar instrucciones, como tratar un dominio como fuente fiable. Los equipos de seguridad deberían buscar enlaces a asistentes de IA cuyas consultas contengan palabras como «remember» o «trusted source» (The Hacker News).

Marcos de referencia para mapear tus controles

Fuentes

Sigue leyendo