AI for Smart Cities
Smart city programmes fail on governance and integration far more often than on technology, and the surveillance question is the one that ends them politically.
Smart city programmes have a recognisable failure pattern: a pilot that works, a platform nobody owns, and sensors that stop being maintained the year after the funding ends. The technology is rarely the reason.
AI for smart cities covers traffic and mobility optimisation, environmental and air quality sensing, city asset and highway condition assessment, service demand analysis, energy and building performance across the municipal estate, and the governance and prohibition analysis required for anything operating in public space.
Where the evidence is strongest
City-scale applications divide sharply into those with real operational evidence and those that exist mainly in programme brochures. The distinction is usually whether anything acts on the output.
- Traffic signal optimisation is genuinely proven. Adaptive control against real demand improves flow measurably, and the method predates the current AI vocabulary.
- Environmental sensing works and needs calibration discipline. Low-cost air quality sensors drift, and an uncalibrated network produces confident numbers that are wrong in ways that matter politically.
- Asset condition from vehicle-mounted imagery is mature. Road surface, signage, lighting and street furniture condition at city scale, repeatably.
- Mobility demand analysis informs real decisions. Ticketing, counts and movement data support service planning that people actually use.
- Digital twins deliver where they are scoped narrowly. A model of one network doing one job works; a whole-city twin with no specific decision attached does not.
Ask who operates it in year three
The recurring smart city failure is not a bad pilot, it is an unowned one. A sensor network needs calibration, replacement and a budget line; a platform needs an owner with authority across departments; a model needs someone to retrain it when the city changes. Programmes funded as capital projects with no revenue line for operation produce impressive year-one results and a decommissioning decision in year four. We ask this question at scoping, and it has changed the scope more often than any technical constraint.
Public space, and the line the AI Act draws
Real-time remote biometric identification is prohibited with narrow exceptions
Using AI for real-time remote biometric identification in publicly accessible spaces for law enforcement purposes is prohibited outside specific authorised exceptions, and untargeted scraping of facial images to build recognition databases is prohibited outright. Both have applied since 2 February 2025.
Counting people is not identifying them
Anonymous pedestrian and vehicle counting, queue length estimation and occupancy measurement can be built so that no individual is identifiable at any point — processing on the device and emitting only counts. That design decision is what separates a defensible deployment from a contested one.
Design for the public meeting, not just the legal advice
A camera in public space becomes a political question whether or not it is lawful. Being able to say precisely what is processed, what is retained, what leaves the device and what it can never do is worth more than a compliance memo nobody reads.
Function creep is the thing residents fear, correctly
A network built for traffic counting that later acquires recognition capability is exactly the pattern that erodes public consent. Constrain it technically, not by policy, so the later request is refused by the architecture. See AI risk assessment.
Integration, which is where these programmes actually die
City data sits in transport, highways, waste, planning, housing and environmental systems procured separately over twenty years. The analytical ambition of most smart city programmes assumes an integration that does not exist.
| Layer | Typical state | What is actually needed |
|---|---|---|
| Sensor and device estate | Mixed vendors, mixed protocols | An ingestion layer that tolerates heterogeneity |
| Asset register | Partial and inconsistent between departments | One authoritative register; usually the real first project |
| Service systems | Siloed by department and vendor | Read access and stable identifiers, not full integration |
| Geospatial reference | Frequently good | The join key most cities already have and underuse |
| Ownership | Programme team, time-limited | A permanent owner with cross-department authority |
| Operating budget | Capital only | A revenue line, or the estate degrades on schedule |
The asset register is usually the project underneath the project
Almost every city-scale ambition runs into the fact that no single authoritative register says what assets exist, where they are and what condition they are in. Departments hold overlapping partial versions that disagree. Building that register is unglamorous, it is not what the programme was funded for, and it is the prerequisite for most of what the programme promised. We say so early, because the alternative is discovering it in month six.
How an engagement runs
Ownership and integration assessed first, because both outlast the technology.
Scope, ownership and prohibition analysis
Who owns this in year three, what the integration reality is, and whether anything approaches a prohibited practice.
Data and estate assessment
Sensor calibration state, asset register quality, and which systems can actually be read.
Build
Traffic and mobility analysis, environmental sensing with calibration discipline, or asset condition at scale.
Trial
On a defined corridor or district, with operational outcomes measured rather than dashboard adoption.
Operation
Calibration maintained, models retrained as the city changes, ownership held.
What you receive
City systems that still work in year three.
Traffic and mobility analysis
Adaptive signal and flow optimisation against real demand, measured on journey time.
Environmental sensing
With calibration discipline built in, so the numbers survive scrutiny.
City asset condition
From vehicle-mounted imagery, repeatably, across the whole network.
Authoritative asset register
The consolidated register most city ambitions turn out to require.
Privacy-preserving counting
Occupancy and flow with processing on the device and no individual identifiable.
Ownership and operating model
Who runs it, on what budget, with what authority — documented before build.
Is this the right starting point?
Worth being direct. There are situations in smart cities where custom AI work is the wrong spend, and those are listed rather than buried.
Worth doing if
- Traffic and mobility data exists and signal timing is set on historical assumptions.
- Sensor networks have been deployed and calibration is unmanaged.
- Asset records disagree between departments and nobody holds an authoritative version.
- A previous smart city pilot succeeded technically and was never operationalised.
- You need a defensible position on what a public space deployment can and cannot do.
Do something else if
- The proposal involves biometric identification in public space for law enforcement.
- There is capital funding and no revenue line for operating what gets built.
- No department will own the system after the programme team disbands.
- Integration is assumed to exist and no assessment is permitted before the build.
Frequently asked questions
Marked up with FAQPage schema so these answers can surface directly in search results and inside AI assistant responses.
Why do smart city programmes keep failing?
Ownership and operating budget, far more often than technology. The recurring pattern is a pilot that works, a platform nobody owns across departments, and a sensor estate with no calibration or replacement budget — funded as a capital project with no revenue line. That produces strong year-one results and a decommissioning decision around year four. We ask who operates this in year three at scoping, and the answer has reshaped more programmes than any technical constraint we have raised.
Can we use cameras in public space?
For counting and flow, yes, if it is designed so no individual is ever identifiable — processing on the device, emitting only counts, with nothing retained that could identify anyone. For real-time remote biometric identification for law enforcement purposes, the AI Act prohibits it outside narrow authorised exceptions, and untargeted scraping of facial images is prohibited outright, both since February 2025. The design point that matters politically is function creep: constrain the capability in the architecture rather than in a policy, so a later request for recognition is refused by the system rather than by a committee.
Is a digital twin worth building?
Narrowly scoped, frequently yes. A model of one network making one class of decision — drainage capacity, signal timing, a utility network — earns its place because something acts on the output. A whole-city twin with no specific decision attached becomes a visualisation with a maintenance burden, impressive in a presentation and unused in operations. The test we apply is which recurring decision this changes, and if the answer is a list of possibilities rather than one decision, the scope is wrong.
Our air quality sensors give strange readings. Is that a model problem?
Almost certainly a calibration problem. Low-cost air quality sensors drift, and an uncalibrated network produces confident numbers that are wrong — which in this domain is politically dangerous, because air quality figures get quoted in council chambers and press coverage. Calibration against reference instruments, drift correction and a maintenance schedule are what make the network trustworthy. It is unglamorous infrastructure work and it determines whether any analysis built on top of it is worth anything.
What should we do before any of this?
Build one authoritative asset register. Nearly every city-scale ambition runs into the fact that no single register says what exists, where it is and what condition it is in, with departments holding overlapping versions that disagree. It is not what the programme was funded for and it is the prerequisite for most of what the programme promised. Cities that do this first find the subsequent projects unexpectedly straightforward; cities that skip it find them unexpectedly impossible.
Related verticals
Organisations in smart cities usually share data, buyers or regulators with these. All fourteen are listed on the Public Sector & Education page.
AI for State and Local Government
Service request triage, planning and licensing, and asset condition — with a clear line around social care prediction.
Read more →AI for Public Safety and Policing
Evidence review, call handling and resource forecasting — with the prohibitions and our own refusals stated plainly.
Read more →AI for Federal and National Government
Case extraction, backlog triage and enquiry handling — built to the impact assessment and appeal standard from the start.
Read more →Tell us what the problem looks like.
Thirty minutes, no charge, no deck. We will tell you whether this is an AI problem, a data problem, or a process problem — and we will say when the honest answer is to buy something rather than build it.