The Price is Right: Responsible Uses of Personal Data in Pricing

The way prices are set is changing: more accessible data, sophisticated algorithms, and ubiquitous online shopping have given retailers the ability to automatically tailor offers to customers in real-time or near-real-time based on increasing amounts of data about markets and consumers. A number of pricing strategies involving personal data, market data, and advanced machine learning—what this resource refers to collectively as “data-driven pricing”—have recently become common marketing practice. While data-driven pricing is often deployed to attract, retain, or reward customers, it can also provide retailers with insights that could be used to individualize prices in ways that average consumers might find unexpected or unfair, or that cause unintended disparities across groups. For these reasons, data-driven pricing has become the subject of increasing scrutiny from civil society, lawmakers, and enforcers in the United States.

This resource provides an overview of how data is used to inform pricing; contextualizes data-driven pricing in existing U.S. law, enforcement activity, and emerging legislation; and recommends a number of best practices for guiding retail and e-commerce platforms in using data responsibly when it affects pricing. These practical recommendations, developed in consultation with companies working to build trustworthy pricing practices, are aligned with how leading organizations have built robust, responsible AI Governance programs based on frameworks like National Institute of Standards and Technology (NIST)’s AI Risk Management Framework (AI RMF). 

Read the full report: The Price is Right: Responsible Uses of Personal Data in Pricing


Recommendations include:

Red Lines under the EU AI Act: Restricting Real-time Remote Biometric Identification Systems for Law Enforcement Purposes

Blog 8 | Red Lines under the EU AI Act Series

This blog is the eighth of a series that explores prohibited AI practices under the EU AI Act and their interplay with existing EU law. You can find the whole series here.

  1. Introduction

The eighth blog in the “Red lines under the EU AI Act” series examines the general prohibition on the use of real-time biometric (RBI) systems in publicly accessible spaces for law enforcement purposes imposed by Article 5(1)(h) of the EU AI Act, the three narrow exceptions to the prohibition permitted for Member States to utilize, and how these obligations fit in the broader context of real-time biometric identification in the EU. 

There are a few key takeaways from our analysis of this provision:

With these key takeaways in mind, Section 2 of this blog examines the reasoning behind the prohibition on RBI, while Section 3 explores the specific elements that all must be triggered to bring processing activity within the provision’s scope. Section 4 outlines the important but limited exceptions to the prohibition, while Section 5 examines how this provision interacts with other relevant areas of EU law, such as Article 9 of the General Data Protection Regulation (GDPR). Section 6 includes closing thoughts and takeaways along with a brief examination of salient activity by DPAs. 

2. Why the prohibition? Specific risks associated with RBI for law enforcement purposes

As noted earlier in this blog series, the creation and use of large scale biometric identification systems has long been an area of serious concern for EU authorities. This is particularly acute in the context of such systems’ deployment for law enforcement purposes; the Guidelines recognize the potential impact on the rights and freedoms of individuals widespread deployment of these technologies represents. The Guidelines further identify the “feeling of constant surveillance” the deployment of RBI systems in public spaces may elicit risks “indirectly dissuad[ing] the exercise of freedom of assembly and other fundamental rights,” and technical failures in AI systems may also produce discriminatory effects based on sensitive personal characteristics such as age, ethnicity, race, sex, or disability status. 

3. Verification vs. Identification: what systems are captured by the RBI prohibition?

The Guidelines walk through a number of questions that must be examined in order to understand whether a given system falls within the prohibition’s scope: 

It is critical to note that all of these criteria must be present for a system to be affected by the ban set forth in Article 5. 

Article 3(41) of the AI Act defines an RBI system as an “AI system for the purpose of identifying natural persons, without their active involvement, typically at a distance through the comparison of a person’s biometric data with the biometric data contained in a reference database.”

Whether a system qualifies as an RBI system depends on: 

The Act and Guidelines consider biometric data to be machine-readable representations of individuals’ measurable physical characteristics – for example, eye distance and size, or nose length – or behavioral characteristics, such as gait or voice print. This is broader than the definition of biometric information provided in Article 4(14) of the GDPR, which defines biometric data as information arising from specific technical processing of physical, physiological, or behavioral characteristics of a natural person in such a way that would permit the unique identification of that person. This last part of the GDPR definition of biometric data (“unique identification”) is absent from the AI Act concept, as further analyzed in Blog 6 and Blog 7 of this series. However, “identification” plays a key part in defining RBI systems.

The function of such a system at a distance and an individual choice to interact with it (or possibly even knowledge of its existence) are at the core of whether a system qualifies as remote. “Identification” is critical in that it is distinguished from “verification”: establishing the identity of a natural person by comparing biometric data of that individual to biometric data of individuals stored in a database as opposed to verifying a specific person is who they claim to be via matching sensor data to an on-device record.  

Per Recital 17 of the AI Act, a system operates in “real time” if it captures and processes biometric data “instantaneously, near-instantaneously or in any event without significant delay.” This determination is a fact-based inquiry, ensuring that an artificial, “minor” delay cannot be incorporated in order to allow a prohibited system to be deployed. The Commission also notes that the same device may well be capable of “real-time” and “post-identification” functions – the prohibition’s application is technology-agnostic.

“Publicly accessible space” is defined in Article 3(44) of the AI Act as “any publicly or privately owned physical space accessible to an undetermined number of natural persons, regardless of whether certain conditions for access may apply, and regardless of the potential capacity restrictions.” The Act and Guidelines emphasize this status is also a fact-based inquiry and cannot be evaded by mere signage or official designation; this component of the prohibition is clearly tied to the potential risk posed by RBI deployments to the exercise of fundamental political freedoms such as the freedom to assemble.

Finally, Article 3(46) of the AI Act defines “law enforcement purpose” as those “activities carried out by law enforcement authorities or on their behalf for the prevention, investigation, detection or prosecution of criminal offences or the execution of criminal penalties, including safeguarding against and preventing threats to public security.” This definition is consistent with the Data Protection in Law Enforcement Directive (LED). The Commission is careful to note in the Guidelines that non-Law Enforcement entities acting on their own behalf to detect crime would not fall afoul of the prohibition, but rather need comply with the Article 6 governance of “high-risk” AI systems. 

4. When is RBI processing for law enforcement permitted?

Recital 33 of the AI Act emphasizes that any exceptions to the prohibition on using RBI systems for law enforcement purposes must be “exhaustively listed and narrowly defined situations.” There are three set out in Article 5(1)(h)(i)-(iii) of the AI Act:

(i) the targeted search for specific victims of abduction, trafficking in human beings or sexual exploitation of human beings, as well as the search for missing persons;

(ii) the prevention of a specific, substantial and imminent threat to the life or physical safety of natural persons or a genuine and present or genuine and foreseeable threat of a terrorist attack;

(iii) the localisation or identification of a person suspected of having committed a criminal offence, for the purpose of conducting a criminal investigation or prosecution or executing a criminal penalty for offences referred to in Annex II and punishable in the Member State concerned by a custodial sentence or a detention order for a maximum period of at least four years.

Article 5(2)-(7) of the AI Act provides additional limitations on the exceptions, expanded on in Section 10 of the Guidelines. Key limitations include:

Each enumerated exception fulfills a public objective – and is consistent with the overall philosophy of both the AI Act and GDPR of balancing the inherent interest of individuals in the exercise of fundamental rights against the risk of significant harm to the public in specific, factual scenarios. The exceptions to the RBI prohibition also represent an area of deference to the Member States, as they do not function automatically and must be authorized by Member State national laws. As a result, all Member States may not permit precisely the same types of RBI system usage in law enforcement contexts.

5. LED, GDPR and additional safeguards – how does the prohibition interact with other laws? 

A significant element of the RBI prohibition is that the prohibited activity is explicitly tied to RBI systems deployed for law enforcement purposes – and law enforcement authorities themselves are, per Article 2(2)(d) of the GDPR, excluded from that scope of that regulation. Instead, national laws implemented by EU Member States to operationalize the LED are the pre-existing restriction on the use of RBI technologies for law enforcement. The Guidelines do specifically observe that, where Member States have made missing persons inquiries an administrative matter and not a criminal one, the Article 5 RBI prohibition would not qualify and the use of RBI systems in such searches would be governed by the GDPR instead.

The use of RBI systems for law enforcement pursuant to a relevant exception is permitted only if the law enforcement authority has completed a fundamental rights impact assessment as provided for in Article 27 of the AI Act (which imposes the obligation to conduct Fundamental Rights Impact Assessments (FRIA) in relation to high-risk AI systems) and has registered the system in the EU database according to Article 49 of the AI Act. A FRIA must generally be completed before an RBI system is deployed – it cannot be created as an after-the-fact rationale for a pre-determined deployment. The Guidelines note that provisions relating to FRIAs apply only to the Article 5 prohibition on RBIs and not to FRIAs required in connection with high-risk AI systems generally, which will also be informed by a future, still-forthcoming guidance document and template for FRIAs, currently expected this year. The Guidelines also highlight that the FRIA requirement does not replace any existing Data Protection Impact Assessment (DPIA) requirement that may be required under provisions of the LED, GDPR, or the Data Protection Regulation of the EU institutions and bodies (EUDPR), depending on the specific system in question. 

The Guidelines attempt to differentiate between a DPIA, which focuses on the risks to rights and freedoms stemming from the processing of individuals’ personal data specifically, and a FRIA, which is a “more general” assessment of how an AI system could impact fundamental rights. The Commission offers additional detail on each of the categories of information a FRIA must contain, which include: 

Article 5(3) of the AI Act imposes a key further limitation on Member States who wish to deploy RBI systems – each individual use of the system must receive prior authorization from either a judicial or independent administrative authority, and automated decision-making producing an adverse legal effect cannot be based solely on a system’s output. This prior authorization requirement has an extremely limited exception for emergency situations where it is “effectively and objectively impossible to obtain an authorization before commencing use” of the RBI system, and in such circumstances that authorization must still be requested within 24 hours of the use of a system. The Commission makes clear that the “double assessment” requirement of both the FRIA and the prior-use “necessity and proportionality” authorization is an intended consequence of the Act. Member States are also provided guidance on the necessity of deleting any data gathered under a use of the “emergency” authorization exception. 

Whether a decision with adverse legal effect is produced solely based on an RBI system’s output, is linked to the human oversight requirements set out in Article 14 of the AI Act. The Commission emphasizes that even with prior authorization, an RBI system may not be deployed where its outputs would produce adverse legal effects (for example, arrest and imprisonment solely on the basis of an individual’s identification by an RBI system, without further checks). Specifically, two natural persons with the necessary competence, training, and authority must separately verify and confirm identification by an RBI system before action is taken on the basis of that identification. Furthermore, each use of an RBI system must be notified to both the market surveillance authority and the national data protection authority. 

