Control de inventario con IA en restaurantes: la merma que no aparece en ninguna cuenta

La escena que se repite cada semana en la cocina, y que nadie anota

Todo restaurante tiene una versión de esta escena. Es martes en la tarde, el cocinero abre la cámara fría y encuentra dos kilos de camarón con un color que ya no convence a nadie. Los huele, los mira una vez más, y los tira a la basura sin decírselo a nadie, porque interrumpir el servicio para llenar un papel no está en la cultura de esa cocina. El mismo día, el mesero grita mal un pedido, se cocina un plato que nadie pidió, y ese plato termina en la basura o, en el mejor de los casos, en el almuerzo del personal. Ninguno de los dos eventos aparece jamás en un reporte. No hay una cuenta contable que diga “merma de camarón: 2 kilos” ni “error de comanda: 1 plato”. Esos costos se disuelven dentro del costo de venta general, mezclados con lo que sí se vendió, y ahí se vuelven invisibles.

El dueño que revisa sus números cada mes ve un costo de insumos que sube sin que suban las ventas, y no tiene forma de saber si es porque el proveedor subió precios, porque el chef cambió las porciones, o porque la cocina está botando comida sin registrar nada. Sospecha, pero no puede señalar la causa. Y sin poder señalar la causa, no puede corregirla: puede bajar el precio del menú, presionar al proveedor, recortar personal, todo menos atacar el problema real, porque ese problema real nunca quedó escrito en ningún lado con su propio nombre.

Por qué la merma se esconde en la contabilidad y nadie la ve venir

La contabilidad de un restaurante casi nunca tiene una línea llamada “merma”. Lo normal es que el sistema de punto de venta registre las ventas, el proveedor mande una factura por lo comprado, y en algún punto alguien calcule el costo de venta como una resta entre lo que entró y lo que se vendió. Ese cálculo es correcto en teoría contable y es casi inútil para gestionar el negocio, porque mezcla en una sola cifra la merma real (lo que se dañó, se venció o se malgastó) con las diferencias de porcionado, los platos de cortesía, los errores de comanda y hasta los robos pequeños. Todo cae en el mismo balde, y en ese balde nadie distingue las causas.

La consecuencia práctica es que ningún sistema, con IA o sin ella, puede calcular algo que nadie registró por separado. Esto es lo primero que hay que aceptar antes de hablar de tecnología: la inteligencia artificial no descubre la merma escondida en una hoja de cálculo donde nunca se anotó. Necesita que alguien, todos los días, distinga entre “esto se vendió”, “esto se regaló”, “esto se dañó” y “esto se botó”. Sin esa distinción diaria, cualquier modelo predictivo trabaja sobre un número contaminado, y el resultado es una ilusión de precisión sobre datos que ya venían mal desde el origen.

Qué datos hacen falta y en qué formato, antes de pensar en modelos

Antes de evaluar cualquier proveedor de software conviene tener claro qué información hace falta reunir, porque de eso depende todo lo que venga después. No es un listado técnico complicado, es una disciplina de registro diario con cinco piezas concretas:

• Compras registradas por insumo y unidad: qué entró, cuándo, de qué proveedor, y en la misma unidad que usa la cocina (kilos, litros, unidades), no en “cajas” o “bultos” que cambian de peso según quien las llene.
• Recetario estándar por plato: cuánto insumo lleva cada plato que sale de cocina, para poder calcular cuánto debería haberse consumido según lo que se vendió ese día.
• Merma explícita, anotada el mismo día: qué se botó, por qué (vencido, dañado, error de comanda, cortesía) y cuánto, en la misma unidad que las compras.
• Ventas por plato, no solo el total del día: el punto de venta ya suele generar esto, el error común es no cruzarlo nunca con el consumo real de insumos.
• Fecha y turno: la merma de un lunes de lluvia no se parece a la de un sábado de quincena, y sin la fecha el histórico no sirve para proyectar nada.

Nada de esto exige comprar un sistema antes de empezar. La disciplina se puede sostener dos semanas con una planilla y un lápiz colgado en la pared de la cocina, y esa prueba corta ya dice más que cualquier demo de software. Empezar a usar IA en un restaurante casi siempre arranca aquí, no en la tecnología: en instalar el hábito de registrar antes de automatizar nada.

Predicción de demanda con el histórico que ya tienes, sin inventar datos nuevos

Una vez que existen esos datos día a día, y no antes, recién tiene sentido hablar de predicción. Un modelo de IA predictiva no inventa el futuro: mira el patrón de ventas de los últimos meses (qué se vendió cada día de la semana, en qué fechas hubo picos por quincena o feriado, cómo se comportó cada plato del menú) y proyecta una demanda probable para los próximos días. No es magia, es la misma lógica que usa un chef con experiencia cuando dice “el viernes se vende el doble de lomo saltado”, solo que el modelo la aplica mirando cientos de datos a la vez y no solo su memoria de las últimas semanas.

La ganancia real aparece cuando esa demanda proyectada por plato se traduce a insumos usando el recetario estándar. Si el sistema anticipa que el viernes se van a vender cuarenta porciones de lomo saltado, y la receta dice cuánta carne, cebolla y papa lleva cada una, el pedido de compra deja de basarse en “lo de siempre” y empieza a basarse en lo que la demanda real de esta semana sugiere. Eso ataca las dos formas de perder plata al mismo tiempo: faltar insumo a mitad de servicio y comprar de más algo que termina vencido el lunes siguiente.

Pedidos sugeridos a proveedor: de la demanda proyectada a la orden de compra

