AWS Rekognition EU Alternative 2026: Biometric Data, Article 9 GDPR, and the CLOUD Act Problem

Post #732 in the sota.io EU Compliance Series

AWS Rekognition is Amazon's managed computer vision service. It performs facial analysis, face search, object detection, text extraction, content moderation, and video analysis — all through a simple API. For teams building applications that need to identify faces in photos, moderate user-uploaded images, analyze surveillance footage, or extract text from documents, Rekognition is the path of least resistance: no ML expertise required, no model training, no infrastructure to maintain.

That simplicity carries a GDPR cost that goes beyond data residency concerns. Rekognition is not just a cloud service that stores data in the United States — it is a service that processes biometric data, which the GDPR treats as a special category of personal data under Article 9. Special category data requires an explicit legal basis to process. It triggers mandatory Data Protection Impact Assessments. It cannot be processed by default under the general consent or legitimate interest provisions that cover ordinary personal data.

Amazon Web Services, Inc. is a Delaware corporation headquartered in Seattle, Washington. The CLOUD Act (18 U.S.C. § 2713) allows US authorities to compel production of data from US companies regardless of where that data is stored. When that data includes facial embeddings, biometric templates, and behavioral inferences derived from images of identifiable people, the implications under GDPR Article 9 are severe.

This analysis covers six GDPR exposure points in AWS Rekognition that European development teams need to understand before deploying any biometric processing in their applications.

Article 9 and the Biometric Data Problem

Before examining Rekognition specifically, the GDPR framework for biometric data requires context. Article 4(14) defines biometric data as "personal data resulting from specific technical processing relating to the physical, physiological or behavioural characteristics of a natural person, which allow or confirm the unique identification of that natural person." Article 9(1) prohibits processing biometric data "for the purpose of uniquely identifying a natural person" without an explicit legal basis under Article 9(2).

The key phrase is "for the purpose of uniquely identifying." Courts and data protection authorities have applied this broadly. Even when an application does not explicitly aim to identify individuals, using facial recognition to verify that two photos depict the same person, or to search a database for matching faces, qualifies as processing for unique identification purposes.

Article 9(2) provides a narrow list of legal bases: explicit consent, vital interests, manifestly public data, employment law obligations, legitimate activities of foundations, and a few others. For most commercial applications — user authentication, content moderation, surveillance — these bases are difficult to satisfy. Explicit consent under Article 9 must meet a higher standard than ordinary consent: it must be freely given, specific, informed, and unambiguous, with the data subject able to withdraw without detriment.

Building an application on Rekognition means building on infrastructure that processes Article 9-class data under US jurisdiction. Even if your own legal basis satisfies Article 9(2), you still need to ensure that the processor — AWS — provides sufficient guarantees under Article 28. And you still face the CLOUD Act problem: a legal basis under GDPR Article 9(2) does not override a US government compelled disclosure order.

Rekognition Collections: Face Embeddings Under US Jurisdiction

AWS Rekognition's IndexFaces API extracts a mathematical representation of a face from a photograph — a facial embedding or face template — and stores it in a Rekognition Collection. Collections are the persistent storage mechanism for face search: you index faces into a collection, then use SearchFacesByImage to find matching faces in the collection when new images arrive.

These facial embeddings are biometric data under GDPR Article 4(14). They are derived from physical characteristics that uniquely identify individuals. They are stored in AWS's managed infrastructure in the region you select — but stored under US corporate jurisdiction. AWS manages the collection storage, the embedding format, and the encryption keys.

The GDPR problem: Facial embeddings stored in Rekognition Collections are Article 9 personal data held by a US cloud provider subject to CLOUD Act compelled disclosure. The data subject's biometric template — a permanent, immutable representation of their face — is accessible to US law enforcement through the same legal mechanism that applies to email attachments and database records.

Unlike passwords, biometric data cannot be changed. If a Rekognition Collection is compelled from AWS, the individuals whose faces were indexed have permanently lost control of their biometric identifiers. Under GDPR Article 5(1)(f), personal data must be protected with appropriate technical and organisational measures. Storing facial embeddings in a system with known government-compellable disclosure pathways raises fundamental questions about what "appropriate" means for Article 9 data.

