¿Qué es el envenenamiento de datos?
Privacidad, seguridad e identidad
El envenenamiento de datos es la manipulación deliberada de los datos de los que aprende un sistema de aprendizaje automático, con el fin de que el modelo se comporte de forma incorrecta más adelante. En ocasiones el efecto es una degradación general. En otras, se trata de un comportamiento oculto y dirigido que solo se manifiesta bajo condiciones específicas. El envenenamiento de datos se encuadra dentro del ámbito más amplio del aprendizaje automático adversarial y es distinto de un jailbreak de IA, que intenta eludir las reglas de un modelo en tiempo de ejecución mediante instrucciones, en lugar de corromper los datos de los que aprendió.
Revisado por Jackie, Head of Learning & Development, Levellers - Última revisión: 8 de junio de 2026
Qué significa esto
Una forma sencilla de entender el envenenamiento de datos es compararlo con la formación de un nuevo empleado mediante manuales manipulados y ejemplos incorrectos. Si el material de formación está alterado de la manera adecuada, el aprendiz puede parecer competente la mayor parte del tiempo, pero fallará exactamente en los puntos que el atacante desea.
Eso es lo que ocurre con los datos de aprendizaje automático envenenados. El atacante modifica algunos de los ejemplos, etiquetas u otras entradas de aprendizaje para que el modelo absorba un patrón distorsionado. El modelo se despliega entonces como si fuera fiable, aunque su comportamiento haya sido moldeado en silencio con antelación.
En ocasiones el efecto es general: el modelo simplemente funciona peor en conjunto. En otras es dirigido: determinadas entradas, frases, clases o condiciones desencadenan el comportamiento incorrecto mientras todo lo demás sigue pareciendo normal. Esta versión dirigida puede ser mucho más difícil de detectar, ya que el rendimiento general puede seguir siendo aceptable.
En los sistemas de IA modernos, "datos" también abarca más de una cosa. Puede incluir corpus de preentrenamiento, conjuntos de datos de ajuste fino, ejemplos etiquetados por personas, datos de clasificación y preferencias, corpus de embeddings y, en algunos contextos, datos de retroalimentación que se reutilizan posteriormente para la mejora. Esta cadena de suministro más amplia es la razón por la que el envenenamiento de datos no es solo una cuestión de ciencia de datos. Es también una cuestión de adquisición, plataforma y gobernanza.
Por qué es importante
El envenenamiento de datos es importante porque el comportamiento del modelo depende de los datos de los que aprendió. Si los datos están comprometidos, el modelo puede estarlo también, aunque el software que lo rodea parezca normal.
Esto es especialmente relevante ahora, porque muchas organizaciones no construyen todo desde cero. Utilizan conjuntos de datos de terceros, repositorios abiertos, etiquetadores externos, modelos preentrenados, centros de modelos compartidos, fuentes de datos suministradas por socios, bucles de retroalimentación y canalizaciones de reentrenamiento automatizado. Cada dependencia puede ser útil, pero también puede ampliar la oportunidad de contaminación.
Para los responsables, el peligro no es solo una menor precisión. Los sistemas envenenados pueden erosionar la confianza de formas más silenciosas. Un modelo antifraude puede pasar por alto los patrones incorrectos. Un modelo de moderación puede desarrollar puntos ciegos. Un modelo de lenguaje ajustado con material corrupto puede producir respuestas sesgadas o manipuladas sobre temas específicos. Una puerta trasera oculta puede permanecer inactiva hasta que aparezca un desencadenante en producción. Esto significa que el envenenamiento de datos puede pasar desapercibido hasta que más importa.
Cómo funciona
El envenenamiento de datos ocurre antes o durante el proceso de aprendizaje, no principalmente en el momento en que el usuario introduce instrucciones. El atacante necesita alguna vía para influir en los datos que el modelo utiliza para aprender. Esa vía puede ser directa o indirecta. Puede implicar alterar un conjunto de datos, corromper etiquetas, introducir muestras elaboradas, publicar material de entrenamiento contaminado que otros ingieran posteriormente, o abusar de un proceso de retroalimentación o actualización.
A grandes rasgos, existen dos efectos comunes. El primero es la degradación indiscriminada: el atacante quiere que el modelo empeore en general, quizás con menor precisión o fiabilidad en muchas entradas. El segundo es la manipulación dirigida: el atacante quiere que el modelo se comporte incorrectamente ante un conjunto reducido de entradas, clases o desencadenantes, mientras permanece mayormente normal en el resto.
La manipulación dirigida suele ser más peligrosa en la práctica porque se oculta mejor. Un modelo puede superar muchas pruebas ordinarias y aun así contener un patrón dañino latente. En el lenguaje clásico de la seguridad, esto puede describirse como una puerta trasera: el modelo se comporta con normalidad hasta que aparece el desencadenante o la condición adecuada.
Las taxonomías actuales también distinguen el envenenamiento de datos del envenenamiento de modelos. El envenenamiento de datos cambia los ejemplos de los que aprende el modelo. El envenenamiento de modelos cambia el artefacto o los parámetros del modelo de forma más directa, lo que es especialmente relevante en entornos como el aprendizaje federado o las cadenas de suministro de modelos comprometidas. En el debate empresarial cotidiano los términos a veces se confunden, pero mantenerlos separados ayuda a los equipos a decidir dónde situar los controles.
La IA generativa amplía aún más el campo. En este contexto, el envenenamiento puede dirigirse a los datos de preentrenamiento, los datos de ajuste de instrucciones, los datos de preferencias, los datos de embeddings u otros artefactos utilizados para moldear el comportamiento del modelo. Las orientaciones de seguridad actuales también señalan que los modelos publicados a través de repositorios compartidos pueden conllevar tanto riesgo de comportamiento como riesgo en la cadena de suministro de software. En otras palabras, el envenenamiento no se limita al texto o las imágenes dentro de un conjunto de datos. También puede formar parte de la cadena más amplia a través de la cual se adquieren modelos y artefactos relacionados.
También conviene distinguir el envenenamiento de datos de cuestiones adyacentes. Una instrucción de usuario que engaña a un asistente desplegado no es envenenamiento de datos. Se trata de un ataque basado en instrucciones en tiempo de ejecución. Una instrucción maliciosa oculta en un documento recuperado se trata habitualmente como inyección de instrucciones indirecta o envenenamiento de la base de conocimiento, a menos que ese contenido se incorpore posteriormente al proceso de entrenamiento o ajuste fino. Una buena gobernanza depende de mantener estas categorías bien diferenciadas.
Desde el punto de vista defensivo, la pregunta importante no es "¿Podría ocurrir esto en teoría?", sino "¿Dónde podría alguien influir en nuestros datos de aprendizaje en la práctica?". Los puntos de palanca habituales incluyen conjuntos de datos externos, etiquetado externalizado, scraping a escala web, retroalimentación de usuarios sin revisar, almacenamiento comprometido, control de acceso débil, reentrenamiento automatizado e importación de modelos desde centros públicos.
El control comienza, por tanto, con la procedencia y la propiedad. Es necesario saber de dónde provienen los datos, quién los etiquetó, quién los modificó, cuándo se modificaron y qué versiones del modelo aprendieron de ellos.
A continuación se necesitan controles de integridad. Versionar los conjuntos de datos. Separar las fuentes de confianza de las que no lo son. Restringir el acceso de escritura. Utilizar aprobaciones para los cambios importantes en los datos. Conservar los artefactos necesarios para la reversión y la investigación.
La validación también es importante. Los conjuntos de datos de reserva, las pruebas canario, las comprobaciones de anomalías y la evaluación en casos extremos específicos pueden ayudar a detectar cambios sospechosos que los promedios generales de referencia pueden ocultar. Los conjuntos de modelos y la comparación con fuentes de confianza también pueden dificultar que el envenenamiento pase desapercibido.
La disciplina en la cadena de suministro es esencial. Si se importan modelos, conjuntos de datos o herramientas, conviene verificar su origen y su nivel de confianza. Las orientaciones modernas tratan cada vez más la cadena de suministro de aprendizaje automático de forma similar a la cadena de suministro de software, lo que significa que la procedencia, la transparencia y la revisión de dependencias forman parte de las operaciones responsables.
Por último, conviene monitorizar tras el despliegue. El envenenamiento de datos suele descubrirse tarde, cuando un modelo empieza a comportarse de forma extraña con el tráfico real. La monitorización posterior al despliegue en busca de deriva, patrones de fallo concretos y cambios de rendimiento inexplicables ayuda a los equipos a detectar problemas antes, aunque no lo detectará todo.
La mecánica es sencilla de describir aunque difícil de gestionar. El atacante influye en el material de aprendizaje. El modelo interioriza la distorsión. El comportamiento dañino aparece más tarde, ya sea de forma general o bajo condiciones específicas. La defensa práctica consiste en tratar los datos de entrenamiento y ajuste como activos críticos para la seguridad, no como simple materia prima para la experimentación.
Ejemplos
Un filtro de spam se entrena con datos de correo electrónico que incluyen etiquetas manipuladas. El modelo aprende los patrones incorrectos y deja pasar mensajes que debería haber bloqueado. Este es un caso clásico en el que unos datos de aprendizaje deficientes generan un comportamiento operativo deficiente más adelante.
Un modelo de atención al cliente se ajusta con tickets históricos. Si esos tickets contienen ejemplos sistemáticamente corruptos, o si el proceso de curación está manipulado, el modelo puede desarrollar puntos ciegos concretos pero graves en torno a problemas específicos.
Un equipo de modelos importa un modelo base o un conjunto de datos de terceros desde un repositorio público sin realizar comprobaciones de procedencia suficientes. El atractivo inmediato es la velocidad. El coste oculto es la incertidumbre sobre lo que el modelo ha aprendido y si se han introducido comportamientos ocultos en fases anteriores.
Un equipo utiliza bucles de retroalimentación en tiempo real para la mejora continua. Si esa retroalimentación no se filtra ni se gobierna, las señales maliciosas o de baja calidad pueden empezar a moldear el comportamiento futuro de formas que nadie pretendía.
Malentendidos frecuentes
Un malentendido habitual es que el envenenamiento siempre arruina el rendimiento del modelo de forma tan evidente que cualquiera lo detectará. No necesariamente. Algunos envenenamientos buscan efectos sutiles y dirigidos que dejan muchas métricas estándar en niveles aparentemente aceptables.
Otro es que el envenenamiento requiere controlar una gran parte de los datos. En ocasiones no es así. En las condiciones adecuadas, cambios cuidadosamente situados pueden tener efectos desproporcionados.
Un tercero es que el envenenamiento de datos y el envenenamiento de modelos son lo mismo. Están relacionados, pero son distintos. El envenenamiento de datos cambia las entradas de aprendizaje. El envenenamiento de modelos cambia el modelo de forma más directa.
Un cuarto es que esto solo es un problema para los grandes modelos fundacionales. También afecta a modelos internos más pequeños, modelos de tareas ajustados y cualquier flujo de trabajo que reentrene a partir de datos que la organización no gobierna con rigor.
Riesgos y límites
El envenenamiento de datos es difícil de detectar con certeza, especialmente cuando el efecto es concreto y el sistema es grande. Algunas organizaciones nunca tendrán visibilidad completa sobre todas las fuentes de preentrenamiento previas utilizadas por un proveedor. Esto limita las garantías y aumenta el valor de la diligencia debida con los proveedores, el despliegue controlado y la monitorización posterior al despliegue.
También existen compromisos. Una recopilación de datos más amplia puede mejorar la cobertura, pero también ampliar la exposición. Un reentrenamiento rápido puede mejorar la actualidad, pero puede importar señales deficientes con mayor rapidez. El intercambio abierto puede acelerar la adopción, pero reduce las garantías a menos que la procedencia y la validación sean sólidas.
Este artículo es una guía práctica, no asesoramiento legal ni profesional. Si un comportamiento envenenado pudiera afectar a decisiones reguladas, actividades críticas para la seguridad o datos personales sensibles, es recomendable realizar una revisión formal de seguridad, legal y de riesgos.
Qué hacer a continuación
En primer lugar, mapear la cadena de suministro de datos para cada modelo relevante. Incluir fuentes, etiquetadores, repositorios, almacenes de artefactos, desencadenantes de reentrenamiento y quién puede aprobar cambios.
En segundo lugar, asignar responsabilidad. Alguien debe ser responsable de la integridad de los datos de entrenamiento, ajuste, embeddings y evaluación, no solo del rendimiento del modelo.
En tercer lugar, aplicar controles de procedencia y versiones. Los conjuntos de datos importantes deben ser trazables, reproducibles y reversibles. Si un modelo cambia, debe saberse exactamente qué entradas de aprendizaje cambiaron.
En cuarto lugar, separar los niveles de confianza. Mantener los datos internos de alta confianza separados de los datos externos de baja confianza, y no permitir que la retroalimentación no revisada entre automáticamente en los bucles de mejora para casos de uso de alto riesgo.
En quinto lugar, reforzar las comprobaciones a los proveedores. Preguntar a los proveedores sobre la procedencia de los conjuntos de datos, los controles de etiquetado, las prácticas en centros de modelos, la gobernanza del reentrenamiento y cómo detectan o investigan la contaminación.
En sexto lugar, desarrollar evaluaciones dirigidas. No depender únicamente de puntuaciones agregadas. Utilizar casos canario, casos extremos y pruebas específicas de patrones que puedan revelar manipulaciones ocultas.
Por último, preparar la reversión y la respuesta a incidentes. Si aparece un comportamiento sospechoso, los equipos deben poder pausar las actualizaciones, comparar versiones, inspeccionar la ruta de datos modificada y revertir de forma segura.
¿Tiene alguna pregunta o sugerencia, o desea saber cómo investigamos y revisamos estas guías? Lea sobre nuestros estándares editoriales y cómo contactarnos.
Preguntas frecuentes
¿Es el envenenamiento de datos lo mismo que un jailbreak de IA?
No. Un jailbreak es un intento en tiempo de ejecución de eludir las restricciones de un modelo desplegado mediante instrucciones. El envenenamiento de datos cambia lo que el modelo aprende antes de que sea desplegado o actualizado.
¿El envenenamiento siempre hace que el modelo empeore de forma evidente?
No. Algunos envenenamientos causan una degradación general, pero otros son dirigidos y están diseñados para permanecer ocultos hasta que aparezca un desencadenante o una condición específica.
¿Es esto solo un problema del conjunto de datos de entrenamiento?
No. Puede afectar al preentrenamiento, al ajuste fino, a los datos de preferencias, a los embeddings, a los bucles de retroalimentación y a otros artefactos de aprendizaje que moldean el comportamiento del modelo.
¿Cuál es la diferencia entre el envenenamiento de datos y el envenenamiento de modelos?
El envenenamiento de datos altera las entradas de aprendizaje, como muestras o etiquetas. El envenenamiento de modelos altera el modelo de forma más directa, por ejemplo cambiando parámetros o actualizaciones en determinados entornos de entrenamiento.
¿Puede ayudar la monitorización posterior al despliegue?
Sí, pero no es suficiente por sí sola. La monitorización puede revelar deriva o comportamientos sospechosos, pero prevenir la contaminación mediante procedencia, control de acceso y validación es más eficaz.
¿Qué deberían preguntar los responsables a los proveedores?
Conviene preguntar sobre la procedencia de los datos, la gobernanza del etiquetado, los controles de reentrenamiento, las comprobaciones de la cadena de suministro de modelos, la detección de anomalías, los procesos de reversión y qué evidencias puede aportar el proveedor si se sospecha contaminación.
Fuentes
Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations (National Institute of Standards and Technology). Primary. Definitions of data poisoning, distinction from model poisoning, generative AI relevance, and the role of targeted and backdoor poisoning.
Understanding adversarial attacks against Machine Learning and AI (National Cyber Security Centre). Primary. Supports the plain English definition of training data poisoning and the distinction from malicious model training and other AML classes.
ML02:2023 Data Poisoning Attack (OWASP Foundation). Primary. Practical prevention guidance covering validation, secure storage, access control, monitoring and model validation.
LLM04:2025 Data and Model Poisoning (OWASP Gen AI Security Project). Primary. Supports generative AI specific poisoning discussion across pre training, fine tuning and embedding data.
Secure your supply chain (National Cyber Security Centre). Primary. Supports the point that data and labels determine model behaviour, that third party datasets widen risk, and that targeted backdoors can be introduced through poisoned data.
Poisoning Attacks Against Machine Learning (National Institute of Standards and Technology). Secondary. Corroborates the distinction between data poisoning and model poisoning and the broader consequences of poisoned learning material.