Adapting the Privacy Profession to Changing Times

As spring comes into full bloom, the changing of the seasons offers an opportunity for privacy teams to start thinking about how they can be more effective in their workplaces. Privacy work needs to evolve in a couple of important ways, and the value of that work for the organization may have its highest manifestation as a strategic partner helping the organization itself re-invent its work.

One path is through alliance. It is true that many new issues are coming up that, to some organizations, may seem to be a higher priority than privacy. These issues of course include AI but also youth online safety, age assurance, and cybersecurity. There is a growing basket of privacy and compliance issues: governance risk and compliance, data protection, trust and safety, content moderation, AI governance, cybersecurity, and in advertising, debates around the appropriate role of generative AI in creating ads. We might previously have thought of these issues as “privacy adjacent” but increasingly we can think of them as “data governance gateways.” The organization prioritizes these issues because they must, and yet each one is a gateway back to privacy concerns. Leading with these other issues can create a path back to the key data governance issue on the agenda of the privacy team.

Managing these data governance gateways means building alliances with the other people at the organization integral to concerns. Some privacy teams have felt stretched as their work on  AI privacy and governance has grown, but these issues can be reframed as a gift to the privacy team because it is something that the organization deems important and a high priority. Leading on governance in a strategically critical area allows privacy teams to get the attention of the C-Suite and other key stakeholders and make the case for why resources are needed to fulfill it.  The organization probably already is prioritizing cybersecurity, so a good relationship with the CISO team is vitally important: it may have budget resources that the privacy team does not. These other issues and teams offer the potential for networks of alliances.  On an organization chart, these developments might look like a diminution of privacy team influence.  But real influence is shaped by productive interactions, effective communication of a clear message, and the finesse and persistence entailed in effective leadership across different teams of stakeholders. The skill and mindset for privacy executives of leading across teams has never been more important.

It’s also possible for privacy teams to continue to evolve. In their early stages, the privacy team was the “Lonely Voice,” an appendage to the legal department or the marketing team that tried desperately to get attention to its issues but was often a low priority voice. We certainly hope that no privacy teams are still stuck there. Many of them advanced to a higher evolution, establishing effective partnerships in the organization with other key stakeholders, including marketing teams, sales teams, product teams, and privacy engineers. Successful teams positioned themselves to be the “Pathfinder”  helping guide the organization through the minefield of increasing regulation and law and enabling the organization to execute its goals.  

Over the past few years, we have started seeing the next evolution of the privacy team’s role, initially to a broader data governance role and now to a position more readily perceived as a strategic partner, helping the organization compete in the age of AI. More than ever legal regulatory and enforcement trends demand consideration of data stewardship, accuracy, bias, transparency, and safety in the business planning and strategy processes. Cybersecurity, always a major risk, is deeply stressed by the new threats enabled by AI. Beyond regulatory and enforcement trends, AI is reshaping how every business plans and operates and data protection and governance issues are increasingly strategic, if AI enablement is to advance.

The alliances across various compliance or data governance gateway stakeholders that the privacy executive builds now become of strategic importance not just for the privacy team but for the organization itself.  It’s helpful to think of “data governance” not just as the small basket of privacy issues but as a larger basket of “data governance gateway” or “privacy adjacent” issues for which there is a cohort of allies  – a “compliance alliance” – with significant influence across the organization.  This new compliance cohort now must be the strategic partner helping the organization succeed. These executives, whether Chief Privacy Officer, Data Governance Leader, Responsible AI executive or other, are well positioned to lead this effort as they work across teams and silos. 

Consider cybersecurity, where substantial investment is required in core technology and resources, but equally important are cultural changes that need to be made to reduce risk from avoidable human mistakes made by employees. Focusing on cultural change with deeper business awareness across all teams, not just the cybersecurity team, will ultimately help the organization protect itself.  The cybersecurity team benefits from this compliance alliance.

In advertising and ad tech, AI drives a substantial strategic imperative for companies to think about how to incorporate AI into their offerings. The challenge of offering opt outs from targeting, sharing, selling, across many state regimes is trending toward more comprehensive, perhaps browser-based approaches that likely will increase opt out rates. Some companies may benefit from reducing their emphasis on ID-based targeting and shift resources toward a strategic approach that includes building audiences using AI and more multichannel pathways to finding people to buy products. Digital advertising still has a future, but so do many other forms of marketing. Advertisers not thinking more holistically about the various ways that they could connect to consumers are going to miss out. Publishers can be thinking more clearly about adopting AI and being able to interact with the likely growth in standardized agentic AI. Advertisers need to get their arms around generative AI that creates the ads at a far greater speed but needs to also deepen connection to actual humans, because many consumers may respond better to more meaningful human connection. Publishers and advertisers have a strategic interest in finding more creative ways of connecting to actual consumers in a way that actually matters for those consumers, rather than responding to the various measurement techniques that might be counting clicks or traffic or eyeballs without really focusing on what’s actually moving products.  Given the dependence on new uses of data, continual engagement with data governance teams on these issues is paramount. 

New laws that promise protections to people who are under 18 (beyond COPPA’s 12 and under consent requirement) are an increasingly urgent area of focus for companies. These laws are generating serious strategic conversations about whether under-eighteens should be part of their business at all, and if so, how they can provide age-appropriate experiences for that cohort. Privacy leaders, as part of the larger “compliance alliance,” are well positioned to tee up that discussion.

In what parts or regions of the world will the organization compete, given the diversity and changing nature of digital rules outside the United States? Companies might well think about what other regions they operate in, balancing that with the various state laws in the United States, and reflect on how to plan and design systems to efficiently address regulatory and enforcement trends. We have probably passed the point where ad hoc adaptation suffices.  Once again, the privacy team brings strategic value.

For the privacy team that is facing expanded work with limited resources, there is opportunity to build alliances and to reframe this work in a way that is more germane and central to the organization’s mission. Becoming a genuine strategic partner that helps the business rethink how it profits in the face of new regulations and new technologies builds the case of expanded resources. 

Unquestionably, this approach raises the degree of difficulty and level of effort for privacy teams and data governance executives. A strategic executive needs to develop the skills of connection, leadership without authority, and leading across teams. Performing at this level requires highly effective communication – and what makes communication most effective is persistent and consistent messaging. It will require advancing pragmatic solutions focused more on cost and revenue opportunity and much less on risk and fear. It will require motivating privacy teams that may feel demotivated with clarity, purpose, and in-the-trenches support so that they know someone is looking out for them.

One note of caution: A commitment to collaboration and saying, “Yes, and . . . “ to business initiatives cannot mean that privacy teams or the “compliance alliance” never say no. They obviously can’t be perceived as a blocker by default, but they have to earn trust to effectively encourage responsible design decisions that consumers and other business partners trust.  This is a key part of the partnership: Honest guidance that builds a successful business, not enablement that ignores the fact that success is not when the ship sails, but when it arrives safely in port, having delivered the goods.

Dwight Eisenhower is credited with saying that if a problem seems unsolvable, make it bigger. What this gets at is that often we try to solve problems by breaking them into smaller pieces, but sometimes the solution is found by reframing, up-leveling, and finding new pathways into the problem.  That is going to be the pathway for privacy teams to show their value to organizations now: They’ve got to make the compliance problem – and the business opportunity – bigger. Making the business challenge bigger makes it more relevant and facilitates development of alliances with influential stakeholders in the organization. It also elevates privacy professionals as strategic partners at a moment in which the business has little choice but to rethink how it grows in a time of rapid change. It is seizing a propitious moment. It is embracing the uncertainty of moving forward with the promise of success and growth rather than being diminished.  It embraces hope, not fear.  It centers the idea that technology is part of how the organization will progress and yet it still preserves the fundamental truth that it will be humans working together, communicating effectively, and uniting around a common purpose of helping the organization succeed that will make privacy teams continue to be relevant in 2026 and beyond.