El paso siguiente, cuando la predicción de demanda ya funciona con datos propios, es que el sistema sugiera cuánto pedir a cada proveedor. La lógica combina tres cosas: cuánto insumo va a hacer falta según la demanda proyectada, cuánto queda ya en el almacén o la cámara fría, y cuánto tarda ese proveedor en entregar. Un proveedor que entrega el mismo día permite pedir casi al día, mientras uno que necesita tres días de aviso obliga a proyectar más lejos y a cargar con más inventario en el medio, con más riesgo de que algo se dañe antes de usarse.

La sugerencia no debería reemplazar la firma de quien aprueba la compra. Lo que cambia es la base de la decisión: en vez de pedir “lo de siempre” por costumbre, el encargado ve un número calculado a partir de la demanda real de las últimas semanas y decide si lo ajusta por algo que el sistema todavía no sabe (un evento privado reservado, una promoción, un cambio de carta). El criterio humano no desaparece, se mueve del “cuánto pido” al “por qué me desvío de lo que sugiere el sistema”, que es una pregunta mucho más fácil de responder con cabeza fría.

Cuando el pedido sugerido se cruza además con un cambio de carta, por ejemplo un plato que se retira o un precio que sube, conviene revisar primero cómo usar IA para la carta de un restaurante y sus precios, porque un cambio ahí mueve toda la proyección de insumos que viene después.

Lo que la IA no puede predecir en un restaurante, y quién tiene que cubrir eso

Un modelo entrenado con el pasado predice bien lo que ya vio repetirse. Fuera de eso, hay una lista de situaciones donde ninguna predicción va a acertar sola, y donde delegar la decisión completa en el sistema es un error caro:

• Reservas grandes de último momento: un evento privado confirmado el mismo día no está en ningún patrón histórico, y el sistema recién lo “aprende” después de que pase varias veces.
• Un plato nuevo en la carta: sin historial de ventas propio, cualquier proyección inicial es una suposición razonada, no una predicción con datos reales detrás.
• Quiebres del lado del proveedor: si el proveedor no entrega lo pactado, ningún modelo de demanda arregla eso, porque es un problema de la cadena de suministro, no de pronóstico.
• Un evento externo puntual: un partido importante, una noticia local, un cambio brusco de clima que nadie anticipó, o el cierre temporal de un competidor cercano que desvía tráfico de un día para otro.

Tratar la sugerencia del sistema como una orden ciega, sin nadie que la revise contra lo que se sabe del negocio esa semana en particular, es uno de los errores al usar IA en un restaurante que más rápido convierte una herramienta útil en una fuente nueva de merma. El modelo predice sobre lo que ya vio. Lo que nunca vio sigue siendo trabajo de quien dirige el local ese día.

Cómo se mide el ahorro: por qué aquí no hay un porcentaje que valga para todos

Esta es la pregunta que hace todo dueño primero, y la respuesta honesta empieza por decir que no existe un número universal de cuánto baja la merma con estos sistemas. Cualquier cifra que alguien te dé sin haber visto tu operación, tu volumen y tu forma actual de registrar, es una cifra de marketing, no un dato tuyo.

Lo que sí determina el resultado es medible, y depende de tres cosas concretas. Primero, qué tan mal está hoy el registro: un restaurante que hoy no anota nada tiene más margen de mejora que uno que ya lleva un control decente en una hoja de cálculo. Segundo, el volumen y la rotación de insumos frescos: un local con alta rotación de productos perecibles (pescadería, carnes, vegetales de hoja) tiene más expuesto que ganar que uno que trabaja sobre todo con insumos secos o congelados de larga duración. Tercero, la disciplina para sostener el registro diario después del entusiasmo de la primera semana, que es donde la mayoría de estos proyectos se cae.

El único número que sirve es el que se mide en la propia operación, comparando un “antes” contra un “después”. Eso significa registrar la merma en la moneda local, día por día, durante varias semanas, antes de tocar nada del proceso. Ese periodo de medición no es un paso opcional ni un capricho de consultor: es el único punto de referencia real. Sin ese “antes” documentado, cualquier “después” es una afirmación que nadie puede verificar, y un dueño que compara contra una sensación en vez de contra un número se termina convenciendo de un ahorro que quizás nunca ocurrió. Los ahorros reales, cuando existen, quedan documentados con su cifra propia en casos documentados, no en un promedio genérico de industria.

Mi criterio sobre por dónde empezar en un restaurante real

El control de inventario con IA empieza en la disciplina, no en el software

El control de inventario con IA en restaurantes casi nunca falla por el modelo predictivo. Falla porque nadie sostuvo el registro diario el tiempo suficiente para que hubiera algo de qué aprender. La tecnología para predecir demanda y sugerir pedidos ya existe y es accesible incluso para un local de barrio; lo que sigue siendo escaso es la costumbre de anotar, todos los días, qué se botó y por qué.

Por eso la pregunta que un dueño debería hacerse antes de evaluar cualquier proveedor no es “qué tan buena es su IA”, sino “¿mi cocina puede sostener un registro diario simple durante un mes?”. Si la respuesta es no, ahí está el proyecto real, y todavía no tiene nada que ver con algoritmos. Este orden, medir antes de automatizar, es el mismo criterio que sostiene el framework Arquitectura IA para cualquier proceso de una empresa, no solo para una cocina. La merma que no aparece en ninguna cuenta sigue sin nombre hasta que alguien decide ponérselo todos los días, aunque nadie esté mirando ese día en particular. Ese hábito, más que cualquier modelo, es lo que separa a un restaurante que reduce su fuga más grande de uno que sigue pagándola sin saber cuánto le cuesta.