Cómo preparar los datos de un hotel para agentes de IA

Un hotel está preparado para agentes de inteligencia artificial cuando sus sistemas pueden identificar, describir, cotizar y modificar una reserva sin ambigüedad, con permisos explícitos y un registro de lo ocurrido. No basta con conectar un modelo al PMS ni con cargar documentos en un chatbot.

En 30 segundos: antes de automatizar una reserva, el hotel necesita identificadores estables para propiedades y habitaciones, una fuente autorizada para cada dato, disponibilidad y precios consultados en tiempo real, operaciones transaccionales idempotentes, permisos por acción y una salida a humano. La IA interpreta la intención del huésped; el código valida tarifas, inventario, políticas, pagos y confirmaciones.

El problema no empieza en el modelo

En la sesión Is Traveltech ready for AI? How to feed the Artificial Agents, celebrada en ITB Berlin, Matthias Spohr, CEO de GIATA, y Bradley Johnson, vicepresidente de producto de Sabre, llegan al mismo punto desde dos lados del mercado: los agentes no pueden compensar una base de datos fragmentada.

Spohr lo resume en seis palabras: “Better data to deliver better travel.” Su argumento no es que la IA necesite más contenido, sino que necesita distinguir entidades, atributos y estados con suficiente precisión para actuar.

Un viajero puede entender que “habitación superior con terraza” y “doble premium exterior” quizá describan productos parecidos. Un sistema necesita identificadores, atributos comparables y reglas explícitas. Si nueve distribuidores nombran de forma distinta cinco habitaciones, el agente no ve cinco opciones: ve decenas de cadenas de texto potencialmente diferentes.

El problema se vuelve serio cuando la IA deja de inspirar y empieza a ejecutar. Recomendar un hotel equivocado es una mala respuesta. Reservar el hotel equivocado, cobrar y emitir una confirmación es un incidente operativo.

De dato correcto a dato operativo

El vídeo utiliza un ejemplo útil: un hotel estaba a 15 kilómetros en línea recta del lugar de una boda, pero una montaña convertía el trayecto real en unos 80 kilómetros por carretera. El primer dato podía ser matemáticamente correcto y, al mismo tiempo, inútil para la decisión del huésped.

Para un agente, la calidad no se reduce a que un campo tenga un valor. Un dato hotelero debe cumplir al menos cinco condiciones:

Condición	Pregunta operativa
Identidad	¿Sabemos sin duda a qué hotel, habitación, tarifa o reserva se refiere?
Autoridad	¿Qué sistema puede afirmar y modificar este dato?
Vigencia	¿Cuándo se actualizó y durante cuánto tiempo sigue siendo válido?
Contexto	¿Qué restricciones cambian su significado: ocupación, fechas, canal, moneda o política?
Trazabilidad	¿Podemos reconstruir de dónde salió y qué proceso lo transformó?

Google aplica una lógica parecida en su infraestructura hotelera. Su referencia de datos estructurados para precios exige que el identificador del hotel coincida con el utilizado en el feed de precios y que la información estructurada sea coherente con lo visible. Su esquema de alojamiento también incluye un identificador de propiedad y una fecha de última actualización.

No son requisitos diseñados específicamente para agentes generativos. Son una señal de algo más básico: para distribuir y vender inventario hotelero, la identidad y la vigencia del dato ya eran fundamentales antes de la IA.

Las seis capas que debe ordenar un hotel

No hace falta centralizar todo en una única aplicación. Hace falta que cada capa tenga responsabilidades claras y contratos estables.

1. Identidad canónica

Cada propiedad, tipo de habitación, plan tarifario, servicio y reserva necesita un identificador interno estable. El nombre comercial puede cambiar; el identificador no.

GIATA plantea esta dificultad a escala de distribución con identificadores de hotel y mapeo de habitaciones. Su documentación explica cómo GIATA Drive centraliza contenido estructurado y cómo los códigos internos, del PMS y de los canales deben relacionarse para distribuir correctamente cada tipo de habitación.

Para una cadena, el principio puede aplicarse sin adoptar una plataforma concreta: crear una tabla de correspondencias entre el ID interno y los IDs de PMS, channel manager, motor, CRM, OTA y proveedor de contenido.