FPF has launched a project which I lead to help senior privacy and data governance executives more effectively frame their value to senior management and boards. While full participation is limited to our members, please reach out with any useful ideas. If you would benefit from participating and want to learn more about FPF membership, contact [email protected].

More Parties, More Risks, More Opportunity? Evolving Governance to Support Cyber Resilience Amidst Evolving Policy and Technological Change

*Special thanks to Jim Siegl and Jocelyn Aqua for their advice and expertise.

Summary: Artificial Intelligence (AI) presents fundamental opportunities and challenges for defense of increasingly complex digital ecosystems amid rising attack costs, fragmented regulation, and evolving industry practices. A coordinated response across the public and private sectors, including smart deployment of AI tools for risk detection and defense, is critical to building resilient AI systems and securing supply chains. This article describes emerging risks, identifies regulations and governance frameworks relevant to addressing them, and proposes governance steps that organizations can take to improve supply chain resilience. 

In recent years, third-party and supply chain cybersecurity attacks have become one of the most significant risks to national and organizational security. The 2020 SolarWinds breach demonstrated how integrated environments built on shared code, automated updates, and implicit trust in upstream vendors can allow a single vendor breach to cascade across agencies and enterprises. That incident granted foreign adversaries unauthorized access to more than 200 public and private organizations, including the Departments of Homeland Security, Treasury, and Commerce. Although the U.S. Securities and Exchange Commission (SEC) ultimately dismissed the SEC’s civil enforcement action against SolarWinds, this incident illustrates how an attack on one trusted software provider can lead to system-wide failures. In 2023, PyTorch, an open-source artificial intelligence/machine learning (AI/ML) framework, was injected with malware following a supply chain attack. In 2024, the XZ Utils backdoor illustrated how a single vulnerability in a trusted open-source library can compromise the build process and enable remote code execution across countless systems.

The threat became more pronounced in 2025. Approximately 30% of cybersecurity breaches last year originated from third-party relationships – double the percentage from just two years earlier. This rise tracks closely with increased reliance on external vendors, cloud platforms, model providers, and open-source components. While the growth of these interconnected supply chains can yield efficiencies and service improvements and accelerate innovation, they can also multiply the number of attack surfaces that bad actors can exploit.

Over several years, FPF has been exploring the ways that AI can accentuate security risks, while also creating new detection and defense capabilities. The recent announcement of Project Glasswing put a spotlight on the presence of both opportunity and risk as AI technologies rapidly evolve. Autonomous and agentic systems, add new layers of complexity and risk – as well as opportunities to more effectively detect, combat and mitigate those risks. Unlike traditional software, agentic AI systems may ingest external data, reuse pretrained models, and act across organizational boundaries with limited human intervention, which introduces or exacerbates distinct vulnerabilities. These risks intersect with traditional cybersecurity concerns but require new or expanded governance mechanisms around data provenance, model integrity, and automated decision-making. 

Emerging Risks in AI-Enabled Supply Chains

Organizations must navigate an evolving industry landscape while managing an interconnected network of vendors, cloud services, and open-source components, creating systemic risk from a single compromised dependency that can cascade across operations. 

Risks and Opportunities from Third-Party Components and Systems

Third-party software libraries, datasets, and cloud infrastructure can yield enormous value for organizations, including for risk management and cyber defense. At the same time, these tools can introduce vulnerabilities that are difficult to detect or control. In AI ecosystems, dependency chains are often deeper and less transparent than in traditional software systems, encompassing not just code, but models, training data and pre-trained weights. The proliferation of new AI-driven technologies and services, particularly those that involve agents, amplifies these risks. Once deployed, these agentic AI systems can act independently and potentially bypass traditional security controls.

Amplified Risk by AI Systems

AI systems and plugins can introduce new or exacerbate established cyber attack methods. These techniques exploit the model’s reliance on data and user input to manipulate system behavior or extract sensitive information. Specific examples include:

• Data and model poisoning through compromised training data or dependency libraries that alter model behavior at scale; 
• Prompt injection attacks where malicious inputs manipulate model outputs or downstream actions without altering underlying infrastructure; 
• Model supply chain hijacking via malicious model weights or corrupted open-source components;
• Autonomous agent exploits, where AI agents interact with external systems or application programming interfaces (APIs) using delegated credentials, tool access, or persistent permissions without sufficient guardrails; or 
• Cross-system interdependency, when a compromise in one model, tool, or plugin spreads across an entire interconnected ecosystem. 

Agentic AI systems introduce a distinct risk profile characterized by autonomy, multi-step decision-making, and the ability to take actions in external environments. Rather than producing static outputs in response to bounded inputs, these systems can plan, iterate, and take actions across external environments using delegated tools and credentials. This shift effectively extends the operational boundary of the system to include external services, APIs, and data sources in real time. As a result, risk is no longer confined to model performance or data integrity, but includes the downstream effects of autonomous decision-making and execution across interconnected systems.

These risks are amplified in environments where agents operate with persistent credentials or broad API access. In such contexts, a single compromised interaction can propagate across systems, particularly when agents are designed to optimize for task completion without sufficiently robust constraints on permissible actions. The resulting behavior may be difficult to predict or audit, as it emerges from the interaction between model outputs, tool responses, and external system states rather than from a single deterministic process.

As organizations deploy agentic AI, institutional decisionmaking can risk becoming more distributed and opaque. Agents may interact autonomously with external systems, exacerbating cybersecurity risks such as propagation of incorrect or malicious instructions across the supply chain, extraction of confidential data, and escalation-of-privilege scenarios (if access controls are misconfigured). The autonomy of agents may require new or evolved forms of oversight, logging, and training.

AI Governance and Accountability

Technical controls alone are insufficient to mitigate AI-specific supply chain risks. Effective enterprise cybersecurity requires active leadership oversight and a culture of accountability. Executives must move beyond a “baseline understanding” and toward a risk-aware mindset where cybersecurity training is tailored to AI specific industry roles and threat models. Company policies and protocols should incorporate this understanding. Human governance is essential to assess and enforce organizational standards.

Applicable Regulations and Governance Frameworks

In the absence of a single  statutory framework that governs the intersection of AI and cybersecurity, federal and state agencies have developed a range of guidelines, voluntary frameworks, certifications, and procurement requirements that seek to address growing cyber and AI governance risks.

Security Guidance from the Federal Government

Several federal frameworks provide relevant guidance for companies around third-party and supply chain cyber risk:

• National Institute of Standards and Technology (NIST) Cybersecurity Framework (CSF) and NIST Special Publications (SPs) 800-171 and 800-161: Offers detailed technical guidance for supply chain risk management (SCRM), with emphasis risk assessments, dependency mapping, continuous monitoring, and vendor due diligence.
  • The NIST Cybersecurity Framework is a voluntary and scalable cybersecurity risk guidance. The updated CSF 2.0 includes “govern” as a key function, which embeds cybersecurity governance into enterprise risk management, aligning strategy, policy, and oversight with business objectives.
  • NIST SP 800-161 provides comprehensive guidance for enterprise SCRM. It recommends a multidisciplinary governance structure, emphasizes iterative risk assessment and monitoring, and integrates risk management into procurement processes. 
