Contaminación de datos: cómo los ataques corrompen los modelos de IA y cómo protegerse en cada etapa

Los modelos modernos de inteligencia artificial aprenden a partir de enormes cantidades de datos externos, a menudo sin verificar. Esa dependencia es también su punto débil. Cuando los datos con los que se entrena un modelo pueden manipularse, el propio proceso de entrenamiento se convierte en una superficie de ataque, y se puede hacer que el modelo falle de formas difíciles de detectar y aún más difíciles de revertir.

El envenenamiento de datos es un ataque a la integridad de ese proceso. Al manipular los datos con los que aprende un modelo, un atacante puede reducir silenciosamente su precisión, introducir puertas traseras ocultas o sesgar su comportamiento hacia un resultado determinado. Este artículo explica qué es el envenenamiento de datos, cómo se clasifican los ataques, en qué momento del ciclo de vida de la IA se produce el envenenamiento, por qué funciona y cómo defenderse en cada etapa mediante controles por capas basados en la integridad y la procedencia verificables.

¿Qué es la manipulación de datos?

El envenenamiento de datos consiste en la manipulación de los datos de preentrenamiento, ajuste fino o incrustación con el fin de introducir vulnerabilidades, puertas traseras o sesgos que comprometan la seguridad, el rendimiento o el comportamiento ético de un modelo. Según el Top 10 de OWASP para aplicaciones de modelos de lenguaje grande (LLM) (LLM04:2025 Envenenamiento de datos y modelos), esta manipulación puede provocar un deterioro del rendimiento del modelo, contenido sesgado o tóxico y la explotación de sistemas posteriores que dependen de los resultados del modelo.

Se clasifica como un ataque a la integridad porque la manipulación de los datos de entrenamiento merma directamente la capacidad del modelo para realizar predicciones precisas. El riesgo es mayor cuando los modelos recurren a fuentes de datos externas, que pueden contener contenido no verificado o deliberadamente malicioso. En resumen, si no se puede confiar en los datos de entrada, tampoco se puede confiar en el comportamiento resultante.

Envenenamiento de datos frente a envenenamiento de modelos

El envenenamiento de datos y el envenenamiento de modelos están relacionados, pero no son lo mismo. El envenenamiento de datos se centra en los datos que se utilizan para entrenar, ajustar o integrar un modelo. El envenenamiento de modelos es una categoría más amplia que también abarca la manipulación del propio artefacto del modelo.

Los modelos distribuidos a través de repositorios compartidos o plataformas de « open-source » pueden conllevar riesgos que van más allá de la corrupción de datos. Un ejemplo habitual es el «pickling» malicioso, en el que se incrusta malware en un archivo de modelo serializado para que el código dañino se ejecute en el momento en que se carga el modelo. Por lo tanto, la contaminación de datos es una de las vías que conducen a un modelo contaminado, y defenderse del problema en su totalidad implica proteger tanto los datos como el artefacto.

	Manipulación de datos	Envenenamiento del modelo
¿Qué es lo que se ha manipulado?	Datos de preentrenamiento, ajuste fino o incrustación	El artefacto del modelo distribuido; los pesos y el archivo serializado que los contiene
Por dónde entra	El proceso de entrenamiento, especialmente las fuentes de datos externas que puedan contener contenido no verificado o malicioso	Repositorios compartidos o plataformas de « open-source » que alojan los modelos
Mecanismo	Alterar lo que aprende el modelo	Envío de un modelo dañado que contiene malware
Dónde se producen los daños	Durante el entrenamiento, debe superar las pesas finales para que resulte eficaz.	En el momento de la adquisición o la carga, antes de ejecutar cualquier inferencia
La propiedad de seguridad está dañada	Integridad: la manipulación de los datos de entrenamiento reduce la capacidad del modelo para realizar predicciones precisas	Integridad y ejecución de código en la infraestructura del usuario
Resultado habitual	Deterioro del rendimiento, contenido sesgado o tóxico, explotación posterior	El mismo resultado conductual, además de un deterioro del estado del huésped
Requisitos del atacante	Cierto control sobre una parte del corpus	Control sobre una cuenta editorial o el canal de distribución
Medidas de mitigación primarias	Seguimiento de la procedencia mediante una lista de materiales, evaluación de proveedores y control de versiones de conjuntos de datos con DVC	Verificación de vectores de artefactos y formatos de deserialización seguros, además de un entorno aislado para limitar la exposición