2. Contenido de propiedad y habitación

Servicios, políticas, accesibilidad, horarios, imágenes y atributos de habitación no deberían vivir únicamente en textos libres repartidos entre extranets.

Conviene separar:

• hechos verificables: tamaño, ocupación, camas, accesibilidad, horarios;
• contenido comercial: descripción y narrativa;
• condiciones variables: disponibilidad, precio, restricciones y promociones;
• inferencias: “ideal para familias” o “ambiente tranquilo”, que necesitan criterio y evidencia.

La IA puede adaptar la narrativa. No debería inventar el hecho subyacente.

3. Inventario, precio y políticas

Son datos dinámicos y deben consultarse cerca del momento de decisión. Un índice semántico o una base vectorial puede responder qué incluye una habitación, pero no debería confirmar si queda disponible o cuánto cuesta ahora.

El agente necesita herramientas separadas para:

1. buscar opciones candidatas;
2. consultar disponibilidad y precio vigentes;
3. validar ocupación, impuestos y restricciones;
4. bloquear o reservar inventario;
5. volver a comprobar antes de cobrar.

4. Perfil y consentimiento del huésped

Preferencias, historial y contexto pueden mejorar la respuesta, pero no todo dato disponible debe entrar en cada conversación. El sistema necesita distinguir entre dato permitido, dato necesario y dato sensible.

El CRM puede ser la autoridad para consentimiento y preferencias; el PMS, para la estancia activa. La capa de integración decide qué parte se expone a cada agente según finalidad, rol y momento del viaje.

5. Operaciones transaccionales

Crear una reserva, cancelar, modificar fechas o emitir un enlace de pago son comandos, no respuestas de texto. Cada comando debería tener:

• esquema de entrada validado;
• permisos mínimos;
• clave de idempotencia para evitar duplicados;
• estados explícitos: solicitado, pendiente, confirmado o fallido;
• compensación o procedimiento de recuperación;
• registro del actor, herramienta y resultado.

La alianza anunciada por Sabre, Mindtrip y PayPal ilustra esta separación: la experiencia conversacional puede descubrir y guiar, mientras APIs preparadas para agentes y una capa de pago ejecutan las partes deterministas.

6. Observabilidad y revisión humana

Un agente en producción necesita más que logs de conversación. Hay que poder responder:

• qué intención detectó;
• qué datos recuperó y con qué antigüedad;
• qué herramientas llamó;
• qué política permitió o bloqueó la acción;
• qué cambió en cada sistema;
• cuándo y por qué intervino una persona.

Sin esa trazabilidad, un hotel puede medir mensajes respondidos, pero no fiabilidad operativa.

Un contrato de datos mínimo

Este ejemplo simplificado no pretende imponer un estándar. Muestra la diferencia entre entregar al agente texto suelto y ofrecerle una entidad verificable:

{
  "propertyId": "htl_es_men_004",
  "roomTypeId": "room_deluxe_seaview",
  "source": {
    "system": "pms",
    "externalId": "DLX-SV-2",
    "observedAt": "2026-10-11T08:15:00Z"
  },
  "facts": {
    "maxOccupancy": 2,
    "bedType": "king",
    "accessible": false,
    "amenities": ["balcony", "coffee_machine"]
  },
  "offer": {
    "arrival": "2026-11-12",
    "departure": "2026-11-15",
    "currency": "EUR",
    "total": 642.0,
    "refundable": true,
    "expiresAt": "2026-10-11T08:30:00Z"
  }
}

El modelo puede explicar la oferta, compararla con las preferencias y pedir una aclaración. No puede cambiar total, extender expiresAt ni asumir que accessible: false es aceptable para el huésped.

Este límite reduce al mismo tiempo alucinaciones, errores de integración y discusiones posteriores sobre qué información vio el cliente.

Qué decide la IA y qué debe seguir siendo determinista

La arquitectura más segura no intenta convertir todo en IA. Separa interpretación de ejecución.

La IA puede	El código debe
Interpretar una petición en lenguaje natural	Validar fechas, ocupación y formatos
Detectar información que falta	Consultar inventario y precio autorizados
Comparar opciones según preferencias	Aplicar impuestos, restricciones y políticas
Redactar una explicación personalizada	Controlar permisos e idempotencia
Resumir el caso para recepción	Confirmar el cambio en el sistema de registro
Recomendar la siguiente acción	Cobrar, conciliar y registrar la transacción

El patrón práctico es: LLM para la ambigüedad, herramientas para los hechos y código para las garantías.

También evita un error habitual: dar acceso directo al PMS a un agente generalista. El agente debería recibir herramientas estrechas —por ejemplo, buscar_disponibilidad, preparar_cambio o cancelar_con_confirmacion—, no una API abierta con decenas de operaciones y permisos compartidos.

Cómo evaluar si el hotel está preparado

Antes de elegir modelo o proveedor, intenta responder estas preguntas con evidencia:

1. ¿Existe un inventario actualizado de PMS, motor, channel manager, CRM, RMS, pagos y herramientas operativas?
2. ¿Cada entidad crítica tiene un identificador estable y una tabla de correspondencias entre sistemas?
3. ¿Está definido qué sistema manda para cada dato?
4. ¿Se conoce la latencia de cada sincronización?
5. ¿Las APIs permiten leer y escribir las operaciones necesarias?
6. ¿Los webhooks se reintentan y procesan de forma idempotente?
7. ¿Las políticas comerciales están estructuradas o solo existen en PDFs y conocimiento del equipo?
8. ¿Se puede reconstruir una reserva desde la intención inicial hasta el cobro?
9. ¿Hay permisos separados para consultar, proponer y ejecutar?
10. ¿Existe una cola clara de revisión humana para excepciones?

Si varias respuestas dependen de “pregúntale a esta persona”, el primer proyecto no es un agente. Es documentar el proceso y convertir conocimiento informal en estado compartido.

En una Radiografía de una cadena de cuatro hoteles encontramos 47 aplicaciones donde la dirección estimaba unas 25, doce herramientas sin propietario claro y tres dependencias críticas de personas. La diferencia entre el mapa declarado y el real es precisamente lo que una implementación de IA hereda si empieza demasiado pronto.

Una secuencia de implantación realista

Fase 1 — Inventariar y elegir un proceso

No empieces por “crear un agente para el hotel”. Elige un proceso con dueño y métrica: responder preguntas pre-stay, clasificar solicitudes de grupos o gestionar cambios sencillos de reserva.

Fase 2 — Definir entidades y autoridades

Documenta IDs, campos obligatorios, sistema de origen, frecuencia de actualización y reglas de reconciliación. Si dos sistemas afirman cosas diferentes, decide cuál gana y cómo se alerta.

Fase 3 — Construir herramientas estrechas

Expón únicamente las consultas y comandos necesarios. Añade validación, timeouts, reintentos, idempotencia y respuestas de error pensadas para que el orquestador pueda decidir si reintenta, pregunta o escala.

Fase 4 — Operar primero en modo copiloto

El agente prepara la respuesta o la acción; una persona confirma. Esta fase produce casos reales para ajustar políticas y descubrir excepciones sin conceder autonomía prematura.

Fase 5 — Automatizar por nivel de riesgo

Las preguntas informativas con fuente fiable pueden automatizarse antes. Un cambio con coste, una cancelación no reembolsable o una decisión sobre accesibilidad mantienen confirmación explícita.

Fase 6 — Medir resultado operativo

No midas solo contención del chatbot. Mide precisión de la respuesta, tiempo hasta resolución, errores por tipo de operación, transferencias útiles, reservas completadas y discrepancias entre sistemas.

La ventaja no será tener un agente antes

Los canales cambiarán. Los modelos también. La parte reutilizable es una operación con datos identificables, APIs controladas y decisiones trazables.

El hotel que ordene esa base podrá conectar asistentes web, WhatsApp, herramientas internas o nuevos canales de reserva sin reconstruir la lógica cada vez. El que añada un agente sobre sistemas fragmentados tendrá una interfaz moderna reproduciendo errores antiguos a mayor velocidad.

Por eso, el primer paso no es comprar otro chatbot. Es saber qué sistemas existen, cómo se conectan y dónde se rompe el dato.