6. Relevant Enforcement and Key Takeaways

Pre-AI Act data protection enforcement activity relating to law enforcement use of real-time RBI systems in public spaces has been limited. So far, topically related enforcement has exclusively been directed at private-sector biometric identification activity, notably in the constellation of cases connected to the activities of Clearview AI. Of particular note (and discussed further in Blog 4 and Blog 5 of this series) are enforcement actions by the Dutch DPA rejecting an alleged third-party interest in combating crime as a valid lawful basis for processing biometric data, and by Italy’s Garante finding violations of core data protection principles related to fairness and transparency, both resulting in large fines.  

The requirement for Member State implementation may still cause significant divergence in practice

Because each member state must draft a separate law specifying which of the three exception categories it opts into, which crimes from Annex II it authorizes, and which authority grants case-by-case approval, there is significant effort required before a single deployment can lawfully occur, and because there is no Europe-wide shared definition of serious criminal offenses, operational consequences may vary.

Forthcoming guidelines will be critical to understanding the operational environment

Due to the required “double assessment” structure for deploying RBI systems pursuant to one of the objections, assuming the Member State legal authorization and review process is satisfied, potential deployers will still need to complete the required Fundamental Rights Impact Assessment for any lawful deployment of an RBI system to commence – and the completion of that step will hinge on a template and guidance document that the Commission has not yet published.

Limits are a feature, not a bug

Taken together, the limited exceptions to the RBI prohibition and detailed, overlapping requirements for their use are clearly designed to create an extremely limited environment for authorizing the deployment of RBI systems, subject to significant oversight by actors outside of their operational environments, given the systems’ potential to impact the fundamental rights and freedoms of individuals. This follows the logic of Article 10 of the LED, which permits processing biometric data for uniquely identifying a natural person only where such is strictly necessary and authorized by Member State law.

The Rest of the West: Oregon and Washington Build on California Chatbot Law

Introduction

The West Coast now has a full set of chatbot laws on the books. Following California’s SB 243 (signed in 2025 and effective January 1, 2026) both Oregon (SB 1546) and Washington (HB 2225) enacted companion chatbot laws that will take effect on January 1, 2027. Together, these laws establish a new framework for regulating chatbot interactions with minors.

California’s SB 243 set the stage for regulating chatbots in the U.S., building on earlier legislative momentum (including in New York) to introduce a framework centered on disclosures and safety protocols, such as connecting users to crisis hotlines when they express suicidal ideation. For a deeper dive into SB 243 and its key provisions, see our previous FPF blog post. 

Oregon and Washington retain many of the core elements of SB 243 but take the framework significantly further, expanding into new areas such as content restrictions and engagement design. Washington’s HB 2225, in particular, introduces a more expansive regulatory approach that will likely require companies to make design changes to their chatbots. While these laws are framed around “companion chatbots” and largely focus on minors, their reach may be broader than first appears. Even systems that are not labeled or designed as companion chatbots could be implicated, depending on how they function in practice. 

This blog post compares Oregon’s SB 1546 and Washington’s HB 2225, while providing context from California’s SB 243, across the laws’ scope, requirements, and enforcement. While the laws are similarly scoped, their requirements diverge in meaningful ways, creating potential compliance challenges (especially where provisions are ambiguous or require interpretation). Key takeaways include:

For additional context, see our FPF chatbot legislative tracker and our prior analysis of the 2026 chatbot legislative landscape. We have also developed a detailed comparison chart of SB 243, SB 1546, and HB 2225, available here.

Comparison Chart: CA’s SB 243, OR’s SB 1546, and WA’s HB 2225

Why These Differences Matter

The differences across these laws are important because their scopes are similar enough that many chatbot operators will need to comply with all three frameworks at once. In practice, this means navigating overlapping (but not identical) requirements across jurisdictions.

Oregon and Washington introduce more detailed and intervention-oriented requirements, including limits on engagement techniques, broader content restrictions, and more prescriptive safety obligations. These shifts move beyond the user-facing disclosures of SB 243 and into how chatbot systems are designed and operate in practice. At the same time, the laws are not fully aligned. Operators may need to navigate differences in definitions, thresholds, and obligations, often working across legislative language that remains open to interpretation. This ambiguity could lead to inconsistent implementation or push companies toward adopting the most restrictive standard across jurisdictions.

These differences are particularly important as chatbot legislation continues to be enacted in 2026. With dozens of similar bills under consideration across states and at the federal level, Oregon’s and Washington’s approaches may signal how this policy space is evolving and how future requirements may appear in other states.

Scope: Companion Chatbot

“Companion chatbot” may seem like a narrow category, but in practice, these laws may sweep in more systems than many operators might expect. 

California and Washington adopt capability-based definitions, focusing on whether a system can generate human-like, relationship-sustaining interactions. California goes slightly further by including systems capable of meeting a user’s “social needs,” which may expand scope even more. Because capability (not intent) is the trigger for which AI tools are in scope, multipurpose tools (e.g., tutoring systems, coaching assistants, general-purpose chatbots) could fall within the law even if companionship is not their primary function. 

Oregon, by contrast, uses a behavior-based definition (similar to New York’s S-3008C), requiring a system to actually exhibit certain relational behaviors, such as retaining user information across sessions, initiating emotional dialogue, and sustaining ongoing personal conversations. This definition is somewhat narrower, as it focuses on how the system operates in practice rather than what it is capable of doing. However, all three approaches still raise scope challenges. Even under Oregon’s slightly narrower model, chatbots that have a certain level of user interaction and/or personalization may meet this behavioral threshold, meaning tools not designed or marketed as “companions” could be subject to the law.

All three laws attempt to limit overbreadth through carve-outs (e.g., customer service tools, video game features, voice assistants), but Oregon and Washington include more detailed exceptions. Oregon uniquely excludes systems supporting patient or resident care services, narrowing scope in some healthcare contexts. Washington, meanwhile, excludes narrowly tailored educational tools, but only where they do not provide open-ended conversational companionship. This caveat may still leave more advanced or interactive AI tutoring systems in scope.

Requirements 

  1. Disclosures

All three laws rely heavily on disclosures, but they take different approaches to when and how those disclosures must be delivered. At a high level, California and Oregon use a perception-based trigger for disclosures to all chatbot users: disclosure is required when a reasonable person would believe (or be misled into believing) they are interacting with a human. Washington, by contrast, requires disclosure with clear timing requirements: at the start of an interaction and at regular intervals (at least every three hours). This makes Washington both broader in application and more prescriptive in practice, while California and Oregon offer more flexibility but less clarity on timing.

These differences become more pronounced in the minor-specific disclosure requirements. All three laws impose additional disclosures for minors but vary in knowledge standards and when these enhanced disclosures for minors are triggered:

The laws also diverge on timing and format for these minor-specific disclosures. California and Oregon require disclosures every three hours and include a “take a break” reminder, while Washington requires disclosures every hour for minors but does not include a break prompt. Washington’s shorter interval may be more protective, but it also introduces practical challenges: companies may need to shift between different disclosure cadences depending on user age, which could push some operators toward adopting a uniform (and more frequent) standard across all users set at the one-hour interval. California’s reference to “continuing” interactions further complicates compliance. As drafted, it is unclear what constitutes a break in continuity, such as periods of user inactivity or leaving and reentering an interaction. For example, it is not clear whether a brief pause (e.g., a user stepping away for several minutes to use the restroom before returning to the chat) would remain part of the same interaction or reset the notice requirement. 

Finally, the laws differ in how far they move beyond basic disclosure. California uniquely requires a “suitability” warning that chatbots may not be appropriate for some minors, adding an extra layer of consumer-facing transparency. Washington, on the other hand, requires system-level safeguards to prevent misrepresentation, such as prohibiting chatbots from claiming to be human. This marks a shift from disclosure to design, requiring operators to adapt their chatbot to ensure no “output” claims that the chatbot is human.

  1. Safety Protocols

At a baseline, all three laws require systems to detect signals of self-harm or suicidal ideation and direct users to crisis resources (such as the 988 hotline), establishing a shared expectation that chatbots must respond to users in distress.

The laws diverge, however, in how expansive these requirements are. Oregon is the most prescriptive, outlining what protocols must include, such as escalation through “additional intervention” if a user continues expressing distress. But the law does not define what that “intervention” entails, leaving open whether operators are expected to go beyond providing resources and take a more active role in mitigating harm. This ambiguity is notable in light of prior legislative proposals. For example, earlier (un-enacted) legislation in Virginia (SB 796) would have required operators to make reasonable efforts to notify emergency services or law enforcement in certain high-risk situations, an approach that raised significant concerns around privacy and user safety. While Oregon does not include such explicit requirements, the open-ended nature of “additional intervention” raises similar questions about the scope of an operator’s responsibility.

Oregon also expands scope by including self-harm “intent” in addition to ideation, potentially requiring more proactive detection of user risk. Because intent may not always be explicitly stated, this could require reliance on inferred signals from user interactions, again raising both implementation and privacy considerations.

Notably, Washington is the only law to define “self-harm,” but does so narrowly as “intentional self-injury, with or without intent to cause death.” This definition leaves uncertainty around what specific behaviors or signals must be identified, especially when indications are inferred from user context rather than explicitly stated. As a result, operators may face challenges complying with all three laws and determining when intervention obligations (e.g., connecting users to crisis hotlines) are triggered.

Other key differences include:

  1. Content Restrictions for Minors

Oregon goes beyond the other laws by imposing a broader set of content restrictions on chatbot interactions with minors. Across the laws, there is a shared baseline: operators must prevent chatbots from generating sexually explicit content involving minors. However, the scope of what is restricted differs. California takes the narrowest approach, prohibiting visual sexually explicit material and outputs that “directly state” a minor should engage in such conduct. Oregon expands this to content that “suggests or states” such conduct, capturing a wider range of dialogue. Washington goes further by prohibiting not only explicit content, but also “suggestive dialogue” with minors, an even broader and more ambiguous category. “Suggestive” is inherently subjective and context-dependent. This phrase may make it harder for operators to determine what content is prohibited and could lead to more conservative moderation to reduce operators’ compliance risk. 

Beyond sexually explicit content, Oregon is the only law to impose broader behavioral restrictions, including a prohibition on outputs that “simulate emotional dependence.” This requirement moves beyond easily identifiable categories of content (e.g., sexually explicit content) into the nature of the relationship between the user and the system, which is more interpretive. While the policy intent is clear (preventing harmful attachment or manipulation), the phrase is open-ended and not defined, potentially capturing a wide range of common chatbot behaviors.

Together, these provisions signal a shift toward regulating not just what chatbots say, but how they interact with users, introducing greater ambiguity and operational complexity for compliance.

  1. Minor Engagement Optimization Restrictions

