Biometric vs non-biometric counting: where the EU AI Act draws the line

Why the line matters now

The EU AI Act has changed the question every retailer, mall operator, airport, and museum has to answer about a people counter. The old question was whether the system was accurate enough for operations. The new question, often asked first, is whether the system is biometric. The two answers sit in very different regulatory worlds. Biometric identification is one of the most heavily regulated categories of processing in the Union, with prohibitions on certain uses and high-risk obligations on most of the rest. A counter that does not identify individuals sits outside the biometric category and outside most of those obligations.

This post describes where the line actually runs, using the EU AI Act and the GDPR's special-category rules as they are written, and explains what a vendor has to do to stay on the non-biometric side of it. It is the companion to our longer reading of the AI Act, the EU AI Act and people counting in 2026. If you have already read that, this post is the practical filter you can apply to any vendor on a shortlist.

This article is informational and is not legal advice. Confirm classification with your Data Protection Officer and your legal counsel before you sign anything.

What "biometric" means in EU law

Two pieces of law set the meaning. The GDPR defines biometric data in Article 4(14) as personal data resulting from specific technical processing relating to the physical, physiological, or behavioural characteristics of a natural person, which allow or confirm the unique identification of that person. Article 9(1) lists biometric data used for the purpose of uniquely identifying a natural person as a special category, which means processing is prohibited unless one of the narrow exceptions in Article 9(2) applies.

The EU AI Act layers a second test on top of this. It treats biometric identification and biometric categorisation as distinct uses, and the prohibitions in Article 5 target the most intrusive applications: real-time remote biometric identification in publicly accessible spaces for law enforcement, with limited exceptions; biometric categorisation systems that infer race, political opinions, trade union membership, religious or philosophical beliefs, sex life, or sexual orientation; emotion recognition in workplaces and education, with public-safety exceptions; and untargeted scraping of facial images for biometric databases. Article 6 then classifies most other biometric uses as high-risk, with the heavy obligations of Title III attached: risk management systems, data governance, technical documentation, logging, human oversight, conformity assessment, and post-market monitoring.

The common thread is identification. A system becomes biometric, in the regulatory sense, when it is set up to recognise or categorise an individual person from a physical or behavioural trait. A system that counts people without trying to recognise any of them is, by the same logic, not biometric. The legal definitions are precise, but the line they draw is unsurprising in practice.

The two tests a counter has to pass to be non-biometric

Out of the definitions above, two operational tests are enough to classify a counter in practice. Both must be true.

1. It does not identify individuals. The system is not designed, configured, or capable of recognising who any specific person is across visits, across cameras, or against any database. There is no unique identifier produced for a visitor and no template that could be used to identify them later.
2. It does not categorise individuals on biometric traits. The system does not infer age, gender, ethnicity, emotion, gait, or any other trait drawn from a person's body or behaviour. It treats each visitor as one count, not as a profile.

If both tests pass, the system processes no biometric data within the meaning of Article 4(14) GDPR and falls outside the biometric prohibitions and high-risk obligations of the AI Act. It may still process personal data in other ways, and Articles 5 to 32 of the GDPR still apply to whatever it does process, but the heavy biometric regime does not attach. If either test fails, the system is biometric, and the rest of the AI Act and Article 9 GDPR analysis has to be done.

What the regulated class actually looks like

The biometric class is broad and includes systems that do not always feel intuitively biometric. The clearest way to read where you sit is to list the practices that, if any one of them is present in the measurement path, make a counter biometric in the regulatory sense.

• Face recognition or face matching. Including one-to-one verification (matching a face to a known template) and one-to-many identification (matching against a database). Both produce biometric data.
• Face templates, even ephemeral ones. Storing or computing a numerical face template, even briefly in memory, is biometric processing once it is used to recognise a person across frames or visits.
• Fingerprint, iris, or palm reading. Rare in retail people counters, common in access control. Any presence of these in the same pipeline brings the deployment into the biometric class.
• Gait or body-shape recognition. Identifying or re-identifying a person from how they walk or from their body silhouette. This includes person re-identification across non-overlapping cameras based on body features.
• Voice recognition. Identifying a person from their voiceprint, which is biometric under Article 4(14).
• Emotion recognition. Inferring an emotional state (happy, angry, attentive, distracted) from facial expression, body language, or voice. The AI Act prohibits this in workplaces and education and treats it as biometric in other contexts.
• Demographic inference. Estimating age, gender, or ethnicity from camera frames is biometric categorisation. Even where presented as an aggregate marketing metric, the input is a biometric trait and the processing falls inside the AI Act's biometric categorisation provisions.

A counter that involves any of the above sits inside the biometric regime. The fact that the operator only looks at aggregate counts at the end does not change the classification, because the question is what the system processes, not what the operator chooses to display.

What sits outside the biometric class

By contrast, several measurement methods produce visitor counts without identifying anyone and without inferring biometric traits. Used on their own, they do not constitute biometric processing.

