Personalización hotelera con IA: cómo usar datos sin invadir al huésped

La personalización hotelera no consiste en que una cámara identifique a cada persona que cruza el vestíbulo. Consiste en que el equipo pueda comprender una necesidad y actuar en el momento adecuado sin obligar al huésped a repetir información ni exponer más datos de los necesarios.

En 30 segundos: empieza por una decisión de servicio concreta, no por reconocimiento facial ni por un chatbot. Unifica únicamente el contexto necesario, registra finalidad y consentimiento, aplica políticas antes de mostrar o ejecutar una recomendación y ofrece siempre una alternativa no biométrica. La IA interpreta y prioriza; los sistemas autorizados validan identidad, reserva, permisos y acción. Si la propuesta no mejora una métrica del recorrido o no puede explicarse al huésped, no debería pasar del prototipo.

El problema no es la falta de datos

Un hotel puede acumular información en PMS, CRS, CRM, fidelización, motor de reservas, POS, spa, restaurante, encuestas y bandejas de entrada. Aun así, la persona que atiende una llegada puede no saber que el vuelo se retrasó, que existe una incidencia abierta o que el huésped ya declaró una preferencia relevante.

En la sesión When the Hotel Sees You: Inside the Predictive Future of Guest Recognition and Augmented Reality, David Poprawka, estratega de innovación de Infor, formula esa contradicción: la hostelería dispone de datos en muchos sistemas, pero el contexto no aparece cuando ocurre el encuentro de servicio. La presentación muestra prototipos con realidad aumentada y visión artificial; su enseñanza más transferible no es el dispositivo, sino el proceso de innovación:

1. definir el problema que merece resolverse;
2. reunir el contexto en una capa gobernada;
3. dar a los agentes herramientas estrechas para consultar y actuar;
4. construir un prototipo y medirlo en la propiedad real;
5. decidir con evidencia si la experiencia justifica el riesgo y el coste.

El orden importa. Empezar por unas gafas, una cámara o un modelo conduce a buscar después una utilidad. Empezar por una fricción permite comprobar si basta con una solución más simple.

La pregunta útil no es “¿cómo reconocemos a todos los huéspedes?”, sino “¿qué decisión mejora si conocemos un dato determinado en este momento?”.

Reconocer no significa identificar por la cara

La identificación puede diseñarse como un espectro de menor a mayor intrusión:

Mecanismo	Ejemplo	Riesgo relativo	Uso razonable
Contexto anónimo	ocupación, cola, idioma elegido	bajo	adaptar capacidad o interfaz sin identificar personas
Declaración en la conversación	nombre y motivo facilitados al equipo	bajo	localizar una reserva o incidencia con confirmación
Enlace o código de reserva	QR, magic link o localizador	bajo-medio	abrir el expediente correcto por iniciativa del huésped
Sesión autenticada	app, wallet o programa de fidelización	medio	recuperar preferencias consentidas entre canales
Proximidad voluntaria	credencial móvil activada por el usuario	medio	preparar una llegada o un acceso con alcance limitado
Biometría uno a uno	verificar que la persona coincide con una plantilla aportada	alto	autenticación excepcional con alternativa equivalente
Identificación biométrica uno a muchos	buscar un rostro en una base de datos	muy alto	difícil de justificar para personalización ordinaria
Inferencia de emociones	estimar estado emocional por cara, voz o conducta	muy alto	experimental; requiere análisis jurídico y científico específico

La mayoría de los casos hoteleros no necesita las tres últimas filas. Si el huésped puede escanear un código o presentarse ante el equipo, la biometría puede ser desproporcionada.

Además, “reconocer” puede significar reconocer la situación, no a la persona: una habitación incompleta, una mesa mal montada, una cola que crece o un equipo que requiere mantenimiento. La sesión de ITB propone precisamente usos de visión para housekeeping y banquetes donde el objeto del análisis es el estándar operativo. Estos casos también necesitan controles, pero evitan convertir cada interacción en identificación personal.

Arquitectura de contexto para el servicio

Una solución mantenible separa cinco responsabilidades.

1. Sistemas de registro

El PMS gobierna reserva y estancia; el CRM, consentimiento y relación; el POS o sistema de restaurante, consumos y reservas; la aplicación operativa, tareas; y el sistema de fidelización, identidad y beneficios. Ninguno tiene que contenerlo todo.

2. Resolución de identidad

Relaciona identificadores solo cuando existe una base autorizada. Debe distinguir entre una coincidencia confirmada, una probable y una inexistente. Una coincidencia de nombre nunca debería fusionar perfiles por sí sola.

3. Capa de contexto

Construye una vista temporal para una interacción, no una copia ilimitada del huésped. Puede responder: reserva activa, idioma, solicitudes abiertas, preferencia confirmada, consentimiento aplicable y próxima acción permitida.

Esta capa complementa el trabajo de preparar los datos del hotel para agentes de IA: añade finalidad, vigencia y exposición a cada dato, no solo estructura.

