A sensor package appears on a council consent agenda with three attachments and a five-figure line item. It promises fewer traffic deaths, faster snowplow routing, or less water lost to leaks. The vendor's slide deck is polished, the pilot timeline is tight, and nobody in the room wants to be the person who slows things down.

What is usually missing is a plain answer to a plain question: what happens to the data about people? Most privacy problems in smart city projects are not caused by malicious technology. They are caused by contracts signed before anyone asked what the system would collect, who would hold it, how long it would sit there, and who could demand access to it a year from now. The questions below are meant to be asked before the vote, not after the first complaint.

Start With a Data Inventory, Not a Product Demo

Ask the vendor to put it in writing: what categories of data the system collects, at what level of detail, how often, where it is stored, who can access it, how long it is kept, and whether it is linked to other city datasets.

The granularity matters more than the label. A smart water meter that reports monthly totals is a billing tool. The same meter reporting every fifteen minutes can reveal when a house is empty. A foot-traffic counter that counts anonymous passersby is one thing; a device that logs Wi-Fi or Bluetooth identifiers is a movement tracker. A camera that reads plates is a different system from one that stores images of every vehicle.

Treat "anonymized" as a claim to verify, not a fact. Records that seem harmless alone can become identifying when combined with permit records, utility accounts, or a school calendar. If a vendor cannot produce a clear inventory, that silence is itself an answer.

Read the Contract for Data Rights

Procurement language decides most of this. Before signing, get straight answers to these:

• Does the city own the raw data, or only a license to use it?
• Can the vendor use, share, sell, or feed city data into its own products? Under what terms?
• What happens at the end of the contract — is data returned, deleted, and certified as deleted?
• Which subcontractors and cloud providers touch the data, and where is it stored?
• How quickly must a breach be reported, and who pays for notifying affected residents?
• Can the city audit the vendor's security practices and data handling?

Watch for "derived" and "aggregate" carve-outs

Clauses that sound harmless often are not. Language allowing a vendor to use "aggregated or derived data for product improvement" can hand over broad rights to insights drawn from your residents' behavior. If the city is paying for the system, the default should be that the city keeps the data and the vendor gets what it needs to run the service — nothing more.

Plan for Function Creep Before It Happens

Technology bought for one purpose drifts into another. Cameras installed for traffic enforcement become a tool for searching plates on behalf of other agencies. A noise sensor becomes a way to identify gatherings. A transit fare system becomes a record of where a specific person travels.

Write down permitted uses and prohibited ones. Decide who can approve a new use and whether that approval requires a public meeting. Require query logs, restrict access by role, set automatic deletion, and limit live viewing. Ask directly whether the data can be shared with other agencies, including law enforcement at any level, and under what legal standard. Because public agencies are often subject to records requests, ask what a request for this data would produce — the answer is frequently more than the council expected. For specific legal questions, get advice from your city attorney rather than relying on the vendor's assurance.

The Due-Diligence Checklist

1. Written purpose. One paragraph explaining the problem the technology solves and how success will be measured.
2. Data inventory. Categories, granularity, retention, storage location, and access.
3. Narrow scope. Collect only what the stated purpose requires, nothing speculative.
4. Retention schedule. A default deletion period, with a documented reason for anything longer.
5. Contract protections. Ownership, secondary-use limits, audit rights, deletion certification, breach terms.
6. Security basics. Encryption, access controls, logging, and a named person responsible.
7. Public notice. A one-page, plain-language summary posted before launch, not after.
8. Sunset and review. A fixed end date for the pilot and published evaluation criteria.
9. Exit plan. Data export in a usable format and no lock-in that makes switching impossible.
10. Ongoing oversight. A staff owner and an annual report to council on how the system is actually used.

Transparency Residents Can Actually Find

A privacy notice buried on page forty of a PDF is not transparency. Publish the contract and the data inventory, redacting only what genuinely requires it. Keep a public register of where sensors are installed and what they do — a simple map works better than a spreadsheet nobody opens. Put new systems on a regular agenda instead of the consent calendar so there is room for discussion.

Then publish the results. If a pilot did not deliver, say so. A city that reports its own failures earns more trust the next time it asks for one.

If you are a resident, not an official

• Ask at public comment what data the system collects and how long it is kept.
• Request the contract and any privacy assessment through your public records process.
• Ask whether the data can be shared with other agencies, and under what rules.
• Ask what happens to the data if the pilot ends.

Make Privacy Review Routine

The goal is not to stop projects. It is to stop surprises. Cities that can answer these questions move faster, because they do not have to pause a rollout to explain why a system nobody discussed is now producing records about residents who never agreed to it.

Build the review into procurement as a standard step, the way budget and insurance reviews already are. Keep template contract clauses on file. Update the data register once a year. Hand this checklist to the next council member who inherits the program, and to the residents who will live with it.

Photo: Vanessa Garcia / Pexels