The Article 28 requirement adds complexity. AWS Rekognition is a data processor under GDPR. Your Data Processing Agreement with AWS must address the specific risks of biometric processing — including the Article 9 special category designation, the legal basis for AWS's processing of your data, and the mechanism for responding to data subject rights requests (erasure, access, restriction). The standard AWS DPA is a general instrument; its adequacy for Article 9 biometric processing has not been tested under GDPR Article 28(3)'s specificity requirements.

Facial Analysis: Sensitive Inferences Without Explicit Collection

Rekognition's DetectFaces API goes beyond face detection. It returns estimated age ranges, facial landmarks (eye position, mouth corners, nose tip), pose estimation (pitch, roll, yaw), and inferred emotional states (confused, surprised, disgusted, happy, etc.). It can infer whether a face has eyes open or closed, whether the person is wearing sunglasses, and whether a smile is detected.

The GDPR problem: Emotional state inferences and behavioral indicators derived from facial analysis may constitute special category data beyond the explicit biometric identification use case. The EDPB's Guidelines on Facial Recognition Technology in Law Enforcement (2020) and several national DPA opinions have indicated that even analytical results derived from facial images carry Article 9 implications when they reveal or infer sensitive characteristics.

More directly: performing DetectFaces on images of identifiable individuals and storing the results in CloudWatch Logs or your own database creates a record of inferred emotional states and behavioral signals tied to those individuals. This is exactly the type of profiling data that GDPR Article 22 governs when used in automated decision-making.

For consumer-facing applications — particularly retail analytics, event photography, or HR software — the inferred data from Rekognition's facial analysis endpoints can be used in ways that trigger Article 22 obligations around automated profiling, even if the developer's intent was purely technical (counting smiling faces, not profiling individuals).

Video Analysis: Persistent Tracking and Movement Profiles

Rekognition Video processes video streams and stored video files. The StartFaceSearch API tracks known individuals across video frames. The StartPersonTracking API maintains persistent identifiers for detected persons across a video, enabling movement tracking without requiring face identification. The GetFaceSearch and GetPersonTracking APIs return per-frame data showing exactly where tracked individuals appear throughout a video.

The GDPR problem: Video surveillance analysis that creates movement profiles of individuals is among the most sensitive forms of personal data processing under GDPR. Multiple supervisory authorities (including the Belgian, French, and German DPAs) have issued guidance indicating that automated video surveillance analysis that tracks individuals across frames constitutes high-risk processing requiring Article 35 DPIA regardless of the purpose.

Rekognition Video processes video through Amazon Rekognition's managed API. The video content, the extracted face tracks, and the movement data are all processed under AWS's infrastructure. If the video contains EU residents — employees, customers, or members of the public — that processing occurs under US jurisdiction. Kinesis Video Streams, which Rekognition Video integrates with for live stream analysis, compounds this by streaming video data continuously to AWS before any analysis occurs.

For applications involving workplace surveillance, retail footfall analysis, or event security, Rekognition Video creates a processing architecture where biometric and behavioral data about EU residents flows continuously to a US-controlled service. Under GDPR Articles 13 and 14, individuals in frame must be informed of this processing — a disclosure requirement that the casual implementation of Rekognition Video routinely fails to satisfy.

Content Moderation: Sensitive Category Inferences Stored in Audit Logs

Rekognition's DetectModerationLabels API analyzes images for explicit or suggestive adult content, violent content, and other categories defined in Rekognition's moderation taxonomy. The API returns a confidence-scored hierarchy of content labels. For platforms with user-generated content, it is a standard tool for automated moderation pipelines.

The GDPR problem: Content moderation results for images that contain identifiable people generate inferences about the content of those images — and by association, about the individuals depicted. An image moderated as "explicit" or "violence" creates a label associated with identifiable individuals. If these moderation decisions are logged to CloudWatch Logs (a common implementation pattern), the logs contain a record linking identifiable people to sensitive content classifications.

Under GDPR Article 9(1), inferences that reveal or are derived from intimate or sexual behavior can constitute special category data. The Article 29 Working Party (now EDPB) Opinion 03/2012 on developments in biometric technologies noted that "data pertaining to an individual's intimate life or sexual behavior" receives heightened protection. Rekognition's explicit content moderation labels, when stored in logs associated with identifiable images, create records that may qualify.

