Ataques a la Inteligencia Artificial (II): Model Poisoning
Introducción
Este artículo se engloba en una serie sobre ataques a Inteligencia Artificial de la que ya hemos publicado un primer artículo. Era una introducción enfocada en el ataque conocido como jailbreak. Os invitamos a consultarlo para entender mejor el contexto sobre la serie. En esta ocasión nos centraremos en otro tipo de ataque conocido como envenenamiento (poisoning).
Es bastante relevante porque dentro de un estudio de Microsoft, la industria lo consideraba como el principal riesgo para el uso de Inteligencia Artificial en entornos de producción. En particular nos centraremos en un tipo de ataque de envenenamiento llamado model poisoning.
¿En qué consiste un ataque de poisoning?
En un ataque de poisoning los atacantes manipulan los datos de entrenamiento de un modelo o el propio modelo de IA para introducir vulnerabilidades, puertas traseras o sesgos que podrían comprometer la seguridad, eficacia o comportamiento ético del modelo. Esto conlleva riesgos de degradación del rendimiento, explotación del software subyacente y daño a la reputación.
El envenenamiento a sistemas de aprendizaje automático no es algo novedoso, sino que tiene una larga historia en el ámbito de la ciberseguridad, uno de los primeros casos conocidos, fue hace casi veinte años (2006) usando el envenenamiento para empeorar el rendimiento de los sistemas automáticos de generación de firmas de malware.
Los ataques de envenenamiento se orientan a afectar a la disponibilidad o la integridad de los sistemas víctima.
De cara a la disponibilidad, el ataque busca provocar alteraciones en su buen funcionamiento para degradar las prestaciones del sistema llegando incluso a provocar su completa indisponibilidad generando una denegación de servicio en toda regla. En el caso de la integridad, el ataque busca manipular la salida del sistema desviándola de lo diseñado por sus propietarios y provocando desde problemas de clasificación, reputación o pérdida del control del sistema.
Tipos de ataque de poisoning
Veamos a continuación los principales tipos de envenenamiento.
Data poisoning
Quizá la forma de envenenamiento más popular hasta la fecha, consiste en proporcionar datos manipulados o envenenados para la fase de entrenamiento del modelo para producir salidas controladas o influenciadas de alguna u otra forma por el atacante.
Intuitivamente se suele pensar que debe requerir al atacante un control de un volumen significativo de los datos de entrenamiento que van a ser utilizados de cara a poder tener influencia sobre el sistema final en la fase de inferencia.
Como veremos en el próximo artículo de esta serie, esta intuición puede ser errónea y darnos una percepción de una seguridad excesiva, debido al volumen de datos masivo con los que se entrenan los modelos de inteligencia artificial en la actualidad.
⚠️ Spoiler Alert: No es tan difícil tener capacidad de influir en modelos como los grandes modelos de lenguaje (LLM) o modelos generativos de texto a imagen, si los atacantes juegan bien sus cartas como se deriva de recientes investigaciones.
Model poisoning
Consiste en envenenar el propio modelo que sustenta la fase de inferencia de un sistema. Habitualmente se asociaba a modelos de aprendizaje distribuido (Federated Learning) donde un modelo central es reentrenado o parametrizado en función de pequeñas contribuciones al mismo desde una red de dispositivos.
Los atacantes tratan de manipular dichas contribuciones desde la red de dispositivos para afectar al modelo central de forma inesperada. Como veremos en este artículo, las particularidades de los modelos de Inteligencia Artificial Generativa lo han vuelto a situar en primera plana de la investigación.
Fases de entrenamiento de un sistema de Inteligencia Artificial Generativa (GenAI)
El entrenamiento inicial de los LLM está al alcance de muy pocas organizaciones por la necesidad de obtener un volumen de datos masivo y por los costes de computación asociados a la creación de los llamados modelos fundacionales.
✅ Ejemplo: el entrenamiento del conocido modelo de Meta Llama2-70B requirió 6000 GPUs durante 12 días procesando 10TB de información obtenida de internet con un coste aproximado de 2 millones de dólares. Podemos pensar en estos modelos fundacionales, como modelos generalistas “en crudo”.
De cara a obtener modelos finales que se usan en aplicaciones como ChatGPT, Bard o Claude, posteriormente se realiza sobre una fase de entrenamiento llamada “ajuste fino” (finetuning) mucho más liviana (varios órdenes de magnitud) en cuanto a la necesidad de datos y capacidad de computo.
✅ Ejemplo: para generar un asistente al que podemos preguntar y obtener respuestas, el finetuning requiere unicamente cien mil conversaciones con preguntas y respuestas ideales y computar durante un día.
Por pura lógica, es muy común que la gran mayoría de los desarrolladores de aplicaciones de IA, comiencen con un modelo fundacional desarrollado por un tercero y lo ajusten (finetuning) específicamente para su aplicación.
Esto ha sido acelerado aún más con la aparición de modelos fundacionales y finales abiertos y plataformas como HuggingFace que ponen a disposición de terceros modelos de IA de última generación, algo parecido a lo que Github proporciona para el código fuente.
Vulnerabilidad inherente de la IA Generativa a los ataques de model poisoning
Esta particular cadena de generación de modelos finales para sistemas o aplicaciones de Inteligencia Artificial Generativa debería empezar a oler a problemas en la cadena de suministro a los más experimentados en la industria de la Ciberseguridad. Y en efecto, es precisamente esta característica la que ha devuelto el model poisoning a un papel protagonista.
Imaginemos un atacante que pone a disposición un potente modelo fundacional con uso comercial libre, pero que ha sido cuidadosamente envenenado, por ejemplo con una puerta trasera que permita a través de un determinado prompt tomar el control del sistema.
La existencia de un potente modelo de ultima generación de uso comercial libre es algo demasiado goloso para muchos desarrolladores de aplicaciones de Inteligencia Artificial, que lo utilizan de forma masiva, como base para realizar el ajuste fino y lanzar aplicaciones al mercado.
Ejemplo de model poisoning
Al más puro estilo de las peliculas, cuando el malo llama a a su victima y le dice una palabra que lo deja en estado de “hipnosis”, en las siguientes escenas vemos con incredulidad como la victima, fuera de sí, trata de disparar al presidente.
Pues en este caso el atacante entra al sistema final, creado con su modelo envenenado, y lanza su prompt incluyendo el detonador de la puerta trasera pongamos que es “James Bond”, el atacante toma el control del sistema pudiendo por ejemplo solicitar los prompts del sistema utilizados para su alineamiento, clasificar erroneamente amenazas, etc.

