RGPD e IA en la gestión de inquilinos y huéspedes: qué exige la ley

Un agente de IA que atiende a inquilinos o huéspedes trata datos personales en cada mensaje: nombre, teléfono, a veces documento de identidad para el registro de viajeros, historial de reservas, incidencias reportadas y, en ocasiones, datos de pago. El RGPD y la LOPDGDD no hacen ninguna excepción porque el tratamiento lo ejecute un sistema y no una persona. Las obligaciones son las mismas y, en un punto concreto —la transparencia—, hay que ser más explícito precisamente por eso.

Conviene empezar por el reparto de papeles, que es de donde cuelga todo lo demás: la gestora, el operador o el propietario que decide para qué se tratan los datos es el responsable del tratamiento. El proveedor de software que los procesa siguiendo sus instrucciones es el encargado. Esa distinción no es burocracia: determina quién responde ante la Agencia Española de Protección de Datos y quién tiene que poder demostrar qué.

La base legal del tratamiento

Antes de que el agente conteste el primer mensaje tiene que estar decidido bajo qué base legal se tratan esos datos. En la gestión de inquilinos y huéspedes casi siempre es la ejecución del contrato —el arrendamiento o la reserva—: no hace falta pedir un consentimiento aparte para gestionar el check-in de quien ya ha reservado, porque tratar sus datos es necesario para cumplir lo pactado. Hay obligaciones que se apoyan en otra base distinta, el cumplimiento de una obligación legal, como la comunicación de los datos del viajero al registro de la Administración.

Donde sí hace falta consentimiento —libre, específico y revocable— es en todo lo que va más allá de la estancia: comunicaciones comerciales, encuestas con fines de marketing o cesión a terceros que no participan en la prestación. Mezclar los dos planos en una misma casilla al hacer el check-in es uno de los errores que más se ven, y no se arregla con una frase en las condiciones.

Transparencia y decisiones automatizadas

La información al interesado tiene que estar disponible en el momento en que se recogen sus datos, no escondida tres clics más abajo: quién trata, para qué, con qué base, cuánto tiempo y cómo ejercer los derechos. Cuando la atención la lleva un sistema automatizado, conviene además que se pueda saber que se está hablando con uno y cómo pedir una persona. No hace falta un cartel a media conversación; hace falta que nadie tenga que averiguarlo.

Distinto, y más serio, es el terreno del artículo 22 del RGPD: las decisiones únicamente automatizadas que producen efectos jurídicos o afectan significativamente a alguien. Responder una duda o abrir una incidencia no entra ahí. Descartar a un candidato a inquilino, denegar una solicitud o resolver una retención de fianza sin que intervenga una persona, sí puede entrar. La línea práctica es sencilla y conviene escribirla antes de encender nada: lo que decide sobre el acceso a una vivienda o sobre el dinero de alguien lo aprueba una persona.

Los derechos del inquilino o huésped no cambian

Acceso, rectificación, supresión, limitación, portabilidad y oposición se aplican igual cuando quien atiende es un agente. En la práctica, eso significa que el sistema tiene que poder responder a «¿qué datos tenéis míos?» o «quiero que borréis mi historial» de forma verificable y en plazo, no con una respuesta educada. Si un inquilino pide la supresión y el agente contesta que ya está hecho sin que exista un proceso real detrás, eso no es un detalle de producto: es un incumplimiento.

Lo razonable es que esas peticiones no las resuelva el agente. Que las reconozca, las registre con su fecha —que es la que empieza a contar— y las escale a quien lleva la protección de datos en la empresa.

Minimización: el agente no necesita saberlo todo

Un error frecuente al montar un agente conversacional es darle acceso a más información de la que necesita para resolver la conversación que tiene delante. El que gestiona check-ins no necesita ver el histórico de pagos de toda la cartera para decir dónde está la llave. La minimización no es solo un principio legal: es lo que limita el daño cuando algo sale mal. Cuanto menos dato innecesario circula, menor es la superficie expuesta ante un error, una fuga o un acceso indebido.

