Reglamento de IA: cómo revisar el asistente virtual de un destino turístico

Para revisar el asistente virtual de un destino turístico con el Reglamento Europeo de Inteligencia Artificial (RIA), también conocido como AI Act o Ley de IA, hay que hacerlo en cuatro pasos: describir por escrito el uso real del asistente, comprobar las obligaciones que de verdad le aplican, pedir al proveedor que acredite lo que hace con los datos y ordenar la evidencia en un plan con fechas y responsables. Que el asistente se limite a informar lo deja, en principio, fuera de los usos de alto riesgo; aun así, el destino necesita una nota escrita que lo justifique, y la transparencia y la alfabetización del equipo le afectan igualmente.

En este artículo explicamos cada paso, qué documento o prueba sirve de evidencia en cada uno y cómo repartir el trabajo en 90 días. Es orientación práctica para el técnico de turismo: no certifica el cumplimiento ni es un dictamen jurídico, y la revisión del DPD y de la asesoría jurídica del destino sigue haciendo falta.

Equipo iUrban · Publicado el 26 de octubre de 2026 · Fechas de aplicación contrastadas el 26 de octubre de 2026

En este artículo:

• Qué exige el Reglamento de IA y tabla de fechas
• Paso 1: describir el uso real del asistente
• Paso 2: comprobar las obligaciones que sí le aplican
• Paso 3: qué pedir al proveedor sobre los datos
• Paso 4: ordenar la evidencia en 90 días
• Fuentes

¿Qué exige el Reglamento de IA al ayuntamiento que usa un asistente virtual?

Si el asistente solo informa, en principio no es de alto riesgo, pero no queda fuera del RIA: le afectan las prácticas prohibidas, la alfabetización en IA del equipo y la transparencia, empezando por el aviso de que se habla con una IA. Unas obligaciones recaen en el proveedor, otras en el ayuntamiento como responsable del despliegue y otras en los dos, y para cada una conviene guardar una evidencia distinta. Vale igual para una diputación, una mancomunidad o un ente de turismo que ponga el asistente al servicio de sus visitantes. La tabla lo resume con las fechas que recogen el texto consolidado del RIA y el AI Act Service Desk de la Comisión Europea.

Obligación	Quién responde	Desde cuándo	Qué evidencia guardar
Prácticas prohibidas (art. 5)	Proveedor y responsable del despliegue	Aplicable desde el 2 de febrero de 2025; exigible por las autoridades desde el 2 de agosto de 2026. Las dos prohibiciones nuevas (material íntimo no consentido y abuso sexual infantil), desde el 2 de diciembre de 2026	Constancia escrita de la revisión de funcionalidades con el proveedor
Alfabetización en IA (art. 4, modificado en 2026)	Proveedor y responsable del despliegue	Aplicable desde el 2 de febrero de 2025 (art. 113)	Plan de apoyo con sesiones y materiales adaptados
Aviso de que se habla con una IA (art. 50.1 y 50.5)	Proveedor (el destino guarda la prueba)	2 de agosto de 2026	Captura del aviso en cada canal y prueba con lector de pantalla
Marcado de contenido sintético (art. 50.2)	Proveedor	2 de agosto de 2026 (los sistemas ya en el mercado, hasta el 2 de diciembre de 2026)	Respuesta del proveedor con la fecha de puesta en el mercado
Textos de interés público generados con IA (art. 50.4)	Responsable del despliegue	2 de agosto de 2026	Revisión humana con responsabilidad editorial documentada
Obligaciones de alto riesgo (anexo III)	Proveedor y responsable del despliegue, solo si el uso es de alto riesgo	2 de diciembre de 2027	Nota de finalidad cotejada con el art. 6 y el anexo III

Qué regula el Reglamento de IA y a quién se dirige cada obligación

El Reglamento (UE) 2024/1689, conocido como RIA, ordena las obligaciones de un asistente como este según el riesgo de su uso, no según la tecnología que lleva dentro; los modelos de IA de uso general tienen un régimen aparte, que queda fuera de este artículo. Según el texto consolidado que publica EUR-Lex, vigente desde el 27 de julio de 2026, las obligaciones cambian con dos cosas: para qué se usa el sistema y qué papel tiene cada organización.

Proveedor y responsable del despliegue: quién responde de qué

El artículo 3 distingue, entre otros, dos papeles:

• Proveedor: quien desarrolla el sistema, o lo encarga, y lo pone en el mercado o en servicio con su nombre.
• Responsable del despliegue: quien utiliza el sistema bajo su propia autoridad. Es el papel que suele tener el destino que pone el asistente al servicio de sus visitantes.

Separar los dos papeles es el primer trabajo, porque varias obligaciones recaen en uno y no en el otro. Nuestra recomendación es dejarlo en una ficha sencilla: finalidad del asistente, canales en los que funciona, proveedor, modelo, subproveedores, persona responsable del destino y fecha de puesta en servicio.

¿Desde cuándo se aplica el Reglamento de IA a un asistente virtual?

Una parte ya se aplica: las prácticas prohibidas y la alfabetización del equipo. La transparencia del artículo 50, que incluye el aviso de IA, se aplica desde el 2 de agosto de 2026, y las obligaciones de alto riesgo llegan el 2 de diciembre de 2027 (anexo III) y el 2 de agosto de 2028 (anexo I). Esas tres fechas son las del AI Act Service Desk de la Comisión Europea (revisado el 10/10/2026 y contrastado de nuevo el 26/10/2026); en el alto riesgo hay, además, un régimen transitorio que hay que analizar caso por caso.

El resto de las fechas, con quién responde de cada obligación, está en la tabla de obligaciones y fechas, al principio del artículo.

Paso 1: describir el uso real del asistente

La clasificación depende del uso, así que el punto de partida es escribir qué hace el asistente y qué no hace. Contestar sobre horarios, rutas o eventos es una función; conceder ayudas o reconocer a alguien por su rostro son funciones distintas, y cada una abre su propio análisis.

¿Es de alto riesgo el asistente virtual de una oficina de turismo?

En principio, no, si solo informa: responder sobre horarios, rutas o eventos no figura, por esa función, entre los usos de alto riesgo del artículo 6 y el anexo III. La respuesta cambia si el sistema decide sobre ayudas o el acceso a servicios públicos esenciales, interviene en el empleo o usa biometría: en esos casos hace falta una clasificación especializada y la revisión turística ya no basta.

Para un asistente que solo informa, la evidencia de que no es de alto riesgo es una nota de finalidad cotejada con el artículo 6 y el anexo III, con la lista de funciones que el asistente no realiza. Conviene revisarla cada vez que se amplíen sus funciones.

En paralelo, el RGPD tiene su propia puerta: el artículo 22 protege frente a decisiones automatizadas con efectos jurídicos o similares. En nuestra lectura, que recoge nuestra guía de autoevaluación, las recomendaciones turísticas ordinarias no activan ese supuesto por sí solas, pero el DPD debe revisar la lista de decisiones del asistente.

Descartar las prácticas prohibidas del artículo 5

El artículo 5 prohíbe, entre otras prácticas, la manipulación que cause perjuicio y el aprovechamiento de vulnerabilidades de las personas. En un asistente turístico informativo no es lo esperable, pero la comprobación no admite «no aplica»: se revisan las funcionalidades con el proveedor y se deja constancia escrita. Si apareciera una función prohibida, se desactiva, y esa respuesta no se compensa con ningún otro punto bien resuelto.

Paso 2: comprobar las obligaciones que sí le aplican

Transparencia: que el visitante sepa que habla con una IA

El artículo 50.1 obliga al proveedor a diseñar el sistema para que la persona sepa que está interactuando con una IA, salvo las excepciones que el propio artículo prevé. El artículo 50.5 añade que esa información debe ser clara y distinguible, llegar a más tardar en la primera interacción y cumplir los requisitos de accesibilidad.

Aunque el destinatario normativo sea el proveedor, el aviso lo ve el visitante en el canal oficial del destino. Por eso recomendamos que el técnico tenga:

1. Una captura del aviso en cada canal (web, oficina digital, mensajería), al inicio de la conversación.
2. Una prueba del aviso con teclado y lector de pantalla, dentro de la evaluación de accesibilidad del portal (Real Decreto 1112/2018). Para el resto del recorrido del visitante, explicamos cómo preparar la oficina de turismo para que sea realmente accesible.
3. La respuesta del proveedor sobre el marcado de contenido sintético del artículo 50.2, con la fecha de puesta en el mercado del sistema.

