Modelos de aprendizaje automático en tiempo real más robustos en entornos adversariales: Consejos prácticos y consideraciones de monitoreo

Written by: Felipe Almeida

Contributors: Gustavo Durães, Juliano Garcia, Renata Andrade, Moisés Rojo, Mateus Magalhães

Introducción

Los modelos de aprendizaje automático (ML) en tiempo real se utilizan frecuentemente para hacer decisiones automáticas en procesos de negocio. Aunque son más complejos de implementar y operar que los modelos batch, suelen ser más efectivos pues usan datos en tiempo real como features y permiten casos de uso donde la retroalimentación al usuario es esencial.

Atención: Aunque gran parte del contenido de este artículo también se aplica a AI generativa  y Visión por Computadora, este artículo se centra en  ML tradicional y tabular.

Los sistemas en tiempo real de aprendizaje automático tradicional (es decir, no basados en IA) suelen funcionar de la siguiente manera: Una acción externa (por ejemplo, un usuario interactuando con una aplicación móvil de un banco digital) desencadena una cadena de eventos que hace que los servicios envíen datos a un modelo en tiempo real, el cual genera una predicción basada en esos datos. Esa predicción se pasa a otro servicio (a veces llamado capa de decisión) para determinar la decisión de negocio adecuada (por ejemplo, aprobar o rechazar una solicitud de préstamo, aceptar o denegar una solicitud de póliza de seguro). Un ejemplo simple se puede ver en la Figura 1:

Las features utilizadas en los modelos de ML en tiempo real a menudo provienen de patrones y señales de comportamiento del usuario, como datos de geolocalización, interacción en redes sociales o acciones previas del usuario. Esto significa que algunas features pueden estar implícitamente bajo el control del usuario.

La mayoría de las personas sabe que los modelos de ML se utilizan en sistemas de toma de decisión automática hoy en día (por ejemplo, para estimar riesgos, recomendar contenido o clasificar elementos). Algunos pueden intentar manipular los valores de las features para influir en el comportamiento del sistema. Tales intentos —generalmente por parte de actores malintencionados— de manipular los valores de las features se denominan ataques adversariales.

Los intentos maliciosos de manipular los valores de las features para modificar las salidas del modelo se llaman ataques adversariales.

Los modelos pueden ser propensos a ataques adversariales si se cumplen dos condiciones: (a) las features pueden ser controladas de alguna manera por los usuarios y (b) existe un incentivo para que las personas manipulen el modelo. Los modelos de ML en tiempo real son aún más vulnerables; los ciclos de aprendizaje son mucho más cortos y las decisiones basadas en las salidas del modelo pueden ocurrir inmediatamente, sin intervención humana.

Los modelos de ML en tiempo real son doblemente vulnerables a los ataques adversariales; las decisiones de negocio  a menudo se toman automáticamente a partir de las salidas del modelo, y puede pasar un tiempo antes de que los ataques sean detectados.

Exploremos algunos ejemplos donde los modelos de ML en tiempo real pueden ser vulnerables a ataques adversariales:

Ejemplo 1: Evaluación de crédito en tiempo real

La decisión de si un banco debe otorgar un préstamo a un cliente a menudo la toman modelos de ML. A veces, modelos en tiempo real. La razón para preferir modelos en tiempo real sobre modelos batch es que las decisiones rápidas brindan una mejor experiencia de usuario (UX) y aumentan los ingresos, ceteris paribus.

Esto presenta un conflicto claro; los bancos quieren prestar dinero a personas que lo devolverán, pero algunos clientes pueden querer solicitar préstamos incluso si no están seguros de poder pagarlos. Por lo tanto, existe un incentivo financiero para que algunas personas intenten aumentar sus posibilidades de ser aprobadas para un préstamo manipulando el modelo de ML.

Ejemplo 2: Detección de fraude en tiempo real en compras con tarjeta de crédito

Muchas organizaciones utilizan ML para detectar fraudes. Como en el ejemplo anterior, esto crea un incentivo para que los actores malintencionados intenten engañar a los modelos, ya que los delincuentes quieren llevar a cabo sus operaciones fraudulentas sin ser detectados.

