Facial age estimation & age assurance

Regulators now expect online platforms to keep minors out of adult content, gambling, social media and harmful features, and retailers must not sell alcohol or tobacco to minors. Facial age estimation predicts an age from a face image, compares it to a threshold plus a safety buffer, returns only "over / under", and deletes the image immediately. It is a low-friction first layer; uncertain cases fall back to an ID check or a privacy-preserving digital credential.

Problem & value

• Today: online services use self-declared birthdates (trivially bypassed), card checks or ID-document upload (friction, privacy-heavy, drop-off). Retail relies on staff judgement ("Challenge 25" in the UK) and manual approval at self-checkouts, which creates queues and staff conflict.
• AI value: a result in seconds without handing over an identity document, no account or name needed, consistent decisions across staff and shifts, and a measurable false-accept rate per age band.
• Regulatory driver: DSA Art. 28 and the Commission's guidelines on protection of minors (2025) treat age assurance as an appropriate measure for high-risk content; the EU age-verification blueprint app and the planned EUDI Wallet are the privacy-preserving credential route; the UK Online Safety Act and Ofcom guidance require "highly effective age assurance", explicitly naming facial age estimation as an accepted method; Germany's JMStV/KJM has approved age-verification concepts for years [1][2][3].
• Benefit figures: vendors publish mean absolute error (MAE) values and independent evaluation exists (NIST FATE); error varies strongly by age band, sex and skin tone, so compare the numbers on the threshold band only (for example 13-17 vs. 18+) rather than headline MAE [4][5].

Variants

• Online age-gating (DSA Art. 28 / EU blueprint): selfie in browser or app via SDK or redirect; platforms for adult content, social media, gaming, gambling, dating; result token returned to the service.
• Retail self-checkout & vending: camera at the kiosk checks the shopper when an age-restricted item is scanned; failure triggers a staff override or ID scan. Also fuel stations, cigarette and alcohol vending, online alcohol delivery (check at door via app).
• Device / OS level and app stores: age signal shared with apps (age range only).
• Account-based reuse: a "reusable age token" issued once and presented elsewhere (blueprint style).
• Private use: parental-control setup and child-safe modes on family devices; no separate use case.

How it works

1. trigger (age-restricted item scanned / adult page requested)
2. capture (selfie or kiosk frame; on-device or browser SDK)
3. face detection + quality check (pose, blur, light, one face only)
4. liveness / presentation-attack detection (screen replay, mask, injection attack)
5. age regression/classification model
6. estimated age + uncertainty
7. decision: estimate >= threshold + buffer
8. PASS estimate < threshold
9. FAIL in buffer zone / low quality
10. FALLBACK (ID check, wallet proof, staff)
11. return only over/under token; delete image immediately; log result without image

• Model: a CNN or vision-transformer regression head trained on large face datasets with verified ages; output is calibrated per age band. A "buffer" (for example estimate must exceed 25 for an 18+ gate, a design choice per risk appetite) trades false accepts against fallbacks.
• No identification: no gallery search and no stored template; this is what separates it from VIS-016. Document authenticity checks sit in ANOM-014.
• Human in the loop: staff override at retail, appeal route online (ID or wallet), regular audit of borderline cases and demographic error rates.

Data preparation

This use case needs almost no historical data: the input is a live selfie or camera frame that is processed and deleted at once. Preparation is mostly configuration and test data. Decide the legal age threshold and the safety buffer per product (e.g. alcohol, tobacco, gambling, adult content), and document them in the shop system, ERP or policy file where the rules for age-restricted articles already live.

Typical gaps: article master data without an "age-restricted" flag, no defined fallback when the estimate is uncertain (staff ID check, document check, wallet proof), and unclear retention of logs. Preparation steps: flag restricted articles in the ERP or shop, define the fallback process, and set logging to store only the decision, never the image. Collect a small test set of consenting staff volunteers across age groups, skin tones and lighting conditions to check accuracy and bias at your own counters or in your own web flow.

Effort share: roughly 10-15 percent of the project; most work is process and legal design, not data. For related groundwork see PREP-024 (rules for what may enter which AI tool), PREP-025 (purpose and legal-basis check) and PREP-018 (building evaluation sets).

Implementation paths

Which path for whom

• smb: A - certified age-estimation services are mature, EU-hostable and priced per check, and the process (over/under gate) is standard.
• enterprise: A - age gating is a commodity compliance function; a certified provider also carries the testing and audit burden.
• developer: B - integrate a vendor or cloud API into your own app or checkout flow and keep the fallback logic (ID check, wallet proof) under your control.
• public: B - integrate on EU-hosted APIs or national age-verification apps; self-hosting is rarely worth it and only certified products suit regulated duties.

