El otoño pasado asesoraba a un 3PL en el Inland Empire — un almacén de unos 120,000 pies cuadrados — que acababa de implementar un modelo de IA para la previsión de reposición. El acta de aceptación estaba firmada. El equipo del proveedor se fue en la semana tres. El día 96, el gerente del almacén me llamó: "Lao Mi, creo que el sistema se ha roto. Sus sugerencias de reposición están cada vez más locas."
Le hice tres preguntas. ¿Cuál fue la precisión de previsión del modelo la semana pasada? No lo sabía. ¿Adónde van los correos de alerta? Fue a comprobarlo — y descubrió que seguían llegando al buzón que el equipo de proyecto del proveedor había configurado. Ese equipo se había disuelto hacía dos meses. Las alertas caían en una bandeja de entrada que nadie abría. Tercera pregunta: ¿quién fijó los umbrales de deriva? Silencio al otro lado de la línea.
Esta no es una historia aislada. He visto varios proyectos de IA morir igual en los últimos años — no durante la selección, no durante el desarrollo, sino en los tres meses posteriores a la puesta en marcha. Cuando aceptas un equipo, un montacargas no cambia de carril solo. La IA es diferente. Come datos nuevos cada día, y cuando los datos cambian, el modelo cambia con ellos. Sin nadie vigilando, el "sistema de IA" que posees tres meses después ya no es el que firmaste.
El día de la puesta en marcha es el día más arriesgado del proyecto
He aquí una idea contraintuitiva: para un proyecto de IA, la firma de aceptación marca el comienzo, no el final.
Las pruebas de aceptación ocurren en condiciones estáticas. Los datos fueron limpiados por el proveedor de antemano, el conjunto de prueba fue curado y la mezcla estacional fue elegida a mano. Por supuesto que el proveedor quiere que las métricas de aceptación se vean bien — el pago final está en juego. Eso no es deshonestidad; es naturaleza humana.
Pero una vez que los datos reales empiezan a fluir, todo cambia. Nuevos clientes traen nuevos patrones de pedido. La mezcla de SKU cambia. Las especificaciones de empaque se sustituyen. Las temporadas pico y valle se alternan. Estos son los "datos sucios" que el modelo nunca vio durante el entrenamiento. Vi un almacén pasar del 92% de precisión de previsión en la aceptación al 78% dos meses después. La causa raíz era casi cómica: los datos de entrenamiento no tenían combinaciones de SKU de la temporada pico del Q4, así que el modelo empezó a adivinar a lo loco en cuanto llegó la temporada pico.
Mi veredicto es tajante: los criterios de aceptación deben incluir una cláusula de repetición de pruebas a los 90 días. Firma dos veces — una en la puesta en marcha para confirmar que el sistema está funcionando, y otra el día 90 para confirmar que el modelo sigue aguantando frente a datos reales. Si falla la segunda prueba, el pago final queda sobre la mesa y el proveedor regresa a afinarlo. Una cláusula en el contrato supera a diez métricas extra el día de la aceptación.
Muchos compradores temen pedir esto. Les preocupa que el proveedor lo tome como desconfianza. Yo lo veo al revés: un proveedor dispuesto a firmar esa cláusula es uno que realmente cree en su modelo.
Los modelos no mueren de golpe. Se vuelven tontos poco a poco.
Esta es la mayor diferencia entre la operación de IA y la operación tradicional de TI. La caída de un servidor es repentina — suena la alarma y todo el mundo lo sabe. La deriva del modelo es una enfermedad crónica. Un poco peor hoy, un poco peor mañana, y tres meses después te das cuenta de que se ha vuelto inútil en silencio.
La deriva tiene dos sabores, en términos sencillos. Primero, los datos cambiaron: solías enviar 8,000 pedidos al día, ahora son 12,000. El cliente A solía ser el 60% del volumen; ahora domina el cliente B. El modelo aprendió los patrones de los datos viejos, y los datos nuevos no los siguen. Segundo, las relaciones cambiaron: "los fines de semana hay mucho trabajo" solía ser cierto, luego los clientes cambiaron sus hábitos de pedido y los fines de semana se quedaron tranquilos. Los datos en sí se ven igual, pero lo que significan se ha movido.
Lo aterrador no es la deriva en sí — es que nadie está mirando. En ese almacén del Inland Empire, el sistema llevaba semanas enviando alertas. Las métricas de deriva ya estaban por encima del umbral. Pero las alertas iban a una bandeja que nadie leía, lo que equivale a no tener alertas. Ese es el vacío operativo del que hablo: el sistema está hablando y nadie escucha.
¿Cómo llenarlo? La tabla de responsabilidades debe definirse antes de la aceptación, y debe nombrar personas reales — "el cliente es responsable" no cuenta. Recomiendo tres capas.
Operaciones del almacén vigila las métricas de negocio a diario. Nadie siente la calidad de la previsión más rápido que operaciones — cuando las sugerencias de reposición no tienen sentido, los recolectores se quejan primero. Denles una regla simple: si las cantidades sugeridas se desvían de la realidad más allá de una proporción fija durante tres días seguidos, escalar. No hace falta conocimiento de algoritmos. Solo leer los números.
TI — o el proveedor — vigila las métricas del modelo semanalmente. Puntuaciones de deriva, distribuciones de características, confianza de predicción. Esto necesita a alguien que sepa lo que está mirando. Si no tienes esa persona en casa, compra soporte remoto del modelo al proveedor en el contrato; facturación trimestral está bien. No escatimes aquí. Si lo omites, los cientos de miles que ya gastaste pueden irse por el desagüe.
La dirección revisa la tendencia mensualmente. ¿La curva de precisión sube o baja? ¿Cuánto costó el reentrenamiento y valió la pena? Treinta minutos bastan, pero la reunión tiene que ocurrir. Si no, descubres en la revisión trimestral que el modelo lleva tres meses roto. Demasiado tarde.
¿Quién fija los umbrales de deriva? Mi respuesta: el proveedor propone, el comprador decide. El proveedor conoce el modelo y lo que cuenta como fluctuación normal. El comprador conoce el negocio y qué nivel de error es inaceptable. Fíjenlos juntos, escríbanlos en el POE (procedimiento operativo estándar) y péguenlo en la pared.
Un traspaso que no está en el contrato no ocurrió
Este es el pozo más profundo en el que he caído. En un almacén, un proyecto de inspección de calidad con IA, el contrato decía "el proveedor proporcionará capacitación." Antes de la aceptación, el proveedor sí dio capacitación — una presentación de dos horas. Tres meses después el modelo se portó mal, y el ingeniero de operaciones ni siquiera sabía dónde vivía el pipeline de características. De qué tabla venían los datos, en qué servidor estaban los archivos del modelo — tres preguntas, cero respuestas. Llamó al proveedor. El equipo de proyecto había desaparecido. Un representante de soporte dijo que podían "abrir un ticket de soporte de pago."
Así que ahora hago que los compradores revisen una lista de traspaso punto por punto antes de firmar la aceptación. Cuatro puntos. Falta uno, no firmes.
Primero, documentación del modelo. Cuál es la lista de características, qué versión de los datos de entrenamiento se usó, en qué supuestos se basó el modelado — cosas como "supone que el número de SKU se mantiene constante" o "supone que la estructura de pedidos es estable." Esos supuestos son tus futuras líneas de advertencia de deriva. En el momento en que un supuesto se rompe, el modelo necesita reentrenamiento. Los documentos no necesitan ser elegantes. Necesitan ser legibles.
Segundo, configuración de alertas. Quién recibe las alertas, quién está en copia, con qué frecuencia se revisan, quién escala. Escribe cada dirección de correo, y envía una alerta de prueba el día de la aceptación para confirmar que llega. No te rías — he visto un proyecto donde la dirección de alerta estaba mal escrita y nadie lo descubrió hasta después de la puesta en marcha.
Tercero, el proceso de reentrenamiento. Quién dispara el reentrenamiento, cuáles son las condiciones de disparo, quién lo ejecuta y quién paga. El reentrenamiento no es gratis — preparación de datos, cómputo y validación cuestan dinero. Si no lo acuerdas de antemano, ambas partes empiezan a señalarse cuando algo se rompe. Vi una disputa arrastrarse durante cuatro meses. El modelo simplemente estuvo pudriéndose ahí durante cuatro meses.
Cuarto, el plan de reversión. Cuando el modelo se porta mal, ¿cómo vuelves al motor de reglas antiguo con un solo cambio? ¿Dónde está el interruptor, quién tiene permiso para accionarlo y cómo sigue operando el negocio después del cambio? Este es el que más se omite, pero cuando las cosas salen mal, es el que te salva.
El contrato necesita dos cláusulas más: soporte remoto del proveedor durante 6 a 12 meses después de que el equipo se vaya, con tiempos de respuesta por escrito; y propiedad de los datos — los datos de entrenamiento, los archivos del modelo, el pipeline de características — el comprador recibe una copia completa de todo. El proveedor puede irse. Los activos se quedan.
Esta es la conclusión. Un proyecto de IA se diferencia de comprar un equipo en algo fundamental: el equipo es una entrega única, pero la IA es algo que sigue evolucionando. Lo que aceptas no es una máquina. Es algo vivo que necesita alimentación continua. Si el contrato no dice quién lo alimenta, es solo cuestión de tiempo antes de que muera de hambre.
Una pregunta para dejarte: si tu proyecto de IA sale en vivo mañana, ¿puedes nombrar a la bandeja de entrada de quién van los correos de alerta el día 90 — y quién es responsable de abrirlos? Si no, no firmes aún el formulario de aceptación.
Traducido del inglés. En caso de discrepancia, prevalece la versión en inglés.
