Manipulación de datos: cómo los atacantes corrompen los datos de entrenamiento y recuperación de la IA

El «envenenamiento de datos» consiste en la corrupción deliberada de los datos a partir de los cuales aprende o que recupera un modelo de inteligencia artificial o de aprendizaje automático, con el fin de que el modelo se comporte según los deseos del atacante. Se dirige a los corpus de preentrenamiento, los datos de ajuste fino y de preferencias, los índices de recuperación y el contexto de las herramientas de los agentes, y constituye un ataque a la integridad más que un robo de datos.

La amenaza ya no es teórica. En mayo de 2026, unos investigadores encontraron un « malware » en un repositorio de modelos de Hugging Face que ocupaba el primer puesto en las tendencias, y un estudio de *Nature Medicine* de 2025 demostró que sustituir el 0,001 % de los tokens de entrenamiento por desinformación médica daba lugar a modelos más propensos a propagar errores médicos. Esta página define el ataque, desglosa sus cuatro etapas del ciclo de vida, asocia cada técnica de MITRE ATLAS denominada «poison» a sus medidas de mitigación y explica claramente qué mitad del problema puede detectar un equipo de seguridad.

¿Qué es la manipulación de datos?

Dos ejemplos concretos marcan los límites. En mayo de 2026, investigadores de HiddenLayer documentaron un repositorio de Hugging Face que alcanzó el primer puesto en las tendencias al incluir un cargador que ejecutaba un programa de robo de información. Eso es «envenenamiento de artefactos»: el objeto envenenado es un paquete de modelo publicado, en lugar de un conjunto de entrenamiento. En cuanto a los datos de entrenamiento, un estudio de *Nature Medicine* de 2025, con experimentos realizados en 2024, simuló un ataque contra *The Pile*, un corpus abierto de preentrenamiento, y señaló que «la sustitución de tan solo el 0,001 % de los tokens de entrenamiento por desinformación médica da lugar a modelos perjudiciales que son más propensos a propagar errores médicos».

¿Es el envenenamiento de datos un ataque adversarial? Sí. El informe NIST AI 100-2e2025, sobre aprendizaje automático adversarial elaborado por la agencia, clasifica el envenenamiento como una categoría de ataque independiente, junto con los ataques de evasión en el momento de la inferencia y los ataques a la privacidad. El envenenamiento es el miembro de esa familia relacionado con la integridad: cambia lo que un modelo aprende o recupera, en lugar de robar lo que sabe. La inversión de modelos, a veces clasificada erróneamente como un tipo de envenenamiento, es un ataque a la privacidad. La entrada actual LLM05:2026 de OWASP define esta misma clase de forma amplia: «El envenenamiento de datos y modelos describe una clase de ataques y fallos en los que un adversario (o un proceso inseguro) manipula datos o artefactos del modelo».

Manipulación de datos frente a uso indebido de datos

El uso indebido de datos consiste en el uso no autorizado de datos que ya obran en poder de una organización: por ejemplo, un empleado que consulta los registros de clientes por motivos personales está cometiendo un uso indebido. El envenenamiento de datos consiste en la corrupción deliberada de los datos a partir de los cuales un modelo aprende o que este recupera: por ejemplo, un atacante que inserta muestras mal etiquetadas en un conjunto de entrenamiento está envenenando los datos. El verdadero punto en común es la condición previa, ya que ambos suelen comenzar con alguien que dispone de un acceso de lectura o escritura que no debería tener.

La manipulación de datos frente a prompt injection

Prompt injection manipula los datos de entrada de un modelo en tiempo de ejecución, aplicándolos a un modelo que ya ha sido entrenado, y su efecto suele desaparecer al finalizar la sesión. El envenenamiento de datos altera lo que el modelo ha aprendido o lo que recupera, por lo que la corrupción persiste en todos los usuarios y sesiones hasta que se limpian los datos o se vuelve a entrenar el modelo.

Envenenamiento de datos frente a envenenamiento de modelos

En el aprendizaje federado, el «envenenamiento de modelos» se refiere a que un atacante envía actualizaciones maliciosas del modelo, no datos maliciosos, y confundir ambos conceptos constituye un error de hecho, más que una simple preferencia terminológica. El documento de OWASP Machine Learning Las 10 principales medidas de seguridad (borrador v0.3, edición de 2023) los mantiene separados precisamente por este motivo, enumerando ML02:2023 Ataque de envenenamiento de datos y ML10:2023 Envenenamiento de modelos como riesgos independientes.

