El fin de la ficción en los viajes: ingeniería de fiabilidad determinista con IA agéntica e integración con GDS

Resumen ejecutivo: el alto coste de la alucinación del «viaje de ensueño»

En el panorama de la tecnología de viajes, en rápida evolución, ha surgido una dicotomía peligrosa. Por un lado, tenemos el poder creativo sin precedentes de los grandes modelos de lenguaje (LLM) como GPT-4, Claude 3.5 Sonnet y Gemini, capaces de tejer narrativas ricas sobre «alojamientos ecológicos de lujo en Costa Rica» que impulsan a los usuarios a soñar y reservar. Por el otro, tenemos la fría realidad binaria del inventario mundial de viajes: el asiento de avión que está disponible o vendido, la habitación de hotel que existe o no existe. La intersección de estos dos mundos ha producido un modo de fallo crítico para los primeros adoptantes de la IA generativa en viajes: el «viaje de ensueño» alucinación.

Considere el arquetipo de este fallo: una familia solicita un itinerario concreto a una agencia de viajes con su nuevo planificador de IA. Piden un «alojamiento ecológico de lujo en Costa Rica por menos de 200 $». La IA, optimizada para la verosimilitud más que para la verdad, alucina un hotel. Combina las mejores características de tres reseñas distintas halladas en sus datos de entrenamiento en una única propiedad inexistente. La descripción es hermosa, el precio es atractivo y el enlace de reserva —si se genera— no lleva a ninguna parte o, peor, a una página de pago genérica para una reserva que no puede cumplirse. La familia reserva sus vuelos. Llegan a Costa Rica y no encuentran nada. La IA había alucinado el hotel porque combinó detalles de puntos de datos no relacionados en una narrativa cohesiva pero ficticia.

Este whitepaper, preparado por Veriprajna, sostiene que la era del «LLM Wrapper» —simples chatbots que pasan las indicaciones del usuario directamente a un modelo— ha terminado para la industria de los viajes. El futuro pertenece a la IA agéntica: sistemas que no se limitan a escribir texto, sino que orquestan de forma activa flujos de trabajo, manejan herramientas y verifican la realidad frente a la fuente de verdad inmutable: el Sistema de Distribución Global (GDS). Postulamos que la industria de los viajes requiere un cambio arquitectónico fundamental de la narración probabilística a la gestión determinista de inventario.

Este informe sirve como plano técnico integral de ese puente, y detalla el rigor de ingeniería necesario para construir sistemas que sobrevivan al «valle inquietante» de la fiabilidad. Exploramos el patrón de diseño «Orquestador-Trabajador», la necesidad de la «llamada a herramientas» frente a la generación de texto, y la implementación concreta de bucles de verificación que garantizan que una IA nunca prometa una habitación que no pueda confirmarse con un código de estado HK (Holding Confirmed). Veriprajna se sitúa en esta frontera. No construimos wrappers; construimos la infraestructura cognitiva que tiende el puente entre el potencial creativo de la IA y el rigor operativo de la empresa.

Parte I: El mentiroso creativo – por qué los LLM fallan en la logística

1.1 La trampa de la probabilidad: cuando «probable» significa «falso»

Para entender por qué una IA sofisticada inventaría un hotel, primero hay que comprender la arquitectura fundamental del modelo Transformer. En su núcleo, un LLM es un motor de predicción del siguiente token. ¹ No «conoce» hechos del modo en que una base de datos relacional sabe que Hotel_ID_1234 tiene Room_Count: 5. En su lugar, calcula la probabilidad estadística de la siguiente palabra de una secuencia a partir del vasto corpus de texto con el que se entrenó. Esta naturaleza probabilística es el motor de la creatividad, que permite al modelo redactar poesía o código, pero es el talón de Aquiles de la logística.

Cuando un usuario pide un «alojamiento ecológico de lujo en Costa Rica por menos de 200 $», el modelo activa un cúmulo de asociaciones latentes relacionadas con «Costa Rica», «eco-lodge», «lujo» y «asequible». Empieza a generar una descripción. La probabilidad de que la palabra «lush» (exuberante) siga a «Costa Rica» es alta. La probabilidad de que «rainforest» (selva) siga a «lush» es alta. El modelo construye una narrativa convincente usando estos tokens de alta probabilidad. El fallo crítico ocurre cuando el modelo intenta nombrar la propiedad. Si ha visto miles de reseñas del «Tabacon Resort» y miles del «Nayara Springs», puede fusionarlos de forma probabilística. Podría generar un nombre que suene verosímil —p. ej., «Tabacon Springs Eco-Lodge»— y atribuirle servicios que no pertenecen en exclusiva a ninguna de las dos propiedades, pero que es estadísticamente probable que aparezcan en descripciones de resorts costarricenses. ²

En la escritura creativa, esta fusión es una característica; se llama imaginación. En la logística de viajes, es una alucinación. El modelo optimiza la coherencia, no 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 frente a una base de datos de inventario en tiempo real. ³ Esta distinción es sutil pero devastadora. En un contexto creativo, la «verdad» es subjetiva y maleable. En un contexto transaccional, la verdad es binaria. Un asiento en un vuelo existe, o no existe. Una habitación de hotel está disponible para una fecha concreta, o no lo está. No hay término medio, y sin embargo el LLM opera enteramente en el término medio de la probabilidad.

