De operaciones a Tecnología e IA

La tecnología es donde empecé. La estudié, y mi tesis de maestría en la Universidad de Salford, en 2010, fue sobre outsourcing de TI en Bolivia. Durante mi primera década en GOJA lideré tecnología desde Cochabamba, donde armamos el equipo y las herramientas con las que funcionaba la empresa. En 2020 pasé a ser VP de Operaciones y durante seis años manejé supply chain, merchandising, compliance y customer service.

Hace dieciocho meses también asumí el equipo de tecnología. Este año tomamos una decisión que, creo, dice mucho de hacia dónde van empresas como la nuestra: Tecnología e IA se convirtió en una función propia, y pasé a liderarla.

Operaciones y tecnología son disciplinas distintas, y está bien que lo sean. Operaciones maneja el negocio que tenemos. Tecnología e IA tiene que construir el sistema que permita que el negocio escale mucho más rápido que su headcount. Construir un sistema agéntico no es un proyecto paralelo que se hace entre una orden de compra y otra. Necesita su propio liderazgo, su propio roadmap y su propio foco.

Para mí también es volver a mis raíces. Y se siente bien.

Cuando entré a GOJA en 2010, nadie había escrito el libro sobre cómo manejar tiendas en Amazon. No había cursos, ni manuales, ni consultores que lo hubieran hecho antes. Éramos expertos en formación.

Así que hicimos lo que tenía sentido: mirar los datos. Ventas por día, rankings, precios, reviews, lo que hacía la competencia. Cuando las herramientas no existían, las construimos. La experiencia que todavía no teníamos la reemplazamos con números, y con esos números construimos la experiencia. En 2017 llevamos Riskless, un sistema de tráfico, inventario y pricing construido en Cochabamba, a Collision. Era esa costumbre convertida en software.

Desde entonces uso el mismo marco de trabajo, casi sin ponerle nombre: cuando no tengo la experiencia, la reemplazo con datos.

Así aprendí finanzas. Hace unos diez años le pedí a un amigo de FP&A una clase uno a uno sobre lo que realmente hacía, y después me metí en nuestros números hasta que tuvieron sentido. Así aprendí supply chain. No podía competir en experiencia con gente que llevaba veinte años manejando cadenas de suministro, pero sí podía mirar la velocidad de venta, el lead time y la cobertura de cada SKU todas las semanas, y ver patrones antes de que alguien me los explicara.

Los amigos me ayudaban con el vocabulario. Las respuestas de verdad casi siempre venían de los datos.

Aprender IA desde adentro

Usar IA como usuario y construir el sistema del que otros van a depender son dos trabajos muy distintos. En el último año algunos principios se me hicieron claros. Ninguno es secreto. La mayoría de los equipos los aprende por las malas.

La mayoría de los problemas de IA son primero problemas de datos. Antes de elegir un modelo, las preguntas son de granularidad, resolución de entidades y definiciones. En Amazon, un producto puede tener varios SKUs por distintas razones, y finanzas y operaciones muchas veces lo miran a niveles diferentes. Si tus datos no reconcilian esas vistas, ningún modelo lo va a hacer. Las decisiones del pasado viven en los datos durante años, y quien estuvo cuando se tomaron lee un esquema de forma muy distinta a quien recién llega.

La capa semántica y la base de conocimiento son el producto. Un modelo no sabe qué significa margen de contribución en tu empresa, qué joins son seguros, ni qué números son reales y cuáles son forecast. Si expones tablas crudas, va a responder rápido, con seguridad, y mal. La capa semántica resuelve eso con definiciones de métricas, reglas de negocio y relaciones válidas. La base de conocimiento va más allá y guarda cómo piensa el negocio: estrategias, reglas de decisión, qué se intentó y qué pasó. La capa semántica evita que el modelo se equivoque. La base de conocimiento es lo que lo hace útil. Las dos merecen la misma disciplina que el código: versionadas, probadas, con dueño. Los modelos se están volviendo un commodity. El conocimiento de tu negocio, escrito de forma que un sistema lo pueda usar, no.

Un protocolo no es una estrategia. MCP hizo fácil poner herramientas y datos frente a un modelo, y lo usamos. Pero una superficie de herramientas sin semántica solo hace que los errores lleguen más rápido. El valor está en lo que el modelo entiende cuando llega.

Un prototipo no es un sistema. Con buenos datos y un modelo fuerte, cualquiera puede armar un artefacto funcional en una tarde y programarlo para que corra todos los días. Se siente como un agente. Un sistema agéntico en producción es otra cosa: runtime, estado, orquestación, evaluaciones, observabilidad, gobierno y un modelo de costos. En esa brecha es donde se rompen la mayoría de las expectativas, y explicarla es buena parte de mi trabajo.

Agentes acotados, autonomía ganada. Agentes más chicos, con alcance preciso y contexto separado, suelen funcionar mejor que un agente que hace todo. La autonomía se gana por etapas, dentro de límites de política claros, con una persona responsable de la decisión hasta que la evidencia diga otra cosa. Y cada agente tiene que estar atado a un resultado de negocio que ya medimos. Si no podemos decir qué número mueve, no lo construimos.

Usar un modelo solo donde se necesita criterio. Si la respuesta ya está en la base de datos, la lógica determinística es más rápida, más barata y auditable. Rutear bien entre las dos es una de las decisiones de diseño más subestimadas.

La inferencia es una línea del P&L. Usar IA estilo chat es barato. Un sistema que pasa cada decisión por un modelo, todos los días, es un costo operativo real. El negocio tiene que ver el costo por decisión antes de que llegue la factura.

Invertir en lo que se acumula. Los atajos ingeniosos para las limitaciones de los modelos de hoy envejecen rápido, porque los modelos mejoran cada pocos meses. Un registro limpio de qué decidimos, por qué y qué pasó después, no. Cada decisión registrada así alimenta la base de conocimiento y mejora la siguiente.

Por qué operaciones importa aquí

Un sistema agéntico para un negocio en Amazon es, en muchos sentidos, operaciones hechas explícitas. Un agente de forecast necesita saber que una promoción distorsiona la velocidad de venta del mes pasado. Un agente de pricing necesita umbrales, tiempos y una tolerancia al impacto en ventas. Un agente de inventario necesita entender que la caja inmovilizada en un producto lento es un costo real. Nada de eso viene del modelo.

Seis años manejando operaciones significan que sé qué decisiones importan, dónde mienten los datos y qué necesitan de verdad las personas que toman esas decisiones. Esa es la parte que yo traigo a la tecnología. Mis ingenieros traen una profundidad en el código que yo nunca voy a tener, y así es exactamente como debe funcionar un buen equipo.

Sigo llamando a amigos

Mi método no cambió en dieciséis años. Cuando no sé algo, le pido lo básico a alguien que sepa, y después me voy a los datos. La diferencia es que ahora los datos me responden, y estoy construyendo el sistema que va a hacer lo mismo por todos en GOJA.

Estoy aprendiendo más rápido que en cualquier otro momento de mi carrera, y esta vez desde adentro, no como usuario.

Estoy de vuelta en mis raíces, y se siente bien.