Cada pocos días, una nueva demo recorre el circuito: escribes una pregunta en inglés sencillo—“¿Qué pasa si la demanda se dispara en Alemania?”, “¿Qué pasa si cerramos esta planta?”, “¿Qué pasa si cambiamos de proveedores?”—y un asistente responde con total confianza con un plan revisado, una breve explicación y una lista ordenada de los próximos pasos. La propuesta es irresistible: supply chain, finalmente hecha conversacional. La planificación, finalmente sin fricción. La optimización, finalmente accesible.

Burbujas de chat abstractas sobre una compleja red de supply chain

En mi libro Introduction to Supply Chain (ver el Capítulo 6, especialmente las partes que tratan sobre “general intelligence” y el legado de OR), argumenté que supply chain es una disciplina que repetidamente confunde interfaces elegantes con progreso. Ese argumento es importante ahora, porque los large language models (LLMs) están siendo posicionados—tanto por investigadores serios como por proveedores serios—como la pieza faltante que finalmente conectará las matemáticas con las operaciones, y la planificación con la realidad.

Lo que la comunidad está construyendo realmente

La comunidad de investigación operativa ha sido notablemente consistente en lo que quiere de los LLMs: un traductor universal entre la intención humana y la maquinaria matemática.

La serie de competiciones NL4Opt en NeurIPS es explícita sobre el objetivo: aumentar la “accesibilidad y usabilidad de los optimization solvers” permitiendo a los no expertos expresar problemas en lenguaje natural, y luego generar los artefactos de modelado (incluyendo código de modelado LP y MIP) que los solvers pueden utilizar. Esta no es una idea marginal; se está formalizando en tareas de referencia, conjuntos de datos, métricas de evaluación y estructuras de competición basadas en premios.

OptLLM impulsa la misma idea desde el lado de la investigación hacia un flujo de trabajo de extremo a extremo: el usuario expone un problema de optimización en lenguaje natural; el sistema lo convierte en formulaciones matemáticas y código de programación; luego llama a un solver externo e itera mediante un diálogo de múltiples rondas para refinar el modelo. En otras palabras: inglés → matemáticas → código → solver → resultados → inglés, con el LLM orquestando el ciclo.

El capítulo TutORials 2024 de INFORMS, de Wasserkrug, Boussioux y Sun, ofrece un enfoque más amplio, orientado a los profesionales: los LLMs pueden acelerar la creación y despliegue de soluciones de OR/MS mediante (i) la reducción del tiempo de desarrollo mientras se mejora la calidad de las soluciones, (ii) la extracción de datos estructurados a partir de texto no estructurado sin construir modelos NLP a medida (mencionan explícitamente el demand forecast como un caso de uso motivador), y (iii) la habilitación de interfaces en lenguaje natural para que los usuarios empresariales puedan interactuar de forma flexible con modelos analíticos. El capítulo es notable no solo por su optimismo, sino por su énfasis en el uso responsable: los LLMs se presentan como herramientas poderosas, pero herramientas que necesitan gobernanza y rendición de cuentas.

Mientras tanto, la línea de trabajo de aprendizaje para optimizar también está incorporando a los LLMs —no solo como “interfaces”, sino como componentes dentro del ecosistema de solvers. La ambición del “foundation model” ha llegado a MILP: investigadores de Microsoft proponen entrenar un único modelo a lo largo de diversas clases de MILP e introducen MILP‑Evolve, un marco evolutivo basado en LLM que genera grandes y diversas clases de problemas MILP “con una cantidad ilimitada de instancias”, apoyando tareas como aprender a ramificar y alinear instancias MILP con descripciones en lenguaje natural. Una encuesta de 2025 sobre LLMs para la optimización evolutiva va más allá y categoriza los paradigmas emergentes: LLMs como optimizadores autónomos, LLMs integrados dentro de algoritmos de optimización, y LLMs utilizados a un nivel superior para la selección y generación de algoritmos—señalando explícitamente hacia “self-evolving agentic ecosystems” para la optimización.

En el ámbito de la planificación de supply chain, las propuestas riman casi perfectamente con la agenda de OR, pero con un enfoque diferente: no se trata de “hacer los solvers accesibles,” sino de “hacer a los planificadores rápidos.”