El peligro se agrava por el objetivo de entrenamiento del modelo. La mayoría de los modelos fundacionales se entrenan con aprendizaje por refuerzo a partir de retroalimentación humana (RLHF), donde los evaluadores humanos prefieren respuestas exhaustivas, corteses y seguras. Si un modelo dice «no lo sé», a menudo recibe una recompensa menor durante el entrenamiento que si intenta una conjetura verosímil. Esto crea un sesgo sistémico hacia la fabricación. ³ En la industria de los viajes, este sesgo es catastrófico. Un agente de viajes humano que adivina la disponibilidad es despedido; una IA que adivina la disponibilidad suele ser elogiada por su «fluidez» hasta el momento en que el cliente llega al aeropuerto.

1.2 El «valle inquietante» de los agentes de viajes

El peligro de los despliegues actuales de LLM en viajes reside en su competencia lingüística. Un chatbot tosco que no entiende una consulta es frustrante pero inofensivo. Un LLM avanzado que entiende la consulta a la perfección y responde con información elocuente, persuasiva, pero fácticamente incorrecta es peligroso. Esto crea un «valle inquietante» de fiabilidad: el usuario confía en el sistema por su elevada inteligencia verbal, bajando la guardia respecto a la verificación de los hechos.

Hemos entrado en una fase en la que la fluidez de la IA enmascara su incompetencia en la logística. Cuando una IA habla con la autoridad de un conserje experimentado, usando jerga del sector y lenguaje empático, el usuario asume de forma natural que esa capacidad lingüística se extiende a la capacidad operativa. Esta asunción es falsa. Un LLM puede redactar una carta de disculpa perfecta por una maleta perdida, pero no puede localizar la maleta. Puede describir una suite del Ritz Paris con un detalle exquisito, pero no puede decirle si esa suite está reservada para la Semana de la Moda.

Casos judiciales recientes de gran repercusión, como el incidente del chatbot de Air Canada, subrayan este riesgo. ³ En aquel caso, un chatbot alucinó una política de reembolso que no existía. El tribunal dictaminó que la aerolínea era responsable de la información proporcionada por su «agente». Esto sienta un precedente aterrador para el sector: si su IA promete una suite con vistas al mar por 200 $, y el GDS solo tiene una habitación estándar por 400 $, su agencia puede ser responsable de la diferencia —o, peor, de las vacaciones arruinadas. El fallo de Air Canada desmanteló de hecho la defensa de que un chatbot es una entidad separada o una herramienta «beta». Si una empresa despliega un agente para interactuar con los clientes, la empresa es responsable de las afirmaciones del agente.

Esta responsabilidad se extiende más allá de los reembolsos. Considere las implicaciones de seguridad. Una IA podría alucinar una ruta de trekking segura en Perú que no existe, llevando a los turistas a un terreno peligroso. ² Podría inventar un programa de exención de visado para un país concreto, haciendo que los viajeros sean deportados a su llegada. La alucinación del «viaje de ensueño» no es solo un problema de atención al cliente; es un campo de minas legal y de seguridad. Las agencias de viajes que despliegan wrappers sin guardarraíles están, en esencia, externalizando su responsabilidad a un generador de números aleatorios.

1.3 Las limitaciones del enfoque «wrapper»

La oleada inicial de adopción de IA generativa en viajes estuvo dominada por los «wrappers». ⁴ Se trata de capas de software delgadas que se sitúan entre la interfaz de usuario y un modelo fundacional (como GPT-4). El «wrapper» representa el camino de menor resistencia para los desarrolladores: sencillo de construir, barato de desplegar e inmediatamente impresionante en las demos. Sin embargo, bajo la superficie, la arquitectura wrapper es fundamentalmente inadecuada para las complejidades del viaje empresarial.

Anatomía de un wrapper:

1.​ Entrada del usuario: «Encuéntrame un hotel en París.»

2.​ Indicación del sistema: «Eres un asistente de viajes servicial. Encuentra hoteles en París.»

3.​ Procesamiento del LLM: El modelo genera una lista de hoteles a partir de sus datos de entrenamiento (que tienen una fecha de corte de conocimiento y ningún acceso en tiempo real).

4.​ Salida: «Aquí hay algunos hoteles estupendos: [lista de hoteles que podrían haber cerrado o cambiado de

nombre].»

Esta arquitectura es fundamentalmente defectuosa para el viaje empresarial porque es:

●​ Sin estado: No recuerda que el usuario rechazó previamente hoteles de más de 300 $ salvo que ese contexto se reinyecte manualmente en cada turno. Esto provoca bucles frustrantes en los que el usuario debe repetir las restricciones, rompiendo la ilusión de un asistente inteligente.

●​ Ciego: No puede ver el inventario en vivo. No sabe que el «Hotel Ritz» está completo para la Semana de la Moda. Se basa en datos de entrenamiento que pueden tener meses o años. En el mundo vertiginoso del inventario de viajes, unos datos de una hora de antigüedad a menudo ya son demasiado viejos; unos datos de un año de antigüedad son inútiles.

●​ Sin verificar: No tiene mecanismo para comprobar si su salida es verdadera. Confía en su propia generación probabilística. Si el modelo alucina un precio, no hay código ejecutándose para verificar ese precio contra una base de datos.

●​ Lineal: Procesa la conversación en un flujo lineal de texto. No puede «volver atrás» y corregir un error de razonamiento sin que el usuario se lo señale. Carece de la capacidad iterativa de resolución de problemas de un agente verdadero.