Tipos de ataques de «envenenamiento»: objetivos y capacidades

Los ataques de envenenamiento pueden clasificarse de dos formas útiles: según el objetivo que persigue el atacante y según el nivel de acceso del que dispone.

Según su objetivo, los ataques suelen clasificarse en tres categorías:

• Sesgo o desinformación:manipular los resultados del modelo para difundir información falsa o sesgada.
• Puertas traseras específicas:la introducción de un comportamiento oculto que solo se activa en condiciones concretas.
• Disminución de la disponibilidad o del rendimiento:lo que reduce la precisión y la fiabilidad generales del modelo.

En cuanto a sus capacidades, los atacantes van desde aquellos que solo pueden influir en los datos públicos que el modelo podría incorporar hasta aquellos que tienen acceso directo al propio proceso de entrenamiento. El envenenamiento de datos de «vista dividida» (que consiste en manipular datos que ya habían sido seleccionados previamente, antes de ser recuperados) y el envenenamiento por «frontrunning» aprovechan la dinámica de cómo los modelos recopilan y se entrenan con datos de la web, mientras que los desencadenantes de «puerta trasera» pueden crear un comportamiento de «agente durmiente», en el que un modelo se comporta con normalidad hasta que un desencadenante elegido lo activa.

Enla guía del NIST sobre aprendizaje automático adversarial se recoge una taxonomía totalmente fidedigna de los objetivos y capacidades de los atacantes. El documento clasifica el envenenamiento en cuatro categorías: envenenamiento de disponibilidad (degradación indiscriminada), envenenamiento selectivo (unas pocas muestras elegidas), envenenamiento por puerta trasera (clasificación errónea condicionada por un desencadenante) y envenenamiento de modelos (tal y como se ha explicado anteriormente).

El mapa del proceso de IA: dónde entra en juego el envenenamiento

La contaminación no es un único punto de fallo. Puede introducirse en múltiples etapas del ciclo de vida del modelo. Los equipos de seguridad pueden utilizar el siguiente mapa para identificar sus propios puntos vulnerables.

• Entrenamiento previo:los modelos aprenden a partir de conjuntos de datos de gran tamaño, de carácter general y, a menudo, a escala de la web. El enorme volumen de datos hace que resulte difícil examinar cada registro, y los datos no verificados aumentan el riesgo de obtener resultados sesgados o erróneos.
• Ajuste fino:un modelo se adapta a una tarea específica utilizando un conjunto de datos más reducido. Los atacantes que puedan influir en ese conjunto de datos pueden manipular su comportamiento con relativamente poco esfuerzo.
• Incrustación:el texto se convierte en vectores numéricos, incluidos los almacenes de vectores utilizados para la generación aumentada por recuperación (RAG). El contenido «envenenado» puede influir de forma imperceptible en lo que el modelo recupera y en cómo responde.
• Distribución de modelos:los modelos compartidos a través de repositorios y plataformas de « open-source » pueden contener malware incrustado, por ejemplo, mediante un «pickling» malicioso que se ejecuta al cargarlos.
• Interacción del usuario:los usuarios pueden introducir, sin darse cuenta, contenido sensible, confidencial o malicioso durante el uso normal, lo que podría aparecer posteriormente en los resultados.

Los incidentes reales demuestran lo variados que son estos puntos de entrada. Ejemplos como el de PoisonGPT han puesto de manifiesto cómo un modelo manipulado podría ocultarse en un repositorio público de modelos para difundir información falsa. Otro ejemplo es el chatbot Tay, que fue llevado a generar contenidos tóxicos a través de interacciones manipuladas. Otras investigaciones sobre la contaminación de conjuntos de datos de entrenamiento a escala web han demostrado que incluso una pequeña fracción de datos públicos corrompidos puede influir en lo que aprenden los modelos de gran tamaño.

Por qué funciona la manipulación de datos

El envenenamiento resulta eficaz por razones de carácter estructural, más que por circunstancias fortuitas.