La publicación de MIT Sloan Executive Education de 2025 sobre LLMs en la planificación de supply chain es representativa. Describe a planificadores haciendo complejas preguntas what-if en lenguaje natural; el LLM traduce la consulta en ajustes matemáticos y devuelve insights legibles para humanos. Afirma que lo que antes requería “días” de idas y vueltas con los ingenieros puede convertirse en “minutos,” y extiende la promesa a disrupciones en “tiempo real”: los planificadores pueden “ajustar dinámicamente los modelos matemáticos” sin depender de equipos de IT, y volver a ejecutar la optimización para producir planes revisados explicados en lenguaje sencillo. El mismo artículo admite, casi como un aparte, la dificultad central: la validación—asegurar que los ajustes generados por la IA coinciden con las condiciones reales del negocio—sigue siendo un desafío.

Simchi-Levi, Mellou, Menache y Pathuri (2025) hacen explícita la tesis de la “democratización”: los planificadores y ejecutivos actualmente dedican demasiado tiempo a entender los resultados, ejecutar escenarios y actualizar modelos, por lo que los LLMs pueden “democratizar la supply chain technology” facilitando la comprensión y la interacción “sin intervención humana,” reduciendo el tiempo de decisión de “días y semanas” a “minutos y horas.”

El proyecto OptiGuide de Microsoft Research se sitúa exactamente en esta intersección de OR y planificación: tiene como objetivo “democratizar la toma de decisiones” combinando optimización con IA generativa, y afirma su uso en producción para planificadores de supply chain en la nube que responden a preguntas “what if” y reciben recomendaciones accionables.

Los proveedores de software, sin sorpresa, se han convergido en los mismos temas: copilots, agents, consultas en lenguaje natural y decisiones más rápidas.

SAP posiciona a Joule como un copilot de IA generativa integrado en sus aplicaciones empresariales, incluyendo supply chain, y las páginas específicas de IBP de SAP enfatizan el acceso conversacional a la documentación del producto (una forma más fluida de buscar y recuperar guías) e integración de Joule con SAP IBP. Las propias notas de lanzamiento comunitarias de SAP para IBP mencionan la integración de Joule como una innovación en esa línea de lanzamientos.

Los anuncios de Oracle de 2025 enfatizan “AI agents” integrados en Oracle Fusion Cloud Applications. Para supply chain, Oracle afirma que estos agents automatizan procesos, optimizan la planificación y el cumplimiento, y aceleran la toma de decisiones; incluso enumera agents como un asesor de planificación de excepciones y notas que resume alertas y notas. La documentación de preparación de Oracle también describe un agente “Supply Chain Planning Process Advisor” construido con LLMs + RAG para responder a las preguntas de los planificadores sobre responsabilidades, tareas diarias y procesos de escalada, fundamentado en documentos empresariales que el cliente carga.

El comunicado de prensa ICON 2025 de Blue Yonder presenta “AI agents” y un “supply chain knowledge graph,” afirmando que los agents permiten a las empresas “ver, analizar, decidir y actuar” con velocidad de máquina y que la IA agentic está impregnada en la planificación y la ejecución.

Kinaxis describe capacidades de IA agentic y generativa que reducen las barreras para interactuar con datos de supply chain—consultando un “digital twin” en lenguaje natural y recibiendo respuestas—y sus materiales públicos y la cobertura de analistas independientes describen un marco multiagente destinado a reducir la dependencia de IT y permitir que los planificadores interactúen directamente con los datos operativos.

o9 impulsa la misma narrativa con una marca diferente: “GenAI agents” más un enterprise knowledge graph que evoluciona hacia un “large knowledge model,” posicionado como un cambio radical en la productividad y la experiencia para las funciones de planificación.

Por encima de todo esto se encuentra Gartner, que proporciona el lenguaje de la categoría. En un comunicado de prensa de agosto de 2025, Gartner predice una rápida proliferación de AI assistants y de AI agents específicos para tareas en aplicaciones empresariales, describe las “etapas” de la evolución de la IA agentic, y advierte que una idea errónea común es llamar a los asistentes “agents”—un malentendido que etiqueta como “agentwashing.”

Entonces, sí: se está realizando un trabajo real. Benchmarks, frameworks, arquitecturas agents, integraciones y mucha ingeniería orientada a la producción. La pregunta no es si los LLMs pueden ser conectados a las herramientas de supply chain—ya lo están. La pregunta es si esa conexión aborda las causas reales por las que la toma de decisiones en supply chain sigue siendo obstinadamente mediocre.

Por qué no estoy convencido de que la interfaz sea el cuello de botella

