EU AI Act compliance for biometrics: the audit trail for remote identification, categorisation, and emotion recognition

By Catalina Turlea·
EU AI Act compliance for biometrics: the audit trail for remote identification, categorisation, and emotion recognition

Written by Catalina Turlea

25 Apr 2026

Biometric AI is the highest-scrutiny category in the EU AI Act. Annex III, point 1 makes three things high-risk: remote biometric identification systems, biometric categorisation by sensitive or protected attributes (race, political opinion, trade union membership, religion, sex life, sexual orientation), and emotion-recognition systems.

A handful of biometric uses are prohibited outright. Article 5 outlawed emotion-recognition in workplaces and educational institutions and untargeted scraping of facial images for face-recognition databases. The fine for crossing that line reaches €35 million or 7% of worldwide annual turnover. Whichever is higher.

If your product touches biometrics in any of the surviving allowed categories, the audit trail is not optional. It is the product.

The biometric obligations stack up fast

Biometric AI is one of the few Annex III categories where providers cannot opt for purely internal conformity assessment. Article 43 requires either internal control plus the relevant Annex VII checks or notified-body involvement. Either way, the file you have to produce gets thicker:

  • - Article 11 + Annex IV — technical documentation including data sources, accuracy by demographic, the explicit basis for the chosen confidence threshold, and the human-oversight measures.
  • - Article 12 + Article 26(6) — logs that include, at minimum for remote biometric identification, "the period of each use of the system," "the reference database against which input data has been checked by the system," "the input data for which the search has led to a match," and "the identification of the natural persons involved in the verification of the results."
  • - Article 13 — instructions for use with the accuracy, robustness, and cybersecurity metrics; foreseeable circumstances of risk; demographic performance breakdowns.
  • - Article 14 — for remote biometric identification, "no action or decision shall be taken by the deployer on the basis of the identification resulting from the system unless that identification has been separately verified and confirmed by at least two natural persons."
  • - Article 19 — minimum six-month retention; longer where data-protection or national law requires.
  • - Article 72 — post-market monitoring across the lifecycle.
  • - Article 73 — serious-incident reporting in 15 days, 10 if there is widespread fundamental-rights infringement, 2 if critical infrastructure is seriously disrupted.

Anyone deploying biometric AI also has to register the system in the EU database under Article 49 and complete the Fundamental Rights Impact Assessment under Article 27 before first use.

That is the audit trail. Skip a piece and you have skipped compliance.

Why "the model said it's a match" is the wrong sentence

Biometric AI fails in ways that observability cannot catch.

A face is matched. The HTTP status is 200. The confidence score is 0.91. The logs are clean. The match is wrong, and the demographic against which it is wrong is the one where the training data was thinnest. That mistake does not surface in a Slack thread. It surfaces as a regulator's letter and an Article 27 review of the Fundamental Rights Impact Assessment that nobody filed.

The Act anticipates this. It demands that the system's accuracy be documented by sub-group, that two natural persons separately verify a match before any decision is taken, that the deployer keep the logs, and that a serious incident be reported within days. Every one of those obligations exists because biometric AI is exactly the place where models look like they work and quietly do not.

The villain is Ship and Pray. Three good demos, a vendor pilot, a signed contract, a system live in an airport or a building lobby. The model has not been evaluated on the demographic distribution it will see in production. The two-person verification workflow is a sentence in the instructions-for-use, not an enforced workflow. The logs do not include the reference database. The audit trail is a folder of screenshots.

A regulator will reject that product. In biometrics, customers will reject it too. Enterprise and public-sector buyers in Europe will write Annex IV technical documentation requirements into procurement. You either provide it or you do not win.

The biometric audit-trail checklist

For each biometric AI feature, you should be able to produce:

  1. - Annex IV technical documentation — including the dataset's demographic composition, accuracy at the chosen threshold across each demographic, and the rationale for the threshold.
  2. - Versioned model, prompt, and threshold configurations — every change captured with date, author, and the evaluation that justified the change.
  3. - Pre-deployment evaluation reports — signed off by a domain expert who is empowered to refuse to ship.
  4. - Article 12 runtime logs — for remote biometric identification, with the period of use, the reference database, the input that matched, and the identity of the verifying persons.
  5. - Two-person verification records — for every decision taken based on a remote biometric identification, the identity of both verifiers.
  6. - Human oversight records under Article 14 — the deciders, their training, their authority to reject or override.
  7. - Post-market monitoring data — periodic re-evaluation, drift detection, demographic-performance tracking.
  8. - Serious-incident register under Article 73.
  9. - EU database registration entry under Article 49 and the Fundamental Rights Impact Assessment under Article 27.

If any one of those is missing, the system is not compliant.

Where domain experts come in

Article 14 requires human oversight by people with the competence to provide it. In biometrics, that means privacy specialists, identity-verification experts, civil-liberties advisors, and operations staff trained on the specific deployment context.

None of them touch the evaluation interface. The eval set is a notebook. The thresholds are decided in an engineering planning meeting. The two-person verification workflow lives in PDF instructions and not in the product. The audit trail is whatever can be reconstructed from screenshots after an incident.

Lovelaice exists for this gap. The privacy or identity expert defines what acceptable looks like before the model sees any data — demographic accuracy thresholds, false-match rate floors, confidence-band rules, refusal criteria. They evaluate outputs through a simple interface, with blind review to remove bias from the scoring. Every evaluation is captured. Every prompt and threshold version is immutable. Every result is exportable.

When the supervisory authority asks for the demographic breakdown of false matches at the current threshold, you do not say "we'll get back to you." You export the run.

Retention and reporting windows to design for

  • - Prohibited practices under Article 5 are already in force. Emotion-recognition in workplaces and schools, untargeted facial-image scraping, and certain biometric categorisations cannot be deployed at all.
  • - Six months minimum log retention. Longer where GDPR, law-enforcement, or national rules require.
  • - Ten years retention of Annex IV technical documentation and the EU declaration of conformity.
  • - 2 days to report a serious incident if it seriously disrupts critical infrastructure. 10 days if a person dies or a fundamental-rights infringement is widespread. 15 days otherwise.

Biometrics is where the AI Act expects the most documentation and the least improvisation. Speed without proof is a fine measured in tens of millions. Build the audit trail before the model goes anywhere near a real face.

Sources

More in this series

The EU AI Act audit-trail series — one article per Annex III high-risk category: