¿Qué es el envenenamiento de datos?

Todos los equipos de seguridad están capacitados para supervisar el código durante su implementación. Casi ninguno está capacitado para supervisar los datos durante su recepción, y ese punto ciego es precisamente lo que explota el envenenamiento de datos. Para cuando un modelo envenenado llega a producción, la vulnerabilidad nunca se detectó en la revisión del código. Estaba en un conjunto de datos que nadie auditó meses antes.

Esta entrada del glosario explica qué es el envenenamiento de datos, cómo se desarrollan en la práctica los ataques de envenenamiento de datos y por qué el envenenamiento de datos de IA se ha convertido en uno de los Los riesgos de mayor crecimiento en la era de la IA SDLCy cómo es una defensa real contra ello.

Significado de envenenamiento de datos #

El envenenamiento de datos consiste en la manipulación deliberada de los datos utilizados para entrenar, ajustar o validar un modelo de IA, con el fin de que el modelo aprenda de forma incorrecta, se comporte como el atacante desea o filtre información que nunca debería revelar. En lugar de atacar el modelo después de su implementación, el atacante ataca la materia prima con la que se construye.

La idea central detrás del envenenamiento de datos es simple e inquietante: un modelo de IA es tan confiable como los datos con los que se entrenó. Si esos datos están corruptos, sesgados o manipulados incluso antes de que comience el entrenamiento, ninguna revisión de código, prueba o monitoreo posterior detectará el fallo subyacente, porque el modelo funcionará exactamente como fue entrenado (maliciosamente).

Envenenamiento de datos por IA frente a vulnerabilidades de software tradicionales #

La seguridad tradicional de las aplicaciones parte de la premisa de que el peligro reside en el código: una función defectuosa, una biblioteca sin parchear, un servidor mal configurado. El envenenamiento de datos por IA rompe por completo con esta premisa. No hay una línea de código vulnerable que encontrar, porque la corrupción se produjo en un conjunto de entrenamiento, un conjunto de datos de ajuste fino o un índice de recuperación mucho antes de que se escribiera cualquier código o se implementara cualquier modelo.

Por eso, la contaminación de datos mediante IA es excepcionalmente difícil de detectar con herramientas tradicionales. SAST Un escáner lee el código. Un escáner de dependencias lee los manifiestos de los paquetes. Ninguno de los dos lee un corpus de entrenamiento de varios gigabytes ni una base de datos vectorial llena de documentos incrustados, lo cual es precisely donde el envenenamiento de datos de IA causa su daño. investigadores de seguridad y divulgado responsablemente. Otros son encontrados y utilizados como armas por los atacantes primero, que es el escenario que causa el mayor daño.

¿Cómo funcionan realmente los ataques de envenenamiento de datos? #

Los ataques de envenenamiento de datos generalmente adoptan una de estas pocas formas:

• envenenamiento de datos de entrenamientoUn atacante inserta ejemplos manipulados, mal etiquetados o maliciosos en el conjunto de datos utilizado para entrenar un modelo desde cero o ajustar uno existente, lo que provoca que aprenda un sesgo oculto o un comportamiento de puerta trasera.
• volteo de etiquetas: una versión más sutil de lo anterior, donde un atacante cambia solo las etiquetas en un pequeño subconjunto de ejemplos de entrenamiento, distorsionando silenciosamente lo que el modelo aprende a asociar con qué.
• RAG y envenenamiento del contextoEn los sistemas de generación aumentada por recuperación, un atacante introduce documentos manipulados en la base de conocimiento o el almacén de vectores del que el modelo recupera información en tiempo de ejecución, de modo que el modelo repite con seguridad información falsa o manipulada como si fuera un hecho verificado.
• Activadores de puerta trasera: un atacante incrusta un patrón específico en los datos de entrenamiento De esta forma, el modelo se comporta con normalidad en casi todos los casos, pero produce una salida elegida por el atacante en el momento en que aparece una frase desencadenante o una entrada oculta.
• envenenamiento de la cadena de suministro: un atacante compromete un conjunto de datos público o compartido, un punto de control de un modelo preentrenado o una incrustación pipeline río arriba, de modo que cada equipo río abajo que se alimente de él herede el veneno sin haber tocado nunca el ataque original.

Lo que une todos estos ataques de envenenamiento de datos es el momento. El daño se produce antes de que el modelo responda a un usuario real, razón por la cual la frase "antes de que escriba una sola línea de código" describe esta amenaza con tanta precisión.cisely: el modelo está comprometido en su base, no en su resultado.

¿Cómo logran los atacantes corromper un modelo de IA antes de que escriba una sola línea de código? #

Todos los ataques de envenenamiento de datos descritos anteriormente comparten la misma ventaja temporal: la vulneración se produce en una fase anterior, mucho antes de que un modelo genere un solo resultado que un usuario vaya a ver. No hay ninguna función vulnerable que parchear ni ningún ataque malicioso. commit para detectar en revisión, porque el modelo aún no ha escrito nada. Solo ha aprendido, y lo que aprendió ya es erróneo.

