DEV Community

CaraComp
CaraComp

Posted on • Originally published at go.caracomp.com

Blurring a Name Doesn't Anonymise a Face: What GDPR Actually Says

Think your facial datasets are anonymized? Think again.

For developers building computer vision (CV) pipelines or biometrics-heavy applications, the line between "pseudonymized" and "anonymized" data just became a high-stakes technical boundary. A recent EU court ruling has clarified a long-standing debate: if you strip the names from a facial dataset but retain the ability to re-identify those individuals—even through "additional information" like a lookup table or a specific encryption key—you are still processing personal data under GDPR.

For those of us working with facial comparison algorithms, this ruling collapses the "metadata-only" defense. It implies that the face itself is the primary identifier. From a technical perspective, this means your Euclidean distance vectors and biometric embeddings are likely considered high-risk personal data under Article 9, regardless of how many layers of UUIDs you wrap them in.

The Algorithm is the Identifier

In the world of facial comparison, we treat a face as a high-dimensional vector. We calculate the Euclidean distance between these feature sets to determine a match. This court ruling reinforces that this geometric topology—the specific landmarks of the eyes, nose, and jaw—is an inherent biometric fingerprint.

If you are a developer managing a database of face embeddings, you cannot simply claim the data is anonymous because you haven't attached a "Name" string to the record. If your system allows a 1:N search or a comparison against a known source image, the data remains pseudonymized, not anonymized. The distinction is critical: pseudonymized data is still fully regulated. If your deployment allows for re-identification through any "reasonably likely" technical means, you are on the hook for full GDPR compliance, including the heavy transparency obligations for biometric data.

Deployment and API Implications

This news significantly changes how we approach "Data at Rest" and "Data in Transit." For solo investigators or small firms using facial comparison technology, the burden of compliance often feels like an enterprise-level problem. This is why we’ve focused on a "comparison" model at CaraComp rather than a "surveillance" model.

When you build or use tools that rely on user-provided case photos (1:1 or 1:N comparison within a closed case file), the technical footprint is different from mass-scanning public feeds. However, even within those closed files, stripping a name from a photo while keeping the photo in a case folder is legally insufficient for anonymization.

Developers need to consider:

  • Reversibility: If your embedding can be used to reconstruct a likeness (via GANs or feature inversion), your "anonymization" script is actually just a pseudonymization tool.
  • The "Additional Information" Standard: If a lookup table exists anywhere in your stack—or even in your client's physical files—the biometric data is still PII.
  • Court-Ready Reporting: For investigators, the reliability of the comparison is paramount. You can't stake a reputation on 2.4/5 reliability scores or "black box" algorithms. You need enterprise-grade Euclidean distance analysis that produces professional, court-ready reports, even at a fraction of the enterprise price point.

The AI Act and the Compliance "Double-Tap"

Compounding this is the EU AI Act, which classifies many biometric identification systems as high-risk. If you are deploying facial comparison tools in a legal or investigative context, you may now be facing a "compliance double-tap": GDPR Article 9 obligations for special category data, plus AI Act requirements for conformity assessments and logging.

For the solo investigator, this tech shouldn't be a gatekept secret for agencies with six-figure budgets. You can access the same Euclidean distance analysis used by the majors for $29/month, but you must understand that the "face" is the data. Blurring the name on the folder doesn't change the pixels in the file.

How are you handling the storage of biometric embeddings in your current CV projects—are you treating vectors as PII, or just the metadata?

Top comments (0)