City and Public-Space Surveillance

This is engineering guidance, not legal advice. Confirm specifics with qualified counsel.

Why this matters

If you architect, procure, or build surveillance for a municipality, a transit authority, a port, a stadium district, or a "safe city" programme, this is the largest and highest-stakes system you will ever scope — and the one where a wrong assumption is most expensive, because it is paid for with public money and answered for in public. The city surveillance market was about USD 15.6 billion in 2026 and growing at roughly 8% a year, and the buyers are no longer just police: traffic departments, transit operators, emergency management, and private business owners all feed cameras into shared real-time crime centres. This article is the vendor-neutral reference design for city-scale surveillance — how to federate thousands of cameras across districts, how the storage and bandwidth math actually works at this scale, what the analytics realistically do, and, above all, where the legal lines are drawn around watching the public — so you can architect a system that survives both a citywide incident and a court challenge. It assembles the building blocks from the rest of this course rather than repeating them, and spends its own words on what is unique to the city: scale and privacy at the limit.

The two loads that define a city system

Every reference design in this course leads with the load that defines the use case. For retail it is people-counting accuracy; for a perimeter it is the false-alarm rate; for industrial sites it is uptime in a harsh environment. For a city, two loads define everything, and they pull in opposite directions.

The first load is scale. A city system is not a big building system — it is a different kind of object. You are not managing hundreds of cameras in one building on one network; you are managing thousands or tens of thousands across districts that each have their own network, their own power, and often their own camera vendor bought in a different procurement cycle five years apart. Several US cities now run real-time crime centres that integrate two to three thousand cameras or more, and the largest programmes register or integrate well over ten thousand. At that size, the things that were easy at building scale — adding a camera, searching footage, surviving a network outage — become the whole engineering problem.

The second load is privacy and legal weight. A shop films its own customers on its own premises; a factory films its own yard. A city films everyone, in spaces they have no choice but to walk through, often without a meaningful way to opt out. That is the most heavily regulated activity in all of surveillance, and the law around it has moved fast. A city design that is technically excellent but legally reckless does not get deployed — it gets injuncted, defunded, or switched off after a public outcry. So privacy is not a chapter at the end of the project; it is a constraint on the architecture from the first diagram.

Figure 1. What makes a city different. Retail, perimeter, building, and industrial designs each push one load hard. A city pushes two at once — the largest camera fleets in the field and the heaviest privacy and legal weight — and the architecture has to answer both simultaneously.

Hold both in mind for the rest of this article. Every design choice below is in service of scaling to thousands of cameras and staying inside the law about watching the public.

Why a city is many systems, not one

The first instinct of a newcomer is to imagine one enormous video management system — the software platform that ingests, records, and manages many camera streams, called a VMS — with every camera in the city plugged into it and every operator looking at one map. That design fails at city scale for two concrete reasons, and understanding why is the key to the whole architecture.

The first reason is bandwidth. Video is heavy and constant. Suppose a city runs 5,000 cameras, each producing a modest 2 megabits per second (Mbps) of compressed video — a reasonable average for a 4-megapixel camera using the efficient H.265 codec with a smart bitrate setting. If you tried to send every stream continuously to one central data centre just to record it, the incoming traffic would be:

5,000 cameras × 2 Mbps = 10,000 Mbps = 10 Gbps, sustained, 24/7

Ten gigabits per second, every second of every day, before a single operator has opened a live view. Double the bitrate to a sharper 4 Mbps and it is 20 Gbps. No city funds a private fibre ring of that capacity to a single building just to centralise recording, and even if it did, that building is now a single point of failure for the entire city's video.

The second reason is resilience. A city is not allowed to go blind. If the link from a district to the central data centre is cut by a contractor's digger — which happens — a centralised design loses every camera in that district and any footage that was only stored centrally. For a system whose whole purpose is public safety, a fragile centre is a non-starter.

The solution is federation: instead of one system, you build many small systems — typically one per district, precinct, or site — that each record their own cameras locally, and you place a thin coordination layer on top that lets an authorised operator at the centre search and stream any camera on demand. The video lives at the edge, near the cameras; only the lightweight catalogue of what exists, plus the streams an operator actually opens right now, crosses the wide-area network. We cover this pattern in depth in federation: managing many sites as one; a city is its most demanding application.

