0
Image of a cellular phone with the ChatGPT app open.

Overview: The EU General-Purpose AI Code of Practice

AI & Algorithms, Cybersecurity, EU , , , ,

Why Do We Need a Code of Practice?

On August 2, 2025, the general-purpose AI (GPAI) provisions of the EU AI Act went into effect. GPAI models (including models that support most generative AI, like ChatGPT), now face certain obligations in the EU, including requirements around transparency, copyright and systemic risk. However, the EU AI Act is a framework: it defines obligations but leaves technical details to harmonized standards and codes of practice. While this approach sets certain expectations and allows the EU AI Act to remain technology-neutral, it also leaves questions about how businesses substantially comply with the EU AI Act. To bridge this gap, a multi-stakeholder group drafted the General-Purpose AI Code of Practice (GPAI Code). On August 1, 2025, the European Commission issued a formal opinion confirming the GPAI Code is an “adequate tool” to help demonstrate compliance with the EU AI Act. Why is the Code significant? This opinion signals that organizations who adopt the GPAI Code may be able to demonstrate good-faith efforts to comply with the relevant provisions of the EU AI Act –  according to the Commission’s website: “The Code of Practice helps industry comply with the AI Act legal obligations…of general-purpose AI models.” In its opinion, the Commission notes that the Code provides actionable commitments and reporting mechanisms, especially for high-risk models. Additionally, the Commission emphasized that the Code provides a practical framework to demonstrate regulatory compliance. Following this endorsement, providers of GPAI models can voluntarily sign the Code, which “will reduce their administrative burden and give them more legal certainty than if they proved compliance through other methods.” Still, signatories should be aware that the Code explicitly states that adherence to the Code does not necessarily constitute evidence of compliance with the EU AI Act.

What is a General-Purpose AI Model?

A GPAI model is a component of an AI system with a wide range of possible uses, whether intentional or unintentional. It is important to note that these models are not systems in themselves but are part of AI systems. Additional elements, like user interfaces, are necessary to make these models fully operational systems. Under Article 3(63) of the EU AI Act, a GPAI model includes those trained on a “large amount of data using self-supervision at scale.”  They can be applied across sectors or tasks, usually without substantial modification, meaning GPAI models “can be integrated into a variety of downstream systems or applications.” Recital 98 of the EU AI Act states that the generality of the model can also be determined by the number of parameters, and “models with at least a billion parameters…should be considered to display significant generality and to competently perform a wide range of distinctive tasks.” GPAI models are sometimes called “foundation” or “frontier” models, and while they may include large language models (LLMs), they can also process audio, physical, textual or visual data, powering systems like DALL-E, GPT-4, Gemini, LaMDA, SEER, ALIGN, and more.

How are general-purpose AI models regulated?

Under the EU AI Act, the chapter on GPAI both addresses generative AI and outlines some of the most stringent requirements under the Act. However, all requirements for GPAI under the EU AI Act are directed to providers as opposed to deployers. Providers of GPAI models have a range of obligations under the EU AI act, both directly to supervising authorities and onward to AI providers who integrate the GPAI models into their systems. Obligations of Providers of GPAI Models If a provider places a GPAI model on the EU market, or integrates such a model into its own AI system on the EU market, it must:
  • Prepare and maintain technical documentation for regulators. This should include at least a general description of the GPAI model, including the tasks it’s designed to perform and the types of systems in which it can be integrated; acceptable use policies; and information on training process.
  • Prepare and maintain documentation for downstream providers. This should include information that allows the downstream AI system providers to comply with their own obligations under Article 53(1)(b). Similar to the technical documentation, this includes but is not limited to a general description of the model, and a description of its elements and development process.
  • Prepare an EU copyright policy. This policy should establish a means to comply with EU regulations on copyright and related rights.
  • Prepare and publish a summary of training content. Using the template provided by the AI Office, providers of GPAI must share a comprehensive summary of AI training information. This should allow stakeholders to exercise their rights by informing them of the information used to train the GPAI model.
  • Cooperate with relevant authorities and appoint an authorized representative. Providers must also cooperate with relevant authorities, and if they are established outside the EU, appoint an authorized representative located in the EU.
