IA en logística: dónde sí y dónde no

Son las seis de la tarde en la sala de control de una paquetería. Las furgonetas llevan desde las ocho en la calle y empieza la hora mala: los clientes que no están en casa, el conductor que escribe desde un portal sin timbre, el WhatsApp de alguien que pide que se lo dejen al portero, el retraso que se va a comer las tres últimas franjas de una ruta. Cada caso es pequeño. Son doscientos en una hora, y hay dos personas mirando una pantalla.

Cuando se habla de IA en logística casi nunca se habla de esto. Se habla de Amazon optimizando rutas, de almacenes con robots, de predicción de demanda. Todo eso existe, pero una paquetería regional no tiene ese problema ni ese presupuesto. Su problema está en esa sala a las seis de la tarde, y es donde más rendimiento tiene la IA hoy.

Este mundo lo conozco desde el lado del software: pasé más de un año en Trucksters, una empresa de transporte de mercancías por carretera, desarrollando el TMS interno con el que trabaja su equipo de operaciones. Lo que sigue sale del diseño de una demo que preparé para empresas de reparto: una torre de control que decide sobre las excepciones de la última milla. Todavía no lo he montado para ningún cliente, así que lo que viene son ideas con su porqué, para que juzgues si alguna encaja en tu operación.

Dónde se pierde el dinero en la última milla#

En el reparto el plan casi nunca es el problema. Las rutas salen bien de un TMS decente. El dinero se va en lo que se sale del plan:

• La entrega fallida, que se convierte en un segundo intento mañana: otra parada y otro coste completo por un paquete que ya habías pagado por entregar.
• La franja incumplida, que no cuesta en el momento pero sí en la siguiente queja, y en el cliente que se va a la competencia.
• El tiempo de la sala de control, que no escala. Si el volumen se dobla en Navidad, las excepciones también, y las personas no.

Todas tienen algo en común: alguien tiene que decidir qué hacer con un caso, y casi siempre la decisión depende de datos que ya están en el sistema. El historial del cliente, la posición de la furgoneta, la política de la empresa.

Ejemplos de IA en logística, excepción por excepción#

Cliente ausente#

Es el caso más repetido y el más claro. Las opciones son pocas: reprogramar para mañana, llevarlo a un punto de recogida, dejarlo con un vecino autorizado o reintentar hoy si la furgoneta vuelve a pasar cerca. La buena elección depende del historial de ese cliente: si suele recoger él, si tiene un punto preferido, si ya ha fallado tres veces este mes.

Un modelo pequeño de clasificación, de los que eligen entre opciones en lugar de escribir texto, puede decidir esto en torno a 100 milisegundos y devolver, además de la elección, cuán seguro está: «punto de recogida, con un 91 % de confianza». Ese porcentaje es lo que permite dejarle actuar solo.

El WhatsApp del cliente#

«Estoy en el hospital con mi padre, si viene el repartidor que se lo deje al portero, o si no mañana por la tarde». La IA es buena justo en esto: entender qué pide alguien que escribe como escribe la gente. Aquí hay dos decisiones distintas. Una es la intención: cambiar de franja, cambiar de dirección, reclamar, preguntar. La otra es el tono, porque no se responde igual a alguien tranquilo que a alguien que amenaza con cancelar. Lo estándar se resuelve solo; lo que tiene matices pasa a una persona.

El conductor parado en un portal#

«Portal sin timbre y no coge el teléfono, tengo catorce paradas más, ¿qué hago?». El conductor está parado esperando, y cada minuto se arrastra a las catorce paradas siguientes. Este caso es casi siempre rutina: llamar al cliente, si no contesta dejar aviso y seguir. Clasificar el problema (acceso, cliente, mercancía, vehículo) y devolver la instrucción estándar es exactamente el tipo de decisión que un modelo rápido resuelve antes de que el conductor termine de escribir.

Retrasos en ruta#

Un atasco de veinte minutos puede no afectar a nadie o comprometer las últimas seis entregas de la jornada. Lo útil es medir cuánto afecta: sin impacto, recuperable, muchas paradas, jornada perdida. Según la respuesta se avisa ya a los clientes afectados, antes de que llamen ellos, o se proponen paradas para otra furgoneta cercana.

Paquete dañado y entrega disputada#