More practically: audit logs of content moderation decisions for user-generated content are often retained indefinitely for legal and compliance purposes. When those logs reference images of identifiable individuals and include sensitive content labels, they create a persistent record of sensitive inferences stored in AWS-managed infrastructure under US jurisdiction — with the full CLOUD Act exposure this implies.

Celebrity Recognition: Processing All Faces to Identify Some

Rekognition's RecognizeCelebrities API identifies famous individuals in images. Its implementation reveals a structural GDPR issue that applies even when no celebrities are present: to determine whether a face is a celebrity, Rekognition must first perform facial analysis on every detected face in the image, extract facial embeddings for each face, and then compare those embeddings against its celebrity recognition model.

The GDPR problem: The celebrity recognition API processes the biometric data of all individuals in an image — including non-celebrities and entirely private persons — as a prerequisite to returning results about public figures. This intermediary biometric processing is not disclosed in the API's name or common documentation descriptions, but it is inherent to the technical operation.

For applications that use RecognizeCelebrities on user-uploaded photos of groups, events, or public spaces, the API silently performs Article 9-class biometric processing on everyone in frame, not just the celebrities it reports. The faces of private individuals — friends, family members, bystanders — are processed by a US-controlled biometric analysis system without their knowledge or consent.

GDPR Article 13 requires transparency at the point of collection. An application that uses RecognizeCelebrities on user-uploaded group photos and discloses only "celebrity recognition" in its privacy notice is failing to disclose the biometric processing of non-celebrity individuals that the API performs. This is a structural transparency failure that the simplicity of the API call obscures.

The Mandatory DPIA Requirement

GDPR Article 35 requires a Data Protection Impact Assessment before beginning processing that is "likely to result in a high risk to the rights and freedoms of natural persons." Article 35(3)(b) specifically identifies "large scale processing of special categories of data referred to in Article 9(1)" as automatically requiring a DPIA.

Biometric data is Article 9 special category data. Any application that processes biometric data at scale — which, for a managed API like Rekognition, means any production deployment with more than a small number of test users — triggers the mandatory DPIA requirement.

A compliant DPIA for a Rekognition-based application must document the processing purpose, the Article 9(2) legal basis, the data flows including AWS as a processor, the technical safeguards, the residual risks, and the mitigating measures. The DPIA must be consulted with the relevant supervisory authority if the residual risk remains high after mitigation.

The key tension: Rekognition's architecture makes several DPIA residual risks difficult to mitigate. The CLOUD Act exposure for facial embeddings stored in Rekognition Collections cannot be eliminated by any configuration choice — it is inherent to using a US-headquartered cloud provider. A DPIA that documents this residual risk may require consultation with the supervisory authority before processing can begin. DPAs in Germany, France, and the Netherlands have signaled skepticism about US cloud providers' ability to provide sufficient guarantees for Article 9 biometric processing precisely because of this structural issue.

EU-Native Alternatives to AWS Rekognition

The EU alternatives for biometric processing and computer vision fall into two categories: open-source self-hosted solutions and EU-based managed services.

Open-Source Self-Hosted:

CompreFace (Exadel) is a dedicated open-source face recognition system. It provides REST APIs for face detection, recognition, verification, and attribute analysis. The architecture is containerized and designed for self-hosted deployment. Running CompreFace on EU infrastructure — a VPS in Frankfurt, a bare-metal server in Amsterdam, or an EU PaaS like sota.io — ensures biometric processing under EU jurisdiction with no third-party cloud involvement. The face embeddings are stored in your own database, not in a US-controlled collection. Crucially, CompreFace's embedding storage is under your complete control: you can encrypt it with your own keys, audit access at the database level, and satisfy data subject erasure requests with a targeted database delete.

InsightFace is one of the leading open-source face recognition frameworks, supporting face detection, alignment, recognition, age/gender estimation, and face parsing. It runs on Python/ONNX and can be deployed as a REST API service. Self-hosted InsightFace on EU compute keeps all biometric processing within your infrastructure. The inference runs locally, no data leaves your environment, and the DPIA residual risk profile is fundamentally different from a managed cloud service.