• Cybersecurity and Infrastructure Security Agency (CISA) Secure by Demand Guide: Provides buyers a checklist of questions to assess software manufacturers’ supply chain security practices, such as establishing secure authentication defaults, reporting vulnerabilities, and providing security logs and a software bill of materials (SBOMs). 
• CISA Tabletop Exercise Packages (CTEPs) and Tips: Supports agencies and vendors in evaluating their cloud and procurement-related cybersecurity frameworks.
  • CISA also offers best practices for cloud security and third-party risk management that emphasize shared responsibility models, continuous monitoring, and secure integration of AI services.
• Department of Defense’s Cybersecurity Maturity Model Certification (CMMC): Sets standards for federal contractors, including vendors supplying AI services or model components to defense agencies.
• Federal Risk and Authorization Management Program (FedRAMP): Establishes security requirements for cloud service providers, and its procurement standards now extend to AI services deployed within federal environments.

AI Guidance from the Federal Government

Federal guidance on AI-related cybersecurity continues to evolve, offering several guides for how to approach AI-related risks in supply chains:

• NIST AI Risk Management Framework (AI RMF): Provides a structured approach for assessing AI-related risks, encouraging transparency and accountability across the AI lifecycle.
• The White House AI Action Plan sets out high-level policy principles around safety, transparency, and procurement/vendor accountability, calling for stronger oversight mechanisms to ensure that AI tools integrated into supply chains are trustworthy and secure.

State Governance

States are taking an increasingly active role in regulating AI and related cybersecurity risks. In particular, California has a number of strong AI procurement and cyber requirements. 

• New York Department of Financial Services (NYDFS) – 2025 Industry Guidance: Highlights the importance of incorporating AI governance into cybersecurity compliance (and noted that automation can amplify existing vulnerabilities), requiring financial institutions to evaluate AI model risks, confirm training data provenance, and assess vendor-level AI controls.
• California Privacy Protection Agency (CPPA) – 2025 Regulations: One of the first comprehensive state-level efforts to regulate AI systems and third-party data handling practices. Applicable provisions govern automated decision-making technologies (ADMT), mandatory cybersecurity audits for parties meeting certain thresholds associated with business volume and the selling and sharing of data; and and vendor accountability.

Industry Guidance 

In addition to regulatory guidance and frameworks from federal and state government agencies, there are a number of industry standards and best practices that may address AI- and agent-related third-party and supply chain cybersecurity risks. Examples include: 

• Open Worldwide Application Security Project (OWASP) GenAI Security Project – CheatSheet – A Practical Guide for Securely Using Third-Party MCP Servers 1.0: Provides a framework for companies and developers using a third-party Model Context Protocol (MCP). Along with mapping out common threat types, this cheat sheet provides actionable controls and workflows, such as strong authentication processes, sandboxed environments, and validation measures (e.g., establishing a “trusted MCP registry” and instituting periodic audits). 
• SysAdmin, Audit, Network, and Security (SANS) Institute – Critical AI Security Guidelines: Provides a practitioner-oriented framework to help organizations build, deploy, and operate secure AI systems. Recommends developing strict access or authentication controls, safe deployment strategies (e.g., sandboxing or red-teaming), risk-based deployment, and regular data sanitization and validation.
• Snowflake – AI Security Framework: Develops a threat taxonomy of security and privacy risks specific to AI systems to help cross-discipline teams evaluate AI risk in a systematic way. The framework also provides mitigation strategies to address listed risks, though specific implementation would depend on the architecture, environment, and threat model. 
• Massachusetts Institute of Technology (MIT) AI Risk Initiative – Mapping Frameworks at the Intersection of AI Safety and Traditional Risk Management: Although this analysis does not provide specific risk mitigation strategies, it provides an overview of almost a dozen AI risk management frameworks that sit “at the intersection of traditional risk management and AI safety” (with a particular emphasis on frontier, general-purpose, or “high-risk” AI systems). The MIT initiative could serve as a starting point for companies who want to ground their AI risk-management in proven safety or risk frameworks.

Across the public and the private sector, guidance on third-party and AI-related cyber risk is converging around core principles of transparency, accountability, and continuous oversight and governance. Federal frameworks have established baseline expectations for secure procurement and vendor management, while states are advancing more specific AI governance requirements. Industry standards can complement these efforts by offering practical controls and methodologies for implementing secure and responsible AI practices. Collectively, these frameworks underscore the need for organizations to adopt an integrated, risk-based approach to managing third-party and AI supply-chain security.

Recommendations and Next Steps

To strengthen AI-driven supply chain resilience, organizations should prioritize:

• AI Models and Agents Monitoring: Establish passive AI agent monitoring, then consider moving toward active “guardrails” to intercept and block anomalous agent actions, cross-system API calls, or unauthorized data exfiltration in real-time.
• Provenance for Third-Party AI Models Requirements: Consider creating AI Bills of Materials (AI-BOM), which would mandate vendors to provide a standardized AI-BOM that inventories code libraries (a “Software Bill of Materials” or SBOM), model provenance, training dataset origins, and cryptographic signatures of model weights to prevent tampering.
• AI-Specific Vendor Risk Assessments: Evaluate not only traditional cybersecurity controls but also model lineage, dataset provenance, and plugin dependencies. Consider AI-specific adversarial red-teaming (i.e., updating vendor risk assessments to include results from adversarial testing such as prompt injection and data poisoning resilience).
• Contracts and Procurement Controls: Include model security obligations, and update notification requirements and audit rights. Consider updating vendor contracts to ensure that no high-impact decision is made without a clear path for human intervention.
• Organizational Literacy: Ensure boards and executives understand AI-specific supply chain risks to enable informed oversight decisions. Elevate AI literacy beyond the IT department. Form a committee of legal, security, and business leaders to define the organization’s risk appetite for third-party AI dependencies and agentic autonomy.

Conclusion

The accelerating convergence of AI adoption, complex vendor ecosystems, and increasingly sophisticated cyber threats has elevated third-party and supply-chain security to a critical strategic priority for industry leadership. Recent incidents and rising breach rates demonstrate that traditional governance models must evolve for environments characterized by autonomous systems, complex dependency chains, and cross-system interdependencies. Both the private and public sector are responding with increasingly aligned expectations that emphasize transparency, accountability, and continuous monitoring across the AI lifecycle and vendor ecosystem.

For organizations, the imperative is to move beyond fragmented or compliance-only approaches and adopt an integrated, risk-based governance model that unifies traditional cybersecurity controls with AI-specific safeguards and robust oversight. Businesses that strengthen vendor accountability, implement continuous model monitoring, and invest in organizational education will be best positioned to mitigate systemic risks, realize new opportunities to strengthen defenses, maintain operational resilience, and meet evolving regulatory obligations.

For questions about FPF membership or our ongoing work related to the topics discussed in this blog, please contact [email protected].

Contextualizing the Proposed SECURE Data Act in the State Privacy Landscape

Special thanks to FPF’s Dr. Gabriela Zanfir-Fortuna, VP of Global Policy, for her contributions to this analysis.

The House Committee on Energy and Commerce’s Republican data privacy working group released their long-awaited comprehensive consumer privacy bill on April 22, titled the “Securing and Establishing Consumer Uniform Rights and Enforcement over Data Act” (SECURE Data Act) (H.R. 8413). Compared to prior federal efforts, the SECURE Data Act closely resembles many of the existing state comprehensive privacy laws—particularly those based on the Washington Privacy Act (WPA) framework—in terms of its structure, terminology, consumer rights, and business obligations. 

