Tu agente de viajes con IA te está mintiendo, y no lo sabrás hasta que te quedes tirado

Una mujer nos escribió por correo el año pasado con una captura de pantalla. Había usado un popular planificador de viajes con IA para reservar unas vacaciones familiares a Costa Rica. La IA le había recomendado un lugar llamado algo así como «Tabacon Springs Eco-Lodge»: descripciones exuberantes, un precio inferior a los 200 dólares por noche, fotos que parecían coincidir. Reservó vuelos para cuatro personas. Alquiló un coche. Les dijo a sus hijos que iban a ver monos desde una casa en un árbol.

El alojamiento no existía.

No que «estuviera cerrado» o «en renovación». Literalmente no existía. La IA había mezclado detalles de dos o tres resorts costarricenses reales —el nombre de uno, las comodidades de otro, el precio de un hostal calle abajo— y los había cosido en una única propiedad bellamente descrita que jamás se había construido. El enlace de reserva llevaba a una página de pago genérica que le cobró la tarjeta y no le entregó nada.

Cuando leí ese correo, no sentí sorpresa. Sentí reconocimiento. Porque mi equipo en Veriprajna había pasado meses observando exactamente este modo de fallo, desmenuzándolo, entendiendo por qué ocurre a nivel arquitectónico. Y la respuesta es a la vez sencilla y profundamente incómoda para cualquiera que construya productos de IA en el sector de los viajes: los sistemas de IA más populares del sector están optimizados para sonar correctos, no para ser correctos. Esa distinción es sutil en un generador de poesía. En la logística de viajes, es la diferencia entre unas vacaciones y un desastre.

¿Por qué tu IA inventa hoteles que no existen?

Esto es lo que la mayoría de la gente no entiende sobre los grandes modelos de lenguaje: GPT-4, Claude, Gemini, todos ellos. No «saben» cosas de la manera en que una base de datos sabe cosas. Un sistema de reservas de hotel sabe que la habitación 412 del JW Marriott está reservada del 3 al 7 de marzo. Eso es un hecho, almacenado en una fila, consultable.

Un LLM no funciona así. Predice la siguiente palabra de una secuencia basándose en patrones estadísticos de sus datos de entrenamiento. Cuando le pides un «eco-lodge de lujo en Costa Rica por menos de 200 dólares», activa grupos de asociaciones: «Costa Rica» evoca «exuberante», «selva tropical», «eco-lodge». Empieza a generar texto que es estadísticamente probable que siga a esas palabras. ¿Y cuando necesita nombrar la propiedad? La mezcla. Toma fragmentos de miles de reseñas que ha visto y los compone en algo que suena plausible.

En la escritura creativa, esa mezcla se llama imaginación. En los viajes, se llama alucinación. Y el modelo no tiene forma de distinguir la diferencia.

El modelo está optimizando para la coherencia, no para la corrección. Está diseñado para producir una respuesta que parezca una respuesta válida, no una que sea una respuesta válida verificada contra el inventario en tiempo real.

Lo que empeora esto es cómo se entrenan estos modelos. Durante el aprendizaje por refuerzo a partir de retroalimentación humana (RLHF), los evaluadores humanos prefieren de forma sistemática las respuestas exhaustivas y seguras frente a las que dicen «No lo sé». Así que el modelo aprende, a un nivel profundo, que adivinar con seguridad se recompensa y admitir ignorancia se penaliza. Un agente de viajes humano que adivina la disponibilidad es despedido. Una IA que adivina la disponibilidad es elogiada por su «fluidez», hasta que el cliente aterriza en un país extranjero sin ningún lugar donde dormir.

La noche en que me di cuenta de que la fluidez es el problema

Hay un momento al que sigo volviendo. Estábamos probando un prototipo temprano —no un producto que lanzáramos, sino un experimento interno para entender cómo manejan los LLM las consultas de viajes—. Le pedí que me encontrara un hotel cerca de Central Park por menos de 250 dólares la noche durante la Semana de la Moda en Nueva York.