La manipulación de datos frente a la manipulación del SEO

El «envenenamiento SEO» manipula los resultados de búsqueda para mostrar malware, mientras que el «envenenamiento de datos» corrompe los datos de entrenamiento o de referencia de la IA: se trata de un término común, pero con un tipo de ataque diferente, una superficie de ataque diferente y una defensa diferente.

Cuando el envenenamiento es una medida defensiva

La misma mecánica funciona a la inversa como medida de protección. Nightshade, desarrollado a partir de datos de 2023, demostró que bastaban menos de 100 muestras «envenenadas» para controlar una instrucción de Stable Diffusion SDXL, por lo que los artistas pueden alterar sus propias obras para evitar que sean extraídas (arXiv:2310.13828). Un preprint de 2024, actualizado en 2025, reveló que las herramientas populares de perturbación protectora «solo proporcionan una falsa sensación de seguridad» y que el aumento de resolución de imágenes disponible en el mercado las degrada (arXiv:2406.12027). Ese resultado se centra en la perturbación protectora contra la imitación de estilos, un mecanismo diferente del envenenamiento ofensivo de Nightshade, y no refuta los hallazgos de Nightshade.

Tipos de ataques de contaminación de datos

Los tipos de «envenenamiento» se diferencian en lo que el atacante modifica, etiqueta, toma como muestra o activa, y en si el objetivo es un deterioro generalizado o un comportamiento oculto.

• Inversión de etiquetas. El atacante modifica las etiquetas de muestras que, por lo demás, son legítimas, lo que hace que el modelo considere que lo malicioso es benigno o viceversa.
• Inyección de datos. El atacante introduce nuevas muestras, creadas por él mismo, en un corpus a partir del cual el modelo va a aprender.
• Envenenamiento de «etiqueta limpia». Altera las muestras sin modificar sus etiquetas, lo que burla los controles de coherencia de las etiquetas. Se trata de una subcategoría específica definida en la norma NIST AI 100-2e2025.
• Ataques de puerta trasera o de activación. Instalar un comportamiento oculto que solo se active ante un patrón de entrada específico, mientras que, en el resto de casos, el modelo se comporte con normalidad.
• Ataques contra la disponibilidad o de degradación. El objetivo es empeorar el modelo en general, en lugar de provocar errores selectivos.
• Envenenamiento selectivo frente a envenenamiento no selectivo. Una distinción transversal: los ataques selectivos alteran resultados concretos, mientras que los ataques no selectivos merman el rendimiento general.
• «Envenenamiento de vista dividida». Consiste en adquirir un dominio caducado al que todavía hace referencia el índice de un conjunto de datos, de modo que, en un rastreo posterior, se recupere el contenido del atacante. Se menciona en la guía conjunta sobre seguridad de los datos de IA de las agencias aliadas, del 22 de mayo de 2025.
• Envenenamiento por «frontrunning». La inyección de contenido malicioso justo antes de que se realicen las capturas de pantalla de las fuentes colaborativas para su recopilación, tal y como también se menciona en esa guía de 2025.
• Ataques a subpoblaciones. Deterioran el rendimiento de un segmento concreto de la distribución de datos, mientras que las métricas globales permanecen intactas.
• Envenenamiento por goteo lento o «la rana que hierve». Las pequeñas irregularidades se van extendiendo con el tiempo, de modo que ningún cambio concreto da lugar a una revisión.
• Intoxicación por artefactos. Publicar conjuntos de datos, modelos o herramientas de agentes «envenenados» en repositorios públicos, registrados en MITRE ATLAS como AML.0115 y analizados por el Cloud Alianza de Seguridad como superficie de ataque del repositorio. Esta variante se solapa con ataques a la cadena de suministro de software, y, más allá del caso específico de la IA, pertenece a esa página.

Dónde se produce la «contaminación»: el ciclo de vida de los datos de IA en cuatro etapas

El envenenamiento suele presentarse como un problema propio de la fase de entrenamiento, pero ese enfoque se queda ahora corto en dos etapas. Los datos de los que depende un sistema de IA pasan por cuatro etapas distintas, y cada una de ellas puede verse contaminada: el corpus de preentrenamiento, los datos de ajuste fino y de preferencias, el índice de recuperación que lee un sistema implementado en el momento de la consulta, y las definiciones de herramientas, los resultados y la memoria que alimentan a los agentes de IA. Las dos primeras son superficies de la fase de desarrollo. Las dos últimas son superficies de la fase de ejecución, y son las que un equipo de seguridad puede supervisar realmente.

