La IA que sí funciona: cómo una empresa de última milla dejó de quemar dinero en tokens y construyó algo que de verdad escala
No fue magia. Fue arquitectura limpia, datos bien gobernados, equipos que entienden el negocio y la disciplina de no pagar por lo que puedes hacer tú mismo.
Hay dos tipos de empresas que hablan de inteligencia artificial hoy. Las que acumulan facturas de cientos de miles de dólares en APIs de modelos de lenguaje sin poder mostrar un solo KPI que haya mejorado, y las que calladamente están transformando sus operaciones porque entendieron algo que la mayoría ignora: la IA no es un producto que compras, es una capacidad que construyes. Esta es la historia de una empresa de logística de última milla que eligió el segundo camino.
La llamaremos Veloz. Una empresa mediana, con operación en cinco ciudades, flota propia y tercerizada, centros de distribución propios (CEDIS) y el reto clásico del sector: promesas de entrega en ventanas de dos horas, clientes que exigen visibilidad en tiempo real y una operación que, hasta hace tres años, corría sobre hojas de cálculo, WhatsApp y buena voluntad.
El error que todos cometen primero
Cuando Veloz decidió "usar IA", el primer impulso fue el mismo que el de casi todas las empresas: conectarse a la API de algún modelo grande, construir un chatbot para rastreo de pedidos y declarar la transformación digital completa. El equipo técnico lo intentó durante seis meses. El resultado: una factura promedio de $38,000 USD mensuales en tokens, respuestas inconsistentes, latencias inaceptables para operación en tiempo real y, lo más revelador, la certeza de que el 80% de esas llamadas eran para tareas que perfectamente podían resolverse con lógica determinista, reglas de negocio y modelos mucho más pequeños corriendo en su propia infraestructura.
"Estábamos pagando precios de primera clase para volar en clase turista. Habíamos confundido 'usar IA' con 'subcontratar el pensamiento'. El problema no era la tecnología. Era que no entendíamos qué problema real queríamos resolver."— CTO de Veloz, en sesión interna de retrospectiva
Fue ese momento de claridad el que cambió todo. En lugar de seguir escalando el gasto, el equipo tomó una decisión que parecía contracultural en el clima de hype de la IA: parar, limpiar y diseñar desde los cimientos.
Primero: arquitectura limpia o todo lo demás es ruido
No se puede construir inteligencia sobre caos. Veloz tenía sistemas heredados, datos duplicados, integraciones punto a punto y ningún contrato claro entre servicios. Antes de poner un solo modelo en producción, el equipo de ingeniería pasó cuatro meses haciendo algo que pocos quieren hacer porque no genera titulares: desacoplar, modelar y blindar.
La apuesta fue una arquitectura de microservicios bien definida y deliberadamente simple. No cien servicios para demostrar modernidad. Ocho dominios claros: pedidos, rutas, flota, CEDIS, clientes, notificaciones, facturación y analítica. Cada dominio con su propio servicio, su propio repositorio de datos y una API contratada y versionada. Todos corriendo en AWS, con ECS para contenedores y API Gateway para exposición controlada.
La decisión de diseño más importante fue adoptar el patrón hexagonal —también conocido como arquitectura de puertos y adaptadores— como base estructural de cada servicio. La lógica de negocio vive en el núcleo, completamente aislada de los detalles técnicos de infraestructura. Las bases de datos, los canales de mensajería, las interfaces de usuario y las integraciones externas son adaptadores intercambiables que se conectan al núcleo a través de puertos bien definidos. El resultado práctico es poderoso: el negocio se modela con claridad y flexibilidad, y los cambios tecnológicos no contaminan las reglas que le dan sentido a la operación. Cuando el equipo de negocio dice "queremos cambiar cómo se calcula la prioridad de una ruta", ese cambio vive en un solo lugar y no obliga a tocar la base de datos ni la capa de API.
Kafka en el centro: eventos como lenguaje común de la operación
Para la comunicación entre dominios, Veloz eligió Apache Kafka sobre Amazon MSK como columna vertebral de mensajería. Cada evento relevante de la operación —pedido creado, ruta iniciada, entrega confirmada, incidencia reportada, stock actualizado en CEDIS— es publicado en un topic con esquema definido y versionado en un registro central. Los consumidores se suscriben de forma independiente, procesan a su ritmo y el productor no necesita saber quién escucha.
Esto resolvió uno de los problemas más silenciosos y costosos que tenía la arquitectura anterior: las dependencias síncronas en cascada. Cuando el servicio de notificaciones tenía un problema, arrastraba al de pedidos. Cuando el de facturación se saturaba, bloqueaba al de rutas. Con Kafka en medio, un servicio puede estar degradado sin que su falla se propague al resto. La resiliencia dejó de ser una aspiración y se convirtió en una propiedad estructural del sistema.
⬡ Arquitectura en movimiento: el flujo de una entrega
Cuando un cliente confirma un pedido en la app o en web, el servicio de pedidos publica un evento en Kafka. El servicio de rutas lo consume y calcula la asignación óptima. El servicio de flota verifica disponibilidad y emite su propia confirmación como evento. El servicio de notificaciones escucha ese evento y envía el mensaje al cliente. Todo en paralelo, todo desacoplado, todo trazable. Ningún servicio llama directamente a otro. El sistema completo es observable como una secuencia de eventos con timestamps precisos.
Seguridad desde el diseño: Cognito, NIST y el principio de mínimo privilegio
La plataforma de Veloz opera en dos superficies: una aplicación web para el equipo operativo, supervisores y clientes corporativos, y una app móvil para repartidores propios y terceros. Ambas comparten la misma capa de identidad y acceso construida sobre Amazon Cognito, con federación de identidad para los socios terceros y autenticación multifactor obligatoria para todos los roles con acceso a datos operativos.
El modelo de seguridad no fue una capa añadida al final del proyecto. Fue diseñado desde el inicio siguiendo el marco NIST de ciberseguridad en sus cinco funciones: identificar, proteger, detectar, responder y recuperar. Cada microservicio opera bajo el principio de mínimo privilegio: solo puede leer y escribir exactamente los recursos que necesita para su función específica, con políticas IAM declaradas explícitamente y revisadas en cada ciclo de liberación.
Los datos en tránsito viajan siempre cifrados con TLS 1.3. Los datos en reposo, incluyendo coordenadas GPS, información de clientes y datos financieros, están cifrados con claves administradas en AWS KMS con rotación automática. Los logs de acceso, las trazas de auditoría y los eventos de seguridad se centralizan en AWS CloudTrail y se analizan con alertas automáticas ante patrones anómalos. No es paranoia: es la infraestructura de confianza que hace posible que clientes corporativos confíen su operación a la plataforma.
Observabilidad de plataforma: ver todo, en todo momento, desde cualquier lugar
La observabilidad en Veloz opera en tres niveles simultáneos e integrados. El nivel de infraestructura captura métricas de cada contenedor, función y servicio de AWS en tiempo real vía CloudWatch. El nivel de aplicación rastrea cada llamada entre servicios con trazabilidad distribuida usando AWS X-Ray, permitiendo identificar en segundos dónde exactamente ocurre una degradación. El nivel de negocio traduce todo lo anterior en métricas que le importan a operaciones, comercial y dirección: entregas en ventana, costo por paquete, disponibilidad de flota, nivel de ocupación por CEDIS.
Esta observabilidad está disponible tanto en la plataforma web —con dashboards de alta densidad para el equipo de control de operaciones— como en la app móvil, donde cada repartidor ve su propio panel de desempeño en tiempo real y los supervisores de zona reciben alertas push cuando una ruta entra en zona de riesgo. La información correcta llega a la persona correcta, en el dispositivo correcto, en el momento en que todavía puede hacer algo al respecto.
La regla interna que rige todo el diseño sigue siendo tan simple como poderosa: si un servicio no puede explicarse en una oración, es demasiado grande; si una regla de negocio no vive en el núcleo, está en el lugar equivocado; si un evento no se puede rastrear, no debería existir. Esta simplicidad intencional, expresada con rigor en cada capa de la plataforma, es el andamio sobre el cual todo lo demás crece sin colapsar.
Gobierno de datos: el trabajo aburrido que lo habilita todo
Aquí es donde la mayoría de las empresas hace un retiro de liderazgo, genera un bonito PowerPoint con pirámides de datos y luego no cambia absolutamente nada en la operación real. Veloz hizo algo diferente: asignó a una persona de negocio, con autoridad y criterio, como responsable de cada dominio de datos. No un título decorativo. Una persona que responde cuando los datos están mal.
El programa de gobierno arrancó con tres preguntas concretas para cada entidad de datos crítica: ¿De dónde viene este dato? ¿Quién es responsable de su calidad? ¿Qué decisión de negocio depende de él? Suena básico. Y lo es. Pero ejecutarlo con disciplina en una empresa con operación en tiempo real y múltiples canales de captura es todo menos trivial.
⬡ Gobierno de datos en práctica
Veloz implementó un catálogo de datos sobre AWS Glue con contratos de calidad automatizados. Cada pipeline de datos tiene un SLA de frescura y un umbral de completitud. Si los datos de una ruta activa tienen más de 90 segundos sin actualización, se dispara una alerta. Si la tasa de nulos en el campo de coordenadas GPS supera el 3%, el proceso de asignación de rutas entra en modo degradado y notifica al equipo de operaciones.
No es inteligencia artificial. Es higiene de datos bien ejecutada. Y es lo que hace posible que la IA, cuando llega, tenga algo sobre qué trabajar.
El resultado de este trabajo previo fue un conjunto de datos confiables, catalogados y con linaje trazable: 47 millones de eventos de entrega históricos, datos de tráfico en tiempo real integrados vía API, telemetría de flota y registros de desempeño por repartidor. Esta fue la materia prima real de la transformación.
IA nativa en plataforma: el giro que cambió la economía del modelo
Con la arquitectura limpia y los datos en orden, llegó el momento de rediseñar la estrategia de IA. Y la decisión más importante no fue qué modelos usar. Fue cuáles problemas NO necesitan un modelo grande.
El equipo clasificó sus casos de uso en tres categorías. En la primera entraron los problemas que parecen complejos pero que, con buenos datos históricos y algoritmos clásicos de optimización, se resuelven de manera determinista y eficiente: asignación de rutas, predicción de ventanas de entrega, detección de anomalías en telemetría de flota. Estos corrían con modelos propios entrenados sobre SageMaker, sin una sola llamada a API externa.
En la segunda categoría quedaron los casos donde sí se necesita comprensión de lenguaje natural o generación: clasificación de incidencias reportadas por clientes, extracción de información de documentos de operación, asistencia a repartidores para reportar novedades en campo. Aquí entró un modelo de lenguaje mediano, desplegado en su propia infraestructura dentro de AWS, con inferencia vía SageMaker Endpoints. Sin tokens. Sin facturación por llamada. Sin latencia de red hacia un tercero.
"Cuando le mostramos al CFO que habíamos pasado de $38,000 dólares mensuales en APIs externas a $4,200 en cómputo propio con mejor rendimiento, no lo podía creer. Le tuvimos que enseñar la factura de AWS tres veces."— Head of Data & AI, Veloz
En la tercera categoría, la más pequeña, quedaron los casos genuinamente complejos donde sí tiene sentido pagar por un modelo de frontera: redacción de comunicados complejos a clientes corporativos, análisis de contratos con terceros, escenarios de negociación. Para esto, y solo para esto, se mantiene una integración con API externa, con un presupuesto fijo y controlado. La factura pasó de ser una sorpresa mensual a ser una línea predecible en el presupuesto de operación.
Los agentes: orquestación con propósito, no automatización decorativa
La palabra "agente" se ha convertido en uno de los términos más abusados del vocabulario tecnológico actual. Veloz los implementó con una filosofía radicalmente diferente a la del hype: ningún agente hace algo que no pueda auditarse, explicarse y revertirse en menos de diez minutos.
Tres agentes en producción, todos dentro del ecosistema de AWS, orquestados con AWS Step Functions y con estado persistente en DynamoDB:
Agente de reasignación dinámica. Monitorea en tiempo real el estado de las rutas activas. Cuando detecta un repartidor con probabilidad de incumplimiento de ventana superior al 70% (modelo propio, actualizado cada 15 minutos), ejecuta una secuencia: evalúa repartidores cercanos disponibles, calcula impacto en sus rutas actuales, propone reasignación al supervisor de zona y, si hay confirmación, la ejecuta y notifica al cliente final. El supervisor tiene 90 segundos para rechazar. Si no responde, el agente ejecuta. Tiempo promedio de resolución de incidencia de ruta: de 22 minutos a 4 minutos.
Agente de gestión de CEDIS. Conectado en tiempo real al inventario de los centros de distribución vía integración con el WMS. Predice puntos de quiebre de stock por SKU crítico con 6 horas de anticipación, genera órdenes de reposición internas, coordina la comunicación con transportes de abastecimiento y actualiza el dashboard operativo. Antes, este proceso requería dos personas trabajando en paralelo. Hoy es supervisión de excepción.
Agente de calidad de experiencia. Procesa cada interacción de cliente: rastreos, llamadas clasificadas por voz a texto, tickets. Identifica patrones de insatisfacción antes de que lleguen a queja formal, genera resúmenes diarios para el equipo de servicio y detecta casos que requieren intervención humana inmediata. La tasa de escalación a queja formal bajó 41% en los primeros cuatro meses de operación.
Observabilidad: cuando ver todo cambia la calidad de todo
Una plataforma que no puedes observar es una plataforma que no puedes confiar. Veloz invirtió de manera deliberada en tres capas de observabilidad, todas nativas en AWS: métricas de negocio en tiempo real con CloudWatch y dashboards en Grafana, trazabilidad distribuida de servicios con AWS X-Ray, y monitoreo de calidad de datos con alertas automáticas sobre los pipelines críticos.
Pero la observabilidad que transformó la operación no fue la técnica. Fue la de negocio. Cada métrica que importa al director de operaciones está disponible en un dashboard que se actualiza cada 60 segundos: porcentaje de entregas en ventana comprometida, costo por entrega por zona, tasa de primer intento exitoso, disponibilidad de flota propia vs tercerizada, nivel de servicio por CEDIS. Nada de reportes del día anterior. Nada de consolidados semanales que llegan cuando ya no sirven para tomar decisiones.
⬡ El efecto compuesto de la observabilidad
Cuando puedes ver lo que pasa en tiempo real, cambias el tipo de conversaciones que tienes. Los directores de operaciones de Veloz dejaron de hablar de lo que "pasó ayer" para hablar de lo que "está pasando ahora y qué hacemos". Las juntas de operación pasaron de dos horas de revisión de pasado a 40 minutos de decisión sobre el presente. Ese cambio cultural, habilitado por datos observables, es incuantificable en papel pero absolutamente visible en la velocidad de respuesta de la empresa.
La observabilidad también transformó la relación con los socios de flota tercerizada. Por primera vez, Veloz tenía datos objetivos y en tiempo real para las conversaciones de desempeño. Los acuerdos de nivel de servicio dejaron de ser documentos que nadie revisaba hasta que había un conflicto, y se convirtieron en compromisos monitoreados de forma continua, con visibilidad compartida para ambas partes.
Flota propia y tercerizada: la orquestación como ventaja competitiva
Uno de los problemas más complejos de la última milla es saber cuándo confiar la entrega a tu flota propia y cuándo activar capacidad tercerizada, sin perder el control de la experiencia del cliente. Veloz resolvió esto con lo que internamente llaman el modelo de orquestación híbrida.
La lógica es simple de explicar aunque compleja de ejecutar: la flota propia tiene prioridad en rutas de alta densidad, clientes de alto valor y zonas donde el costo de falla es mayor. La flota tercerizada se activa de manera dinámica para picos de demanda, rutas de baja densidad y extensiones geográficas. El modelo de optimización evalúa cada pedido contra disponibilidad de flota, costo marginal por entrega, promesa de ventana horaria al cliente y historial de desempeño del transportista.
El resultado es que los terceros no reciben rutas al azar. Reciben rutas para las que están optimizados. Y la plataforma sabe, por historial, que el transportista Ramírez tiene una tasa de entrega en primer intento del 94% en la zona sur pero solo del 71% en la zona industrial. Eso es información que antes no existía en ningún sistema.
Los números que convencen a cualquier directivo
La transformación de Veloz no fue gratuita ni instantánea. Tardó 18 meses desde la decisión de rehacer los fundamentos hasta tener todos los componentes en producción estable. Pero los resultados simulados sobre sus métricas reales de operación cuentan una historia convincente.
| Métrica de negocio | Antes (año 1) | Después (año 3) | Variación |
|---|---|---|---|
| Entregas en ventana comprometida | 71% | 91% | +20 pp |
| Costo por entrega (promedio) | $68 MXN | $47 MXN | −31% |
| Gasto mensual en IA/APIs externas | $38,000 USD | $4,200 USD | −89% |
| Tiempo resolución incidencia de ruta | 22 min | 4 min | −82% |
| NPS (Net Promoter Score) | 34 | 67 | +97% |
| Rotación anual de personal operativo | 48% | 29% | −40% |
| Ingresos anuales (crecimiento) | Línea base | +67% | 3 años |
Lo que los números no capturan completamente es el efecto sobre la capacidad de crecimiento. Veloz puede ahora incorporar un nuevo CEDIS en menos de seis semanas con integración total a la plataforma. Antes, ese proceso tomaba seis meses y requería trabajo manual de migración de datos. La plataforma escala porque fue diseñada para escalar, no porque se le agregaron parches encima.
El factor humano: equipos que entienden el negocio, directivos que entienden la tecnología
Es el punto más incómodo de hablar porque implica reconocer que el mayor cuello de botella en transformación tecnológica no es la tecnología. Son las personas en posiciones de poder que no entienden lo que están decidiendo.
Veloz hizo algo que pocas empresas tienen el coraje de hacer: antes de invertir en plataforma, invirtió en capacidad. Sus equipos de producto, datos e ingeniería no son silos separados que se comunican vía tickets. Son equipos cross-functional organizados alrededor de dominios de negocio. El equipo de rutas tiene un ingeniero de datos, un desarrollador backend, un diseñador de producto y un especialista en operaciones logísticas. Todos reportando al mismo líder, todos con el mismo objetivo: que las rutas funcionen mejor.
"El día que nuestro director de operaciones pudo leer un diagrama de arquitectura y entender por qué una decisión técnica impactaba en el costo por entrega, fue el día que dejamos de tener proyectos de TI y empezamos a tener proyectos de negocio con componente tecnológico."— CEO, Veloz
El liderazgo tecnológico de Veloz no es decorativo. El CTO tiene historial en operaciones logísticas. La Head of Data vino del área de inteligencia comercial. El Director de Producto pasó dos años en campo acompañando a repartidores. Esta combinación de capacidad técnica con comprensión profunda del negocio es, más que cualquier tecnología, lo que hace posible que las decisiones sean buenas.
En industrias operativamente intensas como la logística, el conocimiento del negocio no es opcional para los equipos de tecnología. Es el requisito mínimo. Los sistemas inteligentes son solo tan buenos como la comprensión que tienen sus diseñadores de los problemas que intentan resolver.
Lo que Veloz enseña al resto del mercado
La historia de Veloz no es excepcional por sus resultados. Es excepcional por la secuencia de decisiones que los hizo posibles. Primero los fundamentos: arquitectura limpia, datos gobernados, equipos alineados. Luego la inteligencia: modelos propios donde tiene sentido, agentes bien acotados, observabilidad profunda. Y al final, con esa plataforma construida, el crecimiento se vuelve una consecuencia natural, no una apuesta.
El mercado está lleno de empresas que se saltaron los primeros dos pasos y están pagando las consecuencias: sistemas que no hablan entre sí, datos que nadie confía, facturas de IA que crecen más rápido que los ingresos y equipos que no entienden por qué la tecnología que compraron no resuelve sus problemas.
La IA no es la respuesta a todos los problemas de una empresa. Pero cuando los problemas están bien definidos, los datos son confiables, la arquitectura permite iterar sin romper todo y los equipos entienden el negocio que están automatizando, la IA puede hacer algo extraordinario: hacer que una empresa que ya hacía bien las cosas, las haga mucho mejor, a mayor escala, con menor costo y con la confianza de que el sistema no va a caerse en el momento más crítico.
Ese es el tipo de transformación que vale la pena construir. Y empieza, casi siempre, por dejar de buscar atajos.
#JMCoach
Los nombres, cifras operativas y detalles de implementación presentados en este artículo son se cambiaron un poco para generar el artículo manteniendo su esecnia, basados en patrones reales de transformación en empresas de logística de última milla en México y Latinoamérica. Los principios arquitectónicos y de gobierno de datos descritos corresponden a prácticas documentadas de la industria.
No hay comentarios.:
Publicar un comentario
Nota: sólo los miembros de este blog pueden publicar comentarios.