Predicción demanda IA restaurante: compra mejor

Pronosticar no es adivinar ni automatizar la compra

Una predicción de demanda estima una cantidad futura para una unidad y un horizonte definidos: cubiertos para la cena de mañana, porciones de un plato por turno o unidades de una categoría durante la próxima semana. El resultado puede apoyar preparación, personal o compras, pero no decide por sí solo cuánto pedir.

Esa última decisión incorpora existencia útil, merma, pedidos abiertos, rendimiento de recetas, plazo del proveedor, presentación de compra, vida útil, capacidad y costo de equivocarse. Confundir forecast con orden de compra convierte una estimación incierta en una acción rígida.

El contexto sí merece atención. El Programa de las Naciones Unidas para el Medio Ambiente estimó que el sector de servicios alimentarios generó 290 millones de toneladas de desperdicio de alimentos en 2022 a escala global. Es una estimación sectorial que incluye partes comestibles y no comestibles; no significa que un restaurante particular desperdicie un porcentaje fijo de sus compras ni demuestra cuánto podría ahorrar con IA.

Regla de salida: no conectes un pronóstico a producción o compras hasta que venza a un baseline sencillo en periodos futuros no vistos, muestre sesgo aceptable para el caso, declare incertidumbre y conserve una aprobación humana y un camino de regreso.

Define la decisión, unidad y horizonte

“Predecir la demanda del restaurante” es demasiado amplio. Completa una ficha por caso:

Elemento	Pregunta
Decisión	¿Preparar, comprar, programar personal o reservar capacidad?
Variable objetivo	¿Cubiertos, porciones, unidades o kilos consumidos?
Granularidad	¿Local, canal, turno, plato o ingrediente?
Horizonte	¿Siguiente turno, varios días o ciclo de compra?
Momento de corte	¿A qué hora se emite la predicción?
Usuarios	¿Quién revisa y puede modificar la recomendación?
Costo del error	¿Qué cuesta sobrepronosticar y qué cuesta quedarse corto?
Acción permitida	¿Solo consulta, sugerencia o ejecución con aprobación?

Un horizonte corto puede aprovechar reservas ya confirmadas; uno largo necesita representar mayor incertidumbre. Un forecast por plato ayuda a preparación, pero no se convierte en ingredientes sin recetas y rendimientos vigentes. Un pronóstico agregado de cubiertos puede ser correcto mientras falla en la mezcla de platos.

Evita empezar con todas las combinaciones local × turno × canal × plato. Muchas series tendrán pocos datos o demasiados ceros. Elige un nivel con volumen suficiente y una decisión concreta; añade detalle solo si mejora la acción.

La demanda observada no siempre es la demanda real

Las ventas registran lo que se pudo vender, no necesariamente lo que el cliente quiso comprar. Si un plato se agotó a mitad del servicio, las ventas posteriores aparecen como cero aunque hubiera demanda. Si el POS no distingue “agotado”, el modelo puede aprender que ese producto perdió popularidad.

Marca:

periodos con ruptura de stock o artículo oculto;
cierres parciales y horarios especiales;
devoluciones, cortesías, anulaciones y pruebas;
cambios de receta, tamaño o precio;
aperturas, remodelaciones y cambios de capacidad;
canales que entraron o salieron;
eventos privados y ventas atípicas identificables.

No borres automáticamente los valores atípicos. Un concierto cercano puede ser una anomalía para el calendario normal y, al mismo tiempo, un evento repetible que merece una variable.

Datos disponibles al momento de pronosticar

La regla contra el data leakage es simple: una variable solo puede usarse si estaba disponible, con esa versión, cuando habría salido el forecast histórico.

Señales internas

ventas por unidad objetivo y fecha de servicio;
disponibilidad y rupturas de stock;
reservas conocidas al corte, incluidas cancelaciones esperables sin identificar personas;
calendario operativo, capacidad y canal;
menú y precio vigentes en ese momento;
promociones confirmadas antes del corte;
inventario y pedidos con su propia frescura;
merma medida con definición estable.

Señales externas

festivos y calendario local conocidos;
eventos confirmados con fecha de publicación;
pronóstico meteorológico tal como existía al corte, no el clima observado después;
cambios planificados en acceso, terraza u horario.

Guardar solo el clima real produce fuga de información al evaluar el pasado: el modelo histórico recibe una precisión que el equipo no tenía al decidir. Si usas un proveedor externo, conserva timestamp, versión, disponibilidad y condiciones del plan; no describas una API como “gratuita” de forma permanente.

Los datos personales rara vez son necesarios. Para ocupación, usa conteos agregados de reservas en lugar de nombres, teléfonos, preferencias o notas de salud. Define finalidad, acceso y conservación conforme a la LFPDPPP vigente cuando exista tratamiento de datos personales.

Construye baselines antes del modelo

Un algoritmo sofisticado solo aporta valor si supera una alternativa simple bajo la misma prueba. Crea uno o varios baselines:

mismo turno del día equivalente anterior;
promedio o mediana móvil de periodos comparables;
promedio estacional por día de semana;
reserva confirmada al corte más una tasa histórica de demanda sin reserva;
pronóstico manual actual del chef o gerente, guardado antes de conocer el resultado.

La mediana puede resistir mejor eventos extremos; el promedio reacciona de otra forma. No elijas después de ver el periodo de prueba. Documenta la fórmula y congélala para una comparación honesta.

“IA” también es una etiqueta comercial. Una regresión o método estadístico sencillo puede rendir mejor que un modelo complejo cuando los datos son escasos. Evalúa el resultado, la estabilidad y la explicación operativa, no el nombre de la tecnología.

Backtesting temporal: entrenar en el pasado, probar en el futuro

Dividir filas al azar mezcla pasado y futuro y puede inflar el desempeño. Usa cortes temporales:

entrena con un bloque inicial;
pronostica el siguiente periodo como si estuvieras en esa fecha;
avanza el corte;
vuelve a entrenar solo con datos disponibles;
repite sobre varios ciclos y temporadas relevantes.

Esta evaluación de origen móvil muestra cómo se comporta el sistema ante cambios reales. Mantén un conjunto final sin tocar para la decisión de lanzamiento y segmenta resultados por local, horizonte, turno y unidad. Un promedio global puede esconder que el modelo falla justo los sábados de mayor impacto.

El historial suficiente depende de la estacionalidad y los cambios del negocio. Tres meses pueden bastar para un piloto acotado sin ciclo anual; no bastan para afirmar que el modelo conoce todo el año. Doce meses tampoco solucionan un menú totalmente nuevo. Declara qué patrones están representados y cuáles quedan fuera.

El backtesting respeta el tiempo: cada predicción se evalúa solo con información que existía antes de observar la demanda real.

Métricas: tamaño, dirección y costo del error

No existe una “precisión de ±15%” válida para todo restaurante. Elige métricas antes de evaluar y conserva valores por segmento.

MAE: error absoluto medio

MAE = promedio(|pronóstico − real|)

Se expresa en la unidad de la demanda. Un MAE de cuatro porciones significa que el error absoluto promedio fue de cuatro porciones; no dice si el modelo siempre pidió de más.

WAPE: error absoluto ponderado

WAPE = suma(|pronóstico − real|) / suma(real)

Resume el error relativo sobre un conjunto y pesa más los periodos con mayor volumen. No lo calcules si la demanda total del segmento es cero y no lo uses como única métrica para artículos de baja rotación.

Sesgo: dirección sistemática

Sesgo = suma(pronóstico − real) / número de observaciones

Con esta convención, un valor positivo indica sobrepronóstico promedio y uno negativo, subpronóstico. Declara la convención porque otras herramientas invierten el signo. Un MAE aceptable con sesgo constante puede acumular merma o quiebres.

Costo ponderado

El costo de una porción sobrante no siempre equivale al de un plato no disponible. Define una función con el equipo: costo evitable de excedente, oportunidad perdida, urgencia del proveedor, vida útil y capacidad de reutilización segura. No conviertas automáticamente toda diferencia en ahorro contable.

Intervalos y cobertura

Publica un rango, no solo un punto. Evalúa qué proporción de resultados cae dentro del intervalo anunciado y qué tan ancho es. Un rango que siempre cubre porque es enorme no ayuda; uno estrecho que falla en picos genera falsa confianza.

De platos a producción y compras

El forecast es una entrada a otra fórmula. Para una preparación, una lógica conceptual podría ser:

necesidad = demanda prevista + colchón aprobado − existencia útil − producción ya comprometida

Después aplica rendimiento, porción, lote, vida útil y capacidad. Para compra, añade pedidos en tránsito, presentación del proveedor, lead time, frecuencia de entrega y stock de seguridad diseñado para el costo del error.

Mantén separados:

demanda prevista: lo que podría solicitar el cliente;
producción recomendada: lo que conviene preparar bajo restricciones;
compra sugerida: lo que falta después de existencias y pedidos;
orden autorizada: decisión humana y compromiso con proveedor.

La predicción de etiquetas, añadas y reposición de vino tiene otras restricciones y pertenece a predicción de demanda de vinos. La optimización del portafolio y rentabilidad del menú corresponde a IA para optimizar el menú. Medición y reducción de residuos se desarrolla en IA y desperdicio alimentario. Aquí la frontera es evaluar demanda de platos o cubiertos.

Overrides humanos con evidencia

El equipo conoce información que puede no estar en los datos: una obra cerró la calle, un grupo cambió su selección o el chef redujo capacidad. Permite modificar la recomendación, pero registra:

forecast original y versión del modelo;
valor modificado;
rol y momento del cambio;
motivo estructurado y nota breve;
información nueva disponible;
resultado real;
error del modelo y del override.