La comunidad de OR tiene razón en una cosa: la optimización es difícil de expresar de manera limpia. La comunidad de planificación también tiene razón en una cosa: la gente pierde tiempo traduciendo preguntas en hojas de cálculo, correos electrónicos, reuniones, tickets y cambios de modelos ad hoc. Un LLM puede reducir esa fricción. Puede acortar el camino entre “me pregunto…” y “aquí hay una respuesta computada,” tal como lo describe la publicación de MIT Sloan.

Pero los supply chains no están fallando porque los planificadores carecen de una forma más rápida de hacer preguntas.

Ya existen décadas de solvers, lenguajes de modelado y progreso académico. La afirmación embebida en NL4Opt—“hacer que los solvers sean utilizables por no expertos mediante el lenguaje natural”—presupone que el principal obstáculo es la incapacidad del usuario para formular problemas. Esa es una historia reconfortante para los investigadores, porque convierte un desordenado fallo organizativo en un problema de traducción. Además, resulta ser en gran medida falsa en supply chain.

Lo que bloquea la adopción en el mundo real no es que la gente no pueda escribir restricciones. Es que las restricciones, los objetivos y la semántica de los datos son rutinariamente erróneos—o, más precisamente, son erróneos de maneras que tienen relevancia económica. Puedes generar montañas de código de modelado y aun así estar optimizando tonterías.

Esta no es una crítica nueva. Russell Ackoff argumentó en 1979 que OR se había vuelto “contextualmente ingenuo” y que su aplicación se restringía cada vez más a problemas relativamente insensibles a sus entornos. Los supply chains son lo opuesto a ser insensibles al entorno. Están dominados por la volatilidad, efectos de sustitución, datos ausentes, retroalimentación retrasada e incentivos que remodelan el comportamiento en cuanto comienzas a “optimizar.”

La agenda de LLM en OR tiende a subestimar una brutal asimetría: escribir un modelo es más fácil que validarlo. OptLLM puede generar formulaciones y código, y luego iterar en diálogo. Sin embargo, la verdadera dificultad no radica en producir otro objeto matemático—sino en asegurar que el objeto coincida con las verdaderas compensaciones económicas, restricciones operativas y la realidad de medición de la empresa. Un LLM puede producir una restricción plausible; no puede certificar que esta restricción es lo que tu almacén realmente experimenta a las 3 a.m. durante una promoción, con el registro real de personal, las políticas reales de empaque, las reglas reales de reposición y los modos reales de fallo.

En la planificación, la misma asimetría se vuelve aún más peligrosa, porque el reflejo cultural es confiar en el plan. El artículo de MIT Sloan celebra que los planificadores pueden “ajustar dinámicamente los modelos matemáticos” sin IT. Simchi-Levi y sus coautores lo enmarcan como la eliminación de la necesidad de equipos de ciencia de datos y proveedores de tecnología en el proceso. Esto se vende como empoderamiento. Yo lo veo como eludir precisamente la fricción que solía prevenir la deriva incontrolada del modelo.

Si cambiar el modelo es fácil, la organización cambiará el modelo constantemente. No porque sea prudente, sino porque resulta psicológicamente satisfactorio. Cada interrupción invita a una nueva excepción. Cada pregunta ejecutiva invita a un nuevo escenario. Cada reunión invita a un nuevo ajuste para satisfacer la intuición de alguien. Obtienes un movimiento más rápido, sí—pero también obtienes una entropía más rápida.

Los proveedores, comprensiblemente, se han orientado hacia “agents” que resumen, explican y guían. El Planning Process Advisor de Oracle es esencialmente una capa LLM+RAG sobre políticas y procedimientos: responde preguntas basadas en documentos que cargas e integra esta experiencia de chat dentro de las páginas de flujo de trabajo. La posición de Joule en IBP de SAP, de manera similar, destaca la búsqueda conversacional y las respuestas basadas en la documentación. Estas son características legítimas de productividad. Pueden reducir el tiempo perdido buscando el documento de proceso correcto. Pero no cambian de manera significativa la calidad de las decisiones. Son, en el mejor de los casos, un mejor sistema de ayuda.

Luego llegamos a la narrativa más grandiosa “agentic”. Blue Yonder anuncia múltiples AI agents, impregnados en la planificación y la ejecución, con el objetivo de una optimización continua y una toma de decisiones a velocidad de máquina. Kinaxis describe marcos agentic, AI agents que monitorean y actúan en tiempo real, e interacción en lenguaje natural con un digital twin. Gartner predice un mundo lleno de estas cosas, mientras advierte que mucho de lo que se vende como agents son realmente asistentes—“agentwashing.”