Figure 2. The city reference architecture is federated. Each district is a self-contained system that records its own cameras locally and keeps working if the wide-area link drops. A thin federation layer lets the central operations centre search the whole city and pull any stream on demand — so the network carries a few live views and metadata, not 10 Gbps of constant recording.

This single decision — record local, stream on demand — is what turns an impossible 10 Gbps backhaul into a manageable one. Instead of every stream travelling to the centre, only the streams an operator opens travel. If fifty operators across the city each watch one 4 Mbps camera at once, that is 200 Mbps of live viewing, not 10 Gbps of recording. The rest stays in the district where it was captured.

Common mistake: designing a city as one centralized VMS because that is how a single building is designed. It looks simpler on a slide, and it collapses in practice — the backhaul cost is absurd, the central site becomes the city's single point of failure, and the first cut fibre takes a whole district offline. City scale is a federation problem. Build many small, autonomous systems and coordinate them; do not build one giant one.

The storage is a petabyte problem

At city scale, storage stops being a line item and becomes the budget. Let us do the arithmetic out loud, because the number surprises people.

Storage from a video stream is just bitrate multiplied by time. One megabit per second, recorded continuously, produces a predictable amount per day:

1 Mbps = 0.125 megabytes per second
0.125 MB/s × 86,400 seconds per day = 10,800 MB = 10.8 GB per day

So every 1 Mbps of continuous recording is about 10.8 GB per camera per day. Now scale it to our 5,000-camera city at an average 2 Mbps:

Per camera:   2 Mbps × 10.8 GB = 21.6 GB per camera per day
Whole city:   21.6 GB × 5,000 cameras = 108,000 GB = 108 TB per day
30-day keep:  108 TB × 30 days = 3,240 TB ≈ 3.2 PB

Three point two petabytes for a single month of footage — and that is the usable figure. Real storage adds redundancy so a failed disk does not lose video (RAID, typically a 1.4–1.6× overhead) and headroom so the array is never run to the brim, which pushes the raw requirement toward 5 PB. A city that keeps 90 days instead of 30 triples it. This is why, at city scale, three levers matter more than the camera spec:

• Retention length is the biggest multiplier. Keeping footage twice as long costs twice the storage. The right number is set by law and operational need, not by whatever the disks happen to hold — covered in retention policy: how long to keep footage.
• Recording mode changes the bill. Continuous recording captures everything; motion- or event-based recording on lower-priority cameras can cut a camera's footprint substantially. The full storage equation and its levers live in surveillance storage and the retention math.
• Storage tiering moves older footage from fast, expensive disk to slow, cheap archive as it ages, so you are not paying premium prices to hold last week's quiet corridors. See storage tiers: hot, warm, cold, archive.

Figure 3. The two numbers that size a city system. Left: the storage math — 5,000 cameras at 2 Mbps write ~108 TB a day and ~3.2 PB over a 30-day retention, before redundancy. Right: the bandwidth contrast — centralizing every stream needs ~10 Gbps of constant backhaul, while a federated design carries only the few streams an operator opens on demand.

Because storage dominates the cost, capacity planning is not optional at this scale — recording servers are sized by sustained write throughput, not just by camera count, and each resource (storage, network, server, client) hits its own limit at a different point. We work that method through in scaling a VMS: capacity planning, and turn a design into a number in estimating a surveillance project.

The standards spine that holds a multi-vendor city together

A city fleet is never one brand. Cameras arrive over a decade of separate procurements, from different manufacturers, in different districts. The only thing that keeps that from becoming dozens of incompatible silos is a shared standard, and in surveillance that standard is ONVIF — the common language that lets cameras and recording software from different makers understand each other.

ONVIF works through profiles, each covering a slice of functionality: Profile S for live streaming, Profile G for recording and retrieval, Profile T for advanced streaming such as H.265, and Profile M for analytics metadata and events — the channel by which a camera tells the VMS "a vehicle entered this zone." For a city, ONVIF is what lets a new district's cameras join the platform without a custom integration for every model. But remember the limit that runs through this whole course: ONVIF guarantees a baseline both devices agree on, not full feature parity. A camera's most advanced analytics often still need the vendor's own software kit. Keep "works over ONVIF" and "every feature works over ONVIF" separate in your head and in your contracts. The full picture is in ONVIF explained for engineers, and the position-1 commercial overview of ONVIF profiles in security systems is a useful companion.

At the system level, the international standard IEC 62676 sets out the requirements and application guidelines for video surveillance systems, including the pixel-density needed to detect versus identify a person — a useful, vendor-neutral reference when a procurement document needs to specify performance rather than a brand.