Aquí la IA no decide. Una foto de una caja abollada o un «me aparece como entregado y no tengo nada» tienen consecuencias económicas y de reputación, y deben pasar siempre por una persona. Lo que sí hace la IA es preparar el caso: describir la foto, cruzar la hora de entrega con la ruta, ordenar la cola por gravedad y dejar redactada una propuesta. A la persona le llega el caso ya resuelto sobre el papel, y solo tiene que aprobar, editar o rechazar.

La avería: aquí no hace falta IA#

Una furgoneta se rompe a las cinco con once paradas pendientes. Repartirlas entre las furgonetas cercanas que tienen jornada suficiente es un problema de distancias y horas, y se resuelve con código de toda la vida. Lo incluyo porque es la prueba de que alguien ha pensado: un proyecto en el que todo es IA suele ser un proyecto en el que nadie se preguntó si hacía falta.

Cómo implantar IA en una empresa de transporte sin perder el control#

La forma de montar esto que me parece sensata es un embudo de cuatro capas, en el que cada caso se queda en la primera que puede resolverlo:

1. Reglas. Lo contractual y lo aritmético va en código: intentos máximos, franjas cerradas, horas de jornada. No cuesta nada y no se equivoca.
2. Un modelo de clasificación rápido. Varias preguntas cortas sobre el caso, cada una con su respuesta y su confianza. Nunca una sola pregunta del tipo «¿qué hacemos?» con diez opciones.
3. Un umbral que pones tú. Por encima de 0,80 de confianza se ejecuta solo; entre 0,60 y 0,80 se ejecuta y queda marcado para revisar; por debajo, sube a la siguiente capa.
4. Un modelo grande y una persona. El modelo de lenguaje lee el contexto completo, propone qué hacer y redacta el mensaje. Una persona lo aprueba.

De todo el sistema, ese umbral es lo que más importa. El primer mes lo pones alto y revisas mucho. Cuando te fíes, lo bajas. No hay que reentrenar nada ni reescribir instrucciones: es un número, y lo decide el director de operaciones.

Por qué no mandar todo a ChatGPT#

Es la tentación obvia, porque un modelo grande entiende cualquier caso, y es lo que menos recomiendo. Un modelo grande de los de chat tarda varios segundos por caso y cuesta del orden de un céntimo por decisión. Uno pequeño de clasificación responde en torno a una décima de segundo y cuesta una fracción de céntimo. Con doscientos clientes ausentes en una hora, la diferencia es una cola de varios minutos frente a ninguna, y dólares frente a céntimos al día, multiplicado por cada día del año.

No es que el modelo grande sea malo. Para el 90 % de estos casos es llevar a un cirujano a poner tiritas. Lo quieres para el otro 10 %: lo ambiguo, lo que lleva foto, lo que hay que explicar con tacto.

Cómo saber si funciona#

Un sistema que decide sobre tu reparto tiene que poder demostrar lo que hace. Las métricas que miraría:

• Entregas fallidas evitadas: ausencias que acabaron en punto de recogida, vecino o reintento con éxito el mismo día, en lugar de un segundo intento mañana.
• Porcentaje de casos resueltos solos frente a revisados, y cómo cambia al mover el umbral.
• Tiempo de la sala de control por caso, antes y después.
• Cada decisión registrada con los datos que se usaron, la respuesta y su confianza. Cuando algo sale mal se audita y se ajusta la política, no se discute de memoria.

Si un proveedor no te puede enseñar el registro de por qué se tomó cada decisión, no estás comprando un sistema de decisión. Estás comprando una caja negra con buena presentación.

Por dónde empezaría yo#

Por un solo tipo de excepción. El cliente ausente suele ser el mejor candidato: es el más repetido, las opciones están acotadas y el ahorro se mide en segundos intentos que no ocurren. Se conecta por eventos al TMS que ya tienes, sin migrar nada, y el primer mes funciona en modo «solo proponer»: el sistema sugiere, tu equipo decide, y al final del mes comparas sus propuestas con lo que hizo la gente.

Es el mismo principio que apliqué en Northard, una aplicación de inspección de equipos de seguridad: el veredicto no se opina, se calcula, y queda escrito por qué.

Si en tu operación hay una de estas excepciones que se come las tardes de alguien, cuéntamelo. En IA aplicada y automatización explico cómo trabajo, y la primera conversación sirve para decidir si la IA es la herramienta o basta con una regla.