The smart city was sold for fifteen years as a technical solution to political problems: sensors, platforms and dashboards that would optimise traffic, waste, energy and safety. Two decades on, the record lets us separate what works, which is usually unglamorous, from what was mainly a sales operation by the firms selling the equipment.
This guide reviews where the concept came from, which cases worked and which failed, who owns the data a city generates, what specific problems algorithms raise when they decide about people, and what minimum rules any municipal technology deployment should have.
Where the concept came from
The term took off after 2008, when IBM launched its Smarter Planet campaign and several large technology companies found a new market in city governments after the crisis. The proposition was coherent: if a city can be measured in real time, it can be optimised the way a factory is optimised.
Criticism arrived early and precisely. Adam Greenfield argued in Against the Smart City (2013) that the model treated the city as an engineering problem with a single solution, ignoring that almost everything urban is a conflict of interests rather than an efficiency failure. Shannon Mattern has insisted that the dashboard metaphor turns the resident into a user and the council into an operator, removing politics from the frame.
The historical precedent helps. In the 1970s the RAND Corporation applied optimisation models to New York's fire service, and the result was the closure of stations in poor districts of the Bronx and Brooklyn just before they burned. The models were not malicious: they measured what could be measured rather than what mattered.
What has worked and what has not
The boring things have worked. Traffic signal management using real data, arrival information at stops, heatwave and flood warning systems, remote metering of the water network to detect leaks, contactless fares, fill sensors in waste containers and, above all, open data allowing anyone to audit a service. These are cumulative, cheap improvements.
What has not worked is building entire cities from scratch as technology showcases. Songdo in South Korea was built with all its digital infrastructure planned and took years to fill with people; Masdar in Abu Dhabi drastically scaled back its ambitions. And the most instructive case is Sidewalk Toronto, Alphabet's project for the Quayside district, cancelled in 2020 after resident opposition centred on data governance.
The common lesson is that a city's problem is almost never a lack of information. Barcelona put it well during its technological sovereignty period: the question is not what technology can measure, but what problem the city has and whether technology is the cheapest answer.
There is also a pattern in the failures worth naming. The projects that collapsed were the ones that started from a product and looked for a city to install it in, while those that lasted started from a service that was already failing and asked whether data would fix it. Nothing in a dashboard tells a council how to distribute a budget, and the cities that understood this early treated technology as plumbing rather than as strategy.
Who owns a city's data
When a council contracts a bike share, parking or waste collection system, it generates extremely valuable data about how people move and live. The question of who owns that data is settled in the procurement documents, and for years it was settled by omission in the supplier's favour.
The consequences are concrete. If the data belongs to the supplier, the council cannot change company without losing its historical series, cannot cross-reference it with other services and cannot publish it. This is called vendor lock-in, and it is how many cities ended up tied to one platform for decades.
The alternative is proven. From 2016 Barcelona wrote data sovereignty clauses into its contracts, requiring free software, open formats and municipal ownership of the data, and developed Decidim, the participation platform now used by hundreds of institutions. Amsterdam and Helsinki have followed similar paths with their public algorithm registers.
Algorithms that decide about people
When an automated system decides who receives a benefit, where police patrol or which file gets inspected, three well-documented problems appear. The first is training data bias: a model learns from the past, and if police patrolled some districts more, the model will learn there is more crime there and send more patrols, confirming its own prediction.
The second is opacity. Virginia Eubanks documented in Automating Inequality (2018) how automated welfare allocation systems in the United States deny benefits without anyone being able to explain why or to whom you appeal. The third is displaced responsibility: when the system gets it wrong, the official says the program decided and the supplier says it only provides the tool.
Predictive policing cases have accumulated cancellations. Several American cities have banned facial recognition in public space, and the European AI Regulation classifies many of these uses as high risk. The practical rule emerging is simple: the more a decision affects a person's rights, the less automatable it should be, and the more obligatory the explanation.
Platforms: the other urban technology
While the debate was about sensors, platforms changed the city far faster. Short-term tourist letting has removed housing from the residential market in the centres of dozens of cities, and its effect on rents has been measured in several studies. Delivery has filled streets with last-mile vehicles and created a labour market regulation is chasing years behind. Ride hailing has added traffic rather than replacing it, according to several evaluations.
The common feature is that these companies operate by their platform's rules inside a regulated public space, and their scale changes land use without going through any plan. A city can take two years to approve a planning amendment and watch a district transform in six months because a pricing algorithm changed.
The responses that have worked are regulatory and anticipatory: mandatory licences and caps per zone for tourist letting, as in Amsterdam or Barcelona; an obligation to share data with the council as a condition of operating; micrologistics with consolidation centres and cargo bike delivery; and employment recognition for riders, which in Spain arrived by statute in 2021.
Minimum rules for a municipal deployment
There is a set of rules shared by the cities that have handled this best. First, start from the problem and not the technology: write down what you want to solve and how it will be measured before looking at any catalogue. Second, collect the minimum data needed and delete it when it is no longer needed, because data you do not keep cannot leak or be repurposed.
Third, municipal ownership of the data, open formats and interoperability written into the contract. Fourth, a public register of the algorithms in use, with their purpose, their data and their owner, as Amsterdam and Helsinki have done. Fifth, an impact assessment before deployment and independent auditing afterwards, not only by the supplier.
And sixth, a proportionality rule that is frequently forgotten: check whether a cheaper non-technological solution exists. Many problems presented as candidates for sensors are better solved with more staff, a change of timetable or paint on the ground.
Seventh, plan for the exit before the entry: every contract should state how the data is handed back, in what format, and how the service continues if the supplier disappears. A city that cannot describe its exit has not bought a system, it has joined one.
The question that remains
The useful argument is not for or against urban technology, because a contemporary city does not work without it. The argument is about who defines the problem, who keeps the data and who can audit the result. Those three questions separate a public policy from an equipment purchase.
William J. Mitchell anticipated much of this in 1995, and his most useful warning still holds: he treated connectivity as one more urban infrastructure, with its layout and its inequality. The digital divide is not distributed at random, it is distributed by neighbourhood, exactly like drains, and it is therefore a planning matter before it is a computing one.
The final test is reversibility. A badly designed street can be redone; a fifteen-year contract with a proprietary platform cannot. Before any deployment it is worth asking what happens if in five years the supplier raises the price, shuts down or changes hands, and whether the city can keep providing the service without it.
Frequently asked questions
- What is a smart city?
- A city using sensors, data and automated systems to manage its services. The term took off around 2008, driven by large technology firms, and today covers both genuine management improvements and largely commercial operations.
- Why did Sidewalk Toronto fail?
- Alphabet's project for the Quayside district was cancelled in 2020 after years of resident opposition focused on who would own the data generated and under what safeguards. It is the case that best shows data governance decides the project.
- Who owns the data a city generates?
- Whoever the procurement documents say. If left unspecified it usually stays with the supplier, tying the council to that company. Barcelona has written municipal ownership, free software and open format clauses into contracts since 2016.
- What is wrong with predictive policing?
- It learns from the past: if police patrolled certain districts more, the model infers more crime there and sends more patrols, confirming its own prediction. Add to that opacity and the difficulty of appealing against an automated decision.
- What should a council require before buying technology?
- Define the problem and the indicator before looking at catalogues, collect minimal data, require municipal ownership and open formats, publicly register the algorithms, audit independently, and check whether a cheaper non-technological solution exists.