Si el destino publica textos generados con IA para informar sobre asuntos de interés público, el artículo 50.4 recae en el responsable del despliegue. La revisión humana con responsabilidad editorial documentada es una excepción que vale para ese texto, no para imágenes, audio o vídeo que sean ultrafalsificaciones.

Alfabetización del equipo en IA

El artículo 4 vigente, según el AI Act Service Desk, pide medidas de apoyo para el personal que usa y supervisa la IA, adaptadas a su función; no exige garantizar un nivel individual de conocimientos ni un certificado. Para un destino, la evidencia razonable es un plan de apoyo con sesiones y materiales adaptados: casos reales de atención turística, errores frecuentes del asistente y qué hacer con los datos personales que el visitante escribe sin que se le pidan.

Paso 3: qué pedir al proveedor sobre los datos

Muchos destinos piden al proveedor dos cosas: que guarde los datos en la Unión Europea y que se comprometa a no entrenar sus modelos con ellos. Pueden pedirlas, pero la ley no las exige a todos por igual. En nuestra lectura del RGPD y de los criterios de la AEPD, lo que se pide es saber qué ocurre con los datos, quién los trata, con qué garantías y con qué límites, y que eso esté acreditado por contrato y documentación. El destino puede exigir condiciones más estrictas en su contrato, pero eso es una decisión suya, no un mínimo legal igual para todos.

Qué pedir al proveedor	Qué acredita	En qué se apoya
Contrato de encargo y lista de subencargados	Quién trata los datos por cuenta del destino y con qué instrucciones	RGPD art. 28 (AEPD: responsable y encargado)
Mapa de alojamiento, accesos remotos y transferencias fuera del EEE	Dónde están los datos y qué garantía ampara cada transferencia, también en soporte y subproveedores	RGPD arts. 44 a 49
Cláusula sobre el uso de conversaciones para entrenar modelos	Si se reutilizan, para qué y con qué límites, en el proveedor y en todos sus subproveedores	Condición contractual; RGPD según finalidad y papeles
Plazos de conservación y prueba de borrado	Que conversaciones, registros y copias se eliminan cuando toca y que los derechos se atienden en toda la cadena	RGPD art. 5 y arts. 12 a 22
Mapa de datos para el registro de actividades	Que el DPD puede revisar el tratamiento con información real	RGPD arts. 30 y 37
Información para el análisis de riesgo	Que el destino puede decidir, de forma motivada, si necesita una evaluación de impacto	RGPD arts. 24, 25, 32 y 35
Pruebas de seguridad y protocolo de incidentes	Accesos, fugas de datos e instrucciones maliciosas probados antes de producción	RGPD arts. 32 a 34; ENS si aplica

Dos criterios para leer esas respuestas. El primero: no basta con no pedir el nombre al visitante. Las direcciones IP, los registros y los identificadores de soporte también pueden ser datos personales, y el «no aplica» solo vale si el mapa demuestra que no hay ninguno. El segundo: la etiqueta del contrato no decide el papel de cada uno; lo decide el flujo real de los datos, y por eso conviene contrastar la documentación con lo que pasa en el modelo, la analítica, el soporte y el alojamiento.

Si estás en la fase anterior, la de preparar la licitación, hemos explicado qué incluir en el pliego si vas a licitar un asistente con IA. Las mismas preguntas sirven después para comprobar que lo contratado se cumple.

Paso 4: ordenar la evidencia en 90 días

Cada comprobación se responde con una de cuatro opciones: «sí, con evidencia», «no», «sin evidencia» o «no aplica, justificado». La regla que más ordena el trabajo es que una comprobación pendiente de prueba no se cierra cambiando la respuesta, sino aportando la evidencia.

Nuestra recomendación es empezar por las carencias que nuestra guía de autoevaluación marca como prioritarias (clasificación del uso, prácticas prohibidas, aviso de IA, finalidad y base jurídica de los datos, contrato de encargo, transferencias, revisión del DPD y registro de actividades, análisis de riesgo, decisiones automatizadas, conservación y borrado, accesibilidad del recorrido, consultas de emergencia y pruebas de seguridad) y seguir por las que afectan a más personas, canales o tratamientos. Así se decide mejor qué revisar primero y no se dispersa el esfuerzo.