Oregon and Washington’s chatbot laws are both notable for taking a step toward regulating engagement optimization with minors, an area California does not address at all. While both states introduce these requirements, Washington’s approach is significantly more expansive. Oregon primarily targets reward-based mechanisms designed to reinforce or prolong user engagement. Washington, by contrast, regulates a wide range of interaction patterns, including excessive praise, mimicking emotional or romantic relationships, discouraging breaks, promoting isolation, and encouraging gift-giving/ expenditures tied to the chatbot relationship.

This broader scope means Washington’s law may require more significant design changes and ongoing judgment calls from operators. Many of Washington’s provisions are subjective and difficult to operationalize. Terms like “excessive praise” or outputs designed to “prolong use” are not defined, and could capture a wide range of otherwise benign interactions.

Several notable provisions include:

Overall, this section of Washington’s law reflects a shift toward regulating engagement design itself, not just content or disclosures. While this approach may offer stronger protections for minors, it also introduces some ambiguity and operational complexity for companies attempting to comply.

Enforcement

All three laws are notable for relying on private rights of action (PRA), a departure from most chatbot bills proposed this year, which primarily rely on state AG enforcement. This trend raises an important question: do these laws signal a shift toward PRAs in the chatbot space or are they outliers in an otherwise AG enforcement-driven landscape? California and Oregon take a similar approach, allowing individuals to bring claims with statutory damages of $1,000 per violation (or actual damages). Washington takes a different route by incorporating violations into its Consumer Protection Act, allowing private enforcement but without explicit statutory damages. As a result, California and Oregon may create stronger incentives for litigation and greater potential exposure for companies.

Beyond enforcement structure, there are also differences in how resilient these laws may be to legal challenges. Both California and Washington include severability clauses, while Oregon does not. Severability allows portions of a law to remain in effect if others are struck down, an important consideration in the chatbot regulatory space, where laws may face challenges on First Amendment or preemption grounds. As legal challenges possibly emerge in the coming months, they may help determine how important these severability clauses are in preserving chatbot regulatory frameworks.

Looking Ahead

Oregon and Washington may be the first chatbot laws of 2026, but they are unlikely to be the last. Idaho (S 1297) recently enacted its own chatbot law, while Georgia’s chatbot bill (SB 540) is awaiting gubernatorial action. Dozens of the nearly 100 chatbot bills introduced this year also continue to move through the legislative process. At the federal level, proposals like the SAFE Bots Act (within the KIDS Act), Sen. Hawley’s (R-MO) GUARD Act and Sen. Husted’s (R-OH) CHAT Act signal growing momentum for chatbot regulation in Congress.  For more insights on proposed and enacted chatbot laws, see FPF’s weekly updated chatbot tracker. 

What’s notable is not just this volume of activity but the increasing divergence in regulatory approaches. For example, Georgia’s SB 540 introduces requirements not found in the West Coast laws, including risk-based age assurance to access chatbots that may contain sexually explicit conduct and parental control tools to manage minors’ privacy and safety settings. Similarly, newly proposed companion bills in California (AB 2023 and SB 1119) include novel provisions banning targeted advertising restrictions for minors, imposing risk assessment and testing requirements, and offering parental tools with features like time limits on chatbot use.

These developments emphasize that chatbot regulation is shifting beyond disclosure-based frameworks toward more intervention-oriented, design-focused approaches. As more laws are enacted, operators will need to track not just whether they are in scope but how requirements diverge across jurisdictions, often in ways that are operationally significant.

Red Lines under the EU AI Act: Understanding the prohibition of biometric categorization for certain sensitive characteristics 

Blog 7 | Red Lines under the EU AI Act Series

This blog is the seventh of a series that explores prohibited AI practices under the EU AI Act and their interplay with existing EU law. You can find the whole series here.

The EU AI Act provides for rules on prohibited AI practices that the legislature considers incompatible with fundamental rights and European Union values. Article 5(1)(g) introduces a prohibition on the biometric categorization for “certain sensitive characteristics”, focusing on systems used to categorize individuals “based on their biometric data to deduce or infer their race, political opinions, trade union membership, religious or philosophical beliefs, sex-life or sexual orientation”. 

The European Commission guidelines on prohibited AI practices (hereinafter, “the Guidelines”) note that information, including sensitive data, can be extracted, deduced, or inferred from biometric data with or without the individual’s knowledge, leading to unfair or discriminatory treatment that undermines human dignity, privacy, and the principle of non-discrimination protected under the EU acquis. This provision also reflects longstanding concerns with regard to the risks associated with processing sensitive personal data, particularly where such processing may take place without the knowledge of the individual. 

With this in mind, Section 1 unpacks the (limited) scope and key definitions of the prohibition, including the cumulative conditions required for the provision to apply. Section 2 takes a look at the situations that fall outside the scope of the prohibition, and, finally, Section 3 explores the interaction between the biometric categorization prohibition and the existing EU legal framework. 

Several key takeaways emerge: 

1. (Limited) Scope and key definitions

To trigger the prohibition under Article 5(1)(g) AI Act, five cumulative conditions must be simultaneously met: 

  1. The AI system must be placed on the market, put into service, or used.
  2. The AI system must be a biometric categorization system. 
  3. The AI system must categorize individuals.
  4. The AI system must categorize individuals based on their biometric data.
  5. The AI system must infer sensitive characteristics (e.g., race, political opinions, religious beliefs, and so on). 

The first condition, relating to the placing on the market, putting into service or use of an AI system, applies to both providers and deployers within their respective responsibilities. The Guidelines also clarify that the prohibition does not cover the labelling or filtering of lawfully acquired biometric datasets, including for law enforcement purposes.

The requirement that all five conditions be fulfilled simultaneously is likely to be significant in practice. It may limit the scope of the prohibition and it raises questions about how it will be applied in specific cases, particularly where systems are designed to avoid explicit inference of sensitive traits while still enabling similar outcomes.

1.1 Defining biometric categorization

Biometric categorization refers to assigning individuals to predefined groups based on their biometric data, rather than identifying or verifying their identity. Such categorization may be used, for example, to display targeted advertising or for statistical purposes, without necessarily identifying the individual. 

Article 3(40) AI Act defines a biometric categorization system as an AI system that assigns natural persons to specific categories based on their biometric data, unless this function is ancillary to another commercial service and strictly necessary for objective technical reasons. Biometric data, defined in Article 3(34) AI Act, includes behavioural characteristics based on biometric features. As discussed in a previous blog, this definition is broader than the definition of biometric data in the GDPR. Categorization based on clothing, accessories, or social media activity falls outside the scope of biometric categorization under the AI Act.

The Guidelines further clarify that biometric categorization may involve categories based on physical characteristics such as facial structure or skin colour, some of which may correspond to sensitive characteristics protected under EU non-discrimination law. At the same time, the AI Act definition contains an important limitation: a system will not fall within the definition where the categorization is ancillary to another commercial service and strictly necessary for objective technical reasons. According to Recital 16 AI Act, an ancillary feature is one that is intrinsically linked to another commercial service and cannot be used independently of that service.

The Guidelines provide several examples to illustrate this distinction. For instance, filters that categorize facial or bodily features on online marketplaces, allowing consumers to preview a product on themselves, may constitute an ancillary feature because they are linked to the principal service of selling a product. Similarly, filters integrated into social media platforms that allow users to modify images or videos may also be considered ancillary features because they cannot be used independently of the platform’s content-sharing service.

The Guidelines also identify examples of systems that would fall within the prohibition. These include AI systems that analyse biometric data from photographs uploaded to social media platforms to categorize individuals by their assumed political orientation and send them targeted political messages. Another example concerns AI systems that analyse biometric data from photos to infer a person’s sexual orientation and use that information to serve targeted advertising. In both cases, the categorization would not be strictly necessary for objective technical reasons and therefore would fall within the definition of biometric categorization under the AI Act. Importantly, the systems that perform such categorization need to fall under the definition of “AI system” pursuant the AI Act for the prohibition to apply.

The risks associated with biometric categorization also reflect broader concerns under EU data protection law. The EDPB has clarified that inferences about sensitive characteristics may themselves constitute special categories of personal data under Article 9 GDPR. Also, the Court of Justice of the European Union has held that processing which allows information falling within Article 9(1) GDPR categories to be revealed must be regarded as processing of special categories of personal data (Meta Platforms and Others, C-252/21). However, the prohibition to process sensitive data under the GDPR has several exceptions, such as explicit consent. 

The EDPB and the European Data Protection Supervisor (EDPS) have taken a similar position in their Joint Opinion 5/2021 on the Proposal for the AI Act. They called for a broader prohibition of certain biometric AI practices. In particular, they called for a general ban on the use of AI for automated recognition of human features in publicly accessible spaces, including faces, gait, fingerprints, DNA, voice, and other biometric and behavioural signals.

1.2 For the prohibition to apply, categorization must take place at the level of the individual

Another essential condition for the prohibition to apply is that the system must categorize individual natural persons based on their biometric data. Importantly, the categorization must take place at the level of the individual. If biometric analysis is performed without categorizing specific individuals, the prohibition does not apply. For example, the prohibition would not be triggered where a system analyzes biometric information only to categorize an entire group without identifying or singling out individual persons. These include AI systems that conduct “attribute estimation”, sometimes referred to as demographic analysis, by assigning characteristics such as age, gender or ethnicity based on biometric features such as facial characteristics, height or skin, eye or hair colour, or other features such as a visible scar or distinctive tattoo.

1.3 “Sensitive characteristics” under the AI Act

The prohibition under Article 5(1)(g) AI Act applies only when a biometric categorization system is used to deduce or infer specific sensitive characteristics, such as: race, political opinions, trade union membership, religious or philosophical beliefs, sex life, or sexual orientation.

This means that not all biometric categorization systems fall within the scope of the prohibition. Rather, the prohibition targets systems that attempt to derive particularly sensitive characteristics from biometric data.

For example, a system that claims to infer an individual’s race from their voice would fall within the scope of the prohibition. By contrast, a system that categorizes individuals according to physical traits such as skin or eye colour, or a system analysing the DNA of crime victims to determine their origin, would not be prohibited under Article 5(1)(g). Another example provided by the Guidelines concerns a biometric categorization system that claims to infer a person’s religious orientation from tattoos or facial characteristics would fall within the prohibition.

2. Biometric categorization for bias detection: What falls outside the scope of the prohibition?

The prohibition in Article 5(1)(g) AI Act does not apply to all uses of biometric categorization. In particular, it does not cover AI systems used for the labelling or filtering of lawfully acquired biometric datasets, including in law enforcement contexts. As explained in Recital 30 AI Act, such uses may include sorting images by biometric characteristics, such as hair or eye colour.