Etapa Lo que modifica el atacante Quién tiene el control Tipo de control Preentrenamiento El corpus base Ingeniería de datos y el proveedor del modelo Fase de compilación: procedencia, saneamiento, firma del conjunto de datos Ajuste fino y datos de preferencias Corpus de tareas y pares de preferencias Ingeniería de aprendizaje automático y MLOps Fase de compilación: linaje del conjunto de datos, revisión, control de acceso RAG y recuperación El índice de recuperación en tiempo real o el almacén de documentos Equipos de aplicaciones y plataformas, junto con seguridad Tiempo de ejecución: supervisión del acceso de escritura, detección de cambios en el corpus, medidas de protección Herramientas de agentes y contexto Definiciones de herramientas, salida de herramientas, memoria de los agentes Plataforma y seguridad Tiempo de ejecución: refuerzo de la memoria, listas de herramientas permitidas, medidas de protección

Tabla: Las cuatro fases del ciclo de vida de los datos de IA, qué modifica un atacante en cada una de ellas y quién tiene el control.

‍

La generación reforzada por recuperación (RAG) basa las respuestas de un modelo en un repositorio de documentos que cambia a diario, lo que convierte el envenenamiento en un ataque en tiempo de ejecución con su propia técnica de MITRE ATLAS, AML.0070 Intoxicación de RAG. El resultado de referencia es «PoisonedRAG», publicado en USENIX Security 2025 a partir de experimentos realizados entre 2024 y 2025, en el que se informó de «una tasa de éxito de los ataques del 90 % al inyectar cinco textos maliciosos por cada pregunta objetivo» en una base de datos de conocimiento con millones de textos, y se concluyó que las defensas evaluadas eran insuficientes (arXiv:2402.07867).

El ajuste fino presenta una novedad: los datos de preferencias. Las técnicas de alineación, como la optimización directa de preferencias (DPO), aprenden a partir de pares de respuestas clasificadas como mejores o peores, por lo que los pares de preferencias erróneos distorsionan la propia señal de preferencias, influyendo en lo que un modelo ajustado considera una buena respuesta. La etapa hereda los mismos controles de compilación que cualquier corpus de ajuste fino: linaje, revisión y control de acceso.

La novedad más reciente es el contexto del agente. Protección de los agentes de IA es una disciplina en sí misma, pero lo específico del envenenamiento es que cualquier cosa que lea un agente puede contener contenido del atacante. Una técnica revelada en DEF CON 34 En agosto de 2026, el atacante inserta texto en los campos de registro que un agente de clasificación basado en IA lee posteriormente y sobre el que actúa (SecurityWeek, 10 de agosto de 2026); la tasa de éxito declarada por los propios investigadores frente a un agente codificador fue del 90 % (Tenet Security). Ninguna de las dos revelaciones menciona un marco concreto, pero la técnica se ajusta perfectamente a AML.0080 Contaminación del contexto de los agentes de IA. En todo seguridad de la IA generativa, cada fase se reduce a las mismas dos preguntas: quién puede escribir en los datos y quién supervisa las operaciones de escritura.

Cómo consigue un atacante acceso de escritura

Todas las variantes de envenenamiento comparten un requisito previo: antes de que alguien pueda envenenar un conjunto de entrenamiento interno, un corpus de ajuste fino, un índice de recuperación o un registro de modelos, alguien ya ha obtenido acceso de escritura a él. Eso implica credenciales comprometidas, cuentas de servicio con permisos excesivos, abuso de los derechos de cloud o un usuario interno. En términos de MITRE ATLAS, el acto de envenenamiento se produce después de AML.0004 Acceso inicial, AML.0013 Acceso mediante credenciales, AML.0008 Descubrimiento, AML.0015 Movimiento lateral, y AML.0009 Recopilación. No se transmite ninguna información sobre el veneno en sí, pero todo lo relacionado con la intrusión que lo introduce se transmite mediante telemetría que un SOC ya recopila: detección de amenazas a la identidad para la fase de acreditación, cloud detección y respuesta para la fase de concesión de derechos.

‍

