Nuestra IA reservó un hotel que no existía, y la matemática decía que pasaría
La primera vez que vi a nuestro asistente de viajes confirmar un hotel que no existía, la sala de la demostración llegó a aplaudir.
Un evaluador había pedido un eco-lodge de lujo en Costa Rica por menos de 200 dólares la noche. El modelo devolvió el «Tabacon Springs Eco-Lodge»: un texto precioso, una tarifa por noche plausible, una pantalla de confirmación. Se lee de maravilla. También son dos propiedades reales, Tabacon y Nayara Springs, fundidas en un único lugar ficticio. No existe ningún Tabacon Springs Eco-Lodge. Si una familia hubiera estado al otro lado de esa pantalla, habría volado a Costa Rica y habría llegado a una recepción donde nunca habían oído hablar de ella.
Ese momento es la razón entera por la que la reserva de viajes con IA agéntica es más difícil de lo que parece, y es por lo que quiero repasar en qué nos equivocamos antes de acertar. La versión breve: en los viajes, una respuesta fluida y una respuesta verdadera son objetos distintos, y la brecha entre ambas no es un fallo que se elimine iterando. Es una propiedad estructural de usar un modelo probabilístico para hacer un trabajo determinista.
A un agente de viajes humano que adivina la disponibilidad lo despiden. A una IA que adivina se la elogia por su tono, hasta que un cliente está plantado en un aeropuerto.
El consejo pidió «una estrategia de IA». El mercado les dio un motivo para entrar en pánico.
Voy a poner el contexto, porque si diriges producto en una empresa de gestión de viajes o en una OTA, lo estás viviendo ahora mismo.
Entre febrero y abril de 2026, cada capa de distribución importante de los viajes lanzó o anunció reservas agénticas. Sabre, PayPal y Mindtrip anunciaron la primera experiencia agéntica de extremo a extremo del sector el 12 de febrero: vuelos disponibles de forma general en el segundo trimestre de 2026, funcionando sobre las API Mosaic de Sabre en más de 420 aerolíneas y dos millones de hoteles, con la base de conocimiento de 6,5 millones de puntos de Mindtrip por encima. El día anterior, el CEO de Marriott confirmó que el AI Mode de Google reservaría en Marriott directamente, saltándose por completo el canal de las OTA. Amadeus metió un asistente generativo llamado Cytric Easy dentro de Microsoft Teams, construido con Accenture. Navan sigue reportando cifras que hacen que cada TMC tradicional parezca lento.
Así que el director financiero entra en la sala y pregunta por qué no estás «haciendo algo de IA como Navan». Y aquí está la trampa en la que vi caer a equipos inteligentes: oyen esa pregunta como lanza un chatbot rápido, cuando la verdadera pregunta —la única que importa— es cómo hacemos esto sin quemarnos como Air Canada.
Los compradores con los que hablo no se preguntan si hacer reservas agénticas. Ese debate está zanjado. Se preguntan cómo hacerlo sin apostar la empresa al inventario de una sola plataforma, y sin que una máquina que se equivoca con total seguridad cree una responsabilidad legal de la que ellos personalmente tengan que responder.
La responsabilidad legal ya tiene nombre, y tu equipo jurídico lo conoce
Si quieres entender por qué los abogados de viajes están nerviosos, solo necesitas un caso.
El 14 de febrero de 2024, el Tribunal de Resolución Civil de la Columbia Británica ordenó a Air Canada pagar a Jake Moffatt 812,02 dólares después de que su chatbot inventara una política retroactiva de tarifas por duelo que contradecía las reglas tarifarias reales de la aerolínea. La defensa de Air Canada fue que el chatbot era, en efecto, una entidad legal separada responsable de sus propias declaraciones. El tribunal lo rechazó en lenguaje llano: una empresa es responsable de todo lo que aparece en sus superficies, ya vengan las palabras de una página web estática o de un modelo.
Ochocientos doce dólares es un error de redondeo. El precedente no lo es. Cada informe jurídico de tecnología de viajes escrito desde entonces cita a Moffatt, y una resolución más reciente falló en sentido contrario sin ayudar en nada a quienes despliegan estos sistemas: en enero de 2026 un tribunal de Hangzhou acotó la responsabilidad de un proveedor de LLM cuando un usuario intentó hacer valer la promesa de un chatbot. Leídos en conjunto, ambos casos apuntan en la misma dirección incómoda: el deber de diligencia recae sobre la marca de viajes, no sobre el proveedor del modelo. No puedes externalizar la culpa a OpenAI.
Y no es solo dinero. En 2025, turistas caminaron hasta los 4.000 metros en los Andes peruanos buscando el «Cañón Sagrado de Humantay», un lugar que un planificador de IA se había inventado por completo. Una pareja malasia condujo 400 kilómetros para subirse a un «Kuak Skyride» que no existe. Un pueblo de Tasmania de 33 habitantes empezó a recibir llamadas sobre unas termas que nunca tuvo. La norma ISO 31030, el estándar de gestión de riesgos en los viajes, convierte la seguridad del viajero en obligación de quien despliega el sistema: esos incidentes son precisamente lo que existe para prevenir. Con aproximadamente una cuarta parte de los turistas usando ya la IA para planificar viajes, el radio de impacto dejó de ser teórico hace un tiempo.
En qué me equivoqué: creía que esto era un problema de prompts
Aquí viene la parte de la que no estoy orgulloso.
Nuestra primera versión era, sinceramente, un envoltorio de buen aspecto. Un modelo capaz, un prompt de sistema bien diseñado, recuperación sobre un catálogo de hoteles, una interfaz de chat limpia. Se demostraba bien, tan bien que me sorprendí a mí mismo creyendo que las alucinaciones eran un caso límite que exprimiríamos hasta eliminarlo con mejores prompts y un índice de recuperación más grande. Por aquel entonces, un inversor me dijo, más o menos, que simplemente usara GPT y dejara de darle tantas vueltas. Durante cerca de un mes le creí a medias.
El momento Tabacon Springs es lo que quebró esa creencia, pero lo que de verdad me hizo cambiar de opinión fue sentarme y hacer la aritmética que había estado evitando.
Una reserva de vuelo realista consta de unos diez pasos secuenciales: interpretar la intención, buscar, filtrar, tarifar, retener, comprobar la política, recopilar los datos del pasajero, ceder el pago, confirmar el PNR, emitir el billete. Supongamos —siendo generosos— que cada paso es una llamada a un modelo probabilístico que acierta el 90 % de las veces. De extremo a extremo, tu tasa de éxito es 0,9 elevado a la décima potencia. Alrededor del 34 %.
No puedes salir a base de prompts de un fallo estocástico que se compone. El error no se hace más pequeño a medida que añades pasos. Se multiplica.
Luego encontré el número que puso fin al debate interno. El benchmark TravelPlanner del OSU NLP Group midió a GPT-4, usando el popular patrón ReAct, completando itinerarios realistas de varios días con un 0,6 %. No un 60 %. Cero coma seis. Seis viajes exitosos de cada mil.
La gente agita por ahí una cifra del «97 %» del mismo benchmark, y quiero ser preciso aquí porque tomarla prestada nos haría parecer deshonestos o ingenuos: ese 97 % procede de un solucionador basado en código que corre contra una base de conocimiento estática y congelada —instantáneas de OpenFlights y Yelp—, no de un modelo reservando contra inventario en vivo y cambiante. No es una cifra de reservas en producción, y cualquiera que la cite como tal no se ha leído el paper. La cifra honesta para un LLM que dirige todo el flujo es la pequeña.
Ese fue el giro. El problema nunca fue el prompt. El problema era que habíamos metido un modelo probabilístico en el flujo de control, para empezar.
¿Cómo impides que una IA reserve un hotel que no está ahí?
Una vez que dejé de intentar hacer el modelo más fiable y empecé a intentar quitarlo de las partes que tienen que ser fiables, la arquitectura casi se diseñó sola.
La regla en la que nos asentamos: el modelo de lenguaje hace lenguaje, y nada más. Extrae lo que un viajero quiere decir y resume los resultados de vuelta en un español llano. No llama al GDS. No comprueba la política. No toca el pago. Cada una de esas cosas es lógica determinista, codificada a mano. Ejecutamos la orquestación como una máquina de estados —LangGraph es nuestro plano de control habitual, aunque no somos dogmáticos al respecto; si un cliente está sobre AWS Bedrock AgentCore o Vertex AI Agent Builder, construimos allí en su lugar.
El detalle que importa más que el framework es el estado tipado. La mayoría de los despliegues de agentes en producción que he visto mueren de la misma muerte silenciosa: el estado se desvía en silencio entre pasos, nadie se da cuenta, y el agente actúa con total seguridad sobre una imagen corrupta del mundo. Un esquema de estado estricto tipado con Pydantic —cada campo declarado, validado en cada transición— es la cosa poco glamurosa que lo evita. Cuando una reserva tiene que abarcar múltiples confirmaciones, un patrón saga gestiona la reversión: si el hotel falla después de que el vuelo ya esté emitido, el grafo sabe cómo anular y deshacer en lugar de dejar al viajero reservado a medias.
Lo construimos como tres capacidades, no como un solo producto, porque no todos los compradores necesitan el paquete completo. Está el agente de reservas determinista: el núcleo. Está la verificación como servicio, una API independiente que cualquier equipo de IA de viajes ya existente puede llamar para preguntar «¿es real este hotel, es actual este precio, está de verdad confirmado este PNR?»: una barrera de protección que se sitúa delante de un envoltorio que ya has lanzado, lo cual es una respuesta mucho más barata cuando el equipo jurídico saca a relucir Moffatt en tu comité de dirección que arrancarlo todo de cuajo. Y está una capa de política y cumplimiento que compila la política de viajes de una empresa o las reglas tarifarias de una OTA en restricciones aplicadas, instrumenta las obligaciones de deber de diligencia de la ISO 31030 y lleva incorporados los requisitos de transparencia de la Ley de IA de la UE. Escribimos cómo encajan las tres en la página de solución de este trabajo.
La aplicación de la política tiene que ser código, no un prompt. Los prompts se desvían entre versiones del modelo. A las reglas de negocio no se les permite hacerlo.
El número que nadie pone en la diapositiva del pitch
Si pudiera hacer que cada equipo de viajes interiorizara una sola cosa antes de lanzar, no sería la alucinación. Sería la economía de la búsqueda.
Los proveedores de GDS no cobran por reserva. Cobran por búsqueda de segmento, normalmente de 3 a 3,50 dólares más una comisión de en torno al 10 %, y aplican ratios de look-to-book que te penalizan por comprar de forma especulativa. El Grupo Lufthansa volvió a subir sus tarifas de reserva de GDS, con efecto a partir del 1 de enero de 2026, en Amadeus, Sabre y Travelport. Ahora imagina un agente que «servicialmente» ejecuta cuatro búsquedas exploratorias por turno de conversación porque el modelo decidió ser minucioso. Con el margen de comerciante del 3 al 5 % de una OTA, ese agente se fundirá el beneficio del trimestre en un chatbot que en realidad nunca reserva nada.
Esta es la línea más pasada por alto en cada demostración de viajes agénticos que he presenciado, y es exactamente por lo que esas demostraciones no sobreviven al contacto con la producción. Un agente determinista limita y almacena en caché las búsquedas porque la capa de orquestación —no el humor del modelo— decide cuándo una búsqueda vale su tarifa.
Y para una TMC, esa economía se ata directamente al número que el director financiero persigue de verdad. La métrica que este desarrollo mueve es el porcentaje de reservas sin intervención y el tiempo de gestión de la cola offline que hay detrás. Cada reserva alucinada o no gestionable es un tique que vuelve a caer en un agente humano, que es el coste al que se apunta cuando alguien en la sala dice «haz algo de IA como Navan».
¿Por qué no puedes construirlo sin más sobre la API de Amadeus?
Unas cuantas realidades que tuve que aprender por las malas, y que ahora saco a relucir en la primera llamada de descubrimiento para que a nadie le sorprendan en el tercer mes.
Si eres una TMC que planea «construir sin más sobre la API de Amadeus», comprueba qué clave tienes. El nivel Self-Service Production de Amadeus específicamente excluye el endpoint Flight Create Orders: está, en su propia formulación, diseñado para empresas sin certificación de agencia de viajes. Para emitir órdenes de verdad necesitas Enterprise. He visto esa única partida retrasar una hoja de ruta un trimestre entero.
Luego está la costura que todo el mundo trata como resuelta y no lo está: NDC frente a GDS. New Distribution Capability es estupendo para la oferta y la orden iniciales, pero el servicio posterior a la reserva —cambios, reembolsos, reprotección en operaciones irregulares— sigue funcionando sobre infraestructura GDS incluso cuando la venta original fue por NDC. Un agente en producción necesita ambos conductos, no una elección binaria entre ellos. Y el propio NDC no es una sola cosa: la gestión de órdenes de Nivel 4 a través de un agregador como Verteil o Duffel es una integración distinta de la compra de Nivel 3 en la que se detienen la mayoría de los envoltorios. Las operaciones irregulares (IROPS) son donde la brecha se vuelve real: un solo fenómeno meteorológico puede dejar tirados a viajeros por avionadas enteras, y reprotegerlos cuesta de 500 a 2.000 dólares cada uno. Un agente que puede buscar pero no puede dar servicio es un juguete.
Y si tu diseño tiene al agente emitiendo billetes directamente en lugar de derivar a un sistema anfitrión, ya estás en terreno de acreditación: ARC en EE. UU., que tarda unos 25 días una vez cumplidos los prerrequisitos, o la acreditación completa de la IATA, que puede llevar de seis a doce meses. También hay una trampa de pagos: en el momento en que una interfaz de chat recopila datos de tarjeta, has metido toda tu pila en el alcance de PCI. El comercio agéntico de hoy todavía cede la autorización real a un paso de pago humano, con tokenización a través de un proveedor como VGS o Checkout.com que mantiene los datos de tarjeta fuera de tu entorno.
Nada de esto está en la ponencia magistral. Todo ello está en el informe de incidentes de producción.
«¿Por qué no comprar sin más el de Sabre, o Cytric, o Navan?»
La gente me pregunta esto constantemente, y mi respuesta honesta les sorprende: a veces deberías hacerlo.
Si eres una OTA de ocio contenta con distribuir el inventario de Sabre sobre las vías de Sabre, la pila Sabre–PayPal–Mindtrip es una compra razonable, siempre que hayas aceptado un suministro atado a Sabre y la ausencia de una capa de política corporativa o de instrumentación de la ISO 31030. Si eres una empresa nativa de Microsoft que ya está en Cytric y Concur, Cytric Easy dentro de Teams probablemente sea lo adecuado para ti, y te lo diré directamente. Si quieres arrancar tu TMC por completo y operar una plataforma nativa de IA, Navan se ha ganado de verdad sus cifras —73 % de gastos sin intervención, violaciones de política reducidas del 35 % a menos del 5 %— y no voy a fingir que les ganamos a ser Navan.
Encajamos en un caso más estrecho y específico: quieres conservar tus contratos de GDS existentes y tu relación con la TMC y añadir inteligencia por encima, neutral respecto al proveedor, sin convertirte en distribuidor de aquel a quien le compraste tu agente. Ese es el desarrollo. Y las partes que no puedo hacer, las digo en voz alta: no somos un agente emisor de billetes acreditado por la IATA/ARC, así que la emisión pasa por tu anfitrión; no somos dueños de tus acuerdos comerciales de GDS; y no podemos arreglar una política de viajes corporativa ambigua, aunque te ayudaremos a afinarla en el descubrimiento, porque una política ambigua hace un agente ambiguo por muy bueno que sea el código.
El plazo que cierra la ventana
Una cosa más sobre el reloj. Las obligaciones de transparencia de la Ley de IA de la UE para quienes despliegan estos sistemas entran en vigor el 2 de agosto de 2026, y la guía de clasificación de alto riesgo aterrizó ya el 2 de febrero de 2026. Si tu agente habla con consumidores de la UE, la divulgación no es opcional y «ya lo añadiremos luego» es un hallazgo de incumplimiento esperando a suceder. Construimos la superficie de divulgación del Artículo 50 y un rastro de auditoría de registrar-y-explicar desde el principio, porque adaptar la transparencia a posteriori sobre un envoltorio de caja negra es mucho más doloroso que diseñarla desde el inicio.
Así que aquí es donde he acabado después de todo esto. La fluidez ya es gratis: cada envoltorio del mercado suena seguro de sí mismo, y un viajero no puede distinguir una confirmación real de una alucinada leyéndola. Lo que un viajero sí puede distinguir, al final, es si la habitación está en la recepción cuando llega. Esa brecha —entre una frase que se lee como verdadera y un PNR que es verdadero— no se cierra porque el modelo se hiciera más grande. Se cierra porque alguien decidió, antes del lanzamiento, que el modelo nunca sería lo que responda «¿es esto real?». La capa determinista que lo responde es poco glamurosa, no se demuestra tan bien, y es el trabajo entero.
El Tabacon Springs Eco-Lodge sigue sin ser un lugar real. La única pregunta que importa es si tu sistema lo sabe antes de que tu cliente esté plantado en el vestíbulo. Si quieres ver cómo construimos el nuestro para que lo supiera, el desglose completo está aquí.