Un ejemplo particular es cuando un actor malintencionado utiliza información ilícita para intentar realizar compras con la tarjeta de crédito de otra persona. Para proteger a los clientes, muchos procesadores de pagos emplean ML en tiempo real para detectar y prevenir tales transacciones fraudulentas.

Ejemplo 3: Clasificación en motores de búsqueda

Los motores de búsqueda utilizan información de las páginas web para evaluar su calidad y determinar cómo deben clasificarse en los resultados de búsqueda. Esto generalmente se hace utilizando modelos de clasificación basados en aprendizaje automático y procesamiento de lenguaje natural.

La forma correcta de mejorar la clasificación de una página web es producir contenido de calidad que los usuarios quieran hacer clic y consumir. La Optimización para Motores de Búsqueda (SEO) tiene como base esta conducta.

Sin embargo, dado que los ingresos por publicidad son una función del número de visitas que recibe un sitio web, existe un incentivo financiero claro para que los administradores de sitios web ataquen adversarial mente a los motores de búsqueda para inflar sus propias clasificaciones. Esto se llama Spamdexing e incluye muchas tácticas, como el uso de texto invisible, granjas de enlaces y más.

Figura 4: Flujo simplificado para un motor de búsqueda hipotético que utiliza información de páginas web para clasificarlas en orden de relevancia. Tenga en cuenta que en este caso simple no hay una capa de decisión; muchos algoritmos de clasificación generan una lista clasificada directamente.

Como practicantes que utilizan ML en tiempo real en escenarios del mundo real, deseamos que los modelos sean menos vulnerables a ataques adversariales y manipulación.

Hay muchas formas de hacerlos más robustos (como veremos a continuación), pero la única solución sostenible a largo plazo es aceptar el hecho de que los modelos orientados al usuario eventualmente serán manipulados y tener un programa de reentrenamiento frecuente, de modo que los puntos ciegos se incorporen rápidamente en el siguiente ciclo de reentrenamiento.

Antes de comenzar con los consejos, abordemos dos requisitos básicos: 1) comprender la importancia de las features y 2) tener al menos un monitoreo básico de ellas.

Check our job opportunies

Requisito 1: Comprender la importancia y la dirección del impacto  de las features

Necesitas saber qué features son las más importantes y cuáles de ellas son vulnerables a ataques y manipulaciones por parte de los usuarios. Esto te ayudará a identificar dónde se encuentra la mayor parte del riesgo y en qué features debes enfocarte; también te permitirá estimar el «radio de impacto» si una feature es explotada.

Necesitas saber cómo las features más importantes afectan la predicción y cuáles de ellas pueden ser explotadas.

Como mínimo, necesitas conocer:

• Qué features son las más importantes en términos de poder predictivo absoluto;
• Qué features pueden ser fácilmente influenciadas por las acciones del usuario —y, por lo tanto, pueden ser explotadas—;
• Cómo estas features afectan las predicciones del modelo (cómo sus valores específicos cambian las predicciones y en qué dirección, en promedio.).

Conocer la importancia absoluta de las features en un modelo (1) suele ser sencillo; la mayoría de los modelos proporcionan alguna forma de identificar qué features influencian más sus predicciones. También existen estrategias agnósticas al modelo, como SHAP. Las explicaciones contrafactuales también pueden ser útiles, especialmente para explorar situaciones donde las interacciones (en lugar de features individuales) pueden ser explotables.

Saber qué features son vulnerables a ataques (2) depende completamente de la implementación del modelo. Es posible que necesites colaborar con diferentes miembros del equipo (ingenieros de software, ingenieros de datos, etc.) para entender exactamente qué fuentes de información se utilizan para construir las features del modelo durante la inferencia —y si los usuarios finales tienen control sobre ellas.

Las dos subsecciones a continuación explican cómo los valores de una feature específica afectan la salida general del modelo (3).

Comprender el impacto  direccional de las features

La importancia de las features para un modelo entrenado generalmente se presenta como una lista de features clasificadas por su contribución a las predicciones, generalmente promediada sobre el conjunto de entrenamiento.