Merece la pena revisarlo por perfiles: qué ve el agente de atención, qué ve el equipo de mantenimiento, qué ve el proveedor externo que acude a la avería. Casi siempre, al proveedor le basta la dirección, el acceso y la descripción del problema.

Plazos de conservación

Los datos no se guardan indefinidamente por si acaso. Tiene que haber un criterio escrito de cuánto se conserva cada tipo de dato una vez terminada la relación, y qué ocurre al cumplirse: borrado efectivo o anonimización real. Y no todos los plazos son iguales: la documentación con efectos fiscales o contables tiene el suyo, el registro documental de viajeros tiene el que fija su propia norma —que no se puede acortar por política interna— y una conversación de atención que ya no sirve para nada no tiene por qué sobrevivir a ninguna de las dos.

Esto pesa especialmente en alquiler turístico y coliving, donde la rotación es alta y en dos años se acumulan históricos de mucha gente que ya no tiene ninguna relación con la propiedad.

Qué garantías debe poder ofrecer el proveedor

Si la atención se apoya en un proveedor externo, ese proveedor es encargado del tratamiento y eso trae obligaciones concretas que hay que poder verificar, no dar por supuestas:

• Contrato de encargado firmable, y no una cláusula genérica en los términos de uso: qué datos se tratan, con qué finalidad, durante cuánto tiempo y bajo qué instrucciones.
• Cifrado en tránsito y en reposo, y control de quién, dentro del proveedor, puede acceder a las conversaciones y con qué justificación.
• Trazabilidad. Poder consultar qué dijo el sistema, cuándo y a quién. Sirve para resolver una discusión con un inquilino y para demostrar cumplimiento si lo pide la autoridad de control.
• Ubicación de los datos y, si hay transferencia fuera del Espacio Económico Europeo, el mecanismo que la ampara.
• Subencargados declarados —incluidos los proveedores de modelos de lenguaje— y aviso previo cuando cambien, con derecho a oponerse.
• Notificación de brechas sin dilación indebida, para que el responsable pueda cumplir su propio plazo con la autoridad. Si el proveedor avisa tarde, el que llega tarde eres tú.

Hay una garantía más que conviene exigir por escrito y que no siempre está: que los datos de la empresa no se usen para entrenar modelos del proveedor ni de terceros, y que estén aislados de los de sus demás clientes.

Qué preguntar antes de contratar

Seis preguntas concretas, y conviene desconfiar de quien no las conteste con precisión:

1. ¿Puedo firmar un contrato de encargado del tratamiento, y qué cubre exactamente?
2. ¿Dónde se almacenan los datos y las conversaciones, y quién los subprocesa?
3. ¿Puedo consultar el historial completo de una conversación gestionada por el sistema?
4. ¿Qué ocurre con los datos de un inquilino o un huésped cuando termina la relación, y en qué plazo?
5. ¿Están aislados de los de otros clientes, y se usan para entrenar algún modelo?
6. ¿En cuánto tiempo me avisáis de una brecha, y con qué información?

La responsabilidad no se delega del todo

Contratar a un proveedor que cumple no traslada la responsabilidad. El responsable sigue teniendo que saber qué datos recoge, para qué, cuánto los guarda y a quién se los cede, y sigue teniendo que reflejarlo en su registro de actividades de tratamiento aunque la conversación la lleve un sistema. Si el tratamiento cambia de escala o de naturaleza —empezar a tratar documentos de identidad, por ejemplo—, toca revisar si hace falta una evaluación de impacto.

En términos de protección de datos, la diferencia entre automatizar bien y automatizar mal no está en usar IA o no usarla. Está en si alguien de la empresa puede explicar, con detalle verificable, qué hace el sistema con cada dato que toca. Si esa persona existe y esa explicación está escrita, la automatización es defendible; si no, el problema ya existía antes de la IA.