Path A — Buy (recommended)

• Specialist age-assurance providers: Yoti (UK, widely used in UK/EU retail and platforms), Privately (CH), k-ID (age-signal platform for games), AgeChecked, VerifyMy (UK), Veriff, Persona, Incode, Entrust/Onfido, Idemia Public Security (FR, EU), Signicat (NO/EU), IDnow (DE, EU), AU10TIX. Many offer facial age estimation plus document and wallet fallback in one SDK.
• Retail: vendors integrate with NCR Voyix, Diebold Nixdorf (DE, EU) and Toshiba self-checkout stacks, or stand-alone kiosks and vending-machine modules.
• Check: independent evaluation (NIST FATE, ISO/IEC 30107-3 liveness testing via accredited lab, conformity to ISO/IEC 27566-1 and IEEE 2089.1), EU data residency, deletion of images in seconds, no template retention, subprocessor list, accuracy per age band and skin tone, DPIA support [5][6].
• Choose A when: you need compliance quickly and cannot run a biometrics evaluation programme.

Path B — Build on cloud APIs

• General vision APIs are poor fit: most hyperscaler face APIs removed or restricted age and attribute inference (Microsoft restricted it in Azure Face), so use specialist age-estimation APIs from Path A vendors or process on the device.
• Orchestration: policy engine for thresholds per product, fallback to EUDI/blueprint verification, token issuing (signed, short-lived, claim "age_over_18"), and logging without images.
• EU Digital Identity Wallet / blueprint: the open-source reference implementation supports zero-knowledge or selective-disclosure proofs of "over 18" and should be the preferred second factor [2].

Path C — Self-host (open source)

• Models: MiVOLO (face and body age estimation), InsightFace attribute models, DEX-style regressors, and face detection such as RetinaFace or YuNet; liveness via Silent-Face-Anti-Spoofing or similar. Run through ONNX Runtime, OpenVINO or TensorRT.
• Datasets: public sets like UTKFace, FairFace, Adience, MORPH, AgeDB and IMDB-WIKI have noisy labels and licensing limits; check licences before commercial use.
• Hardware: HW1 suffices (CPU or small edge GPU, Jetson Orin Nano) because models are small; keep inference at the kiosk so no image leaves the device.
• Caution: liveness and injection-attack defence is the hard part; open-source alone rarely reaches the assurance level regulators accept (for example Ofcom "highly effective").

Path D — Custom training

Worth it only for vendors of age assurance or very large platforms. Needs tens of thousands of face images with verified dates of birth, consent and DPIA, balanced across age, sex and skin tone, with a hold-out set concentrated at the legal threshold. Evaluate on the threshold band, not overall MAE.

State of the art (2026)

• NIST's ongoing FATE Age Estimation & Verification evaluation benchmarks commercial algorithms and reports accuracy by age, sex and region; the best algorithms are accurate to within a couple of years on average but errors grow near thresholds and for some demographic groups [5].
• Standards matured: ISO/IEC 27566-1 (age assurance systems framework) and IEEE 2089.1 define terms and test metrics; PAS 1296 (UK) preceded them [6].
• Regulators moved from "age estimation is allowed" to "state the false-accept rate, test for bias, and offer alternatives" (Ofcom, CNIL, European Commission guidelines, Australian Age Assurance Technology Trial).
• Privacy-preserving credentials (EU blueprint app, EUDI Wallet, double-blind "age tokens") compete with face estimation and are expected to become the default for high-risk services; estimation remains the low-friction fallback.
• Limits and failure modes: error near the threshold (for example 16-20 year olds), bias across skin tones and by sex, makeup, lighting and glasses, attacks with printouts, screens, deepfakes or camera injection, and children passing as adults. Never use estimation as the only barrier for high-risk goods.

Shared resources & combinations

• Same stack (face-biometrics + liveness + edge-runtime): VIS-016 face recognition (do not share templates or galleries), ANOM-014 document and liveness checks, VIS-017 checkout-free retail cameras.
• Combination: VIS-027 content moderation (what is age-gated), VIS-008 people counting (anonymous analytics at the same cameras, separate purpose), and VIS-030 anonymisation of any retained footage.

Effort, cost & KPIs

