Cities Are Starting to Run Like Systems: The Next Race in Public-Sector Smart Infrastructure

Over the past decade, the public sector’s understanding of “smart infrastructure” has undergone a quiet shift.

It was initially treated as an equipment upgrade checklist: more energy-efficient streetlights, connected water meters, cameras installed at intersections, electricity meters that can be read remotely. These projects are usually driven by a single department, with clear acceptance criteria and well-defined budget cycles. But what truly changed the logic of how cities operate was not these devices themselves, but the fact that they gave cities a continuous state for the first time—an operating state that can be continuously read, coordinated, and preemptively intervened in.

When Rio de Janeiro fed real-time footage and data from multiple departments into the same operations center, when Barcelona sought to connect public facilities to a unified city IoT layer, when Singapore began building a city-level digital twin, these projects were ostensibly technical engineering, but in reality they all answered the same question: Can a city be run like a system?

There is no standard answer to this question. And when it falls into the hands of the public sector, the answer is often not given by technology.

From Periodic Management to Continuous State Awareness

Traditional municipal management has its fixed rhythm. Budgets are organized annually, inspections scheduled weekly, complaints responded to one by one, incidents reconstructed from reports. This rhythm held for so long because the cost of collecting information was too high—cities could only observe themselves by sampling.

What smart infrastructure changes is this time constant. When traffic signals, pipe network pressure, waste collection vehicles, and public building energy consumption all continuously generate data, the city’s “perception” shifts from sampling to continuous. The change is not about seeing clearly something previously invisible, but about the decision-making clock being sped up.

This is also why many cities first deploy adaptive traffic signal systems, rather than more dazzling city dashboards. Los Angeles’s transportation department has invested continuously in adaptive signal control for years, with a very pragmatic logic: intersection congestion is a problem that can be observed at the second level and intervened in at the second level. It does not require redefining the city, only making the existing management chain run faster.

The same logic is recurring in water, energy, and public safety. Leak detection has shifted from “investigating after receiving a complaint” to “alerting when pressure is abnormal”; streetlights have shifted from “switching on and off by time” to “adjusting by foot traffic.” None of these are grand narratives, but cumulatively they change the default response time of municipal response.

Data Is Not a Byproduct, but a New Public Asset

Toronto’s Quayside project is an unavoidable precedent. Sidewalk Labs once partnered with Waterfront Toronto, planning to build a highly sensorized community on the waterfront. The project was ultimately terminated in 2020, and the core of the public controversy was not technical feasibility, but who owns the data, who profits from it, and whether the daily activities of public space can be commercialized.The outcome of this project had a more far-reaching impact than its technical solution. Since then, many cities have added a new clause to smart-city contracts: data ownership, boundaries of use, and exit mechanisms. The focus of negotiations shifted from “what can you provide” to “what do I retain.”

This shift points in the same direction as the experience of national-level data infrastructure. Estonia’s X-Road has been studied repeatedly not because it is technically complex, but because it turned cross-institutional data exchange into a rule-bound foundational layer: who can query, why they query, and when an audit trail is left. India’s public digital layer built around digital identity and payments is also grappling with the same proposition—when infrastructure is made public, access rights and governance rights must be defined at the same time.

More and more policy discussions are beginning to use the term “digital public infrastructure” to describe such systems. Its implication is that a city’s digital layer is not some vendor’s product, but something that must be designed and maintained as a public good.

The Allure of Platformization, and the Cost of Lock-In

“City operating system” is a powerful metaphor: unifying scattered departmental systems onto a single platform, and using one data foundation to support all applications. It does solve the problems of duplicated development and chaotic interfaces, but it also creates a new risk—binding cross-departmental capabilities to a single vendor’s roadmap.

Thus, technical questions become institutional ones: whether interfaces are open, whether standards are portable, and how high the exit costs are.

The procurement choices of some local governments in Europe can be understood in this context. The German state of Schleswig-Holstein decided to push ahead with migrating administrative office endpoints to open-source software, while Munich wavered for years between open-source and commercial software. The motives behind these decisions were rarely purely cost or performance; more often they were a reassessment of dependencies: who controls the pace of updates, who sets feature priorities, and who can leave with the data when the contract expires.

For the public sector, procurement is never just buying something; it is choosing a long-term relationship. Procurement of intelligent infrastructure stretches the term of that relationship even longer.

Algorithms Enter Governance: Where Does Legitimacy Come From?

When automation begins to intervene in specific decisions—resource allocation, risk ranking, permit review, urban planning simulation—the question is no longer “how accurate is it” but “on what grounds.”

Amsterdam and Helsinki successively established public-facing algorithm or AI registers, seeking to explain where municipal systems use automation, on what basis, and who is responsible. The value of such tools lies not in technical transparency itself but in bringing algorithms into existing structures of public accountability: who approves, who audits, and who can be questioned.

The entry into force of the EU Artificial Intelligence Act further turns this practice from the choice of individual cities into a region-wide compliance environment. For the public sector, one practical consequence is that the rollout speed of intelligent infrastructure may no longer depend on computing power and networks, but on whether it can clearly explain why a system makes a particular decision.This is not the language of technocrats, but the language of governance. And cities must speak both languages at once.

Digital Twins: From “Seeing” to “Rehearsing”

Digital twins are often misunderstood as 3D visualization. Their truly valuable use is to make decisions into objects that can be tested.

One goal of Singapore’s city-level digital twin is to allow planning and emergency scenarios to be repeatedly simulated in a virtual environment: after building density increases in an area, how do the wind environment and heat load change; under an extreme rainfall event, which road sections will accumulate water first. Toronto’s digital twin work in the post-Quayside period also focuses on simulating infrastructure and development scenarios, rather than community surveillance.

The value of such systems lies not in the visuals, but in front-loading the act of “making the call” into an “experiment.” For cities, this is a scarce capability—the real world cannot be redone, but simulations can.

Security Is No Longer an Add-On, but an Infrastructure Attribute

When the control layers of transportation, energy, water, and public services begin to interconnect, the attack surface is no longer a single point. A compromised sensor is inconsequential; a tampered control command may affect physical systems.

The update to the EU’s cybersecurity directive brings more public-sector and critical infrastructure operators into scope, reflecting a broader consensus: in intelligent infrastructure, security is not post-launch hardening work, but a premise of design. What cities need is not only firewalls, but also supply-chain vetting, emergency switchover capabilities, and cross-departmental drills—these belong to urban governance, not IT operations.

The Next Contest Is About Institutional Capacity

If these threads are put together, a relatively clear judgment emerges: in the competition among cities around digital capabilities, the real watershed is not technology choices.

Sensors can be procured, cloud resources can be rented, and models can be called. What is difficult to replicate is: whether departments can share data, whether procurement can identify long-term dependencies, whether finance can shift from one-off capital expenditure to ongoing operating expenditure, and whether a city has enough internal technical capacity to judge the solutions vendors propose.

This also explains why some smart city projects with a lot of early buzz faded into ordinariness a few years later, while other less conspicuous projects keep accumulating value through use. The former often aim at device deployment volume; the latter aim at service continuity.

The intelligence of infrastructure ultimately tests the institutions themselves. Cities do not need more sensors to prove they are getting smarter; they need stronger coordination capacity, clearer boundaries of authority and responsibility, and fiscal models willing to pay for long-term operations.

The real question may not be “can a city be run in real time,” but: when a city can indeed be run in real time, who decides in which direction it runs.

The answer to this question is not in the server room.