MITRE ATLAS documenta el alcance del acceso de escritura que ya está expuesto. Caso práctico AML.CS0028, registrado como un ejercicio y no como un incidente real, con fecha del 26 de septiembre de 2023, señala que «más de 8.000 registros privados de contenedores mal configurados estaban expuestos en Internet», de los cuales aproximadamente el 70 % permitía el acceso de escritura y en los que se podía acceder a más de 1.000 modelos de IA únicos (Repositorio de datos MITRE ATLAS). Un registro en el que se permite la escritura es una superficie de ataque: cualquiera que pueda realizar entradas en él puede sustituir un modelo.

El incidente de seguridad de Hugging Face de julio de 2026 muestra la versión entrante del mismo problema. El comunicado de la empresa indica que «un conjunto de datos malicioso se aprovechó de dos vías de ejecución de código en nuestro procesamiento de conjuntos de datos» para ejecutar código en un nodo de procesamiento (comunicado de Hugging Face, 16 de julio de 2026; cronología técnica). Se trata de una ejecución de código procedente de un artefacto del conjunto de datos, más que de un envenenamiento de los datos de entrenamiento, y es el argumento más claro de que la ingesta de conjuntos de datos constituye un límite de ejecución: la plataforma cerró ambas vías de código como respuesta. Un preprint coordinado sobre el envenenamiento de la recuperación, publicado el 17 de agosto de 2026 (arXiv:2608.16044), parte de la misma premisa: cualquiera que pueda añadir documentos a un almacén compartido puede intentar manipular sus respuestas.

Considera la ruta de acceso de escritura como la superficie de detección. El uso no autorizado de la IA la amplía al crear almacenes de datos que nadie ha registrado, y los mismos fallos de acceso que dan lugar a una filtración de datos provocan, en un proceso de IA, la generación de un artefacto contaminado.

La manipulación de datos en MITRE ATLAS: técnicas y medidas de mitigación

MITRE ATLAS es el equivalente de IA adversaria de ATT&CK, y es allí donde un hallazgo de envenenamiento se convierte en un modelo de amenaza. Esta tabla de correspondencias se basa en ATLAS v2026.07 (archivo de datos con fecha del 31 de julio de 2026; versión de GitHub publicada el 7 de agosto: dos fechas para una misma versión, lo cual no supone una contradicción). La versión incluye una matriz, 16 tácticas, 101 técnicas, 77 subtécnicas, 37 medidas de mitigación y 68 casos prácticos (registro de la versión). ATLAS se publica aproximadamente una vez al mes: la v2026.05 salió el 27 de mayo, la v2026.06 el 30 de junio y la v2026.07 tiene fecha de datos del 31 de julio, por lo que conviene verificar la versión actual antes de citar las cifras.

Ocho técnicas con nombres relacionados con el veneno abarcan la matriz, y la versión v2026.07 asigna a cada una de ellas un valor de madurez: «Realizado», «Demostrado» o «Factible», lo que sirve como ayuda integrada para establecer prioridades.

Tabla: Los 11 objetos relacionados con el «poison» en MITRE ATLAS v2026.07: ocho técnicas distintas denominadas «poison», además de las tres subtécnicas de AML.0115.

Los identificadores de las técnicas se han modificado recientemente, por lo que las referencias publicadas antes de agosto de 2026 pueden incluir identificadores ya retirados. El 31 de julio de 2026, ATLAS consolidó tres técnicas retiradas, AML.0019 Publicar conjuntos de datos viciados, AML.0058 Publicar modelos «envenenados», y AML.0104 Publicar la herramienta «Poisoned AI Agent» en AML.0115 Publicar artefactos de IA envenenados, con subtécnicas para conjuntos de datos, modelos y herramientas de agentes de IA. La técnica principal actual para la corrupción clásica de conjuntos de entrenamiento es AML.0020 Envenenamiento de datos de entrenamiento, en AML.0006 Perseverancia.

Lo que la mayoría de las explicaciones no llegan a abordar es la correspondencia con las técnicas de mitigación. ATLAS enumera 37 medidas de mitigación, y seis de las ocho técnicas denominadas «poison» cuentan con al menos un control asociado (repositorio de datos de MITRE ATLAS):

Tabla: Correspondencia entre técnicas y medidas de mitigación de ATLAS para el envenenamiento en la versión 2026.07, en la que las dos técnicas relacionadas con herramientas de agente no tienen medidas de mitigación asignadas.