Plazo	Trabajo del destino	Cómo se cierra
Días 1 a 15	Validar el ámbito y las respuestas, reunir las pruebas y asignar las tres primeras carencias a turismo y a las áreas competentes	Mapa de necesidades y alcance aprobado
Días 16 a 45	Corregir las carencias prioritarias, configurar los procesos y documentar las responsabilidades	Pruebas y evidencias de cada corrección
Días 46 a 90	Repetir las pruebas, revisar lo pendiente y adoptar un procedimiento de mantenimiento	Informe del ámbito revisado y fecha de la siguiente evaluación

La ficha por carencia

Cada carencia se registra con los mismos campos, para que cualquiera del equipo pueda seguirla:

1. Identificador y causa: qué control falla o qué evidencia falta, y en qué canal y proceso.
2. Responsable y fecha: quién ejecuta, quién valida desde su competencia y cuándo se cierra.
3. Solución y dependencia: qué hace el destino, qué integración o apoyo experto necesita.
4. Aceptación: la prueba repetible, la evidencia esperada y el resultado tras corregir.

Además del RIA: documentar la calidad de la atención

Las comprobaciones de este apartado no son obligaciones del RIA, sino buenas prácticas de atención turística. Las incluimos porque son las que protegen el protagonismo del canal oficial: si el asistente da un horario caducado, el visitante puede dejar de confiar en la fuente oficial del destino.

• Información verificada: horarios, precios y accesibilidad contrastados con fuentes actualizadas, con un responsable y una frecuencia de revisión por cada dato.
• Correcciones que llegan a todos los canales: un cambio de horario probado desde su origen hasta la web, el asistente y la oficina.
• Derivación a una persona: un canal humano con criterios de escalado y una incidencia resuelta como prueba.
• Consultas de emergencia, salud y seguridad: respuestas aprobadas que remiten a los servicios oficiales.
• Procedencia del contenido: registro de fuentes, titular y permiso de uso de lo que alimenta al asistente.

Para quien quiera situar el tipo de herramienta del que hablamos, explicamos qué es un asistente turístico cognitivo en otro artículo, y en su página contamos cómo funciona el asistente virtual de Cicerone.

Lo que esta revisión no cubre

Una autoevaluación ordena lo que el destino tiene documentado y lo que le falta. No certifica el cumplimiento, no es un dictamen jurídico y no sirve para sistemas de alto riesgo, biometría, decisiones con efectos significativos ni para quien desarrolla modelos de IA de uso general: esos casos requieren una evaluación especializada. Tampoco basta con instalar un programa para acreditar el RIA o el RGPD; lo que acredita es la evidencia de cada comprobación.

Esta revisión mira el RGPD, la accesibilidad y el ENS solo en lo que tocan al asistente. Cada uno tiene su propio alcance y sus propias obligaciones, y conviene revisarlos con las personas que se ocupan de ellos en el destino.

Conclusión

Revisar el asistente virtual de un destino con el Reglamento de IA no empieza por la tecnología, sino por el uso: qué hace, para quién y quién responde. Con el uso descrito, las obligaciones que aplican se acotan (prácticas prohibidas, transparencia, alfabetización y, si hay datos personales, el RGPD), lo que se pide al proveedor se convierte en acreditaciones por contrato y el trabajo cabe en un plan de 90 días con responsables y pruebas de cierre.

Fuentes

Fuentes primarias revisadas el 10 de octubre de 2026; las fechas de aplicación (artículos 4, 5, 50 y 113 y la página «When does enforcement start?» del AI Act Service Desk) se volvieron a contrastar el 26 de octubre de 2026. Revisa el texto vigente antes de sacar conclusiones sobre un caso concreto.

• Reglamento (UE) 2024/1689, texto consolidado vigente desde el 27/07/2026 (EUR-Lex)
• AI Act Service Desk: fechas de exigibilidad (Comisión Europea)
• AI Act Service Desk: definiciones, artículo 3
• AI Act Service Desk: artículo 4
• AI Act Service Desk: prácticas prohibidas, artículo 5
• AI Act Service Desk: clasificación, artículo 6 y anexo III
• AI Act Service Desk: transparencia, artículo 50
• Reglamento (UE) 2016/679, RGPD (EUR-Lex)
• AEPD: responsable y encargado del tratamiento
• AEPD: garantías de las transferencias internacionales
• AEPD: evaluación del riesgo
• AEPD: obligaciones de las Administraciones públicas
• AEPD: decisiones individuales automatizadas
• Real Decreto 1112/2018, accesibilidad de sitios web y aplicaciones del sector público (BOE)
• Esquema Nacional de Seguridad (BOE)