Compliance·7 min read

GDPR and biometric data: what developers need to know

Facial images from which identity can be derived are special category data under GDPR Article 9. Here's what that means in practice for teams integrating face AI APIs.

ShareX / TwitterWhatsApp

If your application processes facial images — for KYC, access control, content moderation, or any other purpose — you are almost certainly processing special category data under the EU General Data Protection Regulation. The compliance obligations are more demanding than for ordinary personal data, and the penalties for getting it wrong are proportionally severe.

This post is aimed at developers and technical leads integrating face AI APIs. It's not legal advice — you should work with a qualified DPO or privacy counsel for your specific situation — but it covers the practical landscape clearly.

What counts as biometric data under GDPR?

Article 4(14) defines biometric data 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 natural person."

This covers:

  • Facial images that are processed to extract identity information (not just stored as photos)
  • Face embeddings (numerical vectors derived from a face image)
  • Liveness scores, similarity scores, and other biometric-derived outputs tied to an individual

A photo stored in a gallery app is not necessarily biometric data. A photo submitted to a face recognition API that generates an embedding used for identification — that's biometric data, and Article 9 applies.

The lawful bases under Article 9(2)

Processing biometric data is prohibited by default. You need an explicit lawful basis from the narrower list in Article 9(2). The most relevant for commercial applications are:

  • Explicit consent (Art. 9(2)(a)) — the data subject has given explicit consent to the processing of their biometric data for one or more specified purposes. This is the most common basis for consumer apps.
  • Substantial public interest (Art. 9(2)(g)) — used by some financial institutions for AML/fraud prevention, subject to national law implementation.
  • Vital interests (Art. 9(2)(c)) — rarely applicable in commercial contexts.

Note that consent under Article 9 must be "explicit" — ticking a general terms checkbox is not sufficient. You need a specific, affirmative consent action for the biometric processing specifically.

Data minimisation and zero retention

Article 5(1)(c) requires that personal data be "adequate, relevant and limited to what is necessary." For biometric processing, this principle argues strongly for zero-retention architectures: process the image, extract the necessary output, and discard the image immediately.

This is exactly how Quantilence works. Images submitted to our API are processed in-memory and never written to disk. The only output we return is the API response — a score, verdict, or annotated image. We do not build biometric databases from API submissions.

If your own system needs to persist a face embedding for ongoing recognition (e.g., employee access control), the embedding itself is biometric data and must be handled accordingly — encrypted at rest, access-controlled, subject to the full Art. 9 regime.

When do you need a DPIA?

A Data Protection Impact Assessment (DPIA) is required under Article 35 when processing "is likely to result in a high risk to the rights and freedoms of natural persons." Processing biometric data at scale almost always requires a DPIA. Specifically required when:

  • Systematic and extensive evaluation of personal aspects based on automated processing
  • Large-scale processing of special category data (Art. 9)
  • Systematic monitoring of a publicly accessible area

For a KYC integration processing thousands of selfies per day, a DPIA is not optional — it's required. The DPIA should document the purpose, necessity, proportionality, risks, and mitigations. Your DPO must be consulted.

Controller vs processor — what role are you in?

GDPR controller vs processor relationship for biometric API integrations
GDPR controller vs processor relationship for biometric API integrations

If you're using a face AI API:

  • You are the controller — you determine the purpose and means of processing your users' biometric data. You are responsible for the lawful basis, transparency, and data subject rights.
  • The API provider is a processor — they process the data on your instructions. They must have appropriate security controls and a Data Processing Agreement (DPA) in place with you.

Always request and sign a DPA with any face AI provider before sending personal data to their API. At Quantilence, DPAs are available to all paid customers — contact our team to request one.

Penalties for getting it wrong

Article 83(4) GDPR sets fines for Art. 9 violations at up to €10M or 2% of global annual turnover, whichever is higher. Supervisory authorities have issued substantial fines for unlawful biometric processing: Clearview AI received fines across multiple EU jurisdictions; Italian DPA fined an employer €50K for implementing facial recognition time-tracking without a valid Art. 9 basis. These are not theoretical risks.

Practical checklist

  • Obtain explicit, specific consent from individuals before submitting their facial images to an API
  • Document your lawful basis under Art. 9(2) in your Record of Processing Activities (RoPA)
  • Conduct a DPIA for large-scale or high-risk biometric processing
  • Sign a DPA with your face AI API provider
  • Use a zero-retention API provider — don't send images to vendors who store them without necessity
  • Implement data subject rights workflows: access, rectification, erasure, portability
  • Set up a breach notification procedure (72-hour window to supervisory authority)
ShareX / TwitterWhatsApp

Try it yourself

All Quantilence APIs are available as live demos — no account, no setup required.

Browse live demos