El dato del huésped es uno de los más sensibles que maneja un hotel: un nombre, una habitación, unas fechas de estancia y unas peticiones son, juntos, una foto bastante completa de la vida de una persona durante varios días. Por eso el RGPD trata estos datos con un nivel de exigencia mayor que el de un email cualquiera, y por eso elegir proveedor de software hotelero no es solo una decisión de producto: es también una decisión de cumplimiento. Esta guía explica, sin humo, qué exige el RGPD a un hotel y a su proveedor, cómo aborda Estevano la protección del dato del huésped a nivel técnico, y qué seis preguntas concretas plantear a cualquier proveedor antes de firmar. Lo escribimos con un compromiso: no afirmar certificaciones que no tenemos (ISO, SOC2 y similares se tratan 1:1 con cada cliente que las pide). Por qué el dato del huésped es especialmente sensible El dato del huésped no es "cliente de e-commerce": en un hotel se cruzan tres cosas que, individualmente, ya serían sensibles, y juntas son delicadas: Identidad. Nombre, apellidos, idioma, a veces documento (en jurisdicciones donde se exige). Permite identificar a la persona inequívocamente. Localización temporal. Habitación, fechas de entrada y salida. Permite saber dónde está esa persona ahora mismo. Comportamiento. Peticiones, alérgenos, gustos, incidencias. Permite inferir hábitos, salud, preferencias. Una filtración aquí no es un riesgo abstracto. Es saber quién está en qué habitación, durmiendo solo o acompañado, con qué alergias y a qué hora pidió la última cena al room service. Por eso conviene ser estrictos. Qué exige el RGPD al hotel y al proveedor El RGPD obliga al hotel como responsable del tratamiento y al proveedor como encargado del tratamiento. Cada uno tiene papel distinto, pero ambos responden. Los puntos no negociables: Base legal clara. Tratar el dato solo para lo que el huésped razonablemente espera (ejecutar su estancia, atender sus peticiones), o con consentimiento explícito para el resto. Minimización. Pedir solo lo necesario. Si para que el huésped pida una toalla no hace falta su DNI, no se pide. Encargado de tratamiento (DPA). Contrato entre hotel y proveedor que regula cómo procesa el dato, dónde lo guarda y qué pasa si hay incidente. Derechos del huésped. Acceso, rectificación, borrado y portabilidad de sus datos. El proveedor debe permitirlo técnicamente. Notificación de brecha. Si algo sale mal, hay 72 horas para notificarlo a la AEPD y al afectado cuando proceda. Hasta aquí la teoría. Lo interesante es cómo se traduce eso en una arquitectura técnica que realmente proteja al huésped, no solo a la auditoría. Cómo lo aborda Estevano (técnico y honesto) Estevano se construyó con esta lógica desde el primer día. Lo contamos sin certificaciones que no tenemos: PIN del huésped hasheado en servidor. El PIN con el que el huésped entra a la app y verifica acciones por voz se guarda hasheado tipo bcrypt. No viaja en claro y no se puede revertir desde la base de datos. Bloqueo por intentos. Si alguien intenta adivinar un PIN por fuerza bruta, el sistema bloquea. La verificación siempre ocurre en servidor, nunca en el cliente. Aislamiento estricto por hotel. Cada hotel es un tenant. La base de datos aplica Row-Level Security (RLS): un empleado o huésped del Hotel A nunca puede leer datos del Hotel B, ni por error de la app. No es un filtro del frontend que se podría saltar; es una barrera de la propia base de datos. Hosting en UE disponible. Para hoteles europeos, el procesamiento y almacenamiento se mantiene dentro del Espacio Económico Europeo, con datos cifrados en reposo y en tránsito. Mínimo de datos personales. Estevano no necesita DNI ni datos de pago del huésped para operar el día a día. Trabaja con habitación + PIN y datos operativos. Cuanto menos se pide, menos hay que proteger. Borrado y acceso. A petición del hotel, los datos de un huésped pueden exportarse o eliminarse de forma completa, no solo "ocultarse" desde la UI. Lo que no afirmamos: no tenemos hoy una certificación ISO 27001 ni SOC 2 Type II publicadas. Las conversaciones serias sobre cumplimiento avanzado las llevamos 1:1, con DPA específico y con evidencias de cada control técnico mencionado arriba. "Cumplir en el papel" vs estar construido para aislar Hay proveedores que cumplen en el papel : tienen un DPA bonito, una política de privacidad y una página de "seguridad", pero por dentro todos los hoteles comparten la misma tabla, sin aislamiento real entre tenants. Eso es legalmente complicado y operativamente frágil: una consulta mal escrita y un hotel ve datos del otro. Estar construido para aislar es distinto: la base de datos misma impide que un hotel acceda a datos de otro, independientemente de qué haga el código de la app. Es una diferencia de arquitectura, no de marketing. Estevano se construyó así desde el primer día, porque ya estaba pensado multi-hotel y multi-marca. Y la IA, ¿dónde encaja en el RGPD? Cuando el huésped escribe al conserje IA, la conversación se procesa para entender intención y disparar acciones. El RGPD exige aquí dos cosas: que el huésped sepa que está hablando con IA, y que sus datos no se usen para entrenar modelos sin consentimiento. En Estevano el huésped sabe que conversa con el conserje IA del hotel, no con un humano. Las conversaciones se usan para servirle a él, no como material de entrenamiento de modelos externos. Los modelos lingüísticos se invocan a través de proveedores con compromisos de no-entrenamiento sobre datos del cliente. Checklist: 6 preguntas RGPD antes de firmar Si estás evaluando software hotelero, llévate estas preguntas a la reunión y exige respuestas concretas: 1. ¿Cómo aislan los datos entre hoteles? Quieres oír "Row-Level Security en base de datos" o equivalente, no "filtramos por hotel en el código". 2. ¿Dónde se procesan y almacenan los datos? Región (UE, EE. UU., etc.), proveedor cloud, y si los datos salen de la UE. 3. ¿Cómo se autentica al huésped? PIN hasheado, bloqueo por intentos, verificación en servidor. Si te dicen "con el número de habitación" sin más, eso no es autenticación. 4. ¿Firmáis DPA con el detalle del RGPD? Pide ver el documento antes de firmar el contrato comercial. 5. ¿Cómo respondéis a derechos del huésped? Acceso, borrado y portabilidad: con qué proceso, en qué plazo y quién opera. 6. ¿Los datos del huésped se usan para entrenar modelos? Si la respuesta no es un "no" claro, sigue mirando. Conclusión El cumplimiento del RGPD no se compra en una página de marketing: se reconoce en la arquitectura. Aislamiento real por hotel, PIN hasheado, hosting en UE, mínimo de datos personales y procesos claros para los derechos del huésped son los cimientos. Las certificaciones llegan después, encima de ese cimiento, no en vez de él. Si quieres ver cómo encaja todo esto en una plataforma de conserjería digital, mira el producto, o, si gestionas varios hoteles, marca blanca.