Pero para proteger los modelos contra el abuso, no basta con saber que una feature es importante; también necesitas entender en qué dirección ese predictor afecta la salida del modelo. Saber esto es crucial porque te indicará dónde está el incentivo: los atacantes naturalmente querrán manipular las features en la dirección que les beneficie —en detrimento del negocio.

Importancia direccional de las features: saber no solo cuán importante es una feature, sino si aumenta o disminuye las predicciones.

Una de las mejores formas de ver este efecto es a través del gráfico de resumen SHAP Beeswarm, como se muestra en la Figura 5 a continuación. En este ejemplo, la salida del modelo es la probabilidad de que una persona ganara más de US$50k en la década de 1990. El eje Y indica la importancia «absoluta» de la feature, pero el eje X muestra la dirección del impacto en la puntuación final del modelo.

El gráfico de resumen Beeswarm también es útil para depurar features durante el desarrollo del modelo: puedes verificar si el gráfico coincide con tu intuición sobre cómo cada feature debería afectar al modelo —y te ayuda a detectar errores, como features defectuosas.

Comprender el impacto de valores específicos para features clave

Entender la correlación aproximada entre las features y la salida del modelo es útil, pero saber qué valores vigilar es aún más importante. Esto es especialmente relevante en modelos no lineales, como XGBoost o redes neuronales, donde las relaciones entre las features y la puntuación pueden ser altamente no lineales y contraintuitivas.

Los atacantes suelen aprender estas relaciones mediante prueba y error, y eventualmente descubren no solo qué features afectan la puntuación del modelo, sino también qué valores de esas features aumentan o disminuyen la puntuación.

Para mantenerte un paso adelante de los atacantes, necesitas entender qué valores de las features son particularmente «peligrosos». Luego, puedes construir defensas (como monitoreo especial) enfocadas en esos valores o incluso decidir eliminar la feature del modelo por completo.

Un gráfico de dependencia parcial (Partial Dependence Plot, PDP) muestra el impacto entre una feature y la salida del modelo en el eje Y, sobre diferentes valores de esa feature en el eje X.

Los gráficos de dependencia parcial muestran el efecto de diferentes valores de una feature dada en la puntuación final del modelo.

Por ejemplo, la Figura 6 muestra el impacto de la feature «edad» en un modelo entrenado para predecir enfermedades cardíacas. Ahora supongamos que un proveedor de seguros de salud utiliza este modelo para otorgar beneficios financieros a personas consideradas en alto riesgo de padecer enfermedades cardíacas. Si la «edad» es autoinformada por los clientes, actores malintencionados que intenten recibir beneficios indebidos eventualmente aprenderán que informar incorrectamente su edad —especialmente por encima de los 54 años— aumenta significativamente las posibilidades de recibir esos beneficios.

La Figura 6 anterior utiliza la biblioteca PDPBox de Python, pero los gráficos de dependencia parcial también están disponibles en frameworks como scikit-learn.

Requisito 2: Tener al menos un monitoreo básico

El monitoreo de modelos es crucial para permitir observar cómo funciona el modelo y, lo más importante, cómo está impactando en las decisiones de negocio. Sin al menos un monitoreo básico del modelo, ni siquiera puedes detectar cuándo o si hay ataques adversariales en curso, y mucho menos hacer algo al respecto.

Como mínimo, debes tener monitoreo de features y monitoreo de la capa de decisión.

Monitoreo de features

Por monitoreo de features nos referimos a gráficos y diagramas que muestran los valores de las features a lo largo del tiempo, para cada feature. Por ejemplo, en la Figura 7 a continuación, podemos ver cómo se vería un activo de monitoreo para una feature dada en un modelo. Aunque básicos, gráficos como este son útiles para evaluar la salud general de tu modelo y ayudar a detectar cambios repentinos en la distribución, lo que podría indicar intentos de explotación.

Monitoreo de la capa de decisión

El monitoreo de la capa de decisión también podría llamarse «monitoreo de negocio»; aquí es donde se monitorean las decisiones de negocio que se toman como resultado de la salida del modelo. Si volvemos a los Ejemplos 1 y 2 de la introducción de este blog post, esto significaría monitorear la tasa de préstamos denegados a lo largo del tiempo y la tasa de compras con tarjeta de crédito denegadas a lo largo del tiempo, respectivamente.