Para Veriprajna, el «wrapper» es un prototipo, no un producto. La fiabilidad de grado empresarial exige un sistema que trate al LLM no como la fuente de la información, sino como el enrutador de la intención. El paso de wrapper a agente no es un mero upgrade; es un cambio de especie. Es la diferencia entre un loro que imita el sonido de un piloto y el piloto que realmente vuela el avión.

Parte II: Más allá del wrapper – la arquitectura de IA agéntica

2.1 Definición del sistema agéntico

El paso del LLM pasivo a la IA agéntica es la transición técnica definitoria de 2025. ⁵ Mientras que un LLM es un motor de generación de texto, un agente es un sistema capaz de ejecutar un bucle cognitivo que implica razonamiento, uso de herramientas y retroalimentación del entorno. El agente no es solo un hablante; es un hacedor.

Los componentes nucleares de un agente:

1.​ Razonamiento: Descomponer un objetivo complejo («Planifica un viaje de negocios a Londres») en subtareas (reservar vuelo, reservar hotel, comprobar la política). Esto exige que el modelo comprenda las dependencias: no se puede reservar el hotel hasta conocer las fechas del vuelo.

2.​ Uso de herramientas: Reconocer que no puede responder una pregunta desde sus pesos internos y debe llamar a una función externa (p. ej., Sabre_GetAvailability). Este es el puente entre la mente probabilística de la IA y el mundo determinista de la API.

3.​ Acción: Ejecutar la herramienta e interpretar el resultado. El agente debe ser capaz de analizar JSON, XML u otros formatos de datos estructurados que devuelva la herramienta.

4.​ Bucle: Si la herramienta devuelve un error (p. ej., «No se encontraron vuelos»), el agente puede razonar sobre el error e intentar un parámetro distinto (p. ej., «Buscar aeropuertos cercanos»), en lugar de rendirse o alucinar un vuelo. ⁶ Esta resiliencia es lo que separa a un agente de un script. Un script se cae ante un error; un agente se adapta.

La tabla siguiente destaca las diferencias arquitectónicas fundamentales que hacen de los sistemas agénticos la única opción viable para soluciones de viaje fiables.

Tabla 1: Wrappers LLM frente a sistemas agénticos

Característica	Wrapper LLM	Sistema de IA agéntica
Objetivo principal	Generar texto coherente respuesta	Ejecutar un flujo de trabajo de varios pasos para lograr el objetivo
Fuente de datos	Pesos preentrenados (Memoria congelada)	APIs y herramientas en tiempo real (Datos en vivo)
Arquitectura	Un solo turno Petición/Respuesta	Múltiples turnos Bucle «Reason-Act-Observe» (Razonar-Actuar-Observar)
Gestión de estado	Sin estado (depende de la ventana de contexto)	Con estado (mantiene conversación y estado del objetivo)
Fiabilidad	Baja (propensa a la alucinación)	Alta (anclada en las salidas de las herramientas)
Modo de fallo	Fabricación confiada	Informe de error o autocorrección
Coste	Bajo (solo costes de tokens)	Más alto (tokens + llamadas a API + sobrecarga de cómputo)
Conciencia del inventario	Ninguna (ciego)	Tiempo real (conectado al GDS)

2.2 El patrón Orquestador-Trabajador

En dominios complejos como los viajes, un solo agente suele ser insuficiente. Una sola indicación que intente gestionar vuelos, hoteles, alquiler de coches y restricciones alimentarias fracasará inevitablemente por sobrecarga de contexto e instrucciones en conflicto. Veriprajna aboga por el patrón Orquestador-Trabajador (Orchestrator-Worker) (también conocido como patrón supervisor-subordinado). ⁷

En esta arquitectura, desacoplamos la carga cognitiva.

●​ El orquestador (el cerebro): Un LLM de alto razonamiento (p. ej., GPT-4o o Claude 3.5 Sonnet) actúa como interfaz con el usuario. Analiza la petición en lenguaje natural, mantiene el historial de la conversación y determina el plan de alto nivel. No interactúa directamente con el GDS. Su trabajo es la gestión, no la ejecución. Decide qué hay que hacer, no cómo hacerlo.

●​ Los trabajadores (los especialistas): Son agentes especializados o bloques de código determinista equipados con herramientas concretas. Están «ciegos» a la conversación completa del usuario, pero son expertos en su dominio específico.

○​ Trabajador de vuelos: Especializado en interactuar con las APIs Amadeus Air. Sabe cómo interpretar códigos IATA y clases tarifarias. Comprende los matices de «layover» (escala) frente a «stopover» (estancia intermedia).

○​ Trabajador de hoteles: Especializado en las APIs Sabre CSL. Conoce la diferencia entre un «Deposit» (depósito) y una «Guarantee» (garantía). Comprende códigos tarifarios de hotel y descripciones de habitación.

○​ Trabajador de políticas: Comprueba la política de viajes corporativos del usuario (p. ej., «Sin business class en vuelos de menos de 4 horas»). Actúa como responsable de cumplimiento, rechazando opciones que violen las reglas antes de presentarlas al orquestador.

Flujo de trabajo de ejemplo:

1.​ Usuario: «Reserva un vuelo a NYC el martes que viene y un hotel cerca de Central Park.»

2.​ Orquestador: Descompone la intención en dos tareas: Task_A: Search Flights, Task_B: Search Hotels. Identifica que Task_B depende de la hora de llegada de Task_A.