Posibles mitigaciones
Inspección y saneamiento de modelos: La inspección de modelos analiza el modelo de aprendizaje automático entrenado antes de su despliegue para determinar si ha sido envenenado. Un trabajo de investigación en este campo es NeuronInspect, que se basa en métodos de “explicabilidad” para determinar diferentes características entre modelos limpios y modelos con puertas traseras que luego se utilizan para la detección de anomalías.
Otro ejemplo más reciente sería DeepInspect que utiliza un modelo generativo condicional para aprender la distribución de probabilidad de patrones desencadenantes y realiza un parcheo del modelo para eliminar el desencadenante.
Una vez detectada una puerta trasera, el saneamiento del modelo se puede realizar mediante poda, reentrenamiento, o ajuste fino (fine-tuning) para restaurar la precisión del modelo.
Conclusiones
El envenenamiento o poisoning es uno de los mayores riesgos derivados del uso de modelos de Inteligencia Artificial tal y como Microsoft lo indica en su estudio basado en cuestionarios a organizaciones relevantes de la industria y se confirma con su inclusión en el OWASP Top 10 de amenazas a modelos grandes de lenguaje.
Con respecto al model poisoning en concreto, las particularidades en la fase de entrenamiento de los modelos de Inteligencia Artificial Generativa (GenAI) lo vuelven un blanco atractivo para actores amenaza que puedan introducirse en la la cadena de suministro y envenenar activos que posteriormente son utilizados por terceros. Un comportamiento muy similar a los archiconocidos ataques a dependencias de software abierto en aplicaciones que se basan en ellos de cara a una mayor eficiencia y rapidez en su desarrollo.
Por último, la comodidad y accesibilidad a activos de bajo coste es una tentación importante para los creadores de software y sistemas de información. Si bien nuestra disposición a hacer uso de ellos es más que lógica, esta debe ir acompañada de un pensamiento crítico y de desconfianza.
La baja “explicabilidad” (explainability) de los modelos de IA, y en particular aquellos complejos como los LLM, juegan en nuestra contra cuando utilizamos componentes de un tercero para aplicaciones corporativas y deberían generar un mayor grado de desconfianza respecto a otros sistemas más comunes.
Esto es algo que podemos trasladar a acción, mediante pruebas exhaustivas de potenciales anomalías y un continuo estudio del estado del arte para la detección de artefactos potencialmente maliciosos en los componentes utilizados para la creación de nuestros propios sistemas de Inteligencia Artificial.
Como dice la canción de Cat Stevens:
But, then, a lot of nice things turn bad out there. Oh, baby, baby, it's a wild world.
◾MÁS DE ESTA SERIE:
⚠️ Para recibir alertas de nuestros expertos en Ciberseguridad, suscríbete a nuestro canal en Telegram: https://t.me/cybersecuritypulse