It is notable that under Recital 85, the EU AI Act states that GPAI systems “may be used as high-risk systems by themselves or be components of other high-risk systems.” Therefore, the providers of GPAI systems must work closely with providers of high-risk AI systems to ensure compliance with any requirements of high-risk systems under the Act. Obligations of Providers of GPAI Models with Systemic Risk What does “systemic risk” mean? GPAI models with systemic risk include models that reasonably pose foreseeable negative effects relating to major accidents, disruption of critical sectors, serious consequences to public health and safety, public and economic security, democratic processes, and the dissemination of false or discriminatory content, or other similar effect. Under Article 51(1) of the EU AI Act, a GPAI model will be classified as having systemic risk if:
  • It has high impact capabilities, or
  • It is designated by the Commission to have high impact capabilities based on the criteria in Annex XIII (i.e., the number of parameters in the model, the size of the data set, the amount of computation used to train the model, etc.).
What are the additional obligations for these models? In addition to the requirements for all GPAI models, those with systemic risk have additional obligations related to:
  • Model evaluation, assessment, and mitigation of systemic risks;
  • Incident management and reporting; and
  • Cybersecurity protections and technical documentation.
Because there are differences in the obligations between GPAI systems generally and GPAI systems with systemic risk, this classification procedure should be noted by providers of GPAI systems; it is essential to understand where each GPAI model falls, and what requirements the model has under the EU AI Act. According to Article 52(6), a list of GPAI models with systemic risk will be published and updated by the European Commission, but it has not been published at the time of writing.

What is the General-Purpose AI Code of Practice?

While not legally binding, providers of GPAI models can use the Code of Practice to demonstrate compliance with their obligations under the EU AI Act. The Code consists of three chapters on 1) transparency, 2) copyright, and 3) safety and security. The first two chapters apply to all providers of general-purpose AI models, providing a way to demonstrate compliance with obligations under Article 53 of the AI Act. The final chapter applies only to general-purpose AI models with systemic risk under Article 55 of the AI Act. Chapter 1: Transparency Among other things, this chapter requires signatories to create and maintain documentation for all GPAI models distributed within the EU for up to ten years. There are exceptions for models that are free, open-source, and do not pose systemic risk. When completing this documentation, signatories must use a standard Model Documentation Form, which includes information on licensing, technical specifications, training data, and other parameters of the GPAI model. The Code encourages publication of this information to promote transparency. Chapter 2: Copyright This chapter requires signatories to create and maintain a copyright policy that complies with the EU’s legal standards. This includes, but is not limited to, ensuring that data collected by web crawling is lawfully accessible, and certain websites flagged for copyright infringement are avoided. Importantly, signatories must designate a contact for copyright holders to submit complaints, along with a process for handling those complaints. Chapter 3: Safety & Security (GPAI with systemic risk only) One of the main elements of this chapter is the requirement for signatories to develop a state-of-the-art Safety and Security Framework before releasing any GPAI model categorized as posing a systemic risk. Additionally, systemic risks should be identified and inventoried, and before progressing with development or deployment, the signatories should weigh the relative risks and determine if they are acceptable, among other requirements.

What’s next?

The Code will be monitored and reviewed at regular intervals by the AI Office, and may be updated in response to emerging risks, technological developments, or incidents involving general-purpose AI models.
0

The Do’s and Don’ts of DSARs: A Practical Guide for Responding to Data Subject Access Requests

DSAR, EU, GDPR, State Privacy Laws, United States , , , , , ,
Handling data subject access requests (DSARs) isn’t as easy as ticking a compliance checkbox. It can be a test of an entity’s data organization, internal communication, and understanding of legal requirements. Between navigating jurisdictional nuances and meeting strict deadlines, the DSAR response process can quickly unravel without a clear plan. In this guide, we suggest best practices for handling and responding to DSARs, along with tips and common pitfalls to avoid when planning effective responses.