The Guidelines note that labelling or filtering biometric datasets may be necessary to ensure that datasets used to train AI systems are representative across demographic groups. Where training data contains systematic differences between groups, for example, due to historical bias in data collection, algorithms may replicate those biases and potentially lead to discriminatory outcomes. In such cases, labelling data according to certain characteristics may be necessary to improve data quality and prevent discrimination. In some circumstances, the AI Act may even require such labelling operations in order to comply with the requirements applicable to high-risk AI systems (see Article 10 AI Act).

The Guidelines provide several examples of permissible uses. One example concerns the labelling of biometric data to prevent recruitment algorithms from disadvantaging individuals from certain ethnic groups, where historical training data reflects biased outcomes. Another example involves categorizing patients’ images by skin or eye colour, which may be relevant to medical diagnosis, including certain cancer diagnoses.

The exception also applies in law enforcement contexts where biometric datasets have been lawfully acquired. For example, law enforcement authorities may use AI systems to label or filter datasets suspected of containing child sexual abuse material. Such systems may help detect and redact sensitive information in images or assist investigations by labelling biometric features such as gender, age, eye or hair colour, scars, markings, or tattoos in order to identify victims or establish links between cases. Similarly, filtering and labelling features such as hand characteristics or distinctive tattoos may help identify possible suspects in law enforcement contexts.

3. Interplay with other EU laws

This prohibition must be understood in the context of the existing EU data protection framework. 

Interestingly to note, the Guidelines refer to an earlier explanation provided by the Article 29 Working Party (the precursor to the EDPB) when describing “biometric categorization” in the Opinion on developments in biometric technologies. Article 3(40) AI Act provides a legal definition, describing a biometric categorization system as an AI system that assigns natural persons to specific categories on the basis of their biometric data, while also specifying an exclusion where such categorization is ancillary to another commercial service and strictly necessary for objective technical reasons. 

By contrast, the Article 29 Working Party explains biometric categorization as the process of determining whether the biometric data of an individual belongs to a group with predefined characteristics, emphasizing that the objective is not to identify or verify the individual but to assign them automatically to a category, for example, to display different advertisements depending on the perceived age or gender of the person. While both definitions describe categorization based on biometric data rather than identification, the AI Act establishes a regulatory definition determining the scope of the prohibition, whereas the Article 29 Working Party description provides a conceptual explanation of how biometric categorization systems operate in practice.

Furthermore, Article 9(1) GDPR establishes a general prohibition on the processing of special categories of personal data, subject to exceptions, which might see some processing of biometric data in the context of biometric categorisation lawful under the GDPR, as long as it respects its strict provisions. The AI Act introduces an additional layer of restriction, which raises important conflict of law questions with the GDPR. As analyzed in the first blog of this series, the GDPR takes priority in application (the AI Act “shall not affect” the GDPR). Further guidance on the intersection of the GDPR and the AI Act in this respect is needed. 

The Guidelines clarify that AI systems intended to categorize individuals based on biometric data to infer attributes protected under Article 9(1) GDPR are classified as high-risk AI systems, provided they are not already prohibited under Article 5 AI Act. At the same time, Article 5(1)(g) further limits the possibilities for lawful processing of personal data under EU data protection law, including the GDPR, the Law Enforcement Directive (LED), and Regulation (EU) 2018/1725 (EUDPR). In particular, the provision excludes the use of biometric data to categorize natural persons in order to infer sensitive characteristics such as race, political opinions, trade union membership, religious or philosophical beliefs, sex life or sexual orientation, subject to the limited exception for the labelling or filtering of lawfully acquired biometric datasets.

The prohibition is also consistent with Article 11(3) LED, which explicitly prohibits profiling that results in discrimination on the basis of special categories of personal data, including race, ethnic origin, political opinions, religious beliefs or sexual orientation.

4. Closing reflections and key takeaways

The AI Act prohibits specific biometric inference practices, not biometric categorization as such

Article 5(1)(g) AI Act does not prohibit biometric categorization in general. It prohibits the placing on the market, putting into service, or use of AI systems that categorize individuals based on biometric data for the purpose of inferring certain sensitive characteristics, such as race, political opinions, religious beliefs, trade union membership, sex life or sexual orientation. The prohibition applies only where all cumulative conditions of Article 5(1)(g) are met. This means that many forms of biometric categorization such as categorization based on non-sensitive physical traits or for purposes that do not involve inferring the listed characteristics, do not fall within the prohibition.

The objective and design of the system are central to determining whether the prohibition applies

The Guidelines place significant emphasis on the purpose and functionality of the AI system, in particular, whether the system is designed to deduce or infer one of the sensitive characteristics listed in the provision. This means that the prohibition is not triggered only by the presence of biometric analysis, but by the intended inference of protected attributes from biometric data. The examples provided in the Guidelines illustrate this distinction: systems that claim to infer race from voice or religious beliefs from facial features would fall within the prohibition, whereas systems categorizing individuals based on traits such as eye or hair colour would not.

Context and use matter for determining the scope of the prohibition

The prohibition applies only where individuals are individually categorized based on their biometric data, and where the categorization results in the inference of the listed sensitive characteristics. Systems that analyse biometric data at an aggregated level without singling out individuals would not meet this condition. Similarly, the AI Act explicitly excludes certain practices from the scope of the prohibition, including the labelling or filtering of lawfully acquired biometric datasets, for example, where such operations are carried out to improve dataset quality, mitigate bias in AI training data, support medical diagnosis or assist law enforcement investigations.

The relationship between this prohibition and EU data protection law needs further clarification

Finally, the prohibition must be understood in the broader context of EU data protection and non-discrimination law. The GDPR already restricts the processing of special categories of personal data under Article 9(1), while the AI Act introduces an additional regulatory layer by prohibiting certain biometric inference practices altogether. Given that the AI Act itself establishes that it does not affect the GDPR, further guidance is needed for those cases where processing of biometric data would be lawful under Article 9(2) GDPR, but prohibited under the AI Act. 

2026 Chatbot Legislation Tracker

Co-authored by Rafal Fryc

With nearly 100 chatbot-specific bills introduced across states in 2026, a complex and increasingly fragmented compliance landscape is quickly emerging. This tracker helps stakeholders understand that landscape by highlighting chatbot legislation advancing through initial chambers in state legislatures and Congress, and organizing key provisions across proposals to show what is coming and how requirements may vary across jurisdictions. The tracker is updated on Thursdays to reflect legislative movement and amendments.

View the Chatbot Legislation Tracker Here

This tracker highlights chatbot-related legislation advancing through U.S. state legislatures and Congress in 2026. It includes bills that have passed at least one legislative chamber and is updated weekly to reflect movement and amendments. This tracker reflects a subset of FPF’s broader legislative tracking work. FPF members receive access to comprehensive tracking across the full AI policy landscape, including all chatbot and AI-related legislation. To learn more about corporate membership, visit FPF’s Become a Member page.

Red Lines under EU AI Act: Unpacking the prohibition of emotion recognition in the workplace and education institutions

Blog 6 | Red Lines under the EU AI Act Series

This blog is the sixth of a series that explores prohibited AI practices under the EU AI Act and their interplay with existing EU law. You can find the whole series here.

The sixth blog in the “Red lines under the EU AI Act” series focuses on unpacking the prohibition on emotion recognition in the workplace and educational institutions, as contained in Article 5(1)(f) AI Act and explored in the Commission’s Guidelines on the topic. This analysis revealed a number of key takeaways:

Article 5(1)(f) AI Act prohibits AI systems from inferring the emotions of a natural person in the workplace and education institutions based on biometric data, with specific exceptions for medical and safety purposes. Recital 44 AI Act invokes the lack of scientific basis for the functioning of such systems and the key shortcomings such as limited reliability, the lack of specificity and the limited generalisability, which may lead to discriminatory outcomes and can be intrusive to the rights and freedoms of the concerned persons. 

Acknowledging the power imbalances in these environments which, combined with the intrusive nature of these systems, could lead to detrimental or unfavorable treatment of certain natural persons or whole groups, this prohibition aims to protect individuals from potentially invasive emotional surveillance. It is important here to note that AI systems for emotion recognition that are not put into use in the areas of workplace or educational institutions do not fall within the scope of this prohibition and qualify as ‘high risk’ under Annex III, paragraph 1, subparagraph c of the AI Act.

It is unclear whether AI systems that do not have as a primary aim the identification or inference of emotions, but have emotion identification or inference as a secondary functionality, are covered by the prohibition. For example, an AI system primarily intended for transcribing meetings that can also infer emotions or intentions, or an AI system that monitors students during a test, but at the same time also identifies emotions.  

1. Limited scope: The provision does not prohibit ‘emotion recognition systems’, but only ‘AI systems to infer emotions’

The Guidelines highlight that the prohibition in Article 5(1)(f) AI Act does not refer to emotion recognition systems more generally, but only to “AI systems to infer emotions of a natural person”. 

Article 3(39) AI Act defines an ‘emotion recognition system’ as “an AI system for the purpose of identifying or inferring emotions or intentions of natural persons on the basis of their biometric data”. Three elements can be identified in this definition:

  1. The AI system must be used for identifying or inferring; 
  2. Emotions or intentions of natural persons;
  3. Based on the biometric data of natural persons.

Hence, the target of these AI systems are emotions and intentions of individuals, which might be identified or inferred (a lower threshold). The identification or inference must be based on biometric data of the individuals. This definition seems to cover the use of emotion recognition on individuals, leaving out groups. 

The prohibition in Article 5(1)(f) AI Act does not refer to ‘emotion recognition systems’, but only to ‘AI systems to infer emotions of a natural person’. Recital 44 further clarifies that prohibition covers AI systems ‘to identify or infer emotions.’ ‘Intensions’ are not mentioned either in the Article 5(1)(f), nor in Recital 44. Hence, it appears that while the definition of ‘emotion recognition systems’ provided in Article 3(39) can serve as a reference point for this prohibition, it does not equate to what the prohibition covers, the prohibition being narrower in scope.

Certain cumulative conditions must be fulfilled for the prohibition to apply:

  1. The practice must constitute the “placing on the market”, “putting into service for this specific purpose,” or the “use” of an AI system;
  2. The AI system is used specifically to infer emotions;
  3. The AI system is in the area of the workplace or education and training institutions; 
  4. AI systems intended for medical or safety reasons are excluded from the prohibition.

All the cumulative conditions listed above must be met simultaneously to trigger the prohibition, a consistent approach of the AI Act’s full set of prohibited practices, an approach which narrows down the scope of the prohibition to very specific use cases.