What the analytics actually do at city scale

City surveillance is where video analytics earns its keep, because no control room can watch thousands of cameras with human eyes. The realistic jobs fall into a few groups, and the honest framing — the one that keeps you out of trouble — is to separate analytics that describe things and behaviour from analytics that identify a specific person.

Traffic and vehicle analytics are the workhorse. Automatic number-plate recognition (called ANPR in the UK and LPR in the US) reads vehicle plates for traffic management, congestion and bus-lane enforcement, and flagging stolen or wanted vehicles. The scale is real: the UK's national ANPR network runs on the order of 13,000 cameras submitting roughly 55–60 million plate "reads" every day. A plate is personal data, but it is not special-category biometric data, so the legal weight sits on retention and access rather than on capture — a distinction we draw carefully in licence-plate recognition (LPR/ANPR).

Crowd and movement analytics count people, estimate density, and flag unusual flow — a crowd building beyond a safe threshold at a transit hub, a person moving against the flow, an object left behind. These are rule- and counting-based and generally describe a scene without identifying anyone; the rule logic is covered in behavioural analytics: loitering, intrusion, and zones, and the people-counting craft in the retail analytics reference design.

Forensic search is the analytic operators use most. After an incident, you do not scrub through thousands of hours of footage — you query a metadata index built at record time across the whole federated fleet ("a red van, this corridor of districts, between 14:00 and 16:00"). What you can find depends entirely on what was indexed; the method and its limits are in search by event and forensic search.

Run all of these at the edge where you can — on the camera or a district server — so the analytics produce small metadata rather than shipping full video to the centre. That keeps the federated bandwidth budget intact and is the same edge-versus-cloud calculus we lay out in edge vs cloud video analytics. And never quote a single accuracy number for any of them. Analytics accuracy is a precision-and-recall range that depends on camera angle, lighting, weather, and tuning; a plate reader on a controlled lane is far more reliable than the same model on free-flowing night-time traffic.

The line you cannot casually cross: live face recognition of the public

Everything above describes a person or a vehicle without naming them. The moment a city analytic moves from detecting a person to identifying a named individual from their face in real time, in a public space, you have crossed into the single most regulated act in surveillance — and in much of the world, across a legal line.

Start with the distinction, because vendors blur it. Face detection ("there is a face here") is not face recognition ("this face belongs to Jane Doe, matched against a watchlist"). Recognition turns a face into a biometric template — a string of numbers unique to that person — and compares it against a database. That template is special-category biometric data under the EU's General Data Protection Regulation (GDPR, Regulation (EU) 2016/679), specifically Article 9, which prohibits processing it for the purpose of uniquely identifying someone except under narrow conditions. The model internals — how a face becomes a template — belong to our AI for Video Engineering section; here the point is the legal gate, and the law on public face recognition is now explicit.

The EU Artificial Intelligence Act (Regulation (EU) 2024/1689), whose prohibitions have applied since 2 February 2025, bans in Article 5(1)(h) the use of real-time remote biometric identification systems in publicly accessible spaces for law-enforcement purposes — exactly the "live face recognition on a city street" use case — subject only to three exhaustively listed exceptions: a targeted search for specific victims of abduction, trafficking, or sexual exploitation, or for missing persons; the prevention of a specific, substantial, and imminent threat to life or a foreseeable terrorist attack; and the localisation or identification of a suspect of a serious criminal offence listed in the Act. Even within those exceptions, deployment requires prior authorisation by a judicial or independent administrative authority, a fundamental-rights impact assessment, and registration in an EU database. The Act separately prohibits building face databases by untargeted scraping of images from the internet or CCTV. Remote biometric identification used outside that prohibition (for example, after the fact, or by non-police actors under the GDPR) is classed as high-risk, with a heavy obligations regime; those high-risk duties were scheduled for 2 August 2026 but were deferred to 2 December 2027 under the "Digital Omnibus" simplification provisionally agreed on 7 May 2026 — a date worth re-checking, because this part of the law is still moving.

Figure 4. The line a city design must not cross by accident. Detecting people and vehicles, counting crowds, and reading plates are personal-data processing governed by the usual rules. Real-time face recognition of the public for law enforcement is a red line under EU AI Act Art. 5(1)(h) — prohibited except for narrow, court-authorised exceptions — and any face matching is special-category biometric data under GDPR Art. 9.