3.​ Orquestador: Delega Task_A al trabajador de vuelos y Task_B al trabajador de hoteles.

4.​ Trabajador de vuelos: Llama a Amadeus_FlightSearch. Devuelve 3 opciones.

5.​ Trabajador de hoteles: Llama a Sabre_GetHotelAvail. Devuelve 3 opciones.

6.​ Orquestador: Sintetiza los resultados. «He encontrado un vuelo de Delta a las 8 AM y una habitación en el JW Marriott Essex House...»

Esta separación de responsabilidades permite un manejo robusto de errores. Si falla el trabajador de hoteles, el orquestador aún puede presentar las opciones de vuelo y preguntar al usuario si quiere reintentar la búsqueda de hotel con criterios distintos, en lugar de hacer caer toda la interacción. ⁷ También permite el desarrollo en paralelo; un equipo puede mejorar la ingeniería de indicaciones del trabajador de hoteles sin romper el trabajador de vuelos.

2.3 El bucle «Reason-Act-Observe»

El motor que impulsa a un agente es el bucle ReAct (Reason + Act). ⁹ En lugar de responder de inmediato, el agente entra en un monólogo interno, visible para los desarrolladores pero oculto (o resumido) para el usuario. Este monólogo permite al modelo «pensar antes de hablar».

●​ Pensamiento: El usuario quiere un hotel en Costa Rica por menos de 200 $. Necesito comprobar la disponibilidad.

●​ Acción: Call Tool_HotelSearch(location="Costa Rica", max_price=200, currency="USD").

●​ Observación: La API devuelve `` (lista vacía).

●​ Pensamiento: No se encontraron hoteles por menos de 200 $. El presupuesto del usuario podría ser demasiado bajo para «lujo». Debería buscar hoteles por menos de 300 $ e informar al usuario.

●​ Acción: Call Tool_HotelSearch(location="Costa Rica", max_price=300, currency="USD").

●​ Observación: La API devuelve ``.

●​ Respuesta final: «No pude encontrar ningún lodge de lujo por menos de 200 $, pero encontré dos opciones muy bien valoradas por menos de 300 $...»

Este bucle es lo que impide la alucinación. Un wrapper simplemente habría inventado un hotel por menos de 200 $ para satisfacer la restricción del usuario. El agente, limitado por la lista vacía de la API, se ve obligado a confrontar la realidad y negociar con el usuario. ¹⁰ El sistema agéntico, en esencia, tiene una «conciencia» derivada de las salidas de las herramientas: no puede decir lo que las herramientas no confirman.

Parte III: La fuente de verdad del inventario – inmersión profunda en el GDS

Para construir un agente de señal «verdadera», hay que dominar la integración con los Sistemas de Distribución Global (GDS). Estos sistemas —principalmente Amadeus, Sabre y Travelport— son las columnas vertebrales de la industria de los viajes. Son masivos, complejos e implacables. No hablan «inglés»; hablan en códigos de estado, segmentos y estricturas crípticas. Integrarse con ellos no consiste meramente en enviar peticiones HTTP; consiste en comprender la lógica arcana de la gestión de inventario de viajes.

3.1 Comprender la conectividad GDS: REST frente a SOAP/EDIFACT

Históricamente, interactuar con un GDS exigía conocimiento de EDIFACT (Electronic Data Interchange for Administration, Commerce and Transport) o de oscuros comandos de terminal (cryptic). Hoy, tanto Amadeus como Sabre ofrecen APIs JSON REST, mucho más accesibles para los agentes de IA modernos. ¹¹ Sin embargo, el legado de la era del mainframe sigue impregnando las estructuras de datos. Un agente debe poder traducir conceptos modernos (como «una habitación con vistas») a parámetros heredados (como RoomViewCode="SV").

APIs Amadeus Enterprise

Amadeus ofrece un conjunto rico de APIs «Self-Service» y «Enterprise». Para un sistema agéntico, los endpoints clave son:

●​ Hotel List API (/reference-data/locations/hotels/by-city): Devuelve los datos estáticos (IDs, nombres, ubicaciones) de hoteles en una ciudad. De forma crucial, esto no da disponibilidad. ¹³ Un agente que se base solo en esta API alucinará disponibilidad. Sabe que el hotel existe, pero no si tiene habitaciones.

●​ Hotel Search API (/shopping/hotel-offers): El peso pesado. Comprueba disponibilidad y precios en tiempo real. Devuelve una lista de «offers» asociadas a un hotel ID específico. ¹⁴ La estructura de esta respuesta es profunda y anidada, y exige un agente capaz de un análisis JSON complejo.

●​ Hotel Booking API (/booking/hotel-orders): Ejecuta la transacción real. Esta es la operación de «escritura» que compromete el dinero del usuario.

La estructura de datos de la verdad: Una respuesta de Amadeus para una oferta de hotel válida contiene un objeto JSON estructurado con un offerId único. Este ID es la «clave» de la realidad de esa habitación. Si la API no devuelve un offerId, la habitación, en la práctica, no existe, independientemente de lo que diga el sitio web del hotel. El agente debe entrenarse para tratar el offerId como el santo grial: sin él, no es posible ninguna reserva. Sabre Content Services for Lodging (CSL)

