# Face recognition for government and public safety URL: https://ayonix.com/solutions/government-and-public-safety Updated: 2026-10-17 | Published: 2026-09-08 | Author: Jan Mocary, Chief Technology Officer, Ayonix AI 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. ## Which public-sector organisations have deployed Ayonix? Ayonix has delivered face recognition, video analytics and AI agents to border, police, defence, airport and interior-ministry operators. Each project below is published as a case study that names the organisation, the problem it had and what was deployed. What the five have in common is the governance built on top of the system's output: a person reviews before anything happens, and the system records who searched, who decided and who overrode. The sections below explain why that, more than the algorithm, is what a public-sector deployment is judged on. - United Nations: border control: Passport-to-face verification at e-gates, watchlist screening with officer review, and an audit record of every approval and override. - Turkish Police forces: public-space video analytics: Existing CCTV connected to face recognition against legally managed watchlists, with alerts reviewed by authorised officers before any action. - Ministry of Defence of India: on-site video analytics: Detection, tracking and recording on an ATLAS BOX appliance next to the cameras, operating fully offline, including on an air-gapped network. - Colombo Bandaranaike International Airport: passenger processing: Face-to-passport verification, watchlist screening and queue analytics across the immigration, security and boarding areas. - Dubai Ministry of Interior: building-approval checks: Retrieval-augmented checks of drawings and documents against the regulations, with an evidence-linked report; reviewers validate, override and decide, and every action is logged. ## How do government agencies actually use face recognition? 18 of 24 — surveyed US federal agencies reported using face recognition in fiscal 2020 (US Government Accountability Office, GAO-21-526: https://www.gao.gov/products/gao-21-526) Reported purposes across the 24 agencies surveyed (GAO-21-526, fiscal 2020). 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. - Digital access or cybersecurity, such as unlocking an agency phone — Agencies: 16 - Generating leads in criminal investigations — Agencies: 6 - Physical security, monitoring a location or controlling building access — Agencies: 5 - Conducting or supporting related research and development — Agencies: 10 ## What does the EU AI Act prohibit? 2 February 2025 — date the EU AI Act's prohibitions on unacceptable-risk practices became applicable (European Commission: https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai) 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. 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. - 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. ## 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. Three deployment models routinely written as though they were the same. 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. - Air-gapped — Where it runs: Customer hardware inside the boundary — Outbound network: None at all - On-premise — Where it runs: Customer hardware or data centre — Outbound network: Usually permitted, often restricted - Private cloud — Where it runs: Dedicated tenancy at a provider — Outbound network: Inherent; data leaves the organisation ## 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. The two operations compared on the properties that decide their governance. 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. - Trigger — Retrospective search: A specific incident already under investigation — Live identification: Continuous, on everyone who passes - Subjects processed — Retrospective search: Those present in the retained footage — Live identification: Everyone in view, indefinitely - Time pressure on the reviewer — Retrospective search: Hours or days — Live identification: Seconds - Authorisation — Retrospective search: Can be sought before each search — Live identification: Sought once, applies continuously - Typical regulatory treatment — Retrospective search: Conditioned — Live identification: Prohibited or narrowly excepted ## What should a public sector procurement ask for? 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. - 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. ## How do government agencies buy from Ayonix? For vendor registration the company record is published in one place: Ayonix Co., Ltd. (アヨニックス株式会社), founded in Tokyo in 2007, with offices in Japan, Australia and the United States. The company facts page gives the legal name, address and telephone numbers in the form Ayonix asks registries to use. - Start from the requirement rather than the product: verification or identification, live or retrospective, and whether the site permits any outbound network at all. Ayonix scopes a project against those three answers. - Pilot on the agency's own cameras before any volume commitment, reporting both error types and the outcome of every alert review. - Deploy on hardware the agency controls, its own servers or an ATLAS BOX appliance, with air-gapped operation where the site requires it. - Contract with Ayonix directly, or through a local systems integrator in the Ayonix partner programme. - Ask Ayonix about a public-sector pilot - Ayonix company facts for vendor registration - Find or become an Ayonix systems integrator ## Frequently asked questions **Which government organisations have deployed Ayonix?** Published Ayonix case studies name the United Nations for border control, Turkish Police forces for public-space video analytics, India's Ministry of Defence for on-site video analytics on an ATLAS BOX appliance, Colombo Bandaranaike International Airport for passenger processing, and Dubai's Ministry of Interior for AI-assisted building-approval checks. Each describes the problem, the deployment and the review workflow. **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.