Shadow, canary, A/B y bandits: cómo desplegar modelos de ML con seguridad

Imagina que un equipo lleva meses trabajando en un nuevo modelo de machine learning y la evaluación offline pinta genial: mejor precision, mejor recall, menos falsos positivos y una latencia aceptable. La pregunta natural es si puede pasar a producción. Probablemente sí. Pero luego viene otra más importante: ¿debería recibir el 100 % del tráfico de producción desde el primer momento? Normalmente no. Un modelo que brilla con datos históricos puede comportarse de forma muy distinta cuando se encuentra con clientes reales, tráfico real, entradas inesperadas, fallos de infraestructura y distribuciones de datos que cambian.

Por eso los equipos de ML en producción recurren a cuatro estrategias, cada una con su función:

• El despliegue en sombra (shadow) permite observar un modelo nuevo sin actuar según sus respuestas.
• Un lanzamiento canary lo expone a una pequeña parte del tráfico real.
• Un test A/B lo compara directamente con el anterior.
• Un bandit multibrazo desplaza el tráfico hacia lo que mejor funciona a medida que llegan los resultados.

El ejemplo de referencia: detección de fraude

Una plataforma financiera procesa 1 millón de transacciones al día, y cada una pasa por un modelo de detección de fraude. El modelo actual en producción es V1. El equipo de ML ha creado V2.

Customer Transaction
        ↓
    Payment API
        ↓
  Feature Service
        ↓
 Fraud Model V1
        ↓
  Fraud Risk Score
        ↓
 ┌──────┼────────┐
 ↓      ↓        ↓
Approve Review  Decline

Según las cifras offline, V2 es mejor. Aun así, ponerlo de golpe en el millón de transacciones añade un riesgo innecesario, porque cuanto mayor es el despliegue inmediato, mayor es el posible radio de impacto. Así que V2 se introduce poco a poco.

Despliegue en sombra: observar antes de actuar

El despliegue en sombra es una de las formas más seguras de probar un modelo nuevo con tráfico de producción. El tráfico real llega al modelo nuevo, sus predicciones se registran y los clientes no notan nada. La arquitectura:

Production Transaction
                         ↓
               ┌─────────┴─────────┐
               ↓                   ↓
          🟢 Model V1         🔵 Model V2
           Production             Shadow
               ↓                   ↓
       Actual Decision        Log Prediction
               ↓
            Customer

Toma una transacción como esta:

Amount: $4,800
Location: Dallas
Device: New device
Transactions last 5 min: 4
Merchant risk: Medium

V1 le asigna una probabilidad de fraude de 0,31 y la aprueba. V2 le asigna 0,82 y la mandaría a revisión. Como V2 funciona en modo sombra, su respuesta no afecta al cliente: solo se registra. Con el tiempo, los logs permiten comparar:

• Diferencias en las predicciones
• Precision y recall
• Falsos positivos y falsos negativos
• Latencia de inferencia
• Disponibilidad de las features
• Deriva de datos
• Consumo de recursos

El modo sombra responde a cómo se comportaría V2 en producción sin cederle el control. Shadow significa ver antes de cambiar.

Lanzamiento canary: empezar en pequeño y crecer con confianza

Supongamos que V2 se ve sano tras la prueba en sombra. Ahora debe tomar decisiones reales, pero el paso no va del 0 % al 100 %. Empieza con una porción mínima del tráfico:

Production Traffic
                 ↓
          ┌──────┴──────┐
          ↓             ↓
        99%             1%
          ↓             ↓
     🟢 Model V1   🟡 Model V2

De un millón de transacciones diarias, unas 990.000 siguen yendo a V1 y unas 10.000 a V2, y ahora las decisiones de V2 cuentan. Mientras las métricas aguanten, la proporción sube por etapas (1 %, 5 %, 10 %, 25 %, 50 % y luego 100 %). En cada etapa conviene seguir el dinero perdido por fraude, los clientes legítimos rechazados, la tasa de aprobación, la latencia, los errores y timeouts, cuántos casos acaban en revisión manual y la carga de la infraestructura.

Ahora supongamos que los rechazos falsos se disparan cuando V2 llega al 10 %:

V2 reaches 10%
       ↓
🚨 Guardrail triggered
       ↓
Stop rollout
       ↓
Rollback
       ↓
100% → V1

Un canary responde a si V2 es lo bastante seguro para lanzarlo de forma progresiva. Canary significa controlar el radio de impacto.

Tests A/B: que decidan los datos

Cuando los dos modelos funcionan de forma estable, la pregunta cambia. Ya no se trata solo de si V2 es seguro, sino de si de verdad produce mejores resultados de negocio. El tráfico elegible se reparte al azar:

Eligible Traffic
                    ↓
            Random Assignment
              ↙           ↘
            50%           50%
             ↓             ↓
        🔵 Model V1   🟣 Model V2
          Group A       Group B

Después se comparan los resultados. Los valores de abajo son solo ilustrativos.

Métrica	Modelo V1	Modelo V2
Detección de fraude	92,0 %	95,1 %
Rechazos falsos	1,8 %	1,2 %
Latencia media	42 ms	51 ms
Revisión manual	4,5 %	3,7 %

Esa tabla esconde una lección: el modelo más preciso no es automáticamente el mejor en producción. V2 podría detectar mejor el fraude y a la vez aumentar notablemente la latencia, o subir el recall y mandar a demasiados clientes legítimos a revisión manual. Lo que hay que valorar es el resultado de negocio en conjunto.

No confundas los dos métodos. Un canary pregunta si V2 puede lanzarse con seguridad. Un test A/B pregunta si V2 es realmente mejor que V1. En este último, deja que los datos elijan al ganador.

