What do GDPR and the EU AI Act mean for your media library?

GDPR makes photos personal data and face recognition biometric. And from August 2026, the AI Act adds marking duties. What it means for your media library.

Co-founder, Clipido
Last updated 30 July 202610 min read

Most compliance conversations about digital asset management start and end with one question: "is it hosted in the EU?" It's a fair place to start. It's a terrible place to stop. A media library concentrates three things regulators care about (identifiable people, licensed third-party material, and increasingly AI-generated content) into one system that's deliberately easy to share out of. That's the whole point of the system. It's also the whole compliance problem.

This is a practical overview for marketing and communication teams, not legal advice. Where it matters, it matters enough to involve your DPO.

Photographs are personal data

Here's the starting point that surprises people: an identifiable person in a photograph is personal data under the GDPR. Not special-category data by default (an ordinary photo of a colleague at a conference is regular personal data), but in scope, which means the whole framework applies. Lawful basis, purpose limitation, retention, and the rights of the person in the image.

What does that mean for your library, practically?

You need a basis for holding and publishing. For employees, that's usually legitimate interest for internal use and consent for external marketing use; being on the payroll doesn't mean agreeing to appear in an advertising campaign. For events, it's normally legitimate interest supported by clear signage, with an easy objection route. For models and talent, it's contract, evidenced by a release.

Retention has to be finite. "We keep everything forever" isn't a retention policy. Photography with identifiable people needs a defined lifespan tied to the purpose it was collected for. In a DAM this is perfectly workable: set an expiry or review date as a field, and let the system surface what's due.

