Privacy and human review in face recognition

What makes a purpose narrow enough to govern?

A stated purpose of "security" cannot be tested against, so it cannot constrain anything. A purpose narrow enough to govern names the population, the location, the trigger and the action — and each of those makes a later use either clearly within scope or clearly outside it.

• Who is enrolled, and on what basis they were enrolled. Employees who consented as a condition of access are a different population from members of the public who did not.
• Where recognition runs, camera by camera. "The building" is not a location; a named door is.
• What triggers an alert, and what the system does with it — including whether it can act without a person.
• How long an enrolment lasts, and what removes someone from it. A gallery nobody can leave grows into a different system than the one that was approved.

The test of a well-drawn purpose is whether a request to reuse the system for something adjacent — finding a missing person, checking attendance, investigating a theft — can be answered from the document rather than negotiated. If it has to be negotiated each time, the purpose was too broad to be a control.

How long should biometric data be kept?

The default should be that a face image captured at a camera is discarded once the match attempt resolves, and that only the outcome is retained. Most systems keep far more than they need, and the reason is usually that nobody specified otherwise.

1. Separate the three things people conflate: the enrolment template, the captured probe image, and the match record. They have different lifetimes and different risks.
2. Discard probe images by default. If they are retained for investigation, set the period in days and enforce it in code rather than in policy.
3. Keep templates only as long as the person is entitled to access, and make removal an actual process with an owner rather than an intention.
4. Retain the match record — who, when, which camera, what score, what happened — for as long as the audit obligation requires. This is the item worth keeping.
5. Encrypt templates at rest and be explicit that a template is biometric data even though it is not a photograph. A stolen template database is a breach whatever it looks like.

A short retention period is also the strongest available answer to a subject-access or deletion request, because there is less to find and less to argue about. Systems designed to keep everything make every later governance question harder than it needed to be.

Why does human review fail, and what fixes it?

Human review is the control most often cited and least often designed. The failure mode is specific and well understood: an operator shown a high-confidence match, with a queue waiting and a system that is usually right, is being asked to disagree with a machine under time pressure. People do that far less often than a governance document assumes.

• Do not show the score as the headline. A number reading 98 anchors the decision before the operator has looked at the faces.
• Show the two images side by side at a size that supports comparison, and make that the primary interface rather than a detail view behind a click.
• Give the operator a way to say "not sure" that is not a rejection. Forcing a binary choice under time pressure produces agreement with the machine.
• Do not measure operators on throughput alone. Whatever is measured is what the review optimises for, and throughput optimises for agreeing.
• Log the operator's decision separately from the system's, so the two can be compared. If they never disagree, the review is not functioning as a control.

That last item is the one that turns human review from a claim into a measurement. A review step where the human agrees with the system essentially always is not adding oversight; it is adding a signature.

What should the audit log record?

An audit log exists to answer questions asked months later by someone who was not there. That is a higher bar than logging for debugging, and it changes what has to be recorded.

The log itself is sensitive: it records who was looked for and by whom. Access to it needs its own controls, and it should not be readable by the operators whose decisions it records.

What does the EU AI Act require, and when?

The EU AI Act is the most consequential regulation in this area for any organisation with European operations, and its obligations arrive in stages rather than all at once. The Commission publishes the framework and the timeline; the summary below points at that source rather than paraphrasing it as advice.

• Real-time remote biometric identification in publicly accessible spaces for law enforcement is prohibited, subject to narrowly drawn exceptions.
• Most other biometric identification uses fall into the high-risk category, which brings obligations on risk management, data governance, logging, human oversight and accuracy documentation.
• The obligations phase in over a period beginning in 2025, so the compliance date depends on which category a deployment falls into.
• This is a summary and not legal advice. The determination of which category a specific deployment falls into is a legal question about that deployment.

• European Commission — regulatory framework for AIThe Act itself, its risk categories and the application timeline, from the body that publishes it.

Outside the EU the picture is fragmented, and the practical consequence is that a system designed only for the least demanding jurisdiction it operates in will need rebuilding. Designing to the strictest requirement across the operating footprint is usually cheaper than the alternative.

What should a buyer require from a vendor?

1. Where processing happens, precisely. On-premise, edge and air-gapped deployment change the data-protection analysis completely, and the answer should be in the contract rather than in a diagram.
2. Whether any data leaves the site, including telemetry, crash reports and model-improvement data. "Encrypted in transit" describes how data travels, not whether it should be travelling.
3. Whether customer data is used to train or improve the vendor's models, and the ability to refuse it without losing support.
4. Deletion on termination, with a defined period and evidence that it happened.
5. Documented error rates from a pilot on the buyer's own site, rather than a published accuracy figure — and the ability to re-test after deployment.
6. The audit log's contents and who can read it, including whether the vendor can.

Ayonix should be held to this list too. A framework a vendor publishes and exempts itself from is marketing; the point of writing it down is that a buyer can use it in a negotiation with us.