• Time-of-Flight depth counting. A ceiling-mounted sensor fires infrared pulses and measures how long they take to return, which gives the height and shape of a passing object to roughly 30 centimetres. The output is geometry, not a picture, and is not associated with any identifier. It can count a person crossing a threshold without recognising or categorising them.
• Radio signal sensing without identifier capture. Inside a building, a sensor can detect the radio signals a phone emits and triangulate position, then discard the address that came with the packet. As long as no MAC, IMEI, or advertising ID is stored and no template is built that could re-identify the device, the result is a position over time without an identifier attached.
• Stereo or mono vision counters configured for headcount only. Camera-based counters can in principle stay non-biometric if no face template is computed, no recognition takes place, and no demographic inference is performed. In practice this is fragile, because the same camera frame can later be reused for biometric processing without changing the hardware. The classification then depends on configuration, configuration controls, and audit, which is a heavier burden than a non-camera method.
• Thermal counting without identification. Low-resolution thermal sensors can count bodies without producing recognisable images of them. The classification holds as long as no thermal signature is used to identify or categorise individuals.

The pattern is clear: a counter stays non-biometric by not producing data that recognises or categorises an individual. The cleanest way to guarantee that is not to capture the data in the first place. A camera frame is hard to keep out of biometric scope once it exists, because regulators will reasonably ask what stops a later configuration change from reusing it. A measurement that never produces a face, a fingerprint, or a recognisable body silhouette removes that question.

Practical questions a vendor should be able to answer in writing

If you are evaluating a counter and you want a defensible answer to "is this biometric?", these are the questions worth putting to the vendor on paper. The wording is deliberately closed (yes or no) because biometric classification is not a question that benefits from marketing prose.

1. Does the system capture face images or face templates? If yes, it is biometric. If no, continue.
2. Does the system perform face recognition, verification, or matching? Including against an internal database, a temporary in-memory store, or a third-party identity service.
3. Does the system infer demographic attributes (age, gender, ethnicity) from any sensor input? If yes, it falls inside the AI Act's biometric categorisation provisions.
4. Does the system perform emotion recognition? If the deployment is in a workplace or an educational setting and the answer is yes, the deployment falls inside the AI Act's prohibitions.
5. Does the system re-identify individuals across cameras, zones, or visits? Including gait, body-shape, or any other behavioural template intended to track the same person across time.
6. Does the system store MAC addresses, IMEIs, advertising IDs, or other device identifiers by default? If yes, the deployment processes personal data even before any biometric question, and may build identifiers that act as proxies for the individual.
7. Is the answer to all of the above no, including across roadmapped features in the next 12 months? A vendor that intends to add face recognition in the next release is not a non-biometric vendor.

A vendor that can answer all seven with a written no is selling a non-biometric counter. Anything less, and the deployment classification has to be done at the configuration level, not the product level, and your DPO and procurement team will need to see how that configuration is enforced and audited.

Article 5 prohibitions: where the line is hardest

Some uses of biometric systems are prohibited under Article 5 of the AI Act, not merely high-risk. A people counter that captures only aggregate counts is far away from these prohibitions, but the categories are worth knowing because they are sometimes brought up in procurement reviews. The relevant prohibitions are:

• Real-time remote biometric identification in publicly accessible spaces for law enforcement, with narrowly defined exceptions.
• Biometric categorisation systems that infer race, political opinions, trade union membership, religious or philosophical beliefs, sex life, or sexual orientation.
• Emotion recognition in the workplace and in educational institutions, with limited exceptions for medical and safety reasons.
• Untargeted scraping of facial images from the internet or CCTV to build face recognition databases.

None of these is a typical retail people counter. The point of listing them is to make clear what the Act is mainly worried about: systems that recognise or categorise specific people, especially in ways that could chill rights. A camera-free, identifier-free count of how many people walked through a door is structurally a different kind of system, and the law treats it accordingly.

Edge cases that often surprise people

Three patterns commonly cause confusion in procurement. Each is worth naming explicitly.

Camera-based counting with in-camera face blur

A vendor may describe a camera that blurs faces locally inside the camera unit before any frame is transmitted. This reduces some risks but does not change the classification cleanly. The unblurred frame existed at the moment of capture, and the unit holds, at minimum, the capability to process it. Some supervisory authorities accept this as a privacy-enhancing measure; the AI Act analysis still has to consider whether the underlying processing falls inside biometric scope, and whether configuration controls prevent reuse. Treat it as a configuration question, not a product property.

Wi-Fi or Bluetooth counters that store MAC addresses

A signal-pattern counter that stores raw or hashed MAC addresses is not strictly performing biometric processing, but it is processing personal data because identifiers can be linked back to a device, and through that to a person. This is GDPR territory rather than AI Act biometric territory, but it carries its own lawfulness, consent, and minimisation burdens. The clean answer is to design the signal pipeline to discard the identifier at capture so the question never arises.

Aggregate "anonymous demographics"

