GDPR and an employee's photo as an avatar: Recital 51 explained

Is an employee photo used for an AI avatar biometric data under GDPR? Recital 51 says photos are biometric only with specific technical means. Not legal advice.

5 min readSume
All posts

Under GDPR Recital 51, a photograph is not automatically special-category biometric data. It counts as biometric data only when processed through a specific technical means that allows unique identification or authentication of a person. A plain photo of an employee used to make a talking avatar may therefore not be biometric, but it is still personal data, so you still need a lawful basis, a purpose and a way to honour the person's rights. This is general information, not legal advice.

The wording of the recital is on GDPR Recital 51 at gdpr-info.eu, read 2026-10-05.

Two questions, not one

The recital draws a line between what is processed and how. The same image can fall on either side, depending on the technical means applied to it.

Photo processing and Recital 51, read 2026-10-05
SituationRecital 51 readingStill personal data?
Photo stored and shown as a profile pictureNot special-category by itselfYes
Photo used as the reference image for an avatarDepends on whether processing allows unique identificationYes
Face template built to identify or authenticate the personBiometric data, special categoryYes

What the Sume docs say, and do not say

Sume's avatar creation takes a photo URL, validates the file and creates a reusable avatar under a handle. The API documentation describes the inputs and the preflight; it does not state a legal classification of any avatar output, and I do not claim one. Whether your use is biometric depends on your own processing, so ask your data protection adviser, and write down the answer.

In practice that means two separate records. One is the processing record for the photo and the avatar, with the purpose and the lawful basis. The other is your assessment of whether any step creates a template or other data used to identify the person. If the assessment is uncertain, treat the data with the higher level of care until a specialist says otherwise. That approach costs little and avoids having to reverse a decision later.

Groundwork before the upload

Whatever the classification, an employee avatar needs the same groundwork. Work through this list before the photo leaves your systems.

Consent deserves a separate note. Where an employer asks an employee, the power imbalance can make consent hard to treat as freely given, so consider whether another basis fits better, and say in writing why. Whatever the basis, the person should know the avatar is synthetic, know where it will be used, and have a way to say no without penalty.

  • Pick and record a lawful basis, and note that consent from an employee may not be freely given because of the power imbalance.
  • Say what the avatar will say and where it will appear.
  • Keep a record linking the person, the photo, the avatar handle and the approved uses.
  • Decide what happens when they leave or withdraw.
  • Tell the person in plain words that the video is synthetic, and show a disclosure on the video.

Withdrawal and removal

Two things are worth planning for. The docs list no route to delete an avatar, so removal is a process question rather than an API call; ask Sume support how a removal is handled and record the reply. And withdrawal of permission has to be acted on in your videos too: the withdrawn voice consent post shows how to find and replace what is already published.

Where to go next

Start with the release checklist, keep a register, and treat this post as a pointer to the recital rather than as advice. The photo rules on Create new avatar cover what the API accepts, not what the law allows.

Sources

Related posts

More in Use cases

All Use cases posts

Written by Sume