Face recognition for government and public safety
Government face recognition deployments are judged on their governance as much as their engineering: who may run a search, what happens on a match, what is logged, and whether the system identifies people who never enrolled. The legal exposure follows that last question rather than the accuracy of the matcher.
How do government agencies actually use face recognition?
| Purpose | Agencies |
|---|---|
| Digital access or cybersecurity, such as unlocking an agency phone | 16 |
| Generating leads in criminal investigations | 6 |
| Physical security, monitoring a location or controlling building access | 5 |
| Conducting or supporting related research and development | 10 |
The distribution is the part worth reading. The most common government use in that survey was unlocking a government phone, and the investigative uses that dominate public discussion were a minority. A programme designed as though every deployment is a surveillance deployment mis-scopes its own controls.
What does the EU AI Act prohibit?
Article 5 bars real-time remote biometric identification in publicly accessible spaces for law enforcement, subject to three exceptions: targeted search for specific victims of abduction, trafficking or sexual exploitation and for missing persons; prevention of a specific, substantial and imminent threat to life or of a terrorist attack; and locating a person suspected of a listed serious offence. Each requires prior judicial authorisation.
- The prohibition is about identification of people who did not enrol, in public, in real time. It is not a ban on biometrics.
- Verification with the subject's participation - a staff badge replacement, a document check at a counter - sits outside it.
- Retrospective analysis of recorded footage is treated differently from real-time operation, with its own conditions.
- A specification that says only 'face recognition' has not stated which of these it is, and therefore has not stated which rules apply to it.
What does a defensible alert workflow require?
A candidate match is a request for a human decision, not a conclusion. Government deployments that cause harm generally do so through the process built on top of the match rather than through the match itself: the technical error rate stops being the risk once an alert can act on its own.
- Show the probe image, the enrolled image and the score together, so the reviewer can see what the system compared.
- Record the reviewer's decision against the alert, including dismissals, and retain both for audit and threshold tuning.
- Keep an enrolment justification for every person on a watchlist, with a review date, so the list expires rather than accumulates.
- Restrict who may run a search and log every query with its requester and stated purpose, not only its result.
- Require a second, independent basis before any consequential action follows from a match.
Every enrolled entry is another chance for an unrelated person to score above the threshold, so an unpruned watchlist degrades on its own. List hygiene is an accuracy control, not administration.
The harder problem is what the reviewer brings to the decision. An operator shown a high score, a plausible pair of images and a queue behind them is being asked to disagree with a machine under time pressure, and people do that far less often than a governance document assumes. Presenting the score without a scale, or without the base rate of dismissals at that threshold, makes the number look like a verdict rather than one input.
The practical countermeasures are procedural rather than technical: record dismissals as first-class outcomes so an operator who rejects a match is doing their job rather than logging an anomaly; report the confirmed-to-dismissed ratio to the people who set the threshold; and require an independent basis before action, so that no single reviewer's agreement with the system is sufficient on its own.
Why does deployment mode decide the shortlist?
In classified facilities, in parts of central government and in critical infrastructure, a rule that the data cannot leave the premises decides the architecture before any evaluation begins. That rule excludes cloud services outright and excludes a good deal of on-premise software too, because most of it still calls home for licensing, telemetry or model updates.
| Model | Where it runs | Outbound network |
|---|---|---|
| Air-gapped | Customer hardware inside the boundary | None at all |
| On-premise | Customer hardware or data centre | Usually permitted, often restricted |
| Private cloud | Dedicated tenancy at a provider | Inherent; data leaves the organisation |
A requirement written as on-premise will be satisfied by software that phones home. If the intent is an air gap, the requirement has to say so, and the practical test is installing on a host with no route out rather than reading a datasheet.
How does retrospective analysis differ from live operation?
Searching recorded footage after an incident and identifying people from a live camera are treated as different operations by regulators, and they have genuinely different properties. The distinction is often collapsed in a specification that asks for face recognition and lets the vendor decide which one it built.
| Retrospective search | Live identification | |
|---|---|---|
| Trigger | A specific incident already under investigation | Continuous, on everyone who passes |
| Subjects processed | Those present in the retained footage | Everyone in view, indefinitely |
| Time pressure on the reviewer | Hours or days | Seconds |
| Authorisation | Can be sought before each search | Sought once, applies continuously |
| Typical regulatory treatment | Conditioned | Prohibited or narrowly excepted |
The reviewer's time budget is the difference that matters most operationally. A retrospective search can return a ranked candidate list that an analyst works through carefully; a live alert asks for a decision while the person is still walking. Systems designed for the first and deployed for the second put an unreasonable demand on the operator and then record their answer as a judgement.
Retention policy is what makes retrospective search possible at all. A footage retention period set for storage cost rather than for investigative need decides, silently, which incidents can be investigated later.
What should a public sector procurement ask for?
- Which mode: verification against a presented credential, or identification against a gallery. This decides the legal analysis.
- Which algorithm identifier was submitted to independent evaluation, and on what date.
- The demographic breakdown behind any performance figure, rather than the aggregate.
- The audit record: what is logged per search, who can read it, and how long it is kept.
- Behaviour with no outbound network, tested on a host with no route out.
- A pilot on the agency's own cameras, reporting both error types and the confirmed-to-dismissed alert ratio.
Independent evidence about algorithms comes from NIST, which measures submitted algorithms on sequestered data and publishes results whatever they show. NIST does not endorse vendors and issues no certification, so any claim of NIST approval in a bid response is a reason to ask for the underlying report rather than a credential to score.
Frequently asked questions
- How many government agencies use face recognition?
- GAO found 18 of 24 surveyed US federal agencies used it in fiscal 2020. Sixteen used it for digital access or cybersecurity such as unlocking an agency phone, six to generate leads in criminal investigations, and five for physical security or monitoring a location.
- Is face recognition banned for law enforcement in the EU?
- Not entirely. The AI Act's prohibitions became applicable on 2 February 2025, and Article 5 bars real-time remote biometric identification in publicly accessible spaces for law enforcement with three narrow exceptions, each requiring prior judicial authorisation. Verification with the subject's participation is outside the prohibition.
- Should a watchlist match trigger automatic action?
- No. A candidate match is evidence for a human decision, and a workflow that acts on it directly converts a scoring error into a real-world consequence. Standard practice shows the probe and enrolled images with the score, records the reviewer's decision, and requires an independent basis before anything follows.
- What is the difference between on-premise and air-gapped for government?
- On-premise means the software runs on the agency's hardware, which usually still permits outbound connections for licensing, telemetry and updates. Air-gapped forbids all of them. A requirement written as on-premise is routinely met by software that calls home, so the stricter intent has to be stated explicitly.
- Can a vendor be NIST certified for a government bid?
- No vendor can. NIST runs evaluations and publishes reports on how submitted algorithms performed; it does not endorse vendors, issue certificates or maintain an approved list. A NIST certification claim in a bid response is a reason to request the underlying report, not a credential to score.
- How large should a government watchlist be?
- As small as the stated purpose allows. Every enrolled entry is another opportunity for an unrelated person to score above the threshold, so false alerts scale with the list. Enrolment should carry a documented justification and a review date so entries expire rather than accumulate.
- What should be logged for a face recognition search?
- The query itself, not only its result: who ran it, when, on what basis, against which gallery, and what they decided afterwards including dismissals. An audit record that captures only matches cannot answer the question an oversight body will actually ask, which is what was searched for and why.