IA Aplicada Caso real · 17 de junio de 2026 · 10 minutos de lectura

Del pedido a la puerta: un motor completo para restaurante creado con IA

Así he utilizado la inteligencia artificial para desarrollar para KaliSushi un sistema propio con carta digital, pedidos, reservas, pagos con tarjeta y Bizum, avisos por SMS, impresión en cocina y una aplicación web para gestionar a los motoristas y confirmar las entregas en tiempo real.

En apenas cinco horas construimos el núcleo del sistema de pedidos de KaliSushi. Después lo hemos seguido ampliando hasta cubrir todo el recorrido: desde que el cliente realiza el pedido hasta que el motorista confirma la entrega desde su móvil.

No era un ejercicio para aprender IA

El punto de partida fue KaliSushi, un restaurante que ya tenía web, carta digital e infraestructura propia. El objetivo era ir mucho más lejos: construir un sistema capaz de gestionar el pedido desde que el cliente elige los productos hasta que la información llega a cocina.

Además, había una condición importante: debía funcionar sobre la tecnología existente, formada por Windows Server, IIS, ASP clásico y SQL Server. No tenía sentido tirar una infraestructura que ya funciona para sustituirla por la tecnología de moda. La solución debía adaptarse al negocio, no obligar al negocio a adaptarse a la solución.

La innovación no consiste siempre en cambiarlo todo. Muchas veces consiste en aprovechar bien lo que ya existe y añadirle nuevas capacidades.

Qué hemos construido

La última pieza: una app para los motoristas

Una de las últimas ampliaciones ha sido la pantalla de reparto. Es una página web móvil, pequeña por fuera pero muy práctica por dentro, que permite a cada motorista consultar exactamente qué pedidos tiene asignados, abrir la dirección del cliente y confirmar la entrega.

Antes, cuando un pedido salía del restaurante, cocina sabía que estaba listo, pero no tenía una confirmación clara de cuándo había llegado al cliente. Si alguien llamaba preguntando por su pedido, era difícil saber si el motorista seguía de camino o si ya lo había entregado.

No necesitábamos una aplicación cara ni compleja. Necesitábamos resolver tres cosas muy concretas:

• Que el motorista viera los pedidos que tenía asignados.
• Que pudiera confirmar la entrega desde su propio teléfono.
• Que esa confirmación llegara automáticamente al panel de administración.

Acceso por PIN, sin instalaciones

Cada repartidor tiene un PIN de cuatro dígitos configurado desde el panel. Al entrar en la página ve una cuadrícula con los nombres de los motoristas, toca el suyo, introduce el PIN y accede. No hay que instalar ninguna app ni recordar un usuario y una contraseña convencional.

La sesión permanece activa durante ocho horas, suficiente para cubrir un turno completo.

Un panel pensado para repartir, no para administrar

Una vez identificado, el motorista ve los pedidos organizados en tres grupos:

Cada tarjeta muestra el nombre del cliente, el teléfono como enlace directo para llamar, la dirección con acceso inmediato a Google Maps, los productos del pedido y el importe total.

Confirmar la entrega con un toque

Cuando el pedido está listo aparece el botón Confirmar entrega. Al pulsarlo, el estado cambia a entregado en la base de datos. La pantalla del motorista se actualiza automáticamente cada 45 segundos para recoger nuevas asignaciones sin tener que recargarla manualmente.

Cocina también sabe que el pedido ha llegado

El panel de administración ya emitía un aviso sonoro al recibir un pedido nuevo. Para no confundir ambas situaciones, añadimos un segundo sonido específico para las entregas confirmadas.

El pedido nuevo utiliza tres notas agudas y rápidas, pensadas para llamar la atención. La entrega confirmada utiliza un acorde ascendente más suave —Do, Mi y Sol— que transmite cierre en lugar de urgencia.

También cambia el título de la pestaña del navegador:

• Pedido nuevo: 🔔 ¡PEDIDO NUEVO!
• Entrega confirmada: ✅ Entrega confirmada

El panel compara las entregas confirmadas durante el día con el contador que tenía almacenado en la recarga anterior. Si el número aumenta, reproduce el aviso. La primera vez que se abre durante el día solo guarda el estado actual, evitando notificaciones innecesarias.

La parte técnica

La aplicación utiliza el mismo entorno que el resto del motor: Windows Server, IIS, ASP clásico y VBScript. La autenticación se gestiona con sesiones de ASP, los avisos sonoros se generan directamente en el navegador mediante la Web Audio API y el panel detecta los cambios comparando el valor del servidor con un contador almacenado en localStorage.

