La ciudad inteligente se vendió durante quince años como una solución técnica a problemas políticos: sensores, plataformas y paneles de control que optimizarían el tráfico, la basura, la energía y la seguridad. Dos décadas después, el balance permite separar lo que funciona, que suele ser poco vistoso, de lo que fue sobre todo una operación comercial de las empresas que vendían el equipamiento.
Esta guía repasa de dónde viene el concepto, qué casos han funcionado y cuáles fracasaron, quién es dueño de los datos que genera una ciudad, qué problemas concretos plantean los algoritmos cuando deciden sobre personas, y qué reglas mínimas debería tener cualquier despliegue tecnológico municipal.
De dónde viene el concepto
El término se popularizó a partir de 2008, cuando IBM lanzó su campaña Smarter Planet y varias grandes tecnológicas encontraron en los ayuntamientos un mercado nuevo tras la crisis. La propuesta era coherente: si una ciudad se puede medir en tiempo real, se puede optimizar como se optimiza una fábrica.
La crítica llegó pronto y fue precisa. Adam Greenfield sostuvo en Against the Smart City (2013) que el modelo trataba la ciudad como un problema de ingeniería con solución única, ignorando que casi todo lo urbano es un conflicto de intereses y no un fallo de eficiencia. Shannon Mattern ha insistido en que la metáfora del panel de control convierte al vecino en usuario y al ayuntamiento en operador, eliminando la política del cuadro.
El precedente histórico ayuda a entenderlo. En los años setenta, la RAND Corporation aplicó modelos de optimización a los servicios de bomberos de Nueva York, y el resultado fue el cierre de parques en barrios pobres del Bronx y Brooklyn justo antes de que ardieran. Los modelos no eran malintencionados: medían lo que se podía medir y no lo que importaba.
Qué ha funcionado y qué no
Ha funcionado lo aburrido. La gestión de semáforos con datos reales, la información de llegada en las paradas, los sistemas de aviso por ola de calor o inundación, la telelectura de la red de agua para detectar fugas, el pago sin contacto en el transporte, los sensores de llenado en contenedores y, sobre todo, los datos abiertos que permiten a cualquiera auditar un servicio. Son mejoras acumulativas y baratas.
No han funcionado las ciudades diseñadas enteras desde cero como escaparate tecnológico. Songdo, en Corea del Sur, se construyó con toda la infraestructura digital prevista y tardó años en llenarse de gente; Masdar, en Abu Dabi, redujo drásticamente sus ambiciones. Y el caso más instructivo es Sidewalk Toronto, el proyecto de Alphabet para el barrio de Quayside, cancelado en 2020 tras una oposición vecinal centrada en la gobernanza de los datos.
La lección común es que el problema de una ciudad casi nunca es la falta de información. Barcelona lo formuló bien durante su etapa de soberanía tecnológica: la pregunta no es qué puede medir la tecnología, sino qué problema tiene la ciudad y si la tecnología es la respuesta más barata.
De quién son los datos de una ciudad
Cuando un ayuntamiento contrata un sistema de bicicletas públicas, de aparcamiento o de recogida de residuos, genera un dato valiosísimo sobre cómo se mueve y vive la gente. La pregunta de quién es propietario de ese dato se decide en el pliego de contratación, y durante años se decidió por omisión a favor del proveedor.
Las consecuencias son concretas. Si los datos son del proveedor, el ayuntamiento no puede cambiar de empresa sin perder su serie histórica, no puede cruzar la información con otros servicios y no puede publicarla. Eso se llama dependencia del proveedor y es el mecanismo por el que muchas ciudades quedaron atadas a una plataforma durante décadas.
La alternativa está probada. Barcelona incorporó a partir de 2016 cláusulas de soberanía de datos en sus contratos, exigiendo software libre, formatos abiertos y titularidad municipal de los datos, y desarrolló Decidim, la plataforma de participación que hoy usan cientos de instituciones. Ámsterdam y Helsinki han seguido caminos parecidos con sus registros públicos de algoritmos.
Algoritmos que deciden sobre personas
Cuando un sistema automático decide quién recibe una ayuda, dónde patrulla la policía o qué expediente se inspecciona, aparecen tres problemas bien documentados. El primero es el sesgo de los datos de entrenamiento: un modelo aprende del pasado, y si la policía patrullaba más unos barrios, el modelo aprenderá que allí hay más delito y mandará más patrullas, confirmando su propia predicción.
El segundo es la opacidad. Virginia Eubanks documentó en Automating Inequality (2018) cómo los sistemas automáticos de asignación de ayudas sociales en Estados Unidos deniegan prestaciones sin que nadie pueda explicar por qué ni ante quién recurrir. El tercero es el desplazamiento de responsabilidad: cuando el sistema se equivoca, el funcionario dice que lo decidió el programa y el proveedor dice que solo aporta la herramienta.
Los casos de vigilancia predictiva han ido acumulando cancelaciones. Varias ciudades estadounidenses han prohibido el reconocimiento facial en espacio público, y el Reglamento europeo de inteligencia artificial clasifica como de alto riesgo buena parte de estos usos. La regla práctica que emerge es sencilla: cuanto más afecte una decisión a los derechos de una persona, menos automatizable debería ser, y más obligatoria debería resultar la explicación.
Plataformas: la otra tecnología urbana
Mientras se discutía sobre sensores, las plataformas cambiaron la ciudad mucho más deprisa. El alquiler turístico de corta duración ha retirado vivienda del mercado residencial en los centros de decenas de ciudades, y su efecto sobre el precio del alquiler está medido en varios estudios. El reparto a domicilio ha llenado las calles de vehículos de última milla y ha creado un mercado laboral que la regulación persigue con años de retraso. El transporte bajo demanda ha añadido tráfico en lugar de sustituirlo, según varias evaluaciones.
El rasgo común es que estas empresas operan con reglas de su plataforma dentro de un espacio público regulado, y que su escala cambia el uso del suelo sin pasar por ningún plan. Una ciudad puede tardar dos años en aprobar una modificación urbanística y ver cómo un barrio se transforma en seis meses porque cambió un algoritmo de precios.
Las respuestas que han funcionado son regulatorias y anticipadas: licencia obligatoria y límite por zona para el alquiler turístico, como en Ámsterdam o Barcelona; obligación de compartir datos con el ayuntamiento como condición para operar; micrologística con centros de consolidación y reparto en cargobici; y reconocimiento laboral de los repartidores, que en España llegó por ley en 2021.
Reglas mínimas para un despliegue municipal
Hay un conjunto de reglas que las ciudades que mejor lo han hecho comparten. Primero, empezar por el problema y no por la tecnología: escribir qué se quiere resolver y cómo se medirá antes de mirar ningún catálogo. Segundo, recoger el mínimo dato necesario y borrarlo cuando deje de serlo, porque el dato que no se guarda no se filtra ni se usa para otra cosa.
Tercero, propiedad municipal de los datos, formatos abiertos e interoperabilidad escritos en el pliego. Cuarto, registro público de los algoritmos que se usan, con su finalidad, sus datos y su responsable, como han hecho Ámsterdam y Helsinki. Quinto, evaluación de impacto antes del despliegue y auditoría independiente después, no solo del proveedor.
Y sexto, una regla de proporcionalidad que se olvida con frecuencia: comprobar si existe una solución no tecnológica más barata. Muchos problemas que se presentan como candidatos a sensorización se resuelven mejor con más personal, con un cambio de horario o con pintura en el suelo.
La pregunta que queda
La discusión útil no es a favor o en contra de la tecnología urbana, porque una ciudad contemporánea no funciona sin ella. La discusión es quién define el problema, quién se queda los datos y quién puede auditar el resultado. Esas tres preguntas separan una política pública de una compra de equipamiento.
William J. Mitchell anticipó en 1995 buena parte de lo que iba a pasar, y su aviso más útil sigue vigente: trató la conectividad como una infraestructura urbana más, con su trazado y su desigualdad. La brecha digital no se reparte al azar, se reparte por barrios, igual que las alcantarillas, y por eso es un asunto de urbanismo antes que de informática.
El criterio final es de reversibilidad. Una calle mal diseñada se puede rehacer; un contrato de quince años con una plataforma propietaria, no. Ante cualquier despliegue conviene preguntar qué pasa si dentro de cinco años el proveedor sube el precio, cierra o cambia de manos, y si la ciudad puede seguir prestando el servicio sin él.
Preguntas frecuentes
- ¿Qué es una smart city?
- Una ciudad que usa sensores, datos y sistemas automáticos para gestionar sus servicios. El término se popularizó hacia 2008 impulsado por las grandes tecnológicas, y hoy se usa tanto para mejoras reales de gestión como para operaciones sobre todo comerciales.
- ¿Por qué fracasó Sidewalk Toronto?
- El proyecto de Alphabet para el barrio de Quayside se canceló en 2020 tras años de oposición vecinal centrada en quién sería dueño de los datos generados y con qué garantías. Es el caso que mejor muestra que la gobernanza de los datos decide el proyecto.
- ¿De quién son los datos que genera una ciudad?
- De quien lo diga el pliego de contratación. Si no se especifica, suelen quedar en manos del proveedor, lo que ata al ayuntamiento a esa empresa. Barcelona incorporó desde 2016 cláusulas de titularidad municipal, software libre y formatos abiertos.
- ¿Qué problema tiene la vigilancia predictiva?
- Que aprende del pasado: si la policía patrullaba más ciertos barrios, el modelo deduce que allí hay más delito y manda más patrullas, confirmando su propia predicción. A eso se suman la opacidad y la dificultad de recurrir una decisión automática.
- ¿Qué debería exigir un ayuntamiento antes de comprar tecnología?
- Definir el problema y el indicador antes de mirar catálogos, recoger el dato mínimo, exigir propiedad municipal y formatos abiertos, registrar públicamente los algoritmos, auditar de forma independiente y comprobar si existe una solución no tecnológica más barata.
