Aplicación web
Manifest AI: del correo al sistema de gestión, sin copiar nada
Plataforma que convierte los manifiestos turísticos recibidos por correo, en texto libre, en órdenes de transporte estructuradas, validadas y listas para el sistema de gestión.
-
correos de manifiesto procesados
-
órdenes generadas
-
endpoints REST
-
ejemplos verificados a mano
En resumen
En breve
- Manifest AI lee los correos con los manifiestos de transporte y los convierte en órdenes estructuradas, listas para importar en el sistema del operador turístico.
- Un modelo de lenguaje interpreta el texto descriptivo, mientras que las horas de recogida, las validaciones y las reglas de negocio quedan en manos de código determinista.
- Un conjunto de ejemplos verificados a mano mide la precisión: el modelo elegido extrae correctamente el 90,6% de los campos.
- Si el servicio de IA no responde, la extracción recurre automáticamente a un motor de reglas en lugar de detenerse.
- En producción: 8.655 bloques de servicio extraídos de 379 correos, backend FastAPI y frontend Next.js en Azure.
Cuál era el problema
Un operador turístico recibe por correo los manifiestos de los traslados: texto sin estructura, cientos de bloques por mensaje. Cada bloque es una reserva (pasajeros, hotel, vuelo, vehículo, horarios) escrita en inglés corriente, con formatos incoherentes e información repartida entre campos distintos.
Una persona tenía que leer cada bloque, entender de qué servicio se trataba, calcular a mano la hora de recogida según el vuelo y el aeropuerto, y copiarlo todo en el sistema de gestión. Trabajo lento y repetitivo, sobre datos donde una hora equivocada significa un cliente que se queda en tierra.
Correos, servicios, órdenes: tres etapas inspeccionables
El flujo sigue el camino natural del dato. Los correos llegan de un buzón vigilado y se guardan íntegros; el cuerpo se divide en bloques de servicio individuales, reconociendo reservas nuevas, modificaciones y cancelaciones; cada bloque se convierte en una orden estructurada de unos 25 campos, con la hora de recogida calculada, las peticiones especiales detectadas y el vehículo validado.
Cada etapa se puede inspeccionar y corregir, y la persona siempre es la última en aprobar. Solo en ese momento la orden se traduce al formato del sistema de destino y se envía por su API.
La IA donde hay que interpretar, las reglas donde hay que ser exacto
La decisión de arquitectura central es no dejar que el modelo de lenguaje haga las cosas que tienen que ser exactas. El modelo interpreta los campos descriptivos (pasajeros, vehículo, hotel, vuelos, comentarios), donde las variantes lingüísticas son infinitas, siguiendo un esquema JSON generado a partir del modelo de datos de la orden.
Todo lo que tiene que ser exacto queda en código determinista: la hora de recogida, las peticiones especiales como sillas infantiles y sillas de ruedas, la coherencia entre vehículo y número de pasajeros, las notas operativas por localidad. El servicio más frecuente, el traslado de salida, se extrae enteramente con expresiones regulares: formato estable y volúmenes altos, donde lo determinista es más rápido, gratuito y repetible. Y si el servicio de IA no responde, la extracción recurre a un motor de reglas en lugar de detenerse.
El cálculo de la hora de recogida
No es una función de inteligencia artificial, y justamente ahí está la cuestión. La hora se obtiene de una jerarquía explícita de fuentes: primero la ya confirmada por el proveedor, después la confirmada con el cliente, después la indicada por el operador, y solo a falta de todas ellas un cálculo automático, a partir de la hora del vuelo o del tren menos el tiempo de antelación configurado, teniendo en cuenta el horario de apertura del aeropuerto.
Un indicador distingue siempre la hora declarada de la calculada, así quien trabaja sabe de qué fiarse. Las reglas cambian según el tipo de servicio (en las salidas se calcula hacia atrás desde el vuelo, en las llegadas la hora es la del aterrizaje) y son datos en una tabla, modificables desde la interfaz: 39 configuraciones activas en 17 aeropuertos.
Medir si la IA está funcionando
Dentro de la aplicación hay un conjunto de ejemplos reales con la salida correcta verificada y aprobada a mano. Sirve para tres cosas: como ejemplos en el prompt de extracción, como prueba de regresión después de cada cambio en el flujo, y como banco de pruebas para comparar modelos.
Así se eligió el modelo: en Groq, openai/gpt-oss-120b extrae correctamente el 90,6% de los campos frente al 84,7% de llama-3.3-70b, y a menor coste. El modelo se cambia desde una variable de entorno, así que se puede volver atrás sin una nueva publicación.
Las reglas del oficio, puestas en código
Buena parte del valor está en las reglas del dominio. Los traslados a Capri e Ischia se dividen automáticamente en tramos, ferry más tierra, con el motivo de la división registrado; Venecia tiene sus propias reglas para taxis acuáticos y servicios sin acompañante; algunas localidades generan por sí solas la nota para el proveedor, como la espera de treinta minutos después de aterrizar en Fiumicino o el punto de encuentro en Roma Termini.
Las cancelaciones reconocen el patrón de la nueva reserva, con una correspondencia que nunca destruye datos.
Cómo está construido
Backend en Python con FastAPI, SQLAlchemy 2.0 tipado y Pydantic v2, sobre Azure SQL con 20 migraciones versionadas. Es la segunda versión: la primera era en Flask y se reescribió mientras el sistema ya estaba en producción.
Frontend en Next.js 15, React y TypeScript con Tailwind CSS: 28 páginas de aplicación y modo oscuro en toda la interfaz. Autenticación JWT con roles y permisos en tabla, adjuntos en Azure Blob Storage, publicación en Azure Static Web Apps y App Service con GitHub Actions.
El paquete
Qué se entregó
- Arquitectura de la aplicación
- Backend FastAPI con 106 endpoints REST
- Frontend Next.js con 28 páginas de aplicación
- Flujo de extracción híbrido de IA y reglas
- Reescritura del backend de Flask a FastAPI
- Publicación en Azure con GitHub Actions
En detalle
Ficha técnica
- Plataforma: aplicación web en Azure
- Año: 2025
- Estado: En producción
- Tecnologías: Python, FastAPI, Next.js, TypeScript, Azure, LLM, SQLAlchemy, Web App, Automatización
Las capturas vienen del entorno de producción: están difuminados la marca del cliente y todos los datos personales. Cifras tomadas el 20 de septiembre de 2026.
Hablemos
¿Necesitas un software así?
Si tienes un proceso que hoy gestionas a mano y querrías automatizar, cuéntamelo: vemos juntos si tiene sentido construir una herramienta encima.
¿Necesitas algo parecido? Este proyecto es un ejemplo de automatización con inteligencia artificial. La primera reunión y el presupuesto son gratuitos: escríbeme y lo hablamos.
