~/blog $ cat rgpd-app-municipal.mdx

RGPD en una app municipal: qué datos puedes tratar y qué te va a preguntar el DPD

21 · 08 · 2026 11 min de lectura #ayuntamientos #proteccion-de-datos

Casi todas las apps municipales que se paran antes de salir se paran aquí. No por un problema técnico: porque llega el informe del delegado de protección de datos y nadie sabe contestar de dónde sale la potestad para pedir el teléfono del vecino. Este artículo es la traducción práctica de esa conversación, escrita desde el lado de quien construye apps para ayuntamientos y ha pasado por ella unas cuantas veces.

Va en orden: quién es quién, qué datos entran en juego, con qué amparo, y qué papeles hay que tener encima de la mesa.

Quién es quién: el proveedor no es el dueño de nada

El ayuntamiento es el responsable del tratamiento: es quien decide para qué se tratan los datos y con qué medios esenciales. La empresa que desarrolla y opera la app es encargada del tratamiento y solo puede tratarlos siguiendo instrucciones documentadas. Esto no es un matiz burocrático, tiene tres consecuencias muy concretas:

• Hace falta el contrato de encargo del artículo 28 del RGPD, firmado antes de que el proveedor toque un solo dato real. No vale una cláusula suelta en el presupuesto.
• El proveedor no puede usar los datos para sus propios fines: ni para entrenar nada, ni para estadísticas comerciales, ni para «mejorar el producto» sin más.
• El proveedor no puede subcontratar sin autorización. Y aquí está el punto ciego: el servicio de notificaciones push, el de copias de seguridad, el de errores, el de analítica y el proveedor de infraestructura son subencargados. Todos.

Si el contrato de encargo no lista los subencargados con nombre y país, el registro está incompleto. Es lo primero que mira un DPD con oficio.

Qué datos trata de verdad una app municipal

Mucha gente cree que una app de avisos «no trata datos personales». Trata unos cuantos, y algunos no son evidentes:

La fila que más problemas da es la de incidencias. Es también la más útil de la app —lo contamos en cómo funciona una app de incidencias vecinales— y la que exige más cuidado de diseño.

La base jurídica: por qué el consentimiento suele ser la respuesta equivocada

El reflejo habitual es «pedimos consentimiento y listo». En una administración eso es casi siempre un error, por dos motivos: el consentimiento debe poder retirarse libremente, y un vecino no puede «retirar» el hecho de que el ayuntamiento gestione su cita previa; y en una relación con un poder público la libertad del consentimiento es discutible de partida.

Lo que hay que buscar es amparo en el artículo 6.1.c) —cumplimiento de una obligación legal— o en el artículo 6.1.e) —misión realizada en interés público o ejercicio de poderes públicos—. Y la Ley Orgánica 3/2018 pone una condición que conviene leer despacio:

«Una competencia atribuida por una norma con rango de ley». Para un ayuntamiento, eso normalmente significa señalar la competencia municipal concreta de la Ley reguladora de las Bases del Régimen Local y, cuando exista, la norma sectorial. Traducido a la práctica: cada funcionalidad de la app debe poder apuntar a una competencia municipal. Avisos de cortes de agua, incidencias en la vía pública, agenda cultural, gestión de instalaciones deportivas: todas tienen dónde agarrarse. Un juego con premios patrocinados, no.

Dónde sí hace falta consentimiento

El consentimiento no desaparece, se reubica. Sigue siendo necesario para lo accesorio y para lo que no forma parte del servicio:

• Almacenar o acceder a información en el dispositivo cuando no es imprescindible para prestar el servicio solicitado: analítica no esencial, identificadores publicitarios, herramientas de terceros. Es la regla del artículo 22.2 de la LSSI, y la Agencia Española de Protección de Datos la aplica también a las aplicaciones móviles, no solo a las webs.
• Comunicaciones que no correspondan a una competencia municipal: promociones de terceros, patrocinios, encuestas comerciales.
• Permisos del sistema —ubicación, cámara, notificaciones—, que el propio sistema operativo pide, y que hay que solicitar en el momento en que se usan y no todos de golpe en el primer arranque.