Sabre ha modernizado sus APIs de alojamiento bajo el paraguas CSL. Este sistema agrega contenido del GDS de Sabre y de agregadores de agregadores (como Expedia/Booking.com a través de Sabre). ¹⁵ Esta agregación añade una capa de complejidad: el agente debe distinguir entre una tarifa GDS (que podría retenerse con una tarjeta) y una tarifa de agregador (que podría exigir pago inmediato).

●​ Get Hotel Availability (GetHotelAvailRQ): Este es el motor de compra principal. Agrega contenido de múltiples fuentes.

●​ Enhanced Hotel Book (EnhancedHotelBookRQ): El motor de reserva. Gestiona la complejidad de crear el PNR, añadir el segmento y confirmar la transacción.

3.2 El lenguaje crítico de los códigos de estado

La trampa más peligrosa para un agente de IA es malinterpretar el «Status» de un segmento de reserva. Una reserva GDS no siempre es un binario «Reservado» o «Fallido». Existe en estados de flujo. Una reserva puede estar «Waitlisted», «Pending», «On Request» o «Confirmed». Una IA que trate «On Request» como «Confirmed» crea un desastre.

Tabla 2: Códigos de estado GDS críticos (estándar Sabre/Amadeus)

HK	Holding Confirmado	SUCCESS	El inventario está asegurado. El agente puede confirmar al usuario. Este es el único código que permite un mensaje de confirmación positivo.
UC	Unable to Confirm	FAILURE	El hotel rechazó la petición (a menudo por datos de caché obsoletos). El agente debe disculparse y volver a buscar.
NN	Need	PENDING	La petición se envía pero aún no está reconocida. No prometa confirmación todavía. El agente debe hacer polling de una actualización.
PN	Pending (Aggregator)	PENDING	Común en CSL para inventario no GDS. Exige polling del estado final.
NO	No Action Taken	FAILURE	El proveedor denegó la petición. Trátese como UC.
US	Unable to Sell	FAILURE	El tipo de habitación está en lista de espera o cerrado.

El escenario de la «reserva falsa»: Imagine un agente que llama a EnhancedHotelBookRQ. La API devuelve una respuesta. Un agente ingenuo podría ver 200 OK en la cabecera HTTP y decir al usuario: «¡Está reservado!» Sin embargo, dentro del cuerpo JSON, el estado del segmento podría ser UC (Unable to Confirm). La llamada HTTP tuvo éxito (el mensaje se entregó), pero la reserva falló. La desconexión entre la capa de transporte (HTTP) y la capa de aplicación (GDS Status) es una trampa clásica de los wrappers. Regla de oro de Veriprajna: un agente de IA nunca puede emitir un mensaje de confirmación salvo que analice el código de estado específico del segmento y lo valide como HK.¹⁶

3.3 El problema de la caché de inventario (Look-to-Book)

La disponibilidad GDS a menudo está en caché. La respuesta «Shop» (cuando el usuario busca) puede mostrar una habitación como disponible, pero milisegundos después, cuando se envía el comando «Book», la habitación puede haber desaparecido. Esta es la discrepancia «Look-to-Book». Es una ocurrencia habitual en los viajes, sobre todo en temporadas altas.

Los LLM son notoriamente malos explicando este matiz. Tienden a decir «¡Lo reservé!» o «Ha fallado». Les falta el vocabulario de «Estaba ahí hace un segundo, pero ahora se ha ido». Estrategia agéntica: el agente debe programarse con un flujo de trabajo de recuperación de errores.

●​ Si Book devuelve UC (Unable to Confirm):

○​ Entonces disparar automáticamente una nueva petición Shop del mismo hotel para ver si hay una tarifa/habitación distinta disponible.

○​ Si sí: Presentar la nueva opción al usuario («La tarifa anterior se agotó, pero encontré una habitación similar por 10 $ más»).

○​ Si no: Disculparse y sugerir el siguiente mejor hotel de la lista de búsqueda original.

Esto exige que el agente mantenga «estado»: una memoria de los resultados de búsqueda originales, lo que los wrappers simples no pueden hacer. El agente necesita, de hecho, una «memoria a corto plazo» del estado del mercado para navegar estos fallos con gracia.

3.4 Inmersión: el payload de datos de Amadeus frente a Sabre

Para construir un agente verdaderamente agnóstico, hay que manejar las diferencias en la estructura del payload. Amadeus usa una estructura JSON muy estricta y anidada en la que el precio se desglosa en base, total e impuestos. Un agente debe sumarlos correctamente o arriesgarse a cotizar un precio un 20 % más bajo que el cargo (excluyendo impuestos). Sabre a menudo devuelve precios con el impuesto ya incluido o desglosado de forma distinta según el RatePlan. Capa de normalización: Veriprajna construye un «trabajador de normalización» que toma los JSON dispares de Amadeus y Sabre y los convierte en un esquema interno estandarizado. El orquestador solo ve este esquema estándar. Así se evita que el LLM se confunda con las sutiles diferencias en las convenciones de nombres de campos (p. ej., amount frente a totalPrice).

Parte IV: La arquitectura de la fiabilidad – patrones y protocolos

Para implementar la visión de Veriprajna, desplegamos una pila arquitectónica específica diseñada para la fiabilidad determinista. No dejamos que el LLM navegue la web; le damos herramientas. Este capítulo detalla los patrones de diseño concretos que habilitan esta fiabilidad.

4.1 La interfaz de function calling (las «manos» de la IA)

