La conclusión por adelantado: el fracaso de un proyecto de IA es un problema organizativo, no tecnológico
En tres años y siete proyectos de IA en almacenes — verificación por visión, previsión de demanda, despacho de AGV — ninguno murió por razones técnicas. Seis murieron por razones organizativas: el CEO lo aprobó pero la planta no lo usó, nadie era dueño de los datos, los KPI se peleaban entre sí, la formación fue un trámite y un piloto no pudo escalar.
Por eso este artículo no trata de tecnología. Cinco trampas, cada una con una historia que viví y una lista de verificación que puedes copiar tal cual. Cuando un proyecto de IA fracasa, audita la organización antes de auditar la tecnología.
Trampa 1: El mandato del CEO que nadie en la planta sigue
Lo he visto tres veces.
Otoño de 2024. Un 3PL de ropa. El CEO vio una demo de verificación por visión en una cumbre y firmó en el acto: más de 40 cámaras en 28 estaciones de empaque. Primera semana: 11% de pedidos marcados. Tercera semana: los operarios cubrían las cámaras con cartón — cada alerta implicaba una revisión de 2 minutos, más o menos una hora extra no pagada por persona al día en pico.
Más de la mitad de las cámaras estaban cubiertas antes de que lo detectáramos. El CEO dijo "que las usen"; los supervisores dijeron "ven tú a hacerlo". Dos semanas de estancamiento — proyecto muerto.
Así es exactamente como lo trajimos de vuelta:
- Convierte los 2 minutos extra en dinero. Un pedido mal enviado cuesta entre 5 y 7 dólares arreglarlo (devolución, servicio, reenvío); la revisión de 2 minutos cuesta menos de 0,30 dólares en salarios. Pusimos esa comparación en cada estación.
- Cambia el salario, no a las personas. Los operarios cobraban a destajo. Añadimos el cumplimiento de verificación a la fórmula: las cuadrillas con alto cumplimiento ganaban un 8% más por pieza. El cartón desapareció al día siguiente.
- Pon a la planta en la lista de verificación del lanzamiento. Antes del relanzamiento, tres veteranos procesaron 200 pedidos a mano, etiquetando cada falso positivo. La tasa cayó del 11% a menos del 4% — entonces firmaron.
Lista de prevención: antes del lanzamiento, responde tres preguntas — ① ¿le cuesta tiempo a la planta o se lo ahorra? ② Si le cuesta tiempo, ¿se compensa en dólares? ③ ¿La planta lo ha tocado antes del lanzamiento? Si queda una sin responder — no lanzas.
Trampa 2: Datos sin dueño, modelos alimentados con basura
A principios de 2025. Un distribuidor de alimentos quería que la IA de previsión bajara las roturas de stock del 6% a menos del 3%. Los datos parecían completos: tres años de ventas, un calendario de promociones, movimientos de inventario.
Dos meses después, el modelo se estancó. La auditoría: cuatro meses de ventas de 2023 retro-cargadas a mano, el calendario de promociones sin las ofertas regionales (estaban en la app de chat del gerente de ventas), el 12% de los ajustes sin códigos de motivo.
Peor aún — nadie era dueño de los datos. TI culpaba al negocio, el negocio culpaba al sistema, el CEO nos culpaba a nosotros. Seis semanas de echarse culpas, luego pausa. De todas las causas de fracaso de un proyecto de IA, los datos huérfanos son la más cara — siempre aparecen a mitad del proyecto, cuando ya se gastó la mayor parte del presupuesto.
Ahora cada contrato que escribo incluye una cláusula de propiedad de datos:
- Punto uno de la lista de lanzamiento: nombra al dueño de los datos. No el departamento de TI — una persona concreta del negocio, con su nombre en el documento del proyecto, con una línea de KPI: integridad de campos clave ≥ 98%.
- Primero audita, después modela. La primera semana es solo auditoría: muestrea tres meses, revisa cada campo por tasas de faltantes y consistencia. Los campos con más del 15% de faltantes se retro-cargan o se eliminan.
- Presupuesta la limpieza como su propia partida. Regla práctica: la limpieza es entre el 30% y el 40% del esfuerzo total de un proyecto de IA. Si no es una línea aparte en el presupuesto, discutirás por ella después.
Trampa 3: Los KPI en conflicto mandan las recomendaciones de la IA a la basura
La trampa más sigilosa — todo parece estar bien en la superficie.
- Un 3PL de autopartes desplegó reposición con IA: recomendaciones diarias a las 8 AM, 82% de precisión en pruebas. Un mes después, la adopción era del 23% — el responsable decía que las cantidades "no cuadraban con mi experiencia".
Al responsable lo medían por tasa de roturas; a compras por rotación de inventario. La IA recomendaba más stock de seguridad — bajaron las roturas, la rotación sufrió. Atrapado en medio, el responsable ignoró la mayoría de las recomendaciones. Los KPI miden resultados, no "si escuchaste a la IA".
Lo he visto tres veces, mismo guion: la IA optimiza para el objetivo global, pero el KPI de cada persona es un objetivo local. Lo que es óptimo globalmente parece sabotaje localmente.
La única solución: alinear los KPI antes del lanzamiento.
- Dibuja un mapa de conflictos de KPI. Lista cada rol que toca la IA; marca si cada recomendación ayuda o perjudica su KPI. Los conflictos se vuelven obvios de inmediato.
- Dale un nombre formal a la "tasa de adopción de IA". Añádela a la revisión trimestral del responsable: adopción ≥ 70%, rechazos razonados excluidos, peso del 10%. Suficiente para poner "escuchar a la IA" en el lenguaje de la revisión.
- Establece un periodo de protección de 30 días. Durante el primer mes, las oscilaciones de KPI causadas por las recomendaciones de la IA no cuentan. Sin eso, la planta apaga el sistema el primer día.
Trampa 4: La formación de trámite convierte el sistema en decoración
La formación típica en IA: la tarde antes del lanzamiento, dos horas de diapositivas del proveedor, la planta con el móvil, hoja de asistencia firmada. Hecho. Y luego nada.
Verano de 2025. Un almacén de e-commerce de cosmética desplegó planificación de oleadas con IA, con objetivo de un 15% menos de recorrido de pickers. Dos semanas después: solo un 3% menos. Los pickers ignoraban las oleadas del sistema y agrupaban por instinto — "la formación fue demasiado rápida". Nunca habían pulsado "crear oleada con un clic": miedo a pulsar mal y que les culparan.
No es un problema de personas; es un problema de diseño de la formación. Mi estándar ahora:
- Sin diapositivas — manos al teclado. Regla de lanzamiento: cada operario completa 20 pedidos completos en la práctica. Más de 3 errores, sin autorización. Las hojas de asistencia no valen; valen los exámenes prácticos.
- Publica una política de "puedes equivocarte al pulsar". Las dos primeras semanas son un periodo de prueba: los errores de clic no se castigan, el equipo del proyecto está en sitio. El miedo bloquea más que la pereza.
- Mantén un "traductor" por turno. Un veterano respetado por equipo aprende primero, luego enseña al resto. La planta pregunta a sus compañeros cosas que nunca preguntaría a un proveedor.
Trampa 5: El piloto tiene éxito, y luego nada escala
Esquiva las cuatro primeras y esta sigue esperándote.
Finales de 2024. El DC regional de una cadena de supermercados corrió un hermoso piloto de previsión: roturas del 5,2% → 2,8%, ovación en la conferencia del grupo, el CEO ordenó desplegarlo en los 12 DC. Un año después, 2 estaban en producción.
El responsable del piloto estaba cedido y se fue. Los datos del piloto se limpiaron a mano durante tres meses; nadie limpió el resto. Cada DC tenía mezclas y ritmos distintos — los parámetros necesitaban reajuste, nadie lo programó. Y lo grande: el equipo se disolvió. Un "proyecto piloto" no tiene plantilla, ni presupuesto, ni dueño.
Conclusión contraintuitiva: un piloto exitoso es a veces donde empieza el fracaso de un proyecto de IA — la dirección asume que "el modelo está probado" y subestima el coste organizativo de la réplica. Copiar tecnología es Ctrl+C; copiar una organización es fundar una startup de nuevo.
- Escribe el plan de réplica cuando constituyas el piloto. El DC nº 1 pilota, los DC nº 2–3 empiezan cuándo, quién es responsable, cuál es el presupuesto — todo en el acta. Un piloto sin plan de réplica es una demo.
- Convierte el equipo piloto en un equipo permanente. Mantén el núcleo de 2–3 personas como equipo de despliegue con plantilla y presupuesto dedicados. Doce DC a 6–8 semanas cada uno es un año de trabajo.
- Documenta el manual de "un DC, un ajuste". Qué parámetros son universales, cuáles deben reajustarse por DC, el procedimiento estándar de reajuste. Sin eso, cada DC nuevo reaprende las mismas lecciones.
Autochequeo de las cinco trampas: lista de la noche del lanzamiento
Una tabla. Imprímela, marca cada casilla la noche del lanzamiento. Alguna casilla sin marcar — no lanzas:
| # | Trampa | Pregunta de autochequeo | Estándar de aprobado |
|---|---|---|---|
| 1 | La planta no lo usa | ¿El sistema le cuesta tiempo a la planta o se lo ahorra? | El tiempo extra se compensa en dólares; la planta lo probó a mano |
| 2 | Datos huérfanos | ¿Quién es el dueño de los datos — nombre en el documento? | Persona nombrada, ligada a KPI, auditoría antes de modelar |
| 3 | KPI en conflicto | ¿Los KPI de los roles que toca la IA entran en conflicto? | Mapa de conflictos dibujado, adopción en las revisiones, protección de 30 días |
| 4 | Formación de trámite | ¿Cuántos pedidos ha procesado a mano cada operario? | ≥20 pedidos; 3+ errores significa sin autorización |
| 5 | No se puede replicar | Plan de réplica, equipo, presupuesto, manual — ¿los cuatro? | El acta tiene un capítulo de réplica; equipo de despliegue con personal |
Una última cosa sobre el fracaso de un proyecto de IA
Cuando la autopsia dice "la tecnología no estaba madura", nueve de cada diez veces la causa real quedó sin escribir. Los problemas de organización no son vergonzosos — objetivos desalineados, datos sucios, KPI en conflicto son naturales. Volver a caer en el mismo hoyo por tercera vez sí lo es.
Cada una de estas cinco trampas, la he visto al menos tres veces. Espero que no veas ni una.
Por Lin Xiao, consultor de implementación de WMS
Traducido del inglés. En caso de discrepancia, prevalece la versión en inglés.