This blog post provides a detailed overview of the SECURE Data Act, including its scope, provisions, and how it compares to the other state laws based on the WPA framework.

1.  Scope

Applicability: The bill would apply to businesses subject to the FTC Act or a common carrier subject to title II of the Communications Act of 1934 that, excluding personal data controlled or processed solely for completing a payment transactions, either (1) have gross annual revenue in excess of $25 million and collect or process the personal data of at least 200K consumers annually or (2) collect and process personal data of at least 100K consumers and derive at least 25% of their annual gross revenue from selling such personal data.

These default and data sale thresholds are structurally similar to how most state comprehensive privacy laws are scoped, but the figures themselves are higher than in any of the states. 

Nonetheless, direct comparison is difficult since these thresholds are comparing state laws applicability at 100,000 consumers per state, while the federal bill applies at 200,000 consumers nationally. Thus, for businesses operating across multiple states, the federal threshold may be easier to meet despite the higher absolute number, while the bill’s additional revenue requirement ($25M) could exclude smaller data-intensive entities within scope of many state laws. 

Exemptions: Consistent with most of the state laws, this bill includes a variety of entity-level exemptions, such as: federal, state, or local governmental entities (or any entities acting as a processor on behalf of a federal or state governmental entity); financial institutions subject to the Gramm-Leach-Bliley Act (GLBA); HIPAA-covered entities or business associates; nonprofits; and institutions of higher education.

Notable data-level exemptions include: HIPAA-protected health information; health records; personal data that may impact the creditworthiness, credit standing, character, or general reputation of a consumer and is collected or disclosed by a consumer reporting agency or a furnisher engaged in activities subject to the Fair Credit Reporting Act (FCRA); and information subject to other laws such as the Drivers Privacy Protection Act (DPPA), the Family Educational Rights and Privacy Act (FERPA), and GLBA. As mentioned above, the bill also broadly exempts “publicly available information.” This is defined consistently with many state privacy laws as information that (1) is lawfully made available through government records or (2) “information that a business has reason to believe is lawfully made available to the public through widely distributed media, by the consumer, or by a person to whom the consumer has disclosed the information, unless the consumer has restricted the information to a specific audience.” There are also exceptions for deidentified and pseudonymous data, both of which are defined in the bill. 

One point of comparison with the state legislative landscape is the distinction between entity- and data-level exemptions. The newer and recently amended state laws have tended to eschew entity-level exemptions, particularly under GLBA and HIPAA, in favor of data-level exemptions. This bill opts for the broader entity-level exemptions. Although financial institutions would be broadly exempted from the bill, Congress is working on financial privacy as well. The SECURE Data Act was jointly released alongside the House Committee on Financial Services’ GUARD Financial Data Act, which would update GLBA to strengthen financial privacy protections.

In addition to the entity- and data-level exemptions, the bill also includes a variety of exceptions for common business activities, such as cooperation with law enforcement, providing a product or service specifically requested by a consumer or a parent of a consumer, preventing security incidents, engaging in public or peer-reviewed scientific or statistical research in the public interest (subject to safeguards), conducting internal research for product development and improvement, performing internal operations reasonably aligned with consumers’ expectations, and more. These exceptions are common in state privacy laws.

Key Definitions: The definitions in this bill are generally consistent with the majority of state comprehensive privacy laws, including common core definitions such as  “consumer” (an individual acting in their individual or household capacity and not in a commercial or employment context), “personal data” (any information that is linked or reasonably linkable to an identified or identifiable natural person, excluding deidentified data or publicly available information); and “sensitive data” (includes sensitive characteristics [such as race and ethnicity, religious belief, sexual orientation, citizenship], genetic and biometric data, and personal data from a child). As discussed below, the bill includes a novel extension of sensitive data to also include teens, defined as individuals aged 13 or over but under 16.  

There are a few definitions that, while consistent with some state laws, are among the narrowest versions of those definitions. “Biometric data,” for example, does not include data generated from photographs or video or audio recordings, even if such data is used to identify an individual. The “sale of personal data” is also defined narrowly as the exchange of personal data for “monetary consideration,” whereas many states have extended this to include exchanges “for other valuable consideration.” 

2.  Consumer Rights

Similar to much of the bill, the consumer rights most closely resemble the narrower iterations of the WPA framework. This bill includes the standard consumer rights to: confirm whether the controller is processing one’s personal data and to access that data; correct inaccuracies in one’s personal data, taking into account the nature of the personal data and the purpose of the processing; delete one’s personal data provided by, or obtained from, the consumer; obtain a copy of one’s personal data in a portable format (if technically feasible); and to opt-out of the processing of one’s personal data for targeted advertising, the sale of personal data, and profiling in furtherance of a solely automated decision that has a legal or similarly significant effect on the consumer. The bill also includes the requirement to obtain consent prior to processing a consumer’s sensitive data as a consumer right rather than a controller obligation. 

Although the standard rights are all present, this bill lacks some of the newer rights that have been included in a few of the state laws. For example, Oregon, Delaware, Maryland, and Minnesota all provide a right to know third party recipients of one’s personal data. Minnesota and Connecticut include rights to contest certain adverse profiling decisions. Neither of those rights are in this bill. 

Another significant aspect of these rights is the pseudonymous data exemption. Consistent with a few of the state privacy laws, this bill provides that the consumer rights do not apply to pseudonymous data. This arguably narrows the right to opt-out of targeted advertising, if a controller is able to demonstrate that “any information necessary to identify  the consumer is kept separately and is subject to appropriate administrative and technical measures to ensure that the personal data is not attributed to an identified or identifiable natural person.” Because the requirement to obtain consent before processing a consumer’s sensitive data is included in the same section as the consumer rights, this also arguably brings pseudonymous data outside the scope of that opt-in consent requirement, which is something that none of the state comprehensive privacy laws have done. However, that is debatable. The pseudonymous data exception provides that “[a]n assertion of any consumer right under section 2 does not apply to pseudonymous data” provided additional protections are met. The word “assertion” implies an affirmative action on the part of the consumer, which may limit the exception to only the consumer rights and not the consent requirement. Furthermore, Section 2, although labeled “Consumer privacy rights,” has distinct subheadings for “(a) Consumer Privacy Rights” and “(b) Consent Required for Processing Sensitive Data.” Although the exception says “any consumer right under section 2,” it could be interpreted to apply only to the rights in subsection 2(a). Nevertheless, pseudonymous data is still subject to a number of protections under the bill, such as data minimization and data security obligations. 

Finally, it is notable that this bill does not impose a requirement for controllers to recognize and comply with opt-out preference signals (OOPS) / a universal opt-out mechanism (UOOM). Privacy scholars and advocacy groups have long criticized the control-based model of American privacy law for requiring consumers to affirmatively exercise data rights, which is difficult for consumers to do at scale. A growing number of states—including California, Colorado, Connecticut, Delaware, Maryland, Minnesota, Montana, Nebraska, New Hampshire, New Jersey, Oregon, and Texas—have added the ability for consumers to exercise their opt-out rights on a default basis via a UOOM, such as the Global Privacy Control. While this bill does not require controllers to comply with such signals, it does direct the Secretary of Commerce to conduct a study on the feasibility and efficacy of such tools. 

3.  Business Obligations

The duties for controllers and processors under this bill largely align with those commonly found in state comprehensive privacy laws. For example, controllers are subject to procedural data minimization and purpose limitation requirements that tie data collection and processing to what is disclosed in a controller’s privacy notice. This is consistent with the approach taken in most of the state privacy laws. A controller must—