1.    Understand the Individual’s Ask

Under international data privacy laws, including those in the US and EU, individuals may have rights over the personal data collected about them by covered entities. The way individuals generally actualize those rights are through DSARs submitted to the relevant entities. These rights can include, but are not limited to:
  • Accessing Data: Individuals may request access to all or specific categories of their personal data.
  • Ceasing Data Processing: Individuals may request the entity stop processing their personal data.
  • Data Correction or Deletion: Individuals may request rectification of inaccurate or outdated personal data or even request the deletion of their personal data.
  • Processing Information: Individuals may request what their personal data is used for and why.
  • Portability: Individuals may request to receive a copy of their personal data in a portable format.
When an individual makes a request to exercise one of these rights, the entity must then respond to the request within a set time frame determined by the applicable law. These time frames differ between applicable laws, so the first step is ensuring you know the appropriate time frame to apply. Who can submit a DSAR? DSARs may be submitted by individuals whose data is processed by entities under the scope of laws like the GDPR and US state privacy laws. Depending on the jurisdiction, DSARs may also be submitted by employees of the covered entity or by agents appointed by the individual and authorized to submit DSARs on the individual’s behalf. Why are DSARs important? DSARs allow individuals to determine what information a covered entity holds about them, how it’s being used, and why it is being processed. In short, they empower individuals to understand and exert some control over their personal data. Additionally, DSARs serve as a tool to confirm that covered entities are upholding their promises: by using these requests, individuals can check whether entities are adhering to both privacy laws and customer privacy notices. This allows individuals to better hold entities accountable for lawful data processing.

2.    Build A Response Team

Given the complexity of modern data systems, internal collaboration is essential when handling DSARs. Clear communication helps ensure DSARs are handled effectively—especially for more comprehensive requests, like deleting or accessing an individual’s data. To build your response team, start by identifying key players. Privacy officers can help oversee legal and regulatory compliance, data experts can help retrieve and process data securely, and communication teams can help draft clear responses to requests and questions. While the specific structure of each team will vary based on the covered entity’s size and complexity, every member of the team should understand the DSAR requirements and specific responsibilities, and get proper training based on their role. Do: Train Your Team       Training is critical to help every member of the team understand the importance of DSARs and their role in maintaining compliance. This isn’t about knowing the legal jargon—each team member should be able to recognize these requests (even if worded in a vague or informal way) and how to execute the steps required to meet deadlines. Since each DSAR is unique, teams should also have a clear point of contact for guidance and next steps if there is any confusion. Don’t: Delay Decisions Effective responses generally take effective planning. Because of the tight DSAR response deadlines imposed by applicable laws, covered entities should plan for these requests before they arrive. By defining clear rules, covered entities can avoid last-minute confusion and chaos when responding to DSARs.

3.    Prepare A Playbook

The regulatory landscape governing DSARs is far from uniform. Because each law may have its own requirements and response timeline, it is essential to understand jurisdiction-specific obligations. A playbook is a simple way to address these obligations in one place and guide the response team through a step-by-step process. To create a playbook, consider:
  • Legal scope: Identify applicable laws based on where the entity operates and whose personal data they process.
  • Verification requirements: Confirm the verification requirements, if any, under each law to determine what steps are needed to confirm the identity of the individual submitting the DSAR.
  • Data retrieval methods: Determine what tools and workflows are needed to locate and compile data efficiently, and how this information may be transmitted to the individual, if necessary.
  • Template responses: Draft standardized responses for anticipated outcomes, like fulfillment or denial of requests, or requests for additional information.
  • Escalation plans: Provide guidance for handling complex requests.
Playbooks should be regularly reviewed to reflect changes in regulations or operational processes. Do: Note the Nuances of Each Law Laws that provide individuals with rights over their personal data commonly include exemptions, such as data that is covered by other laws. Double-check and note these requirements for each jurisdiction and ensure that the playbook is marked in a way that users can easily understand it. Don’t: Forget to Customize Using the same strategy for every DSAR risks a misstep in responses. Privacy laws are often unique, and failing to adapt to these nuances can lead to delays, incomplete responses, or even regulatory penalties. By making your playbook specific to both your entity’s needs and the requirements of each jurisdiction, you are better preparing your team to handle DSARs.

