Si estás pensando en contratar un chatbot / asistente de IA generativa para tu destino (web, app…), en 2026 ya no vale con “que responda bien”.
La clave es otra: que puedas demostrar control.
Control de fuentes, datos, seguridad, auditoría y cumplimiento (RIA/AI Act + RGPD).
Este artículo es una guía práctica para licitar con garantías y evitar el típico problema: comprar una solución “bonita” por fuera y opaca por dentro.
Para quién es: áreas de turismo, contratación, transformación digital y proveedores que quieran hacer las cosas bien desde el minuto 1.
1) Qué es la RIA (AI Act) y por qué te afecta como destino
La RIA (Reglamento de IA / AI Act) es el marco europeo que regula el uso de IA en la UE. Te afecta aunque el modelo sea de un tercero, porque tú eres quien lo pone delante del ciudadano (y eso trae responsabilidades). La referencia oficial está en Comisión Europea.
Traducción útil para un destino:
Si tu asistente se equivoca, inventa info o trata datos personales sin control, el problema no se queda en “un bug”: puede convertirse en incidente, reclamación y crisis reputacional.
2) Fechas clave para no ir tarde
Sin marearte con el BOE/DOUE: hay hitos que marcan el ritmo de los proyectos.
- 01/08/2024: entrada en vigor del AI Act.
- 02/02/2025: aplican obligaciones como prácticas prohibidas y alfabetización en IA.
- 02/08/2025: obligaciones para modelos de propósito general (GPAI).
- 02/08/2026: aplicabilidad general del reglamento (con excepciones concretas).
Consejo de licitación: si licitas en 2026, el proyecto debe nacer con evidencias (logs, control de fuentes, roles RGPD, etc.), no como “ya lo mejoraremos”.
3) Lo que más te toca en un chatbot: transparencia (Artículo 50)
Para un asistente de cara al público, el mínimo que deberías exigir está muy conectado con el Artículo 50 (transparencia). En España, una referencia muy práctica es AESIA.
En la práctica, exige esto:
- Aviso claro: “Estás hablando con un sistema de IA”.
- No suplantación: que no “finja ser humano”.
- Transparencia cuando se genere contenido sintético (cuando aplique).
✅ Regla de oro: si el requisito no se puede comprobar, no sirve. Pásalo a “verificable”: dónde aparece el aviso, en qué canales, con qué persistencia, etc.
4) RGPD: el riesgo silencioso (porque turismo “captura datos” sin querer)
Un chat turístico puede acabar guardando: nombre, email, teléfono, ubicaciones, hábitos, reservas, preferencias… aunque tú no lo pidas.
Por eso el RGPD aquí no es “un apartado legal”: es diseño del sistema. Hay orientación útil desde European Data Protection Supervisor y European Data Protection Board sobre IA generativa y protección de datos.
Qué tienes que dejar atado en el pliego:
- roles (responsable/encargado), subencargados y ubicaciones
- minimización + retención configurable
- borrado verificable
- “no entrenamiento por defecto” con tus datos/conversaciones (salvo instrucción explícita)
- transferencias internacionales declaradas (si existen)
5) El error típico: “una pasarela a un LLM y listo”
El problema no es usar un LLM externo. El problema es no poder contestar (con evidencias) a esto:
- ¿Con qué fuentes oficiales responde?
- ¿Qué hace cuando no sabe?
- ¿Cómo audito por qué dijo X?
- ¿Qué guarda y cuánto?
- ¿Cómo borro y lo demuestro?
- ¿Puedo cambiar de proveedor sin perderlo todo?
Si no puedes responder, has comprado una caja negra.
6) Checklist de pliego (práctico y accionable)
| Bloque | Qué pedir | Señal de alarma |
|---|---|---|
| Arquitectura | diagrama + componentes + terceros + dónde se procesa | “no aplica / es interno” |
| Fuentes (RAG) | fuentes oficiales del destino + versionado + respuesta segura | “el modelo ya sabe” |
| Trazabilidad | logs exportables (pregunta, respuesta, fuente, versión reglas) | “solo analíticas” |
| RGPD | encargo, no entrenamiento por defecto, borrado verificable, retención | “cumplimos RGPD” sin detalle |
| Seguridad | cifrado, accesos, incidentes, SLA | “seguridad estándar” |
| Transparencia AI Act | aviso IA y reglas visibles en todos los canales | “lo ponemos si hace falta” |
| Accesibilidad | lectura fácil, multidioma real, UX accesible | “lo traduce automático” |
| Reversibilidad | exportación conocimiento + config + soporte salida | “no garantizamos” |
7) Las 12 preguntas que separan “proveedor serio” de “humo”
- ¿Qué modelo(s) usa y dónde se procesa cada dato?
- ¿Qué terceros/subencargados intervienen y con qué rol?
- ¿Qué se guarda del chat y cuánto tiempo? ¿Se puede configurar?
- ¿Se usan datos para entrenar? (respuesta esperada: no por defecto)
- ¿Cómo funciona el RAG y qué fuentes oficiales usa? ¿Cómo se versionan?
- ¿Qué hace cuando no hay evidencia? (“respuesta segura”)
- ¿Puedo auditar una respuesta concreta (log + fuente + versión de reglas)?
- ¿Cómo gestionáis derechos RGPD y borrado verificable?
- ¿Hay transferencias internacionales? ¿Qué garantías aplican?
- ¿Qué medidas de seguridad aplicáis (cifrado, accesos, incidentes)?
- ¿Cómo cumplís transparencia (aviso IA, no suplantación, etc.)?
- ¿Cómo salgo del servicio sin perder conocimiento/configuración?
8) Bloques para preparar tu pliego
8.1 Transparencia (RIA / AI Act)
El sistema deberá informar de forma visible y comprensible de que el usuario interactúa con un sistema de IA en todos los canales contratados. Dicho aviso deberá ser persistente o fácilmente accesible durante la interacción y verificable mediante evidencia funcional.
8.2 Fuentes oficiales (RAG) + respuesta segura
El adjudicatario deberá implementar un mecanismo de respuesta basada en fuentes oficiales del destino (p. ej., recuperación de información / RAG), con inventario de fuentes autorizadas, versionado y trazabilidad. En ausencia de evidencia, el sistema deberá emitir respuesta segura, evitando la invención de información, y derivar al canal oficial correspondiente.
8.3 Trazabilidad auditable
El sistema deberá registrar y permitir exportar, bajo demanda, evidencias de interacción: fecha/hora, canal, idioma, consulta, respuesta, fuente utilizada (si procede), y versión de políticas/guardrails/prompting aplicadas, con retención configurable.
8.4 RGPD “sin sorpresas”
Queda prohibido el uso de datos, conversaciones o contenidos del destino para entrenamiento o mejora de modelos por parte del adjudicatario o terceros, salvo instrucción expresa y documentada. Se exigirá borrado verificable, retención configurable, y detalle de subencargados y ubicaciones de tratamiento.
8.5 Accesibilidad e inclusión (para turismo real)
La solución deberá ser accesible e inclusiva: lenguaje claro, soporte multidioma real, y experiencia usable para diferentes perfiles (incluyendo personas con dificultades de lectura o interacción), aplicando buenas prácticas de accesibilidad en los canales contratados.
8.6 Reversibilidad
La solución deberá garantizar reversibilidad al fin del contrato: exportación de base de conocimiento, configuraciones relevantes (intents, flujos, prompts/guardrails) y soporte de transición.
Que el usuario sepa que habla con un sistema de IA y que exista transparencia en el uso del sistema (especialmente por Art. 50), además de cumplir el resto de obligaciones aplicables según el caso.
El AI Act entró en vigor el 1 de agosto de 2024 y será plenamente aplicable el 2 de agosto de 2026, con hitos intermedios (2 feb 2025 y 2 ago 2025).
Es el artículo que fija obligaciones de transparencia para ciertos sistemas (incluidos generativos e interactivos): aviso al usuario y medidas relacionadas con contenido sintético, entre otras.
No “por ley” en todos los casos, pero en la práctica el RAG es una de las mejores formas de reducir alucinaciones, responder con fuentes oficiales y facilitar auditoría y trazabilidad (lo que te ayuda a cumplir y a defenderte). (Esto es una recomendación técnica, no una obligación literal.)
Email, teléfono, nombre, ubicaciones, preferencias, detalles de viaje o reservas… incluso cuando el usuario lo cuenta en lenguaje natural. Por eso hay que diseñar minimización, retención y borrado desde el inicio.
Sí, pero solo si el pliego exige control: arquitectura clara, subencargados identificados, trazabilidad auditable, reglas de datos (no entrenamiento por defecto) y transparencia al usuario.
Diagrama + lista de terceros, logs exportables, fuentes (RAG), políticas/guardrails versionadas, retención configurable y reversibilidad para cambiar de proveedor.