• Limit the collection of personal data to what is adequate, relevant, and reasonably necessary in relation to the purposes for which such data is processed, as disclosed to the consumer; and
• Obtain the consumer’s consent to process personal data for purposes that are neither reasonably necessary to nor compatible with the disclosed purposes for which such data is processed, as disclosed to the consumer. 

Data security is another requirement that closely tracks the language adopted in almost every state comprehensive privacy law. A controller is required to establish, implement, and maintain reasonable data security practices to protect the confidentiality, integrity, and accessibility of personal data, and such practices must be appropriate to the volume and nature of the personal data at issue. While this is consistent with the language commonly seen in the state laws, the bill deviates slightly by adding a rebuttable presumption that a controller has taken appropriate security measures if the controller (1) complies with a relevant code of conduct (see below) or (2) has data security practices that are “state-of-the-art . . . including such a practice demonstrated by adherence to a widely-accepted technical specification or through a third-party attestation” and its security program “reasonably conforms to a relevant Federal or widely-accepted international risk management framework.” 

Controllers are also subject to familiar requirements, such as providing a privacy notice that meets enumerated criteria (including a more novel requirement that the privacy notice disclose if personal data has been transferred to, processed in, stored in, or sold to North Korea, China, Russia, or Iran), a prohibition on processing personal data in violation of civil rights law, and oversight/contractual requirements with respect to their processors. 

Notably absent from the bill is a requirement to conduct data protection impact assessments (DPIAs). All of the state comprehensive privacy laws except those in Alabama, Iowa, and Utah require some form of assessment for processing activities that present a heightened risk of harm to consumers. DPIAs are also a core component of most industry best practices.  

4.  Youth Privacy

As is commonly the case in comprehensive privacy laws, the bill classifies personal data of children (under 13)  as sensitive data. However, the bill extends this classification to all teens’ data (aged 13 through 15), requires parental consent for teen data processing and consumer rights, and omits a defined knowledge standard—representing a meaningful departure from typical state (and federal) approaches. Additionally, this bill does not include a duty of care or heightened privacy protections and risk assessment requirements, such as those adopted in Connecticut, Colorado, and Montana.

As discussed above, controllers would be prohibited from processing a consumer’s sensitive data without consent. Consistent with the state laws, there is a clarification that processing the sensitive data of a child (although this is normally restricted to a “known child”) must be done in accordance with the Children’s Online Privacy Protection Act (COPPA). This bill goes further, however, by also requiring the verifiable consent of a parent to process the sensitive data of a teen. In turn, VPC, under the bill, would require direct notice to the parent and unambiguous pre-collection authorization for both initial and subsequent personal data processing or use. Note that “sensitive data of a child” or “sensitive data of a teen” means any personal data of either category because sensitive data includes “personal data collected from a child or teen.” 

Furthermore, consumer rights requests on behalf of children and teens would only be exercised by a parent, defined broadly to include natural parents, adoptive parents, legal guardians, and those with legal custody. This is arguably narrower than under the state laws, which often provide that a parent or guardian “may” invoke rights on behalf of the child. Similar to state laws that aim to deconflict consumer rights requests with COPPA requirements, controllers who comply with consumer rights processes under COPPA for children’s data requests would be deemed compliant with consumer rights requirements under this bill. These parental rights with respect to processing teens’ sensitive data and invoking teens’ data rights are a contrast to the state privacy laws. While a growing number of states envision some layer of heightened protections for teens, these laws typically do not require parental consent for processing the data of minors above the age of 12, broadly maintaining teen autonomy over data collection and processing decisions. 

The bill notably omits a knowledge standard for child and teen requirements—arguably creating ambiguity regarding when controllers should be on notice to implement age-specific protections and obligations. In contrast, state privacy laws commonly utilize either “actual knowledge” or “actual knowledge or wilful disregards” standards. Note that Congress is concurrently considering several other youth privacy and online safety legislative proposals—including COPPA 2.0 and the App Store Accountability Act—which could inform the future trajectory of this bill’s minor-specific protections and age-based knowledge triggers among related frameworks.

5.  Novel Requirements: Data Brokers, Cross-Border Data Transfers, and Codes of Conduct

While the majority of this bill borrows heavily from existing laws in states like Kentucky and Tennessee, it includes a few requirements that are either atypical or completely novel: data broker registration, explicit authority for the Secretary of Commerce to advise on cross-border data transfers, and Codes of Conduct under the law. 

First, the bill requires data brokers to register with the FTC, which would then publish a searchable registry. Similar requirements are seen in standalone data broker registry laws in Vermont, California, Nevada, Texas, and Oregon, though each varies in definitions and specific obligations. California’s Delete Act goes the furthest by creating an accessible deletion mechanism that allows a consumer to submit a deletion request to all registered data brokers. Compared to most state data broker laws, however, the bill’s definition of “data broker” is fairly narrow, covering a controller that (i) collects and processes personal data of a consumer who is not a customer or client of the controller or a user, reader, or subscriber of a product or service by the controller and (ii) derives at least 50% of its annual gross revenue from selling personal data. “Data broker” does not include a person acting as a processor. 

A novel addition to this bill compared to past iterations of a federal privacy framework are provisions concerning international data flows and the protection of personal data in international commerce. Notably, though, the bill does not propose any restrictions for the transfer of personal data of US persons across borders. On the contrary, the provisions seem to converge towards supporting the international flow of personal data. 

The bill would designate the Secretary of Commerce as the President’s principal advisor on international personal data flows and empower the Secretary to: assess foreign governments’ data protection frameworks for alignment with the bill’s protections; develop policy recommendations addressing topics such as the impact of international data flows on consumer rights, economic competitiveness, and U.S. security interests, including mitigation of risks posed to the international flow of personal data by “covered nations” (i.e., North Korea, China, Russia, and Iran); and negotiate international agreements with foreign governments, forums, or political and economic unions to promote cross-border data flows. The latter provision would seemingly cover agreements such as the existing EU/UK/Switzerland – U.S. Data Privacy Framework, opening the possibility for such agreements with other nations or political unions as well (more ambiguous is how the provision would relate to coverage of cross-border data transfers in international trade agreements, like the US-Mexico-Canada Agreement and the US-Japan Digital Trade Agreement). The concept of “assessing” foreign governments’ data protection frameworks for “alignment” with the protections in the bill is reminiscent of “adequacy assessments” in global international data transfers legal regimes. A data protection regime found adequate usually means that personal data can flow with no restrictions to that foreign nation. However, it is not clear to what end the assessment proposed in the bill would be conducted. 

Finally, one of the more interesting additions to the bill is codes of conduct. Any controller or processor (or group thereof) would be able to submit an application to the Secretary of Commerce for “approval of a code of conduct that meets or exceeds the requirements . . . under this Act.” Such a code of conduct must include an independent organization to administer the code, assess compliance, and refer would-be violators to the FTC or a state attorney general. There would be a  public comment period prior to approval, and the Secretary could later withdraw approval. Controllers or processors in compliance with an approved code of conduct would be entitled to a rebuttable presumption that they are in compliance with the relevant requirements of the Act. These codes of conduct appear loosely comparable to the safe harbor program provided in the COPPA Rule. Notably, a certification by the controller pursuant to the Global Cross Border Privacy Rules system (or any successor system) or a a processor pursuant to the Global Cross Border Privacy Rules System Privacy Recognition for Processors (or any successor system) would be treated as participation in an approved code of conduct. This appears to be inspired by similar provisions in Tennessee’s law and is consistent with efforts across successive U.S. administrations to promote the Global CBPR system. 