Erasure has to actually work. When someone asks to be removed, you need to find every instance (the crops, the resized exports, the copy in last year's campaign gallery) and retire them all. That's straightforward with similarity detection and centralised sharing, and close to impossible across a shared drive and forty transfer links. It's one of the stronger operational arguments for a DAM.

Access requests include images. A subject access request covers photographs of the individual. Being able to run that query in a minute rather than a week is worth having.

Face recognition is a different category

Face recognition used to identify a specific individual processes biometric data, which Article 9 of the GDPR treats as a special category. That raises the bar considerably: you need an Article 9 condition, in a marketing context almost always explicit consent, on top of your ordinary lawful basis, and a data protection impact assessment is normally expected.

None of that is an argument against the feature. It's one of the most useful capabilities in a media library, and AI search in a DAM explains why. It's an argument for switching it on with your eyes open:

  • Scope it. Enable it per workspace or collection rather than across the whole library. Employee portraits and event coverage are different consent situations.
  • Restrict naming. Only a small, named group should be able to attach an identity to a cluster. Detection isn't identification until someone types a name.
  • Set retention on the templates. Biometric signatures need their own deletion path, separate from the images.
  • Document it. Purpose, basis, scope, retention, DPIA. One page. Your DPO will ask.
  • Keep processing in the EU. It removes the transfer question from an already complex analysis.

And if you offer visitors self-service photo finding at an event ("find yourself"), the consent position needs to be settled before the doors open, not afterwards. Event photo distribution covers the operational side.

Data residency and transfers

Since Schrems II, transferring personal data outside the EEA requires a transfer mechanism and, in practice, a transfer impact assessment. The EU–US Data Privacy Framework restored a route for certified US providers, but it's under continuing legal challenge, and building your compliance position on a mechanism that has been struck down twice is an uncomfortable place to be for a public body or a regulated business.

Keeping the data in the EU sidesteps the analysis entirely. So when you evaluate a platform, ask for specifics rather than reassurance:

  • Which region, named. "EU hosting available" is a sales answer. Which data centre region, and is it contractual?
  • Where do backups live? Backups replicated to another continent are a transfer.
  • Where does AI inference run? This is the one most often missed. A platform hosted in Frankfurt that calls a US vision API for tagging is transferring your images.
  • Who are the sub-processors? A named, published list, with notice of changes. If a vendor can't produce it quickly, that tells you something.
  • Where is support based, and can support staff see asset content? Access from outside the EEA is a transfer even without a copy being made.
  • Is there a DPA with current SCCs? Standard, but check that it's actually signed.

Public sector, healthcare and financial organisations in Europe increasingly treat EU-only processing as a procurement requirement rather than a preference. If that's you, establish it before the shortlist, not during contracting.

AI training on your content

A newer question, and one worth getting in writing.

If a vendor processes your assets to improve their models, your commercially sensitive product photography and your images of identifiable people become training data. Under the GDPR that's a distinct processing purpose requiring its own basis, and it's very unlikely to be covered by the one you established for hosting.

So ask directly: are our assets, or derivatives of them, used to train or fine-tune any model, yours or a third party's? You want an unambiguous no, in the contract. A privacy page can be edited; a contract clause can't.

One distinction to keep clear: using AI to process your assets (generating tags, embeddings and descriptions for your library alone) is a different thing and entirely normal. The line is whether anything derived from your content leaves your tenancy.

The EU AI Act, from August 2026

Article 50 of the AI Act introduces transparency obligations for AI-generated and AI-manipulated content, applicable from 2 August 2026. The Code of Practice published in June 2026 sets out what compliance looks like in practice.

For a marketing team, here's what actually matters:

Scope. It applies to AI-generated or AI-modified images, audio and video that could be mistaken for authentic: synthetic imagery, generated product visuals, AI-altered photography, synthetic voice. And it applies extraterritorially: if your content reaches EU users, you're in scope regardless of where the company sits. Purely assistive edits such as ordinary colour correction are not the target.

Marking has to be machine-readable. The expected mechanism is a combination of cryptographically signed provenance metadata (in practice C2PA Content Credentials) and, where technically feasible, invisible watermarking. The C2PA 2.4 specification adds an explicit AI-disclosure assertion for exactly this purpose. Signed metadata alone isn't treated as sufficient on its own, because it's trivially stripped.

Humans need a visible disclosure too. A machine-readable manifest doesn't discharge the obligation to tell a person they're looking at synthetic content.

Deployers must preserve what providers add. If your generation tool embeds credentials, stripping them in your own pipeline is a problem. Most image processing removes metadata by default, which makes this a real operational risk rather than a theoretical one.

The penalties are substantial. But the practical exposure for most marcom teams isn't deliberate deception. It's an AI-generated background or an upscaled product shot flowing through a pipeline that quietly discards provenance.

What to do about it

  1. Find out where AI enters your content production. Generation tools, upscalers, generative fill, background replacement, synthetic voice-over. Most teams underestimate this.
  2. Record it as metadata. An "AI involvement" field (none, AI-assisted, AI-generated) on every asset. It's a fifteen-minute schema change, and it's the foundation of everything else.
  3. Check that your DAM preserves C2PA manifests. Through upload, through rendition generation, through download presets. Many pipelines strip metadata as a side effect of resizing. Ask the vendor directly and test it.
  4. Agree a visible disclosure convention with whoever signs off on published content.
  5. Keep the provenance chain intact on export. Delivering a stripped file to a partner pushes the problem downstream while leaving you responsible.

C2PA is worth understanding beyond compliance, by the way. Provenance that survives editing and distribution is genuinely useful in a media library: it tells you where an asset came from and what's been done to it, which is a question people ask constantly and metadata rarely answers.

Rights, licences and releases

Less novel than the AI Act. Considerably more likely to bite you this year.

Stock licences are narrower than people assume. Territory, duration, media type and print run are all commonly limited. A stock image licensed for a one-off web campaign turning up on packaging two years later is a real and frequent invoice.

Model and property releases have to be findable. A release stored in a contracts folder, unlinked from the image, is functionally absent. Attach it, or at minimum record its existence and expiry on the asset.

Employee imagery changes when employment ends. Many organisations agree to withdraw a former employee's images from active campaigns. That requires knowing where they appear: a search problem, solved by face clustering or good tagging.

Commissioned work isn't automatically yours. Copyright in a photograph sits with the photographer unless the contract assigns it. What you usually have is a licence, with terms. Record the terms.

The systems answer is the same in every case: rights become a required field with a controlled vocabulary and an expiry date, and unverified rights get recorded as unknown, do not publish rather than left blank. Blank gets read as permission. Metadata and taxonomy covers the schema.

A due-diligence checklist

Take this to the vendor conversation. If the answers come slowly, that's an answer too.

  • Named EU region for primary storage, in the contract
  • Backups within the EEA
  • AI inference performed in the EU
  • Published sub-processor list with notice of changes
  • Signed DPA with current SCCs where any transfer occurs
  • Contractual commitment that your content is not used for model training
  • Support access from within the EEA, or documented controls
  • Face recognition scoped per area, with separate biometric retention controls
  • Per-asset rights fields with expiry and pre-expiry alerts
  • Central retirement that propagates to every existing share
  • Audit log of downloads, shares and edits
  • C2PA manifests preserved through upload, renditions and download presets
  • Documented export of assets and metadata
  • Deletion path with a stated timeline, including backups
  • Security documentation available on request, an ISO 27001 certificate, a SOC 2 report, or an equivalent written security dossier your IT team can review
  • SSO, and SCIM provisioning where you manage more than a handful of users

Frequently asked questions

Are photographs personal data under the GDPR?

Yes, where an individual is identifiable. Ordinary photographs are regular personal data; images processed through face recognition to identify someone are biometric special-category data under Article 9 and require an additional condition, normally explicit consent.

Does a DAM need to be hosted in the EU?

Not legally, provided you have a valid transfer mechanism and have completed a transfer impact assessment. In practice, EU-only processing removes an entire category of risk and review, and many European public sector and regulated buyers now require it. Check storage, backups, AI inference and support access separately.

What does the EU AI Act require for AI-generated marketing content?

From 2 August 2026, Article 50 requires AI-generated or AI-manipulated content that could pass as authentic to be marked in a machine-readable way, in practice signed C2PA provenance plus invisible watermarking where feasible, alongside a visible disclosure for people. Deployers are expected to preserve markings applied upstream.

What are C2PA Content Credentials?

A cryptographically signed manifest embedded in a file recording how it was created and edited, including whether AI was involved. It is the emerging standard for content provenance and the mechanism regulators point to for machine-readable AI marking.

How do we handle a request to remove someone from our photos?

Find every instance, including crops, resized exports and material already shared, retire them centrally so existing links stop working, and delete any biometric template. This is routine in a DAM with similarity detection and centralised sharing, and very difficult across shared drives and transfer links.

Should we let a DAM vendor train AI on our assets?

No, and it should be excluded contractually. Using AI to process your assets for your own library is normal and expected; using them to improve a shared model is a separate processing purpose and puts commercially sensitive content and images of identifiable people outside your control.

Your archive is full of great work. Let people find it.

See all features