RGPD e IA en tu web turística: 5 decisiones de un caso real

En mi web hay una herramienta gratuita, el Genio del Prompting, que procesa texto de los usuarios con un modelo de IA. Le cuentas en dos frases qué quieres conseguir, eliges para qué IA es —ChatGPT, Claude, Gemini, Midjourney, Veo y otras, en texto, imagen, vídeo, agentes y SEO— y te devuelve un prompt afinado para ese modelo concreto, listo para pegar. Sin registro. Montarla me obligó a responder, con decisiones concretas, las mismas preguntas que se hace cualquier negocio turístico que añade un chatbot, un formulario inteligente o simple analítica: qué guardo, qué cuento, y a quién le pido permiso. Estas son las cinco decisiones que tomé y por qué — aviso previo: no soy abogado, y esto es experiencia documentada, no asesoramiento legal.

1. El consentimiento tiene que bloquear de verdad

El error más extendido en webs turísticas es el banner decorativo: aparece, pide permiso... y mientras tanto los scripts de medición ya han cargado. Eso no es consentimiento; es atrezzo.

En mi caso, el gestor de etiquetas —y con él toda la analítica— no se carga hasta que el usuario pulsa aceptar. Si rechaza, no se carga nunca. Y rechazar cuesta exactamente el mismo clic que aceptar, que es el criterio que la autoridad española de protección de datos viene marcando para los banners. La prueba de fuego es técnica y cualquiera puede hacerla: abre tu web en una ventana privada, no aceptes nada, y mira en las herramientas del navegador qué peticiones salen. Lo que cargue antes de tu "sí" te retrata.

2. El mejor dato es el que no guardas

Cuando diseñé el registro de uso de mi herramienta, la decisión más importante fue negativa: no guardar direcciones IP. No las necesitaba para nada útil, y cada dato personal que almacenas es responsabilidad que contraes — hay que protegerlo, declararlo y poder borrarlo cuando alguien lo pida.

Es el principio de minimización aplicado con lógica de negocio: antes de guardar un campo, la pregunta no es "¿podría servirme algún día?" sino "¿qué decisión concreta tomaré con esto?". Sin respuesta clara, fuera. Para un hotel o agencia, el mismo filtro aplicado al formulario de reservas suele eliminar la mitad de los campos — y de paso mejora la conversión, porque cada campo extra espanta.

3. Si hay IA procesando texto, se dice — en claro y al lado

Mi herramienta envía el texto del usuario a un proveedor de IA para procesarlo. Eso se cuenta, y se cuenta donde se usa: un aviso corto junto al propio formulario —el texto se procesa con IA, no introduzcas datos personales ni confidenciales, se guarda de forma anónima— con enlace a una página de términos que detalla qué se almacena, cuánto tiempo y con qué derechos. Doble capa: aviso breve en el punto de uso, detalle completo a un clic.

Al montarla me hice la pregunta que se hará cualquiera: si uso la cuota gratuita de la API de Gemini, ¿entrena Google sus modelos con ese texto? Fuera de Europa, sí puede. Dentro, no: los términos de la API de Gemini establecen que en el Espacio Económico Europeo, Suiza y el Reino Unido se aplican a todo el servicio, cuota gratuita incluida, las mismas condiciones de uso de datos que en la versión de pago. Y esas condiciones dicen que Google no usa los prompts ni las respuestas para mejorar sus productos. Yo trabajo desde España, así que el texto que pasa por mi herramienta no entrena a Gemini.

Pero que no entrene no significa que el dato desaparezca, y por eso el aviso sigue pidiendo que no se escriban datos personales. Por tres razones:

• Google lo registra un tiempo. Los mismos términos dicen que guarda prompts y respuestas durante un periodo limitado para detectar abusos y atender obligaciones legales. El texto viaja a sus servidores y queda anotado.
• Mi propia infraestructura también guarda. El objetivo, el contexto y el prompt generado se conservan de forma anónima hasta 12 meses para mejorar la herramienta. Si alguien escribe ahí su DNI, su DNI se queda ahí. Cada sistema por el que pasa un texto es un punto más desde el que se puede filtrar.
• Hay datos con reglas propias. Un nombre junto a una alergia ya es un dato de salud, de categoría especial en el RGPD. Un número de tarjeta en crudo entra en la norma PCI DSS. Una API de IA generalista no está pensada ni certificada para hacer de pasarela de pagos ni de historial clínico.

Es exactamente lo que debería llevar cualquier chatbot turístico, y casi ninguno lleva: el huésped que escribe al asistente de un hotel merece saber que su texto lo procesa una máquina de un tercero, y qué pasa con él.

4. Nombra al proveedor, no a tu arquitectura

Matiz aprendido al redactar mis propios términos: la normativa exige identificar a las empresas que tratan datos por tu cuenta — no exige publicar tu esquema técnico. En mi política nombro a los proveedores y su función (infraestructura técnica, procesamiento del texto con IA), sin detallar versiones ni configuraciones concretas. Cumples igual, y no publicas gratis el mapa de tu instalación a cualquiera que quiera buscarle las costuras. En un sector que maneja datos de pago y de viaje, ese pudor técnico es simple higiene de seguridad.

5. Los datos de clientes no se pegan en la IA pública. Nunca.

La regla más importante es también la más fácil de incumplir un martes con prisa: nada de pegar nombres, emails, reservas o incidencias de clientes en las versiones públicas de ChatGPT, Gemini o similares. Al hacerlo pierdes el control del dato, que puede acabar usado para entrenamiento — y ningún cliente te dio permiso para eso. Las guías del propio sector hotelero lo señalan ya expresamente (Cloudbeds, 2026). Para trabajar con datos reales hacen falta versiones de empresa o API con garantías contractuales.

La solución operativa es sencilla y barata: plantillas anonimizadas. "Redacta una respuesta a un cliente que se queja de ruido en la habitación X la noche del día Y" funciona igual de bien sin nombre, sin email y sin número de reserva. Es la misma regla previa que abre los cinco pasos del plan de marketing con IA: datos reales del negocio, sí; datos personales de clientes en herramientas públicas, nunca.

El resumen honesto

Nada de lo anterior exigió abogados caros ni frenó ninguna funcionalidad: fueron decisiones de diseño tomadas a tiempo, casi todas más baratas que su alternativa descuidada. Esa es la lectura que ofrezco a cualquier negocio turístico que esté añadiendo IA: el RGPD no es el impuesto que pagas al final del proyecto — es un conjunto de decisiones de producto que, tomadas al principio, salen casi gratis, y tomadas tarde, cuestan una reforma. Y en un negocio construido sobre la confianza de gente que te da su nombre, su tarjeta y sus fechas de vacaciones, tratar los datos con ese cuidado no es solo cumplimiento: es coherencia con lo que vendes.