Recital 18 AI Act provides a non-exhaustive list of emotions referred to in this definition, including happiness, sadness, anger, surprise, disgust, embarrassment, excitement, shame, contempt, satisfaction, and amusement. The Recital clarifies that physical states, such as pain or fatigue, are not included in this definition. For example, systems used to detect fatigue in professional pilots or drivers for the purpose of preventing accidents are explicitly excluded from this definition. The mere detection of “readily apparent expressions, gestures, or movements” such as basic facial expressions, such as a frown or a smile, or gestures such as the movement of hands, arms, or head, or characteristics of a person’s voice, such as a raised voice or whispering, are not included either unless they are used for identifying or inferring emotions. The Guidelines further clarify that inferring emotions from a written text does not fall within the scope of the prohibition. 

What is left unclear with regard to the prohibition’s scope is that there is a thin line between emotions, other readily apparent expressions, and pain or fatigue, which also result in expressions that can be mistaken for emotions. The distinction between mood and emotion (both of which can manifest in different ways) is similarly not made, making it unclear whether mood detection falls within this prohibition. The distinction between these features would require a detailed analysis of many factors and circumstances on a case-by-case basis, rather than only biometric data, making the application of this prohibition in practice challenging and complex.

2. It is unclear whether the inference of intentions is also prohibited

The AI Act does not provide clarification on what it means by ‘intentions’ and how to differentiate them from ‘emotions’ in cases when the same system can identify both. This distinction is important because the prohibition applies only to emotions and does not refer to intentions, whereas the definition of ‘emotion recognition systems’ applies to both. 

None of the examples provided in Recital 18 seems to fall within the notion of intentions. While the emotions listed in this Recital represent reactions to situations or environments, the notion of ‘intention’ would have a predictive quality about the future. Additionally, the Commission Guidelines seem to focus solely on emotions, without providing any clarification or definition of ‘intentions’. However, in a non-exhaustive list of examples of emotion recognition, they include the example of “Systems inferring from voice or body gestures, that a student is furious and about to become violent”. While ‘furious’ seems to fall within the notion of ‘emotion’, ‘about to become violent’ makes a prediction about a future action based on the (automatically) detected emotion. This prediction might fall within the notion of ‘intention’ to commit an action in the future but it might also be considered as an identification of the transition from a passive state (emotions) to active (a combination of emotions and intentions), making it difficult to understand whether such a prediction falls within the prohibition. The Guidelines, however, do not seem to make such a distinction. 

An example of ‘intentions’ in the workplace could be the detection of an employee’s intention to resign from the job based on their facial expressions during meetings or videocalls. A wide range of intentions, such as intentions to commit a crime, intentions to drop out of school, or even suicidal intentions could fall within this prohibition when detected in the area of the workplace or education. The Guidelines also note that the concept of emotions or intentions should be understood in a broad sense, noting that attitude and emotion are equivalent for the purposes of this prohibition, thus preventing circumvention through changes in terminology.

Another distinction of the prohibition from the definition of ‘emotion recognition systems’ is that the prohibition refers only to the ‘inference of emotions’ as a prohibited practice, whereas the definition of ‘emotion recognition systems’ includes both ‘identification’ and ‘inference’ of emotions.

The Dutch Data Protection Authority (AP) interprets the prohibition as covering both the inference and the identification of emotions and intentions. The Guidelines distinguish between “identification” and “inferring”, clarifying that identification occurs where the processing of the biometric data (for example, of the voice or a facial expression) of a natural person allows to directly compare and identify an emotion with one that has been pre-programmed in the emotion recognition system. “Inferring” involves deduction through analytical processes, including machine learning approaches that learn from data how to detect emotions. 

3.  The prohibition refers only to emotions deriving strictly from biometric data

According to the Guidelines, this prohibition has a similar scope as the rules applicable to other emotion recognition systems1, while it should be limited to inferences based on a person’s biometric data, as defined in Article 3(39) AI Act. Hence, the prohibition in Article 5(1)(f) refers only to emotions deriving strictly from biometric data. 

Biometric data is defined in Article 3(34) AI Act as “personal data resulting from specific technical processing relating to the physical, physiological or behavioural characteristics of a natural person, such as facial images or dactyloscopic data”. The relationship between the AI Act definition of biometric data and that provided in the GDPR is explored below in section 6 of this blog.

The limited scope of this ban on inference based on biometric data excludes AI systems that perform emotion recognition through other inferences not on the basis of biometric data such as AI systems for crowd control, and AI systems inferring physical states such as pain and fatigue.

4. A broad interpretation of the ‘workplace’ and ‘education institutions’ contexts

The prohibition in Article 5(1)(f) AI Act is limited to emotion recognition systems specifically in the “areas of workplace and educational institutions”. The Guidelines submit that the workplace context should be interpreted broadly, covering any physical or virtual space where the work is performed. The Guidelines also specifically mention training institutions as covered by this prohibition. Training institutions are not mentioned in the AI Act’s provision or any of the related Recitals. Besides simply listing training institutions alongside educational institutions, the guidelines do not provide any further details as to what constitutes training institutions.

Interestingly, the Guidelines clarify that hiring processes also fall within the workplace context for the purpose of this prohibition. Similarly, the Guidelines clarify that educational institutions should encompass all types and levels of education, including admissions procedures, and should also be interpreted broadly, without any limit, in terms of the types or ages of pupils or students or of a specific environment.

Based on the text of Recital 44, this prohibition also covers AI systems for emotion recognition in situations related to the workplace and education. This makes the area of applicability of the prohibition broader while leaving space for interpretation as to what “related to the workplace” might consist of. Such an interpretation may require a case-by-case analysis. The Dutch AP has interpreted this broad notion as including for example, home working environments, online or distance learning, and also the application of emotion recognition for recruitment and selection or application for education. Further clarifications with clearer guidelines might be necessary in this regard, for ensuring legal certainty, while keeping in mind the volatile nature of ‘workplace’.

It is important to note that emotion recognition systems installed in a work environment can also be used for emotion detection of customers rather than employees, such as, for example, to detect suspicious customers. The AI Act prohibition does not apply to such cases. However, the same system might detect the emotions of employees simultaneously with those of customers. The guidelines only superficially touch upon this scenario in an example stating that in such cases, it should be ensured that “no employees are being tracked and there are sufficient safeguards”.

5. Exception(s) to the prohibition: medical and safety reasons

In a Joint Opinion on the AI Act, the European Data Protection Board (EDPB) and European Data Protection Supervisor (EDPS) state that the “use of AI to infer emotions of a natural person is highly undesirable and should be prohibited.” In this statement, and in a later EDPS Opinion, they further note that exceptions should be made for “certain well-specified use-cases, namely for health or research purposes”.

The Guidelines note that the exception granted in this prohibition should be narrowly interpreted, limited to what is strictly necessary and proportionate, including limits in time, personal application and scale, and should be accompanied by sufficient safeguards in order to ensure a high-level of fundamental rights protection. The recitals of the AI Act stress that the exception granted in this prohibition applies to AI systems used strictly for medical or safety reasons. For example, a system intended for therapeutic use. As such, therapeutic uses mentioned in Recital 44 AI Act as an exception, should only apply to CE-marked medical devices. The Guidelines note that this exception does not extend to general well-being monitoring, such as stress or burnout detection.

Additionally, the Guidelines note that safety exceptions should be limited to protecting life and health, excluding other interests such as property protection or fraud prevention. “Explicit need” is also mentioned as a requirement for the exception to apply. The Guidelines also highlight that data collected and processed in this context cannot be used for any other purpose, hence linking to the GDPR’s purpose limitation principle.

6. Interplay with the GDPR

The Guidelines mention, in a footnote, that there is a distinction between the definition of biometric data within the AI Act and the definition within the GDPR. The definition provided in the AI Act “does not include the wording ‘which allow or confirm the unique identification’ (the functional use of biometric data), contrary to the definition of biometric data in the GDPR that includes this requirement. As such, the Guidelines conclude that “the GDPR definition of biometric data will apply under data protection rules with regard to the processing of personal data ​​(and when for example Article 9(1) and 9(2) GDPR would be applicable)”. This would mean that the AI Act definition applies in AI contexts, whereas the GDPR definition in data protection contexts. 

When reaching this conclusion, the Commission appears to have disregarded recital 14 of the AI Act, according to which the concept of biometric data in the AI Act must be interpreted “in the light of” the concept of biometric data in the GDPR. The clarification of this gap is crucial given the high bar that needs to be met for unique identification. 

If we stick to the AI Act definition, the notion of ‘biometric data’ becomes broader, including most emotion recognition systems using biometric data that do not necessarily have the ability to identify the individual. These systems would be left out of the prohibition if the GDPR definition of biometric data is to be applied. This raises the question of whether there needs to be a categorization of biometric data for the purposes of Article 5(1)(f), to further clarify the notion of biometric data to be able to determine without doubt which practices count as emotion recognition under this prohibition.

Data protection regulators have already been treating emotion recognition systems, including those in the workplace, as high-risk under data protection law, even before the AI Act became applicable. In the Budapest Bank case, the Hungarian DPA submits that AI emotion recognition in the workplace poses fundamental rights risks and ordered the Bank to modify its data processing practices to comply with the GDPR, specifically by refraining from analyzing emotions during voice analysis. With regard to the emotion recognition of employees based on voice analysis, the DPA stresses the need for a separate balancing of interests, taking into account their vulnerable position resulting from their subordinate status. It can be noticed that the reasoning behind the ban imposed by Article 5(1)(f) of the AI Act is reminiscent of the reasoning in this case.

However, it is interesting to note that in the Budapest Bank case, the DPA did not explicitly classify the voice-derived data as biometric data under Article 9 GDPR. The DPA treated the data as ordinary personal data, attracting heightened scrutiny due to the AI risk, rather than as special category biometric data triggering the application of Article 9 outright. Nevertheless, the Hungarian DPA specifically referenced the EDPB-EDPS Joint Opinion 5/2021 on the AI Act proposal, highlighting that AI-based emotion recognition systems pose a high risk to the fundamental rights of data subjects.

7. Concluding Reflections

The AI Act’s prohibition is consistent with previous case law of DPAs, on the basis of the GDPR

The prohibition’s premise regarding the power imbalance and the vulnerable position of employees and students is reminiscent of a DPA’s fine in a similar case. As such, in the Budapest Bank case of 2022, the Hungarian DPA found that the use of AI for emotion recognition of employees and consumers breached several of the GDPR’s key principles and obligations.

The definition of ‘biometric data’ in the AI Act does not seem to be aligned with the definition of the same concept in the GDPR, creating confusion as to which definition applies in this prohibition.

The Guidelines give precedence to the definition of biometric data in the AI Act for the purpose of Article 5(1)(f) prohibition, whereas the AI Act itself, in its Recital 14, seems to give precedence to the concept of biometric data in the GDPR.