La ironía es que la advertencia de Gartner no es una nota al margen; es el hecho central. La mayoría de estos “agents” son envoltorios. Se sitúan sobre los flujos de trabajo existentes, automatizan fragmentos de interacción y hacen que la interfaz sea más agradable. No reparan la lógica económica de las decisiones, ni resuelven los problemas fundamentales de fidelidad de datos, incertidumbre e incentivos. Pueden reducir el retraso en la toma de decisiones en el sentido estrecho de que alguien puede hacer clic más rápido—pero no en el sentido más profundo de que la empresa esté cometiendo menos errores.

Incluso las integraciones académicas más sustanciales—LLM + optimización de red, con dashboards y explicaciones conscientes del rol—plantean la dificultad central como “cerrar la brecha” entre los resultados de OR y la comprensión de las partes interesadas mediante la traducción de los resultados a lenguaje natural y KPIs contextuales. De nuevo: es útil. Pero mantiene intacta la misma suposición: el modelo es correcto; la gente solo necesita entenderlo. En supply chain, el modelo a menudo es el problema.

Así que cuando oigo “LLMs will democratize optimization,” lo traduzco como: “democratizaremos la producción de pseudo-modelos.” Cuando oigo “LLMs will let planners update models without IT,” lo traduzco como: “aceleraremos la tasa a la que modelos frágiles se parchean, se desparchean y se vuelven a parchar.” Y cuando oigo “agentic AI will orchestrate end-to-end workflows,” pregunto: ¿orquestar hacia qué objetivo, con qué semántica y con qué responsabilidad?

Donde los LLMs pueden ser verdaderamente útiles

Nada de esto es un argumento para ignorar los LLMs. Es un argumento para dejar de pretender que la conversación es un sustituto de la competencia.

El capítulo TutORials de OR/MS tiene razón al enfatizar que los LLMs pueden acelerar la producción de aplicaciones de toma de decisiones, ayudar a convertir texto no estructurado en señales estructuradas y proporcionar capas de interacción en lenguaje natural—a la par que insisten en el uso responsable. Aquí es exactamente donde brillan los LLMs: no como el motor de decisiones, sino como un multiplicador de productividad para los ingenieros y analistas que construyen el verdadero motor de decisiones.

Si utilizas LLMs para escribir glue code más rápido, para generar pruebas, para redactar documentación, para extraer reglas de negocio desordenadas de contratos y SOPs en representaciones estructuradas, estás mejorando la parte del pipeline que en realidad es un cuello de botella: la ingeniería lenta, costosa y propensa a fallos de datos y lógica. Si utilizas LLMs para ayudar a auditores, ejecutivos y operadores a entender por qué se tomó una decisión computada—produciendo explicaciones fundamentadas en evidencia rastreable—puedes mejorar la adopción sin ceder el control.

Incluso la línea de “democratización” puede replantearse productivamente. La afirmación de OptiGuide de que se ha utilizado en producción para cloud supply chain planners que responden a preguntas what-if no es trivial. Pero el valor no radica en que un planner pueda conversar con un optimizador. El valor es que una empresa con una sólida columna vertebral de optimización pueda construir una interfaz más segura y usable—una que exponga las palancas y explicaciones correctas, en lugar de permitir que cualquiera reescriba casualmente las matemáticas subyacentes.

Y sí, la agenda de aprendizaje del solver—modelos fundacionales para MILP, branching aprendido, etc.—puede generar mejoras algorítmicas genuinas. Pero supply chain se beneficiará de esas mejoras solo si el resto de la pila es saludable: semántica correcta, objetivos económicos, manejo robusto de la incertidumbre y un ciclo de ejecución que convierta las recomendaciones en acciones de manera confiable.

En otras palabras, trata a los LLMs de la misma manera en que tratas cualquier herramienta poderosa pero falible: como un acelerador para las personas que construyen sistemas, y no como una capa de barniz sobre procesos rotos. Trátalos como una forma de reducir el costo del rigor, y no como una manera de saltarse el rigor.

supply chain no carece de palabras. Le faltan buenas decisiones. Los LLMs son excepcionales produciendo palabras. Pueden ayudarnos a construir mejores sistemas, más rápido. Pero si confundimos la elocuencia con la corrección, simplemente obtendremos errores presentados en una mejor prosa—y a mayor velocidad.