Face recognition deployment checklist

Stage 1: What is this system for, and who is in it?

This stage costs nothing and constrains everything after it. Skipping it is why deployments end up with a gallery nobody can leave and a purpose broad enough to justify anything.

1. Name the task: 1:1 verification, 1:N identification, or watchlist alerting. They have different error profiles, different legal treatment and different costs, and a project that has not chosen will drift into the most permissive one.
2. Name the population and the basis for their enrolment. Staff who consented as a condition of access and members of the public who did not are different problems.
3. Name what happens on a match, and whether the system may act without a person in the loop.
4. Decide what removes someone from the gallery, and who owns that process.
5. Write the answers down before talking to a vendor. A vendor conversation held before this stage will define the scope for you.

• Privacy and human review in face recognitionWhat makes a purpose narrow enough to govern, and what the audit log has to answer.

Stage 2: Where does processing run?

The architecture decision is the most expensive one to reverse, and three requirements settle it on their own — before accuracy is discussed at all.

• Whether the images may leave the site. If they may not, the architecture is on-premise, edge or air-gapped, and no accuracy comparison changes that.
• Whether recognition must survive a network outage. If a door has to open when the link is down, inference runs locally.
• Whether the latency budget is shorter than the round trip. A gate that must decide in 200 milliseconds cannot wait for a cloud region.
• Only if none of the three binds is a cloud service a live option — and then it is often the better one, which is worth saying plainly.

• On-premise, edge and air-gapped versus cloud-only recognitionThe three requirements in detail, the bandwidth arithmetic, and when cloud is the better answer.

Stage 3: How will people be enrolled?

Enrolment quality caps everything downstream and cannot be fixed later by a better algorithm. This is the stage most often treated as administrative and most often decisive.

1. Decide the source: a controlled capture session, an existing badge photo, or a document scan. They are not equivalent, and a gallery mixing all three performs like its worst member.
2. Set a quality bar and enforce it at capture, not afterwards. Rejecting an image while the person is standing there costs seconds; discovering it a year later costs a re-enrolment programme.
3. Decide how enrolment ages. Faces change, and an enrolment from eight years ago is not the same asset as one from last month.
4. Plan re-enrolment before you need it, including who is told and how.
5. Decide what happens for someone who cannot be enrolled well — and note that this is the same population that will need the fallback path in stage 5.

Stage 4: Where do the cameras go?

Capture design decides more outcomes than algorithm choice, and it is constrained by the building rather than by the budget. It comes after the architecture decision because the architecture determines whether processing happens at the camera or elsewhere, which changes what the camera has to be.

• Survey each capture point for measured pixels across the face, mounting height and angle, and light levels at the three worst times of day.
• Fight for a narrow field of view rather than a higher-resolution camera. Narrowing the view is usually cheaper and more effective.
• Never point a capture camera at a window or glass entrance. Backlight is the most common cause of a system that worked in the demo and fails in the lobby.
• Check whether existing CCTV can serve. Usually it cannot, because it was mounted for scene coverage: high, wide and angled down. Measure rather than assume in either direction.

• Camera placement for face recognitionPixel counts, mounting geometry, lighting, movement, and what a site survey must record.

Stage 5: What happens when it fails?

Every deployment has a population it serves worse, and the plan for them is not a detail — it sizes the staffing, which sizes the business case. A design without an answer here is not finished, however good the recognition is.

1. Define the fallback path: what a person does when they are not recognised, who helps them, and how long it takes.
2. Measure that time. It is the number that determines how many staff the site needs at peak.
3. Make the fallback non-punitive and non-conspicuous. A fallback that singles people out will be avoided, and avoidance shows up as throughput loss.
4. Include the populations that predictably need it: children, wheelchair users, people in lawful head coverings, people who decline to participate.
5. Decide the escalation path for a disputed match, and who has authority to override the system.

Stage 6: Pilot and acceptance

The pilot answers whether the system works here. Its value depends entirely on the acceptance criteria being written before it starts, because criteria agreed afterwards are not criteria.

• Agree the threshold, or the process for setting it, before the vendor sees any data.
• Agree the acceptance criteria as numbers with a direction: acceptable false-match rate, acceptable missed-match rate, required throughput, maximum fallback resolution time.
• Run across the full daily and weekly cycle, including the worst lighting conditions.
• Count attempts rather than reporting rates alone — a rate without its sample size hides whether the measurement had any power.
• Measure the fallback path as part of the pilot, not as a separate exercise.

• How to run a face recognition pilot and acceptance testWhat to agree beforehand, how many subjects a measurement needs, and how to report it.

Stage 7: Rollout and review

A pilot result belongs to the conditions it was run under. Rollout changes those conditions, and the review is what catches the difference before it becomes an incident.

1. Expect identification performance to change with gallery size. A result against 500 enrolled people does not predict the result against 500,000.
2. Re-measure after the gallery has grown, not only at go-live.
3. Watch the operator disagreement rate. If human reviewers essentially never disagree with the system, the review step has stopped being a control.
4. Schedule a camera check: focus drifts, lighting changes with the seasons, and furniture moves into fields of view.
5. Review retention and gallery membership on a fixed schedule, with an owner. Both drift towards keeping more than intended.
6. Record what changed. Threshold changes and camera additions quietly alter what the system is, and an audit six months later needs to be able to see them.

The most common post-rollout failure is not technical. It is a system that was approved for one purpose being used for an adjacent one, because the request was reasonable and the purpose statement was too broad to refuse it.