Face recognition: questions to settle before deployment
Face recognition handles personal data and affects the people it sees. This guide sets out the decisions to make, and to write down, before the first camera goes live.
Face recognition can go wrong without any fault in the software: a purpose nobody wrote down, a list nobody reviews, an alert acted on without a check. The questions below apply whichever supplier's system you use.
Define the purpose
Write one sentence that says what the system is for. For example: alert the control room when a person on the security watchlist enters the building. Or: check faces at a restricted gate against the staff list.
That sentence sets the limits:
- Which cameras take part, and which do not.
- Whose faces go on a list.
- Who receives an alert, and what they may do.
- What the system must not be used for.
A later request that does not fit the sentence is a new purpose. Treat it as a new decision.
Check the law that applies to you
Data protection laws generally treat a face image used to recognise a person as personal data, and some give it extra protection. The rules differ by country, by sector and between public bodies and private organisations.
Before you commit to a system, ask your legal or data protection adviser:
- On what legal basis you may match faces for this purpose.
- Whether consent, a public notice or a formal assessment is needed first.
- What limits apply to storing face data and sharing it.
- Which duties fall on you as the operator, and which on your suppliers.
This guide is general guidance. It is not legal advice.
- Written for
- Security heads, operations managers and buyers planning face recognition
- Settle first
- Purpose, legal basis, watchlist rules, review of matches, thresholds and retention
- A match is
- A lead for a trained person to verify, not proof of identity
Govern the watchlist
A watchlist is a set of decisions about people. Each entry needs an owner, a recorded reason and an end date.
- Who may add an entry
- Name the roles that may add a person, and keep the group small. Where a match has serious consequences, require a second person to approve each entry.
- Grounds for an entry
- State what justifies an entry and what evidence is recorded with it. An entry with no recorded reason cannot be reviewed later.
- Reference photos
- A poor reference photo tends to give poor matches. Set a standard for the photos you accept: recent, sharp, evenly lit and facing the camera.
- Who reviews the list
- Set a review schedule. Have someone other than the person who added an entry check whether it is still justified.
- How entries expire
- Give each entry an expiry date when it is created. Remove an entry that nobody renews.
- Record of changes
- Keep a log of who added, changed or removed each entry, and when.
A match is a lead, not proof
A match means the software found a close resemblance to a list entry. It does not establish who the person is, and no action against a person should rest on it alone.
-
The alert arrives
An alert typically shows the camera snapshot, the matched list entry and a similarity score. The score says how alike the software judges the two faces, and nothing more.
-
A trained person compares
The reviewer compares the two images and, where possible, the live video. If they are not satisfied, they reject the alert and no action follows.
-
Staff confirm identity
Before anyone is refused entry, detained or reported, staff confirm who the person is by other means, such as an identity document.
-
The outcome is recorded
The reviewer records each alert as confirmed or rejected, under their own name. Over time the record shows how often alerts are right.
Thresholds and the two kinds of error
Face recognition software gives each comparison a similarity score and raises an alert when the score passes a threshold. Where you set the threshold decides which mistake happens more often.
| Error | What happens | What reduces it |
|---|---|---|
| False match | An alert links a person to a list entry that is not theirs. That person may be stopped or questioned, and reviewers may start to doubt the alerts. | A higher threshold and better reference photos. Human review before action limits the harm from the rest. |
| Missed match | A listed person passes a camera and no alert is raised. Nobody sees it happen, so the error goes uncounted unless you test. | A lower threshold and camera positions that give clearer faces. |
No setting removes both errors
Raising the threshold cuts false matches and adds missed ones. Lowering it does the reverse. Decide which error costs more for your purpose, set the threshold to suit, and record the reason.
Image quality and testing on site
Results depend on the picture each camera gives. Accuracy figures measured on test images elsewhere do not tell you how your own cameras will perform.
Place cameras for faces
A camera placed for general surveillance often gives poor faces. For each camera that will take part, check:
- Angle. The camera sees faces close to front-on. A steep downward view hides the face.
- Size. The face is large enough in the picture. Ask the supplier how large it must be, then measure it on your camera.
- Light. No bright door or window sits behind the person, and the picture holds up at night.
- Movement. Faces are not blurred. Gates and doorways, where people slow down and face one way, usually give steadier pictures.
Leave out a camera that cannot give a usable face.
Test in your own conditions
Test before the system goes live, on your own cameras, with volunteers who have agreed to take part.
- Add the volunteers to a test list. Have them walk past each camera by day and by night.
- Send people who are not on the list past the same cameras.
- Include caps, glasses, masks and groups, as they occur on your site.
- Include volunteers of different ages, genders and skin tones. Results can differ between groups.
- Count missed matches and false matches for each camera.
Use the counts to set thresholds. Test again when cameras, lighting or software change.
Retention, access and openness
Decide how face data is protected and what the people on camera are told. Put the answers in a written policy and name its owner.
- Retention
- How long alert records, snapshots and face data are kept, and how they are deleted. State what happens to faces that match nothing. A cautious rule is not to keep them.
- Access control
- Who may view alerts, search past records or export images. Give each role only the cameras and functions it needs.
- Audit
- Which actions are logged, and who reads the log. Have someone outside the operating team review it on a schedule.
- Age and gender estimates
- Some systems estimate age and gender from a face. The estimates are sensitive and can be wrong. Use them only as totals for analytics, not to decide about one person. If you have no stated use for them, leave them out of scope.
- Notice
- How people learn that face recognition is in use, for example signs at entrances, a published policy or a briefing for staff. Say what it is for and whom to contact.
- Questions and complaints
- How a person can challenge a match they believe is wrong, who answers, and how a wrong entry is corrected.
How Videolytical approaches this
Videolytical's Face Recognition matches faces against staff, VIP or watchlist databases in real time and shows matches to operators as alerts. Zones, schedules and confidence thresholds are set for each camera. Role-based access for each camera and function, and an audit trail of alerts and operator actions, support the access and audit rules you set.
The purpose, the watchlist rules and the retention periods remain decisions for the organisation that operates the system.
See face recognition on your own footage
Arrange a live demo on your own footage, or ask for an architecture and sizing discussion for your site.