Two dates, six days apart.
On 27 July 2026, Regulation (EU) 2026/1744, the Digital Omnibus on AI, entered into force. It moved the AI Act’s high-risk obligations for standalone Annex III systems from 2 August 2026 to 2 December 2027. Biometric identification, biometric categorisation, emotion recognition, all of it, deferred by sixteen months.
On 2 August 2026, Article 50 started applying. It was not deferred.
Almost every summary that reached a product team covered the first date. The reason is understandable: a sixteen-month delay on conformity assessment, CE marking and registration in an EU database is a large, expensive thing not to have to do this year. The second date came with no headline, because Article 50 is four paragraphs about telling people things, and telling people things does not feel like a compliance programme.
But Article 50 is risk-independent. It does not care which tier your system sits in. And one of its four paragraphs is addressed to deployers of biometric categorisation systems, which is a category that most teams running facial age estimation have never seriously considered they might be in.
Three definitions, three answers
The mistake is not a misreading of any single provision. The mistake is assuming that “are we doing biometrics” is one question.
It is three questions, asked by three different instruments, with three different tests, and they do not line up.
| The question | The test | Facial age estimation |
|---|---|---|
| Is this special category data under GDPR Article 9? | Is the processing for the purpose of uniquely identifying a person (Article 4(14))? | Probably not |
| Is this a biometric categorisation system under AI Act Article 3(40)? | Does it assign people to categories on the basis of biometric data, and is it not merely ancillary? | Almost certainly yes |
| Is this high-risk under AI Act Annex III? | Does it categorise by a sensitive or protected attribute? | Probably not, and deferred to December 2027 anyway |
Most legal teams have answered question one. It is the question the UK’s Information Commissioner’s Office worked through, and the question that produced the industry’s comfortable position: facial age estimation that never matches a face against a stored template is not uniquely identifying anyone, so Article 9 does not bite.
It is worth being precise about what the EDPB did and did not add here, because the statement gets cited in both directions. Statement 1/2025 on age assurance, adopted on 11 February 2025, is ten pages of GDPR principles: proportionality, data minimisation, data protection by design, security, accountability. It does not leave the Article 4(14) question open. It does not address it. Biometric data appears once, in passing, in a list of examples. Anyone citing it as support for either answer is citing a document that never engaged with the question.
That position is defensible. We have written about the case where it stops being defensible, which is the moment you store a template and match against it. Estimation without matching is a different animal from binding, and the distinction is real.
The problem is that answering question one feels like answering all three. It isn’t. The answer to question one was reached by relying on four words in the GDPR that the AI Act deliberately left out.
The four missing words
GDPR Article 4(14) defines biometric data as personal data resulting from specific technical processing relating to physical, physiological or behavioural characteristics, “which allow or confirm the unique identification of that natural person”.
AI Act Article 3(34) defines biometric data as personal data resulting from specific technical processing relating to the physical, physiological or behavioural characteristics of a natural person, such as facial images or dactyloscopic data.
Read them next to each other. The qualifying clause is gone.
Be careful with that observation, because it cuts both ways and the honest reading needs both halves. Recital 14 says the AI Act notion “should be interpreted in light of” the GDPR definition, which is the hook for an argument that the two are meant to be read together and the omission carries no weight. That argument exists and it is not stupid.
But the same recital continues: biometric data “can allow for the authentication, identification or categorisation of natural persons and for the recognition of emotions of natural persons”. Categorisation is named as a separate thing from identification, in the same sentence. A reading in which the AI Act definition silently carries the GDPR’s unique-identification requirement has to explain why the drafters then listed categorisation as a distinct capability, and why they wrote a whole definition of a biometric categorisation system that never mentions identifying anyone.
So the argument that gets you out of Article 9 is the argument that your system does not uniquely identify. Applied to the AI Act, that argument is at best incomplete and quite possibly not responsive to the question being asked. This is an interpretive dispute rather than settled law, and you should treat anyone who tells you otherwise with suspicion in either direction. What you should not do is assume that having answered the GDPR question you have answered this one, because they are not the same question and the textual difference between them is right there on the page.
Then Article 3(40) defines a biometric categorisation system as an AI system for the purpose of assigning natural persons to specific categories on the basis of their biometric data. Recital 16 says those categories “can relate to” aspects such as “sex, age, hair colour, eye colour, tattoos, behavioural or personality traits, language, religion, membership of a national minority, sexual or political orientation.”
Age is on the list. It is the second item.
The list is illustrative rather than closed, and it sits in a recital rather than in the operative text, so it does not settle anything by itself. What it does do is make it very hard to argue that the legislator had not thought about age when writing the definition.
The carve-out, and why your age gate is not in it
Article 3(40) has an exception. A system is not a biometric categorisation system if the categorisation is “ancillary to another commercial service and strictly necessary for objective technical reasons”.
This is the clause every vendor will point at, so it is worth reading what the Regulation says it means rather than what it sounds like.
Recital 16 gives two examples, and hedges both with “could constitute” rather than “constitutes”, so neither is a safe harbour. The first is a filter on an online marketplace that categorises facial or body features so a shopper can preview a product on themselves. The second is a face filter on a social network that lets users modify their own pictures. In both cases the test is the same: the feature cannot, for objective technical reasons, be used without the principal service, and it is intrinsically linked to that service.
A lipstick try-on filter is ancillary to selling lipstick. It is not a product on its own. Nobody opens it for its own sake.
An age gate is not that. An age gate is a control that stands between a user and the service, and its whole function is to produce a categorisation and act on it. It is not a feature of the principal service. It is a precondition of reaching the principal service. If you removed the age check, the service would still work; you would simply be non-compliant with something else.
Recital 16 also closes the obvious move: the carve-out does not apply where the integration of the feature “is a means to circumvent the applicability of the rules of this Regulation”.
Be honest about the confidence level here. Nobody has litigated this. A market surveillance authority has not published a decision on whether a signup-flow age estimator is ancillary, and a competent lawyer could construct the opposite argument, particularly for a platform where the age check is genuinely inseparable from account creation. What we can say is that the two examples the legislator chose both point the other way, and that “our age gate is an ancillary feature” is a position you should write down, date, and be prepared to defend, rather than a position you should assume by default because nobody asked.
If your answer to a regulator is going to be the carve-out, the time to draft that memo is before the question arrives, not after.
What you actually owe, and who owes it
Article 50(3) is one sentence of obligation. Deployers of a biometric categorisation system shall inform the natural persons exposed to it of the operation of the system.
Two details in that sentence matter more than the sentence itself.
It binds the deployer. Article 3(4) defines a deployer as the person using the AI system under its own authority. That is you, the platform. It is not your age assurance vendor, who is the provider. This is the part that surprises teams, because most compliance work in age assurance has been pushed down into vendor contracts and data processing agreements, and this one cannot be. Your vendor can help you draft the notice. Your vendor cannot discharge the duty, and no clause in a DPA moves it.
It has a deadline inside the user session. Article 50(5) requires the information to be given in a clear and distinguishable manner “at the latest at the time of the first interaction or exposure”, and to conform to applicable accessibility requirements.
At the latest at first exposure. Not in the privacy policy. Not on the cookie banner. Not in a help centre article that the user could in principle find. Before the camera turns on.
Look at your own flow and ask where that notice would go. In most age gates we have seen, the screen before the camera permission prompt says something close to “Verify your age” and a button. There is no statement that an AI system will estimate an age from the image, and quite often the word “AI” does not appear anywhere in the flow. The accessibility requirement compounds it: a notice that only exists as text inside a video frame, or that is announced after the camera is already streaming, does not meet the standard. We wrote about the wider accessibility problem in age verification separately, and Article 50(5) turns part of that from good practice into a legal requirement.
The price of getting this wrong is set by Article 99(4): up to €15,000,000, or 3% of total worldwide annual turnover for the preceding financial year, whichever is higher. For small and medium businesses including start-ups, it is the lower of the two rather than the higher. Penalties for this tier have been enforceable since 2 August 2025, and enforcement sits with national market surveillance authorities rather than with a single central body.
That last point is worth sitting with. The disclosure duty is the cheapest obligation in the Regulation to satisfy and one of the easiest to check from the outside. A regulator does not need an investigation, a document request, or access to your infrastructure to find out whether your age gate tells users what it is doing. They need a phone.
Four questions your pipeline answers, not your policy
Here is the part that makes this an engineering post rather than a legal one.
Whether you are running a biometric categorisation system is not settled by what your terms of service call the feature. It is settled by what the code computes and what the storage keeps. Four questions decide it, and in our experience most teams cannot answer more than two of them without calling their vendor.
1. Does the model produce an embedding on the way to the number?
Many facial age estimators are a face encoder followed by a small regression head. The encoder emits a vector that is, by construction, a compact representation of that person’s face. If that vector exists in memory, it existed. If it is written to a queue, a cache, a log line, or a debugging artefact, you are holding something much closer to a biometric template than to an age bracket, and the comfortable Article 9 story gets considerably harder to tell.
Ask for the inference graph, not the marketing page. “We do not store biometric data” and “our pipeline never materialises an embedding” are different claims, and only the second one is checkable.
2. Where does inference run, and who is the deployer?
Running the model on the device is the right architecture for several reasons, and it changes what crosses the network. It does not remove the Article 50(3) duty. The obligation is about informing the person, not about where the matrix multiplication happens. A local model that never uploads a frame still assigns a person to a category on the basis of their biometric data, and the person in front of it is still entitled to be told.
On-device does help with a different question, which is who counts as the deployer when a third-party SDK runs inside your app under your brand. The answer is almost always still you.
3. Is the age head the only head?
This is the one that should worry you most, and it is the one almost nobody checks.
Face models are frequently multi-task. A single backbone trained on a large face corpus will often carry heads for age, for perceived gender, sometimes for expression, occasionally for attributes nobody should be predicting at all. Product teams say “we only read the age output”, and that is true as a statement about their application code. It is not a statement about the model.
It matters because Article 5 sits above all of this. Article 5(1)(g) prohibits biometric categorisation systems that categorise natural persons individually to deduce or infer race, political opinions, trade union membership, religious or philosophical beliefs, sex life or sexual orientation. The prohibition applied from 2 February 2025, though the penalty regime in Article 99 only started applying on 2 August 2025, so there were six months of a ban with no fine attached to it. Since then it has carried the top tier: up to €35,000,000 or 7% of worldwide turnover. Unlike the high-risk rules, it was never deferred.
Read the actual scope rather than the headline. The prohibition turns on categorising people individually, and it expressly does not cover labelling or filtering of lawfully acquired biometric datasets, or categorisation in the law enforcement context. It is not a blanket ban on a model that can compute those attributes. It is a ban on running one against individual users to infer those things about them.
That distinction is exactly why the multi-head question matters. A backbone with an unused head is not automatically a prohibited practice. A backbone with an unused head is a system where the gap between “what we call this feature” and “what this code does to each user” is wide enough that nobody in the company can tell you which side of the line you are on. The defence you want is not “we ignored that output”. It is that the output does not exist. Those are different systems, and only one of them is easy to explain to a regulator.
Ask your vendor for the output schema of the model, in writing, with every field listed. Not the API response you happen to consume. The model’s outputs. A vendor who will not put that in writing has told you something, and it is not a good something.
4. What lands in your logs?
An age decision is small: over 18, checked on this date, by this method, at this confidence, with this policy version. That record is boring, auditable, and nearly worthless to an attacker.
A face crop, a confidence vector, and a raw frame kept “for model improvement” is a different object with a different breach profile. We ran the arithmetic on what retention does to breach size after the IDScan disclosure in September, and the conclusion holds here: the size of the incident is the size of the store, and the size of the store is a product decision made long before any attacker shows up.
Article 50(3) has a tail on it that is easy to miss. It requires the deployer to inform the person and to process the personal data in accordance with the GDPR. The disclosure obligation and the data protection obligation arrive in the same sentence.
What to do before the end of the quarter
Six things, roughly in order of how quickly they can be done.
-
Write the notice. One or two plain sentences, on the screen before the camera permission prompt, in the same language as the rest of the flow. Say that an automated system will estimate an age range from the image, say whether the image is kept, and say what the alternative is. This is an afternoon of work.
-
Check the alternative exists and is named in the same place. If a user can reach the same outcome without a face scan, that route belongs in the notice, not three screens later. If no alternative exists, that is a separate problem worth solving on its own merits.
-
Get the model output schema from your vendor in writing. Every head, every field. Set a date by which you expect it.
-
Write down your Article 3(40) position. Either you are deploying a biometric categorisation system and complying with Article 50(3), or you are relying on the ancillary carve-out. Pick one, put the reasoning in a document, date it, and have someone senior sign it. An undocumented position is not a position.
-
Cut the pipeline back to the decision. If your logs, error monitoring, or session replay contain frames or embeddings from the verification flow, that is work that pays for itself regardless of how the AI Act questions land.
-
Put 2 December 2027 in the calendar. The Commission’s draft guidelines of 19 May 2026 take the view that assigning age or gender from biometrics for age assurance purposes falls outside the high-risk rules, on the basis that those characteristics are not covered by Article 9(1) GDPR. Three caveats travel with that, and they matter more than the headline. It is draft guidance, issued for a consultation that ran to 23 July 2026 after a four-week extension, with a final version expected around the end of 2026. It concerns a classification regime that does not start applying for another fifteen months. And most importantly, “not high-risk” is not “not regulated”: it is a narrow point about Annex III classification, and it leaves Article 50(3), Article 5 and the GDPR exactly where they were. Deferred is not cancelled, draft is not final, and out of one chapter is not out of the Regulation.
The shape of the mistake
There is a pattern here that goes beyond this one Regulation.
The expensive obligation moved and the cheap one arrived, and the industry’s attention followed the money. Sixteen months of relief on conformity assessment is a real, material thing, and it was reported as such. A requirement to add a sentence to a screen is not a story, so it was not a story.
But the compliance exposure does not scale with the cost of the remedy. It scales with how visible the gap is and how easy it is to find. Nobody is going to discover your incomplete technical documentation by loading your signup page. Anyone can discover that your age gate opens a camera without telling the user what the camera is for.
The other half of the pattern is definitional. Three instruments asked overlapping questions about the same face scan, and a team that had genuinely done the work on one of them reasonably concluded it had done the work. That is not negligence. It is what happens when the definitions in adjacent laws differ by four words and nobody is assigned to notice.
How Xident approaches this
Xident splits its operations into two types, and the split exists partly for this reason.
A Check is a decision. A browser age check, a liveness step, a lookup of a returning user’s Xident ID, an OAuth confirmation. It returns a bracket and a confidence, and the record it leaves behind is the decision rather than the raw capture.
A Verification is a document path: OCR and a face match against the document. It is the expensive operation, and it is the one that creates the strongest data, so it is the one to reach for last rather than first. Our orchestration post covers how to sequence the two so that most users never reach the document step.
For teams working through Article 50, three things follow from that design. The decision record is what persists, not the frame. The model’s output schema is documented rather than described. And because the estimator is one layer in a waterfall rather than the only door, the notice you have to write can honestly name an alternative, which is the difference between a disclosure that reads as a warning and one that reads as a choice.
The free sandbox includes 1,000 Checks and 100 Verifications as a one-time grant, which is enough to instrument a full flow and look at exactly what your own logs end up holding before you commit to anything.
If you are running facial age estimation into the EU today, the useful next step is not a legal memo. It is opening your own signup flow on a phone, in a language you do not speak, and asking whether a user would have any idea what just happened to their face.