El function calling (o uso de herramientas) es el mecanismo por el que un LLM solicita la ejecución de código. ⁹ En lugar de devolver texto, el LLM devuelve un objeto JSON estructurado que representa la firma de la función. Esto convierte de hecho al LLM en un compilador de lenguaje natural: compila instrucciones en inglés en llamadas JSON a APIs.

El esquema: Definimos las herramientas usando esquemas JSON estrictos de OpenAI o Anthropic. Un esquema descuidado conduce a un comportamiento descuidado del agente. El esquema es el contrato entre la IA y el código. Ejemplo de esquema para search_hotels:

{
  "name": "search_hotels",
  "description": "Queries the GDS for live hotel availability. ONLY use this when the user explicitly asks for hotel options or availability.",
  "parameters": {
    "type": "object",
    "properties": {
      "city_code": {
        "type": "string",
        "description": "The 3-letter IATA code of the city (e.g., NYC, LON, SIN).",
        "pattern": "^[A-Z]{3}$"
      },
      "check_in_date": {
        "type": "string",
        "format": "date",
        "description": "Check-in date in YYYY-MM-DD format. Must be in the future."
      },
      "max_price": {
        "type": "integer",
        "description": "Maximum price per night in the requested currency."
      }
    },
    "required": ["city_code", "check_in_date"]
  }
}

Por qué importa la tipificación estricta:

●​ pattern": "^[A-Z]{3}$" obliga al LLM a convertir «New York» en «NYC» antes de llamar a la herramienta. Si no lo hace, la capa de validación del esquema captura el error antes de que llegue al GDS, ahorrando costes de API y latencia. ¹⁹

●​ description: La descripción es en realidad parte de la indicación. Decirle al modelo cuándo usar la herramienta es tan importante como decirle cómo. Al añadir instrucciones como «ÚSALO SOLO cuando...», reducimos las llamadas innecesarias a la API.

4.2 El patrón del bucle de verificación (la «conciencia» de la IA)

Este es el diferenciador nuclear de la arquitectura de Veriprajna. Implementamos un bucle de doble comprobación para cada salida de alto valor (precios o confirmación de reserva). ²⁰ En un sistema estándar, la salida de la herramienta se alimenta al LLM, y el LLM habla al usuario. En nuestro sistema, hay un paso intermedio.

El flujo estándar (arriesgado): User -> LLM -> Tool -> LLM -> User. El flujo de verificación (seguro):

1.​ Orquestador: Decide reservar el Hotel X.

2.​ Trabajador: Ejecuta la herramienta de reserva. Devuelve Status: HK.

3.​ Verificador (LLM separado o lógica de código): Este es un paso silencioso. Una indicación (o código) aparte, altamente determinista, analiza la salida del trabajador.

○​ Indicación: «Eres un auditor de aseguramiento de la calidad. Revisa la siguiente respuesta JSON del GDS. ¿El estado del segmento es igual a 'HK'? Si sí, emite TRUE. Si no, emite FALSE.»

4.​ Orquestador: Solo si el verificador dice TRUE genera el mensaje de confirmación para el usuario.

Este bucle captura los errores del «valle inquietante» en los que un LLM podría leer mal un mensaje de error JSON complejo como un éxito. Actúa, en esencia, como una «comprobación de cordura» antes de que la IA haga una promesa que no puede cumplir.

4.3 Salida estructurada frente a relleno conversacional

En la IA empresarial, priorizamos la salida estructurada por encima del brillo conversacional. Cuando el GDS devuelve una lista de 5 hoteles, no volcamos simplemente el JSON en el contexto del LLM y le pedimos que «resuma». Esto consume tokens masivos e invita a la alucinación (p. ej., mezclar el precio del Hotel A con los servicios del Hotel B). El enfoque Veriprajna:

●​ Análisis de datos: Usamos código Python determinista para analizar el JSON del GDS. Extraemos exactamente: Name, Price, Star Rating y Distance from Center.

●​ Inyección de contexto: Inyectamos solo estos datos tabulares limpios en el contexto del LLM.

●​ Restricción: Instruimos al LLM: «Solo puedes describir los hoteles listados en los

Context Data proporcionados. No añadas conocimiento externo sobre estas propiedades.»

Esta técnica de «grounding» garantiza que si el GDS dice que el hotel no tiene piscina, la IA —aunque «sepa» por su preentrenamiento que esta marca suele tener piscinas— no prometirá una. ²¹ Obliga a la IA a atenerse al guion que proporciona el GDS.

Parte V: Construir los guardarraíles – implementación empresarial

5.1 Seguridad y redacción de PII

Las reservas de viajes implican información de identificación personal (PII) sensible: números de pasaporte, datos de tarjeta de crédito, nombres completos. Regla: la PII no entra nunca en la ventana de contexto del LLM si es posible. Este es un requisito crítico de seguridad. El patrón de tokenización:

1.​ El usuario proporciona los datos de la tarjeta de crédito mediante un formulario seguro en el cliente (conforme a PCI-DSS).

2.​ El frontend envía estos datos a una bóveda segura (p. ej., Stripe o un proveedor de pagos de viajes especializado), que devuelve un payment_token.

3.​ El texto enviado al LLM es: «User has provided payment method Token_123.»

4.​ El agente pasa Token_123 a la herramienta de reserva.

5.​ La herramienta (que se ejecuta en un backend seguro) intercambia el token por los datos reales de la tarjeta solo en el momento de la transmisión de la API al GDS.

