IA pragmática en supermercados: 3 casos donde sí funciona, 2 donde no

Si dirigís la tecnología de una cadena de supermercados, la presión por "incorporar IA" este año no llega del equipo técnico. Llega del CEO, del directorio, del consultor externo que vino a una reunión. Llega como un mandato vago: "hay que tener IA". Sin caso de uso. Sin métrica de éxito. Sin presupuesto definido más allá de "empecemos con algo".

Ese mandato es la forma más cara de quemar plata que existe en grocery enterprise hoy. Lo digo con experiencia, no con cinismo: he visto al menos cinco cadenas de la región gastar entre cuarenta y doscientos mil dólares en proyectos de IA que terminaron archivados a los seis meses, no porque la tecnología fallara — sino porque el caso de uso estaba mal elegido desde el primer día.

Este post existe para revertir esa conversación. Acá hay tres casos de IA en supermercados que sí funcionan, con criterios honestos para evaluarlos. Y dos que casi nunca funcionan, con la razón técnica de por qué. La idea no es vender un proyecto — es darte un marco para decir no a los nueve siguientes proyectos vagos que te van a llegar este trimestre.

Caso 1 — Forecasting de demanda con eventos locales

Cuándo funciona: cuando ya tenés al menos dos años de historia de ventas por SKU por tienda, y querés mejorar la precisión del pedido de reposición frente al método heurístico que usa hoy tu equipo de compras.

Cuándo no: cuando tu data de ventas tiene huecos serios, formatos inconsistentes o tu maestro de productos tiene SKUs duplicados sin reconciliar.

El forecasting de demanda con machine learning es probablemente el caso de uso de IA con mayor ROI medible en grocery enterprise hoy. La razón es simple: cada punto porcentual de mejora en precisión de pronóstico se traduce en menos merma de perecederos, menos quiebres de stock, y menos capital atrapado en inventario. En una cadena de cincuenta tiendas con USD 80M-200M de ingreso anual, una mejora del 8% en precisión típica vs el método heurístico actual representa entre USD 600.000 y USD 2.4M por año. Esos números no son hype — son la matemática del margen en grocery.

Lo que separa una implementación que mueve el negocio de una que no es la calidad de las features locales.

Las features locales que hacen la diferencia en Centroamérica:

Calendario operativo guatemalteco. Día de la Madre dispara lácteos y panadería. 14 de Septiembre dispara bebidas y carbón. Fin de quincena dispara categorías masivas en zonas urbanas. Semana Santa cambia toda la dinámica. Vendaval afecta logística. Si tu modelo usa solo calendario gregoriano, estás dejando entre 4 y 9 puntos de precisión sobre la mesa.

Clima por sucursal. Una semana lluviosa en Cobán afecta perecederos distinto que una semana lluviosa en zona 10. Hay APIs gratuitas de clima histórico (Open-Meteo, NOAA) que se pueden inyectar al pipeline.

Eventos del barrio. Un partido de la selección, una feria local, una peregrinación. Estos eventos tienen impacto medible en SKUs específicos en sucursales específicas. La forma honesta de capturar esto es un calendario manual mantenido por el equipo de operaciones — más una fuente de eventos públicos (Visit Guatemala, INGUAT).

Precio competidor. Un scrape semanal de los catálogos de los dos competidores principales en una zona puede mejorar el modelo entre 2 y 5 puntos en SKUs sensibles a precio (commodities como aceite, azúcar, arroz).

El error que mata el ROI de este caso de uso es automatizar el pedido de reposición sin human-in-the-loop el primer trimestre. La forma correcta: el modelo sugiere, el equipo de compras revisa y aprueba o ajusta. A los 90 días tenés data de qué tan a menudo el equipo modificó la sugerencia y por qué. A los 180 días podés automatizar las categorías donde el modelo iguala o supera al equipo.

Caso 2 — Búsqueda semántica de catálogo en español

Cuándo funciona: e-commerce con más de 5.000 SKUs activos, donde el comportamiento del usuario muestra que el buscador interno tiene una tasa de "cero resultados" mayor a 8%, o un bounce rate post-búsqueda mayor a 50%.

Cuándo no: cuando el catálogo es chico (menos de 2.000 SKUs) o cuando la mayoría del tráfico viene a categorías predefinidas y la búsqueda es uso marginal.

El español tiene un problema específico para búsqueda en grocery que el inglés no: regionalismos densos en categorías comunes. Una persona busca "blanquillos" y el sistema le devuelve cero resultados porque tu catálogo dice "huevos". Otra busca "papa" cuando tu maestro registra "patata". Búsqueda por keywords falla. Búsqueda semántica resuelve esto sin que tu equipo de catálogo tenga que mantener un diccionario de sinónimos manualmente.

El stack que recomendamos:

// services/search/src/embeddings.ts
import { OpenAI } from 'openai';
import { Pool } from 'pg';
 
const openai = new OpenAI();
const db = new Pool();
 
// Indexación: corre una vez por SKU, después solo en cambios
export async function embedAndStoreProduct(p: Product) {
  const text = [
    p.name,
    p.brand,
    p.category,
    p.description,
    p.tags?.join(' '),
    // Sinónimos críticos LATAM mantenidos por el equipo de catálogo
    p.regionalAliases?.join(' '),
  ].filter(Boolean).join(' . ');
 
  const { data } = await openai.embeddings.create({
    model: 'text-embedding-3-small', // 1536 dims, USD 0.02 / 1M tokens
    input: text,
  });
 
  await db.query(
    `INSERT INTO product_embeddings (sku, embedding, indexed_at)
     VALUES ($1, $2::vector, now())
     ON CONFLICT (sku) DO UPDATE SET embedding = $2::vector, indexed_at = now()`,
    [p.sku, JSON.stringify(data[0].embedding)],
  );
}
 
// Búsqueda: corre por cada query de usuario
export async function semanticSearch(query: string, limit = 24) {
  const { data } = await openai.embeddings.create({
    model: 'text-embedding-3-small',
    input: query,
  });
 
  const result = await db.query(
    `SELECT sku, name, price, image_url,
            1 - (embedding <=> $1::vector) AS similarity
     FROM product_embeddings pe
     JOIN products p USING (sku)
     WHERE p.active = true
     ORDER BY embedding <=> $1::vector
     LIMIT $2`,
    [JSON.stringify(data[0].embedding), limit],
  );
  return result.rows;
}

Costos honestos para una cadena con catálogo de 30.000 SKUs y un millón de búsquedas por mes:

• Indexación inicial: USD 1-3 (one-time, embeddings de 30k productos).
• Re-indexación incremental: USD 5-15 al mes (solo cambios).
• Búsqueda en producción: USD 12-25 al mes en embeddings de queries.
• Postgres con pgvector ya activo: cero costo adicional sobre la base existente.

Total: menos de USD 50 mensuales en infra de IA. La mejora típica medible: conversión post-búsqueda sube entre 12% y 30%, tasa de cero resultados baja a menos del 1%.

La razón por la que pgvector sobre Postgres es la respuesta correcta para casi todas las cadenas: ya tenés Postgres operativo, ya tenés backups y compliance configurados, ya tenés equipo que sabe operarlo. Pinecone o Weaviate tienen sentido cuando hablamos de cientos de millones de vectores — no es tu caso.

Caso 3 — Asistente interno para gerentes de tienda

Cuándo funciona: cadenas con más de veinte tiendas donde la rotación de gerentes y subgerentes es alta, y donde los procedimientos operativos están documentados pero dispersos en PDFs, intranets y carpetas de SharePoint que nadie consulta.

Cuándo no: cuando los gerentes son senior, estables y ya tienen fluidez total con los procedimientos.

Este es el caso de uso de LLM más subestimado en grocery enterprise. No es glamoroso. No vende bien en una keynote. Pero el ROI por hora ahorrada es directo y medible.

El problema concreto: un gerente de tienda nuevo necesita responder en cinco minutos a preguntas operativas que la persona experimentada respondería de memoria. "¿Cómo proceso una devolución de un cliente que pagó con tarjeta de un banco que no tenemos integrado?" "¿Cuál es el procedimiento de cierre de caja un domingo cuando no hay supervisor?" "¿Cómo escalo un reporte de plaga en cámara fría?". La respuesta vive en algún manual operativo. Encontrarla toma quince minutos. Multiplicado por veinte gerentes nuevos al año, multiplicado por cuatro o cinco preguntas semanales — son cientos de horas perdidas.

El patrón que sí funciona es RAG sobre manuales operativos con scope acotado — no un chatbot abierto.

// services/store-assistant/src/rag.ts
import { Anthropic } from '@anthropic-ai/sdk';
import { getRelevantSops } from './retrieval';
 
const anthropic = new Anthropic();
 
const SYSTEM = `Eres un asistente para gerentes de tienda de una cadena de supermercados.
Reglas estrictas:
- Solo respondes basado en los procedimientos operativos provistos en el contexto.
- Si la respuesta NO está en el contexto, decís exactamente: "Esto requiere consulta con tu supervisor regional. Llamá al [número de turno]."
- Nunca inventás números de teléfono, plazos o autorizaciones.
- Si la pregunta involucra autorización monetaria mayor a Q500, indicás escalar al supervisor.
- Respondés en español, en máximo 4 párrafos.`;
 
export async function ask(question: string, storeId: string) {
  const sops = await getRelevantSops(question, { topK: 5, storeId });
 
  const context = sops
    .map((s) => `### ${s.title} (sección ${s.section})\n${s.body}`)
    .join('\n\n');
 
  const response = await anthropic.messages.create({
    model: 'claude-haiku-4-5-20251001',
    max_tokens: 800,
    system: SYSTEM,
    messages: [
      {
        role: 'user',
        content: `Pregunta del gerente: ${question}\n\nProcedimientos relevantes:\n${context}`,
      },
    ],
  });
 
  return {
    answer: response.content[0].type === 'text' ? response.content[0].text : '',
    sources: sops.map((s) => ({ title: s.title, section: s.section })),
  };
}

