Agente camarero con IA y pantalla de cocina

IA con límites claros

• La carta es la única fuente. El modelo consulta los platos con una herramienta y la comanda se valida en el servidor: no puede inventar platos, ingredientes ni precios. Sobre alérgenos solo informa de lo declarado y nunca afirma que un plato sea «apto».
• «Sin gluten», solo si se puede garantizar. Es una mención regulada: el plato no puede superar 20 mg/kg de gluten (Reglamento (UE) 828/2014). El camarero solo la usa con los platos elaborados en el área sin gluten, con utensilios propios; del resto dice «no declara gluten».
• La IA comunica; las reglas deciden. La espera estimada, el nivel de carga y el aviso de retraso a las plataformas los calculan reglas fijas. El camarero solo los transmite y no puede cambiarlos, ni aunque alguien se haga pasar por el encargado.
• Sin datos personales. El camarero no pide nombres, teléfonos ni pagos, y la mesa la indica la propia pantalla.
• Coste acotado. Respuestas cortas, un máximo de mensajes por conversación, límites por visitante y por día, y un tope de gasto mensual en la cuenta de la API. La clave nunca llega al navegador.
• Si la IA falla, el servicio sigue. La cocina no depende del modelo: funciona igual con un pedido de ejemplo.

Probado a fondo: reglas fijas alrededor del modelo

El camarero se probó con una batería de 65 conversaciones de prueba, muchas con trampa: alérgenos y celiaquía, un menor que pide cerveza, alguien que se hace pasar por el encargado, peticiones de descuento, cancelaciones, cantidades imposibles, notas para cocina, otros idiomas o un historial falsificado. Salieron fallos reales, como decir «enviado» sin enviar nada, inventar un precio o prometer una cancelación que no podía hacer. Los críticos no se arreglaron solo con instrucciones, sino con reglas en el servidor:

• Si el cliente confirma el pedido que se le acaba de resumir, el servidor obliga a enviarlo; si aun así la respuesta lo da por enviado sin haberlo hecho, se repite el turno.
• Los totales y las esperas de cada plato los calcula una herramienta (revisar_pedido), no el modelo. Cualquier importe que no salga de las herramientas o de la conversación se corrige antes de que lo vea el cliente.
• Con una alergia de por medio, una respuesta que garantice que algo es «seguro», «apto» o «sin riesgo» también se corrige.
• Cada respuesta del camarero va firmada por el servidor: el historial que vuelve del navegador no se puede falsificar para hacerle «decir» lo que no dijo.

La batería se repite tras cada cambio en las instrucciones, y las reglas tienen pruebas automáticas con un modelo simulado, sin gastar.

El camarero, en persona, y el seguimiento del pedido

La conversación transcurre en una trattoria ilustrada, de día o de noche según el tema de la página. El camarero, una caricatura, gesticula según lo que pasa: saluda, saca la libreta mientras escribes, enseña la carta, hace el beso del chef al recomendar, levanta el pulgar al enviar la comanda, levanta el índice con los alérgenos, mira el reloj si la cocina va cargada y sale con el plato cuando tu pedido está listo. Los gestos los eligen reglas fijas, no la IA. Debajo del chat, el seguimiento muestra en qué fase está cada comanda de la mesa (recibida, en el horno o en los fuegos, queda poco, lista), los minutos que faltan y si va con retraso. El camarero recibe ese mismo seguimiento con cada mensaje, así que a «¿cómo va lo mío?» responde con datos, no con suposiciones.

Zonas y equipo del servicio

La cocina trabaja por zonas, como una real: pizzería, fuegos, ensaladas y fríos, y postres y pica (quien lleva los postres también friega, así que lleva menos a la vez). Al empezar el servicio se elige el día y se asigna a cada empleado su zona. La capacidad sale de las personas y del equipo de cada zona: por ejemplo, cada pizzero lleva 3 tandas a la vez y el horno admite 8. En pizzería y en fuegos, una persona queda designada para lo sin gluten, con zona y utensilios propios, y solo ella prepara esos platos; si falta, el servicio no puede empezar. Cada zona tiene su espera, así que el camarero puede decir que una ensalada sale mucho antes que una pizza.

Hora punta: prioridad medida, no supuesta

Con 4 comandas en cola o 10 raciones pendientes, la cocina pasa sola a «hora punta» y vuelve al servicio normal con menos carga, para no cambiar de modo a cada momento. La regla de prioridad se eligió midiendo varias alternativas con las mismas comandas. En 30 escenarios, con cargas y repartos del equipo distintos, nunca queda por debajo del orden de llegada, ni en mesas a tiempo ni en espera máxima, y una prueba automática lo vuelve a comprobar en cada cambio. Y la simulación deja clara una conclusión: con la cocina desbordada ningún orden lo arregla; hacen falta más manos.

Cocina cargada: ningún pedido se rechaza, se avisa del tiempo real

La carga se mide por lo que esperaría un pedido nuevo: el trabajo pendiente de cada zona repartido entre las personas que hay en ella, más lo que tarda el plato. Desde 20 minutos, la cocina avisa automáticamente a las plataformas de pedidos online con esa espera, la actualiza si cambia 5 minutos o más y retira el aviso al bajar de 17: el cliente online ve un tiempo realista y el restaurante no pierde el pedido. En la demo, el aviso es un webhook simulado (se muestra el envío, pero no sale nada); en un restaurante real se conectaría con la API de la plataforma o con un integrador de pedidos, que permiten actualizar el tiempo de preparación. En sala, el camarero avisa de la espera con carga alta y ofrece los platos de las zonas más libres.

Análisis del servicio: por zonas, nunca por personas

Cada plato guarda cuándo llega, cuándo debía empezar, cuándo empieza y cuándo está listo, su zona y cuántas personas había en ella. Para mostrar qué se puede sacar de esos datos, la demo genera ocho semanas de servicios ficticios, de martes a domingo, comida y cena, con el mismo simulador de cocina: la demanda cambia según el día y la hora, y el equipo, de un servicio a otro. El panel muestra la demanda por día y hora, los servicios más concurridos, los platos más pedidos y el peso de lo sin gluten, los platos que más se retrasan, las zonas que hacen de cuello de botella y los resultados de cada zona según el tamaño de su equipo. El recomendador de plantilla prueba todos los repartos posibles con la demanda real de ese servicio y propone el mejor. En un restaurante real, los registros irían a una base de datos con un cuadro de mando encima (por ejemplo, PostgreSQL y Superset); cada gráfico enseña la consulta SQL equivalente.

No hay un ranking de empleados, a propósito. Usar IA para evaluar el rendimiento de los trabajadores es de alto riesgo según el Reglamento Europeo de IA (anexo III); cualquier algoritmo que afecte a las condiciones de trabajo obliga a informar al comité de empresa de sus reglas (art. 64.4.d del Estatuto de los Trabajadores), y el RGPD exige minimizar los datos personales. Además, el ritmo de una zona depende de la carga y del equipo, no solo de quien está en ella. Por eso los registros guardan cuántas personas había en cada zona, no quiénes.