Un apunte que sorprende: el permiso de notificaciones que muestra el móvil no equivale al consentimiento del RGPD ni lo sustituye. Son cosas distintas, y la información del artículo 13 hay que darla igual.

Los cinco documentos que os va a pedir el DPD

1. El registro de actividades de tratamiento, y publicado

El artículo 30 del RGPD obliga a mantener el registro. Y el artículo 31.2 de la LOPDGDD añade algo que muchos ayuntamientos desconocen: los sujetos enumerados en su artículo 77.1 —entre ellos las entidades que integran la Administración Local— deben hacer público un inventario de sus actividades de tratamiento accesible por medios electrónicos.

Es decir: la app no solo tiene que estar en vuestro registro interno, tiene que aparecer en el inventario público. Y si la app añade una funcionalidad nueva —incidencias, cita previa, padrón—, el registro se actualiza. No es un documento que se firma una vez.

2. El contrato de encargo con el proveedor

Con el contenido mínimo del artículo 28.3 del RGPD: objeto, duración, naturaleza y fin del tratamiento, tipo de datos, categorías de interesados, obligaciones y derechos del responsable. Y con tres apartados que conviene revisar uno a uno porque son los que fallan:

• Lista de subencargados, con nombre, servicio y ubicación de los datos. Y el procedimiento para autorizar cambios.
• Ubicación de los datos. Si algún subencargado trata datos fuera del Espacio Económico Europeo, hace falta un mecanismo válido de transferencia internacional. Es el punto donde muchos servicios gratuitos de analítica o de notificaciones se caen del proyecto.
• Qué pasa al terminar: devolución o supresión certificada, con plazo. Enlaza directamente con el plan de salida que recomendamos exigir en qué preguntarle a un proveedor antes de firmar.

3. El análisis de riesgos y, si procede, la evaluación de impacto

El artículo 35 del RGPD exige evaluación de impacto cuando es probable que el tratamiento entrañe un alto riesgo para los derechos y libertades, y la AEPD publica una lista de tipos de tratamiento que la requieren. En una app municipal los indicios que aparecen con más frecuencia son cuatro: geolocalización, captación de imágenes en espacio público, uso a gran escala en relación con la población del municipio y datos de personas en situación de vulnerabilidad.

Una app de avisos y agenda cultural probablemente no la necesite. Una que recoge incidencias con foto y ubicación precisa, o que integra servicios sociales, muy probablemente sí. La decisión la toma el ayuntamiento con su delegado, y el consejo práctico es dejarla documentada aunque la conclusión sea negativa: un folio explicando por qué no hace falta vale más que el silencio.

4. La información al interesado, donde se pueda leer

El artículo 13 del RGPD exige informar en el momento en que se obtienen los datos. En una app, eso significa tres sitios y no uno:

• En la ficha de la tienda, que además obliga a declarar prácticas de datos en App Store y Google Play. Si lo declarado allí no coincide con vuestra política, tenéis un problema doble.
• En el primer arranque y en cada formulario que pida datos, con una capa breve y un enlace a la información completa.
• En la web del ayuntamiento, con la política completa y los datos de contacto del delegado.

Y en un idioma que se entienda. Una política de privacidad copiada de una plantilla de comercio electrónico, con referencias a «clientes» y «pedidos», es una señal de alarma para cualquier DPD.

5. El procedimiento de brechas

Hay que tenerlo escrito antes de necesitarlo. El artículo 33 del RGPD da 72 horas desde que se tiene constancia para notificar a la autoridad de control, salvo que sea improbable que la brecha suponga un riesgo. Si el riesgo para los afectados es alto, el artículo 34 obliga además a comunicárselo a ellos. Y el encargado —vuestro proveedor— debe notificaros a vosotros sin dilación indebida.

Tres horas del reloj se pierden siempre en averiguar a quién hay que llamar. Ponedlo en el contrato: teléfono, correo y persona.

Ocho preguntas para hacerle al proveedor por escrito

Son las que resuelven el informe del DPD sin diez correos de ida y vuelta:

1. ¿En qué país y con qué proveedor de infraestructura se alojan los datos?
2. ¿Qué subencargados intervienen, para qué servicio y dónde están?
3. ¿Qué datos se cifran en tránsito y en reposo, y quién custodia las claves?
4. ¿Qué personas de vuestra empresa tienen acceso a datos de producción, y cómo queda registrado ese acceso?
5. ¿Qué plazos de conservación están configurados por defecto para cada tipo de dato, y qué se borra automáticamente?
6. ¿Cómo se atiende un derecho de acceso, rectificación o supresión: hay panel o hay que pediros una exportación?
7. ¿Qué SDK de terceros lleva la app y qué envía cada uno?
8. ¿Cuál es el procedimiento y el contacto en caso de brecha, y en cuánto tiempo nos avisáis?

Si estáis todavía en fase de pliego, estas preguntas se convierten en requisitos: cómo escribirlos está en cómo redactar el pliego técnico de una app municipal.

Diez decisiones de diseño que ahorran el 80 % del papeleo

Esta es la parte que casi nadie cuenta y la que de verdad marca la diferencia. Cumplir es mucho más barato si la app se diseña sin recoger lo que no hace falta:

• No pedir identidad para lo que no la necesita. Para recibir avisos no hace falta ni nombre ni DNI.
• Zona en vez de coordenadas. Para avisos por barrio basta con que el vecino elija su zona en una lista.
• Geolocalización solo al enviar una incidencia, nunca en segundo plano, y siempre editable antes de enviar.
• Borrar los metadatos EXIF de las fotos al subirlas: llevan ubicación y modelo de dispositivo aunque el usuario no lo sepa.
• Avisar de qué no debe fotografiarse y difuminar caras y matrículas cuando la imagen vaya a verse fuera del back office.
• Plazos de conservación configurados desde el primer día, no «ya lo veremos»: incidencia cerrada, foto que se elimina pasado el plazo acordado.
• Sin identificadores publicitarios ni SDK de terceros. Una app municipal no tiene ninguna razón para llevarlos.
• Notificaciones sin datos personales en el cuerpo: el aviso aparece en la pantalla de bloqueo, a la vista de cualquiera.
• Datos alojados en la Unión Europea, incluidas copias de seguridad y registros.
• Botón de borrar cuenta dentro de la app, que además exigen las tiendas si la app permite crear cuenta.

Ninguna de las diez encarece el desarrollo si se decide al principio. Todas encarecen si se descubren en el informe del DPD tres semanas antes de publicar.

Qué pasa si algo sale mal

Conviene decirlo sin dramatizar y sin restar importancia. El artículo 77 de la LOPDGDD establece un régimen distinto para las entidades que integran la Administración Local: en lugar de imponer una multa administrativa, la autoridad de protección de datos dicta una resolución que declara la infracción y establece las medidas que deben adoptarse para que cese la conducta o se corrijan sus efectos. Además, puede proponer la iniciación de actuaciones disciplinarias cuando existan indicios suficientes, y sus actuaciones se comunican al Defensor del Pueblo o a la institución autonómica equivalente.

Dos matices que cambian la lectura:

• Ese régimen no protege al proveedor. La empresa encargada del tratamiento sí puede ser sancionada económicamente, y por eso a un proveedor serio le interesa tanto o más que a vosotros que esto esté bien.
• La ausencia de multa no elimina el resto: la reclamación del vecino, la publicidad de la resolución y la eventual responsabilidad patrimonial siguen ahí.

Cómo lo planteamos nosotros

Nuestra posición en un proyecto municipal es la de encargados del tratamiento y nada más: los datos son del ayuntamiento, se alojan en la Unión Europea, no se usan para ningún fin propio y se devuelven o se suprimen al terminar. Antes de escribir código pasamos por el delegado de protección de datos el listado de datos que va a tratar cada pantalla; sale más barato discutirlo en un documento que en una aplicación ya construida.

Y si vuestro DPD ya os ha devuelto un informe con objeciones sobre una app en marcha, se puede leer y traducir a cambios concretos. Podéis ver cómo queda todo esto en producción en la app del Ayuntamiento de Benissa.

Preguntas frecuentes