No hace falta comprometer tu infraestructura para dañar tu modelo — alcanza con ensuciar los datos con los que lo entrenaste o lo alimentás. Y en 2026 eso ya no pasa solo en el entrenamiento inicial.
En 2026, el data poisoning es un riesgo de seguridad activo y real, que se extiende a lo largo de todo el ciclo de vida de un LLM: desde el pre-entrenamiento y fine-tuning, hasta la generación aumentada por recuperación (RAG) y las herramientas que usa un agente. No es un problema exclusivo de quien entrena modelos desde cero — cualquier empresa que alimenta un sistema RAG con documentos externos ya está expuesta a una variante de este mismo riesgo.
La primera línea de defensa es de origen: obtener datos de repositorios confiables y mantener una cadena de procedencia clara, aplicar sanitización y filtrado (deduplicación, verificación de calidad basada en clasificadores, redacción de información sensible), y tratar cada pieza de dato que pasa por el pipeline de entrenamiento como algo que necesita validación activa, no confianza por defecto.
OWASP recomienda control de acceso basado en roles (RBAC), autenticación multifactor, y acceso de mínimo privilegio a datasets y pipelines de entrenamiento, para bloquear modificaciones no autorizadas. También recomienda sandboxing estricto para limitar la exposición del modelo a fuentes de datos no verificadas — la misma lógica de aislamiento que ya se aplica en seguridad de infraestructura tradicional.
Una defensa efectiva combina detección de anomalías, optimización robusta, y filtrado de datos consciente de confianza para limitar el impacto de un adversario. El entrenamiento adversarial consiste en entrenar deliberadamente al modelo con ejemplos de datos envenenados, enseñándole a identificarlos y clasificarlos correctamente. La privacidad diferencial agrega ruido matemático al proceso de entrenamiento, limitando cuánto puede influir un solo dato individual en el modelo final — reduciendo el impacto potencial de cualquier punto de dato envenenado aislado.
El red teaming y las pruebas de estrés implican ejecutar ataques simulados sobre sistemas de IA críticos, permitiendo que los equipos de seguridad intenten envenenar el modelo en un entorno controlado — la única forma real de saber si las defensas de arriba funcionan es intentar romperlas vos mismo antes de que alguien más lo haga, de forma recurrente, no como un ejercicio de una sola vez antes del lanzamiento.
Carlos Montiel es arquitecto de soluciones IA empresarial. Implementa LLMs, Agentes, RAG y orquestadores en empresas de Guatemala y Latinoamérica. Contáctalo para una consultoría.
Contactar a Carlos Montiel