4. Motor de políticas

Decide qué puede verse y hacerse según propiedad, rol, canal, momento y consentimiento. El mismo dato puede ser válido para preparar la habitación y no para aparecer sobreimpreso en unas gafas delante de acompañantes.

5. Interfaz y herramientas de acción

El colaborador recibe una sugerencia breve, su motivo y una acción posible. Si acepta reprogramar una mesa, la herramienta consulta disponibilidad, ejecuta la modificación y registra el resultado. Mostrar contexto sin poder cerrar el proceso crea otra pantalla, no una mejora.

PMS / CRM / POS / Operaciones / Fidelización
                 │
        identidad + consentimiento
                 │
      contexto mínimo de la interacción
                 │
        política por rol y finalidad
                 │
     recomendación → aprobación → acción
                 │
        resultado, auditoría y aprendizaje

El estado debe ser persistente. Si el empleado cambia de dispositivo o la llamada a un sistema falla, la operación tiene que poder recuperar qué se propuso, qué se aprobó y qué ocurrió.

Un contrato mínimo de contexto

Antes de elegir un modelo, define el objeto que puede consumir. Por ejemplo:

{
  "interaction_id": "int_01J...",
  "property_id": "mad_centro_01",
  "stay_id": "stay_48291",
  "identity_assurance": "authenticated_link",
  "purpose": "arrival_assistance",
  "locale": "es",
  "signals": [
    {
      "type": "flight_delay",
      "value": "95_minutes",
      "source": "flight_status_provider",
      "observed_at": "2026-10-11T16:20:00Z",
      "expires_at": "2026-10-12T00:00:00Z"
    }
  ],
  "preferences": [
    {
      "type": "restaurant_preference",
      "value": "steakhouse",
      "source": "guest_declared",
      "confirmed_at": "2026-05-14T18:03:00Z"
    }
  ],
  "allowed_actions": ["offer_late_arrival_help", "propose_table_change"],
  "prohibited_actions": ["display_companion_history"],
  "consent_version": "guest-experience-v3",
  "retention_until": "2026-11-11T00:00:00Z"
}

Los campos importantes no son los más vistosos. purpose, identity_assurance, source, expires_at, allowed_actions y retention_until permiten evitar que una señal antigua o recogida para otra finalidad se convierta en una recomendación actual.

El modelo no debería recibir pasaporte, tarjeta, notas libres históricas ni datos de otros huéspedes cuando solo necesita sugerir una acción de llegada.

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

La IA resulta útil para:

• resumir el contexto de varios sistemas;
• clasificar la intención de una solicitud;
• detectar que una incidencia y una reserva pertenecen al mismo recorrido cuando los identificadores ya están vinculados;
• proponer una siguiente acción entre opciones autorizadas;
• convertir una instrucción del equipo en parámetros para una herramienta;
• detectar anomalías visuales en un entorno acotado y probado.

El código y los sistemas autorizados deben:

• autenticar al usuario y resolver la reserva;
• comprobar consentimiento, finalidad y permisos;
• validar disponibilidad, precio, beneficio o política;
• impedir acciones fuera del catálogo permitido;
• controlar idempotencia y concurrencia;
• registrar quién vio, aprobó y ejecutó cada acción;
• aplicar retención, revocación y borrado.

Un LLM tampoco es obligatorio para cada paso. Clasificación pequeña, búsqueda estructurada, visión especializada o reglas de elegibilidad pueden ser más baratas y predecibles. La decisión arquitectónica debe seguir el problema y la evidencia, no la moda del modelo.

Privacidad, biometría y reconocimiento de emociones

En Europa, una imagen no se convierte automáticamente en dato biométrico, pero sí lo hace cuando se aplica un tratamiento técnico específico para permitir o confirmar la identificación única. El RGPD sitúa esos datos, cuando se usan para identificar de manera unívoca, entre las categorías especiales. Los tratamientos con nuevas tecnologías y alto riesgo pueden requerir una evaluación de impacto previa.

Las directrices del Comité Europeo de Protección de Datos sobre dispositivos de vídeo y la guía de la AEPD sobre sistemas biométricos insisten en necesidad, proporcionalidad, minimización, seguridad y alternativas. Aunque la guía española se centra en control de presencia, ayuda a entender por qué “tenemos consentimiento” no debería utilizarse como atajo para desplegar identificación facial en un vestíbulo.

Desde el 2 de agosto de 2026, las obligaciones de transparencia del artículo 50 del Reglamento de IA exigen informar a las personas expuestas a sistemas de reconocimiento de emociones o categorización biométrica. Esa obligación de informar no responde por sí sola a las demás preguntas: base jurídica, exactitud, discriminación, conservación, acceso, transferencias y derecho a una alternativa.

Antes de un piloto con biometría o inferencia emocional, el hotel debería poder demostrar:

1. una finalidad específica y medible;
2. que una opción menos intrusiva no resuelve el problema;
3. una base jurídica válida para cada tratamiento;
4. una evaluación de impacto y participación del DPO cuando corresponda;
5. información clara antes de la exposición;
6. alternativa equivalente sin penalización;
7. límites de retención y almacenamiento seguro;
8. pruebas de falsos positivos por grupos y condiciones reales;
9. intervención humana y canal de reclamación;
10. capacidad de detener y borrar el piloto.

También conviene separar personalización de inferencia. Una preferencia declarada por el huésped suele ser más fiable y respetuosa que deducirla de su rostro, gasto o acompañantes.

Casos de uso que pueden justificar un piloto

Llegada afectada por un retraso

El huésped proporciona voluntariamente el número de vuelo. El sistema detecta un retraso y encuentra una reserva de restaurante que ya no encaja. La IA propone reprogramarla; una persona confirma; el restaurante devuelve el nuevo estado. No hace falta reconocer un rostro.

Preferencia operativa confirmada

El huésped declaró almohada hipoalergénica en una estancia anterior y autorizó conservar la preferencia. Antes de la próxima llegada, el sistema crea una tarea y housekeeping confirma su realización. La recepción ve “preferencia preparada”, no el historial completo.

Copiloto para incidencias

Al abrir una reserva, el agente recibe un resumen de solicitudes activas y acciones pendientes. Puede cerrar, escalar o pedir confirmación. La IA reduce búsqueda; no decide compensaciones fuera de política.

Control visual de una habitación

Una aplicación compara la habitación con una plantilla de calidad y señala objetos ausentes o una anomalía. Las imágenes se procesan con alcance y retención definidos; no se reutilizan para vigilar al personal ni identificar al huésped.

Montaje de un evento

La visión detecta diferencias entre el plano aprobado y el montaje real. El sistema crea tareas por zona y conserva evidencia del resultado. Este caso conecta con la automatización de ventas y operaciones MICE sin tratar datos biométricos.

Métricas y observabilidad

La personalización debe mejorar una decisión, no solo producir recomendaciones.

Dimensión	Métricas recomendadas
Servicio	resolución en primer contacto, tiempo hasta la acción, repeticiones evitadas
Adopción	sugerencias vistas, aceptadas, modificadas y descartadas
Calidad	contexto correcto, perfiles confundidos, preferencias obsoletas, falsos positivos
Ejecución	acciones confirmadas, fallidas, duplicadas, revertidas y escaladas
Confianza	quejas, revocaciones, alternativas solicitadas y satisfacción
Privacidad	accesos fuera de finalidad, datos excesivos, retención vencida y exportaciones
Negocio	recuperación de incidencias, upsell aceptado, repetición y coste por interacción

Cada recomendación debería producir una traza: señales utilizadas, versión del modelo, política aplicada, salida, decisión humana, herramienta llamada y resultado. Para mejorar el sistema, registra también el motivo de rechazo; no conviertas todas las correcciones en más datos de entrenamiento sin una revisión de finalidad.

Define guardarraíles. Un aumento de conversión no compensa una subida de perfiles confundidos, quejas o accesos indebidos. Una reducción del tiempo medio tampoco justifica mostrar información sensible en público.

Un plan de implantación en 90 días

Días 1–30 — Elegir una decisión y mapear los datos

• seleccionar un momento de servicio frecuente y medible;
• describir la acción que hoy llega tarde o sin contexto;
• localizar fuentes, identificadores, consentimiento y propietario;
• eliminar campos que no sean necesarios;
• medir tiempo, errores, repetición y satisfacción actuales;
• realizar el análisis jurídico y de seguridad inicial.

Días 31–60 — Construir un copiloto sin biometría

• crear el contrato de contexto y el motor de políticas;
• usar identificación voluntaria o autenticada;
• mostrar una sola recomendación explicable;
• mantener aprobación humana;
• ejecutar mediante una herramienta idempotente;
• registrar accesos, correcciones y resultado.

Días 61–90 — Pilotar, comparar y decidir

• activar el flujo en una propiedad y una cohorte limitada;
• comparar con el proceso anterior o con un grupo de control;
• revisar errores, sesgo, quejas y beneficios;
• probar revocación, caída de sistemas y perfiles ambiguos;
• decidir si se amplía, rediseña o elimina;
• evaluar tecnologías más intrusivas solo si queda una necesidad no resuelta.

El objetivo es presencia, no vigilancia

La mejor personalización puede ser casi invisible: el equipo sabe qué hacer, el huésped conserva el control y la operación confirma el resultado. La tecnología deja de competir por la atención y devuelve la mirada a la conversación.

Reconocer al huésped no exige adivinar su emoción ni identificarlo a distancia. Exige integrar sistemas, gobernar contexto y diseñar límites verificables. Antes de añadir cámaras o modelos, conviene reconstruir dónde se pierde hoy la información y qué decisión concreta debería mejorar.

Ese es el punto de partida de una Radiografía Digital Hotelera: transformar datos dispersos en servicio útil sin convertir la hospitalidad en vigilancia.