El LLM nunca «ve» el número de la tarjeta de crédito, lo que impide que lo filtre accidentalmente en una respuesta alucinada futura o lo registre en un historial de chat. ¹⁹ Este patrón arquitectónico garantiza que, incluso si el LLM se ve comprometido o se le induce de forma maliciosa, no puede revelar datos financieros sensibles porque nunca los poseó.

5.2 Estrategias de latencia y caché

Los flujos de trabajo agénticos son más lentos que los wrappers. Una sola petición de usuario puede disparar 3-4 llamadas a herramientas (Search -> Price Check -> Policy Check -> Response). Esto puede tardar 10-15 segundos: una eternidad en el comercio electrónico. ²² En un mundo acostumbrado a las búsquedas instantáneas de Google, una espera de 15 segundos puede conducir al abandono.

Optimización Veriprajna:

●​ UI optimista: Transmitimos el proceso de «pensamiento» al usuario (p. ej., «Buscando en Amadeus vuelos...», «Comprobando la política corporativa...»). Este truco psicológico reduce la latencia percibida. El usuario ve que el agente está «trabajando», lo que hace tolerable la espera.

●​ Ejecución en paralelo: Usamos el patrón de trabajadores en paralelo. La búsqueda de vuelos y la de hoteles se ejecutan simultáneamente (de forma asíncrona), reduciendo el tiempo total de espera un 50 %. ⁷ En lugar de esperar a que termine la búsqueda de vuelos antes de iniciar la de hoteles, el orquestador lanza ambos hilos a la vez y sintetiza los resultados cuando ambos están listos.

●​ Caché por niveles: Guardamos en caché los resultados GDS «Shop» durante 15 minutos. Si el usuario pide «Muéstrame otra vez ese segundo hotel», lo recuperamos de la caché local de Redis en lugar de volver a golpear la API GDS, cara y lenta. Esto mejora la velocidad y reduce los costes de API.

5.3 El traspaso «humano en el bucle» (Human-in-the-Loop)

Ninguna IA es perfecta al 100 %. Siempre habrá casos límite: un itinerario complejo de varios tramos, un requisito de visado que la IA no entiende, o una caída del GDS. El sistema debe reconocer sus propias limitaciones. El sistema debe detectar «señales de frustración» (p. ej., el usuario repite la misma consulta, el análisis de sentimiento muestra ira) o «caídas de confianza» (el agente entra en bucle sin éxito). En estos casos, el agente debe degradarse con gracia a un modo «copiloto», alertando a un agente de viajes humano y pasándole el contexto estructurado completo de la conversación. El humano entonces completa la reserva de forma manual usando las herramientas que el agente preparó. Esto garantiza que el usuario nunca quede varado por una IA confundida.

Parte VI: Prepararse para el futuro – el camino hacia los agentes de viaje autónomos

La tecnología que desplegamos hoy es el cimiento del agente de viajes autónomo. En la actualidad, estamos en autonomía de nivel 3 (automatización condicional): el agente ejecuta tareas específicas bajo supervisión humana (el usuario confirma la reserva).

El camino al nivel 5:

●​ Agentes de negociación: Agentes que no se limitan a reservar precios listados, sino que llaman a APIs de hotel para negociar tarifas de grupo según el volumen. Imagine un agente que pueda decir a una API de hotel: «Tengo 50 viajeros buscando habitaciones; dame un 20 % de descuento.»

●​ Empaquetado dinámico: Agentes que construyen paquetes a medida (vuelo + hotel + coche) consultando APIs dispares y empaquetándolos en un único precio opaco, gestionando el margen de forma dinámica. Esto permite crear producto único sobre la marcha.

●​ Gestión proactiva de disrupciones: Un agente que monitoriza el estado de los vuelos 24/7. Cuando un vuelo se cancela, el agente —sin entrada del usuario— ya retiene un asiento en el siguiente mejor vuelo y presenta la opción al usuario en el momento en que aterriza.

Este futuro exige la arquitectura rigurosa, con estado y verificada descrita en este documento. No puede construirse sobre wrappers. No puede construirse sobre alucinaciones. Exige un replanteamiento fundamental de cómo integramos la IA con los sistemas heredados.

Conclusión: la promesa Veriprajna

La historia de la familia que llega a un hotel inexistente en Costa Rica es una parábola de la era de la IA. Nos advierte de que la creatividad sin restricción es caos.

En Veriprajna, creemos que el valor de la IA en los viajes no está en escribir hermosas descripciones de hoteles, sino en encontrar hoteles disponibles y asegurarlos de forma fiable. No somos meros integradores de API; somos arquitectos de la confianza. Entendemos que, en la industria de los viajes, la confianza es la única moneda que importa. Si un usuario no puede confiar en que la IA reserve una habitación real, no la usará.

Construimos integraciones GDS agénticas que:

1.​ No adivinan: Consultan.

2.​ No alucinan: Verifican.

3.​ No solo hablan: Actúan.

¿Su IA planifica viajes o escribe ficción? Con Veriprajna, la respuesta es siempre determinista.

Apéndice técnico detallado: especificaciones de integración

Apéndice A: estructura JSON de Amadeus Hotel Search (simplificada)

Petición (agente -> herramienta):

{
"cityCode": "SJO",
"checkInDate": "2025-12-10",
"checkOutDate": "2025-12-15",
"roomQuantity": 1,
"adults": 2,
"radius": 50,
"radiusUnit": "KM",
"hotelName": "ECO LODGE"
}