6. Preemption

With respect to state law, the bill includes broad preemption language that would prohibit any state, or political subdivision of a state, from prescribing, maintaining, or enforcing any law, rule, regulation, or other provision if it “relates to the provisions of this Act.” This broad “relates to” standard could preempt:

• State comprehensive privacy laws;
• Sectoral privacy laws including Illinois BIPA, Washington My Health My Data Act, and kids’ privacy laws; and 
• Data broker laws, including the California Delete Act and state data broker registration requirements.

Nonetheless, if this law passed, preemption would not be automatic. State laws would need to be challenged individually in court to determine whether specific provisions conflict with or “relate to” the federal law. For example, the CCPA/CPRA may be more difficult to fully preempt because it covers employee data, B2B data, and applicant data—categories the federal bill exempts. 

With respect to federal law, the bill explicitly preserves a number of federal privacy laws and regulations, including COPPA, GLBA, HIPAA, FCRA, and FERPA (to the extent a controller or processor is an educational agency or institution). The Communications Act of 1934 and any FCC regulations promulgated under that law would not apply to a controller or processor with respect to the collection, use, processing, transferring, or security of personal data. This bill would repeal the Video Privacy Protection Act (VPPA), 18 U.S.C. § 2710. 

7.  Enforcement

Enforcement authority for violations of the bill would be given exclusively to the FTC and state attorneys general. This approach is consistent with all of the state comprehensive privacy laws—but for California’s narrow private right of action (PRA) with respect to data breaches, none of the state comprehensive privacy laws include a PRA. 

The FTC would enforce violations of the bill as a violation of a trade regulation rule regarding unfair or deceptive acts or practices under the FTC Act. The FTC would also be authorized to enforce the bill against common carriers under the Communications Act of 1934. Notably, the FTC would be prohibited from enforcing any violation of section 3(c) of the bill, which prohibits a controller from processing personal data in violation of a federal law that prohibits unlawful discrimination against a consumer. Rather, the FTC would be directed to transmit any information indicating a violation of that provision to any agency with authority to initiate an enforcement action concerning it. 

The bill also empowers state attorneys general as parens patriae to bring civil actions seeking injunctive relief, damages, restitution, and other legal and equitable relief. Prior to filing an action, a state AG must provide the FTC with written notice of the action, allowing the FTC to intervene in the matter. A state AG would be prohibited from bringing an action against any defendant named in an ongoing civil action under the bill instituted by the FTC or the Attorney General of the United States (note: this is the only reference to the Attorney General of the United States under the bill). Overall, this enforcement structure is conceptually similar to that under COPPA, under which the FTC is the federal enforcement authority but state attorneys general are empowered to pursue actions providing that they notify the FTC, which has the right to intervene. It is notable that the state enforcement authority is limited solely to attorneys general whereas prior efforts such as the ADPPA and the APRA included carve-outs for a “State Privacy Authority of a State” or “an officer or office of a State authorized to enforce privacy or data security laws.” Without a comparable exception, CalPrivacy would not be able to enforce this bill. 

The bill includes a right to cure, requiring the FTC or a state AG to provide notice of an alleged violation and allowing 45 days for the controller or processor to cure the violation and promise that no such further violation shall occur. The state privacy laws are split as to whether they include a right to cure—some include no right to cure, some include a permissive cure option at the AG’s discretion, some have a right to cure that will sunset after a set date, and some have a mandatory right to cure with no sunset provision. An additional source of flexibility is the addition of codes of conduct (discussed below) which can entitle a participating controller or processor to a rebuttable presumption of compliance with this bill.

8. Conclusion

It’s a running joke in the privacy community that important bills always drop on Friday afternoons or holidays, so it was no surprise that this bill was released on everyone’s favorite spring holiday—Earth Day. Humor aside, a federal comprehensive privacy law is long overdue, and it is encouraging to see Congress renewing its attention to this topic. It remains to be seen whether the SECURE Data Act will fare better than prior efforts such as the ADPPA and the APRA. Although it appears that significant partisan consensus building has already gone into this process, which could ease the bill’s passage through committee, time is running out for the 119th United States Congress. 

What is already evident, however, is how much influence the state comprehensive privacy landscape exerted on this bill as compared to prior efforts. The bill’s key terms, rights, obligations, and overall structure closely resemble that of most of the state comprehensive privacy laws, based on the flexible WPA framework, even if the specific provisions selected hew more closely to the narrower iterations of that framework. We note that a number of the exclusions or omissions in the bill are likely intended to create a margin for negotiations with other members and stakeholders in order to garner support. Although the time frame is uncertain, this bill is the first significant proposal drafted to reflect the current landscape of state laws that already protect a majority of U.S. residents and may reflect a first draft of a framework that eventually becomes law. 

FPF will continue to monitor how this bill evolves as it progresses through committee and a broad set of stakeholders across industry, civil society, and academia provide their feedback. 

FPF on the Securing and Establishing Consumer Uniform Rights and Enforcement Over Data (“SECURE Data”) Act

The U.S. is overdue to adopt comprehensive federal consumer privacy legislation. Baseline protections for personal information in a federal privacy law would provide an essential foundation for progress on other Congressional priorities, including AI governance and youth online safety, and it’s encouraging to see Congress renewing its attention to this topic. In the absence of a federal law, twenty-one states have enacted comprehensive privacy laws that, while varying in detail, have generally converged around a common framework. The “SECURE Data Act” largely follows that consensus model, which could facilitate compliance for businesses already navigating state requirements. However, several states have taken different approaches or amended their laws in recent years, including expansions related to health data, minors’ data, and geolocation—raising questions about the extent to which a federal baseline should reflect these alternatives. Arriving at consensus will require careful analysis of which state provisions represent essential protections versus regulatory variation, and consultation with diverse stakeholders including industry, consumer advocates, state regulators, and technical experts. – Matthew Reisman, FPF Vice President for U.S. Policy

The Alabama Personal Data Protection Act Brings Consumer Privacy to the Heart of Dixie

We had to wait almost two years between when the 19th and 20th state comprehensive privacy laws were enacted, but the gap between the 20th and 21st proved to be a mere month. Governor Ivey signed HB 351, the Alabama Personal Data Protection Act (APDPA) into law on April 16. While this law is based on the popular Washington Privacy Act framework, it departs from that framework in a few ways (most notably in terms of what it is missing). For example, the law lacks a requirement to conduct data protection assessments and makes only passing references to authorized agents and opt-out preference signals. 

The APDPA will go into effect on May 1, 2027. This blog post provides an overview of the law’s scope, definitions, consumer rights, business obligations, and enforcement provisions. 

Scope

Covered Entities: The APDPA includes low applicability thresholds, applying to persons that conduct business in, or target products or services to the residents of, Alabama and either (1) control or process the personal data of more than 25,000 consumers (excluding data processed solely for completing a payment transaction), or (2) derive more than 25% of gross revenue from selling personal data, regardless of the number of consumers whose personal data is processed or sold. These thresholds are low. Most state comprehensive privacy laws set the main processing threshold at 100,000 affected consumers and the data sales revenue threshold usually also requires a minimum number of affected consumers (e.g., 25,000). For a list of applicability thresholds in other laws, see page 34 in FPF’s report on the state comprehensive privacy laws.

