AI Watermarking: Key Updates on New Transparency Rules

AI & Algorithms , , , , , , ,

As generative artificial intelligence (AI) continues to advance, it’s becoming increasingly difficult to distinguish human-created content from AI-generated material. In turn, regulators are requiring certain AI systems to disclose where and how content is created. 

Two important examples are the European Union’s AI Act and California’s AI Transparency Act. While both of these laws address AI-generated content, neither requires businesses to use the same type of disclosure in every situation. Instead, the rules distinguish between different forms of transparency, including machine-readable markings that may not be visible to the human eye. These requirements may apply to both the provider of the AI system and the deployer, or the entity that makes the AI available to consumers.

The laws are falling into place, but how do they work in practice? For businesses developing or using generative AI, the challenge is not only whether AI-generated content should be watermarked, but how different types of media should carry that watermark. 

The EU AI Act 

Transparency requirements under Article 50 of the EU AI Act became generally applicable on August 2, 2026, with a grace to December 2, 2026, for certain products that were already on the market as of August 2, 2026. 

Among other requirements, providers of AI systems that generate synthetic text, images, audio or video must generally ensure that the output can be detected as artificially generated or manipulated. This may include machine-readable markings built into the content rather than displayed as a visible layer. 

The AI Act also creates separate disclosure requirements for certain users of AI-generated content. For example, deepfakes generally must be clearly disclosed as AI-generated or manipulated; AI-generated or manipulated text about matters of public interest may also require disclosure when it is published without human review. 

While the law provides the end goal, it does not necessarily define how to achieve it. For example, the EU AI Act was accompanied by the Guidelines on Transparency Obligations for Providers and Deployers of Certain AI Systems. These guidelines provide definitions and explain how compliance with the AI Act’s transparency obligations may be demonstrated. But still, these guidelines defer to “providers and deployers [who] can determine adequate measures themselves, while taking into account these guidelines.” In short, this means the EU AI Act sets the standard but leaves the means of meeting it to the AI provider or deployer. 

This means AI transparency can look different, both because of the media involved and because the provider or deployer can determine how best to meet these transparency standards. For example, a machine-readable watermark may help technology detect that AI was involved, while a visible or audible disclosure is meant to inform the person viewing or interacting with the content that it was AI- generated or altered. But the form and format of these transparency measures may largely be subject to the organisation’s discretion. 

The California AI Transparency Act 

California has also adopted AI-content transparency requirements through the California AI Transparency Act. Originally enacted through SB 942 and amended through AB 853, this law went into effect on August 2, 2026. 

The law generally requires providers of any “large online platform” – that is, a publicly available generative AI platform with over 2 million unique monthly visitors over the preceding 12 months – to provide tools that can help users determine whether covered image, video or audio content was created or altered by an AI system. 

The California AI Transparency Act distinguishes between two different types of disclosures: latent and manifest. A latent disclosure is built into the content, but it’s not readily visible to the average person. A manifest disclosure is one that a layperson can more easily see and understand. 

California’s requirements are also evolving. Businesses subject to the law may need to monitor legislative changes as lawmakers revisit how disclosure and detection requirements need to operate. 

What does AI watermarking look like? 

Anthropic’s recent changes to Claude provide one example of how companies may approach these requirements. 

In August 2026, Anthropic announced that the new Claude models would include machine-readable markings in response to the EU AI Act and other similar legislative requirements. For generated text, Claude uses an imperceptible watermark based on patterns in how the model selects words. According to Anthropic’s press release, the watermark is not a visible or hidden set of characters and does not identify the person or company who generated the content. 

However, these tools are far from perfect. Anthropic explains that a text watermark can disappear or weaken; they describe it as not “foolproof” if content is heavily rewritten, translated or combined with other materials. File-based provenance information can also get lost if files are converted, resaved or captured by screenshot. 

This means that businesses should not treat watermarking as a perfect way to determine whether something was created by AI. Instead, it may be one tool to provide more information about where content came from and whether AI was involved. 

Can EU rules affect U.S. businesses? 

United States companies may also feel the effects of the EU AI Act even when a particular use of an AI product occurs outside Europe. 

For a company operating in multiple countries, creating different versions of the same product for each jurisdiction can become expensive and technically complicated. A business may instead choose and decide to build one version that satisfies the strictest applicable requirements and use that version more broadly.

For example, Anthropic has said that although its Claude watermarking changes were driven by the EU AI Act, it is applying them globally rather than limiting them to European users. 

This can create a spillover, where a law passed in one jurisdiction changes how an AI product operates for users everywhere else.  Similar regulatory concepts are also appearing in U.S. state AI laws. California and other states have adopted requirements involving transparency, disclosures, and AI governance that overlap with themes found in the EU AI Act, even though the laws differ in their scope and specific requirements.

As AI regulations continue to develop across different jurisdictions, companies may consider whether maintaining different disclosure mechanisms per jurisdiction makes sense. Alternatively, companies may comply with the most stringent regulations across all markets, setting a higher standard of compliance across the board. 

What should businesses take away?

Businesses do not necessarily need to approach every type of AI generated content in the same way. However, companies developing or using generative AI may want to review how their systems identify AI generated content, and whether their disclosure practices meet the requirements that might apply to them. Some steps businesses may want to consider include:

  • Identifying what types of AI-generated content the business uses or provides to consumers, including text, images, audio and video. 
  • Determining whether applicable laws require machine-readable markings or visible disclosures.
  • Understanding how watermarks or provenance information may change if content is edited or redistributed. 
  • Checking if AI-generated content from outside vendors keeps its watermark or disclosure when the business edits, downloads, or republishes it into another product. 
  • Considering whether maintaining different product versions across jurisdictions is practical.
  • Monitoring United States, EU, and other developing AI transparency requirements and laws. 

AI watermarking is still rapidly developing both technically and legally. Businesses do not necessarily need to treat every AI-generated output the same way, but they may need to increasingly understand when AI-generated content should be identified and whether their current systems can provide that transparency. For businesses using AI-generated content in marketing, customer communications, and other business activities, understanding when and how that content must be identified can help reduce compliance risks as these rules continue to develop 

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