Volvió con tres opciones. Descripciones detalladas. Precios. Comodidades. Una de ellas incluso mencionaba un bar en la azotea con vistas al parque. El lenguaje era tan pulido, tan específico, que mi primer instinto fue hacer clic en «reservar».

Entonces uno de mis ingenieros —un tipo más callado, muy metódico— ejecutó la misma consulta contra la API de búsqueda de hoteles de Amadeus. Dos de los tres hoteles existían pero no tenían disponibilidad durante la Semana de la Moda. El nombre del tercer hotel se parecía a una propiedad real pero no coincidía con ningún ID de hotel en el sistema. ¿El bar de la azotea? Pertenecía a un hotel completamente distinto a seis manzanas de distancia.

Esa fue la noche en que entendí que el peligro no es la IA que falla de forma evidente. Un chatbot que dice «No entiendo tu pregunta» es frustrante pero inofensivo. El peligro es la IA que entiende tu pregunta a la perfección y responde con información elocuente, persuasiva y objetivamente errónea. Empezamos a llamar a esto el «valle inquietante» de la fiabilidad: la inteligencia verbal del sistema es tan alta que los usuarios bajan la guardia ante la verificación de los hechos.

El caso del chatbot de Air Canada lo concretó en términos legales. Un chatbot alucinó una política de reembolso. El tribunal dictaminó que la aerolínea era responsable, no el proveedor de la IA, ni el chatbot como una «herramienta beta». La empresa que desplegó el agente era responsable de las afirmaciones del agente. Si tu IA promete una suite con vistas al mar por 200 dólares y el GDS solo tiene una habitación estándar por 400 dólares, podrías tener que responder por la diferencia. O peor, por el viaje arruinado.

¿Qué ocurre cuando tratas al LLM como el cerebro en lugar de la boca?

Después de aquella noche de pruebas, mi equipo tuvo una larga discusión. De esas en las que la gente dibuja en pizarras y habla por encima de los demás. La pregunta era simple: ¿intentamos hacer que el LLM sea más preciso, o cambiamos la arquitectura por completo?

Un bando quería mejores prompts, más guardrails, generación aumentada por recuperación. Ajustar el modelo con datos de viajes. El otro bando —en el que acabé yo— sostenía que el problema no era el conocimiento del modelo. El problema era el rol del modelo. Le estábamos pidiendo a un generador de texto que hiciera el trabajo de un gestor de inventario. Es como pedirle a un novelista que dirija una aerolínea. Puede describir bellamente la experiencia de volar, pero no puede decirte si hay un asiento en el vuelo de las 8 de la mañana a Heathrow.

Así que tomamos una decisión que cambió todo lo que construimos después: el LLM nunca sería la fuente de la información de viajes. Sería el enrutador de la intención.

El usuario dice «Encuéntrame un hotel cerca de Central Park». El trabajo del LLM es entender esa intención, descomponerla en parámetros estructurados —ubicación, rango de fechas, presupuesto, preferencias— y entregar esos parámetros a una herramienta que consulta el inventario real. La herramienta devuelve datos reales. El segundo trabajo del LLM es presentar esos datos en lenguaje natural. Pero nunca genera los datos. Los traduce.

Dejamos de construir IA que habla sobre viajes. Empezamos a construir IA que hace viajes: consulta sistemas reales, interpreta códigos de estado reales y solo confirma lo que puede verificar.

Este es el cambio de lo que el sector llama un «envoltorio de LLM» a un sistema de IA agéntica. Y la diferencia no es incremental. Es un cambio de especie. Escribí sobre esta arquitectura en profundidad en la versión interactiva de nuestra investigación.

El patrón orquestador-trabajador: por qué un solo agente no basta

Al principio, intentamos ejecutarlo todo a través de un único agente. Un solo prompt gestionando vuelos, hoteles, alquiler de coches, restricciones dietéticas, políticas de viajes corporativos. Se derrumbó bajo su propio peso. La ventana de contexto se llenaba. Las instrucciones entraban en conflicto. El agente reservaba un hotel antes de confirmar las fechas del vuelo, y luego tenía que deshacerlo todo.

Así que construimos lo que llamamos el patrón orquestador-trabajador. Piénsalo como un consultor de viajes sénior que nunca toca un teclado, gestionando un equipo de especialistas que hacen cada uno una sola cosa extremadamente bien.

El orquestador es un modelo de alto razonamiento —GPT-4o o Claude 3.5 Sonnet— que habla con el usuario, mantiene el historial de la conversación y decide qué debe ocurrir. No toca el GDS directamente. Por debajo se sitúan trabajadores especializados: un trabajador de vuelos que habla las API aéreas de Amadeus y entiende los códigos IATA, un trabajador de hoteles que habla los Content Services for Lodging de Sabre y conoce la diferencia entre un depósito y una garantía, un trabajador de políticas que verifica las reglas de viajes corporativos antes de presentar nada.

Cuando un usuario dice «Reserva un vuelo a Nueva York el próximo martes y un hotel cerca de Central Park», el orquestador descompone eso en dos tareas, identifica que la búsqueda de hotel depende de la hora de llegada del vuelo, lanza primero el trabajador de vuelos y luego el trabajador de hoteles con las fechas correctas. Si el trabajador de hoteles falla, el orquestador aun así presenta las opciones de vuelo y pregunta si el usuario quiere reintentar con criterios de hotel diferentes. Nada se cae. Nada alucina.

La clave estaba en separar el pensar del hacer. El orquestador piensa. Los trabajadores hacen. Y ninguno finge ser el otro.

Por qué el «200 OK» casi nos engaña

Aquí va una historia que todavía me hace estremecer. Estábamos metidos de lleno en las pruebas de integración con las API de reservas de Sabre. Nuestro trabajador de hoteles enviaba una solicitud de reserva, recibía una respuesta HTTP 200 —que en desarrollo web significa «éxito»— y se la pasaba al orquestador. El orquestador le decía al usuario: «¡Ya está reservado!».

Salvo que no lo estaba. No siempre.

Nos tomó una cantidad de tiempo vergonzosamente larga detectar esto. La respuesta HTTP era 200 porque el mensaje se había entregado correctamente. Pero dentro del cuerpo de la respuesta, el código de estado del segmento GDS era UC —Unable to Confirm (imposible de confirmar)—. El hotel había rechazado la solicitud, normalmente porque la disponibilidad en caché estaba desactualizada. La habitación se había vendido en los milisegundos entre la búsqueda y el intento de reserva.

La desconexión entre la capa de transporte y la capa de aplicación es una trampa clásica, y caímos de lleno en ella. Un 200 OK a nivel HTTP decía «tu mensaje llegó». Un UC a nivel GDS decía «tu reserva falló». Nuestro sistema leía el sobre e ignoraba la carta de dentro.

Fue entonces cuando implementamos lo que ahora considero la pieza más importante de nuestra arquitectura: el bucle de verificación. Cada respuesta de reserva pasa por un paso de verificación independiente —ya sea una comprobación de código determinista o un prompt especializado que actúa como auditor de calidad— antes de que cualquier confirmación llegue al usuario. La regla es absoluta:

A un agente de IA nunca se le permite emitir un mensaje de confirmación a menos que haya analizado el código de estado del segmento GDS específico y lo haya validado como HK —Holding Confirmed (reserva confirmada)—. Todo lo demás es un fallo, sin importar lo que diga la cabecera HTTP.

HK significa que el inventario está asegurado. UC significa que el hotel te rechazó. NN significa que la solicitud está pendiente: no prometas nada todavía. NO significa que no se tomó ninguna acción. Estos códigos son la diferencia entre una habitación reservada y un viajero varado, y la mayoría de los sistemas de IA de viajes ni siquiera los analizan.

Para el desglose técnico completo de nuestro manejo de códigos de estado y arquitectura de verificación, consulta nuestro documento de investigación.

¿Cómo maneja un agente de IA «la habitación se acaba de vender»?

Aquí es donde los sistemas agénticos se ganan su lugar. La discrepancia «Look-to-Book» es endémica de los viajes: buscas, ves disponibilidad, haces clic en reservar, y la habitación ha desaparecido. Ocurre constantemente durante las temporadas altas. Una IA basada en envoltorios no tiene vocabulario para esta situación. O bien dice «¡La reservé!» (incorrecto) o «Falló» (poco útil). No puede decir «Estaba ahí hace un segundo, pero alguien más la tomó; aquí tienes tu siguiente mejor opción».

Nuestros agentes sí pueden. Cuando una reserva devuelve UC, el sistema dispara automáticamente una nueva búsqueda de disponibilidad para el mismo hotel. Si hay una habitación o tarifa diferente disponible, presenta la opción: «La tarifa anterior se agotó, pero encontré una habitación similar por 10 dólares más». Si no hay nada disponible, extrae el siguiente mejor hotel de los resultados de búsqueda originales y ofrece ese en su lugar. Esto requiere que el agente mantenga un estado: una memoria de lo que ya buscó, lo que el usuario ya rechazó, cuáles eran las alternativas. Los envoltorios no tienen estado. No pueden hacer esto. Empiezan desde cero cada vez, o alucinan continuidad.

El problema de la normalización del que nadie habla

Una cosa que me sorprendió —genuinamente me sorprendió— fue lo diferentes que son las estructuras de datos entre Amadeus y Sabre. Amadeus devuelve los precios desglosados en base, total e impuestos en un JSON anidado estricto. Sabre a veces incluye el impuesto, a veces no, según el plan de tarifas. Los nombres de los campos difieren. amount en un sistema es totalPrice en otro.

Si alimentas ambas respuestas en bruto a un LLM y le pides que compare hoteles, se confundirá. Podría citar el precio antes de impuestos de Amadeus y el precio después de impuestos de Sabre, haciendo que el hotel de Amadeus parezca 50 dólares más barato cuando en realidad es 20 dólares más caro. Vimos que esto ocurría en las pruebas, y es el tipo de error que es casi imposible que un usuario detecte.

Así que construimos un trabajador de normalización: una capa de código determinista que toma los JSON dispares de ambos sistemas y los convierte en un único esquema estandarizado. El orquestador nunca ve datos GDS en bruto. Ve campos limpios y consistentes: nombre, precio total con impuestos incluidos, categoría de estrellas, distancia al punto de interés del usuario. El LLM presenta estos datos normalizados. No interpreta respuestas de API en bruto. Traduce hechos curados.

«Usa GPT y ya está» y otras cosas que dicen los inversores

La gente me pregunta constantemente por qué no usamos simplemente la generación aumentada por recuperación —volcar los datos de los hoteles en una base de datos vectorial y dejar que el LLM la busque—. O ajustar un modelo con datos de viajes. O simplemente añadir un mejor prompt de sistema.

Un inversor me dijo, sin rodeos: «Usa GPT con un buen prompt. El modelo es lo bastante inteligente». Respeto el instinto: es la solución más simple, y las soluciones simples suelen ser las correctas. Pero no aquí. No cuando el modo de fallo es una familia durmiendo en un aeropuerto.

El RAG ayuda con el conocimiento estático —«¿Cuál es la política de visados de Tailandia?»— pero no puede decirte si el vuelo AA123 tiene asientos disponibles ahora mismo. El ajuste fino ayuda con el tono y el vocabulario del dominio, pero no conecta el modelo con el inventario en vivo. Un mejor prompt de sistema ayuda con el formato, pero no impide que el modelo genere un nombre de hotel que no existe en ningún GDS.

Lo único que evita la alucinación en los viajes es anclar la salida de la IA en datos verificados y en tiempo real del sistema de registro. Ese sistema es el GDS. Todo lo demás es decoración.

La creatividad sin restricción es caos. En los viajes, la restricción es la realidad: el asiento de avión que existe o no, la habitación de hotel que está disponible o no. No hay término medio, y la IA debe dejar de fingir que lo hay.