• Path A: days to weeks for SDK integration; pricing is typically per check (volume tiered).
• Path B: 1-3 months to build policy, fallback and token layers around a vendor.
• Path C: 3-6 months, mostly liveness hardening, evaluation and DPIA; low hardware cost.
• Cost drivers: per-check fees, fallback ID checks, kiosk hardware, bias testing, support for appeals.
• KPIs: false-accept rate (minors passed) and false-reject rate at the threshold band, fallback rate, drop-off rate versus ID upload, time per check, share of attacks detected, staff override rate, complaints.

People & change

Start with management and the department lead (retail, platform or compliance) to set the legal age thresholds and accept the residual error rate. Involve IT early for camera, kiosk and checkout integration, and the data protection officer and legal/compliance before any pilot: face images are biometric-adjacent data, so run a DPIA (Art. 35 GDPR), conclude an AVV (Art. 28 GDPR) with the provider and publish clear customer information.

Works council: depends. Pure customer-facing checks usually do not monitor staff, but point-of-sale cameras that also capture cashiers, or logs showing which employee handled which check, can fall under co-determination (section 87(1) no. 6 BetrVG, where objective suitability for monitoring suffices). Inform the council in good time (section 90(1) no. 3 BetrVG) and agree that no staff performance evaluation is derived. Public bodies involve the staff council.

AI literacy: support staff with short training on what the estimate means, the buffer, and the manual fallback (Art. 4 AI Act). Communicate openly to customers that no identification takes place. Pilot in one shop, kiosk or web flow and keep humans in control: staff can always override and ask for ID, and customers must have a non-biometric alternative.

Guides: GUIDE-005, GUIDE-004, GUIDE-006.

Risks, regulation & compliance

• EU AI Act: classification depends on set-up. Age estimation is not itself listed in Annex III and is not "remote biometric identification". It may count as biometric categorisation (Art. 3(40)) but only inference of the Art. 5(1)(g) sensitive attributes (race, political opinion, etc.) is prohibited, and age is not among them; emotion inference from faces at work or school is prohibited (Art. 5(1)(f)) and must not be added. Do not use estimation to infer other traits. Transparency duties may apply (Art. 50(3)) when biometric categorisation is used; seek legal review, and treat as limited or minimal in typical deployments [7].
• GDPR: a face image is personal data; whether it is Art. 9 "biometric data" depends on whether it is processed to uniquely identify; vendors argue not, but a DPIA is advisable. Use explicit consent or legitimate interest with a non-biometric alternative; data minimisation: process on device, delete immediately, no template, no re-use for training without consent. Children's data triggers Art. 8 and Recital 38 care.
• DSA / sector: DSA Art. 28 and Commission guidelines (proportionate, accurate, reliable, robust, non-intrusive and non-discriminatory age assurance); German JuSchG/JMStV with KJM approval; UK Online Safety Act; national alcohol and tobacco sales laws (Germany: JuSchG, 18+ for spirits, 16+ beer/wine).
• Risks: discrimination (error disparities), false sense of security, attacks, function creep into identification or marketing, reduced access for people without cameras. Mitigations: equal alternatives, bias audits, on-device processing, short retention, staff training, published accuracy.

Getting started

1. Define legal thresholds per product or service and the risk appetite (buffer, fallback rate).
2. Run a DPIA and decide the lawful basis, including a non-biometric alternative route.
3. Shortlist 2-3 vendors with independent test results; request error rates at your threshold band.
4. Pilot at one store or one flow, compare false accepts with a staff-checked sample, track drop-off.
5. Add the EU blueprint or EUDI Wallet route as fallback and review the policy twice a year.

Sources

1. European Commission - Guidelines on the protection of minors online under the DSA - https://digital-strategy.ec.europa.eu/en/policies/guidelines-protection-minors
2. European Commission - EU age verification blueprint - https://digital-strategy.ec.europa.eu/en/policies/eu-age-verification
3. Ofcom - Age assurance guidance under the Online Safety Act - https://www.ofcom.org.uk/online-safety/protecting-children/age-assurance
4. Yoti - Facial age estimation - https://www.yoti.com/business/facial-age-estimation/
5. NIST - Face Analysis Technology Evaluation (FATE) Age Estimation & Verification - https://pages.nist.gov/frvt/html/frvt_age_estimation.html
6. ISO/IEC 27566-1:2025 Age assurance systems - https://www.iso.org/standard/88143.html
7. Regulation (EU) 2024/1689 (AI Act) - https://eur-lex.europa.eu/eli/reg/2024/1689/oj
8. MiVOLO age and gender estimation - https://github.com/WildChlamydia/MiVOLO
9. EU Digital Identity Wallet age verification reference implementation - https://github.com/eu-digital-identity-wallet