Los modelos de lenguaje grande (LLMs) como Claude o GPT-4 son extraordinariamente capaces de entender contexto, responder preguntas y ejecutar tareas en lenguaje natural. El problema para la industria hotelera es que estos modelos no saben nada sobre las reservas de su hotel, la disponibilidad de sus habitaciones ni las tarifas de mañana. Esa información vive en su PMS.
La integración entre LLMs y sistemas PMS es el puente que convierte un modelo genérico de lenguaje en un asistente que puede responder a un huésped: "Su reserva de dos noches en la suite junior llega el jueves, check-in desde las 3pm. Tiene el desayuno incluido." sin que un agente humano haya tocado la conversación.
Esta guía explica cómo construir esa integración de forma segura, sin reemplazar el PMS, y sin exponer datos de huéspedes a riesgos innecesarios.
La arquitectura correcta: el LLM como capa de conversación
El error más común en proyectos de este tipo es intentar que el LLM "use" el PMS directamente. El modelo correcto es diferente: el LLM actúa como interfaz conversacional; el PMS sigue siendo la fuente de verdad. La arquitectura tiene tres componentes:
↓
[Capa de orquestación] → interpreta la intención + consulta el PMS
↓
[PMS API] → devuelve datos de reserva / disponibilidad / tarifas
↓
[LLM] → genera respuesta en lenguaje natural con los datos reales
↓
[Usuario] → recibe respuesta contextualizada
En esta arquitectura, el LLM nunca modifica datos en el PMS directamente. Todas las escrituras (modificar reserva, hacer upgrade, aplicar descuento) pasan por una función validada con lógica de negocio explícita. El LLM solo lee contexto y genera texto.
Acceso API por PMS
Cloudbeds
Cloudbeds ofrece una API REST documentada con autenticación OAuth2. Tiene endpoints para reservas, disponibilidad, huéspedes, tarifas y reportes. El plan Enterprise incluye acceso completo a la API; en planes inferiores, algunos endpoints están restringidos. El límite de rate es 100 peticiones por minuto, suficiente para la mayoría de implementaciones conversacionales.
Opera (Oracle Hospitality)
Opera Cloud expone una API REST moderna desde la versión 22.x. Las versiones anteriores (Opera On-Premise 5.x) requieren conexión vía base de datos Oracle o el middleware OHIP (Oracle Hospitality Integration Platform). Para hoteles con Opera On-Premise, OHIP es el camino más limpio, aunque añade latencia y costo de licencia.
Mews
Mews tiene la API más moderna y developer-friendly de los tres. Su Connector API permite operaciones de lectura y escritura con granularidad alta. Mews también ofrece webhooks para eventos (nueva reserva, check-in completado, solicitud de servicio), lo que permite arquitecturas reactivas más eficientes que el polling.
Casos de uso reales y sus requisitos de integración
Caso 1: Asistente de check-in digital
El huésped recibe un WhatsApp 24 horas antes con un enlace. El asistente confirma datos, responde preguntas sobre servicios y registra preferencias especiales en el PMS. Requiere: lectura de reserva, actualización de notas de huésped, envío de comunicación.
Caso 2: Respuesta automática a solicitudes de información
El canal de WhatsApp del hotel recibe preguntas sobre disponibilidad, precios y servicios. El asistente responde en tiempo real con datos actuales del PMS. Requiere: consulta de disponibilidad en tiempo real, lectura de tarifas vigentes, política de cancelación.
Caso 3: Soporte durante la estadía
El huésped manda mensaje pidiendo toallas adicionales, reportando un problema en la habitación o solicitando late check-out. El asistente crea el ticket en el PMS y confirma el tiempo de respuesta. Requiere: creación de work orders, consulta de disponibilidad de late check-out, lectura del perfil del huésped.
Principio de mínimo privilegio: El token de API que usa el LLM debe tener solo los permisos que necesita para los casos de uso activos. No otorgue permisos de escritura global si el asistente solo necesita leer reservas.
Protección de datos de huéspedes
La integración debe garantizar que los datos personales de los huéspedes no queden almacenados en los logs del proveedor de LLM. Las prácticas mínimas recomendadas:
- Anonimización en el prompt: En lugar de enviar "Juan Pérez, pasaporte MEX123456", el sistema envía un identificador interno y recupera los datos al construir la respuesta final.
- No logging de conversaciones con PII: Configurar el proveedor de LLM para no almacenar conversaciones (Anthropic y OpenAI ofrecen esta opción en planes enterprise).
- Retención de datos definida: Las conversaciones del asistente deben tener una política de retención explícita (típicamente 90 días), alineada con la política de privacidad del hotel.
- Acceso solo a la reserva activa: El asistente no debe poder acceder al historial completo del huésped sin una razón explícita de negocio.
Costos operativos de la integración
El costo de un asistente LLM conectado al PMS tiene dos componentes variables:
- Llamadas a la API del LLM: Aproximadamente $0.01-0.03 USD por conversación completa con un modelo de calidad alta. Para un hotel boutique con 50 habitaciones y 200 conversaciones al mes, el costo en LLM es de $2-6 USD mensuales.
- Infraestructura de orquestación: El servidor que conecta el canal (WhatsApp, web) con el PMS y el LLM. Típicamente $400-800 MXN/mes en la nube.
El canal de comunicación (WhatsApp Business API) tiene un costo adicional de $0.04-0.08 USD por conversación iniciada por el hotel, y es gratuito para conversaciones iniciadas por el usuario en las primeras 24 horas.
Cuándo tiene sentido y cuándo no
La integración LLM-PMS genera valor claro cuando:
- El hotel recibe más de 50 consultas de huéspedes por mes fuera de horario de recepción
- El equipo pierde tiempo respondiendo las mismas preguntas repetitivas
- Se quiere escalar comunicación sin escalar personal
No recomendamos la integración cuando el hotel tiene menos de 20 habitaciones y operación familiar directa — en ese caso, la relación personal es el diferenciador y un asistente automático puede percibirse como impersonal.
El proceso de implementación
Un proyecto de integración LLM-PMS bien ejecutado toma 5-7 semanas:
- Semanas 1-2: Auditoría del PMS, identificación de casos de uso prioritarios, diseño de arquitectura
- Semanas 3-4: Desarrollo de conectores, configuración del LLM con contexto del hotel (servicios, políticas, personalidad de marca)
- Semana 5: Pruebas con escenarios reales, ajuste de respuestas, activación del canal
- Semanas 6-7: Operación supervisada, ajuste de casos no contemplados, transferencia al equipo del hotel