Computer vision para detectar mesas sucias: el caso Dodo Pizza

Resumen en un minuto

Un cliente sentado en una mesa con migas de pizza y un vaso a medio terminar del comensal anterior no escribe "el salón necesita aseo" en la reseña. No vuelve y deja dos estrellas en Google Maps. La visión por computadora ya detecta el segundo exacto en que la mesa se libera y dispara la alerta al mozo. En LATAM, las cadenas QSR la están implementando con fuerza, y Dodo Pizza es uno de los casos más diseccionados en conferencias de ingeniería.

• Una mesa sucia cuesta entre 3 y 7 USD por hora de pico. En un salón de 30 mesas con 5 horas pico, son 450 a 1 000 USD diarios de ingresos perdidos.
• Stack productivo de computer vision restaurante mesas: YOLOv8/YOLO11 + cámara RTSP + edge device (NVIDIA Jetson Orin Nano). Precisión 92-96% de f1-score.
• Dodo Pizza arrancó con CV en zona de despacho — la pizza lista lleva más de 30 segundos en el mostrador → alerta. Después extendió el modelo a detección de estado de mesas en salón.
• Detalle LATAM: las cámaras en salón están reguladas por LGPD (Brasil), LFPDPPP (México), Ley 29733 (Perú), Ley 1581 (Colombia). Toca aviso visible y privacy-by-design.
• Presupuesto MVP por restaurante: 1 500-3 000 USD en hardware más 60-120 horas de un ingeniero ML. El payback se cierra entre 3 y 6 meses.

Por qué vale la pena detectar mesas sucias

En un restaurante con servicio en mesa, la velocidad de rotación (table turnover) es ingreso directo. Cada minuto entre "los clientes se fueron" y "la mesa está lista para sentar a otros" es una ocupación perdida. En cadenas QSR con dine-in — Dodo Pizza, Burger King, KFC, Starbucks — la rotación media de una mesa se mueve entre 20 y 35 minutos. Si la persona de aseo nota la mesa con 4 a 6 minutos de retraso, la rotación cae 10 a 15%.

El segundo dolor es reputacional. El cliente se sienta en la mesa con migas del comensal anterior, foto en Instagram Stories, reseña "está sucio" en Google Maps. En LATAM, donde Google Maps mueve el tráfico físico en zonas turísticas de Lima, Cartagena y CDMX, una reseña así cuesta más que el sueldo mensual del personal de aseo.

El tercero es gerencial: nadie pone KPI sobre lo que no se mide. Antes de CV, "velocidad de aseo de la mesa" era un mito. El gerente reportaba "todo limpio" y verificarlo implicaba recorrer el salón en persona.

La visión por computadora para retail y restaurantes cierra las tres. La cámara ve el salón 24/7, un modelo de object detection evalúa cada mesa en cada frame: "ocupada", "se fueron los clientes", "sucia", "limpia, lista". La métrica "tiempo medio desde que se van hasta que la mesa está lista" se vuelve un número real sobre el que se pagan bonos.

Cómo funciona técnicamente

El stack que hoy eligen el 80% de los proyectos QSR en LATAM se arma sobre seis componentes. Si te falta uno o lo cambias por algo "más simple", la precisión cae por debajo del 85% y los mozos pierden confianza en las alertas en dos semanas.

#1. Fuente de video

Cámaras IP de salón ya instaladas (flujo RTSP, 1080p, 15-25 fps). No hace falta comprar cámaras nuevas: sirven las mismas que se usan para seguridad. La condición es que sean digitales — el CCTV analógico no se conecta al pipeline.

#2. Edge device en el restaurante

Un NVIDIA Jetson Orin Nano de 249-499 USD, o un mini-PC con GPU. Aquí corre el modelo en tiempo real y los frames no salen del local — es crítico para privacidad y para evitar 200-400 USD mensuales de tráfico RTSP a la nube.

#3. Modelo de detección

Object detection de la familia YOLO, normalmente YOLOv8m o YOLO11s, entrenado sobre un dataset propio de "mesa sucia / mesa limpia". El modelo base de COCO no sabe cómo se ve "mesa con migas de pizza" — toca reentrenarlo sobre 800-2 000 imágenes etiquetadas del restaurante concreto. La documentación oficial de Ultralytics cubre el flujo de fine-tuning paso a paso.

#4. Lógica de estados

Encima del detector hay una state machine. Un frame solo no resuelve nada: "mesa sucia en 1 frame" puede ser una sombra o la mano de un mozo. La alerta se dispara si 5 frames consecutivos en 10 segundos muestran el mismo estado. Las operaciones básicas con frames van por OpenCV.