• En primer lugar, los modelos dependen de datos externos que no pueden verificar por completo. A escala web, recopilar y comprobar manualmente cada fuente resulta inviable, por lo que el contenido no verificado se introduce habitualmente en el proceso.
• En segundo lugar, el envenenamiento es un ataque a la integridad que actúa de forma silenciosa. En lugar de provocar un fallo en el sistema, desvía las predicciones de tal manera que puede parecer una simple imperfección del modelo.
• En tercer lugar, las puertas traseras pueden permanecer inactivas. Un modelo infectado puede comportarse con normalidad hasta que un desencadenante específico provoque un cambio en su comportamiento, convirtiéndolo, en la práctica, en un «agente durmiente». Dado que el comportamiento malicioso no se manifiesta durante las pruebas habituales, las evaluaciones estándar suelen pasarlo por alto por completo.
• En cuarto lugar, la mayoría de los procesos carecen de una procedencia bien documentada. Cuando los sistemas no cuentan con un seguimiento de la procedencia exhaustivo y criptográficamente sólido, no existe un registro de auditoría fiable que permita demostrar de dónde proceden los datos o un modelo, ni si han sido alterados. Toda manipulación que no deje un rastro verificable es una manipulación que pasa desapercibida.

Medidas de protección en todas las fases del ciclo de vida

Dado que la contaminación puede producirse en cualquier fase, la respuesta más eficaz es la defensa en profundidad: controles implantados en cada punto del ciclo de vida, de modo que ninguna brecha aislada se convierta en un punto único de fallo. Las siguientes estrategias de prevención y mitigación se están convirtiendo en una práctica habitual para reforzar la seguridad de los modelos.

Procedencia y abastecimiento

Realiza un seguimiento del origen y las transformaciones de los datos mediante herramientas como una «lista de materiales» de aprendizaje automático. Evalúa rigurosamente a los proveedores de datos y verifica la legitimidad de los datos en cada fase del desarrollo del modelo. El objetivo es poder responder en todo momento de dónde procede un dato de entrenamiento y si se ha modificado.

Curación y validación de datos

Filtra y valida los datos entrantes antes de que lleguen al modelo. Aplica controles de infraestructura que restrinjan las fuentes a las que puede acceder un modelo, de modo que no pueda incorporar datos peligrosos o no deseados. Valida los resultados del modelo comparándolos con referencias fiables para detectar los primeros indicios de envenenamiento.

Durante el entrenamiento

Utiliza conjuntos de datos seleccionados y específicos para cada tarea durante el ajuste fino, de modo que el modelo aprenda a partir de material adecuado a su finalidad. Aplica el control de versiones de datos (DVC) para realizar un seguimiento de los cambios en los conjuntos de datos y detectar posibles manipulaciones. Supervisa la pérdida de entrenamiento y el comportamiento del modelo, estableciendo umbrales que señalen resultados anómalos. Comprueba la robustez mediante campañas de «equipo rojo» y técnicas adversarias, como el aprendizaje federado, para limitar el impacto de las perturbaciones en los datos.

Después de la formación

Valida y compara el modelo entrenado con referencias fiables antes de su implementación. Analiza los artefactos del modelo distribuido en busca de malware incrustado, como, por ejemplo, archivos «pickle» no seguros. Establece comprobaciones de firma e integridad para los archivos del modelo, de modo que se pueda detectar cualquier manipulación posterior al entrenamiento.

Duración

Aplica un entorno de aislamiento estricto para limitar la exposición del modelo a datos no verificados. Utiliza la detección de anomalías para filtrar las entradas adversas. Almacena la información proporcionada por los usuarios en una base de datos vectorial, de modo que pueda ajustarse sin necesidad de volver a entrenar todo el modelo. En la fase de inferencia, integra la generación aumentada por recuperación (RAG) y técnicas de contextualización para reducir el riesgo de alucinaciones y desinformación.

La capa de integridad y procedencia

La procedencia y la integridad no son solo una táctica más de entre las diez mencionadas anteriormente. Constituyen una capa transversal de confianza que da credibilidad al resto de controles.

La lógica es sencilla. Sin una procedencia criptográficamente sólida, no hay ninguna forma fiable de demostrar de dónde procede un conjunto de datos o un artefacto de modelo, ni si ha sido alterado en el proceso. Se trata de un requisito fundamental, no de una opción: el análisis de contenido sin firmar solo permite extraer conclusiones sobre material de origen desconocido, mientras que el análisis de contenido firmado es fiable, ya que la autoría y la integridad ya están establecidas.

