Detection, Tracking, Identification

The boundary between these is not a matter of degree. It determines the whole legal and ethical analysis, and it is drawn at a specific technical point.

Detection

Question: is an object of class X present?

Output: a bounding box and a confidence score.

Needs: a model trained on the class, and a threshold.

Retains: nothing about individuals, if designed that way.

Legal position: ordinarily unremarkable. Video of a place is personal data where people are identifiable, but detection itself does not create biometric data.

Tracking and counting

Question: how many, where, how long?

Output: counts, dwell times, paths, occupancy.

Needs: detection plus association between frames.

Retains: temporary identifiers within a scene, which are not identity.

The design decision that matters: whether the per-person track is discarded once the count is computed. If it is, the output is aggregate. If it is stored, you have a movement record of identifiable individuals whether or not you attached a name.

Identification

Question: which known person is this?

Output: a match against an enrolled set, with a score.

Needs: a biometric template — a mathematical representation of a face or gait — and a database to match against.

Retains: biometric data, by definition.

Legal position: entirely different. Biometric data used to identify a person is special-category data under European data protection law, subject to specific state statutes in parts of the United States, and the subject of prohibitions and high-risk classification under the EU AI Act.

Where the line falls

The moment a template is created for the purpose of uniquely identifying someone.

Not when a face appears in frame. Not when a person is detected. When a representation is computed in order to tell one person from another across time and place.

Systems slide across this line by accident. A tracker that re-identifies someone returning to a shop the following week is doing identification, whatever the product is called.

Ask the question directly: could this system recognise the same individual on a different day? If yes, it is identification.

Verification is not identification

A distinction worth keeping, because it is frequently blurred.

Verification: one-to-one. Is this person who they claim to be? Requires their cooperation and a claimed identity.

Identification: one-to-many. Who is this? Requires a database and no cooperation.

The privacy and legal profiles differ substantially, and so does the error behaviour: a one-to-many search across a large gallery generates false matches at a rate that a one-to-one check does not.

Choosing the least capable option

For every proposed use, ask what the decision needs.

Safety alarm in a machine zone: detection.

Queue management: counting.

Occupancy limits: counting.

Access control at a door: verification, with the person's participation.

Finding a specific individual across a site: identification, and this needs a much stronger justification than any of the above.

Design to the lowest tier that answers the question, and record why anything above detection was necessary.

The re-identification test

One question that classifies any system correctly, whatever it is marketed as.

Could this system recognise the same individual on a different day, in a different place?

If yes, it performs identification, regardless of whether a name is attached or a face is displayed.

Repeat-visitor analytics, cross-camera tracking and loyalty matching all fail this test, and all are commonly sold as analytics rather than as biometrics.

Ask the vendor directly and get the answer in writing, because the product literature will not say it.

Sliding across the line by accident

Systems arrive at identification without anyone deciding to.

A tracker extended to work across cameras.

A counter given the ability to recognise returning visitors.

A vendor upgrade enabling face detection by default.

A loyalty integration matching a face to an account.

None of these was proposed as facial recognition and each results in it.

Which is why the register records the tier, why the console check exists, and why the re-identification test should be applied after every upgrade rather than only at procurement.