Respuesta (herramienta -> agente): Nota: el agente debe analizar el booleano available y el objeto price.

{
"data": [...]
}

Apéndice B: lógica de estado de segmento Sabre

Código de respuesta	Flujo lógico
HK (Holding Confirmed)	->PASS. Proceder a la generación del PNR.
UC (Unable to Confirm)	->FAIL. Disparar la lógica de reintento con el siguiente código de tarifa.
LL (Waitlist)	->FAIL (para reserva de consumidor). No presentar como reservable.
SS (Sold Segment)	->PASS. Equivalente a HK en el mensaje inicial de venta.

Obras citadas

1. LLM Hallucinations – Causes and Solutions - Clickworker, consultado el 10 de diciembre de 2025, https://www.clickworker.com/customer-blog/llm-hallucinations/

2. AI Hallucinations in Travel Apps Lead to Fake Landmarks and Dangers WebProNews, consultado el 10 de diciembre de 2025, https://www.webpronews.com/ai-hallucinations-in-travel-apps-lead-to-fake-landmarks-and-dangers/

3. The $500 Billion Hallucination: How LLMs Are Failing in Production | by Yobie Benjamin, consultado el 10 de diciembre de 2025, https://medium.com/@yobiebenjamin/the-500-billion-hallucination-how-llms-are-failing-in-production-75ebb589a76c

4. Agentic AI Frameworks | 2025 - - Flobotics, consultado el 10 de diciembre de 2025, https://flobotics.io/blog/agentic-ai-frameworks/

5. Agentic AI vs LLM: Comparing What Scales Better in Task Runners - Lyzr AI, consultado el 10 de diciembre de 2025, https://www.lyzr.ai/blog/agentic-ai-vs-llm/

6. How agent-oriented design patterns transform system development - Outshift | Cisco, consultado el 10 de diciembre de 2025, https://outshift.cisco.com/blog/how-agent-oriented-design-paterns-transform-stystem-development

7. Agentic AI Design Pattern — Orchestrator-Worker | by Pytrick L ..., consultado el 10 de diciembre de 2025, https://pytrick.medium.com/agentic-ai-design-patern-orchestrator-worker-6d76tfc09f0cf

8. Four Design Patterns for Event-Driven, Multi-Agent Systems - Confluent, consultado el 10 de diciembre de 2025, https://www.confluent.io/blog/event-driven-multi-agent-systems/

9. The LLM Function Design Pattern: A Structured Approach to AI ..., consultado el 10 de diciembre de 2025, https://medium.com/aimonks/the-llm-function-design-patern-a-structured-apprtoach-to-ai-powered-software-development-f4192945d5f4

10. Function Calling, Tools & Agents: The Next Layer of LLM Intelligence - Diggibyte, consultado el 10 de diciembre de 2025, https://diggibyte.com/function-calling-tools-agents-the-next-layer-of-llm-intelligence/

11. Open Source LangChain App Dev Toolkit, LLM API Integration | Amadeus for Developers, consultado el 10 de diciembre de 2025, https://developers.amadeus.com/blog/amadeus-self-service-apis-are-now-available-in-langchain

12. Amadeus for Developers: Connect to Amadeus travel APIs, consultado el 10 de diciembre de 2025, https://developers.amadeus.com/

13. Hotel List API - Geolocation Database, Find Nearby Hotels - Amadeus for Developers, consultado el 10 de diciembre de 2025, https://developers.amadeus.com/self-service/category/hotels/api-doc/hotel-list

14. Hotel Search and Shopping APIs | Enterprise APIs - Amadeus for Developers, consultado el 10 de diciembre de 2025, https://developers.amadeus.com/enterprise/category/hotel/api/search-and-shopping

15. Content Services for Lodging: Get Hotel Availability | Dev Studio, consultado el 10 de diciembre de 2025, https://developer.sabre.com/guides/travel-agency/content-services-for-lodging-get-hotel-avail

16. Technical Overview - Sabre Dev Studio, consultado el 10 de diciembre de 2025, https://developer.sabre.com/technical-overview-0

17. EnhancedHotelBookRQ - Sabre Dev Studio, consultado el 10 de diciembre de 2025, https://developer.sabre.com/enhancedhotelbookrq

18. Tool Calling in LLMs: How to Integrate APIs, Search Engines & Internal Systems Medium, consultado el 10 de diciembre de 2025, https://medium.com/@amitkharche14/tool-calling-in-llms-how-to-integrate-apis-search-engines-internal-systems-9371a1b0f008

19. Stop AI Hallucinations: A Developer's Guide to Prompt Engineering - Shelf.io, consultado el 10 de diciembre de 2025, https://shelf.io/blog/stop-ai-hallucinations-a-developers-guide-to-prompt-engineering/

20. What Are AI Hallucinations? [+ Protection Tips] - Palo Alto Networks, consultado el 10 de diciembre de 2025, https://www.paloaltonetworks.com/cyberpedia/what-are-ai-hallucinations

21. preventing hallucinations in AI: best practices for customer service AI agents Ada.cx, consultado el 10 de diciembre de 2025, https://www.ada.cx/blog/preventing-hallucinations-in-ai-best-practices-for-customer-service-ai-agents/

22. AI Voice Agents for Travel: STT/TTS Architecture, GDS Integration, and HotelPlanner Case Study - Softcery, consultado el 10 de diciembre de 2025, https://sofcery.com/lab/ai-voice-agents-for-travel-agencies-selection-integratiotn-guide