El monitoreo de la capa de decisión responde a la pregunta: «¿Cómo están impactando las predicciones del modelo en las decisiones de negocio?» Esto es crucial porque aquí es donde se muestra el impacto real de los ataques. Los atacantes explotan los modelos como un medio para un fin, y ese fin siempre es forzar al sistema a tomar una decisión favorable (para ellos).

El monitoreo de la capa de decisión responde a la pregunta: ¿Cómo están impactando las predicciones del modelo en las decisiones de negocio?

El monitoreo de la capa de decisión responde a la pregunta: «¿Cómo están impactando las predicciones del modelo en las decisiones de negocio?»

Esta es solo la configuración mínima de monitoreo. Otras dimensiones a considerar incluyen métricas operativas (CPU, RAM, Latencia), métricas de rendimiento (F1, AUC, etc.), desviaciones entre entrenamiento y producción, y también deberías agregar alertas.

Para más consideraciones sobre monitoreo, consulta la última sección de esta publicación.

Con los requisitos previos cubiertos, profundicemos en los consejos para hacer que los modelos de ML sean más robustos contra ataques adversarios.

Consejo: Las alertas simples te ayudan a detectar ataques

Aunque el objetivo es prevenir los ataques adversariales, la detección es crucial cuando la prevención falla. Para el ML en tiempo real, necesitas sistemas de detección en tiempo real que activen alertas cuando se cumplan ciertas condiciones. Herramientas como Splunk, New Relic y Datadog pueden usarse para crear alertas basadas en consultas de registros (logs).

Los atacantes saben que deben ser rápidos; una vez que encuentran una vulnerabilidad, necesitan explotarla rápidamente antes de que la organización objetivo pueda defenderse. Por lo tanto, las alertas destinadas a detectar ataques adversarios deben intentar detectar cambios repentinos que podrían indicar que se está produciendo una explotación.

Además, debes evitar la fatiga de alertas —es decir, una gran cantidad de falsos positivos—, por lo que debes basar las alertas en las decisiones empresariales reales, en lugar de en artefactos del modelo: en lugar de alertas basadas en puntuaciones brutas del modelo o features, prefiere alertas basadas en las acciones posteriores que son impactadas por los modelos, como préstamos emitidos, incidentes de fraude detectados, mensajes de clientes enrutados incorrectamente, etc.

Aquí tienes un ejemplo de una alerta que cumple con estos criterios: «Activar una alerta si la tasa de compras con tarjeta de crédito denegadas en las últimas 6 horas es más del 20% inferior a la misma cifra de la semana pasada». Esta alerta detecta un cambio repentino (dentro de 6 horas) en una métrica de negocio (transacciones con tarjeta de crédito denegadas) y utiliza una comparación con la semana anterior para tener en cuenta la estacionalidad.

Un ejemplo de qué hacer una vez que se activa una alerta verdadera positiva es desactivar un feature flag, como se explica más adelante. Para obtener más información sobre las mejores prácticas en alertas, consulta Best Practices for Real-time Machine Learning: Alerting. 

Consejo: El reentrenamiento frecuente de modelos es la única solución sostenible a gran escala

Los sistemas habilitados por ML que interactúan con usuarios siempre serán objetivos de atacantes, especialmente en casos donde existe la posibilidad de obtener ganancias financieras. Al final del día, los atacantes realizan un análisis de costo-beneficio al planificar ataques, y tu trabajo como profesional es aumentar tanto el costo que deje de ser rentable para la mayoría de las personas explotar tu sistema; con la esperanza de que los atacantes eventualmente elijan otros objetivos más fáciles o, mejor aún, abandonen la vida del crimen y se conviertan en miembros respetables de la comunidad. (Claro.)

Sin embargo, intentar combatir cada vector de ataque individualmente con condiciones manuales eventualmente hace que los sistemas a gran escala se vuelvan frágiles y difíciles de mantener, lo que frustra el propósito de permitir que los datos impulsen las decisiones de negocio. Puede convertirse en una especie de «golpear al topo», donde constantemente intentas defender los sistemas contra nuevas explotaciones, pero los atacantes pronto encuentran nuevas formas de eludir las defensas, y el ciclo nunca termina.