Hay dos filas vacías, y eso es más una constatación que una crítica: a partir de la versión v2026.07, ATLAS no asigna medidas de mitigación a AML.0110 Envenenamiento de herramientas de agentes de IA o AML.0011.002 Herramienta de agente de IA maliciosa. La cobertura de control del marco aún no se ha adaptado a sus técnicas más recientes en materia de herramientas de agente. La visión a nivel de técnica que se presenta más arriba es también más específica que la que publican los organismos de normalización, ya que el propio apéndice de correspondencias del marco de OWASP de 2026 vincula este riesgo con ATLAS únicamente a nivel táctico, sin identificar ninguna técnica (Apéndice A).

Utiliza las dos tablas como sistema de archivo: un hallazgo de envenenamiento se archiva bajo uno de los ocho identificadores de técnica, una medida de control propuesta se asigna a la columna de mitigación, y la pregunta de cobertura de un auditor se convierte en un análisis de deficiencias fila por fila. Esta página se limita deliberadamente a la tabla de correspondencias de envenenamiento; el marco ATLAS en sí, incluida su estructura táctica completa, se trata en una página aparte.

Lo que realmente revelan los estudios y los incidentes

Los resultados obtenidos giran en torno a un tema: los tamaños del efecto son fracciones minúsculas de un corpus, y cada cifra lleva asociado un matiz de alcance que modifica lo que demuestra. La línea temporal que figura a continuación indica por separado el año de publicación y el periodo de datos, ya que ambos suelen diferir en varios años.

Tabla: Investigaciones e incidentes de intoxicación contrastados, ordenados de más antiguos a más recientes, con el año de publicación y el periodo de datos indicados por separado en cada fila.

Del estudio publicado en *Nature Medicine* en 2025, basado en experimentos realizados en 2024, se han difundido tres cifras; se trata de tres experimentos distintos, no de una contradicción. Con una tasa de envenenamiento del 0,01 %, los modelos de 1.300 millones de parámetros generaron un 11,2 % más de completaciones perjudiciales que la línea de base (P = 0,00047), y con una tasa del 0,001 %, el aumento fue del 7,2 % (P = 0,01463). La tercera cifra procede de modelos más grandes: en comparación con modelos de 4 000 millones de parámetros, el ataque de desinformación sobre vacunas de un solo concepto, con la misma tasa del 0,001 %, produjo un aumento del 4,8 % (P = 0,03836) (texto completo). En los tres casos se trata de aumentos en las completaciones perjudiciales respecto a la línea de base, no de tasas de error absolutas, y describirlas como tasas de respuestas incorrectas supone una interpretación errónea de la métrica. Este mismo estudio sirve de referencia para la sección de detección que figura a continuación, ya que sus modelos contaminados obtuvieron resultados equivalentes a los modelos limpios en las pruebas de referencia estándar.

El hallazgo del preprint de 2025, según el cual «250 documentos envenenados comprometen de manera similar los modelos, independientemente del tamaño de estos y de los conjuntos de datos», es un resultado de recuento constante en todas las ejecuciones de preentrenamiento, desde 600 millones hasta 13 000 millones de parámetros (arXiv:2510.07192). La advertencia de sus autores debe tenerse en cuenta junto con la cifra: «Nuestro estudio se centra en una puerta trasera limitada (que genera texto sin sentido) que probablemente no plantee riesgos significativos en los modelos de vanguardia» (Anthropic). A fecha de 20 de agosto de 2026, el preprint seguía sin revisarse, sin haber sido publicado en una revista con revisión por pares y sin que se hubiera localizado ninguna réplica.

El incidente más destacado de 2026 fue un caso de «envenenamiento de artefactos» más que de «envenenamiento de datos de entrenamiento», y se desencadenó como un sencillo malware. HiddenLayer informó de que un repositorio alcanzó «el primer puesto en las tendencias de Hugging Face, con aproximadamente 244 000 descargas y 667 «me gusta» en menos de 18 horas» y, en otra parte del mismo informe, «más de 200 000 descargas hasta su retirada»; su cargador descargaba PowerShell y ejecutaba un programa de robo de información basado en Rust de 1,07 MB dirigido a las credenciales del navegador, los monederos y Discord en Windows (HiddenLayer, 7 de mayo de 2026). Los datos a escala de repositorios apuntan en la misma dirección: en un informe del 20 de mayo de 2026 que abarca datos de 2025, JFrog contabilizó 969 habilidades de agentes de IA maliciosos que transportaban cargas útiles de gran impacto, junto con 495 modelos de IA maliciosos en Hugging Face y 56 extensiones maliciosas en OpenVSX (comunicado de JFrog).