Tres detalles técnicos que separan una implementación útil de una peligrosa:

1. Scope explícito en el system prompt. "Solo respondés basado en los procedimientos provistos". Esto reduce hallucinations a casi cero — el modelo no se inventa procedimientos.

2. Fallback explícito. Cuando no hay contexto suficiente, el modelo deriva al supervisor. No improvisa. Esa frase de fallback es la diferencia entre una herramienta confiable y una demanda judicial.

3. Sources en la respuesta. Cada respuesta cita la sección del manual de donde viene. El gerente puede verificar. Es auditable.

El costo: menos de USD 200 mensuales en API de Claude Haiku para una cadena con 50 tiendas y diez consultas diarias por tienda. La mejora medible: tiempo promedio para resolver dudas operativas baja de quince minutos a menos de uno, y el equipo de soporte regional reduce volumen de llamadas entrantes entre 30% y 50%.

Lo que casi nunca funciona

Y ahora la parte impopular. Hay dos casos de uso que se proponen constantemente en grocery enterprise y que casi siempre fallan en producción.

Chatbot público sin scope

El proyecto típico: "hagamos un chatbot en el sitio web que ayude al cliente con cualquier consulta". Suena bien. Falla en producción.

Las razones técnicas son tres. Primero, sin scope estricto, el chatbot va a contestar preguntas que no debería — desde recomendaciones nutricionales hasta consejos legales — y eso es responsabilidad legal directa de la cadena. Segundo, los costos por query escalan rápido cuando es público (hay bots, scrapers, abuso). Tercero, los clientes con problemas reales prefieren un humano y se frustran con el bot, aumentando el costo de soporte en lugar de bajarlo.

Si querés mejorar la experiencia de soporte al cliente, un asistente con scope acotado para tu equipo interno de soporte funciona. Un chatbot público sin scope, no.

Predicciones críticas sin human-in-the-loop

Ver caso 1, pero más fuerte: automatizar pedidos de reposición de productos perecederos basados solo en predicciones de un modelo, sin revisión humana, es la receta para vaciar cámaras frías o llenar bodegas en exactamente la temporada equivocada. Los modelos fallan en eventos sin precedente — y en grocery hay eventos sin precedente cada cuatro o cinco meses (pandemia, vendaval mayor, decisión gubernamental).

La regla operativa simple: si una predicción equivocada del modelo cuesta más de USD 5.000 en una decisión, un humano firma antes de ejecutar. Punto.

Cómo decidir si tu caso es uno u otro

Antes de gastar el primer dólar en cualquier proyecto de IA, hay tres preguntas que tu equipo técnico tiene que poder responder con números:

1. ¿Cuál es la métrica de éxito y cuál es su valor de baseline hoy? "Mejorar la experiencia del cliente" no es métrica. "Subir conversión post-búsqueda del 14% al 20%" sí lo es. Si no podés definir esto, todavía no tenés caso de uso.

2. ¿Qué pasa si el modelo se equivoca el 5% de las veces? Si la respuesta es "perdemos plata pero el sistema sigue", es un caso candidato. Si la respuesta es "hay riesgo legal o reputacional serio", necesitás human-in-the-loop obligatorio.

3. ¿Tenemos la data limpia y completa que el modelo necesita? En grocery, esto suele ser el bloqueante real — no la tecnología. Si tu maestro de productos tiene SKUs duplicados, si tu historial de ventas tiene huecos por migraciones pasadas, si los precios de competidores no se capturan — ningún modelo va a salvarte.

Si las tres preguntas tienen respuesta clara, el proyecto vale la pena. Si alguna no la tiene, el proyecto es premature optimization disfrazada de innovación.

Si tu CEO te está pidiendo "incorporar IA"

Si llegaste a este post porque tenés que armar una propuesta de IA para presentar al directorio el próximo trimestre — la respuesta correcta no es elegir un caso de uso de moda, es elegir un caso con ROI medible y bajo riesgo. Forecasting con human-in-the-loop, búsqueda semántica para resolver el problema del español, asistente interno para gerentes — son tres apuestas defendibles. Cualquier otra cosa empieza con la pregunta dura de la sección anterior.

En nuestro retainer de ingeniería ayudamos a cadenas a hacer exactamente esto: pasar de "queremos IA" a un proyecto concreto con métrica, ROI estimado, riesgo acotado y plan de fases. No vendemos plataforma — diseñamos el caso de uso, lo construimos en producción y nos quedamos cerca durante la fase de calibración.

Si esto te resuena, hablemos. 30 minutos. Yo llamo.