A vendor may say a camera-based product produces only aggregate demographic counts (age bands, gender split) and that no individual record is kept. The aggregate output does not change the classification of the underlying processing. Inferring age and gender from camera frames is biometric categorisation within the meaning of the AI Act, regardless of how the result is later summarised. The classification follows the inputs, not the dashboard.

How Ariadne sits on the non-biometric side of the line

Ariadne is set up so that all seven of the questions in the previous section answer no, and so the deployment sits on the non-biometric side of the AI Act line by construction rather than by configuration.

Ariadne measures this with Hybrid Fusion, its patented camera-free method. Time-of-Flight depth sensing counts every visitor at the entrances, capturing geometry rather than images, while patented phone signal sensing follows movement through the interior, detecting the signals a phone emits even in airplane mode. The sensor streams both feeds to Ariadne, where Hybrid Fusion combines them into one trajectory per visit and computes counts, dwell, and paths. The streams carry no identifier: no MAC address, no device ID, no biometric data, and no camera is involved. Identifiers are stored only when a visitor explicitly opts in, which keeps the method GDPR-friendly and outside biometric territory.

Translated against the regulatory test: the system does not capture face images and does not compute face templates. It does not perform face recognition, verification, or matching. It does not infer age, gender, ethnicity, or emotion from any sensor input, and the platform does not offer this as a feature. It does not re-identify visitors across cameras, zones, or visits using gait or body shape, because there is no camera frame to build that template from. It does not store MAC addresses, IMEIs, or advertising IDs by default; the only configuration in which an identifier appears is when a visitor explicitly opts in (for example by logging into guest Wi-Fi), and the operator can simply not offer that option. None of these are roadmapped features in the next 12 months. The platform is set up to make the non-biometric answer durable, not just current.

For a deployment, the practical consequence is that the heavy biometric path in the AI Act, Title III risk management, conformity assessment, post-market monitoring, the prohibitions in Article 5, does not attach to the counting activity. Article 9 GDPR is not engaged because no biometric data is processed. The deployment still has to satisfy the ordinary GDPR obligations on whatever it does process, which is documented on the Ariadne privacy policy, and the solution overview lives on the people counting page. The measurement architecture is described in detail on how it works.

A short procurement filter you can use

If you read this post and the longer EU AI Act analysis together, the practical filter for a shortlist is short.

1. Ask each vendor the seven questions above in writing. The answers should be yes or no, not narratives. A vendor that cannot give clean answers is telling you something useful about their product.
2. Ask whether the non-biometric answer is structural or configurable. A configurable answer is fine, but the controller's DPO will have to evidence the configuration and the controls around it. A structural answer, where the hardware cannot produce a face or a fingerprint to begin with, is the easier paper trail.
3. Ask what is on the roadmap. A vendor that intends to add face recognition or demographic inference within the next 12 months will require a re-assessment, and possibly a re-tender, after that change.
4. Cross-check the classification with your DPO. The DPO writes the record. Vendor written answers are inputs to that record. The article you are reading is not a substitute for either.

FAQ

Is people counting always biometric?

No. A counter that does not identify individuals and does not categorise them on biometric traits is not biometric within the meaning of Article 4(14) GDPR or the EU AI Act. Camera-based systems can in principle stay non-biometric through configuration, but the classification then depends on what the configuration enforces and how it is audited. Methods that do not capture face images or identifiers in the first place sit outside the biometric class by construction.

Does aggregating biometric inferences into counts make the system non-biometric?

No. The AI Act and the GDPR look at what the system processes, not what is shown on a dashboard. Inferring age, gender, ethnicity, or emotion from camera frames is biometric categorisation regardless of how the output is summarised later. A vendor that calls demographic estimation "aggregate" is describing a presentation choice, not a classification.

What about systems that blur faces inside the camera before transmitting?

In-camera blurring reduces risk but does not in itself change the classification cleanly. The unblurred frame existed at the moment of capture, and the camera unit retains the capability to process it. The AI Act analysis has to consider whether the underlying processing falls inside biometric scope, and how configuration controls prevent reuse. Treat it as a configuration question rather than a structural answer.

Are MAC addresses biometric data?

No, a MAC address is not biometric data, because it is a device identifier rather than a physical or behavioural trait. It is, however, personal data under the GDPR when it can be linked to a person, and storing it brings its own lawfulness, consent, and minimisation obligations. The clean answer is to design the signal pipeline so the identifier is discarded at capture and the question never arises.

Does Ariadne use cameras?

No. Ariadne counts with Hybrid Fusion: Time-of-Flight depth sensing plus patented phone signal sensing, never cameras. Time-of-Flight captures geometry rather than images, and signal sensing captures no MAC address by default, so the measurement involves no video, no faces, and no biometric data.

Is this article legal advice?

No. This article is informational only. Confirm classification with your Data Protection Officer and your legal counsel, who will adapt the analysis to your jurisdiction, your specific configuration, and your organisation's existing compliance framework.