Outside the EU the picture is fragmented but no less constraining. In the United Kingdom, the Court of Appeal's Bridges v South Wales Police judgment ([2020] EWCA Civ 1058) found a police live-facial-recognition deployment unlawful — not because the technology is banned, but because the legal framework around who could be watchlisted and where it could be used was too loose, breaching the right to privacy, data-protection duties, and the public-sector equality duty. The UK has since expanded live facial recognition under tighter policy, with the regulator auditing forces case by case — a reminder that the rule for the public is "specific, necessary, proportionate, and accountable," not "switched on by default." In the United States there is no federal rule, so cities legislate for themselves: San Francisco became the first city to ban government use of face recognition in May 2019, and well over a dozen US cities have followed, while others permit it — meaning the same analytic is lawful on one side of a county line and a crime on the other. And US state biometric laws, above all Illinois's BIPA, attach serious liability to capturing biometric identifiers without consent, as we detail in BIPA and US biometric privacy law.

A final accuracy point, because it compounds the legal one. Face recognition that scores in the high-90s percent in a cooperative lab test — good lighting, a person looking at the camera — performs far worse on real public-space CCTV at a distance, in crowds, in poor light, and national testing has documented meaningful accuracy differences across demographic groups. A false match in a city deployment is not a statistic; it is a real person stopped for something they did not do. There is no "100% accurate" face recognition, and a city that deploys it as if there were is building both a legal and a human-rights liability. The deeper treatment is in face recognition in surveillance.

Privacy by design is the city architecture

Because the privacy weight is this heavy, the controls cannot be bolted on after the cameras are live. They are architecture, and in a public system they are also what earns the public's consent to be watched at all. Five of them belong in the design from the start.

A lawful basis and a documented purpose. A public authority needs a clear legal basis and a defined purpose for each camera and each analytic, and the cameras must be aimed no wider than that purpose needs. The EU framework for this — the legitimate-interest or public-task basis, the necessity-and-proportionality test, and the duty to minimise what is captured — is set out in the European Data Protection Board's Guidelines 3/2019 on processing personal data through video devices, and grounded in the GDPR. The full treatment is in GDPR for video surveillance and privacy by design for surveillance.

A Data Protection Impact Assessment. Systematic monitoring of a publicly accessible area on a large scale is one of the cases where the GDPR (Article 35) explicitly requires a DPIA before you switch the system on. For a city, that is not an edge case — it is the default, and it should be a gate in the project plan, not a document written after go-live.

Privacy masking. Cameras that necessarily overlook windows, gardens, or interiors the system has no business watching should have those regions digitally blacked out at the source. Masking is the data-minimisation principle made concrete.

Retention and lawful deletion. Footage must be kept no longer than the purpose requires; the GDPR's storage-limitation principle (Article 5(1)(e)) caps the maximum, distinct from any operational minimum. At petabyte scale, automatic, logged deletion on a schedule is not just compliance — it is also how you stop storage growing without bound. ANPR systems illustrate the discipline: reads are typically held for a defined period with tiered access limits, not kept forever.

Multi-agency access control and audit. A city system is shared — police, traffic, transit, emergency management, sometimes private camera owners. Each role must see only what it is entitled to (role-based access control), and every view, search, and export must be logged so misuse can be detected and proven. The shared real-time crime centre is powerful precisely because it pools feeds; that power is exactly why access governance has to be engineered, not assumed.

The whole posture is captured, as an ordered pre-deployment list, in the surveillance compliance checklist — the right companion to this design for the legal-review stage.

A worked reference design: a 5,000-camera city across six districts

Put the pieces together for a mid-size city: about 5,000 cameras across six districts, feeding a central operations centre with a small number of simultaneous live viewers and a forensic-search workload after incidents.

Architecture (federated):
  6 district nodes        each records its own ~830 cameras locally (edge recording)
  Central operations ctr  searches the whole fleet, streams any camera on demand
  WAN role                carries metadata + on-demand live views, NOT constant recording

Storage (30-day retention, 2 Mbps average, H.265):
  Per camera   2 Mbps × 10.8 GB = 21.6 GB/day
  Per district 830 cams × 21.6 GB ≈ 17.9 TB/day  → ~538 TB / 30 days (usable)
  Whole city   ≈ 108 TB/day      → ~3.2 PB / 30 days (usable)
  + RAID & headroom (×1.5)        → ~4.9 PB raw, spread across the six districts