¿Y qué hay de la parte lenta?

No voy a fingir que los sistemas agénticos son rápidos. Una sola solicitud de usuario podría disparar cuatro llamadas a herramientas: búsqueda, verificación de precio, verificación de políticas, síntesis de la respuesta. Eso puede tardar de 10 a 15 segundos. En el comercio electrónico, eso es una eternidad.

Manejamos esto de tres maneras. Primero, transmitimos el razonamiento del agente al usuario: «Buscando vuelos en Amadeus…», «Verificando la política de viajes corporativos…». Mostrar el trabajo reduce drásticamente la latencia percibida. Segundo, ejecutamos los trabajadores en paralelo: el trabajador de vuelos y el de hoteles buscan simultáneamente en lugar de secuencialmente, reduciendo el tiempo total de espera aproximadamente a la mitad. Tercero, almacenamos en caché los resultados de disponibilidad durante 15 minutos en Redis. Si el usuario dice «Muéstrame ese segundo hotel otra vez», no volvemos a consultar el GDS. Lo extraemos de la caché.

¿Es tan rápido como un envoltorio que se inventa una respuesta en dos segundos? No. ¿Es tan rápido como necesita ser para un usuario que quiere una respuesta real? Sí.

La parte en la que admito lo que aún no podemos hacer

Ningún sistema de IA maneja todos los casos. Los itinerarios complejos de múltiples tramos con dependencias de visados, las alianzas aéreas oscuras, las reservas de grupo que requieren tarifas negociadas: estos todavía rompen cosas. Lo sabemos porque construimos detección para ello. Cuando el agente entra en bucle sin resolver, o cuando el análisis de sentimiento detecta la frustración del usuario, el sistema desciende a lo que llamamos «modo copiloto». Alerta a un agente de viajes humano, le pasa el contexto estructurado completo de la conversación, y el humano completa la reserva usando las herramientas que el agente preparó.

La gente me pregunta si esto es un fracaso. Creo que es lo contrario. La IA más peligrosa es la que no sabe cuándo detenerse. Conocer tus límites y ceder el control con elegancia es una característica, no un defecto. El agente que dice «Déjame ponerte en contacto con un especialista» es más fiable que el que sigue adivinando con seguridad.

Hacia dónde va esto a continuación

Lo que estamos construyendo hoy es el cimiento, no el techo. Estamos en lo que yo llamaría autonomía de nivel 3: el agente ejecuta tareas específicas, pero el usuario confirma antes de que se mueva el dinero. El camino hacia adelante incluye agentes de negociación que no solo reservan precios de lista, sino que consultan las API de los hoteles buscando descuentos por volumen, motores de empaquetado dinámico que combinan vuelos y hoteles en productos personalizados con márgenes gestionados, y gestión proactiva de interrupciones: agentes que monitorizan el estado de los vuelos las 24 horas y, cuando ocurre una cancelación, ya reservan un asiento en la siguiente mejor opción antes de que el viajero siquiera sepa que algo salió mal.

Nada de eso es posible con un envoltorio. Nada de eso funciona si el sistema alucina. Cada una de esas capacidades requiere la arquitectura con estado, verificada y anclada en herramientas que hemos estado construyendo.

El sector de los viajes está en un punto de inflexión. La primera ola de adopción de la IA —los envoltorios, los chatbots, los experimentos de «basta con añadir GPT»— creó algo seductor y peligroso: sistemas que suenan como el mejor agente de viajes que hayas conocido pero que en realidad no pueden reservar una habitación. La siguiente ola estará definida por una pregunta más difícil y menos glamurosa: no «¿Puede la IA escribir un itinerario hermoso?», sino «¿Puede la IA confirmar que cada elemento de ese itinerario existe realmente, ahora mismo, al precio que cotizó?».

Esa familia en Costa Rica merecía algo mejor que una ficción bellamente escrita. Todos los viajeros lo merecen. La era de la IA que adivina se acabó. Lo que viene a continuación es la IA que verifica, y que solo habla cuando lo sabe.