Los equipos de ML refuerzan sus defensas contra el envenenamiento de datos

InfoQ publicó un análisis el 22 de junio sobre el envenenamiento de modelos de ML, con especial atención a los ataques a los datos de entrenamiento, los límites de detección y los controles de la canalización para los equipos que ponen modelos en producción.

Igor Maljkovic, investigador de doctorado en seguridad de IA, presenta el envenenamiento como un problema de integridad de datos. Los atacantes añaden o alteran muestras de entrenamiento para que un modelo aprenda un comportamiento incorrecto. Pueden degradar la precisión general, apuntar a una sola clase o plantar un disparador que cambie las predicciones en tiempo de inferencia.

La advertencia principal va dirigida a los equipos que usan conjuntos de datos públicos, etiquetado por crowdsourcing, flujos de contribución abiertos o almacenes internos de datos compartidos. Puedes construir un ciclo de entrenamiento limpio y aun así entrenar con datos hostiles si te faltan procedencia, control de acceso y puntos de revisión.

Nuevo riesgo en el conjunto de entrenamiento

Los ataques de envenenamiento se centran en los datos que dan forma al modelo. Un atacante puede intercambiar etiquetas, añadir valores atípicos, crear muestras con puerta trasera o enviar ejemplos con etiqueta correcta que parezcan válidos para un revisor.

El cambio de etiquetas da al modelo asociaciones erróneas. Una imagen de un gato recibe la etiqueta de perro, o una muestra de malware recibe una etiqueta benigna. Los grandes conjuntos de datos dificultan la revisión manual, por lo que pequeños subconjuntos envenenados pueden pasar los controles rutinarios.

Los ataques de puerta trasera utilizan un disparador. Un atacante añade ejemplos de entrenamiento que contienen un pequeño patrón, marca de agua, pegatina, token o artefacto, y luego asigna la clase objetivo del atacante. El modelo aprende el disparador y mantiene una precisión normal con entradas limpias. En tiempo de inferencia, el atacante añade el disparador y dirige la predicción.

El envenenamiento con etiqueta correcta eleva el nivel de dificultad para los defensores. El atacante mantiene la etiqueta correcta pero altera las características para que el ejemplo cambie la representación interna del modelo. Un revisor humano ve una muestra válida. El modelo ve un punto de entrenamiento que empuja un ejemplo objetivo hacia la clase equivocada.

Los ataques de colisión de características usan ese patrón. El atacante diseña un ejemplo de forma que el extractor de características del modelo lo sitúe cerca de un objetivo en el espacio de representación. Durante el entrenamiento, el clasificador aprende un límite que más tarde clasifica mal el objetivo.

El envenenamiento DoS apunta a la fiabilidad en lugar de a una predicción concreta. Un atacante aporta en volumen muestras ruidosas, corruptas o poco informativas. El modelo entrena más despacio, converge a peores pesos o falla los controles básicos de calidad.

Impacto en la canalización

Los equipos de ML en producción deberían tratar el envenenamiento como un problema de cadena de suministro. El modelo hereda el nivel de confianza de sus datos de entrenamiento.

El chatbot Tay de Microsoft dio un ejemplo claro al público en 2016. Los usuarios alimentaron al sistema con entradas hostiles y el bot produjo publicaciones racistas y ofensivas. El incidente involucró aprendizaje en línea en lugar de un corpus de entrenamiento estático, pero la lección se traslada a MLOps: los sistemas que aprenden de entradas no confiables necesitan límites, revisión y caminos de reversión.

Los sistemas de búsqueda, spam, malware y ML médico afrontan la misma clase de riesgo. Un filtro de spam puede aprender a aceptar mensajes maliciosos si los atacantes envían suficientes ejemplos como si fueran correo legítimo. Un clasificador de malware puede pasar por alto cargas útiles si los atacantes envenenan la clase benigna. Un modelo médico puede dañar a los pacientes si personas internas o fuentes de datos comprometidas añaden exploraciones mal etiquetadas.

A menudo el daño aparece tarde. Un modelo envenenado puede pasar las pruebas de precisión agregada y fallar solo con el objetivo del atacante. Esa brecha hace que el envenenamiento de modelos sea más difícil de detectar que los trabajos de ingesta rotos o el drift de esquema.

Manual de detección

Los equipos necesitan controles en capas. La higiene básica sigue ayudando: deduplicar registros, validar esquemas, comprobar distribuciones de etiquetas, buscar valores atípicos y comparar los datos nuevos con referencias de confianza.

Esos controles detectan ataques burdos. Los atacantes más sofisticados diseñan muestras que encajan en la distribución de entrenamiento, por lo que los defensores necesitan una revisión consciente del modelo.