Entity and Data-Level Exemptions: This law includes a broad set of entity-level exemptions, including familiar exemptions for political subdivisions of the state, institutions of higher education, national securities associations, financial institutions and affiliates subject to 15 U.S.C. Chapter 94 or Title V of GLBA, and covered entities and business associates under HIPAA. The law also includes exemptions for certain political organizations and business entities that sell data primarily to certain political organizations. The law’s data-level exemptions include protected health information under HIPAA (in addition to other health and research -related exemptions), personal data covered by GLBA, personal information used for activities regulated by and authorized under FCRA, personal data regulated by FERPA, and more. 
Exceptions for Common Business Activities: Consistent with other state privacy laws, the APDPA includes a list of broad exceptions, such as: complying with federal, state, and local laws, regulations, inquiries, and investigations; preparing legal defenses; providing a product or service specifically requested by a consumer; performing a contract to which a consumer is a party or taking steps at the request of a consumer prior to entering a contract; taking immediate steps to protect an interest essential for the life or physical safety of an individual; preventing, detecting, or responding to security incidents or illegal activity; engaging in public or peer-reviewed research or processing in the interest of public health, subject to enumerated safeguards; internal research for product improvement; internal operations reasonably aligned with consumers’ expectations; and more.

Is there a small business exemption? State comprehensive privacy laws typically try to exclude small businesses, either by imposing high processing thresholds or by including an exemption for small businesses as a defined term. The APDPA includes a small business exemption, but the language departs from what other states have done. The law provides: “This act shall not apply to any of the following: . . . A business, including an organization cooperatively organized under Chapter 6 of Title 37, Code of Alabama 1975, or an entity that is an instrumentality of a municipal corporation, with fewer than 500 employees, provided the business does not engage in the sale of personal data.” The nonprofit exemption similarly applies only to nonprofits of a certain size (fewer than 100 employees) and who do not sell personal data. As drafted, the small business exemption is a little ambiguous. Based on the original language in the bill as introduced, the intent appears to be to broadly exclude businesses with fewer than 500 employees that do not sell personal data. However, the added language concerning cooperatively organized public utilities and entities that are instrumentalities of a municipal corporation could be read as narrowing the exemption to apply only to such entities. The distinction lies in whether the language “or an entity that is an instrumentality of a municipal corporation” applies to “[a] business” or “an organization cooperatively organized . . . .” Assuming the broader interpretation is correct and this applies to businesses other than those that are instrumentalities of municipalities, this exception is nonetheless different than how other states—Texas, Nebraska, and Minnesota—have approached this issue. Those states’ laws exempt “small businesses” as defined by the U.S. Small Business Administration—a definition that varies based on industry—and allow small businesses to sell sensitive data with a consumer’s consent.

Definitions 

The definitions generally align with the majority of state comprehensive privacy laws. For example: biometric data includes information generated from a photograph, video, or audio recording if used to identify an individual; consumer is defined as an individual acting in their personal (non-employment) capacity; controller is defined as an entity that determines the purposes and means of processing personal data; personal data is defined as any information that is linked or reasonably linkable to an identified or identifiable individual and does not include deidentified data or publicly available information; and there is nothing novel in the definition of sensitive data. 

One unique definition worth noting is the “sale of personal data.” The most common definition under state comprehensive privacy laws is the exchange of personal data for monetary or other valuable consideration by the controller to a third party. (See, e.g., Conn. Gen. Stat. § 42-515). Under the APDPA, a sale of personal data means the exchange of personal data (1) for monetary consideration by a controller to a third party, or (2) “for other valuable consideration by a controller to a third party where the controller receives a material benefit and the third party is not restricted in its subsequent uses of the personal data.” The “other valuable consideration” prong is potentially narrower than other laws that do not explicitly limit sales to exchanges where the data-recipient is “not restricted” in how they subsequently use the data. Depending on how specific a “restriction” on subsequent use must be, this could bring a number of data sharing agreements outside of the scope of the consumer opt-out right. More importantly, however, a sale of personal data does not include a “disclosure or transfer of personal data to a third party for the purposes of providing analytics services.” Given the prevalence of data-sharing for analytics agreements, this exception could narrow the consumer right to opt-out of the sale of personal data.

Consumer Rights

This law includes the standard suite of consumer rights to: confirm whether one’s personal data is being processed and to access such data; correct inaccuracies in one’s personal data; have one’s personal data deleted; obtain a copy of one’s personal data in a portable format; and opt-out of the processing of one’s personal data for the purposes of targeted advertising, the sale of one’s personal data, and profiling in further of solely automated significant decisions concerning a consumer.  Controllers must allow consumers to revoke previously given consent. These rights (including the opt-out right) do not apply to pseudonymous data if the controller is able to demonstrate that information necessary to identify the consumer is kept separately and subject to effective technical and organizational controls that prevent the controller from accessing the information. 

State comprehensive privacy laws typically allow consumers to exercise their opt-out rights via an authorized agent and, increasingly, via opt-out preference signals (“OOPS”). OOPS are usually introduced with a delayed effective date and a number of requirements for such a signal to be valid (e.g., it may not unfairly disadvantage another controller or make use of a default setting). This law does not explicitly provide for authorized agents or OOPS. However, the law does include a tacit acknowledge that a controller must comply with an OOPS because it describes what a controller must do if an OOPS conflicts with a consumer’s existing controller-specific privacy setting or voluntary participation in a controller’s bona fide loyalty program: “[T]he controller shall comply with the consumer’s opt-out preference signal but may notify the consumer of the conflict and provide the choice to confirm controller-specific privacy settings or participation in such a program.” Similarly, the only reference to an “authorized agent” comes when the law specifies that the means for consumers to exercise rights must consider “the ability of the controller to authenticate the identity of the consumer or authorized agent making the request” (emphasis added). These passing references to OOPS and authorized agents create significant ambiguity for controllers as to when they must comply with an OOPS or an authorized agent request (and, for authorized agents, which rights would be in scope). 

Business Obligations

Controllers and processors have enumerated responsibilities under the law, including transparency, data minimization, data security, non-retaliation, oversight of processors, and consent requirements for adolescents. Notably, this law does not require controllers to conduct data protection assessments for processing activities that pose a heightened risk of harm, breaking from the majority of state comprehensive privacy laws. 

Transparency: A controller is required to provide consumers with a “reasonably accurate, clear, and meaningful privacy notice” that includes required information, such as categories of personal data processed and processing purposes. Processing personal data for targeted advertising or selling personal data to third parties must be clearly and conspicuously disclosed in addition to how to opt-out of such. 

Data Minimization: The APDPA includes common procedural data minimization and secondary use restrictions— 

• A controller must limit the collection of personal data to what is adequate, relevant, and reasonably necessary in relation to the purposes for which the personal data is processed, as disclosed by the controller; 
• A controller cannot process personal data for purposes that are not reasonably necessary to, or compatible with, the disclosed purposes for which the personal data is processed, as disclosed by the controller; and 
• A controller cannot process a consumer’s sensitive data without obtaining the consumer’s consent. 

Data Security: A controller must establish, implement, and maintain reasonable administrative, technical, and physical data security practices to protect personal data. 

Non-retaliation: Controllers are prohibited from denying goods or services or providing a different level of quality for goods or services to a consumer in response to a consumer exercising an op-t-out right, subject to exceptions (e.g., if the data is necessary to providing a service or the data is processed in connection with a bona fide loyalty program). The law separately provides that, if a controller responds to a consumer opt-out request by informing the consumer of a charge for using a product or service, the controller must present the terms of any financial incentive for the retention, use, or disclosure of the consumer’s personal data. 