The prohibition expressly differentiates between emotions derived from biometric data and those derived from other types of analysis not involving biometric data, the latter practice being excluded from the prohibition.

Biometric data is defined as “personal data resulting from specific technical processing relating to the physical, physiological or behavioural characteristics of a natural person, such as facial images or dactyloscopic data”. The narrow scope of this ban on inference based on biometric data excludes AI systems that perform emotion recognition through other inferences not on the basis of biometric data.

  1.  See Annex III, point 1(c), and Article 50 AI Act. ↩︎

Privacy Protections Coming Sooner Rather Than Later to the Sooner State

Oklahoma has become the latest U.S. state to enact a comprehensive consumer privacy law after Governor Stitt signed SB 546 into law on March 20. This ends two long legislative droughts: First, this is the long-awaited 20th state comprehensive privacy law and the first since the Rhode Island Data Transparency and Privacy Protection Act was enacted in June 2024. Second, as the bill’s sponsor Rep. West (R) identified in House floor debate, this concluded Oklahoma’s multi-year journey to enacting a comprehensive consumer privacy law. 

SB 546 is a Virginia-style law with few deviations from that model, and it will go into effect on January 1, 2027. This resource provides an overview of the law’s scope, consumer rights, business obligations, and enforcement provisions.

Definitions and Scope

Covered Entities: This law applies to controllers and processors who conduct business in Oklahoma (or produce a product or service targeted to Oklahoma residents) and annually either (1) control or process the personal data of at least 100K consumers, or (b) control or process the personal data of at least 25K consumers and derive over 50% of gross revenue from selling personal data. (Section 15.) These numbers are consistent with the thresholds established in other states. 

Definitions: The law’s definitions are generally consistent with the Virginia model. For example, this law includes the narrower definition of “sale,” which is limited to exchanges of personal data only for monetary consideration (not other valuable consideration). One divergence from the Virginia-model is that the definition of “biometric data” includes data generated from a physical or digital photograph or a video or audio recording if such data is generated to identify a specific individual. (Section 1.)

Entity and Data-Level Exemptions: The law includes entity-level exemptions for state agencies and political subdivisions (and service providers acting on their behalf), financial institutions subject to Title V of GLBA, covered entities and business associates governed by HIPAA, nonprofits, and institutions of higher education. The law also includes data-level exemptions for data subject to GLBA, HIPAA, FCRA, and FERPA, personal data processed in the course of a purely personal or household activity, personal data collected and used for purposes of the federal policy under the Controlled Substances Act, and more. (Sections 15–16.)

Exceptions for Common Business Activities: The law includes many exceptions which are consistent with existing state comprehensive privacy laws, including: legal compliance (local, state, or federal laws, rules or regulations,and government subpoenas, summons, inquiries or investigations); providing a specifically requested product or service; preventing, detecting, protecting against or responding to security incidents, deceptive activities, or any illegal activity; engaging in public or peer-reviewed scientific or statistical research in the public interest; conducting “internal operations” that are reasonably aligned with the consumer’s expectations, existing relationship with the controller, or are otherwise compatible with processing data in furtherance of the provision of a specifically requested product or service; and more. (Section 19.)

Consumer Rights

Consumers have the standard rights to confirm whether a controller is processing their personal data and access that data, correct inaccuracies in their personal data, delete their personal data, obtain a copy of their personal data in a portable format (if technically feasible), and to opt-out of the processing of their personal data for targeted advertising, the sale of personal data, or profiling in furtherance of a decision that produces a legal or similarly significant effect concerning the consumer. Controllers must notify consumers within 45 days if they are declining to take action on a rights request and provide instructions on how to appeal that decision. The law does not include any provisions regarding authorized agents or opt-out preference signals. (Sections 2-3.)

Consistent with most other state laws, the rights of access, correction, deletion, and portability do not apply to pseudonymous data in cases where the controller can demonstrate that any information necessary to identify the consumer is kept separately and is subject to effective technical and organizational controls preventing the controller from accessing the information. (Section 11.)

Business Obligations

Controllers and processors have enumerated responsibilities under the law, including transparency, data minimization, data security, oversight of processors, and data protection assessments. 

Transparency: Controllers must provide consumers with a “reasonably accessible and clear” privacy notice including information such as categories of data processed, processing purposes, how to exercise rights and appeal decisions, and categories of personal data shared with third parties. (Section 8).

Data Minimization: The law includes procedural data minimization and purpose limitation requirements: A controller must limit the collection of personal data to what is “adequate, relevant, and reasonably necessary” for the purposes disclosed to the individual, obtain opt-in consent to process personal data for purposes that are “neither reasonably necessary to nor compatible with the disclosed purposes for which the personal data is processed,” and must obtain opt-in consent to process a consumer’s sensitive data. (Section 7.)

Data Security: Controllers must maintain “reasonable administrative, technical, and physical measures to protect the confidentiality, integrity, and accessibility” of personal data. (Section 7.)

Processors: Controllers must engage in oversight of processors by entering into a contract that meets statutory criteria, such as setting forth instructions for processing data, the nature and purpose of the processing, confidentiality, obligating the processor to cooperate with “reasonable assessments” by the controller or the controller’s designated assessor.” (Section 9.)

DPIAs: Controllers must conduct and document a data protection assessment for certain processing activities: processing personal data for targeted advertising; selling personal data; processing personal data for profiling that presents a reasonably foreseeable risk of substantial injury to consumers (e.g., unfair or deceptive treatment, financial or physical or reputational injury, intrusion on solitude, seclusion or private affairs), processing sensitive data, or other processing activities involving personal data that present a heightened risk of harm to consumers. (Section 10.) 

Enforcement

The law will go into effect on January 1, 2027 and will be enforced exclusively by the attorney general. (Section 22.) The law includes a mandatory cure period, requiring the AG to notify controllers or processors of alleged violations and allowing 30 days for them to resolve violations. (Sections 13–14.) The civil penalty for each violation is $7,500. (Section 14.)

* * *

At long last, Oklahoma takes its place on the privacy patchwork. Looking to get up to speed on the existing state comprehensive consumer privacy laws? Check out FPF’s 2025 report, Anatomy of a State Comprehensive Privacy Law: Charting the Legislative Landscape. 

image

Pictured: Oklahoma receiving its star on the FPF “Privacy Patchwork” quilt.

Navigating Autonomy and Privacy in Emerging AgeTech: Insights from the FPF Roundtable

As AgeTech expands into homes across the country—seeking to enable older adults to live independently longer—fundamental questions about autonomy, privacy, and trust are coming into sharper focus. How do we balance caregiver support with individual privacy? Should data pertaining to older adults be treated as “sensitive?” And in a fragmented privacy and consumer protection landscape, how do we build the trustworthiness necessary for adoption?

The Future of Privacy Forum recently convened a pivotal AgeTech Roundtable, supported by the Alfred P. Sloan Foundation, to delve into the ethical, legal, and policy challenges presented by the rapidly expanding field of AgeTech. The core discussions centered on balancing the growth of these tools without compromising the fundamental autonomy and privacy of the older adults they are intended to serve. This post highlights key themes from the roundtable and outlines next steps in FPF’s ongoing AgeTech initiative.

The Core Tension: Privacy vs. Autonomy

AgeTech devices, ranging from smart home sensors to AI-enabled companion devices, collect highly sensitive personal data, including health, location, voice, and behavioral patterns. A critical nuance explored during the roundtable was the unique privacy calculation older adults face: the willingness to accept continuous monitoring in exchange for the ability to live independently at home for longer.

However, this trade-off is complicated by several factors:

The Crisis of Trust: Fraud and AI

Scams targeting older adults are one of the top consumer protection concerns, and the rising phenomenon of fraud and financial theft severely undermines trust in AgeTech products.

Conclusion and Next Steps

The insights gathered at the roundtable—which centered on the ethical, legal, and policy challenges in the emerging AgeTech landscape—provide a robust foundation for FPF’s continued work to ensure that Agetech serves to enhance, not diminish, the dignity and independence of older adults.

Recommendations and next steps from roundtable attendees included:

Incentives or Obligations? The U.S. Regulatory Approach to Voluntary AI Governance Standards

By FPF Legal Intern Rafal Fryc

As artificial intelligence gets increasingly deployed across every sector of the economy, regulators find themselves grappling with a fundamental challenge: how to govern a technology that defies traditional regulatory frameworks and changes faster than legislation can keep pace. One increasingly common approach can be found outside the text of statutes, where state legislatures are pointing developers and deployers toward established voluntary governance frameworks like NIST’s AI Risk Management Framework or ISO 42001. This shift toward incorporating non-binding technical standards into legal requirements represents more than just regulatory convenience – it is creating a new legal regime in which voluntary industry guidelines are influencing everything from negligence determinations and punitive damage calculations to affirmative defenses for regulatory actions. Understanding how these soft law approaches are influencing legal expectations has become essential for anyone building, deploying, or governing AI systems.

This blog post highlights: 

The Growth of AI Laws Utilizing Voluntary Standards

Colorado’s AI Act (SB 205), prior to the revised policy framework, was the first in the U.S. to require deployers to implement a “risk management policy and program” that aligns with NIST’s AI RMF, ISO 42001, or another “nationally or internationally recognized risk management framework for artificial intelligence systems.”1 On top of required implementation, Colorado offered an affirmative defense to deployers and developers for compliance with these frameworks. Although Colorado was the first to introduce such provisions in the AI space, mentions of external standards in the AI Act were removed by the Colorado AI Policy Working Group in their latest proposed revisions to the Act. Texas later came into the scene with the Texas Responsible Artificial Intelligence Governance Act (TRAIGA), also creating an affirmative defense for developers or deployers that comply with NIST’s AI RMF or another nationally or internationally recognized risk management framework for AI systems.2 Most recently, California’s Transparency in Frontier Artificial Intelligence Act (TFAIA) requires developers to disclose whether and to what extent they incorporate “national standards, international standards, and industry-consensus best practices.”3 New York’s RAISE Act (A 9449) takes a similar approach to California, requiring developers to disclose how they “handle” incorporating external standards. Montana (SB 212) also passed a narrow law, requiring deployers to implement a risk management framework that considers external standards when AI is deployed in critical infrastructure. 

While Texas takes an incentive-based approach, by offering compliance with a non-binding framework as an affirmative defense, California requires that deployers or developers consider and publish their approach to risk management frameworks that align with, or are substantially similar to nationally/internationally recognized standards. Colorado originally occupied a complicated middle ground, mandating adherence for deployers’ risk management while simultaneously offering an affirmative defense from state AG actions for developers, deployers and “other persons.” As with many laws surrounding emerging technologies, the approach is fragmented, where entities utilizing voluntary AI governance frameworks are subject to varying degrees of liability and protection.