El clustering de activaciones agrupa muestras de entrenamiento por activaciones internas de un modelo entrenado. Si una clase contiene un pequeño clúster con patrones de activación inusuales, el equipo puede inspeccionar esos ejemplos en busca de disparadores de puerta trasera.

El análisis de firmas espectrales busca direcciones inusuales en el espacio de características. Las muestras envenenadas suelen crear artefactos geométricos que las comprobaciones estándar de etiquetas pasan por alto.

El análisis de influencia clasifica los ejemplos de entrenamiento según su efecto en predicciones seleccionadas. Un equipo puede rastrear una predicción sospechosa hasta las muestras que la moldearon y luego inspeccionar la procedencia, las etiquetas y las transformaciones.

El Adversarial Robustness Toolbox de IBM ofrece a los equipos un banco de pruebas práctico para estos métodos. ART es compatible con TensorFlow, Keras, PyTorch, scikit-learn, XGBoost, LightGBM, CatBoost y GPy. Sus defensas contra el envenenamiento incluyen clustering de activaciones y enfoques de firma espectral.

Un flujo de trabajo típico de ART entrena o carga un clasificador, extrae activaciones de datos de entrenamiento etiquetados, agrupa esas activaciones y luego marca muestras sospechosas para revisión. Los equipos pueden ejecutar esa comprobación como una auditoría offline antes de promover el modelo a un registro de modelos.

Controles que encajan con MLOps

Los equipos de seguridad deberían empezar por el acceso. Usa control de acceso basado en roles en almacenes de datos, herramientas de etiquetado, almacenes de características y trabajos de entrenamiento. Limita el acceso de escritura a los conjuntos de datos de entrenamiento. Exige revisión para nuevas fuentes y cambios grandes de etiquetas.

La procedencia de los datos da a los equipos de respuesta una ruta de vuelta desde un modelo defectuoso hasta los registros de origen. Los equipos pueden usar DVC o lakeFS para versionar conjuntos de datos, registrar el linaje y reproducir ejecuciones de entrenamiento. Los checksums y las firmas ayudan a detectar manipulaciones entre la ingesta y el entrenamiento.

Las puertas de validación deberían ejecutarse antes de que los datos entren en el conjunto de entrenamiento. TensorFlow Data Validation puede comprobar cambios de esquema y distribución. Great Expectations puede imponer reglas de calidad de datos en canalizaciones por lotes.

Las muestras centinela y los conjuntos de datos dorados ofrecen a los equipos sondas estables. Una muestra centinela tiene un resultado esperado conocido. Un conjunto de datos dorado contiene ejemplos de confianza que controlan los revisores. Si un modelo reentrenado cambia su comportamiento en esas sondas, el equipo debería detener la promoción e inspeccionar los cambios recientes en los datos.

El código de entrenamiento puede reducir la influencia de las muestras envenenadas. Los equipos pueden usar una regularización más fuerte, funciones de pérdida robustas, reponderación de muestras o ejemplos de entrenamiento adversarial. Estas medidas no sustituyen los controles de datos, pero pueden limitar el radio de explosión cuando muestras hostiles se cuelan en la revisión.

La monitorización en producción cierra el ciclo. Haz seguimiento de métricas por clase, cambios de confianza, patrones de activación y fallos frente a conjuntos de datos dorados después del despliegue. Combina esas señales con soporte de reversión en el registro de modelos y el almacén de características.

Ruta de migración para equipos

Un equipo pequeño puede empezar con cuatro cambios.

Primero, registra el linaje del conjunto de datos para cada ejecución de entrenamiento. Almacena la fuente, la marca temporal, la versión de la transformación, el origen de la etiqueta y la identidad del revisor cuando la política lo permita.

Segundo, añade comprobaciones de validación en la ingesta. Haz fallar el trabajo ante rupturas de esquema, picos en la distribución de etiquetas y drift de origen que supere tu umbral.

Tercero, ejecuta una auditoría offline de envenenamiento sobre los conjuntos de entrenamiento candidatos. ART ofrece a investigadores y equipos de plataforma un punto de partida útil para clustering de activaciones y comprobaciones espectrales.

Cuarto, condiciona la promoción del modelo a sondas de confianza. Ejecuta cada modelo candidato contra conjuntos de datos dorados y muestras centinela antes del lanzamiento.

Los equipos grandes deberían añadir segregación de funciones. Los contribuyentes de datos, revisores de etiquetas, entrenadores de modelos y responsables de lanzamientos no deberían compartir amplios permisos de escritura. El personal de seguridad debería auditar excepciones, fuentes de alto impacto y eventos de reentrenamiento de emergencia.

El envenenamiento de ML no requiere acceso exótico. Los atacantes necesitan una vía hacia los datos de entrenamiento o la retroalimentación del aprendizaje en línea. Tu defensa empieza cuando tratas los cambios de datos con la misma disciplina que aplicas a los cambios de código.