4.    Respond Effectively

Most data privacy laws require a response within a certain time frame from when the request was received. In other words, once a DSAR is received, a clock usually starts ticking. We suggest the following steps as a starting place for a well-executed response, but your steps should be tailored to the applicable legal requirements:
  1. Acknowledge the Request: Confirm the request and provide a clear timeline for how the request will be handled.
  2. Verify the Identify (as needed): Ensure the individual’s identity is confirmed, if required by the relevant laws.
  3. Locate and Collect Data: Collaborate across departments as needed to gather the relevant information.
  4. Review Data for Exceptions: Identify data that may be exempt from disclosures or require redaction, like data that pertains to another individual.
  5. Respond Clearly: Deliver the response in a clear, accessible format with an explanation of how that response was arrived at.
  6. Record and Learn: Maintain detailed records for accountability and review the process regularly.
 Do: Build a Feedback Loop    The best way to learn is by doing. After developing your playbook, perform a trial exercise to ensure your communication is streamlined and a test request is handled as expected. Then, talk to your team to review what went well and what improvements are needed. By viewing this process as iterative, with modifications and refinements made along the way, the DSAR response team can effectively grow and shift with the volume of requests or any regulatory changes. Don’t: Overlook Redaction and Exemptions Redaction and exemptions can easily be overlooked, but neglecting these steps can lead to non-compliance, or even a breach. Always double-check any information before it is disclosed and verify that all information is accounted for and handled appropriately.   While typically seen as a compliance obligation, DSARs can also present an opportunity for entities to demonstrate data privacy and transparency. Each DSAR is a chance to refine operations, and with a capable response team and a detailed playbook, entities can approach the process with a better understanding of compliance.
0
An image of the flag of Europe, which consists of twelve golden stars forming a circle on a blue field.

EDPB Opinion on AI Models and GDPR Principles: Key Takeaways

AI & Algorithms, EEA & UK, EU, GDPR , , , , ,
In December 2024, the European Data Protection Board (EDPB) issued an Opinion in response to a request from the Irish supervisory authority, focusing on the application of GDPR principles in the context of AI models. The Irish supervisory authority posed three specific questions:
  1. When and how can an AI model be considered “anonymous”?
  2. What is the appropriateness of legitimate interest as a legal basis for AI deployment and development?
  3. What are the consequences of unlawful processing of personal data on subsequent operations of the AI model?
Through its answers, the EDPB provided key guidance on how AI models interact with fundamental rights to privacy and data protection established in the GDPR.

Anonymous AI Models

According the EDPB, “[f]or a model to be anonymous, it should be very unlikely 1) to directly or indirectly identify individuals whose data was used to create the model, and 2) to extract such personal information from the model through queries.” While anonymous data can help mitigate privacy concerns, it does not automatically make the AI model completely exempt from GDPR compliance. When a model is claimed to be anonymous, supervisory authorities will evaluate the claims of anonymity on a case-by-case basis, considering “all the means likely to be used” by the controller or a user. The Opinion states that supervisory authorities should review the documentation provided by the controller when assessing if the model is truly anonymous. The EDPB outlines methods that the controller may use to demonstrate anonymity, which may include: 1) reducing the amount of personal data used during training, 2) taking steps to ensure this data cannot be identified, and 3) utilizing technical safeguards to prevent data extraction from the AI model using prompts or queries. Key Takeaway: If a business claims an AI model relies on anonymous data, the claims of anonymity should be substantiated on a case-by-case basis with sufficient evidence and documentation. To do this, businesses with allegedly anonymous AI models may need to implement technical measures to limit the collection of data, reduce the likelihood of data being identifiable, protect against that data being extracted by users during deployment, and create documentation capable of demonstrating these efforts.

Legitimate Interest as a Legal Basis