Bandwidth:
  Centralized (rejected)  5,000 × 2 Mbps = 10 Gbps constant backhaul
  Federated (chosen)      ~50 live views × 4 Mbps = 200 Mbps + small metadata

Standards spine:
  ONVIF Profile S/T (stream), G (record/retrieve), M (analytics events); IEC 62676 system-level

Analytics (edge-first):
  ANPR for traffic + wanted-vehicle alerts; crowd/flow at transit hubs; forensic search citywide
  Face recognition of the public: OFF by default — a legal gate (EU AI Act Art. 5 / GDPR Art. 9), not a toggle

Governance (built in, not added):
  DPIA before go-live (GDPR Art. 35) · privacy masking at source · scheduled logged deletion
  role-based access for police/traffic/transit · full audit log of views, searches, exports

The numbers are illustrative and move a great deal with camera resolution, codec, recording mode, climate, and vendor — size a real build with the surveillance cost model and the city surveillance architecture and governance checklist below, which puts the federation decisions, the storage and bandwidth math, the standards spine, and the legal gate on one page. The shape of the design, though, is stable: federate by district so the city scales and survives outages; record at the edge and stream on demand so the network carries views, not constant recording; tier storage and discipline retention so the petabytes stay affordable and lawful; lean on ONVIF and IEC 62676 to hold a multi-vendor fleet together; and treat the biometric line and the governance controls as architecture decided on day one.

Figure 5. Four ways to build at city scale. Federated and hybrid designs dominate real city deployments because they keep recording near the cameras, survive a district-link outage, and avoid the constant backhaul a centralized design demands. Cloud VSaaS suits smaller or camera-light programmes and remote sites.

Architecture	How it scales	Bandwidth to centre	Resilience to a site outage	Deployment model	Best fit
Centralized single VMS	Poorly past ~1,000 cams	Very high (all streams, constant)	Low — centre is a single point of failure	On-prem, one site	Small towns; one campus
Federated multi-district	To tens of thousands	Low (metadata + on-demand views)	High — districts run autonomously	On-prem per district + thin centre	Most city programmes
Cloud VSaaS	Elastic, vendor-managed	Upload-bound; egress costs add up	Depends on the link and provider	Cloud-hosted	Camera-light or remote sites
Hybrid (edge + cloud)	To tens of thousands	Edge records; cloud for select feeds	High — edge survives a cloud outage	On-prem edge + cloud services	Cities wanting cloud analytics with local recording

Where Fora Soft fits in

Fora Soft has built video streaming, real-time video, and computer-vision software since 2005, across 625+ projects, and city-scale surveillance sits squarely at that intersection of large fleets, hard streaming constraints, and analytics. When we design or integrate a city system, we lead with how it behaves under real load — the actual backhaul a federated rollout consumes, the petabytes a chosen retention truly costs, the realistic accuracy of an analytic at the city's real camera angles and lighting — and only then the feature list, because a city design that ignores the bandwidth and storage math fails the moment it leaves the slide. We treat the privacy and legal posture as an architecture decision made on day one — masking, retention and deletion, role-based access and audit, and a hard gate in front of any biometric identification — so the system survives both a citywide incident and a regulator's question, rather than scrambling to retrofit compliance after the cameras are live.

What to read next

• Federation: managing many sites as one — the scaling pattern this design rests on.
• GDPR for video surveillance — the legal frame for watching the public.
• Estimating a surveillance project: scope to number — turn this design into a cost.

Call to action

• Talk to a surveillance engineer — book a 30-minute scoping call to talk through your city surveillance architecture plan.
• See our case studies — 250+ shipped projects across video streaming, WebRTC, OTT, telemedicine, e-learning, surveillance, and AR/VR.
• Download the City Surveillance Architecture & Governance Checklist — One-page planning tool for a city or public-space surveillance build: the two defining loads (scale + privacy weight); the federation decisions (record-local, stream-on-demand, district autonomy, the ONVIF + IEC 62676 standards spine);….

References