screenshot 2026 03 16 153947

The Proposed Laws and Their Application

Nonetheless, the approach appears to be gaining momentum, particularly with proposed legislation regarding frontier models, liability, and automated decisionmaking. All take language from existing bills to require or encourage developers and deployers to have a written policy that takes into account NIST’s AI RMF or a similar framework.4 

Frontier Model Bills

Bills focusing on frontier models either copy or expand California’s approach. While California only required developers to publish their approach to external standards, some bills  require developers and deployers to implement a framework that incorporates the same standards. However, bills under this category notably do not refer to specific standards like NIST or ISO, instead opting for the more general terms “industry-consensus best practices” and “national/international standards.” Within this category, the bills fall under two approaches: either mandating a single framework that incorporates/considers external standards or mandating both a public safety and a separate child protection plan that does the same. Bills in the first category include Illinois SB 3312 and Illinois HB 4799. Interestingly, both bills require any amendments or rulemakings made pursuant to the statute to also consider the same external standards. Bills in the second category include Illinois SB 3261, Utah HB 286, Tennessee SB 2171, and Nebraska LB 1083. These bills not only focus on frontier model developers, targeting chatbot providers as well. 

Liability Bills

Bills focusing on liability typically follow Texas’ approach, where developers and deployers are given a safe harbor from product liability based litigation if they implement external standards in various places in the AI lifecycle. Bills in this category include Illinois SB 3502/SB 3590, Maryland HB 712, and Vermont H 792. The requirements to achieve safe harbor differ for developers and deployers, where developers must conduct “testing, evaluation, verification, validation, and auditing of that system consistent with industry best practices” and also submit a data sheet to the state Attorney General that includes:

  1. “Information on the intended contexts and uses of the artificial intelligence system in accordance with industry best practices;
  2. Information regarding the datasets upon which the artificial intelligence system was trained, including sources, volume, whether the dataset is proprietary, and how the datasets further the intended purpose of the product; 
  3. Accounting of foreseeable risks identified and steps taken to manage them consistent with industry best practices; and 
  4. Results of red-teaming testing and steps taken to mitigate identified risks, consistent with industry best practices.”

Deployer requirements for safe harbor are comparatively relaxed, where the bills mandate a risk management framework that incorporates external standards.

ADMT Bills

Bills focusing on ADMT follow Colorado’s original approach made prior to the revised policy framework, where there are both requirements to implement these standards and safe harbors from litigation to encourage doing so. With Washington’s HB 2157, the bill presumes conformity with the statute if the developer or deployer follows NIST’s AI RMF or ISO 42001. The bill also offers a rebuttable presumption to deployers if they implement a risk management framework that conforms to NIST, ISO, or another standard of similar rigor. New York’s S 1169, on the other hand, requires developers and deployers to implement a risk management policy that conforms with NIST’s AI RMF or another standard designated by the state’s Attorney General. This bill diverges from the others by granting the state Attorney General power to name which standards would qualify under the statute, as opposed to the majority of other bills which leave that determination unanswered. 

The Real Effects on Litigation

Industry standards like NIST’s AI RMF can also be used by courts to determine whether companies exercised reasonable care, even when no statute requires their adoption. This judicial reliance on voluntary standards follows established patterns from product liability and negligence cases, where courts have long looked to industry practices to define standards of care. In AI litigation, these frameworks can emerge as critical evidence in three areas: establishing the duty of care in negligence claims, determining defects in strict liability cases, and assessing good faith conduct when calculating punitive damages. The result is that compliance with non-binding standards can determine liability regardless of whether a jurisdiction has AI-specific legislation.

Product liability in AI litigation can be split into two categories: negligence cases and strict liability cases. Negligence cases depend on whether the defendant had a duty of care to the plaintiff and if that duty was breached. A duty of care’s existence depends on many factors, including industry standards. Many courts have recognized that “[e]vidence of industry standards, customs, and practices is ‘often highly probative when defining a standard of care.”5 Other courts have also concurred that “advisory guidelines and recommendations, while not conclusive, are admissible as bearing on the standard of care in determining negligence.”6 Openly complying with industry standards can provide an objective input into an otherwise subjective determination. 

Strict liability takes a different approach by automatically placing liability in cases of dangerous animals, ultrahazardous activities, and product defects. Although not yet established, harm caused by AI would most likely qualify under the product defect theory, which would make an AI developer liable if they failed to provide adequate warning or if the product is “defective.”7 The current wave of chatbot litigation points to this approach, with various plaintiffs pursuing this avenue.8 In determining what qualifies as “adequate warning” or whether a product is “defective,” courts often look to industry standards. Although a minority of states do not consider industry standards for strict liability,9 the majority of states and federal courts do.10 Following widely adopted established standards, like those by NIST and ISO, can prove dispositive in most strict liability cases relating to AI.

In terms of punitive damages, both state and federal courts have looked favorably on adherence to  industry standards when determining if the defendant acted in good faith; however, there have been exceptions:

  1. A manufacturer followed industry standards but actively resisted safer designs based on economic considerations.11
  2. A company followed industry standards but knew about a remaining risk and failed to warn and remedy the risk.12
  3. A manufacturer followed industry standards but knowingly engaged in conduct that endangered people.13

While following industry standards has been beneficial for determining “good faith” when assessing punitive damages, it mostly serves as the baseline for expected behavior. Readily demonstrating adherence to external standards is necessary to avoiding hefty fines.

Whether through statutory requirements in Colorado and California, affirmative defenses in Texas, or judicial interpretation of “reasonable care” and “good faith” in liability cases, frameworks like NIST’s AI RMF and ISO 42001 are transitioning from voluntary best practices to de facto legal requirements. For AI developers and deployers, the message is clear: application of these standards is becoming less optional and more essential for managing legal risk. Companies that wait for explicit regulatory mandates may find themselves already behind the curve, and organizations should begin implementing recognized risk management frameworks now, not because the law explicitly requires it everywhere, but because the legal system is already treating these standards as the baseline for reasonable conduct.

Beyond the defensive calculus of avoiding penalties and litigation exposure, there is an equally compelling case for adopting external standards: they are simply good governance. These frameworks are road-tested guides for building AI systems that produce accurate, ethical, and trustworthy outcomes. Organizations that internalize them are better positioned to gain customer trust, regardless of what any particular state legislature has done. Given the near impossibility of creating compliance programs that anticipate every nuance of every emerging AI law across fifty states, demonstrating a genuine, documented commitment to robust governance gives regulators reason to extend good faith when questions arise. An organization that can point to systematic, principled governance processes is better positioned in a regulatory conversation than one scrambling to reverse engineer compliance after the fact. The growing statutory references to NIST and ISO standards are a development worth watching closely but, the stronger argument for adoption may be the proactive one: that these frameworks represent a genuine commitment to getting AI governance right, not merely a hedge against enforcement risk.

Design elements of the above image was generated with the assistance of AI and reviewed by FPF.

  1. Colo. Rev. Stat. Ann. § 6-1-1703. ↩︎
  2. 2025 Tex. Sess. Law Serv. Ch. 1174, Sec. 552.105(e)(2)(D) (H.B. 149). ↩︎
  3. Cal. Bus. & Prof. Code § 22757.12. ↩︎
  4. H.B. 286, 13-72b-102(1)(a) (Utah 2026); H.B. 4705, Sec. 15(a)(3)(A), 104th Gen. Assem. (Ill. 2026); S.B. 2171, 68-107-103(a)(1)(G), 114th Gen. Assem. (Tenn. 2026); N.Y. S8828 § 1421(a) (2026). ↩︎
  5. Elledge v. Richland/Lexington Sch. Dist. Five, 341 S.C. 473 (Ct. App. 2000). ↩︎
  6. Cook v. Royal Caribbean Cruises, Ltd., No. 11-20723-CIV, 2012 WL 1792628, at *3 (S.D. Fla. May 15, 2012). ↩︎
  7. Restatement (Second) of Torts § 402A (Am. L. Inst. 1965). ↩︎
  8. Garcia v. Character Techs., Inc., No. 6:24-cv-1903-ACC-DCI, 2025 U.S. Dist. LEXIS 215157 (M.D. Fla. Oct. 31, 2025). ↩︎
  9. Sullivan v. Werner Co., 253 A.3d 730 (2021). ↩︎
  10. Joshua D. Kalanic et al., AI Soft Law and the Mitigation of Product Liability Risk, CTR. FOR L., SCIENCE, & INNOVATION, ARIZONA STATE UNIVERSITY (Jul. 2021), https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3909089 (“Yet, many states still allow industry standards to be presented as evidence because such standards can help show the reasonableness and adequacy of the design.”) ↩︎
  11. Gen. Motors Corp. v. Moseley, 447 S.E.2d 302 (1994). ↩︎
  12. Flax v. DaimlerChrysler Corp., 272 S.W.3d 521 (Tenn. 2008). ↩︎
  13. Uniroyal Goodrich Tire Co. v. Ford, 461 S.E.2d 877, 880 (1995). ↩︎

Red Lines under the EU AI Act: Understanding the ban of the untargeted scraping of facial images and facial recognition databases 

Blog 5 | Red Lines under the EU AI Act Series

This blog is the fifth of a series that explores prohibited AI practices under the EU AI Act and their interplay with existing EU law. You can find the whole series here.

1. Introduction

The fifth blog in the “Red lines under the EU AI Act” series focuses on unpacking the Article 5(1)(e) prohibition to place on the market, put into service, or use AI systems that create or expand facial recognition databases through the untargeted scraping of facial images from the Internet or CCTV footage. It is notable how this provision targets specifically the acts necessary prior to engaging in facial recognition itself, which is tackled separately, under a different provision of the AI Act, Article 5(1)(h). A number of key takeaways emerge from our analysis: 

Following this brief introduction, Section 2 outlines the rationale behind the prohibition, while Section 3 notes its specific scope as defined in the differentiation between “targeted” and “untargeted” scraping. Section 4 outlines what falls outside the scope of the prohibition, potentially including use-cases of AI-driven deepfakes, while Section 5 explores the AI Act’s interplay with other relevant areas of EU law, including the GDPR and Law Enforcement Directive (LED). After noting significant cases on facial recognition by DPAs, Section 6 includes concluding reflections and key takeaways. 

2. Context and rationale: untargeted scraping of facial images as a particularly intrusive practice posing “unacceptable risk”, consistent with past case law under the GDPR 

Article 5(1)(e) AI Act prohibits the creation or expansion of facial recognition databases through the untargeted scraping of internet or CCTV footage. The European Commission’s Guidelines on Prohibited Artificial Intelligence Practices under the AI Act recognize that the untargeted scraping of facial images “seriously interferes with individuals’ right to privacy and data protection and deny those individuals the right to remain anonymous”. This is further supported by Recital 43 AI Act, which recognizes that the untargeted scraping of facial images can add to the feeling of mass surveillance and lead to gross violations of fundamental rights, including the right to privacy. 