Under the GDPR, a legitimate interest may constitute a legal basis for companies to process personal data when they have a justifiable reason to do so (beyond obtaining consent). However, the legitimate interest should be balanced against the data subject’s rights and interests, which requires careful consideration and justification when processing information from data subjects. The Opinion provides a framework to assess if a legitimate interest can be a valid legal basis for processing personal data in AI development and deployment. The framework is comprised of a three-step test:
  1. Identify the legitimate interest pursued by the controller;
  2. Assess the necessity of the processing for purposes of the legitimate interest; and,
  3. Balance the legitimate interests against the rights and freedoms of the data subjects.
When conducting this test, the controller should be careful to identify an interest that is lawful, clearly articulated, and non-speculative. For example, a legitimate interest may be to develop an AI model’s conversational agent or to improve threat detection in an information system. The controller should also adhere to GDPR data minimization principles, which state that the processing activities must be proportionate and in line with only what is necessary to achieve the legitimate interest. Finally, controllers should conduct a nuanced balancing test. This test considers the unique circumstances of each case, which may include the data subject’s interest in retaining control over their data, personal benefits, or socioeconomic interest. The Opinion notes, the more precisely an interest is defined in relation to the purpose of the processing, the more precise the estimation of benefits and risks will be. By employing this framework, developers and deployers should be able to decrease the likelihood that their AI models are disproportionately infringing on individual privacy rights and better align their AI practices with GDPR requirements. Key Takeaway: The three-step analysis, according to the Opinion, is crucial to improving compliance for organizations relying on legitimate interest as a legal basis for processing in AI development or deployment. Organizations relying on legitimate interest in this AI context should review their processing activities to determine whether they are proportionate, transparent, and aligned with GDPR principles—like data minimization—to justify the reliance on legitimate interest as a legal basis for processing.

Consequences of Unlawful Processing

The Opinion notes that supervisory authorities enjoy discretionary powers to investigate and assess violations, and they can choose appropriate remedial measures based on the context of the case. However, the EDPB also provides guidance for the supervisory authorities, based on three scenarios.
  1. In the first scenario, personal data is retained in the AI model. The Opinion states that supervisory authorities will need to consider the surrounding circumstances of the AI model to determine if the development and deployment phases of the model involve different legitimate purposes for processing. If so, each should be examined separately.
  2. In the second scenario, personal data is retained in the model and is processed by another controller during deployment. In this instance, the supervisory authorities should determine if the deploying controller conducted an appropriate assessment to demonstrate accountability with Articles 5(1)(a) and 6 of the GDPR. This assessment should show that the AI model was not developed by unlawfully processing personal data.
  3. In the final scenario, a controller unlawfully processes personal data to develop the AI model, and then anonymizes the data before processing it in the context of deployment. The Opinion states that, if it can be demonstrated to the supervisory authorities that the deployment of the AI model does not entail the processing of personal data, then the GDPR does not apply. Therefore, the unlawfulness of the initial processing in development should not impact the deployment operation of the model.
While supervisory authorities do have substantial discretion in oversight of processing activities, the scenarios highlighted by the EDPB show that the development and deployment phases, while connected, may need to be evaluated independently. Key Takeaway: Organizations should proactively ensure compliance at both the development and deployment stages of an AI model. Supervisory authorities will likely use the above examples as guidance, emphasizing the important of demonstrating lawful practices through each stage of the model. The EDPB’s Opinion is an important guide for organizations navigating the intersection of AI and data privacy law. By addressing issues around anonymous AI models, legitimate interest, and lawful processing in development and deployment stages, the Opinion emphasizes responsible AI development. As AI technologies continue to advance, businesses should be aware of the ways supervisory authorities are overseeing their AI models. The insights provided by the EDPB provide a foundation to help businesses to advance and develop new AI models, while also helping to safeguard and protect the rights of individuals.
0

Upcoming Webinar: The EU AI Act: How Will It Affect Your Business?

