RGPD y datos del huésped

El dato del huésped es de los más sensibles que maneja un hotel. Un nombre, una habitación, unas fechas y unas peticiones son, juntos, una foto bastante completa de la vida de una persona durante varios días. Por eso el RGPD los trata con más exigencia que un correo cualquiera, y por eso elegir el software del hotel no es solo una decisión de producto: también es una decisión de cumplimiento.

Esta guía explica qué exige el RGPD al hotel y a su proveedor, cómo protege Estevano el dato del huésped y qué seis preguntas hacer a cualquier proveedor antes de firmar. Con un compromiso: no presumir de certificaciones que no tenemos. Las de tipo ISO o SOC 2 se hablan con cada cliente que las pide.

Por qué el dato del huésped es tan sensible

En un hotel se cruzan tres cosas que ya serían sensibles por separado y que juntas lo son mucho más:

• Identidad. Nombre, apellidos, idioma y, donde la ley lo pide, el documento. Identifica a la persona sin duda.
• Dónde está. La habitación y las fechas de entrada y salida. Dicen dónde está esa persona ahora mismo.
• Qué hace. Peticiones, alergias, gustos e incidencias. Permiten deducir hábitos, salud y preferencias.

Una filtración aquí no es un riesgo abstracto. Es saber quién está en qué habitación, si duerme solo o acompañado, qué alergias tiene y a qué hora pidió la última cena. Por eso conviene ser estrictos.

Qué exige el RGPD al hotel y al proveedor

El RGPD hace responsable del tratamiento al hotel y encargado del tratamiento al proveedor. Cada uno tiene su papel, pero los dos responden. Lo que no se negocia:

• Una base legal clara. Tratar el dato para lo que el huésped espera (su estancia y sus peticiones) o, para lo demás, con su consentimiento expreso.
• Minimización. Pedir solo lo necesario. Si para pedir una toalla no hace falta el DNI, no se pide.
• Contrato de encargo del tratamiento. Regula cómo trata el proveedor el dato, dónde lo guarda y qué pasa si hay un incidente.
• Los derechos del huésped. Acceso, rectificación, supresión y portabilidad. El proveedor tiene que permitirlos técnicamente.
• Aviso de brechas. Si algo sale mal, hay 72 horas para comunicarlo a la AEPD, y al afectado cuando proceda.

Hasta aquí la teoría. Lo interesante es cómo se convierte en una arquitectura que de verdad proteja al huésped, no solo que pase una auditoría.

Cómo lo hace Estevano

Estevano se construyó con esta lógica desde el principio. Sin certificaciones que no tenemos:

• El PIN del huésped, cifrado en el servidor. El PIN con el que el huésped entra en la app y confirma lo que pide por teléfono se guarda con bcrypt. No viaja en claro y no se puede recuperar desde la base de datos.
• Bloqueo por intentos. Si alguien intenta adivinar un PIN a base de probar, el sistema bloquea. La comprobación se hace siempre en el servidor, nunca en el móvil.
• Cada hotel, aislado. La base de datos aplica seguridad por filas (RLS): un empleado o un huésped del hotel A no puede leer datos del hotel B, ni siquiera por un fallo de la app. No es un filtro de la pantalla que se pueda saltar: es una barrera de la propia base de datos.
• Datos alojados en la UE. La base de datos y los archivos del hotel se guardan en servidores de la Unión Europea, cifrados en reposo y en tránsito.
• Pocos datos personales. Estevano no necesita el DNI ni los datos de pago del huésped para el día a día. Trabaja con habitación, PIN y datos de la operación. Cuanto menos se pide, menos hay que proteger.
• Acceso y supresión. Hoy es un proceso manual: a petición del hotel, y según el contrato de encargo, el equipo de Estevano exporta o elimina los datos de un huésped.

Lo que no decimos: hoy no tenemos publicada una certificación ISO 27001 ni SOC 2 Type II. Las conversaciones serias sobre cumplimiento las tenemos con cada cliente, con su contrato de encargo y con las pruebas de cada control de esta lista.

Cumplir en el papel o estar hecho para aislar

Hay proveedores que cumplen en el papel: un contrato bonito, una política de privacidad y una página de seguridad, pero por dentro todos los hoteles comparten las mismas tablas sin aislamiento real. Eso es delicado legalmente y frágil en la práctica: una consulta mal escrita y un hotel ve los datos de otro.

Estar hecho para aislar es otra cosa: es la propia base de datos la que impide que un hotel acceda a los datos de otro, haga lo que haga el código de la app. Es una diferencia de arquitectura, no de marketing. Estevano se hizo así desde el principio porque nació para muchos hoteles y muchas marcas.

Dónde encaja la IA en el RGPD

Cuando el huésped escribe al conserje de IA, la conversación se procesa para entender qué quiere y hacerlo. Aquí el RGPD pide dos cosas: que el huésped sepa que habla con una IA y que sus datos no se usen para entrenar modelos sin su consentimiento.

En Estevano el huésped sabe que habla con el conserje de IA del hotel, no con una persona. Las conversaciones sirven para atenderle a él, no como material para entrenar modelos de terceros. Los modelos de lenguaje se usan a través de proveedores que se comprometen a no entrenar con los datos de los clientes. Para entender cada mensaje, la conversación pasa por esos proveedores, y su tratamiento no siempre se hace dentro de la UE. Es justo lo que conviene preguntar a cualquier proveedor.

Seis preguntas de RGPD antes de firmar

Si estás eligiendo software para tu hotel, lleva estas preguntas a la reunión y pide respuestas concretas:

1. ¿Cómo aisláis los datos de cada hotel? Quieres oír "seguridad por filas en la base de datos" o algo equivalente, no "filtramos por hotel en el código".
2. ¿Dónde se tratan y se guardan los datos? La región (UE, Estados Unidos...), el proveedor de nube y si los datos salen de la UE.
3. ¿Cómo se identifica al huésped? PIN cifrado, bloqueo por intentos y comprobación en el servidor. Si te dicen "con el número de habitación" y nada más, eso no es identificar a nadie.
4. ¿Firmáis un contrato de encargo con el detalle del RGPD? Pide verlo antes de firmar el contrato comercial.
5. ¿Cómo atendéis los derechos del huésped? Acceso, supresión y portabilidad: con qué proceso y quién lo hace.
6. ¿Se usan los datos del huésped para entrenar modelos? Si la respuesta no es un "no" claro, sigue buscando.

Conclusión

El RGPD no se cumple con una página de marketing: se ve en la arquitectura. Aislar cada hotel, cifrar el PIN, guardar los datos en la UE, pedir pocos datos personales y tener un proceso claro para los derechos del huésped son los cimientos. Las certificaciones llegan después, encima de esos cimientos, no en su lugar.

Si quieres ver cómo encaja todo en la plataforma, mira el producto o la marca blanca.