Processors: Processors are required to adhere to the instructions of a controller and assist the controller in meeting its obligations under the law, including by assisting the controller in responding to consumer rights requests as appropriate. There must be a valid contract in place between the controller and processor that meets statutory criteria (e.g., setting forth instructions for processing data, imposing a duty of confidentiality with respect to the personal data, obligating subcontractors to meet the processor’s obligations). 

Adolescent Privacy: This law approaches children’s and adolescents’ privacy similar to other state privacy laws. Personal data collected from a known child is considered sensitive data, a parent or legal guardian of a known child may exercise the consumer’s rights on behalf of the known child, and a controller cannot process personal data concerning a known child unless the processing is in accordance with COPPA. Additionally, the law has heightened protections for teenagers. Consistent with a growing minority of the state privacy laws—California, Montana, Oregon, Delaware, New Jersey, New Hampshire, and Minnesota—Alabama has heightened protections for teenagers. For consumers whom the controller has actual knowledge are at least 13 years of age but younger than 16, the controller cannot process the consumer’s personal data for targeted advertising or sell the personal data without the consumer’s consent. 

Enforcement

The law will go into effect on May 1, 2027 and will be enforced by the attorney general. The enforcement language is slightly ambiguous with respect to private rights of action (PRA). It is common under other state privacy laws to explicitly foreclose private lawsuits by providing that the law will be enforced “exclusively” by the attorney general and that nothing in the law will be interpreted as a basis for a private right of action under that law “or any other law.” (See, e.g., Conn. Gen. Stat. § 42-525(d).) The APDPA, in contrast, merely provides that “[t]he Attorney General may enforce violations of this act.” Absent a disclaimer to the contrary, plaintiffs may try to allege that a violation of the APDPA gives rise to a cause of action under another law.  

The law includes a mandatory cure period, requiring the AG to notify a controller of alleged violations and allowing 45 days to resolve violations. Civil penalties for violations are higher than most other states—up to $15,000 per violation. 

* * *

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. 

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

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). 

Recommendations include:

• Map and track the collection and use of all data that informs consumer pricing over time, including data sources and provenance. 

• Rigorously test all relevant datasets and pricing algorithms for bias.

• Establish clear internal policies around what data types and uses of data are permitted for informing consumer prices, based on an analysis of fairness, context, and consumer expectations.

• Provide clear disclosures to consumers about how data informs pricing, and how personal data may inform personalized offers.

• Ensure that personalized discounts exist in relation to real “baseline” prices. 

• Implement stronger safeguards around data-driven pricing for essential products.

• Ensure alignment on data use policies when partnering with pricing algorithm vendors.

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:

• The prohibition on the use of RBI systems in public spaces is narrowly tailored. All of the factors must be present for the prohibition to be triggered, otherwise the collection and use of biometric information is categorized as related to “high-risk” AI systems . 
• RBI systems can create a risk to the rights and freedoms of individuals simply by being deployed. The European Commission Guidelines and the AI Act Recitals both emphasize the risk of a “chilling effect” on the exercise of public freedoms that can come from a perception of ubiquitous surveillance. 
• The Guidelines and the AI Act itself make a significant effort to distinguish banned “remote biometric identification” from permitted uses of biometric identification, such as device-level identity verification.
• Mileage may vary – because the offenses for which an exception to the RBI prohibition may be sought are defined in Member State criminal law, actual implementation of the prohibition and its exceptions may diverge significantly in implementation.  

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: 

• Does this system qualify as “remote biometric identification”? 
• Is the system “real time”? 
• Is the space “publicly accessible”? 
• Is the system used for law enforcement purposes? 

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: 

• Whether the system captures “biometric information” 
• Whether the system is “remote”
• Whether the system is used for identification 

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:

• ‘Single target’ – RBI systems can only be deployed for the purpose of confirming the identity of a specifically targeted individual (except for the circumstances involving a genuine and present or foreseeable terrorist attack); 
• Seriousness – assessment of the possible harm and consequences against the interference with fundamental rights, and inclusion of the offense in Annex II of the AI Act; 
• Scale – the number and category of persons affected by interference; 
• Probability –  likelihood that negative event will occur;
• Geographic restriction – where the system will be deployed or the event may occur;
• Personal scope – defining the categories of persons concerned with the deployment; 
• Time limit – duration of deployment must be limited to what is strictly necessary.

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: 

• A description of the RBI use and the deployer’s processes for the use, together with the intended purpose of use; 
• The period of use and frequency of use;
• The categories of persons and groups affected by the system;
• The specific risks of harm to the affected persons;
• Human oversight measures; and
• Risk mitigation measures.

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:

• Scope: California and Washington take a broader, capability-based approach to define companion chatbots, while Oregon uses a narrower, behavior-based definition with more carve-outs, making its scope more targeted.
• Requirements: All three include disclosures and self-harm protocols, but Washington is the most prescriptive (e.g., additional requirements on engagement design, safeguards), and California is the most limited and disclosure-focused.
• Enforcement: All three enforce via a private right of action, with California and Washington including statutory damages, while Washington relies on its Consumer Protection Act for enforcement.

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.

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:

• Oregon: applies the broadest knowledge standard—“knows or has reason to believe”—likely requiring companies to act on signals or inferences about age.
• Washington: uses actual knowledge but also covers systems “directed to children,” a concept that could expand scope depending on interpretation.
• California: is the narrowest, relying solely on actual knowledge.

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.

2. 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:

• Eating Disorders: Washington explicitly includes eating disorders in its protocol, expanding beyond suicide and self-harm. This inclusion raises line-drawing challenges (e.g., distinguishing harmful content from benign requests like nutrition advice) and may push operators toward over-restricting content and relying on inferred signals about user behavior.
• Generating Content: Washington and California require operators to prevent chatbots from generating content that encourages or explains self-harm, moving beyond detection and referral into direct regulation of system outputs. This requirement may require more robust filtering and monitoring systems.
• Evidence-Based Methods: California and Oregon reference “evidence-based” or clinical best practices. Washington instead relies on a more flexible “reasonable methods” standard, which may allow for greater variation in implementation.
• Transparency Reporting: All three require public disclosure of safety protocols, but California and Oregon go further by requiring annual reporting (to a state office in California and publicly in Oregon). Both prohibit inclusion of personal data, though OR’s fully public model may raise different considerations around how information is presented and accessed. 

3. 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.

4. 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:

• Returning and engagement prompts: Washington restricts prompts encouraging users to return for emotional support or companionship. While aimed at reducing dependency, this could also encompass common features like reminders to continue a conversation.
• Isolation and withholding information: The law prohibits outputs that promote isolation from family or encourage withholding information from “trusted adults.” While protective in intent, these provisions may be difficult to apply in situations involving family conflict or abuse, and the term “trusted adult” is undefined.
• Discouraging breaks: Washington also restricts statements that discourage users from taking breaks or suggesting frequent return, a broad category that could cover a wide range of engagement strategies.

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: 

• The AI Act prohibits specific biometric inference practices, not biometric categorization as such – 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 prohibition is not triggered only by the presence of biometric analysis, but by the intended inference of protected attributes from biometric data. 
• The relationship between this prohibition and EU data protection law needs further clarification – Given that the AI Act itself clarifies that it does not affect the application of the GDPR, and some processing of biometric data that may result in biometric categorization can be lawful under Article 9(2) GDPR when following its strict conditions, further clarification is needed with regard to the intersection of the two laws.  

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.

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.