#5. Cola de eventos e integración

Apache Kafka o un broker MQTT envía los eventos al sistema de operaciones. La notificación al mozo llega a Slack o Telegram — en LATAM, el estándar es WhatsApp Business API. Si el restaurante ya usa Odoo POS, conviene revisar el caso Dodo Pizza Real-Time Order Chain.

#6. Dashboard

El gerente ve un mapa del salón con colores por mesa, el tiempo medio de aseo por turno y los tres mozos más lentos. Sin este último componente, el sistema queda como un detector que nadie audita.

La precisión productiva queda entre 92 y 96% de f1-score. Significa que el 4-8% de las alertas son falsos positivos o falsos negativos (una mesa sucia no se detecta durante 30 segundos). Es un umbral tolerable con la state machine bien afinada.

El caso Dodo Pizza: de dónde arrancaron, a dónde llegaron

Dodo Pizza es una cadena global con más de 1 000 puntos, montada sobre su propia plataforma Dodo IS y conocida por su transparencia operacional pública (dashboards de ventas en vivo). Opera en México, Brasil, Nigeria, Reino Unido y otros mercados.

El primer caso de CV en Dodo no fue mesas sino la zona de despacho: una cámara sobre el mostrador detectaba que una pizza terminada llevaba más de 30 segundos esperando y avisaba al repartidor o al personal de salón. Esto bajó el tiempo "lista → en mano del cliente" en un porcentaje de dos dígitos.

Después el equipo extendió el enfoque. Según materiales públicos del blog de ingeniería de Dodo en Habr y presentaciones en conferencias técnicas, el CV en Dodo cubre hoy tres frentes: control de calidad del producto terminado (forma de la pizza, temperatura de la caja), control de zona de despacho (tiempo de espera) y control de salón y aseo (detección de basura y estado de mesas).

En las tiendas LATAM la detección de mesas sucias es más crítica que en las rusas. En México y Brasil Dodo apuesta a dine-in; las pizzerías rusas, en cambio, viven de delivery. Por eso el perímetro mexicano-brasileño se volvió el piloto natural para table-status-CV.

Dodo no compra un producto "de caja" a un vendor de CV. Arma el stack con componentes open source — YOLO, OpenCV, Kafka — y mantiene el modelo en el edge device. Esto les da dos cosas: control sobre los datos (los frames de salón no salen del local) y la capacidad de re-entrenar bajo particularidades locales (el comensal mexicano deja basura distinta a la del ruso).

Cuándo funciona, cuándo se rompe

El piloto rinde si el concepto es dine-in con 15 o más mesas y pico real de fin de semana. En 5 mesas el ROI no cierra. Hay tres condiciones que pasan inadvertidas en las propuestas comerciales y rompen el proyecto si faltan.

Funciona limpio cuando:

• El concepto es dine-in con 15+ mesas y pico de almuerzo o cena de fin de semana.
• El restaurante ya tiene cámaras IP — o estás dispuesto a poner el set inicial de 500-1 500 USD por punto.
• Hay integración POS para cruzar "mesa libre según POS" contra "mesa libre según cámara". Esto cierra el cold start.

Funciona con ajuste fino cuando:

• La iluminación cambia mucho en el día (ventanales, sol directo). El dataset tiene que cubrir distintas horas o el f1 cae en el turno noche.
• El salón se reordena cada cierto tiempo. Cada mesa es un region of interest separado y toca re-etiquetar.
• Hay mesas de vidrio o superficies muy reflectantes. El modelo se confunde con reflejos: necesitas datos adicionales.

No funciona — o sale caro — cuando:

• Es fast-food con bandeja desechable y el cliente recoge solo. El problema deja de ser "mesa sucia" y se vuelve "bandeja no retirada": otro modelo, otra lógica de negocio.
• El salón es chico (5-8 mesas). Sale más barato pagar un recorrido cada 7 minutos del personal de aseo.
• La gerencia no actúa sobre las alertas. Si "mesa 7 sucia hace 40 segundos" no genera respuesta, el sistema degrada hasta el ignored-by-default en dos semanas.

Errores típicos de implementación

#1. Arrancar con un modelo pretrained y no re-entrenarlo

La YOLO base conoce las 80 clases de COCO — "sofá", "persona", "tenedor" — pero no sabe qué es "mesa sucia después de una pizza". Con el modelo pretrained sin fine-tuning te quedas en 50-60% de precisión en producción, lo que enfurece a los mozos y mata la confianza en el sistema. El piso mínimo son 800 imágenes etiquetadas del restaurante específico.

#2. Mandar el video al cloud