The context and rationale of the AI Act’s prohibition is consistent with past case law by DPAs across the EU on the basis of the GDPR. Indeed, the expansion and creation of facial recognition databases on the basis of the untargeted scraping of data, including biometric data such as facial images, has been a continuous area of serious concern for DPAs. From 2022 to 2024, several DPAs imposed large fines on Clearview AI for GDPR violations due to practices related to facial recognition, as highlighted in Section 5 of this blog. 

3. Defining facial recognition databases and (targeted vs.) untargeted scraping

    Article 5(1)(e) AI Act states that the following practice shall be prohibited: “the placing on the market, the putting into service for this specific purpose, or the use of AI systems that create or expand facial recognition databases through the untargeted scraping of facial images from the internet or CCTV footage” (emphasis added).

    Article 5(1)(e) AI Act states that the following practice shall be prohibited: “the placing on the market, the putting into service for this specific purpose, or the use of AI systems that create or expand facial recognition databases through the untargeted scraping of facial images from the internet or CCTV footage” (emphasis added).

    Four cumulative conditions must be met for the prohibition to apply: 

    1. The practice must constitute market placement, putting into service for this specific purpose, or usage of the AI system; 
    2. Aim to create or expand facial recognition databases; 
    3. Employ AI tools for untargeted scraping methods; and 
    4. Source images from either the internet or CCTV footage.

    The Guidelines clarify that, similarly to the other Article 5 prohibitions, all four cumulative conditions above must be met simultaneously to trigger the prohibition. This approach, which is a consistent element of the AI Act’s full set of prohibited practices, seems to ensure a targeted approach to banning very specific uses of AI technologies. The prohibition applies to both providers and deployers who, in accordance with their responsibilities and placement in the value chain, have a responsibility not to place on the market, put into service, or use AI systems for this specific purpose. 

    The Guidelines stress that Article 5(1)(e) AI Act does not require that the sole purpose of the database is to be used for facial recognition; it is sufficient that the database can be used for facial recognition. The Guidelines define a “database” in this context as any collection of data or information that is specially organized for rapid search and retrieval by a computer, and may be temporary, centralized or decentralized. 

    An important distinction in the application of this provision is between targeted and untargeted scraping – the prohibition does not apply to any scraping tool with which a database for face recognition may be constructed or expanded, but only to tools for untargeted scraping. In this context, untargeted scraping is defined as a technique absorbing as much data and information as possible from different sources and without a specific focus to a given individual or group of individuals. This may be done using a variety of scraping tools and techniques, including web crawlers, bots, or other means that allow for the extraction of data from a variety of sources, including CCTV footage, social media, and other websites, in an automatic manner. 

    It is crucial to determine the precise scope of the scraping, since the Guidelines further note that the prohibition does not cover “targeted” scraping, such as the collection of images or videos of specific individuals or pre-defined groups of persons for law enforcement purposes. Furthermore, in more complex systems combining targeted with untargeted searches, only the untargeted scraping is prohibited. 

    Notably, the Guidelines highlight that the publication of images on social media by natural persons does not constitute consent for inclusion in facial recognition databases, aligning with the GDPR notion of (valid) consent as a legal basis for processing personal data. 

    4. What falls out of the scope of the prohibition?

    While specifically targeted scraping is in some cases allowed, several other practices fall outside the prohibition’s scope, including the untargeted scraping of biometric data other than facial images (such as voice samples) and, importantly, non-AI scraping methods. The Guidelines also note that AI systems which harvest large amounts of facial images from the internet to build AI models that generate new images about fictitious persons, similarly fall outside the scope of the prohibition.

    While the logic behind this last use-case is seemingly to permit the effective training of AI models, and it explicitly falls outside the scope of the prohibition, attention should be paid to the compliance of this practice with both copyright and data protection laws. Indeed, AI systems that scrape large amounts of facial images to build AI models may trigger the dual application of EU copyright rules, which protect the images themselves to the extent they are under copyright protection, and the application of the GDPR, which protects facial images as personal data, or even as special category biometric data where they are processed with the purpose of uniquely identifying a person. While the scope of this prohibition was agreed upon by co-legislators during final negotiations for the AI Act, this particular use-case may not account for the increasing sophistication of AI-driven deepfakes. 

    In fact, at the time of writing, the European Parliament reportedly reached a political agreement on the AI Act Omnibus wherein the latest compromise text includes a new addition to the list of prohibited practices. Namely, once adopted, non-consensual sexual deepfakes will be banned under the revised AI Act. 

    It is also worth noting that while this new ban will allow for further protection, it will not cover all use-cases of AI-driven deepfakes, potentially marking an area of continuous, ongoing review by regulators and legislators alike. For this purpose, outside of the Omnibus procedure, the AI Act’s Article 112 empowers the Commission to assess and review the list of prohibited practices on a yearly basis, with the resulting assessment report having to be submitted to the EU Parliament and Council. 

    5. Interplay with other EU laws: From the GDPR to the LED

    5.1. Facial recognition as a long-standing regulatory priority for DPAs across the EU

    The creation and expansion of facial recognition databases on the basis of untargeted scraping of facial images has been a prominent area of regulatory intervention on the basis of the GDPR. In February 2022, the Italian DPA (Garante) fined Clearview AI €20 million and imposed a ban on the company’s further collection and processing of data, including biometric data, and ordered the erasure of such data relating to citizens on Italian territory. 

    In October 2022, the French DPA (CNIL) similarly imposed a fine of €20 million on Clearview AI, recognizing the very serious risk to individuals’ fundamental rights posed by their facial recognition software. In September 2024, in an ex officio investigation, the Dutch DPA (AP) fined Clearview AI €30 million for “illegal data collection for facial recognition.” 

    In their investigations, DPAs found breaches of the GDPR’s Article 6 (lawfulness of processing), Article 9 (processing of special categories of personal data), and a failure to fulfil data subject rights, particularly those found in Article 15 (right of access) and Article 17 (right to erasure). The Garante also found breaches of key principles of data protection, in particular of lawfulness, fairness and transparency (Article 5(1)(a) GDPR), the purpose limitation principle (Article 5(1)(b) GDPR), and the storage limitation principle (Article 5(1)(e)). As such, in addition to constituting a prohibited practice under the AI Act, the untargeted scraping of facial images for the purposes of creating or expanding a facial recognition database also contravenes several obligations found in the GDPR.

    The Guidelines themselves similarly note that, in general, the processing of personal data via the untargeted scraping of the Internet or CCTV material to build up or expand face recognition databases is unlawful, and there is no legal basis under the GDPR for such activity. 

    5.2. Law Enforcement use of facial recognition databases

    Law Enforcement Authorities (LEAs) use facial recognition databases for identification purposes, allowing for the automated identification of individuals that may in some way be related to criminal events, such as suspects, wanted persons, victims, or witnesses. Among the different types of databases used for face matching by LEAs are also databases consisting of surveillance footage or private data sources and open-source data from the internet. 

    While the AI Act prohibits the creation or expansion of facial recognition databases through the untargeted image scraping from the internet or CCTV footage, the provision does not seem to prohibit the use of already existing databases that were previously created from untargeted scraping of internet or CCTV footage that are used by LEAs for face matching and identification purposes. Hence, there might be a legal gap between the prohibition of the creation of new databases and the expansion of existing databases from image scraping, and the use of such databases that were created prior to the entry into force of the AI Act prohibition. 

    The AI Act’s Article 5(1)(e) prohibition admits no exceptions for law enforcement use, unlike Article 5(1)(h) on real-time remote biometric identification (to be explored in the final instalment of this blog series), which has a carve-out for competent authorities in public spaces under strict conditions. The AI Act’s blanket ban seems intentional to prevent circumvention through law enforcement justifications. 

    The LED, the specific legal framework for data protection in law enforcement, takes a more balanced approach: it may permit particularly intrusive practices if proportionate, necessary, and legally grounded. Hence, if a biometric database is strictly necessary, sufficiently targeted (i.e., footage related to a specific investigation), and proportionate for law enforcement purposes, it passes the LED test. 

    Article 10 LED governs the processing of special categories of data, including biometric data processed for the purpose of uniquely identifying a natural person, and permits such processing only where it is strictly necessary, subject to appropriate safeguards, and authorized by Union or Member State law. Untargeted scraping does not seem to satisfy Article 10 conditions. 

    Hence, even though the LED does not explicitly prohibit the use of databases from untargeted scraping, it implicitly reaches to the same normative position as the AI Act due to its strict requirements. The primary difference is that the AI Act’s prohibition does not engage with that balancing at all: untargeted scraping is simply prohibited. The two legal instruments thus create overlapping and mutually reinforcing layers of prohibition. One question that remains is whether a database that was created outside of the EU can be used by LEAs in the EU in accordance with the LED or AI Act.

    6. Concluding Reflections and Key Takeaways

    The AI Act’s prohibition is consistent with previous case law of DPAs, on the basis of the GDPR, which remains the most comprehensive protection in facial recognition use-cases

    The prohibition’s differentiation between the targeted and untargeted scraping of facial images, and the subsequent ban of untargeted scraping, is reminiscent of several DPAs’ fines, particularly in the line of Clearview AI cases between 2022 and 2024. DPAs, including the Italian Garante, the Dutch AP, and the CNIL, found that Clearview AI’s facial recognition software breached several of the GDPR’s key principles and obligations.

    The prohibition expressly differentiates between “targeted” and “untargeted” scraping, thereby limiting the scope of its application and excluding qualified “targeted” scraping from its scope 

    The differentiation between targeted and untargeted scraping is also significant because the AI Act does not include a blanket ban on all scraping of facial images. Indeed, it acknowledges that in some cases, such as in law enforcement contexts, targeted scraping may be lawful when strictly necessary and proportionate. The LED sets out specific conditions for such use-cases, which are tightly regulated across the EU. An analysis of the interplay between the LED and AI Act shows an alignment between the two regulations, creating mutually reinforcing layers of prohibition. 

    Some use-cases, such as the harvesting of facial images for training AI models that generate new images of fictitious persons, may lead to increasingly complex compliance scenarios 

    When analyzing the practices or use cases that fall outside the scope of the prohibition, we also found that specific AI-driven deepfakes have so far not been captured by Article 5 AI Act. This seems to have similarly been recognized by legislators when, on 11 March 2026, it was reported that the European Parliament reached a political agreement on the AI Act Omnibus, which aims to include a new ban on non-consensual sexual deepfakes. It is worth noting that while this is a development that will allow for further protection, the (new) ban does not cover all AI-driven deepfakes.