Lo que nadie mide es la incidencia. Una revisión realizada para esta página no encontró ninguna cifra sobre la incidencia del «envenenamiento de datos» en el informe «Global Cybersecurity Outlook 2026» del Foro Económico Mundial (WEF) y Accenture —donde la palabra «poison» no aparece en ninguna de las 64 páginas del informe—, en la encuesta sobre IA de SANS para 2026, en el Índice de IA 2026 de Stanford HAI, ni en los estudios publicados por Gartner, Forrester e IDC. Ese vacío es la razón por la que circulan en su lugar cifras de proveedores sin fecha. En cuanto a la respuesta ante la intrusión en la plataforma de julio de 2026, consulta nuestro análisis sobre el compromiso del agente de Hugging Face.

Detección y prevención de la manipulación maliciosa de datos

Empecemos por las dos respuestas sinceras. ¿Se puede detectar el envenenamiento tras el entrenamiento? Solo de forma poco fiable: existen técnicas «offline», pero la paridad en las pruebas de referencia no demuestra nada, ya que los modelos envenenados del estudio de *Nature Medicine* obtuvieron los mismos resultados que los modelos limpios en las pruebas de referencia estándar. ¿Se puede eliminar mediante un nuevo entrenamiento? No de forma fiable: el comportamiento de puerta trasera ha persistido a través del ajuste fino supervisado, el aprendizaje por refuerzo y el entrenamiento adversarial, y este último ha enseñado a los modelos a reconocer mejor sus desencadenantes, ocultando así eficazmente el comportamiento (arXiv:2401.05566, 2024). Una valoración de los profesionales de 2021, según la cual «aún faltan años para que haya soluciones prácticas para el desaprendizaje de las máquinas», sigue siendo la postura vigente; la solución viable sigue siendo un costoso reentrenamiento con datos limpios y verificados (CSO Online, 2021).

Lo que sí funcionó en ese estudio fue el filtrado de la capa de salida: «Mediante el uso de grafos de conocimiento biomédico para filtrar los resultados de los modelos de lenguaje grandes (LLM) médicos, proponemos una estrategia de mitigación de daños que detecta el 91,9 % del contenido perjudicial», con una puntuación F1 del 85,7 % (publicación de 2025, datos de 2024) (registro de Mount Sinai).

La división permanente es entre «offline» y «runtime», cada una con un propietario designado.

Tabla: Detección de envenenamiento fuera de línea y en tiempo de ejecución, desglosada por técnica, medida de mitigación de ATLAS asociada y equipo responsable.

Gestión del estado de seguridad de la IA se encarga de la capa de inventario y configuración en tiempo de compilación, Detección de amenazas mediante IA la capa de comportamiento en tiempo de ejecución, y simulacros de ataque a los sistemas de IA pone en práctica AML.M0035 Equipo Rojo de IA.

Los formatos de archivo de modelos son el punto de encuentro entre el envenenamiento y la ejecución clásica de código. Mitigación de ATLAS AML.M0016 El informe «Vulnerability Scanning» lo afirma sin rodeos: «Los formatos de archivo como los archivos pickle, que se utilizan habitualmente para almacenar modelos de IA, pueden contener vulnerabilidades que permiten la ejecución de código arbitrario» (Repositorio de datos MITRE ATLAS). Un detalle sobre las unidades monetarias: desde la versión 2.6.0 de PyTorch, del 29 de enero de 2025, torch.load por defecto es weights_only=True, un cambio que las notas de la versión califican de «una importante medida de mejora de la seguridad» (Notas de la versión 2.6.0 de PyTorch). Safetensors, auditado por terceros en 2023, sigue siendo la opción más segura para la serialización, y Hugging Face explica qué escaneo de encurtidos puede y no puede atrapar.