AI & Algorithms, EU , , , , , , , ,
On Thursday, December 12, 2024 at 11am ET, DataCamp will host a live webinar titled “The EU AI Act: How Will It Affect Your Business?” The speakers are Dan Nechita, Lead Technical Negotiator for the EU AI Act on behalf of the European Parliament, and Lily Li, Data Privacy, Cybersecurity & AI Lawyer and Founder of Metaverse Law. They will cover AI governance and risk management requirements under the EU AI Act and new US AI law. Attendees will:
  • Learn about the scope and requirements of the EU AI Act and other AI legislation.
  • Understand the risk classification system and the requirements for AI literacy.
  • Learn how to comply with regulations and the consequences of non-compliance.
  Join us for this informational webinar by registering at the DataCamp website using this hyperlink.
0
Robotic hand and human hand pointing toward each other with the letters "AI" in between them.

Comparing EU and US AI legislation: déjà vu to 2020

AI & Algorithms, Biometrics, Employment Law, United States , , , ,
This article was initially published in Reuters and Thomson Reuters Westlaw Today.   Lily Li of Metaverse Law discusses the landscape for AI legislation, with the passage of the European Union’s AI Act while states pass AI bills with differing thresholds, coverage and subject matter.   The landscape for EU and US AI legislation feels like a rinse and repeat of data privacy legislation in 2020. Back then, the General Data Protection Regulation (GDPR) was in full force and effect, while California and other states were developing privacy laws at breakneck speed. Many companies were caught unaware by GDPR, only to face a new onslaught of US state-by-state privacy laws.   Now, companies face the same problem. The EU has just passed a comprehensive AI law, the EU AI Act, which imposes significant compliance obligations and antitrust-style mega fines.   In the United States, state legislatures are passing AI bills at a breakneck speed, with differing thresholds, coverage and subject matter. Do global companies bite the bullet and comply with the EU AI Act globally, or should there be a more nuanced jurisdiction-by-jurisdiction approach?   Comprehensive and imposing   The EU AI act is a comprehensive law that has been in development for years by EU regulators. One of its unique features, not seen in US legislation, is a complete ban on certain “prohibited AI practices” (Article 5, https://bit.ly/4gQHfe8). Some of these prohibited practices include assessing whether an individual is likely to commit a crime and real-time biometric identification by law enforcement (think Minority Report), as well as social scoring of individuals.   In addition to setting forth prohibited practices, the EU AI Act designates a list of high-risk AI practices. This includes, but is not limited to, use of AI in employment decisions, credit scores, insurance and access to services. For these high-risk AI practices, AI providers need to implement a full risk management program that considers the following factors:  
  • Data governance
  • Technical documentation
  • Recordkeeping
  • Human oversight
  • Accuracy, robustness, and cybersecurity management
  • Quality management
  Like the GDPR, the EU AI Act imposes significant fines. This can be up to $35,000,000 or 7% of total worldwide revenue, whichever is higher, for engaging in prohibited AI practices (Article 99, https://bit.ly/3XRewgl), and up to $15,000,000 Euros or 3% of the total worldwide annual turnover, whichever is higher for other violations (Article 99, https://bit.ly/3XRewgl). The law requires each EU country to designate at least one independent and impartial body to monitor and enforce the EU AI Act’s requirements.   In contrast, the US is following a patchwork approach. Instead of comprehensive federal legislation, we are seeing a state by state and agency approach. To date, these laws generally fall into four main categories: (i) consumer protection; (ii) employment rights; (iii) image and likeness rights; and (iv) transparency/ risk assessment requirements for high-risk AI processing.   Consumer protection   For state consumer protection laws governing AI, Utah is one of the first movers. In May of 2024, it added requirements governing AI to its consumer protection statutes. Utah’s AI Policy Act requires businesses in Utah to disclose the use of generative AI tools, and also makes businesses liable for any consumer protection violations by these generative AI tools.   At the federal level, the FTC has used its consumer protection authority under Section 5 of the FTC Act, in order to regulate against unfair and deceptive practices in commerce concerning AI. In 2022, Weight Watchers agreed to pay a $1.5 million civil penalty in a settlement with the FTC, in part over allegations that the company improperly collected children’s data to train its models and algorithms. This settlement included “algorithmic disgorgement” — i.e., Weight Watchers was required to delete any models trained on such data.   More recently, on Sept. 25, 2024, the Federal Trade Commission (FTC) has cracked down on companies that make misleading or fraudulent claims about their use of AI tools. This included taking action against DoNotPay (https://bit.ly/3BtSWXW), a company that claimed to offer an AI service that was “the world’s first robot lawyer.”   DoNotPay agreed to a $193,000 settlement with the FTC, pursuant to a consent order. The consent order (https://bit.ly/4dNyjmN) also requires DoNotPay to refrain from “representing that its Service or any other internet-enabled product or service that it offers operates like a human lawyer or any other type of professional, unless that representation is not misleading and DoNotPay possesses competent and reliable evidence to substantiate the representation.” In addition, DoNotPay is required to notify consumers of the order and to submit compliance reports to the FTC.   AI in employment decisionmaking   At the employment level, Illinois recently enacted a law that prohibits the use of AI systems from discriminating against employees or job applicants based on any protected classes.   In addition, this amendment explicitly bans the use of race or zip code when used as a proxy for race in AI systems making employment decisions. Illinois’ requirements join New York City Local Law 144 (https://on.nyc.gov/3zHlSva) in regulating automated employment decision-making tools. While Local Law 144 does not include an explicit ban on the use of race or zip code in AI systems, it has very stringent notice and audit rights.   Where employers use AI systems “to substantially assist or replace discretionary decision making,” Local Law 144 requires publicly available third-party bias audits of automated employment decision-making tools.   Image and likeness rights   Generative AI is also regulated by state laws and cases governing image and likeness rights. Following the actors and writers strike in Hollywood, and high-profile litigation by Sarah Silverman and others, California has acted. In the last week, Governor Gavin Newsom signed two AI bills designed to protect entertainers.   AB 2602 requires contracts with actors and other performers to specify whether generative AI will be used to create a replica of the performer’s voice or likeness. AB 2836 bans the use of digital replicas for deceased performers, without the consent of the performer’s estate.   Transparency and risk assessment   The majority of US state comprehensive data privacy laws require transparency concerning the use of AI to process personal data and make decisions that impact important rights, such as employment, housing, and access to services. In addition, these laws generally give consumers the right to opt out of such processing.   Colorado’s AI Act, slated to go in effect in 2026, goes even further. It imposes risk assessment and bias assessment requirements for any “high-risk artificial intelligence system” that makes or is a substantial factor in making a consequential decision.   For purposes of the law, “consequential decision” means a decision that has a material or similarly significant effect on the provision or denial to any consumer of, or the cost or terms of:  
  • Education
  • Employment
  • Financial or lending services
  • Essential government services
  • Health-care services
  • Housing
  • Insurance
  • Legal service
  The Colorado AI Act has even more substantial transparency and notification obligations. As just one example, developers and deployers of “high-risk” AI systems are required to publicly post on their websites a description of the high-risk systems, as well as describe how the AI system manages the risks of bias. This includes further reporting to the Attorney General of “any known or reasonably foreseeable risks of AI discrimination arising from the intended use of the system.” Section §6-1-1702(5).   Where to go from here?   The trend lines are clear, and AI legislation is here to stay. While the US has not enacted federal AI legislation of the same scope as the EU AI Act, we already see significant risk assessment and transparency requirements. As a result, AI companies need to go global with their AI risk management strategies and not get left behind.   Lily Li is the founder and president of Metaverse Law. She advises global clients on their AI risk assessments and data protection impacts assessments, and supports her clients’ overall governance, risk, and compliance (GRC) programs. In addition, she holds the GIAC Certified Forensic Analyst (GCFA) certification for advanced incident response and digital forensics and certifications in information privacy such as the FIP, CIPP/US/E/M. She is based in Newport Beach, California, and can be reached at info@metaverselaw.com.
1 2