Los datos abiertos no son lo bastante abiertos: las barreras invisibles del civic tech
Los datos abiertos suenan revolucionarios. En la práctica, son un campo de batalla de incoherencias, carencias y abandono silencioso, y quienes desarrollan tecnología cívica son los que pagan el precio.
Cuando empecé a construir H-Park, una PWA gratuita basada en datos abiertos que cartografía las plazas de aparcamiento accesibles en toda Europa, esperaba que la parte difícil fuera la tecnología. El cálculo de rutas, la geolocalización, la arquitectura offline-first, las limitaciones de las aplicaciones web progresivas. Lo de siempre.
Me equivocaba.
La tecnología fue la parte fácil. La parte difícil fueron los propios datos.
La promesa de los datos abiertos
Los datos abiertos suenan revolucionarios. Gobiernos, ayuntamientos e instituciones públicas que publican conjuntos de datos gratis, con licencias permisivas, accesibles para cualquiera. La comunidad del civic tech lleva más de una década celebrando este cambio, y con razón: representa un auténtico salto filosófico, la idea de que la información pública pertenece a los ciudadanos y no a las burocracias.
La Directiva europea de datos abiertos, los innumerables portales nacionales de datos, las iniciativas de ciudad inteligente: todo apunta en la misma dirección. Transparencia, accesibilidad, reutilización. Un círculo virtuoso en el que desarrolladores y organizaciones cívicas construyen servicios sobre la información pública y crean un valor que los gobiernos por sí solos nunca podrían producir.
En teoría, es una de las ideas más convincentes de nuestro tiempo.
En la práctica, es un campo de batalla de incoherencias, carencias y abandono silencioso.
Qué significa realmente «abierto» en 2026
La primera vez que busqué datos de aparcamientos accesibles para una ciudad europea, los encontré en siete formatos distintos repartidos en tres portales diferentes, con cuatro sistemas de coordenadas, dos de ellos obsoletos. Un conjunto de datos no se actualizaba desde 2019. Otro era técnicamente abierto, pero exigía registrarse y obtener la aprobación de una oficina municipal. Un tercero era abierto, reciente y estaba bien formateado, pero solo cubría un distrito de una ciudad de 300.000 habitantes.
No es un caso aislado. Es la norma.
«Abierto», en los datos cívicos, a menudo significa: existe en algún sitio, en algún formato, con alguna licencia, actualizado con una frecuencia desconocida y con un nivel de exactitud del que nadie responde oficialmente.
Eso es algo muy distinto de abierto.
Las cuatro barreras invisibles
1. La fragmentación de formatos
Los datos de aparcamientos accesibles, por quedarme en el ámbito que mejor conozco, existen en GeoJSON, Shapefile, CSV con columnas de latitud y longitud, XML, API municipales a medida y, a veces, como una tabla en PDF incrustada en un acuerdo del pleno municipal. No es broma.
Cada elección de formato refleja una herramienta distinta, una época distinta, un proceso interno distinto. Nadie estandarizó nada porque nadie hablaba con nadie. El resultado es que un desarrollador que quiere agregar datos de diez ciudades de tres países se enfrenta a diez procesos de importación distintos antes de escribir una sola línea de la lógica de la aplicación.
OpenStreetMap sigue siendo, irónicamente, una de las fuentes más fiables para este tipo de datos, no porque las instituciones contribuyan de forma sistemática, sino porque lo hacen los voluntarios. La infraestructura cívica que debía resolver este problema ha sido superada, en muchos casos, por una wiki comunitaria.
2. La incoherencia temporal
Los datos envejecen. Una plaza de aparcamiento que existía en 2021 puede haberse convertido en un carril bici, en una obra o simplemente haber desaparecido. Los conjuntos de datos abiertos rara vez indican con claridad cada cuánto se actualizan y, cuando lo hacen, esa frecuencia es más una aspiración que una obligación.
Para un proyecto como H-Park, los datos desactualizados no son una pequeña molestia: son activamente dañinos. Una persona con discapacidad que confía en nuestro mapa para planificar un trayecto y llega a una plaza que ya no existe no sufre una pequeña molestia. Puede arruinarle el día. Su confianza en la tecnología de apoyo, ya frágil, recibe otro golpe.
Ese es el coste humano concreto del abandono de los datos, invisible cuando se mira un conjunto de datos desde la perspectiva de las políticas públicas.
3. La ambigüedad de las licencias
Me he encontrado con conjuntos de datos etiquetados como «abiertos» que, al leer el documento de licencia, exigían la atribución en un formato concreto, prohibían el uso comercial, prohibían las obras derivadas o, en un caso memorable, exigían que cualquier aplicación construida con esos datos se enviara para su revisión a la institución de origen antes de publicarse.
La comunidad de desarrolladores da por hecho que «datos abiertos» significa algo parecido a CC0 u ODbL. A menudo no es así. Y el texto de la licencia suele estar escondido, mal redactado o en contradicción con lo que afirma la portada del portal.
Esto crea un riesgo legal real para cualquiera que construya algo serio. Y produce un efecto disuasorio silencioso: los desarrolladores cívicos empiezan a ignorar los conjuntos de datos oficiales y a recurrir a fuentes mantenidas por la comunidad precisamente porque estas suelen tener licencias más claras y permisivas.
Las instituciones acaban siendo esquivadas por los mismos desarrolladores a los que pretendían dar poder.
4. El vacío de responsabilidad
Cuando una API comercial devuelve datos erróneos, hay un canal de soporte. Hay acuerdos de nivel de servicio. Hay alguien a quien contactar. Cuando los datos abiertos oficiales son erróneos, hay un formulario de contacto en la web municipal que puede que alguien revise o puede que no, y un tiempo de respuesta que se mide en semanas o meses, si es que llega una respuesta.
En la mayoría de las iniciativas de datos abiertos no existe una estructura de responsabilidad sobre la calidad de los datos. Los datos se publican, la obligación se da por cumplida y lo que ocurre después no se sigue. Si los datos se usan, si son exactos, si causan daños: nada de esto vuelve al proceso.
No es una crítica a las personas que publican los datos. Muchas trabajan duro con recursos limitados. Es un problema estructural: la publicación de datos abiertos se ha tratado como una métrica de producción y no como una métrica de servicio.
La decisión silenciosa de quien desarrolla civic tech
Todo desarrollador que trabaja en civic tech acaba enfrentándose a una versión de la misma decisión: ¿construyo sobre los datos oficiales y heredo sus problemas, o los esquivo y uso fuentes comunitarias?
La mayoría los esquivamos. Usamos OpenStreetMap. Recogemos nuestras propias correcciones con la ayuda de los usuarios. Construimos sistemas de contribución ligeros para que puedan señalar la información desactualizada. En la práctica, nos convertimos en una infraestructura de datos paralela que funciona junto a la oficial: a veces más exacta, siempre más ágil.
Es un desperdicio de esfuerzo extraordinario. No porque los datos comunitarios sean malos, a menudo son excelentes, sino porque son los sistemas oficiales los que deberían hacer este trabajo, y no lo hacen. Cada hora que dedico a construir un flujo de correcciones colaborativas para H-Park es una hora que no dedico a la experiencia de usuario. Cada solución provisional es un impuesto sobre el tiempo del desarrollador que, al final, reduce lo que recibe el usuario.
Cómo es lo que funciona
No quiero limitarme a criticar. Hay cosas que funcionan bien y merece la pena nombrarlas.
Overpass API sobre OpenStreetMap es realmente excelente: flexible, rápida y basada en un modelo de datos pensado para la reutilización desde el principio. La comunidad de Linked Open Data ha producido una infraestructura realmente utilizable, aunque su adopción siga siendo limitada. Dinamarca y los Países Bajos han invertido en serio en datos geoespaciales estandarizados, con frecuencias de actualización reales y API pensadas para los desarrolladores. Son la prueba de que es posible.
La diferencia es siempre la misma: las organizaciones que tratan la publicación de datos como un producto, con usuarios, ciclos de retroalimentación y estándares de calidad, producen datos utilizables. Las que la tratan como un teatro del cumplimiento producen conjuntos de datos que quedan bien en una nota de prensa y fallan en producción.
La trampa de la regulación
El Reglamento europeo de Gobernanza de Datos y el marco normativo más amplio sobre datos abiertos tienen buenas intenciones, pero corren el riesgo de caer en la misma trampa: obligar a publicar sin obligar a la calidad.
Se puede exigir a todos los ayuntamientos que publiquen sus datos de aparcamientos accesibles. Si no se exige un esquema mínimo, un límite máximo de antigüedad, un proceso de validación y un mecanismo de respuesta ante los errores, se obtendrán miles de conjuntos de datos técnicamente conformes pero inútiles en la práctica. Cumplir sin servir para nada es burocracia, no progreso.
El siguiente paso de las políticas de datos abiertos tiene que pasar de qué se debe publicar a cómo debe comportarse. Datos como servicio, no datos como documento.
H-Park existe porque los datos de aparcamientos accesibles deberían ser fáciles de encontrar y fiables. No lo son. Así que construimos algo.
Pero soy consciente de que lo que hemos construido es, en parte, un monumento al fracaso institucional. Cada corrección colaborativa, cada importación manual de datos, cada script de conversión de formatos de nuestro proceso representa un vacío que los sistemas oficiales deberían haber cubierto.
La comunidad del civic tech es extraordinariamente ingeniosa. Sorteamos los problemas con elegancia y creatividad. Pero el ingenio no sustituye a la infraestructura. Y la infraestructura no es algo que los voluntarios deban construir en su tiempo libre mientras los gobiernos publican tablas en PDF y lo llaman datos abiertos.
Los datos abiertos debían democratizar la participación ciudadana. En cambio, con demasiada frecuencia han creado un sistema de dos niveles: las instituciones que publican y los desarrolladores que compensan lo que las instituciones hicieron mal.
Merecemos mejores datos. Y las personas que dependen de lo que construimos merecen algo mejor que soluciones provisionales.