RTSP al cloud equivale a 200-400 USD/mes de tráfico por restaurante más el riesgo de privacidad (multas LGPD/LFPDPPP). Inference en edge, al cloud van únicamente eventos del tipo {"table":7,"status":"dirty"}.

#3. Alerta sin acción operativa

Se instala el sistema pero "tiempo de aseo de mesa" no entra en los KPI del mozo. En dos semanas las alertas se ignoran. CV sin reforma operativa son dólares quemados.

#4. Ignorar la regulación LATAM

En Brasil la LGPD exige aviso visible de videovigilancia (ver ANPD). En México la LFPDPPP la supervisa INAI. Ignorarlo es multa más crisis de PR. Privacy-by-design: los rostros se difuminan en edge, los frames no se persisten.

#5. Un solo dataset para toda la cadena

Un modelo entrenado en CDMX no funciona en Cartagena (otras mesas, otra iluminación, otra comida). Fine-tuning por cluster de restaurantes.

Caso anónimo: pizzería de 22 mesas en CDMX

Pizzería independiente — no Dodo — con 22 mesas en una zona turística de la Roma Norte. Antes del piloto: turnover medio de 31 minutos por mesa, tiempo desde "se fueron los clientes" hasta "mesa lista" medido manualmente en 5,8 minutos. Costo declarado: aproximadamente 2 600 USD/semana en cubiertas perdidas durante el pico de viernes y sábado.

Piloto de 8 semanas: 2 cámaras IP existentes recableadas, 1 Jetson Orin Nano, modelo YOLOv8m fine-tuneado sobre 1 400 imágenes etiquetadas en CVAT. Costo de instalación: 4 800 USD entre hardware, integración con WhatsApp Business y horas de un ingeniero ML freelance limeño. Operación mensual: 380 USD.

Después del piloto (semana 8): tiempo medio de aseo bajó a 1,9 minutos, turnover se acortó a 27 minutos. Las cubiertas adicionales del pico se monetizaron en 1 350 USD/semana extra. Payback efectivo a la semana 16. El gerente acompañó el piloto agregando "tiempo de aseo" al cierre del turno.

Los primeros 14 días el sistema gritaba mucho y los mozos se quejaban. Recién después de fine-tunear contra falsos positivos por la iluminación del ventanal, la cosa se calmó.

Contexto LATAM: precio, leyes y la realidad del piloto

Presupuesto MVP por restaurante (mercado Lima / Bogotá / CDMX, mayo 2026):

Total piloto 3-5 puntos: 15 000-30 000 USD de inversión más 1 500-2 500 USD/mes de operación. Para contexto de presupuestos análogos, ver machine learning para retail y QSR.

Mínimo legal por país:

• BR: LGPD (Ley 13.709/2018). Aviso visible de cámaras y, para cadenas medianas, un Encarregado de Dados (DPO) designado.
• MX: LFPDPPP. Aviso de privacidad en la entrada y en el ticket. Regulador: INAI.
• PE: Ley 29733. Registro de la base de datos personal ante la ANPD Perú.
• CO: Ley 1581 de 2012. Habeas Data, registro en SIC.
• AR: Ley 25.326. Registro en AAIP y señalética visible.

Regla común a todas las jurisdicciones: en edge no se persisten frames, se procesa en tiempo real y al exterior solo salen eventos agregados ("mesa 7, sucia, 40 segundos").

Payback. Si el restaurante factura entre 20 000 y 50 000 USD/mes y el CV aporta entre 5 y 8% de mejora de turnover (resultado típico de piloto), son 1 000-4 000 USD/mes adicionales. ROI del piloto: 3-6 meses. A escala de cadena (50+ puntos) el costo unitario cae 2-3x gracias a dataset compartido y DevOps centralizado.

Qué hacer después

El CV para mesas es el primer paso. Los siguientes use-cases obvios — queue management en caja, control de SOP, detección de defectos del producto, monitoreo de drive-thru — son artículos separados. Para una definición general y el contexto histórico de la tecnología, conviene el panorama de Wikipedia sobre computer vision.

Si tu cadena tiene 5 o más restaurantes en LATAM y estás evaluando un piloto, conviene arrancar con un punto, un solo use-case ("mesa libre → alerta al mozo"), 4 semanas de recolección de datos y 4 semanas de piloto. Si en esas 8 semanas no llegas a 3% adicional de turnover, algo se diseñó mal.

Para profundizar en el stack o discutir el piloto con un equipo que ya implementó CV en QSR LATAM, conviene revisar la página del servicio Computer Vision o pedir directo un diagnóstico de 30 minutos.

Preguntas frecuentes