Revisa después si los overrides mejoraron la decisión por tipo de motivo. No uses el registro para castigar a quien discrepa: úsalo para añadir variables, ajustar protocolos y detectar confianza excesiva en ambos sentidos.

Lanzamiento por etapas

1. Calidad y baseline

Define objetivo, corrige mapeos, marca disponibilidad y ejecuta el baseline. Si el dato de ventas no representa demanda, el primer proyecto es mejorar el registro.

2. Backtest reproducible

Congela datos, variables y métricas. Ejecuta ventanas temporales y publica resultados completos, no solo el mejor periodo.

3. Modo sombra

Genera forecasts sin cambiar producción ni compra. Compara modelo, baseline y decisión humana. Mide además puntualidad, fallos de fuente y cuántas recomendaciones llegan demasiado tarde.

4. Recomendación con aprobación

Permite que un grupo pequeño use el forecast como una señal. Muestra intervalo, frescura de datos y limitaciones. Conserva el procedimiento anterior si la fuente o el modelo no está disponible.

5. Expansión gradual

Amplía por local, horizonte o familia solo si existe evidencia. Automatizar una acción de mayor impacto exige controles adicionales, límites de cantidad, aprobaciones e idempotencia.

NIST organiza la gestión del riesgo de IA en las funciones Govern, Map, Measure y Manage. Para este caso: asigna responsables y tolerancia; documenta contexto y daños; mide desempeño y riesgo; decide despliegue, monitoreo, respuesta y retiro. No es una certificación ni una garantía, sino un marco voluntario adaptable.

Drift y operación continua

Un modelo no mejora automáticamente por acumular semanas. Puede degradarse cuando cambia el menú, precio, canal, clientela o proceso de captura. Monitorea:

error y sesgo por horizonte y segmento;
cobertura y amplitud del intervalo;
variables ausentes o atrasadas;
proporción de artículos nuevos o sin historial;
cambios en la distribución de entradas;
frecuencia y resultado de overrides;
rendimiento frente al baseline vigente;
costo operativo de ejecutar el sistema.

Define umbrales de revisión con base en la tolerancia del restaurante, no cifras universales. Ante degradación, puedes volver al baseline, ampliar revisión humana, excluir una serie o detener recomendaciones. Conserva versión de datos, código, configuración y modelo para reconstruir cada forecast.

Casos límite

Artículo nuevo: usa analogías documentadas, agregación por categoría o una regla manual; declara alta incertidumbre.

Evento extraordinario: incorpóralo solo si la información era conocida al corte y existe suficiente analogía; si no, permite escenario manual.

Cambio de precio o menú: no atribuyas causalidad solo porque demanda y cambio coincidieron. El forecast predice; no demuestra por qué ocurrió.

Fallo de fuente: usa el último dato solo si se marca su antigüedad y la política lo permite. Para decisiones de riesgo, vuelve al baseline o detén la sugerencia.

Cómo evaluar un proveedor

En lugar de comparar precios desactualizados, pide una demostración con datos propios y pregunta:

¿qué unidad y horizontes pronostica realmente?;
¿qué variables estaban disponibles al momento del corte histórico?;
¿contra qué baseline se evaluó?;
¿qué métricas muestra por segmento?;
¿ofrece intervalos, sesgo y explicación de frescura?;
¿cómo trata agotados, productos nuevos y datos faltantes?;
¿guarda forecast original y override?;
¿cómo se exportan datos y versiones?;
¿qué ocurre si termina el contrato?;
¿qué afirmaciones de ahorro vienen de clientes comparables y bajo qué método?;

No traslades resultados de marketing de un proveedor a tu restaurante como garantía. Calcula el valor con un piloto y compara costos reales antes y después, controlando cambios operativos relevantes.

Kavasoft como contexto de datos, no promesa de forecast

El inventario, los movimientos, las fotografías y las auditorías de cava pueden aportar contexto para decisiones de disponibilidad o reposición. Eso no significa que Kavasoft produzca actualmente un forecast, prediga visitas, aprenda preferencias individuales o genere pedidos.

Si quieres relacionar datos de cava con otra herramienta, confirma el alcance para restaurantes: campos exportables, identificadores, historial, permisos, integración y plan. Mantén la predicción de alimentos separada de la custodia y preferencias de socios, y evita usar datos personales cuando bastan agregados.

Checklist de decisión

Fuentes y lecturas recomendadas

UNEP: Food Waste Index Report 2024, estimaciones y metodología global para medir desperdicio en hogares, servicios alimentarios y retail, con sus límites de evidencia.
NIST: AI Risk Management Framework, marco voluntario para gestionar riesgos de sistemas de IA durante su ciclo de vida.
NIST AI RMF Core, resultados y prácticas de Govern, Map, Measure y Manage, incluidos supervisión, documentación, monitoreo y mejora.
Cámara de Diputados: Ley Federal de Protección de Datos Personales en Posesión de los Particulares, texto vigente para evaluar el tratamiento de datos personales en México.