DeepFace is a Python library providing a unified interface to several face recognition models (VGG-Face, FaceNet, ArcFace, DeepID, Dlib). It is well-suited for applications that need flexible model selection and can run in a containerized deployment behind a REST API. Like InsightFace, self-hosted DeepFace eliminates the US cloud jurisdiction problem entirely.

OpenCV with pre-trained models handles many of the non-biometric use cases that Rekognition is often chosen for: object detection (YOLOv8 models), text extraction (Tesseract OCR), image classification, and content moderation. For applications where biometric identification is not actually required — only general computer vision — OpenCV on self-hosted EU infrastructure is significantly lower risk from both a GDPR and DPIA perspective.

EU-Based Managed Services:

Mindee is a French AI document processing company providing APIs for document data extraction, ID verification, and receipt processing. Their infrastructure is EU-based. For use cases involving identity document processing — which is one of Rekognition's common applications — Mindee provides an EU-native managed alternative.

Sightengine is an EU-based content moderation API, processing images for adult content, violence, weapons, and other moderation categories. Their infrastructure is European. For the content moderation use case specifically, Sightengine directly replaces Rekognition's DetectModerationLabels without the US jurisdiction issue.

Migration Approach: From Rekognition to Self-Hosted CompreFace

The core migration path for Rekognition's most sensitive functionality — face recognition and face search — is to replace Rekognition Collections with CompreFace subjects.

Rekognition's IndexFaces maps to CompreFace's "add example of a subject." Rekognition's SearchFacesByImage maps to CompreFace's "recognize faces from image." The data model is similar: you create subjects (equivalent to Rekognition's face IDs), add reference images, and then search for matches. The key difference is that CompreFace runs on your infrastructure — the face embeddings live in your PostgreSQL database, not in an AWS-managed collection under US jurisdiction.

A containerized CompreFace deployment on sota.io provides all of the operational advantages of a managed service (no ML infrastructure to maintain, automatic scaling, containerized deployment) while keeping biometric data under EU jurisdiction. The DPIA for a CompreFace deployment on EU PaaS is structurally different from a Rekognition deployment: the CLOUD Act residual risk is replaced by the risks of your own infrastructure management, which can be mitigated through standard security measures (encryption at rest, access logging, key management) without the structural impossibility of preventing US government access to a US-company-controlled service.

What This Means for Your Architecture

If your application currently uses AWS Rekognition, the compliance assessment is not simply "are EU servers available?" AWS provides Rekognition in eu-west-1, eu-central-1, and other EU regions. Those EU regions do not resolve the core problem: the data is processed by Amazon Web Services, Inc., a US corporation under the CLOUD Act.

The questions that define your Article 9 compliance posture are:

1. What is your Article 9(2) legal basis? If you cannot identify an explicit legal basis from the Article 9(2) list that covers your specific processing, deployment must stop until you can.

2. Have you completed a DPIA? For any production Rekognition deployment processing biometric data of more than a small number of individuals, the DPIA is not optional. The ICO, CNIL, and BfDI have all issued guidance confirming this.

3. Can you satisfy the CLOUD Act residual risk in your DPIA? This is the structural challenge. A self-hosted EU alternative may reduce residual risk to an acceptable level; a managed US cloud service requires you to document and consult on a residual risk you cannot technically mitigate.

4. Are your Article 13/14 disclosures accurate? If your privacy notice says "we analyze images to detect faces" and you are using Rekognition's RecognizeCelebrities API, your notice does not disclose the biometric processing of non-celebrity individuals that the API performs.

For teams that have built on Rekognition for convenience, the Article 9 compliance gap is often larger than it appears. The managed API abstraction conceals the biometric processing depth. Replacing it with self-hosted CompreFace, InsightFace, or Sightengine is a migration, but it is one that puts biometric data where EU data protection law requires it: under your control, on infrastructure you govern, in a jurisdiction that responds to GDPR rather than to the CLOUD Act.

Running computer vision workloads on EU infrastructure doesn't require managing Kubernetes clusters. sota.io deploys containerized applications — including CompreFace, InsightFace, and custom vision models — directly from Git to EU servers in under two minutes. Your biometric data stays in the EU, under your keys, outside CLOUD Act reach. Start with sota.io →