Bandits multibrazo: aprender mientras se optimiza

Un test A/B suele mantener fijo el reparto del tráfico durante toda su duración. Los bandits son distintos porque el reparto puede cambiar a medida que el sistema aprende. Imagina tres modelos de recomendación que empiezan con un reparto equitativo:

Model A → 33%
Model B → 33%
Model C → 34%

Tras recoger resultados:

A → 3.0% conversion
B → 4.2% conversion 🏆
C → 2.7% conversion

El sistema puede entonces desplazar el tráfico poco a poco:

Model A → 20%
Model B → 70% 🚀
Model C → 10%

¿Por qué no mandarlo todo a B? Porque el sistema todavía tiene que aprender. Esa es la tensión entre la exploración, probar alternativas para averiguar si existe algo mejor, y la explotación, enviar más tráfico a la opción que ahora mismo da la mejor recompensa.

Explore
   ↓
Learn
   ↓
Update Expected Reward
   ↓
Exploit
   ↓
Continue Learning

Entre los algoritmos habituales están epsilon-greedy, UCB y el muestreo de Thompson. Los bandits encajan en recomendaciones, ranking de búsqueda, publicidad, selección de ofertas, personalización de contenido y optimización de notificaciones. En resumen: aprender, adaptarse, optimizar.

¿Bandits para decisiones de fraude?

Aquí hay que tener cuidado. Cuando un recomendador prueba una sugerencia más floja, en el peor de los casos el cliente la ignora. Cuando un sistema antifraude prueba una política de decisión más floja, puede aprobarse una transacción fraudulenta. Explorar cuesta muy distinto en cada caso, así que la estrategia de despliegue tiene que tener en cuenta el riesgo de negocio, no solo la calidad del modelo. Los sistemas de alto impacto necesitan salvaguardas y reglas de elegibilidad más estrictas, revisión humana, controles de cumplimiento normativo, buena observabilidad y una forma de revertir.

Todo junto

Un camino maduro para el ML en producción puede tener este aspecto:

🧠 Train Model V2
        ↓
📊 Offline Evaluation
        ↓
🔵 Shadow Deployment
        ↓
🔍 Compare V1 vs V2
        ↓
🟢 Canary Release
        ↓
   1% → 5% → 10%
        ↓
🟣 A/B Testing
        ↓
📈 Validate Business KPIs
        ↓
🚀 Full Rollout
        ↓
👀 Continuous Monitoring
        ↓
🔄 Retraining / Model V3

Para problemas de optimización adecuados, continúa así:

Continuous Monitoring
        ↓
🟠 Multi-Armed Bandit
        ↓
Learn + Optimize

Cuando algo sale mal

Imagina que V2 llega al 25 % del tráfico y la monitorización indica que la latencia ha subido un 45 %, los timeouts se han triplicado y los rechazos falsos han subido un 2,1 %. El sistema de producción debería reaccionar por sí solo:

🚨 Threshold Exceeded
        ↓
🛑 Stop Rollout
        ↓
↩️ Route Traffic to V1
        ↓
🔔 Alert ML / SRE Teams
        ↓
🔍 Investigate

Por eso la observabilidad forma parte del despliegue de ML desde el principio y no es algo que se añade después. Merece la pena seguir tres grupos de métricas:

• Métricas del modelo: qué tan buenas son las predicciones (precision, recall, F1, AUC, ambos tipos de error) y la deriva de los datos
• Métricas del sistema: cómo aguanta el servicio, con latencia, throughput, errores, timeouts, CPU, memoria y disponibilidad
• Métricas de negocio: cuánto vale el resultado (conversión, ingresos, pérdidas por fraude, clientes rechazados, revisiones manuales, engagement)

Un modelo puede ser excelente en lo estadístico y aun así fracasar en lo operativo o en lo comercial.

Las mismas ideas para recomendaciones en e-commerce

En un entorno de menor riesgo, las estrategias cambian de forma:

• Shadow: V2 genera recomendaciones, pero los clientes siguen viendo las de V1.
• Canary: un 5 % de los clientes empieza a ver las recomendaciones de V2.
• Test A/B: un 50 % recibe V1 y otro 50 % V2, y comparas CTR, conversión, ticket medio, ingresos por sesión y retención.
• Bandit: el tráfico se desplaza hacia las estrategias que obtienen mejor recompensa, mientras sigue una exploración controlada.

Las cuatro estrategias, lado a lado

Estrategia	Pregunta principal	Impacto en el cliente	Tráfico
Shadow	¿Cómo se comportará V2?	No	Replicado
Canary	¿Es seguro V2?	Sí	Aumenta gradualmente
A/B	¿Es mejor V2?	Sí	Reparto fijo del experimento
Bandit	¿Qué opción debería recibir más tráfico ahora?	Sí	Dinámico

Un truco rápido para recordarlo: shadow observa, canary lanza con cuidado, A/B compara y un bandit no deja de reoptimizar.

Gestión del riesgo

Cuando se habla de IA y ML, lo habitual es centrarse en algoritmos, features, entrenamiento, precisión y GPU. La producción añade otra dimensión: la gestión del riesgo. La verdadera pregunta va más allá de si un modelo predice bien. Es si puedes introducirlo con seguridad, vigilarlo, medir lo que hace, mantener pequeño el radio de impacto, detectar fallos y revertirlo. Una plataforma de ML en producción que funciona es más que un modelo detrás de una API. Combina modelos, datos, infraestructura, experimentación, observabilidad, salvaguardas, reversión y métricas de negocio. El entrenamiento deja listo un modelo, y la ingeniería de producción decide si merece confianza.