Facial recognition in pro photography: what GDPR allows

Facial recognition has changed event gallery delivery: a guest scans a QR code, takes a selfie, and automatically receives their own photos out of 2,000 files. For the photographer it promises personalised delivery with no manual sorting. On the GDPR side, though, the ground is mined.

This article sets out what a professional photographer can do with facial recognition in 2026, both legally and operationally, based on the GDPR framework and European data protection authority guidance.

Why photographers use facial recognition

Three uses come up in practice.

Sorting by subject. At a wedding with 150 guests, the couple often wants a personalised album for their parents and witnesses. Sorting 1,500 photos by person manually takes several hours. Facial recognition cuts that to minutes: the tool groups photos by face, the photographer checks the result.

Personalised delivery. Rather than sending a full gallery, each guest receives a sub-album containing only their own photos. The couple does not have to filter anything, and the result impresses guests. At a B2B conference with 800 attendees, it is the only way to deliver an individual photo service without dedicated staff.

Spotting who is missing. At an event with a known attendee list, you can identify guests who appear in no photo and alert the team to adjust coverage in real time. A rarer use, but relevant at conferences or corporate shoots where every attendee counts.

In all three cases the added value is real. What remains is understanding what GDPR permits, and how.

GDPR does not say "facial recognition is forbidden". It says it falls into the category of sensitive data, subject to a strict regime.

Biometric data vs simple visual identification

This is the most important distinction, and the most widely misunderstood.

A photo containing a guest is personal data, processed under GDPR article 6. Consent is only one legal basis among several; legitimate interest or performance of a contract is often enough.

A biometric vector (the mathematical fingerprint extracted from a face to allow comparison) is by contrast sensitive data under article 9. Collecting it is prohibited by default, save for explicit exceptions, and the free and explicit consent of the subject remains the only realistic exception for a photographer.

The practical consequence: photographing a guest requires no special procedure. But as soon as you extract their biometric fingerprint to compare it with others, you enter a different legal regime.

When biometric processing is necessary, consent must be:

Freely given: not conditional on the service. A guest cannot be forced to use facial recognition to access their photos. An alternative route (browsing the gallery manually) must remain available.
Specific: explicitly targeting the biometric processing. A general "I accept the terms" does not suffice.
Informed: the subject must know who processes their data, for what purpose, where it is stored and for how long. The form has to say so.
Unambiguous: an active opt-in, not a hidden opt-out. A pre-ticked box is void.
Revocable: the subject must be able to withdraw consent at any time, and processing must stop without a complicated procedure.

In the field this means a consent screen shown to the guest before the comparison selfie is captured, with a direct link to the ordinary gallery for anyone who declines.

Client-side vs server-side processing

Both architectures exist on the market, and contrary to a widespread belief both can be GDPR compliant. What changes is the list of obligations to meet.

Client-side processing: extraction of the biometric vector and the comparison happen in the guest's browser, and the vector never leaves the device. The absence of central storage lightens some obligations (retention, securing vectors at rest). In exchange, accuracy is limited by the power of the guest's phone: lightweight models running in a browser are worse at recognising faces in profile, in low light or in the background.

Server-side processing: the selfie is sent to the platform's server, which extracts the biometric vector and compares it with faces detected in the photos. This processing remains fully subject to article 9, which imposes specific safeguards: explicit consent collected before capture and documented, encryption in transit and at rest, a defined retention period applied automatically, deletion on request, and a DPA between the photographer and the platform. In exchange, server-side models (which are heavier) offer markedly better accuracy at large events.

That is the architecture Evokly uses: each guest's consent is recorded with a timestamp and the version of the text before any capture, the selfie is converted into a facial descriptor (a mathematical vector that cannot be reversed into an image), data is encrypted in transit (TLS 1.3) and at rest, never shared with third parties or used to train models, and deleted automatically when the event expires or on request. A DPA is available for photographers who need one.

Regulators do not mandate one architecture over the other: guidance on biometric systems emphasises consent, minimisation, storage limitation and security, wherever the computation happens.

The detail matters. Whatever architecture a platform advertises, check how it actually works and insist that it be documented in writing: a precise privacy policy, a quantified retention period, an explicit DPA.

The compliant method, step by step

A typical event with compliant facial recognition comes down to six points.

Set the legal basis up front. The legal basis for biometric processing is the guest's explicit consent, collected when the selfie is captured. Add a clause to the contract with the organiser (couple, agency, company) clarifying who is controller and who is processor, and reference the platform's DPA.
Prior information. The invitation or event programme should mention that a facial recognition tool may be used to find your photos, with a link to a privacy policy accessible before the event. See our 2026 event QR code guide for the most effective communication channel.
Consent at the moment of selfie capture. A dedicated screen, in plain language: "To find your photos automatically, your selfie will be converted into a digital fingerprint and compared with the event photos. This fingerprint is encrypted, never shared, and deleted at the end of the event. Continue Browse manually". Consent must be recorded (date, version of the text accepted).
Documenting the processing. Keep an internal register (GDPR article 30) describing the type of data, the retention period, the legal bases and the security measures. Mandatory above 250 employees, recommended for every professional handling sensitive data.
Right to erasure. The guest must be able to request deletion of their photos and a stop to processing at any time. A simple email is enough; an independent photographer does not need a dedicated portal. The response must come within a month.
Limited retention. Event photos are not meant to stay accessible indefinitely. A typical period runs from 90 days to 12 months depending on use. Beyond that, deletion must be documented or justified by fresh consent. Our GDPR guide on event photo retention sets out recommended durations per use case and the documentation to produce (register, mention at consent).

For broader GDPR framing of event photography work, see the Evokly compliance page, which details the full processing chain.

Common mistakes to avoid

Storing embeddings "just in case". A biometric vector saved for later use is sensitive data at rest. If you are not using it immediately, do not store it. The minimisation rule (GDPR article 5(1)(c)) is explicit.

Treating consent as granted by the purchase. A client who pays for photography has not thereby consented to biometric processing of their guests. Those are two distinct levels.

Sharing identified albums without checking. Identifying "Marie Dupont" in 12 photos and then sending the album to the whole guest list is a direct violation, since you are redistributing inferred biometric data without the subject's consent.

Using a US consumer tool with no DPA. Google Photos, Apple Photos and similar consumer tools are not designed for regulated professional use. Without a signed data processing agreement you transfer data outside the EU with no stable legal basis.

Confusing culling AI with facial recognition. Tools like Narrative Select or Aftershoot Edit use AI to suggest selections (blurry photos, duplicates, closed eyes). That does not analyse identities. No article 9 regime, so standard client consent is enough.

For the contract between the photographer and their client (couple, company, agency), a model clause can draw on the following (adapt it with your lawyer or DPO).

Article. Data processing and facial recognition
The Provider offers, as an option, an event gallery equipped with a facial recognition tool allowing each guest to find the photos in which they appear.
The guest's reference selfie is securely transmitted to the name platform, which converts it into a digital fingerprint (a mathematical vector that cannot be reversed into an image) solely for comparison with the event photos. This data is encrypted, is neither shared with third parties nor used for any other purpose, and is deleted when the gallery expires or at the guest's request.
Use of this tool by each guest is strictly optional and subject to their explicit consent, collected and recorded at the moment the reference selfie is captured. An alternative (browsing the gallery manually) remains available unconditionally.
The Client warrants that guests were informed in advance of the availability of this tool through the event invitation channel.
Retention of photos and digital fingerprints is limited to X days/months from the date of the event, after which the files are deleted from the Provider's and the platform's servers. A data processing agreement (DPA) is in place between the Provider and the name platform.

Adapt the retention period to the one your platform actually applies, and check that the DPA you reference genuinely exists before signing.

Facial recognition is not a legal trap. It is a regulated form of processing that requires a clear procedure and an aligned tool. For event photographers delivering large volumes it is a strong commercial differentiator: the gallery becomes usable even by guests who have no idea how to search through 2,000 files, and the service stands apart from a plain WeTransfer link.

To compare platforms on the facial recognition criterion, our guide to Pixieset alternatives covers the functional and pricing differences. To start a concrete trial, see Evokly pricing.