No es una aplicación creada para impresionar en una presentación. Es una herramienta sencilla que resuelve exactamente lo que ocurre entre la cocina, el motorista y la puerta del cliente.

La parte más importante no es el código

Cuando se habla de inteligencia artificial aplicada al desarrollo, muchas veces parece que basta con escribir una frase y esperar a que aparezca una aplicación completa. No funciona así.

La IA acelera muchísimo el trabajo, pero necesita dirección, contexto y criterio. En este proyecto mi función fue definir la arquitectura, explicar las reglas del negocio, decidir qué debía conservarse, revisar el código, probar cada flujo y corregir lo que no funcionaba.

Llevo trabajando con servidores, bases de datos, webs y automatización desde 1997. Esa experiencia no desaparece al utilizar IA. Al contrario: la IA multiplica el valor de lo que ya sabes.

Así fue el proceso

1. Convertir la carta real en datos.
   La IA analizó la carta, identificó categorías, productos, variantes y precios, y ayudó a transformarlos en una estructura preparada para la base de datos.
2. Construir sobre la infraestructura existente.
   Todo se desarrolló respetando ASP clásico, IIS y SQL Server. Cuando una propuesta se desviaba hacia otra tecnología, se corregía inmediatamente.
3. Reutilizar código que ya funcionaba.
   Yo ya disponía de una integración antigua de Redsys. Funcionaba, pero su estructura y su presentación podían mejorarse. Se entregó a la IA para que la leyera, entendiera y adaptara al nuevo motor.
4. Probar con operaciones reales.
   No bastaba con que el código pareciera correcto. Se realizaron pruebas del carrito, del flujo del pedido, del SMS y de un pago real.
5. Corregir en ciclos muy cortos.
   Cada problema se aislaba, se explicaba y se resolvía antes de pasar al siguiente módulo. Esa forma de trabajar evitó acumular errores.

Un ejemplo: la integración con Redsys

Esta fue una de las partes más interesantes. El sistema debía aceptar pagos con tarjeta y Bizum, verificar correctamente la notificación enviada por Redsys y actualizar el pedido en la base de datos.

En lugar de empezar de cero, entregué a la IA una solución anterior que ya utilizaba en ASP clásico. La analizó, entendió la clase de comunicación con Redsys, la firma criptográfica y las páginas de respuesta. Después la reorganizó y la integró en el nuevo proceso de compra.

La diferencia entre el pago con tarjeta y Bizum no exigía crear dos sistemas independientes. Compartían la misma arquitectura y solo cambiaban determinados parámetros. Detectar esto permitió simplificar el desarrollo y evitar duplicar código.

Le pasé una lógica que ya funcionaba. La leyó, la entendió, la mejoró y la conectó con el nuevo sistema. Para mí, ese es uno de los mejores ejemplos de IA aplicada.

Por qué se pudo hacer en cinco horas

La cifra de cinco horas corresponde al núcleo inicial del sistema y sigue siendo muy importante, pero no debe utilizarse como un titular vacío. Lo importante es entender que una persona con experiencia, apoyada por una IA bien dirigida, puede construir en una mañana lo que antes habría requerido muchos días de programación repetitiva.

Qué cambia para el restaurante

El restaurante no depende de una plataforma externa para gestionar sus pedidos directos. El sistema está dentro de su propia web, se conecta con su pasarela bancaria y puede adaptarse a sus horarios, productos, zonas de reparto, mesas y forma de trabajar.

• Control del sistema y de los datos.
• Pedidos directos sin la comisión comercial de un marketplace externo.
• Reglas propias para local, barra, recogida y domicilio.
• Integración con cocina, reservas, clientes, motoristas y comunicación.
• Posibilidad de seguir ampliándolo sin empezar de nuevo.

Naturalmente, la pasarela bancaria, el envío de SMS y otros servicios técnicos pueden tener sus propios costes. La diferencia es que el restaurante no entrega el control de todo su canal digital a una plataforma ajena.

Esto es lo que quiero contar en IA Aplicada

No me interesa publicar una lista interminable de herramientas ni repetir que la inteligencia artificial va a cambiarlo todo. Me interesa enseñar qué ocurre cuando se aplica a un problema real.

En este caso, la IA ha servido para leer información, estructurar datos, comprender código anterior, generar nuevas funciones, localizar errores, adaptar una pasarela de pago, crear el flujo móvil de reparto y acelerar las pruebas. Pero las decisiones, la validación y la responsabilidad siguen siendo humanas.

La IA no sustituyó mi experiencia. Me permitió utilizarla a otra velocidad.

Lo que vino después: cuatro cambios de lógica en una tarde

El sistema entró en producción y el cliente empezó a usarlo. Pocas horas después llegaron las primeras peticiones de mejora. No eran correcciones de errores: eran nuevas reglas de negocio que implicaban cambiar la lógica en varios puntos del sistema a la vez.

Esto es exactamente donde se nota la diferencia entre usar IA para escribir código y usar IA para desarrollar software.

🍽️ La carta como escaparate, no solo como sistema de pedido

Cualquier persona que llegara directamente a la URL de la carta —desde un buscador, una red social o un enlace compartido— veía el sistema en modo pedido completo: botones de añadir, carrito, precios para elegir... aunque no tuviera ninguna intención de hacer un pedido en ese momento.

El cambio era aparentemente sencillo pero implicaba repensar la lógica de entrada al sistema. Si el usuario llegaba a través del proceso normal —eligiendo primero si quería pedir para el local, para llevar o a domicilio— el sistema se comportaba igual que siempre. Pero si accedía directamente a la carta sin ese contexto, el sistema detectaba automáticamente que no había un pedido activo y cambiaba a modo catálogo: mostraba todos los productos con sus descripciones e imágenes, ocultaba los botones de añadir y el carrito, y presentaba un botón destacado de "Hacer mi pedido" que llevaba al flujo de inicio correcto.

La carta pasaba así a funcionar también como escaparate público del restaurante, útil para consultar el menú sin necesidad de comprometerse con un pedido. Un mismo sistema, dos comportamientos distintos según el contexto de entrada, sin duplicar código ni crear una segunda versión de la página.

📮 Zonas de reparto por código postal

El restaurante no reparte a toda la ciudad. Necesitaba validar que la dirección del cliente estuviera dentro de su zona de cobertura antes de aceptar el pedido a domicilio.

No era solo un campo de texto. Implicaba una tabla de códigos postales permitidos en la base de datos, una validación en el carrito al introducir la dirección, un bloqueo en la API si el código no estaba autorizado y un mensaje claro al cliente explicando por qué no podía pedir.

Cuatro puntos del sistema tocados a la vez, con una lógica que afectaba tanto al flujo del pedido como a la experiencia del usuario.

💳 Sin pago, sin pedido para llevar

Para los pedidos de recogida y domicilio, el restaurante quería garantizar que el pago estuviera confirmado antes de poner el pedido en marcha. Si la pasarela no respondía correctamente, el pedido no debía registrarse como válido.

Este cambio cruzaba el carrito, la API de pedidos, la notificación de Redsys y el panel de administración. Cambiar la lógica en un solo sitio sin tener en cuenta el resto habría roto el flujo. Hay que entender el sistema completo para tocar una parte sin romper las demás.

🕐 Horarios por tipo de servicio

El local, la recogida y el domicilio no tienen los mismos horarios. El cliente necesitaba poder definir franjas de apertura distintas para cada modalidad y que el sistema bloqueara automáticamente los pedidos fuera de horario, con un aviso al cliente.

Otro cambio que afectaba a múltiples capas: la configuración en el panel de administración, la comprobación en el momento de hacer el pedido y el mensaje que ve el usuario si intenta pedir cuando el servicio está cerrado.

El cliente pidió las mejoras por la mañana. Estaban en producción esa misma tarde.

Sin IA esto no habría sido imposible, pero sí habría requerido planificar, analizar el código existente, escribir desde cero y probar cada cambio por separado. Con IA el proceso fue distinto: describir el problema, revisar la propuesta, ajustar los detalles del negocio y validar el resultado.

La velocidad no viene de que la IA genere código solo. Viene de que quien la dirige sabe exactamente qué necesita el negocio y puede evaluar si lo que se propone es correcto. Sin ese criterio, la velocidad no sirve de nada.

Estos cuatro módulos son un buen resumen de lo que significa aplicar IA al desarrollo real: no grandes proyectos de laboratorio, sino mejoras concretas sobre un sistema en producción, entregadas rápido y sin romper lo que ya funcionaba.

José Alfonso Benito Guerras

IA Aplicada · Tecnología utilizada en proyectos y negocios reales.