Reference Glossary
Facial recognition (DAM)
Computer vision capability that detects faces in an asset and can match or cluster them to the same individual across a library, distinct from simply detecting that a face is present.
Why it matters in a DAM
In DAM this is usually pitched for talent and model-release compliance — automatically flagging every asset containing a person whose release has expired. But matching a face to identify an individual is processing biometric data, which GDPR Article 9 classifies as a special category requiring explicit consent or another narrow legal basis, and which is exactly what triggered Illinois BIPA lawsuits that cost Facebook $650 million and Google $100 million over face-grouping in Google Photos. Some DAM vendors, including Asset Bank, have said publicly they chose not to ship facial recognition specifically to avoid taking on that compliance risk on customers' behalf.
Common mistake
Teams turn on face-clustering because it's a checkbox in the AI settings, without adding a consent-tracking or documented legal-basis workflow first — the exact gap that produced the BIPA class actions, even though the DAM itself never displays a name next to the face.
Facial recognition in a DAM context usually means two related but distinct things: detecting that a face is present in an image (which most computer vision tagging already does as a matter of course), and matching or clustering faces so the system can say ‘this is the same person as in that other photo’ across the library. It’s the second capability — identification, not just detection — that carries the legal weight.
The pitch for it in DAM is compliance automation: link every asset containing a given model or employee to their release agreement, and flag anything where the release has expired or was never obtained. That’s a real problem worth solving. But under GDPR, biometric data used to uniquely identify a person falls under Article 9 as a special category of personal data, which restricts processing to narrow lawful bases such as explicit consent — a much higher bar than the general lawful-basis rules that apply to ordinary metadata. In the US, Illinois’ Biometric Information Privacy Act (BIPA) has produced some of the largest privacy settlements on record over exactly this kind of face-matching: Facebook agreed to pay $650 million and Google $100 million to Illinois users after both were sued for grouping photos by face without the written consent BIPA requires, even though neither case involved a traditional DAM product.
That legal exposure is significant enough that at least one DAM vendor, Asset Bank, has stated publicly it deliberately does not offer facial recognition as a feature, positioning the decision as reducing customers’ compliance risk rather than adding a high-risk biometric capability to routine marketing workflows. Vendors that do offer it typically push the compliance responsibility onto the customer through their terms of service — which means enabling the feature is a legal decision, not just a product configuration one, and needs sign-off from whoever handles data protection, not just the DAM administrator.
Frequently asked
Why is facial recognition in DAM legally riskier than other computer vision tagging features?
Matching a face to identify an individual is processing biometric data, which GDPR Article 9 classifies as a special category requiring explicit consent or another narrow legal basis — a much higher bar than ordinary metadata processing.
What real-world legal cases illustrate the risk of face-matching features?
Illinois' BIPA law produced major settlements over face-grouping: Facebook agreed to pay $650 million and Google $100 million to Illinois users after being sued for grouping photos by face without the required written consent, even though neither case involved a traditional DAM product.
Why did Asset Bank decide not to offer facial recognition as a DAM feature?
It stated publicly it chose not to ship the feature specifically to avoid taking on the compliance risk of high-risk biometric processing on customers' behalf, reducing customer risk rather than adding the capability.
What's the difference between face detection and face recognition/matching in a DAM?
Detecting that a face is present is something most computer vision tagging already does; matching or clustering faces so the system can say 'this is the same person as in that other photo' across the library is the identification capability that carries the legal weight.
What's the pitched benefit of facial recognition for DAM compliance workflows?
Automatically flagging every asset containing a person whose model release has expired, linking assets to release agreements — a real problem, but one that comes with significant biometric-data legal exposure.
What's the mistake teams make when enabling face-clustering as just a checkbox?
Turning it on without adding a consent-tracking or documented legal-basis workflow first — the exact gap that produced the BIPA class actions — treating it as a product configuration decision instead of a legal one needing data-protection sign-off.
Sources
- Facebook agreed to pay $650 million to settle an Illinois BIPA class action alleging its facial recognition feature extracted and stored users' biometric identifiers without required written consent. checked 2026-08-07 — Consumer Reports
- Under GDPR Article 9, biometric data processed to uniquely identify a person is classified as a special category of personal data requiring a stricter lawful basis such as explicit consent. checked 2026-08-07 — ICO — Key data protection concepts (biometric recognition guidance)
- Asset Bank states it chose not to release facial recognition as a DAM feature in order to reduce customers' compliance risk rather than introduce high-risk biometric processing into marketing workflows. checked 2026-08-07 — Asset Bank blog — Facial recognition in DAM: have you checked it with your data protection officer?