La propia capa de análisis es un software imperfecto: una búsqueda por palabra clave en la NVD el 20 de agosto de 2026 arroja 59 CVE para «picklescan», el escáner de código abierto de archivos de modelos maliciosos, y los investigadores han publicado tres vulnerabilidades de « zero-day » en ella. La corrupción del corpus de entrenamiento, por el contrario, casi no tiene representación en la base de datos CVE, ya que no se trata de una vulnerabilidad en una versión de software ya lanzada al mercado; la NVD indexa la cadena de suministro del aprendizaje automático como un problema de deserialización y seguridad de la memoria, y una consulta en la base de datos CPE sobre un marco de trabajo importante no arroja ningún resultado, mientras que una búsqueda por palabra clave devuelve 70 resultados, por lo que los escáneres basados en CPE subestiman esta capa. El extremo de la pila que se ve afectado por los ataques es objeto de seguimiento por parte de los reguladores. A fecha de 25 de agosto de 2026, la CISA Catálogo de vulnerabilidades conocidas que han sido explotadas (versión del catálogo 24/08/2026, 1.675 entradas) contenía 10 entradas de ML-stack, entre las que se incluía la de MLflow CVE-2026-64849 (falsificación de solicitudes del lado del servidor, añadido el 19 de agosto de 2026, con plazo de corrección el 2 de septiembre) y el de Ray CVE-2025-62593 (inyección de código, añadida el 17 de agosto, con fecha límite el 20 de agosto), recibió una puntuación de 9,4 (crítica) según su CNA en CVSS v4.0 y de 8,8 (alta) según el NVD en CVSS v3.1.

En lo que respecta a los sistemas de recuperación, dos resultados independientes coinciden en que el filtrado por hora de ingestión no es la solución. PoisonedRAG consideró insuficientes las defensas que evaluó, y un preprint del 17 de agosto de 2026 (arXiv:2608.16044) informó de que su clasificador más potente, tras haber sido entrenado, no distinguía el envenenamiento coordinado del tráfico limpio mejor que por casualidad, detectando solo el 4,2 % de los ataques con una tasa de falsos positivos del 1 %, mientras que un detector en el momento de la recuperación que observaba la demanda detectaba el 100 % con la misma tasa. La defensa basada en la recuperación se sitúa en la columna del tiempo de ejecución.

La manipulación de datos en las normas y la normativa

El identificador actual de OWASP es LLM05:2026 Envenenamiento de datos y modelos, publicado el 4 de agosto de 2026 según el proyecto repositorio de código fuente canónico, y el texto de 2026 amplía el alcance: «En los entornos modernos de IA generativa, el envenenamiento no se limita a los “datos de entrenamiento” en el sentido tradicional» (LLM05:2026 fuente). El número de orden ha variado en cada edición: el de la temporada 2023/24 LLM03: Manipulación de los datos de entrenamiento se retiró, y en la lista de 2025 se le cambió el nombre y se le asignó un nuevo número LLM04:2025 Manipulación de datos y modelos, y en 2026 se trasladó a 05:2026, con «Excessive Agency» y « Supply Chain » ocupando 03:2026 y 04:2026 (cobertura de la publicación).

La Ley de IA de la UE menciona este tipo de ataque en la legislación primaria, y solo una vez: la expresión «envenenamiento de datos» aparece una única vez en el texto consolidado de la Ley, en el artículo 15, apartado 5. Dicha disposición exige, para los sistemas de IA de alto riesgo, medidas técnicas «para prevenir, detectar, responder, resolver y controlar los ataques que intenten manipular el conjunto de datos de entrenamiento (envenenamiento de datos)», y la misma cláusula se extiende al envenenamiento de modelos de componentes preentrenados (texto consolidado de EUR-Lex). La obligación no se limita únicamente a la prevención, ya que la detección y la respuesta se mencionan como obligaciones. En cuanto a los plazos: tras la modificación del artículo 113, los requisitos del capítulo III, que incluyen el artículo 15, se aplicarán a partir del 2 de diciembre de 2027 a los sistemas de alto riesgo contemplados en el artículo 6, apartado 2, y en el anexo III, y a partir del 2 de agosto de 2028 a los contemplados en el artículo 6, apartado 1, y en el anexo I. El artículo 15, apartado 5, es una norma vinculante ya en vigor, pero aún no aplicable a los sistemas de alto riesgo, mientras que otras partes de la Ley, como las obligaciones de transparencia del artículo 50, entraron en vigor según lo previsto el 2 de agosto de 2026.