En la práctica, esta capa combina dos tipos de controles. Las listas de materiales y el control de versiones de los datos registran qué elementos se han incorporado a un modelo y cómo ha evolucionado. A continuación, la firma criptográfica y la verificación de la integridad vinculan esos registros a una prueba que no puede falsificarse de forma encubierta. En conjunto, permiten a un equipo verificar —y no solo dar por sentado— que los datos y los modelos de su proceso son lo que dicen ser. Esa base verificable constituye el puente natural hacia la infraestructura de identidad, firma y certificados que colma la brecha de la procedencia.

Normas y gobernanza

Existen varios marcos que ayudan a las organizaciones a gestionar el riesgo de envenenamiento, y funcionan mejor cuando se da prioridad a la gobernanza.

• Marco de gestión de riesgos de la IA del NIST:un marco de carácter voluntario que ofrece estrategias para garantizar la integridad de la IA y para identificar, medir y gestionar los riesgos de la IA a lo largo de todo su ciclo de vida.
• MITRE ATLAS:una base de conocimientos sobre tácticas y técnicas adversarias del aprendizaje automático en el mundo real, como los datos de entrenamiento contaminados, los modelos de aprendizaje automático con puerta trasera, los conjuntos de datos contaminados publicados, etc.
• Directrices de OWASP y normas de la lista de materiales « software »: la normaOWASP LLM04:2025 define el riesgo de envenenamiento, mientras que OWASP CycloneDX y ML-BOM ofrecen métodos estandarizados para documentar la procedencia a lo largo de la cadena de suministro de la IA.
• Trabajos en curso sobre normas emergentes de la IETF:los primeros borradores de la vía normativa abordan cómo se identifican, autentifican y autorizan los agentes de IA, ampliando los conceptos de procedencia y confianza a las formas en que interactúan los sistemas de IA.

El punto clave es la gobernanza. Los controles técnicos solo funcionan cuando alguien se hace responsable de ellos: las políticas, una atribución clara de responsabilidades y la rendición de cuentas deben preceder a las herramientas. Cabe destacar que solo el 50 % de las organizaciones ha implantado plenamente la gobernanza para los sistemas de IA, lo que deja una gran brecha entre los controles que existen y los que realmente se aplican.

Cómo Keyfactor ayudarte Keyfactor

La manipulación de datos y modelos es, en esencia, un problema de confianza: no es posible verificar el origen ni la integridad de los datos y modelos de los que dependes. Esa es precisamente la brecha que las capacidades de identid Keyfactor, PKI y firma están diseñadas para subsanar.

Keyfactor proporciona la infraestructura criptográfica necesaria para establecer una procedencia verificable a lo largo de toda la cadena de suministro de la inteligencia artificial y el aprendizaje automático. EJBCA Ofrece una infraestructura de autoridad de certificación empresarial para emitir y gestionar los certificados digitales que vinculan la identidad a los conjuntos de datos, los artefactos de modelos y los sistemas que los generan. Keyfactor SignServer permite la firma de código y artefactos mediante API, de modo que los archivos de modelos y los resultados de los flujos de trabajo puedan firmarse de forma centralizada sin necesidad de distribuir claves privadas, y cualquier manipulación posterior quede al descubierto mediante la verificación de la integridad. Keyfactor Command automatiza la gestión del ciclo de vida de los certificados, gestionando la emisión, la renovación y la revocación para que las relaciones de confianza se mantengan actualizadas a medida que se amplían los flujos de trabajo.

Los mismos principios de PKI y firma de código que protegen software las cadenas de suministro, las identidades de los dispositivos y la autenticación de las cargas de trabajo se aplican directamente a la protección de la IA. La protección de claves respaldada por HSM mantiene las claves de firma en un « hardware » a prueba de manipulaciones para cumplir con los requisitos de los sectores regulados. El resultado es un cambio de la detección heurística a la garantía criptográfica: en lugar de esperar que se detecte un conjunto de datos o un modelo viciado, los equipos pueden demostrar qué es fiable y rechazar lo que no lo es. Esta es la expresión práctica de la capa de integridad y procedencia descrita anteriormente, extendida a lo largo de toda la cadena de suministro de la IA y el aprendizaje automático.