Unas pocas barreras de protección y un programa robusto de reentrenamiento son una buena estrategia para defenderse de ataques adversarios a gran escala.

Después de tener algunas barreras de protección para prevenir desastres, probablemente sea mejor aceptar que algunas explotaciones ocurrirán —y luego usarlas como datos de entrenamiento. Reentrenar los modelos con frecuencia te permite incorporar intentos de explotación en el conjunto de entrenamiento para las próximas iteraciones del modelo, haciendo que el modelo aprenda de estos casos y se vuelva más robusto con el tiempo.

Una combinación especialmente útil es automatizar el reentrenamiento de modelos, ya que reduce la probabilidad de errores humanos y libera recursos para mejorar los sistemas.

Consejo: Haz que los ciclos de prueba y error sean más costosos para los atacantes

Los atacantes aprenden a manipular los sistemas habilitados por ML mediante prueba y error; interactúan repetidamente con el sistema para aprender sus «peculiaridades» e idiosincrasias. Hacer que les resulte más difícil aprender aumenta el esfuerzo necesario y, por lo tanto, disminuye el incentivo relativo para participar en ataques.

Hacer que sea más difícil para los posibles atacantes recopilar información sobre tus modelos es una excelente manera de mitigar el riesgo adversarial; pero asegúrate de que los usuarios legítimos no se vean perjudicados en el proceso.

A continuación, enumeramos varios ejemplos de cómo hacer que estos ciclos de aprendizaje sean más costosos; sin embargo, debes tener en cuenta que estas estrategias pueden tener consecuencias no deseadas, afectando la experiencia de los usuarios legítimos. Tu caso de uso específico determinará si la compensación vale la pena.

Ejemplo 1: Limita la frecuencia de interacciones

Puedes limitar la cantidad de veces que los usuarios pueden interactuar con tu sistema en un período de tiempo determinado. Por ejemplo, los clientes que deseen solicitar una póliza de seguro solo pueden hacer un intento por mes. Esto obligaría a los usuarios malintencionados a esperar mucho más tiempo para aprender o a crear múltiples cuentas, entre otras cosas.

También es por eso que los sistemas operativos te obligan a esperar unos segundos antes de intentar nuevamente después de ingresar una contraseña incorrecta. Esto se hace para reducir la posibilidad de ataques de fuerza bruta.

Ejemplo 2: Retrasa la decisión del modelo

Cuanto más cerca en el tiempo esté la entrada del usuario de la respuesta del modelo, más claras serán las relaciones de causalidad y más fácil será para las personas encontrar patrones. Mitiga esto retrasando la retroalimentación del modelo, en lugar de proporcionar una respuesta inmediata.

Por ejemplo, cuando los clientes solicitan una hipoteca a través de una aplicación móvil, elige informarles sobre el resultado después de algunas horas (incluso si el resultado está disponible de inmediato).

Consejo: Es posible que necesites intercambiar rendimiento por robustez

A veces, el impacto potencial de los ataques adversarios es tan alto que la única solución disponible es «simplificar» deliberadamente un modelo reduciendo activamente su sensibilidad, intercambiando algo de rendimiento por una mayor robustez.

La solución más simple (no necesariamente la mejor) para abordar features explotables es simplemente eliminarlas del modelo.

Aquí hay algunas formas de lograr esto:

• Eliminar features vulnerables por completo: La forma más sencilla de eliminar el riesgo es eliminar la feature del modelo.

• Usar proxies en lugar de features reales: A veces podemos reemplazar una feature problemática con un proxy. Es decir, alguna otra pieza de información que tenga una alta correlación con la feature original, pero que no exponga la misma superficie de ataque. Algunos ejemplos incluyen usar variaciones de menor granularidad en lugar de los valores reales, o usar información retrasada (lagged information) obtenida de una fuente alternativa y confiable, en lugar de depender de la información proporcionada por el usuario.

• Reemplazar valores problemáticos de features con valores neutrales: Durante el análisis exploratorio de datos (EDA) y el entrenamiento del modelo, es posible identificar valores neutrales de features, es decir, valores para los cuales el impacto promedio en la salida del modelo es cercano a cero. Puedes usar gráficos de dependencia parcial (PD plots) para identificar qué valores de features son especialmente propensos a explotaciones y luego reemplazarlos durante la inferencia por valores neutrales.

• Aumentar la regularización del modelo: Aplicar regularización, explicada en detalle en la sección a continuación, es otra forma de intercambiar rendimiento por robustez, ya que los modelos regularizados a menudo necesitan sacrificar poder predictivo bruto para obtener una mejor generalización fuera de la muestra (OOS).

Consejo: La regularización sigue siendo tu aliada

La regularización es el proceso de hacer que los modelos sean menos sensibles a los cambios en las features. Esto generalmente se hace para evitar el sobreajuste, mejorar la generalización y extender la vida útil de los modelos de ML, ya que los modelos regularizados tienden a degradarse más lentamente. Pero aumentar la regularización también ayuda a que tu modelo sea más robusto contra ataques adversariales.

Existen al menos dos enfoques para la regularización, teniendo en cuenta la robustez adversarial: los enfoques específicos del modelo (es decir, hiperparámetros disponibles para ajustar en algoritmos de ML) y los enfoques centrados en los datos (por ejemplo, agregar ruido a tu conjunto de datos de entrenamiento para que el modelo sea menos sensible a estas features).

Regularización específica del modelo

Por regularización específica del modelo, nos referimos a técnicas que solo pueden usarse para algoritmos de ML específicos. En la mayoría de los casos, estos son hiperparámetros del modelo que disminuyen la capacidad del modelo y, por lo tanto, su capacidad para sobreajustarse. En la Tabla 1 a continuación, enumeramos algunos ejemplos de hiperparámetros que hemos encontrado particularmente útiles:

Algoritmos	Parámetros
Gradient-boosted Trees	Column Sampling Gamma Learning Rate Maximum Tree Depth Minimum Child Weight Number of Trees
Random Forest	Max Tree Depth Number of Trees
Regresión lineal/logística	L1/L2 Regularization
Redes neuronales	Batch Normalization Dropout Early Stopping L1/L2 Weight Regularization Learning Rate

Regularización centrada en los datos

También existen técnicas de regularización que implican algún tipo de preprocesamiento de datos. La principal ventaja de estas es que pueden compartirse entre múltiples modelos y pueden ser específicas para ciertas features; puedes elegir regularizar solo algunas features, mientras mantienes otras sin cambios. Esto (junto con los hiperparámetros mencionados anteriormente) debería obligar al modelo a confiar menos en estas features, sin eliminarlas por completo.

Una forma sencilla de lograr una regularización centrada en los datos es agregar ruido no correlacionado a tu conjunto de entrenamiento, especialmente a las features vulnerables que deseas hacer más robustas.

También existen formas «específicas del dominio» para restringir los valores de una feature. Por ejemplo, si la «edad» es una feature en tu modelo, puedes imponer un rango válido para los valores durante el preprocesamiento utilizando funciones que las obligan a estar dentro de un rango. Incluso si los atacantes descubren cómo modificar estos valores, el daño estará algo limitado porque estarán dentro del rango predefinido.

Sin embargo, no olvides probar este enfoque para ver si funciona en tu caso.

Consejo: Usa feature flags para manejar ataques rápidamente

Aunque nuestro objetivo final es evitar los ataques adversariales, debemos estar preparados para actuar rápidamente y limitar los daños cuando ocurran. Los feature flags son una forma de manejar ataques de manera ágil.

Los feature flags son condiciones simples de IF/ELSE en el código que controlan si la ejecución sigue un camino u otro, esencialmente activando o desactivando partes del código. Esto se muestra en la Figura 8 a continuación:

Los feature flags generalmente se controlan fuera del flujo normal de CI/CD, lo que permite actualizarlos sin la necesidad de un nuevo despliegue del servicio, lo que puede llevar tiempo y/o fallar. Una estrategia común es almacenar los feature flags como archivos en un sistema de almacenamiento remoto, como S3.

Aquí hay algunos ejemplos de cómo usar feature flags para reaccionar a un ataque adversarial en curso:

• Hacer que los umbrales de decisión sean más estrictos: Si una decisión riesgosa (por ejemplo, otorgar un préstamo basado en una puntuación de riesgo) se toma directamente a partir de una predicción del modelo, puedes hacer que esa decisión sea temporalmente más estricta o conservadora. Por ejemplo, requerir una puntuación de riesgo mucho más baja de lo habitual para aprobar un préstamo.

• Desactivar el flujo de negocio por completo: Dependiendo de la importancia del flujo de negocio afectado por el ataque, es posible que desees desactivarlo por completo, incluso a costa de algunos problemas de experiencia del usuario (UX).

• Reemplazar features manipulables con valores neutrales: Codificar valores neutrales en lugar de usar la información proporcionada por el usuario es otra forma de defenderse de los ataques. Puedes descubrir cuáles son estos valores utilizando gráficos de dependencia parcial (PD plots), como se explica en «Comprender el impacto de valores específicos en features clave».

• Usar una versión de respaldo del modelo, sin features manipulables: Otra alternativa es tener una versión de «respaldo» del modelo que no utilice ninguna feature potencialmente explotable. Usar una versión más simple del modelo puede afectar el rendimiento, pero probablemente sea mejor que enfrentar el impacto de un ataque de frente. Esta estrategia se muestra a continuación como pseudocódigo en el Listado 1.

Los feature flags también son muy útiles en todo tipo de situaciones no relacionadas con el ML. Son un tema interesante por sí mismos.

Consejo: Prefiere codificaciones de baja granularidad para features especialmente sensibles

A veces, simplemente no puedes permitirte eliminar features vulnerables de un modelo. Esto puede ocurrir debido a requisitos regulatorios o porque las features son absolutamente cruciales para el modelo, y eliminarlas lo haría inútil.

Una forma de mantener features potencialmente explotables en un modelo (mientras reduces un poco la superficie de ataque) es disminuir su granularidad. Esto generalmente hace que el modelo sea un poco menos preciso, pero proporciona un nivel de protección contra ataques.

Para features numéricas, esto generalmente significa agrupar valores en intervalos o «bins». Varios paquetes de software admiten la creación de intervalos o «bucketization» como pasos de preprocesamiento en un pipeline de ingeniería de features.

La granularidad de una feature se refiere a cuán precisa es. Cuando existe el riesgo de ataques, puede ser útil favorecer features de baja granularidad (baja resolución) sobre features de alta granularidad (alta resolución).

En el caso de features categóricas, disminuir la granularidad significa reducir su dimensionalidad: ya sea agrupando valores o utilizando métodos como PCA después de la codificación. Para features continuas y/o numéricas, por otro lado, puedes usar intervalos (también llamados «bins») en lugar de valores brutos.

Disminuir la granularidad de las features ayuda de dos maneras:

• Reduce la «sensibilidad» del modelo con respecto a esa feature, actuando en la práctica como una forma de regularización.
• Reduce la posibilidad de que pequeñas perturbaciones en el valor de la feature cambien la puntuación del modelo, siempre que no se crucen las fronteras  de clasificación.

Sin embargo, es importante verificar (con gráficos de dependencia parcial, por ejemplo) que este enfoque funcione en tu escenario específico. En algunos casos, las features modificadas aún presentan una superficie de ataque, especialmente si los usuarios malintencionados pueden inferir dónde están las fronteras de decisión.

Consideraciones sobre el monitoreo

El monitoreo es esencial para detectar ataques adversariales en ML en tiempo real, como se explicó anteriormente. Aquí hay algunos consejos prácticos para mejorar tu monitoreo.

Monitorea percentiles para los valores de las features

La mayoría de las herramientas de monitoreo se centran en monitorear los valores promedio de las features numéricas. Aunque útiles, los promedios ocultan información, especialmente cuando las decisiones se toman utilizando predicciones en los extremos, como es el caso de las predicciones de riesgo.

Para evitar puntos ciegos potenciales, también necesitas monitorear los percentiles de las features, especialmente aquellos relacionados con los extremos (percentiles 1, 10, 90 y 99), para que puedas detectar visualmente desviaciones extrañas que puedan indicar que se están produciendo ataques adversariales.

Monitorea las decisiones de negocio