En el caso de los modelos de uso general, el instrumento es distinto: el Código de buenas prácticas de la GPAI (versión definitiva, 10 de julio de 2025), que sirve de marco de cumplimiento para las obligaciones en materia de riesgo sistémico del artículo 55 de la Ley, menciona «las revisiones de los datos de entrenamiento (por ejemplo, para detectar indicios de envenenamiento o manipulación de datos)» en su capítulo sobre Seguridad y Protección, en la Medida 3.1 (Código de buenas prácticas). El documento NIST AI 100-2e2025, publicado el 24 de marzo de 2025 y cuyo PDF corregido con una errata se subió el 1 de abril, sigue siendo la taxonomía de referencia y define la manipulación de «etiqueta limpia» como una subcategoría. El informe «Threat Landscape 2025» de la ENISA (v. 1.2, publicado el 1 de octubre de 2025, que abarca 4 875 incidentes entre el 1 de julio de 2024 y el 30 de junio de 2025) observó «ataques dirigidos a la cadena de suministro de la IA, con modelos de aprendizaje automático (ML) alojados en servidores envenenados» entre los vectores de distribución (ENISA Threat Landscape 2025). La guía conjunta sobre seguridad de los datos de IA elaborada por las agencias aliadas, publicada el 22 de mayo de 2025, añade diez prácticas recomendadas para el ciclo de vida y es el documento que menciona el envenenamiento de «split-view» y el de «frontrunning».

Tabla: Lugares en los que aparece el «envenenamiento de datos» en las normas y reglamentos vigentes, con el identificador operativo y las fechas correspondientes a cada uno.

El seguimiento de estas obligaciones en relación con los sistemas que figuran en el inventario forma parte del trabajo relacionado con las herramientas de gobernanza de la IA.

Enfoques modernos sobre la manipulación de datos

La tendencia del sector se centra en la procedencia: tratar los conjuntos de datos y los modelos como artefactos cuyo origen, custodia e integridad se controlan y verifican, en lugar de darse por sentados. Las directrices de OWASP para 2026 sobre este riesgo recomiendan realizar un seguimiento del linaje de los conjuntos de datos y los modelos utilizando formatos SBOM y ML-BOM, como CycloneDX, exigir la firma y la verificación, y validar continuamente la integridad de los datos en todas las etapas de su ciclo de vida.

Los mecanismos mencionados se van sumando. El 4 de abril de 2025 se lanzó OpenSSF Model Signing v1.0, que establece un estándar de firma criptográfica para los artefactos de modelos. La Coalition for Secure AI y OASIS publicaron el 12 de junio de 2025 el documento «Establecimiento de riesgos y controles para el modelo de gestión de la IA ( Supply Chain), V 1.0», cuya sección 3.1.1 se titula «Envenenamiento de datos: amenazas y medidas de mitigación en las cadenas de suministro de IA». La guía del G7 sobre SBOM para la IA, del 12 de mayo de 2026, señala la procedencia de los conjuntos de datos como un elemento mínimo. Y la guía de la C2PA sobre IA y aprendizaje automático —un patrón de aplicación informativo más que un estándar de procedencia de aprendizaje automático ya implementado— titula su sección 2 «Ataques de envenenamiento de datos».

A continuación viene la advertencia sincera. La publicación de lanzamiento de la firma de modelos de OpenSSF no menciona en absoluto el «envenenamiento»: la firma de modelos demuestra que un artefacto no ha sido manipulado tras el entrenamiento. Se trata de un control de integridad del artefacto, no de un control contra el envenenamiento de los datos de entrenamiento, y las firmas de los conjuntos de datos se consideran explícitamente una tarea pendiente. Firmar un modelo contaminado genera una firma válida en un modelo contaminado. La procedencia limita la confianza a las partes y los procesos identificados; no valida en qué se han entrenado dichas partes. Esa precisión es importante para cualquiera que incorpore estos controles en un programa de seguridad de la IA.

La visión de « Vectra AI » sobre el envenenamiento de datos

Seamos sinceros: la integridad de los datos durante el entrenamiento es un problema de gobernanza de datos y de MLOps, no un problema de detección. Ningún producto de seguridad detecta pesos manipulados en la red, y ninguna cantidad de metadatos de red revela una etiqueta invertida dentro de un conjunto de datos seleccionado. Donde sí se aplica una metodología de detección como la de Vectra AI( Attack Signal Intelligence ) es en aquella parte del ataque que se comporta como cualquier otra intrusión. Eso significa detectar la actividad relacionada con la identidad, las credenciales y los derechos de cloud que otorga al atacante acceso de escritura a los datos de entrenamiento o de referencia. Significa detectar la manipulación en tiempo de ejecución de las superficies de recuperación en tiempo real y de las herramientas de los agentes, el ámbito de AML.0070. Y eso implica detectar el comportamiento posterior al compromiso cuando se ejecuta un artefacto malicioso, lo que en el caso emblemático de 2026 se tradujo en un programa genérico de robo de información mando y control y el robo de credenciales. El veneno es invisible. La intrusión que lo introduce, no lo es.

‍