1. EU Artificial Intelligence Act (Regulation (EU) 2024/1689), Article 5(1)(h) and recitals on real-time remote biometric identification. European Union (EUR-Lex). Tier 1. Prohibits real-time remote biometric identification in publicly accessible spaces for law-enforcement purposes (prohibitions applied from 2 Feb 2025), with three exhaustive exceptions and safeguards (prior judicial/independent authorisation, fundamental-rights impact assessment, EU-database registration); also prohibits untargeted facial-image scraping. The controlling source for the public-face-recognition line. https://eur-lex.europa.eu/eli/reg/2024/1689/oj
2. General Data Protection Regulation (Regulation (EU) 2016/679), Art. 9, Art. 35, Art. 5(1)(e). European Union (EUR-Lex). Tier 1. Art. 9 makes biometric data used to uniquely identify a person special-category; Art. 35 (esp. 35(3)(c)) requires a DPIA for systematic large-scale monitoring of a publicly accessible area; Art. 5(1)(e) is the storage-limitation principle behind retention caps. https://eur-lex.europa.eu/eli/reg/2016/679/oj
3. Guidelines 3/2019 on processing of personal data through video devices (v2.0, 2020). European Data Protection Board (EDPB). Tier 2. The legitimate-interest / public-task basis with a necessity-and-proportionality test, and the data-minimisation and privacy-masking duties for public-space video — the operative interpretation for a city deployment. https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-32019-processing-personal-data-through-video_en
4. R (Bridges) v Chief Constable of South Wales Police [2020] EWCA Civ 1058 (Court of Appeal, 11 Aug 2020). Courts and Tribunals Judiciary (England & Wales). Tier 1. Held a police live-facial-recognition deployment unlawful for an insufficient legal framework (ECHR Art. 8, Data Protection Act 2018, Public Sector Equality Duty); the leading UK authority on public-space facial recognition. https://www.judiciary.uk/judgments/r-bridges-v-cc-south-wales-police/
5. IEC 62676: Video surveillance systems for use in security applications (system requirements and application guidelines). International Electrotechnical Commission (IEC). Tier 1. The vendor-neutral system-level standard for video surveillance, including detect-vs-identify pixel-density guidance — the basis for specifying city-scale performance in procurement without naming a brand. https://webstore.iec.ch/publication/28426
6. ONVIF Profiles S, G, T, and M. ONVIF. Tier 1. Standardise streaming (S), recording and retrieval (G), advanced streaming incl. H.265 (T), and analytics metadata/events (M) across a multi-vendor fleet; the interoperability baseline that lets a city's mixed cameras join one platform, distinct from full vendor-SDK feature parity. https://www.onvif.org/profiles/
7. Automatic Number Plate Recognition (ANPR) — national network scale, access, and retention. Metropolitan Police / National Police Chiefs' Council (UK). Tier 2. The UK national ANPR network runs on the order of ~13,000 cameras submitting ~55–60 million reads/day, with defined retention and tiered access limits — the scale and governance reference for city traffic/vehicle analytics. https://www.met.police.uk/advice/advice-and-information/rs/road-safety/automatic-number-plate-recognition-anpr/
8. EU AI Act "Digital Omnibus": provisional agreement deferring high-risk obligations to 2 December 2027 (7 May 2026). Council of the EU / European Parliament. Tier 2. Documents the deferral of the Annex III high-risk compliance deadline (which covers remote biometric identification used outside the Art. 5 prohibition and biometric categorisation) from 2 Aug 2026 to 2 Dec 2027 — the moving date flagged in the body. https://www.consilium.europa.eu/en/press/press-releases/2026/05/07/artificial-intelligence-council-and-parliament-agree-to-simplify-and-streamline-rules/
9. City Surveillance Market — size and growth (2026). Mordor Intelligence. Tier 5. The city-surveillance market at ~USD 15.6 billion in 2026, growing ~8% a year — used only to size the market context in "Why this matters," not for any technical or legal claim. https://www.mordorintelligence.com/industry-reports/global-city-surveillance-market
10. How Real-Time Crime Centers Draw on Video Surveillance (2026); city RTCC camera-integration counts. StateTech Magazine and city programme reports. Tier 5. Documents US real-time crime centres integrating thousands of cameras (e.g., 2,000–3,200+) from city, business, and private sources — the orientation for the "scale" load, not a technical citation. https://statetechmagazine.com/article/2026/04/how-real-time-crime-centers-draw-video-surveillance
11. San Francisco bans government use of facial recognition (May 2019); subsequent US city bans. Electronic Frontier Foundation (About Face). Tier 5. San Francisco as the first US city to ban government face recognition, with a dozen-plus cities following and others permitting it — the basis for the fragmented-US-regulation point; legal specifics confirmed against the underlying ordinances. https://www.eff.org/aboutface/bans-bills-and-moratoria