Aunque los atacantes trabajan intentando influir en las features del modelo, su objetivo final es impactar las decisiones de negocio. Por lo tanto, estas deben monitorearse por separado. Muy a menudo, los ataques son sutiles, pero son lo suficientemente fuertes como para mover la puntuación más allá de la frontera de decisión, afectando las decisiones de negocio. En otras palabras, debes monitorear la distribución de las decisiones impulsadas por el modelo al final del proceso. Esto es lo que llamamos «monitoreo de la capa de decisión» en el Requisito 2.

En el ejemplo que se muestra en la Figura 10, se muestran las tasas de aprobación de reclamos para una compañía de seguros de automóviles ficticia. La decisión de aprobar o denegar un reclamo de seguro se toma utilizando un modelo de ML. El pico en abril de 2024 es motivo de preocupación: podría ser el resultado de atacantes intentando cometer fraude de seguros. Sin embargo, la predicción promedio del modelo que impulsa las decisiones no parece fuera de lo común; sin el monitoreo de la capa de decisión, estaríamos ciegos a un posible ataque.

Monitorea por segmentos

La segmentación se refiere a dividir las predicciones en grupos de interés. La idea principal es que ver métricas agregadas para todas las instancias como un grupo combinado oculta detalles importantes: dado que el tamaño de la muestra es más grande, las métricas tienden a ser más suaves, y es más difícil detectar problemas que solo afectan a un subconjunto de la población total, especialmente si esos son menos comunes.

Ejemplos de segmentos incluyen:

• Tipos de compras con tarjeta de crédito: compras físicas, compras sin contacto, compras en línea.
• Tipos de clientes: ingresos bajos, ingresos medios, ingresos altos.
• Visitantes en un sitio web: aquellos que usan navegadores, teléfonos móviles, tabletas, etc.

Ver métricas por segmentos también es útil para detectar ataques adversariales, ya que pueden estar dirigidos a subgrupos específicos, en lugar de a todo el espacio de instancias en su conjunto. La Figura 11 a continuación muestra cómo visualizar métricas por segmentos permite detectar problemas que de otra manera pasarían desapercibidos si solo se observan los valores agregados a nivel global.

Atributos de entrada vs. feature

Muchos pipelines de modelos incluyen ingeniería de features o preprocesamiento sobre las entradas brutas proporcionadas por el usuario antes de usarlas en el algoritmo de aprendizaje. Puede ser difícil detectar ataques dirigidos si solo se monitorean las features, porque puede haber múltiples pasos de procesamiento antes de que un atributo de entrada se convierta en una feature.

Debes tener activos de monitoreo separados para los valores de los atributos de entrada, además de monitorear las features y las predicciones a lo largo del tiempo.

Modelos de ML en tiempo real efectivos y resilientes

Los modelos de ML en tiempo real son poderosos pero vulnerables a ataques adversariales, donde actores maliciosos manipulan features para influir en los resultados. Para proteger tus modelos, enfócate en comprender la importancia de las features con herramientas como SHAP y gráficos de dependencia parcial (Partial Dependence Plots), y configura un monitoreo activo para detectar patrones inusuales. Usa alertas en tiempo real basadas en métricas de negocio para detectar ataques temprano.

El reentrenamiento frecuente de modelos ayuda a que tu sistema aprenda de los intentos de ataques, mientras que estrategias como limitar interacciones, retrasar decisiones o agregar ruido hacen que la explotación sea más difícil. En algunos casos, intercambiar rendimiento por robustez —eliminando features vulnerables o aumentando la regularización— puede reducir significativamente los riesgos. Herramientas como los feature flags te permiten responder rápidamente, y reducir la granularidad de las features minimiza la superficie de ataque.

Al combinar estas estrategias, puedes construir modelos de ML en tiempo real que sean tanto efectivos como resilientes. El objetivo no es detener todos los ataques, sino hacer que sean tan costosos que los atacantes desistan.

Si deseas fortalecer tus sistemas de ML, sigue leyendo nuestro blog para obtener más hallazgos. Y si te apasiona construir soluciones de ML de vanguardia, ¡estamos contratando! Únete a nosotros para construir el Futuro Morado.