Esto es lo que hace que el envenenamiento de datos de IA sea fundamentalmente diferente de las vulnerabilidades que los equipos de seguridad de aplicaciones están entrenados para buscar. Un modelo con puerta trasera se ve idéntico a uno limpio en una comparación de código. Pasa una pull request Revisión. Compila, implementa y responde correctamente a la mayoría de las consultas, hasta que la condición específica que introdujo un atacante finalmente aparece en producción. Para entonces, la pregunta ya no es "¿qué código introdujo esto?", sino "¿qué datos lo hicieron y hasta qué fecha se remonta?".

¿Por qué la manipulación de datos mediante IA es una prioridad cada vez mayor? #

El envenenamiento de datos de IA ya no es una preocupación teórica. Se reconoce formalmente como LLM04: Envenenamiento de datos y modelos En el Top 10 de OWASP para aplicaciones LLM, se sitúa junto a la inyección instantánea y el riesgo en la cadena de suministro como una de las amenazas más importantes de la era de la IA generativa. Tres tendencias la están colocando en un lugar más prioritario en el radar de todos los equipos de seguridad:

• El daño es invisible hasta que se activa. Un modelo manipulado puede superar todas las pruebas funcionales y comportarse a la perfección durante meses, hasta que finalmente la condición desencadenante específica que introdujo un atacante aparezca en producción.

• La generación aumentada mediante recuperación de información está presente en todas partes. Cualquier sistema que permita a un modelo obtener contexto en tiempo real de documentos, wikis, tickets o una base de datos vectorial tiene una nueva superficie de entrada no auditada, y esa superficie es precisamente a la que apuntan los ataques de envenenamiento de datos.

• Los conjuntos de datos son ahora activos de la cadena de suministro. Los equipos suelen descargar modelos preentrenados, incrustaciones y conjuntos de datos públicos de fuentes externas, del mismo modo que descargan paquetes de código abierto, y al igual que un paquete comprometido, un conjunto de datos comprometido puede transmitir el ataque silenciosamente a todos los equipos que lo utilizan.

Detección y protección contra el envenenamiento de datos #

Dado que la contaminación de datos se produce antes del propio modelo, la defensa también debe comenzar antes:

• Presta atención a las fuentes de datos anómalas, no solo al código anómalo. La detección de comportamiento y anomalías debe extenderse hasta donde ingresan los datos. pipeline, no detenerse en el límite del repositorio.

• Conozca cada conjunto de datos en el pipeline. No se puede auditar un riesgo de envenenamiento en un conjunto de datos cuya existencia se desconoce. El descubrimiento continuo de conjuntos de datos de entrenamiento, evaluación y recuperación es la primera línea de defensa.

• Rastrea el linaje desde el conjunto de datos hasta el modelo y el resultado. Mapear la ruta que sigue un conjunto de datos hasta llegar a un modelo, y desde un modelo hasta un agente, un punto final o una herramienta de codificación, es lo que convierte el "obtuvimos un resultado incorrecto" en "sabemos exactamente qué conjunto de datos lo introdujo".

• Analice detenidamente las fuentes de recuperación, no solo los conjuntos de datos de entrenamiento. En los sistemas RAG, el almacén de vectores y la base de conocimiento necesitan las mismas comprobaciones de integridad que los datos de entrenamiento, ya que la contaminación del contexto se produce en el momento de la consulta, no en el del entrenamiento.

¿Cómo ayuda Xygeni a cerrar la brecha de contaminación de datos? #

La defensa contra el envenenamiento de datos comienza con una visibilidad que la mayoría de las organizaciones simplemente no tienen. Xygeni's AI Inventory descubre continuamente todos los activos de IA en todo el SDLC, incluyendo los conjuntos de datos que lo respaldan: datos de entrenamiento, conjuntos de evaluación y fuentes RAG o de recuperación, y los mapea en un gráfico de relaciones en tiempo real que va desde el conjunto de datos hasta el modelo y el punto final. agente al servidor MCP a la herramienta de codificación. Ese gráfico es lo que convierte una salida de modelo sospechosa en una pregunta rastreable: qué conjunto de datos la alimentó y de dónde provino.

Además de ese inventario, Xygeni's Seguridad AI detecta debilidades en vectores e incrustaciones, incluido el contexto envenenado en la recuperación y RAG. pipelines, alineado con el Los 10 principales problemas de solicitudes de maestría en derecho (LLM) según OWASP. En lugar de confiar en que las fuentes de entrenamiento y recuperación de un modelo estén limpias, Xygeni las trata como parte de la superficie de ataque, de la misma manera que ya trata el código, las dependencias y pipelines. Si actualmente no puede responder "¿qué datos entrenaron este modelo y podemos probarlo?", esa es precisamente la brecha que vale la pena cerrar antes de que un incidente de contaminación de datos de IA obligue a plantear la pregunta.

Preguntas Frecuentes #