En la primavera de 2024, un gerente de operaciones de un 3PL a las afueras de Dallas firmó un contrato para un sistema de inventario con IA basado en drones. La demostración había sido espectacular: un dron deslizándose sobre las estanterías, informes de variaciones generados automáticamente. Firmó una suscripción anual. Entonces llegó la realidad. El almacén funcionaba con un WMS de una década de antigüedad, y la interfaz de datos personalizada que necesitaba TI ya estaba en cola con dos trimestres de antelación. La "precisión de reconocimiento" del contrato se había medido con el propio conjunto de pruebas del proveedor — nadie la había probado en una zona mixta de palets y cajas sueltas. Un año completo de cuotas de suscripción se pagó antes de que el sistema se conectara siquiera a una sola fuente de datos.
La tecnología estaba bien. El responsable, no.
He visto esta película desde el otro lado también. Un proyecto liderado por TI, un sistema de IA de visión para la inspección en recepción en un almacén mediano. El director de TI hizo todo según el manual: convocó a tres proveedores, comparó fichas técnicas sobre precisión, latencia y protocolos de API, eligió el que tenía mejores cifras de laboratorio. Lo que nunca hizo fue recorrer el muelle de recepción con el equipo. En un almacén real, la iluminación de las estanterías produce reflejos, las etiquetas se pegan torcidas y el film retráctil brilla. Nada de eso aparece en una ficha técnica. En la primera semana, los falsos positivos duplicaron el tiempo de verificación del equipo. El jefe de recepción me dijo sin rodeos que la pistola escáner era más rápida. En un par de meses, el turno de noche había dejado de encender el sistema.
Esta es la verdad incómoda sobre la IA en el almacén: lo difícil nunca fue el modelo. Son tres preguntas — de dónde vienen los datos, quién define lo que cuenta como "correcto" y quién responde por el resultado. TI no puede responder las tres sola. Operaciones no puede responder las tres sola. Un informe de RAND publicado en 2024, "The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed", encontró que más del 80 por ciento de los proyectos de IA no entregan el valor esperado, y las raíces suelen estar en la organización y los datos, no en los algoritmos.
Incluso Amazon, que puede gastar más que nadie, se niega a dejar que el algoritmo cierre el ciclo por sí solo. En junio de 2024 la compañía anunció el Project P.I. — "private investigator" — un sistema que combina IA generativa y visión por computadora en túneles de imágenes en varios centros de fulfillment de Norteamérica para detectar productos dañados y colores o tallas incorrectas antes del despacho. El detalle que importa: los artículos que el sistema marca son revisados por asociados de Amazon, que deciden si el producto se descuenta, se dona o sigue su curso. Los humanos toman la decisión final. Si Amazon no deja que la máquina gestione el almacén por sí sola, un 3PL de 50 personas ciertamente no debería intentarlo.
La trampa liderada por TI y la trampa liderada por operaciones son la misma trampa
Los dos modos de fracaso parecen opuestos, pero fracasan por la misma razón: un lado del edificio es dueño de una decisión que requiere a ambos lados.
Cuando TI lo lleva sola, se obtiene un juguete tecnológico. La demostración recibe aplausos; la planta lo rodea. TI evalúa lo que puede medir — precisión con datos limpios, disponibilidad, esfuerzo de integración — y subestima lo que decide la adopción: los reflejos en el tercer nivel de una estantería, un proceso que el equipo realmente siga a las 2 a.m., quién reentrena el modelo cuando el mix de productos cambia en el cuarto trimestre.
Cuando operaciones lo lleva sola, se obtiene una orden de compra en busca de un proyecto. Operaciones puede describir el dolor a la perfección y no puede evaluar la ruta de entrega. El vendedor del proveedor cobra por conseguir la firma, no por hacer que el sistema funcione — y el comprador liderado por operaciones es la persona más fácil de deslumbrar en todo el edificio con una demostración que jamás sobrevivirá al contacto con un WMS heredado.
La solución que ahora recomiendo a cada cliente es un modelo de doble liderazgo: un líder de negocio y un líder de tecnología, pares, compartiendo el resultado. Suena como un cliché hasta que lo escribes. El líder de negocio es dueño de tres cosas: definir el problema (conteos cíclicos lentos o variación alta — elige uno), comprometer las personas y las horas para el trabajo de datos, y aprobar la efectividad. El líder de tecnología es dueño de tres cosas distintas: selección de proveedor y arquitectura, integración con el WMS y el hardware, y seguridad de los datos. La zona intermedia — la traducción — pertenece a un rol de analista de negocio que no se puede omitir.
Ese analista de negocio no es un empleado de documentación. Es alguien que habla ambos idiomas: puede pasar media jornada con el equipo de conteo cíclico, volver, y explicarle al proveedor en términos técnicos que el tercer nivel de una estantería refleja la luz; puede escuchar al proveedor decir que el modelo necesita miles de imágenes etiquetadas y traducirlo a "el equipo de conteo sacrifica tres días". Asciende a un supervisor sénior a ese rol o contrata un asesor externo — pero no ejecutes el proyecto sin uno. Sin un traductor, las reuniones de TI y operaciones son dos monólogos. O TI cede ante una demanda de negocio irrazonable, u operaciones termina forzada a usar una herramienta que no le gusta a nadie.
Cómo hacer el piloto sin quemar un año
Equipa el piloto de forma ligera pero fija: un analista de negocio, a tiempo completo en el proyecto; un contraparte de TI, a tiempo parcial está bien, pero tiene que ser la misma persona cada semana; dos operadores de planta, fijos durante todo el proyecto, sin rotación — la forma más rápida de corromper un piloto es cambiar constantemente a quién se mide; y un especialista de implementación del proveedor. Cadencia: una reunión de treinta minutos cada semana cubriendo solo tres cosas — lo que mostraron los datos, lo que está bloqueado, lo que se prueba después — y una revisión mensual de una hora sobre la tendencia. Mi regla práctica: un piloto debe llegar a un veredicto en seis a ocho semanas. Seguir o no. Los pilotos que se arrastran más de tres meses casi siempre mueren en silencio, con el dinero y la buena voluntad perdidos.
La aceptación es donde me pongo estricto. Una página, dos líneas de firma. El líder de negocio firma por la efectividad: dos semanas consecutivas en el entorno real, en turnos reales, alcanzando las cifras de tasa de fallos y falsas alarmas que se escribieron antes de empezar el proyecto. El líder de tecnología firma por la parte técnica: interfaces estables, datos fluyendo de vuelta al WMS, controles de acceso en su lugar. Si falta una firma, el proyecto no está terminado. Y los criterios de aceptación deben existir antes del arranque — criterios escritos el día de la aceptación son criterios que el proveedor siempre pasará.
El almacén de una o dos personas también puede hacerlo
Los operadores pequeños leen todo esto y piensan: apenas tenemos dos gerentes, ¿de dónde sacamos doble liderazgo? La respuesta es que cuanto más pequeño eres, más ligera — pero también más literal — tiene que ser la estructura.
Redúcelo a un movimiento: asigna el rol de traductor a una persona con nombre y apellido. Elige al supervisor de almacén menos hostil a los sistemas, o a la persona de TI que realmente camina la planta. Dale un título durante el piloto — contraparte de negocio para este proyecto de IA — y una hora protegida al día. Esa hora importa más que la licencia del software, porque nueve de cada diez veces, los proyectos de IA mueren por "nadie en la planta cooperó", no por "el modelo estaba mal".
En la selección, resiste el paquete. Empieza con exactamente un punto de dolor: variación de conteos, búsqueda de ubicaciones de almacenamiento o verificación de salida. Cuando el proveedor pregunte si quieres los módulos extra, di que no. Tres cláusulas van en el contrato: pago ligado a los resultados del piloto con salida incondicional si el piloto falla; el trabajo de interfaz de datos y su cronograma adjuntos por escrito; capacitación impartida a los operadores de planta, no solo a sus supervisores. Y tres pruebas duras de aceptación: dos semanas en el entorno en vivo, las cifras acordadas antes del arranque efectivamente alcanzadas, y — la que más importa — los operadores encienden el sistema por iniciativa propia. El sistema más preciso del mundo no vale nada si el equipo no lo arranca.
Este es el ejercicio que haría mañana. Toma el proyecto de IA que estás ejecutando o planeando, y escribe una página: qué problema resuelve, cuáles son los criterios de aceptación, y los nombres del líder de negocio y del líder de tecnología — con dos líneas de firma en blanco al final. Si no puedes escribir esa página, o si ambas líneas solo pueden llevar el mismo nombre, estás viendo la misma configuración que el equipo cubierto de polvo de mi historia inicial. Mátalo temprano. Es mucho más digno que quemar primero el presupuesto.
Traducido del inglés. En caso de discrepancia, prevalece la versión en inglés.
