Coming up in this post:

• Summary
• Introduction
• Substantive obligations of GPAI model providers
• Procedural obligations of GPAI model providers
• When are GPAI model providers within the scope of the Act? 
• Supervision and enforcement powers of the Commission
• Routes to enforcement

Introduction

On 2 August 2026, the Commission’s enforcement powers in respect of GPAI model providers will come into force. While the obligations of GPAI model providers, included in Chapter V of the AI Act, came into force on 2 August 2025, the providers are given an adjustment period of one year before the Commission may start exercising its supervision and enforcement powers against them. Providers of GPAI models released before 2 August 2025 must be compliant before 2 August 2027. 

See here for a complete implementation timeline of the EU AI Act

The Commission has exclusive powers to supervise and enforce obligations under Chapter V of the AI Act pursuant to Article 88 AI Act. These powers are complemented by Article 89(1) of the Act, under which the AI Office is also tasked with monitoring GPAI model providers’ compliance with the Act and, where relevant, their adherence to the approved codes of practice. 

Substantive obligations of GPAI model providers

The substantive obligations that the Commission will be responsible for enforcing are included chiefly in Articles 53 and 55 of the Act, namely the obligations to write and keep up-to-date the technical documentation relating to the model, to write, keep up-to-date and provide information and documentation to downstream providers of AI systems, to adopt a policy to comply with EU copyright law, and to write and publish a summary about the content used for training of the model. 

Providers of GPAI models released under a free and open-source licence are only required to comply with the copyright policy and training content summary obligations, unless the GPAI model presents a systemic risk (GPAISR). In addition, providers of GPAISR models must also perform model evaluations, conduct risk assessment and mitigation, record and report serious incidents, and ensure a sufficient level of cybersecurity of the model.

Procedural obligations of GPAI model providers

Perhaps less obviously, the AI Act also imposes several obligations on GPAI model providers that can be described as being procedural in nature. GPAI model providers are under a broad obligation to cooperate with the Commission and national authorities in the exercise of their AI Act powers (Article 53(3)). More specifically, GPAI model providers are under an obligation to respond to a Commission’s request for documentation and information and to avoid providing “incorrect, incomplete or misleading information” (Article 91(4)-(5)). GPAI model providers are also under an obligation to provide access to the GPAI model where requested to do so by the Commission (Article 92(4)-(5)).

Some of these rather procedural obligations relate only to some types of GPAI model providers. For instance, providers established in third countries are under an obligation to appoint an authorized representative in the Union prior to placing their GPAI model on the EU market, unless the model is released under a free and open-source licence (Article 54). The written mandate given by the provider to the authorized representative must meet a set of requirements listed in Article 54(3). 

Similarly, providers of GPAI models with high impact capabilities (which a GPAI model is presumed to have if the cumulative training compute of the model exceeds 10(^25) FLOP), are under an obligation to notify the Commission “without delay and in any event within two weeks after that requirement is met or it becomes known that it will be met”, with the necessary information attached (Articles 51(2) and 52(1)).

When are GPAI model providers within the scope of the Act? 

In order for a GPAI model provider to be subject to the obligations listed above and for those obligations being enforced against them, they must be within the scope of the AI Act. 

Importantly, GPAI model providers are only within the scope of the Act where they place their GPAI model on the Union market, irrespective of where they are based (Article 2(1)(a)). That includes both placing a standalone GPAI model on the Union market, as well as a situation in which the provider integrates its GPAI model into its own AI system and places that AI system on the Union market or puts it into service in the Union, as per Recital 97. 

The same logic could also potentially apply to providers of GPAI models that only place their model on the market in third countries, where it is integrated into an AI system by a downstream provider and then the AI system is placed on the EU market. This approach is especially convincing in light of Recital 97, which states that Chapter V “should apply also when these models are integrated or form part of an AI system”. While this interpretation is supported by Recital 97, it remains to be confirmed in practice.

Supervision and enforcement powers of the Commission

Supervision and non-fining enforcement powers

Moving on to the supervision and enforcement powers of the Commission, the powers that the Commission has in respect of GPAI model providers consist of the power to request documentation and information (Article 91), the power to conduct evaluations (Article 92) and the power to request measures (Article 93). 

Under Article 91, the Commission may request the documentation drawn up pursuant to Articles 53 and 55, or any other necessary information. Similarly, it may request information on behalf of the scientific panel, where necessary and proportionate.

Under Article 92, the Commission may conduct evaluations of GPAI models with a view of either determining compliance (both of GPAI and GPAISR model providers) with the Act, where the information provided by them was insufficient, or with a view of investigating systemic risks posed by GPAISR models. Independent experts, including those from the scientific panel, may conduct evaluations on behalf of the Commission, if the Commission so decides.

Lastly, under Article 93, the Commission may request providers to “take appropriate measures to comply” with their obligations. It also grants the Commission the power to request providers to put in place mitigation measures, where, following an evaluation, there is a “serious and substantiated concern of a systemic risk at Union level”. Finally, the Commission may request providers to “restrict the making available on the market, withdraw or recall the model”.

Fining powers

While Articles 91–93 of the Act confer supervision and non-fining enforcement powers on the Commission, Article 101 provides for the Commission’s power to impose fines.

Fines against whom?

Article 101 empowers the Commission to impose fines on GPAI model providers. Unlike Article 99, which provides for fines to be imposed on operators of AI systems by national MSAs, Article 101 does not expressly refer to the possibility for the imposition of a fine on the provider’s authorized representative. Instead, the wording of Article 101(1) suggests that the Commission may only impose fines on GPAI model providers.

Yet, it could be argued that Article 101 should be interpreted in light of Article 54(4) which states that the authorized representative’s mandate shall empower them “to be addressed, in addition to or instead of the provider, by the AI Office or the competent authorities, on all issues related to ensuring compliance with this Regulation”. Since the imposition of a fine could be regarded as ensuring compliance with the Act, the imposition of fines would not, on this view, be limited to GPAI model providers.

How high?

The maximum level of the fines that may be imposed on GPAI model providers is “3 % of their annual total worldwide turnover in the preceding financial year or EUR 15 000 000, whichever is higher”.

Based on what infringements? 

There are four legal bases for the imposition of a fine under Article 101(1): 

1. infringing the relevant provisions of the AI Act; 
2. not complying with a documentation/information request or supplying deficient information under Article 91; 
3. not complying with a measure requested pursuant to Article 93; and 
4. not providing the Commission with access to the GPAI or GPAISR model in order to carry out an evaluation under Article 92. 

Two of these grounds clearly match the two obligations of procedural nature imposed on GPAI model providers by virtue of Articles 91 and 92 and mentioned earlier in this text. While complying with the request for a measure is not an expressly laid down obligation under Article 93 in the same way the aforementioned obligations under Articles 91 and 92 are, it can still be mapped onto the broader obligation to cooperate with the Commission, specified under Article 53(3).

Yet, this broader obligation of cooperation is likely not limited to the obligation to comply with the Commission’s request for measures. Furthermore, some GPAI model providers are subject to other, non-cooperation related, obligations of procedural nature, such as appointing an authorized representative or notifying the Commission of their GPAI model’s high impact capabilities, as further described earlier in this text. For these reasons, it is highly plausible that the first legal basis for the imposition of a fine, namely where the GPAI model provider infringes “the relevant provisions” of the Act, is not limited to the substantive obligations included in Articles 53 and 55. Instead, it likely also extends to, where applicable, the obligations of procedural nature mentioned in Articles 52, 53(3), and 54.

Routes to enforcement

While the Commission alone is entrusted with the supervision and enforcement of GPAI model obligations under Chapter V of the AI Act, several other actors may also contribute to its enforcement.

Starting with the Commission, the AI Office is tasked with the monitoring of GPAI model providers’ compliance with the Act pursuant to Article 89(1). This includes monitoring the providers’ adherence to approved codes of practice, which constitute a voluntary tool enabling providers to demonstrate compliance with the Act. While codes of practice do not provide a presumption of conformity, the Commission has, in its Guidelines for providers of general-purpose AI models, expressed that “[f]or providers of general-purpose AI models that adhere to a code of practice that is assessed as adequate, the Commission will focus its enforcement activities on monitoring their adherence to the code of practice”. Those providers will also “benefit from increased trust from the Commission and other stakeholders”. 

Given the Commission’s admitted limited scope of the monitoring of and increased trust towards providers that have signed up to the GPAI Code of Practice, effective from 2 August 2025, other actors’ role in the enforcement of the AI Act may prove to be important. The actors that may bring attention to non-compliance and therefore contribute to the enforcement of the Act include national MSAs, downstream providers, and the scientific panel.

Market surveillance authorities

Turning to MSAs, where an MSA is unable to finalize investigation of a high-risk AI system built on a GPAI model because of lack of information pertaining to the underlying GPAI model, the AI Office shall provide that information to the MSA (Article 75(3)). Furthermore, and even more importantly, MSAs may request the Commission to exercise its powers under Articles 91–93 of the Act “where that is necessary and proportionate to assist with the fulfilment of their tasks” under the Act (Article 88(2)). 

Therefore, MSAs can be powerful actors in gaining information about, bringing attention to and requesting action in regard to non-compliance of providers of GPAI models underlying the AI systems that are within the MSAs’ regulatory remit. This mechanism could be particularly significant when combined with the right of a natural or legal person to lodge a complaint with the relevant MSA, where they have reasons to suspect an infringement of the Act (Article 85). The provision adds that “such complaints shall be taken into account for the purpose of conducting market surveillance activities”.

Importantly, Article 85 does not specify that the infringements that are subject to the complaint must relate to infringements at the AI system level. While the reference to the “relevant market surveillance authority” may suggest that the complaint should be limited to the AI systems over which the particular MSA has oversight, it could also be interpreted as referring to the MSA in the member state where the natural or legal person that lodged the complaint is based. This latter interpretation would enable a natural or a legal person to submit a complaint relating to suspected GPAI models’ infringements of the AI Act.

While this interpretation remains to be confirmed in practice, the obligation on part of MSAs to take the complaint into account for the purpose of conducting their activities, which includes their powers to request the Commission to exercise its supervision and enforcement powers under Articles 91–93, could render this combination a powerful tool for individuals to ensure the enforcement of the AI Act against GPAI model providers.

Downstream providers

It is worth mentioning that downstream providers are also granted the right to submit a complaint concerning a suspected infringement of the Act (Article 89(2)). A downstream provider is “a provider of an AI system, including a general-purpose AI system, which integrates an AI model” (Article 3(68)). 

Downstream providers are in possession of the technical documentation drawn up by the GPAI model provider pursuant to Article 53(1)(b) and they are more familiar with the functioning of the underlying model than an average individual. For these reasons, downstream providers are in a unique position to contribute to the enforcement of the AI Act against GPAI model providers if they decide to submit a complaint as a result of which the AI Office decides to exercise its enforcement powers.

The scientific panel

Lastly, the scientific panel plays an important role in ensuring the proper enforcement of the Act. It may issue a qualified alert to the AI Office in case of a suspicion of a GPAI model posing concrete identifiable risk at the EU level or where a GPAI model constitutes a GPAISR model (Article 90). Pursuant to Article 18(1) of the Commission’s implementing act on the scientific panel, the issuance of a qualified alert requires at least a simple majority of the scientific panel’s members. 

The Commission may, based on this alert, exercise its powers under Articles 91–93 AI Act. While not mentioned directly, the Commission may also exercise its fining powers under Article 101 AI Act in such cases, as Article 101 confers a free-standing power to impose a fine based on an infringement of GPAI model obligations. This reasonably includes the infringements that the Commission is alerted to by the scientific panel.

After receiving the qualified alert, the AI Office must decide on whether to exercise its powers under Articles 91–93 AI Act within two weeks, as per Article 19(2) of the implementing act. This provision for a swift procedure renders the mechanism of qualified alerts particularly useful in the AI Act’s enforcement schema.

GDPR required you to rethink how you handle personal data. The EU AI Act requires you to rethink how you use the tools that process it.

Under the EU AI Act (Regulation 2024/1689), AI systems used in employment decisions fall into the high-risk category. That covers recruitment, selection, targeted job advertising, candidate evaluation, performance monitoring, and certain decisions about compliance, contract terms or termination. Starting 2 August 2026, each of those tools will need mandatory risk assessments, technical documentation, bias testing, human oversight, transparency disclosures, and continuous monitoring. 

For staffing businesses, Employers of Record (EORs), and workforce platforms, which sit between employers, technology, and workers, the obligations are more demanding than they are for a single corporate HR department. And it does not matter whether you built the technology. If your business deploys it, compliance is your responsibility, even if the platform vendor says otherwise.

Why the staffing supply chain makes this harder

Most commentary on the AI Act’s employment provisions is written for in-house HR teams at single employers. That misses the reality for staffing businesses.

Think about the typical staffing supply chain. A Vendor Management System (VMS) platform uses algorithmic matching to surface candidates. A Recruitment Process Outsourcing (RPO) provider runs AI-powered screening across thousands of applicants. A staffing agency deploys chatbot pre-qualification. An EOR uses AI to manage onboarding, compliance, termination and performance across multiple jurisdictions. At every stage, AI systems are making or influencing decisions about people’s livelihoods, and the Act’s obligations for deployers do not distinguish between entities in the chain based on who owns the technology.

Under Article 3 of the Act, a “deployer” is any natural or legal person using an AI system under its authority. If your staffing firm selects, configures, or relies on an AI tool to inform workforce decisions, you are a deployer, even if you did not build the technology and even if the platform vendor tells you compliance is their responsibility. The Act assigns obligations to both providers (the vendors who build the systems) and deployers (the businesses that use them). You cannot pass your compliance obligations to a technology partner any more than you can under the GDPR.

Extraterritorial reach

The Act has extraterritorial reach. If the output of your AI system is used in the EU or it affects persons located in the Union (a candidate screened for a role in Berlin, a contractor evaluated in Dublin, a temp worker matched to an assignment in Amsterdam), the regulation applies regardless of where your company is headquartered or where the technology is hosted.

Human oversight is not optional

Every high-risk AI system must be used in a way that allows effective human oversight. No AI tool should make final placement, rejection, or evaluation decisions without a qualified human in the loop. Your recruiters and account managers need to understand how the system works, what its limitations are, and when to override its outputs. Article 14 requires the people exercising oversight to detect and correct errors, including discriminatory patterns. A policy document alone does not satisfy this.

Candidates and workers must be told

Before deploying a high-risk AI system, Article 26(7) requires you to inform workers’ representatives and affected workers. In staffing, this extends to candidates and contingent workers. They have a right to know that AI is being used, how it functions, and what role it plays in decisions that affect them. Under Article 86, individuals subject to decisions made by high-risk AI systems can request an explanation of the main factors behind those decisions. For high-volume recruitment, your disclosure process needs to be operational and visible, not buried in a terms-of-service document.

Data quality and bias monitoring need real attention

If you exercise control over input data fed into high-risk AI systems, you must ensure that data is relevant and representative. Staffing agencies, where candidate pools are often skewed by geography, language, or existing network effects, face a particularly substantive version of this obligation. You need to know what data your AI tools are trained on, how they handle protected characteristics, and whether they produce equitable outcomes across demographics.

Logs and documentation are an infrastructure requirement

Deployers must keep logs generated by high-risk AI systems for at least six months. Combined with the requirement to monitor system performance on an ongoing basis, this creates an operational infrastructure need that many staffing businesses have not yet scoped.

The timeline

See the full implementation timeline for the EU AI Act

The Act entered into force on 1 August 2024. Certain provisions already apply. Since February 2025, some AI practices have been prohibited, including biometric categorization and emotion recognition in the workplace (with some excluded use cases). Also, AI literacy obligations became effective.

The main date for staffing businesses is 2 August 2026, when the full suite of high-risk system obligations becomes enforceable for Annex III systems, including all employment-related AI.

Some industry commentary has suggested that the European Commission’s Digital Omnibus package, proposed in November 2025, will push this deadline back. But this is a proposal, not enacted law. It must pass through Parliament and Council.

The penalty framework

The Act’s enforcement structure follows a tiered model. For deployers who fail to meet their high-risk system obligations, fines can reach up to EUR 15 million or 3% of global annual turnover, whichever is higher. For use of prohibited AI practices, the ceiling rises to EUR 35 million or 7% of turnover. For providing incorrect or misleading information to regulators, up to EUR 7.5 million or 1%.

National market surveillance authorities, not a single EU-wide regulator, handle enforcement in regard to AI systems. In January 2026, Finland became the first member state to confer enforcement powers on its market surveillance authority pursuant to Article 99 AI Act, rendering these powers fully operational. Other member states are following. This decentralised model means enforcement priorities and interpretive approaches may differ across member states. For multi-country staffing operations, that variation creates planning challenges and, for those who engage early with national regulators, potential advantages.

The fine itself, though, is often the wrong thing to focus on. Regulators also have the power to withdraw or recall non-compliant AI systems from the market. For a staffing business whose operating model depends on technology-enabled matching and screening, that is the more commercially significant risk: a core tool pulled mid-contract, with immediate operational disruption.

Some of your tools might be exempt. Most of them probably aren’t.

There is a provision in the Act—Article 6(3)—that gets very little attention in industry commentary, and staffing operators should know about it. It sets out four conditions under which an AI system used in an employment context might fall outside the high-risk classification, even though it operates in a high-risk area.

The system performs a narrow procedural task, such as sorting incoming documents into categories or flagging duplicates in a batch of applications. Or it improves the result of a previously completed human activity, like cleaning up language in a drafted contract. Or it detects patterns in prior human decisions, such as flagging inconsistencies in a manager’s past performance ratings. Or it performs a purely preparatory task: indexing, searching, or translating source material before a human makes a decision.

However, Article 6(3), read together with Recital 53, explicitly states that none of those exemptions apply if the AI system involves profiling within the meaning of Article 4(4) GDPR. Profiling means any automated processing of personal data that evaluates personal aspects of an individual, including analysing or predicting work performance, reliability, behaviour, or location.

Most candidate matching tools, ranking algorithms, and workforce allocation systems do exactly that. They take personal data, apply automated logic, and produce predictions about suitability or fit. That is profiling, and it renders the exemption unavailable in these cases.

The practical implication: when you run your AI inventory and start classifying systems, you may look at the Article 6(3) exemptions and assume several of your tools are outside scope. For the tools that handle procedural or preparatory tasks, that may be correct. For anything that matches, ranks, evaluates, or allocates workers based on personal characteristics, it almost certainly is not.

This is a competitive question, not just a compliance one

The most useful way to think about the EU AI Act is as a market-shaping event that will separate operationally mature staffing businesses from those running on unexamined technology.

Enterprise clients with EU operations, particularly in regulated industries, are already building AI governance into their vendor selection criteria. Staffing businesses that can demonstrate compliant AI practices, transparent candidate processes, and documented oversight frameworks will have a measurable advantage in RFPs and preferred supplier negotiations. 

There is a broader pattern here too. The EU AI Act is the first major AI regulation of its kind, but it will not be the last. Similar frameworks are taking shape in the UK, Canada,  South Korea, Brazil, Taiwan, and at state level in the US. Investing in AI governance infrastructure now builds capacity that transfers across jurisdictions. The businesses treating compliance as a one-off project are solving for today. The ones building governance into their operating model are solving for the next decade.

What to do now to prepare your business

1. Map every AI system your business uses that touches candidate or worker decisions: screening, matching, ranking, chatbots, performance analytics, scheduling algorithms. Include tools embedded in third-party platforms you deploy. You cannot comply with obligations you do not know you have.

2. For each tool, determine whether you are the deployer, whether the system falls within Annex III’s employment category, and who the provider is. Document this in a way your compliance and operations teams can work from.

3. Contact every AI vendor in your stack and ask specific questions: Are they aware of the EU AI Act? Are they pursuing conformity assessment? Can they provide technical documentation, bias audit results, and usage logs? Will they contractually commit to supporting your deployer obligations?

4. Identify who in your organisation will oversee each high-risk AI system. Make sure those people have the training and authority to understand, monitor, and override AI outputs. Document the process. AI literacy obligations are already in effect, so this is a current requirement.

5. Draft the notifications, disclosures, and explanation frameworks you will need to inform candidates and workers about AI use. In a labour market where candidate experience drives placement volume, being clear and upfront about how you use technology is a differentiator, not a burden.

The staffing businesses that will handle this transition best are the ones that start now, move methodically, and treat AI governance as an operating capability rather than a legal exercise. The EU AI Act is the clearest signal yet that the era of unexamined AI deployment in workforce decisions is ending. For operators willing to get ahead of it, the reward is not just compliance but the trust of clients and candidates who increasingly expect it.

This guest post was contributed by Nazareth & Partners. Contact us if you’re interested in submitting a guest post.

Nazareth & Partners advises staffing agencies, EORs, MSPs, RPOs, and VMS platforms on cross-border compliance, including AI governance and EU regulatory readiness. This article is for informational purposes and does not constitute legal advice.

Disclaimer: Please note that the information provided and discussed in the article does not and is not intended to constitute legal advice. Please obtain professional legal counsel where necessary. The content of the EU AI Act may be interpreted differently than stated.

Coming up in this post:

• Summary
• Introduction
• The issues with modifications under the EU AI Act
  • Common issues with modifications of AI models and systems
• What modifications can qualify you as a provider?
  • Substantial modifications of AI systems
  • Substantial modifications of GPAI models
  • What does this mean in practice?
• GenAI in action: practitioner’s examples and open challenges
  • Case 1: Enterprise IT service provider
  • Case 2: Agentic AI platform of scale-up
• Going forward
  • General recommendations for organisations
  • Recommended actions and resources for EU AI Act preparation
• About the authors

Introduction

The EU AI Act primarily regulates providers of general purpose AI (GPAI) models and AI systems, establishing a comprehensive framework for the development and deployment of AI within the European Union. While the EU AI Act clearly identifies the developer of a completely new AI system or GPAI model as a provider, it becomes more complex when someone further down in the value chain modifies an existing third-party AI system or GPAI model. This raises questions about compliance responsibilities, specifically who should and can fulfil the provider obligations under the EU AI Act.

The EU AI Act acknowledges the modification scenarios by defining circumstances under which a modifier of an AI system or GPAI model becomes a provider — effectively transferring regulatory obligations from the original provider to the modifier, either partly or fully.

This shift in compliance responsibilities, especially when looking at high-risk AI systems or GPAI models, is a scenario that businesses typically seek to avoid due to the additional compliance cost and burden. Misclassifying the role, risk category, or the AI model under the EU AI Act poses a significant compliance risk for businesses, as it can lead to fines of up to €15 million or 3% of global annual revenue for non-compliance with the provisions on high-risk AI systems or GPAI models.

With the GPAI model provider obligations taking effect since 2 August 2025, discussions about AI model and system modifications and the resulting compliance implications have become increasingly urgent and relevant for businesses.

In this article, we — a working group of AI Pact members and AI Act early adopters — discuss the classification resulting from modifications under the EU AI Act and discuss compliance challenges from a practitioner’s perspective. We are specifically focussing on GPAI models and applications.

The issues with modifications under the EU AI Act

Due to the EU AI Act’s broad definitions, it can be hard for businesses to figure out when a modification results in provider obligations for the model used. The decisive definition of a “substantial modification” (see Article 3(23)) remains vaguely described in the EU AI Act. This creates uncertainty for organisations.

The challenge of a correct classification is especially relevant when considering scenarios in which businesses build systems or applications upon GPAI models, such as OpenAI’s GPT-4.5 or Anthropic’s Sonnet 4. These models are deliberately designed to be adaptable across a broad set of use cases and to be customised by downstream operators in the value chain. In these scenarios, answering the question of who needs to fulfil what obligations can be difficult.

There are (on-going) initiatives by the European Commission that aim to clarify concepts in the AI Act. With regards to high-risk AI systems, the development of CEN/CENELEC standards is ongoing with expected publication earliest in 2026. These should provide concrete guidance on how to obtain presumption of conformity with the EU AI Act’s provisions on high-risk AI systems but do not focus on GPAI models. With regards to GPAI models, the GPAI Code of Practice from the European Commission’s AI Office is focused on fulfilling the GPAI model provider obligations as well as GPAI models with systemic risk. The Code of Practice has been recently complemented with official Guidelines for GPAI providers (GPAI guidelines). While these are good first steps, uncertainties remain about when a modifier becomes a provider in practice. 

The GPAI guidelines introduce a threshold of one-third of the initial computing power required to train the original GPAI model (measured in FLOPs) as a distinction between substantial and insubstantial modifications. This threshold aims to clarify when compliance obligations shift to the modifier. However, this computing-based threshold, while potentially useful for certain modifications like fine-tuning, may remain insufficient for other types of modifications that substantially change model behaviour and risks without requiring extensive computational resources. The guidelines state that this threshold is merely an indicative criterion. In accordance with the GPAI guidelines paragraph 62, the overarching rule for determining when a modification is substantial comes down to whether the modifications potentially result in substantially modified generality, capabilities or systemic risk of the model.

Given these circumstances, organisations face challenges in implementing the appropriate measures to comply with the EU AI Act as well as in determining whether their use cases and modifications qualify them to become a (GPAI model) provider in the first place.

What modifications can qualify you as a provider?

Prior to the considerations of whether there is a modification that can qualify someone as a provider, it is advised to conduct an assessment of whether the system or model at hand actually lies within the scope of the EU AI Act’s definitions of an AI system or GPAI model. This may seem trivial, but when classifying the operating role, it has proved to be difficult at times.

There are various ways to become a provider under the EU AI Act, both at the AI system and AI model level. In particular, the EU AI Act outlines several scenarios where a business modifying or deploying an AI system can potentially inherit the role and responsibilities of a provider:

• Integration of an existing AI model into a new or existing AI system (see Article 3(68))
• Rebranding a high-risk AI system as one’s own product (see Article 25)
• Repurposing an AI system or model so that it becomes high-risk (see Article 25)
• (Substantial) modifications to an existing high-risk AI system or a GPAI model (see Article 25 and Recital 109)

The first case refers to the EU AI Act’s definition of a “downstream provider” (see Article 3(68)), which likely describes the current circumstances of many organisations best. For instance, bringing your own model (“BYOM”) into an AI system may qualify as an integration. However, being a downstream provider does not necessarily trigger a shift in the compliance responsibilities for GPAI model providers, as it rather describes the role of an AI system provider. In this situation, an organisation would need to validate if the high-risk AI system or transparency obligations apply, and if the upstream provider of the GPAI model has clearly excluded the distribution and use of the model within the EU.

While the second and third case — rebranding and repurposing — are generally quite straightforward thresholds for a shift in compliance responsibility, the cases involving substantial modifications are more ambiguous and pose significant interpretive challenges for organisations, as described above.

Substantial modifications of AI systems

According to the AI Act, a substantial modification refers to a change of an AI system which has not been foreseen by the original provider’s conformity assessment, and which affects the compliance with requirements on high-risk AI systems or which affects the intended purpose of the AI system (see Article 3(23) and Recital 128). Note that an official conformity assessment for a high-risk AI system can only be conducted when there are notified bodies that perform an external audit or when the harmonised standards (by CEN/CENELEC) can be applied. At the time of writing, this is therefore not helpful guidance yet.

The AI Act further addresses modifications explicitly in Article 25, where it states that substantial changes to a high-risk AI system shifts the role of a provider to the modifier — but only if the system remains high-risk. This links the concept of substantial modifications to the impact of the modification on the risk level.

Substantial modifications of GPAI models

When it comes to modifications of GPAI models, however, the EU AI Act becomes less defined. Recital 109 and the FAQ by the European Commission clarify that provider obligations for GPAI models are limited to the scope of the modification, but the EU AI Act does not directly link GPAI model modifications to specific risk levels (only to systemic or non-systemic risk). Further, the EU AI Act does not explicitly speak of substantial modifications in the context of GPAI models — but it does explicitly highlight fine-tuning of GPAI models as modification, suggesting that the modification also needs to have a rather substantial effect on the model. The AI Office confirms the latter in the GPAI guidelines, as it states that, in their view, modifications usually involve training a model on additional data. The guidelines also extensively focus on fine-tuning and retraining a GPAI model.

To further support this distinction, the GPAI guidelines introduce a compute-based threshold: if a modification uses at least one-third of the computational resources originally required to train the model, the modifier is presumed to have become a GPAI model provider. While this threshold adds some clarity, its limitations were highlighted during the public consultation of the guidelines and acknowledged by the AI Office. The threshold may not capture low-compute modifications that still substantially affect a model’s risk profile, and it may be difficult for modifiers to reliably estimate the required compute — especially without access to information from upstream providers. The European Commission chose to set relatively high thresholds, and currently expects only few modifiers to become GPAI model providers.

Again, the threshold is an indicative criterion, and other model modifications could also qualify as substantial modifications. Whether the risk-focussed logic of Article 25 (the article regulating changes in high-risk AI system cases) is also applicable to the modifications of GPAI models, as suggested by some, remains an open question.

A modification to an AI model can take many forms. As outlined by Philipp Hacker and Matthias Holweg (2025), the most relevant types of modifications to an AI model can be grouped into the following categories:

• No change: Using a pretrained AI model without any modifications.
• Modifying hyperparameters: Adjusting parameters like temperature.
• Retrieval-Augmented Generation (RAG): Building applications that enhance a model’s outputs by referencing an external knowledge base or proprietary data.
• Custom GPTs: Creating variants of base models with specified instructions, tools, and personalities.
• Fine-tuning: Training the base model on proprietary or domain-specific datasets to tailor its performance.

Model or knowledge distillation: Training a smaller “student” model based on the outputs of a larger “teacher” model, often to reduce computational requirements.

As Hacker and Holweg (2025) argue, substantial modifications, i.e. substantially changed risk profiles or model behaviour, exist in cases of fine-tuning, model distillation, jailbreaking via parameter manipulation, or changing the core architecture of a model. Other modifications, especially when not changing the risk profile, architecture, generality or intended purpose of an AI model, are likely insubstantial, meaning not triggering a change in GPAI model provider obligations.

What does this mean in practice?

Following the broader logic of the EU AI Act, it is useful to anchor the assessment of whether there is a change in compliance responsibilities, both regarding AI systems and GPAI models, in an assessment of whether the modification is substantial or insubstantial — which in turn requires looking at the modification’s effect on risks.

For AI systems, the exercise is relatively clear: businesses modifying AI systems should review whether changes affect the system’s risk classification, e.g. clarifying if it becomes high-risk or remains high-risk.

For GPAI models, the exercise is a bit more complex. Until further guidance is available and standards are in place, businesses modifying GPAI models can consider two approaches:

1. A more conservative approach, treating any adaptation as a potential trigger for a shift in the GPAI model provider obligations by default. This essentially includes maintaining documentation and summaries of the performed modifications, even though these may not be mandatory.
2. A more pragmatic approach, under which GPAI model provider obligations are assumed to apply only if the modification clearly alters the model’s behaviour, generality, or risk profile, or if the compute thresholds are met. This approach limits governance burdens, but may require stronger justifications if challenged.

In any way, businesses should conduct risk and impact assessments when making any changes to GPAI models or (high-risk) AI systems.

GenAI in action: practitioner’s examples and open challenges

To give an idea of current challenges for practitioners when it comes to the right categorisation, we gathered a few (partly anonymised) real example cases. We also highlight further compliance challenges under the AI Act that are related to GenAI cases, which are yet to be solved, as well as other best practices.

Case 1: Enterprise IT service provider

An enterprise IT service provider makes use of the GPT-4 model by OpenAI to provide and sell a platform that orchestrates different chatbots in one centralised solution. End users can then both chat with the bots to access general knowledge, but also their company’s internal knowledge, within a secure environment. This is a very common “Custom GPT” case, in which the service provider limits their modifications to changes in prompts and adding RAG techniques, while distributing the system under a new name.

The following considerations were particularly relevant to the IT service provider in assessing compliance:

1. First, it was unclear whether building custom bots around the GPT-4 model and providing services under their own brand name qualifies them as a GPAI model provider.
2. Second, there was confusion about whether the August 2, 2025 GPAI deadline applies to their business of selling GPT-based solutions without substantially modifying the core model.
3. Third, they struggle with ensuring that OpenAI delivers the required documentation.

While the IT service provider does qualify as a downstream provider, due to the integration of OpenAI’s model, they neither qualified themselves as a provider of a high-risk AI system (excluded in usage policy and limited through technical means) nor as GPAI model provider due to the very limited scope of modification which does not significantly change the model’s risk. In this case, and at least for compliance purposes, they don’t need to rely on OpenAI’s documentation and they do not face additional obligations under the GPAI model provisions. The IT service provider consulted with the compliance company of one of the authors, Trail, and decided to follow a conservative approach, meaning to keep sufficient technical documentation around the architecture and functionality of the GPAI system, which should be available for development purposes anyway.

Case 2: Agentic AI platform of scale-up

A Swiss scale-up, Unique AI, offers a platform to build agentic AI solutions that help banks, insurance companies and private equity firms to improve their financial operations. These include workflows, such as investment research, due diligence, and KYC processes. The main challenge here was to ensure compliance and proper security of AI agents that are capable of performing actions independently. However, the role under the EU AI Act was unclear at the beginning.

Unique AI conducted in-depth research on the EU AI Act, both internally and with support from a law firm, WalderWyss, where they obtained a legal opinion on the positioning of Unique AI regarding the EU AI Act. Based on the client setup and deployment model, Unique AI can have various roles under the EU AI Act.

Most of the clients chose a single tenant deployment model where Unique AI hosts and runs the software. Based on the legal interpretation of the EU AI Act, Unique’s operational approach positions them as a distributor rather than a provider while making the AI systems and models available. This is because Unique AI leverages existing commercial AI products like Microsoft Azure and OpenAI models, and enriches them with context-specific functionalities through prompt chaining, RAG, and prompt-to-SQL techniques, without altering the original Large Language Model (LLM). Unique AI does not use client data for model training purposes, and excludes the use for high-risk purposes, which further supports this classification. Therefore, the company is not considering themselves as a modifier of the GPAI model and the GPAI model provider obligations remain on upstream providers’ side.

They have adopted an AI Governance Framework, which serves as the foundation for their agentic AI development, embedding trust, safety, accountability, reliability, and transparency into the core architecture of every intelligent agent and workflow, while regular internal benchmarking prevents model drift and maintains consistent quality across all use cases.

To proactively work towards AI Act compliance, Unique AI conducted an internal conformity assessment following David Rosenthal’s methodology in June 2024, led by the company’s Chief Information Security Officer and Chief Data Officer.

As the regulatory landscape continues to evolve, the company maintains a forward-looking approach through continuous updates to their public AI Governance Framework, active participation in regulatory consultations, and open and transparent collaboration with industry peers through initiatives like annually hosted AI Governance Roundtables.

Going forward

As the EU AI Act moves further into its implementation stage, there remain open questions and compliance challenges, specifically for businesses integrating and modifying AI models and systems.

In any case, the overall obligations for GPAI model providers are manageable, as they are essentially limited to keeping technical documentation and summaries within the scope of the modifications. Of course, GPAI model providers with systemic risk face more complex compliance requirements. The AI Office assumes that, as of today, only few downstream modifications would meet the respective compute-thresholds which would trigger a shift in compliance responsibilities. Proper guidance is under way, and there are sufficient hints and proxies available that allow both integrators and modifiers to work towards EU AI Act compliance in the meantime.

The AI Office has also indicated in the GPAI guidelines that GPAI model providers, including those performing modifications, who are anticipating compliance difficulties with respect to the August 2025 deadline should proactively get in touch with the AI Office through its recently launched AI Act service desk. The AI Act service desks established by individual EU Member States, such as the ones from Germany and Austria, can be another option to proactively reach out to authorities in complex cases.

Further, many big GPAI model providers have committed to the GPAI Code of Practice, including OpenAI, Anthropic, Google and Mistral, signalling that there is also an intent to support downstream operators with appropriate documentation on AI models. This can help to mitigate the lack of vendor transparency, as highlighted above, in the upcoming months.

General recommendations for organisations

If you are concerned about modifications of GPAI models and systems under the EU AI Act, review the official GPAI guidelines of the AI Office and start assessing the use cases along the interpretations of the AI Office. The guidelines include further examples of when an organisation is to be considered a GPAI model provider.

Organisations that have now started to think about their EU AI Act compliance in more detail should use their momentum and proactively get going with AI governance initiatives, respecting that AI governance is much broader than regulatory compliance.Voluntary programmes like the European Commission’s AI Pact offer opportunities for peer exchange around the EU AI Act and can help to gain internal buy-in and create awareness for AI governance. The contributors of this article, for instance, proactively created a small, informal community of AI Pact members (“AIPEX”) earlier this year to discuss current challenges and solutions to these in direct meetings, and members of the AI Office took the time to join one of their meetings.

About the authors

From the informal AI Pact Exchange Group (“AIPEX”):

• Øystein Endal, AI risk and compliance manager within the financial services and insurance sector.
• Andrea Vrcic, legal counsel in AI regulation within the financial services and insurance sector.
• Sidsel Nag, manager of AI ethics, regulation, and governance within the consulting sector, and member of the Danish Standardisation Committee.
• Nick Malter, AI policy and governance manager at trail GmbH, an AI governance software company. Initiator of the AIPEX group.

From Unique AI:

Daylan Araz is Data Compliance Officer at Unique AI in Zurich. He was instrumental in developing Unique’s comprehensive AI Governance Framework. He has taken a lead role in achieving the ISO 42001 certification as well as contributing to ISO 27001, ISO 9001, and SOC 2 certifications. Reach out for more information: aigovernance@unique.ai.

This resource was put together by Santeri Koivula, an EU Fellow at the Future of Life Institute, and Karl Koch, founder of the AI Whistleblower Initiative. 

Coming up in this post:

• Introduction
• The connection between the EU AI Act and the Whistleblowing Directive
• How the EU Whistleblowing Directive works
  • Protection against retaliation
  • Who is protected? (personal scope)
  • What can be reported? (material scope)
  • Reporting channels and procedures
• Practical recommendations for whistleblowers
  • Documenting evidence
  • Secure communication
  • Before you report
• Support infrastructure
  • International
  • Belgium
  • France
  • Germany
  • Ireland

Introduction

Whistleblowing plays an important role in identifying violations of law in companies that would otherwise remain hidden. This is especially true in the case of artificial intelligence, where the rapid development of technology makes regulation difficult to keep up. Consequently, policymakers often operate with limited information. Whistleblowing can help fill this information gap, as insiders in companies are uniquely positioned to detect issues that are not readily observable externally. In a recent study, whistleblower protections were listed as one of the most effective interventions for mitigating AI risks. The effectiveness of whistleblowing has been documented in other industries. In the United States, the Securities and Exchange Commission’s Whistleblower Program has enabled the recovery of over US$6.3 billion in monetary sanctions since its launch in 2010.

To protect whistleblowers from adverse consequences connected to their speaking up, in 2019 the European Union adopted the Whistleblowing Directive, which mandates Member States to implement strong laws prohibiting retaliation against whistleblowers. It requires companies to establish internal reporting channels and Member States to set up external reporting channels through designated public authorities. The Directive also allows whistleblowers in certain cases to report directly to the media or the public. This option, though, has been transposed differently in each Member State, often with restrictions that make it an option of last resort.

This post provides an overview of the Whistleblowing Directive and how its provisions relate to the EU AI Act. It also offers practical advice to potential whistleblowers, such as appropriate reporting channels.

The connection between the EU AI Act and the Whistleblowing Directive

From 2nd August 2026 onward, the EU Whistleblowing Directive will explicitly cover reporting violations of the EU AI Act. This means that if you’re in any professional relationship with a company covered by the EU AI Act, and your relationship is governed by EU law, you are protected when reporting violations. For instance, an employee at a general-purpose AI (GPAI) provider could safely report that a GPAI model with systemic risk has inadequate cybersecurity protection, violating Article 55 of the Act. 

However, as the Whistleblowing Directive does not currently cover violations specific to the AI Act, there remains uncertainty regarding the exact scope of reportable AI-related issues today. Further, there are some issues that will remain unclear after violations of the AI Act are covered. Namely, it is unclear whether risks arising solely from internal deployment would qualify for protection.

Nevertheless, even before 2nd August 2026, whistleblowers may already benefit from protections if reporting AI-related concerns under other categories like product safety, consumer protection, or data protection that are already within the Directive’s scope.

How the EU Whistleblowing Directive works

The EU Whistleblowing Directive was adopted to establish comprehensive whistleblower protections across the EU Member States. Initially approved in 2019, it requires all Member States to transpose its provisions into national law by December 2021. As of July 2025, all Member States have adopted the law on paper. However, the European Commission has not yet reviewed and confirmed that these national laws fully comply with the Directive’s standards. Until this confirmation, legal uncertainty remains regarding the extent to which the Directive’s protections are enforceable in some Member States.

Indeed, implementation issues remain. A 2024 report by the European Commission states that the transposition in several Member States needs to be improved in areas such as the material scope and the measures of protection against retaliation. Given this legal uncertainty, those considering a report may benefit from seeking guidance, as the provisions of the Directive are not satisfied in each Member State. Several organisations listed at the end of this post offer support and legal advice.

The Whistleblowing Directive establishes clear reporting channels and protections for reporting misconduct. It applies to a wide range of areas such as public procurement, financial services, environmental protection, and from August 2026, violations related to the EU AI Act, although there may be a lag in implementation in different Member States. The Directive protects whistleblowers across various types of professional relationships, including employees, part-time workers, contractors, and suppliers.

The Directive rests on a straightforward principle: protection from retaliation is afforded to Covered Persons who report on violations of the EU law through appropriate channels. Below, we expand on these protections in detail.

Protection against retaliation

The Directive prohibits any action triggered by a report that causes unjustified detriment to the whistleblower. This includes dismissal, suspension, demotion, withholding of promotion, transfer of duties, change of workplace location, reduction in wages, disciplinary measures, coercion, intimidation, harassment, discrimination, and damage to reputation.

Crucially, the burden of proof shifts to the employer to demonstrate that any adverse action was not related to the whistleblowing. If retaliation is found, remedies include reinstatement and full back pay, with some countries offering additional damages.

Who is protected? (personal scope)

Protection applies to anyone who gained information in a professional context. This includes at least the following:

• Employees in both public and private sectors,
• Self-employed persons,
• Shareholders and persons belonging to administrative or management bodies,
• Volunteers and trainees,
• Job applicants,
• Subcontractors and suppliers, and;
• Individuals who report breaches after their work relationship has ended.

Protection also extends to facilitators who assist the whistleblower in the reporting process, and third persons connected with the whistleblower such as colleagues and relatives who might face retaliation. However, only natural persons qualify as facilitators, meaning support organisations themselves are not covered.

The professional relationship must be governed by EU law. This means that if you are based in the EU but under a non-EU contract, you are still covered when reporting EU law violations. Similarly, if you are based outside the EU but under an EU employment contract, you are also covered. Citizenship is not relevant to protection status.

What can be reported? (material scope)

From August 2026, any suspected violation of the EU AI Act will be covered under the Whistleblowing Directive. Currently, the Directive covers violations in areas such as public procurement, financial services, prevention of money laundering and terrorist financing, product safety, transport safety, environmental protection, nuclear safety, food and feed safety, public health, consumer protection, privacy and data protection, and security of network and information systems. Consequently, some activities related to AI may already fall within its scope, particularly concerning product safety, consumer protection, privacy and personal data, and information security.

Importantly, whistleblower protections do not depend on whether the resulting investigation confirms an actual violation of a law. Rather, whistleblowers are protected if they had reasonable cause to believe the information was true at the time of reporting and constituted a violation covered under the Directive. The “spirit of the law” is also covered, meaning attempts to circumvent the letter of the law are also reportable violations.

Certain exceptions apply to what can be reported under the Directive. National security matters are excluded, particularly reports of breaches involving defense or security procurement covered by Article 346 TFEU, which is subject to strict interpretation under EU case law. Trade secrets may be disclosed only if necessary to expose a violation and if doing so serves the public interest. Additionally, the Directive does not override confidentiality protections, such as confidential communications between a lawyer and their client. 

Reporting channels and procedures

Under the Whistleblowing Directive, individuals can choose freely between internal reporting channels within their organisation, external reporting channels managed by public authorities, or both in parallel. There is no requirement to wait for an internal process to conclude before turning to external reporting. Under certain circumstances, whistleblowers may also directly disclose their information publicly.

Internal reporting channels are established directly by companies and are mandatory for organisations with 50 or more employees. These channels must designate impartial persons or departments to handle reports, acknowledge reports within seven days, provide diligent follow-up, and give feedback to the whistleblower within three months. The confidentiality of both the reporter and the reported person must be maintained.

External reporting is directed to competent authorities designated by Member States. These authorities must diligently follow up on reports and maintain confidentiality, though not all allow for anonymous reporting. Authorities must respond within three months, and failure to do so can enable the whistleblower to go public with the information. In some extraordinary cases, the time frame may be six months due the nature and complexity of the subject of the report.

Public disclosure refers to sharing information outside of the official internal or external reporting channels, for example by directly informing the media or making information publicly available. Whistleblowers who disclose information publicly are protected under the Whistleblowing Directive only under specific conditions. Protection applies if the whistleblower has already reported internally or externally, but the violation remains unaddressed, meaning internal channels or authorities have not responded appropriately within three months, have inadequately investigated, or have failed to take sufficient action. Whistleblowers may also disclose publicly without prior internal or external reporting if they reasonably believe there is imminent danger to the public interest, such as a risk of irreversible damage or physical harm, or if there are reasonable grounds to suspect retaliation when reporting externally, or collusion between authorities and those responsible for the violation. Under these circumstances, those who choose to disclose information to the public will in principle retain full legal protections under the Directive. However, going public with the information is often seen as a last resort, and this option has been implemented differently in each Member State.

For AI Act violations specifically, enforcement responsibilities are divided between EU-level bodies and national authorities. As Member States are yet to integrate the EU AI Act into their implementations of the Whistleblower Directive, we do not yet have certainty on how exactly reporting channels surrounding suspected AI Act violations will be structured. While direct reporting to EU authorities is likely possible, the strongest protections will likely come from reporting through national authorities who can then refer cases to European bodies as needed. In the future, this direct channel to EU authorities may be strengthened; a statement by the Chairs and Vice-Chairs of the EU Code of Practice recommends that a dedicated reporting channel for the EU AI Office is established.

Practical recommendations for whistleblowers

When considering reporting, proper preparation can help protect both you and the integrity of your disclosure. Below, we outline several considerations (for more, you can refer to e.g. “A Tech Workers Guide To Whistleblowing, Ireland Edition” by The Signals Network):

Documenting evidence

When gathering evidence of potential violations, consider your digital safety:

• Your employer may monitor work emails and devices. Use personal devices and communication channels when researching your options.
• If you need to preserve evidence from work systems, taking photos with a personal device (with Wi-Fi turned off) is generally safer than screenshots on work equipment, which might be detected.
• Be careful not to remove or delete files inappropriately, as this could potentially undermine your protection or expose you to other legal issues.

Secure communication

• Use encrypted communication tools like Signal or ProtonMail (with a non-work email address and phone number) when discussing your concerns with legal advisors or support organisations.
• Plan for the possibility that your access to work systems could be abruptly terminated if your reporting becomes known to your employer.
• Use secure intake forms if provided by whistleblower support organisations.

Before you report

• Create a clear chronological timeline of events, and document dates of the suspected wrongdoing and any attempts you’ve made to address the issue internally.
• Focus on factual information rather than opinions or interpretations. Be specific about what rules or regulations you believe are being violated.
• Seek legal advice early, before making any disclosure. This helps ensure your actions remain protected under whistleblower laws.
• Recognise the personal toll that coming forward can exact on you and your family. Many support organisations offer additional services, including psychosocial and career support to help.
• Consider carefully which reporting channel is most appropriate for your specific situation.

Support infrastructure

Whistleblowers can greatly benefit from knowing where to report concerns and where to seek assistance. Below we highlight key institutions and organisations across some EU Member States, as well as international efforts.

International

• The AI Whistleblower Initiative (AIWI) helps connect AI insiders to specialised support organisations and offers specialised support for insiders at frontier AI companies by supplementing existing whistleblower support organisations with AI expertise.
  They also offer “Third Opinion” – a “pre-whistleblowing” service allowing insiders to anonymously submit questions around their concern, without disclosing confidential information. AIWI then custom-assembles expert panels together with the insider to clarify if there might be a cause for concern through an anonymous Q&A. 
• Psst provides a secure digital “Safe” where individuals can privately share concerning non-public information and seek legal, media, or other support. Users can deposit encrypted information, request pro bono legal advice, or choose to be contacted only if similar concerns emerge from others. Psst serves as a lower-stakes alternative to formal whistleblowing. It engages individuals earlier in the process, before they make mistakes that cannot be undone, helping evaluate information and guide next steps while allowing them to remain anonymous if preferred.
• Whistleblowing International Network connects multiple civil society organisations that protect whistleblowers. They offer a range of resources on whistleblowing law and practice, along with other services.
• SUSA (Speak-Up Self-Assessment) is a tool to help employees to understand whether the whistleblowing policy in their company complies with the EU Whistleblowing Directive.

Belgium

• The Federal Ombudsman serves as an authority for receiving whistleblower reports. They guarantee strict confidentiality and never disclose the whistleblower’s identity.  Reports can be submitted through their online reporting form, by email, or by scheduling an appointment with their Centre for Integrity. 
• Whistleblowers are entitled to comprehensive support from the Federal Institute for Human Rights (FIRM/IFDH), an independent public institution that provides psychological, social, technical and media support, legal assistance in proceedings, and financial assistance for legal costs.

France

• The Défenseur des droits (The Defender of Rights) is an independent authority that provides comprehensive support for whistleblowers. Their services include studying complaints, mediating disputes, and conducting investigations, among others.  If a complaint falls outside their five areas of mission, they redirect it to the appropriate authorities.
• Maison des Lanceurs d’Alerte is a coalition of 30 civil society organisations that focuses specifically on supporting whistleblowers. They provide comprehensive assistance including legal, psychological, technical, financial, media and social support tailored to individual needs.

Germany

• Whistleblower Netzwerk E.V (WBN) is the largest whistleblower support organisation in Germany. This non-profit provides legal advice and psychological support to whistleblowers, with particular expertise in corporate misconduct cases. They collaborate with other organisations like Whistleblowing International Network (WIN) and can help connect whistleblowers with international actors if needed.
• The Bundesamt für Justiz (Federal Office of Justice) hosts the Federal External Reporting Office for whistleblowers. They can forward information to responsible authorities. The office accepts online reports through their secure portal and provides detailed information about the reporting process on their website. Before making a report, whistleblowers can also receive advice about protection against reprisals.

Ireland

• The Office of the Protected Disclosures Commissioner (OPDC) serves as an external reporting channel for whistleblowers. Reports can be submitted to the OPDC using their downloadable form, by email, or by phone. Before making a report, whistleblowers can use the OPDC’s pre-engagement procedure to understand if their disclosure qualifies for protection. Whistleblowers also have the option to report to “prescribed persons” – designated public service bodies and regulators who can receive disclosures directly related to their area of responsibility. However, a prescribed person has not yet been designated for AI.
• Transparency International Ireland is the only Irish NGO specialising in whistleblower support. They operate the Speak Up Helpline, providing free confidential information and advice to whistleblowers. They have established the Transparency Legal Advice Centre (TLAC), Ireland’s only independent law center offering free legal advice to whistleblowers.

Definition & Scope

Definition of GPAI models

The Guidelines expand on the statutory definition of GPAI in the AI Act, introducing key thresholds and criteria for classification:

Compute threshold:

• A GPAI model is defined as any model trained using more than 10²³ FLOPs (floating point operations) and capable of generating language (text/audio), text-to-image, or text-to-video outputs.

Functional generality requirement:

• Models that exceed the 10²³ FLOPs threshold but are specialised (e.g., for transcription, image upscaling, weather forecasting, or gaming) are excluded if they lack general capabilities across a broad range of tasks.

Technical clarifications:

• Compute is understood as a combined measure of model size (parameters) and training dataset size.
• A model with ~1 billion parameters trained on substantial datasets would typically meet this compute threshold.
• The Commission has opted for a single estimable compute threshold over listing specific tasks or capabilities.

Model lifecycle and obligations

Once a model qualifies as a GPAI model, lifecycle-wide obligations under the AI Act apply from the start of its pre-training run and extend to all subsequent development phases, including post-market modifications. 

Obligations include:

• Documentation: Must be maintained and updated, and provided to downstream providers and, upon request, to the AI Office or national competent authorities.
• Training data summary: Providers must publish a summary using the yet-to-be-issued AI Office template.
• Copyright policy: Must address copyright compliance and may apply across all models.

GPAI models with systemic risk

Any model trained using ≥10²⁵ FLOPs is presumed to have high-impact capabilities and may be classified as systemic-risk GPAI.

Additional obligations:

• Comprehensive risk assessment and mitigation throughout the lifecycle, including model evaluations.
• Robust cybersecurity measures
• Serious Incident tracking and reporting

Designation pathways:

• Automatic presumption: Based on FLOPs threshold
• Discretionary designation: By the Commission, including following alerts from the scientific panel

Mandatory notifications:

• Providers must notify the Commission within two weeks of reasonably foreseeing or reaching the 10²⁵ FLOPs threshold. Notifications must include:
  • Compute estimates
  • Estimation methodologies (including approximations)

Rebuttal process:

• Providers may contest the systemic risk classification by supplying robust evidence (e.g. benchmark results, scaling laws) that the model does not present systemic risk.
• The Commission may accept or reject rebuttals with reasons.
• Obligations remain in effect during review.

Reassessment rights:

• Initial reassessment may be requested by providers six months post-designation.
• A second reassessment request is allowed after a further six months if the first is unsuccessful.

Ongoing duty to update:

• If the rebuttal was based on materially changed or incomplete/incorrect information, the provider must renotify the Commission.

Determining the GPAI model provider

Single entity development:

• If Entity A develops and places a GPAI model on the EU market, Entity A is the provider.
• If Entity B develops the model for Entity A, but Entity A places it on the market, Entity A remains the provider.

Repository hosting:

• Uploading a model to a repository (e.g., hosted by Entity C) does not transfer provider status. Entity A remains the provider.

Consortium development:

• In the case of GPAI models developed by or for a consortium, the provider is typically the coordinator or the consortium itself, depending on the facts and contractual arrangements.

Upstream and downstream responsibility allocation

Upstream providers:

• If an upstream actor first makes the model available to any downstream actor on the EU market, that actor is the provider and must meet GPAI provider obligations. 

Downstream system integrators:

• If a downstream actor incorporates the GPAI model into an AI system and places the system on the EU market, they are a system provider and must meet obligations relevant to AI systems.

Non-EU origin models:

• If a model is made available outside the EU but is later incorporated into a system placed on the EU market, the model is considered placed at that point.
• The upstream actor is the provider unless they have explicitly excluded EU use. In such cases, the downstream actor becomes the provider.

Downstream modifiers: When they become providers

Not all modifications trigger provider obligations for downstream actors. Minor changes typically do not reclassify a modifier as a GPAI provider.

Threshold for reclassification:

• A downstream actor becomes the new GPAI provider if the training compute used for the modification exceeds one-third of that used to train the original model:
  • ≥ 1/3 of 10²³ FLOPs for all GPAI models
  • ≥ 1/3 of 10²⁵ FLOPs for GPAI models with systemic risk

Scope of obligations:

• Only modification-specific obligations apply: documentation, training data summary, and copyright policy relate only to the additional compute and data.
• However, if modifying a systemic-risk GPAI model, the downstream actor must comply fully with all systemic risk obligations, including notification to the Commission.

Open source models: Exemptions and conditions

Open source GPAI providers benefit from limited exemptions under the AI Act:

• No obligation to provide documentation to downstream providers or, upon request, to the AI Office or national authorities.

Non-exempt requirements:

• Must comply with training data summary and copyright policy requirements.

If designated as a GPAI model with systemic risk, they must fully meet all applicable obligations, including systemic risk management, model evaluations, incident reporting, and cybersecurity.

To qualify as open source under the AI Act, the model must be released under a free and open-source licence that:

• Permits use, access, modification, and redistribution.
• Does not impose restrictions such as:
  • Non-commercial or research-only use
  • Prohibition on redistribution
  • User-size thresholds
  • Mandatory commercial licensing for certain uses
• Permissible restrictions:
  • Credit/attribution requirements
  • Distribution under the same or compatible licence
  • Reasonable and proportionate safeguards against high-risk use (e.g., public safety), provided they are non-discriminatory.

Monetisation and loss of open source status

A GPAI model loses open source exemptions if monetisation is present. Indicators of monetisation include:

• Commercial licensing models:
  • Dual-licensing (e.g., free for academic use, paid for commercial use)
  • Pay-to-access support, maintenance, or updates
  • Hosted access subject to fees or advertising revenue
• Functional dependency on paid services:
  • If users must pay to access essential functionality or security features.
• Personal data processing:
  • Processing user data in connection with access, use, or modification may constitute monetisation, unless solely for non-commercial security purposes.

Not considered monetisation:

• Offering optional premium services or support without restricting free access to the model and its core functionality.

Implementation

Code of Practice 

• Signing the Code of Practice is voluntary, but it can help providers demonstrate compliance with the AI Act’s obligations for GPAI models.
• The Code is not a harmonised standard, so signing it does not create an automatic presumption of compliance.
• The Commission will monitor signatories’ adherence to the Code. Opting out of any chapter (transparency, copyright, or safety/security) means providers cannot rely on the Code to show compliance in that area.
• Signatories may benefit from greater trust and potentially lower fines.
• Non-signatories must independently demonstrate compliance, including through detailed explanations or gap analyses, and should expect more scrutiny from the AI Office—especially regarding lifecycle changes and model modifications.

Enforcement and oversight

• The AI Office will adopt a collaborative and risk-based enforcement model. Informal cooperation is encouraged during training phases.
• Providers of systemic-risk GPAI models are expected to proactively report and engage with the AI Office.
• While obligations kick-in on 2 August 2025, the AI Office does not have full enforcement powers until 2 August 2026 by which time they may request information, order model recalls, mandate mitigations, or impose fines.
• For models placed before 2 August 2025, providers will have until 2 August 2027 to comply. Retraining or “unlearning” won’t be required if technically or economically infeasible, provided this is justified in documentation.
• Models placed after 2 August 2025 must aim to comply on placement. Providers should proactively engage with the AI Office. New entrants, particularly systemic-risk model developers, will receive support to ease compliance.
• Recognising the immature state of external evaluation ecosystems, the AI Office may step in to coordinate development of consistent standards.

Review of Guidelines

• The Commission may update or withdraw these guidelines based on:
  • Experience with implementation
  • Enforcement outcomes
  • Market and technological developments
  • Court of Justice of the EU (CJEU) rulings
• Stakeholders—including providers, regulators, researchers, and civil society—will be invited to contribute to updates via consultations and workshops.

Annex: Training compute – definitions and estimation Methods

Definition:

• Training compute is the total compute used to train a model and assess whether it meets systemic-risk GPAI thresholds:
  • For non-systemic-risk models: compute used for parameter updates.
  • For systemic-risk assessment: all cumulative training compute counts.

Inclusions:

• All compute contributing to model capabilities, including forward passes for synthetic data generation (even discarded data).
• Compute for weight merging or initialization using pre-trained models.

Exclusions:

• Compute for:
  • Publicly available synthetic data
  • Diagnostic/evaluation tasks
  • Failed experiments or research-only runs
  • Auxiliary model training (e.g. reward models)
  • Activation recomputation for memory savings

Estimation methods:

• Cover both hardware- and architecture-based approaches.
• Estimate must be accurate within ±30%, with documentation of assumptions and uncertainties.

The GPAI rules take effect on August 2, 2025, meaning all new models released from that date must comply. However, the Commission’s enforcement actions – such as requests for information, access to models, or model recalls – will only begin a year later, on August 2, 2026. This grace period gives providers time to work with the AI Office to ensure they meet the standards.

For models released before August 2, 2025, providers have until August 2, 2027 to bring them into compliance.

See our full implementation timeline.

Coming up in this post:

• Executive summary
  • Copyright Chapter
  • Safety and Security Chapter
  • Transparency Chapter
• Transparency Chapter
  • Commitment 1: Documentation
  • The Model Documentation Form
• Copyright Chapter
  • Commitment 1: Copyright Policy
• Safety and Security Chapter
  • Commitment 1: Safety and Security Framework
  • Commitment 2: Systemic risk identification
  • Commitment 3: Systemic risk analysis
  • Commitment 4: Systemic risk acceptance determination
  • Commitment 5: Safety mitigations
  • Commitment 6: Security mitigations
  • Commitment 7: Safety and Security Model Reports
  • Commitment 8: Systemic risk responsibility allocation
  • Commitment 9: Serious incident reporting
  • Commitment 10: Additional documentation and transparency
• Appendices
  • Appendix 1: Systemic risks and other considerations
  • Appendix 2: Similarly safe or safer models 
  • Appendix 3: Model evaluations
  • Appendix 4: Security mitigation objectives and measures

Executive summary

Transparency Chapter

Signatories commit to maintaining up-to-date, comprehensive documentation for every GPAI model distributed within the EU, except for models that are free, open-source, and pose no systemic risk. This documentation must follow a standardized Model Documentation Form, detailing licensing, technical specs, use cases, datasets, compute and energy usage, and more. It should be securely stored for at least ten years and made available, upon request, to the AI Office and downstream users. Public release of this information is encouraged to promote transparency.

Copyright Chapter

This chapter ensures alignment with EU copyright law, especially the requirement for prior authorization unless specific exceptions apply (such as text and data mining). Signatories are required to develop and regularly update a robust copyright policy that clearly defines internal responsibilities and complies with legal standards. They must ensure that data collected via web crawling is lawfully accessible, respect machine-readable rights signals like robots.txt, and avoid accessing websites flagged for copyright infringement. Technical safeguards should minimize the generation of infringing content, and terms of service must clearly prohibit unauthorized use. A designated contact point must be provided for copyright holders to submit complaints, with efficient and fair processes for handling them.

Safety and Security Chapter

This chapter sets out comprehensive obligations for developers of GPAI models with systemic risk to identify, assess, mitigate, and transparently report safety and security risks throughout the model’s lifecycle. It establishes a risk governance framework focused on pre-market assessments, ongoing monitoring, and continuous oversight.

Signatories must develop a cutting-edge Safety and Security Framework before model release, outlining evaluation triggers, risk categories, mitigation strategies, forecasting methods, and organizational responsibilities. This framework should be regularly updated in response to new risks, incidents, or significant changes in the model or its environment.

Systemic risks are identified through structured processes such as inventories, scenario analysis, and consultation with internal and external experts. These risks are then analysed using rigorous evaluation methods including simulations, adversarial testing, and post-market surveillance.

Before progressing with development or deployment, signatories must evaluate whether identified risks are acceptable, applying defined risk-tier frameworks with built-in safety margins. If risks are deemed unacceptable, immediate corrective actions are required.

To maintain acceptable risk levels, safety measures must be integrated throughout the model’s lifecycle, including filtering, continuous monitoring, refusal training, phased access controls, downstream tool safeguards, and secure deployment environments. Parallel security controls must prevent unauthorized access or misuse, employing strong digital and physical protections until the model is either publicly released or decommissioned.

A mandatory Safety and Security Model Report must be submitted prior to release and updated as risks evolve. This report should include detailed documentation on risk identification, analysis, mitigation efforts, model behaviour, external evaluations, and any material changes in the risk landscape.

Organizational accountability is key. Signatories must clearly assign oversight, ownership, monitoring, and assurance roles within their governance structures and ensure adequate resources, a strong risk culture, and protections for whistleblowers.

Serious incidents must be promptly tracked, documented, and reported to regulators according to severity and tight deadlines (for example, within 2 days for incidents affecting critical infrastructure). Reports must be regularly updated and kept for at least five years.

Finally, signatories are required to retain detailed records of safety and risk management activities for a minimum of ten years. High-level summaries of their safety frameworks and model reports should be published when needed to reduce risks, unless the model meets specific criteria qualifying it as “similarly safe or safer.”

Transparency Chapter

This chapter establishes clear expectations for how Signatories should meet their transparency duties under Article 53(1)(a)–(b) and Annexes XI and XII of the AI Act. The primary goal is to ensure critical information flows effectively to both downstream providers and the AI Office while preserving appropriate levels of confidentiality.

Commitment 1: Documentation

Signatories pledge to:

• Keep comprehensive, current documentation for every model (Measure 1.1)
• Facilitate information sharing with the AI Office and downstream providers (Measure 1.2)
• Safeguard the accuracy, completeness, and protection of all documentation (Measure 1.3)

These commitments do not apply to free and open-source models, unless they are classified as a GPAI model with systemic risk.

Measure 1.1: Drawing up and keeping up-to-date model documentation

• Before placing a GPAI model on the EU market, Signatories must complete prepare comprehensive documentation addressing all elements specified in the Model Documentation Form (detailed below). 
• This documentation must remain current, reflecting any material changes, and be preserved for a minimum of 10 years after the model’s initial release.

Measure 1.2: Providing relevant information

• Signatories must publicly provide contact details that allow the AI Office and downstream providers to request documentation access.
• When requested, they must deliver the latest documentation version to the AI Office within the designated timeframe.
• Downstream providers must receive necessary documentation – along with any required clarifications – within 14 days, barring legitimate reasons for delay.
• Public release of documentation is recommended as a means of enhancing overall transparency.

Measure 1.3: Ensuring quality, integrity, and security of information

• Signatories bear responsibility for maintaining documentation that is precise, protected from unauthorized modification, and stored securely to demonstrate regulatory compliance.

The Model Documentation Form

The form covers the following categories for regulatory and downstream use:

• Licensing & distribution
• Model identification (name, version, release date, entity)
• Technical specifications (architecture, size, I/O formats)
• Intended and approved use cases
• Integration dependencies (platforms, software/hardware)
• Training methodology and design rationale
• Dataset details (source, type, scope, volume, curation, bias mitigation)
• Energy and compute usage (training & inference)

Copyright Chapter

This chapter facilitates adherence to Article 53(1)(c) of the AI Act, which mandates that providers establish copyright policies consistent with EU copyright and related rights legislation. While following these guidelines supports regulatory compliance efforts, it does not constitute a guarantee of full legal compliance, which ultimately depends on interpretations by national courts and the Court of Justice of the EU (CJEU).

European Union copyright law operates on the foundational principle that prior authorization is required for use of protected works, except where specific exceptions apply – such as text and data mining (TDM) provisions under Article 4(1) of Directive (EU) 2019/790 – and rights holders have not expressly reserved their rights.

Commitment 1: Copyright Policy

Signatories undertake to establish, maintain, and execute a comprehensive copyright policy that applies to all GPAI models distributed within the EU. This policy must align with the standards outlined in this chapter. 

However, adherence to these chapter requirements does not substitute for the fundamental obligation to comply with Union and national copyright legislation. Signatories retain full responsibility for ensuring their operations conform to applicable legal frameworks, including Article 4(3) of Directive (EU) 2019/790, prior to undertaking any copyright-relevant activities.

Measure 1.1: Draw up, keep up-to-date and implement a copyright policy

• Signatories must develop and maintain a unified, regularly updated copyright policy that demonstrates compliance with this chapter’s requirements and clearly defines internal accountability structures. 
• Publication of a policy summary is encouraged to enhance transparency and public understanding.

Measure 1.2: Reproduce and extract only lawfully accessible copyright-protected content when crawling the World Wide Web

• Web crawling systems deployed for training purposes must limit access to legally available content only.
• Circumventing technical barriers (such as paywalls or access restriction mechanisms) is forbidden.
• Providers must exclude websites that EU/EEA authorities have identified as persistent copyright violators, based on a publicly maintained EU-hosted registry.

Measure 1.3: Identify and comply with rights reservations when crawling the World Wide Web

• Crawling systems must possess the capability to recognize and honor machine-readable rights reservations, including robots.txt files, consistent with RFC 9309 standards.
• Providers must adhere to other broadly recognized and technically practical standards approved through EU-level consultations.
• Signatories are encouraged to actively participate in developing such technical protocols.
• They must provide transparency regarding their crawler operations, their approach to handling rights-reserved content, and offer automated notification systems for rights holders.
• Search engine operators must ensure that respecting rights reservations does not compromise their indexing capabilities.

Measure 1.4: Mitigate the risk of copyright-infringing outputs

• Providers must deploy technical protective measures designed to minimize the likelihood that AI models produce copyright-infringing content.
• They must explicitly prohibit infringing uses within their terms of service or documentation, including for open-source model distributions.
• These protective measures must remain effective whether the model is used directly or through third-party implementations.

Measure 1.5: Designate a point of contact and enable the lodging of complaints

• Signatories must establish a dedicated contact point for rights holders and implement a system for receiving substantiated electronic complaints.
• All complaints must receive fair consideration and timely responses, except those that are manifestly groundless or repetitive in nature.
• This complaint mechanism operates without prejudice to other legal remedies available to rights holders for protecting their interests.

Safety and Security Chapter

Commitment 1: Safety and Security Framework

Signatories pledge to establish a state-of-the-art Safety and Security Framework that defines comprehensive systemic risk management procedures and measures designed to maintain acceptable levels of systemic risk. This encompasses developing, implementing, and regularly updating the Framework while keeping the AI Office informed of all developments.

Measure 1.1: Creating the Framework

Signatories shall develop a Framework that documents both existing and planned processes for assessing and mitigating systemic risks. The Framework must encompass: 

• Justified trigger points that determine when lighter tough model evaluations should occur throughout the model lifecycle. 
• For systemic risk acceptance (Commitment 4):
  • Clear criteria and rationale for establishing systemic risk categories and their practical application.
  • Comprehensive high-level mitigation strategies corresponding to each risk category. 
  • Projected timelines indicating when models are anticipated to surpass the current highest risk tier, supported by detailed justification, underlying assumptions, and utilization of forecasting methodologies, expert surveys, or professional estimates. 
  • Clear description of how external guidance (including governmental input) influences development and deployment choices. 

• Clear assignment of systemic risk management responsibilities (Commitment 8).
• Procedures for Framework updates and revisions. 
• Signatories must confirm the Framework within four weeks of notifying the Commission that their GPAI model meets the threshold to be classified as a GPAI model with systemic risk, and at minimum two weeks prior to market launch.

Measure 1.2: Implementing the Framework

Signatories shall maintain continuous systemic risk assessment through: 

• Executing streamlined model evaluations (such as automated evaluations) at designated trigger points (established based on timeframes, computational training resources, development milestones, user accessibility, inference computing capacity, and/or affordances). 
• Ongoing post-market monitoring, 
• Incorporating intelligence from serious incident reports. 
• Expanding assessment scope and intensity as circumstances warrant, or executing comprehensive systemic risk assessment and mitigation protocols based on evaluation results, post-market monitoring data, and serious incident intelligence.

They shall continuously deploy systemic risk mitigation measures that reflect the outcomes of assessments (model evaluations, post-market monitoring, and serious incident analysis).

They shall execute comprehensive systemic risk assessment and mitigation protocols involving: 

• Systematic identification of systemic risks. 
• Thorough analysis of each identified systemic risk. 
• Determination of systemic risk acceptability levels. 
• Implementation of mitigation measures and reassessment when risks prove unacceptable, followed by deployment of safety and/or security countermeasures, with the process cycling back to risk identification

This process must be completed prior to market introduction. 

It must be repeated when:

• The reasonably predictable circumstances supporting the justification for acceptable systemic risk levels, including built-in safety margins, would cease to be valid. 
• The model’s application or integration within AI systems has experienced, or is projected to experience, substantial modification.

Signatories must provide comprehensive reporting of all measures and processes to the AI Office.

Measure 1.3: Updating the Framework

Signatories shall revise the Framework as necessary – promptly following any assessment – to ensure it remains current and maintains state-of-the-art standards. All updates must include comprehensive change documentation detailing the rationale, version identification, and implementation date.

Framework evaluations shall be conducted: 

• At minimum annually following the model’s market introduction; or 
• Earlier, when reasonable evidence suggests that adequacy or compliance has been significantly compromised.

Triggering conditions include: 

• Material changes that could foreseeably result in unacceptable systemic risks. 
• Serious incidents or near-misses that demonstrate materialized systemic risks. 
• Notable shifts in systemic risk profiles (including model capability evolution or declining mitigation effectiveness).

Evaluations examine: 

• Adequacy: Whether Framework procedures and measures effectively address systemic risks. 
• Adherence: Compliance with Framework requirements, explanations for any non-compliance, corrective actions taken, and — where future non-compliance appears possible — detailed remediation strategies.

Measure 1.4: Framework notifications

• Signatories shall grant the AI Office complete, unredacted access to their Framework and all subsequent updates within five business days of final confirmation.

Commitment 2: Systemic risk identification

Signatories pledge to identify systemic risks through a systematic methodology, including the creation of risk scenarios that inform systemic risk analysis and acceptance decisions.

Measure 2.1: Systemic risk identification process

Signatories shall identify systemic risks through:

• Creating a comprehensive inventory of potential risks (Appendix 1.1), drawing from model-agnostic sources, model-specific information (including post-market data and incident reports), and guidance from the AI Office, Scientific Panel, or International Network of AI Safety Institutes (where officially endorsed).
• Examining pertinent characteristics (Appendix 1.2) and sources (Appendix 1.3).
• Identifying systemic risks from this comprehensive analysis.
• Identifying risks catalogued in Appendix 1.4.

Measure 2.2: Systemic risk scenarios

Signatories shall construct detailed systemic risk scenarios, establishing the optimal quantity and granularity level for each identified systemic risk.

Commitment 3: Systemic risk analysis

Signatories pledge to thoroughly examine each identified systemic risk to inform systemic risk acceptance decisions, encompassing the collection of model-independent information, execution of model evaluations, risk modelling, estimation activities, and ongoing monitoring of systemic risks.

Measure 3.1: Model-independent information

Signatories shall collect pertinent model-independent information through approaches including comprehensive literature reviews, market and training data analysis, incident pattern studies, trend projection, expert consultation, and public opinion research.

Measure 3.2: Model evaluations

Signatories shall execute cutting-edge evaluations across all relevant modalities to examine model capabilities, behavioural tendencies, operational features, and real-world impacts (Appendix 3).

Evaluations shall employ suitable methodologies, incorporate open-ended testing for emerging properties, and be guided by model-independent information. Approaches include: structured questioning, task-oriented assessment, standardized benchmarks, adversarial testing, human enhancement studies, model organism research, simulation exercises, and proxy evaluations for restricted content areas.

Measure 3.3: Systemic risk modelling

Signatories shall perform advanced systemic risk modelling, grounded in risk scenarios and informed by identified risks and comprehensive analysis.

Measure 3.4: Systemic risk estimation

Signatories shall calculate the likelihood and severity of potential harm using state-of-the-art methodologies. Estimations may be quantitative, semi-quantitative, or qualitative in nature, encompassing risk scoring systems, risk matrices, or probability distributions, and must incorporate identified risks, analytical findings, and serious incident data.

Measure 3.5: Post-market monitoring

Signatories shall establish comprehensive post-market surveillance systems to inform systemic risk determinations, Model Report updates, and timeline projections.

Monitoring activities shall evaluate model capabilities, propensities, affordances, and effects through methods including:

• End-user feedback collection, dedicated reporting channels, bug bounty programs, community-driven evaluations.
• Monitoring of code repositories and social media platforms, research support initiatives.
• Privacy-preserving data logging (including watermarking and provenance tracking).
• Monitoring violations of usage restrictions and resulting incidents.
• Tracking opaque model characteristics relevant to systemic risk assessment.

Signatories operating AI systems that incorporate their GPAI models must implement corresponding monitoring protocols for those systems.

To facilitate effective monitoring, Signatories shall provide sufficient numbers of independent external evaluators with complimentary access to the model’s most advanced versions, including variants with minimal safety constraints, unless equivalently safe models are made available. Access mechanisms include API interfaces, on-premise installations, dedicated hardware provision, or public model distribution.

Signatories shall publish transparent evaluator selection standards and utilize evaluation outcomes solely for systemic risk assessment purposes. Evaluator inputs and outputs shall not be incorporated into model training processes without explicit consent.

Signatories shall refrain from legal or technical retaliation against evaluators conducting good-faith testing and publication activities, provided they:

• Maintain model availability without disruption.
• Handle sensitive data responsibly.
• Avoid creating public safety hazards.
• Refrain from coercive application of findings.
• Adhere to responsible disclosure protocols.

Such disclosure policies shall permit publication within 30 business days unless extended delays are warranted due to elevated systemic risk concerns.

Small and medium enterprises (SMEs) and small midcaps (SMCs) may seek AI Office assistance for monitoring activities.

Commitment 4: Systemic risk acceptance determination

Signatories pledge to establish clear systemic risk acceptance standards and determine whether systemic risks are acceptable prior to advancing with development activities, market introduction, or operational deployment.

Measure 4.1: Systemic risk acceptance criteria and acceptance determination

Signatories shall articulate and justify systemic risk acceptance criteria within their Framework documentation.

Criteria must include quantifiable risk tiers — encompassing at least one category not yet achieved — based on capabilities assessment, behavioural propensities, risk calculations, or alternative metrics.

They shall implement these categories with suitable safety margins to evaluate the acceptability of individual and aggregate systemic risks, considering risk identification and analysis outcomes.

Safety margins must account for:

• Uncertainties in systemic risk sources (such as post-assessment capability emergence).
• Assessment methodology limitations (including under-elicitation issues).
• Mitigation effectiveness vulnerabilities (such as circumvention risks).

Measure 4.2: Proceeding or not proceeding based on systemic risk acceptance determination

Signatories shall proceed with development and deployment only when systemic risks are determined to be acceptable.

When risks are or may imminently become unacceptable, they must implement suitable corrective actions, including usage restrictions, market withdrawal, enhanced mitigations, and comprehensive re-evaluation.

Commitment 5: Safety mitigations

Signatories pledge to deploy suitable safety mitigations throughout the model lifecycle to preserve acceptable systemic risk levels.

Measure 5.1: Appropriate safety mitigations

Mitigations must demonstrate resilience against adversarial attacks and align with the model’s distribution strategy.

Implementation examples include:

• Comprehensive training data filtration.
• Real-time input and output monitoring.
• Behavioural modifications (including refusal training protocols).
• Phased model access deployment.
• Mitigation tools for downstream users.
• Quantitative safety guarantees.
• Secure agent ecosystems (including model identification, specialized protocols, incident response tools).
• Transparency enhancement tools (including chain-of-thought accessibility, mitigation durability assessment).

Commitment 6: Security mitigations

Signatories pledge to maintain robust cybersecurity measures throughout the model lifecycle to prevent risks arising from unauthorized release, access, or theft. Excludes models with capabilities lower than at least one model with parameters available for public download. Security measures remain in effect until model parameters are made publicly available or securely deleted.

Measure 6.1: Security Goal

• Signatories shall establish a comprehensive Security Goal that identifies threat actors their mitigations are intended to protect against, informed by current and projected model capabilities.

Measure 6.2: Appropriate security mitigations

• Signatories shall deploy security measures that align with their established Security Goal, incorporating those specified in Appendix 4.
• Any departures from Appendix 4.1–4.5(a) must demonstrate equivalent protective outcomes.
• Implementation may be phased to correspond with model capability advancement.

Commitment 7: Safety and Security Model Reports

Signatories pledge to prepare comprehensive Safety and Security Model Reports prior to market introduction, ensure they are updated, and provide timely notification to the AI Office. Reports may reference previous submissions and may encompass multiple models when appropriate. Small and medium enterprises (SMEs) and small midcaps (SMCs) may provide reduced detail levels.

Measure 7.1: Model description and behaviour

The Model Report must contain: 

• A high-level description of the model’s architecture, capabilities, propensities, affordances, and development methodology (including training approaches and data sources). 
• Current and intended applications of the model. 
• Available model variants and versions. 
• Model specifications (including governing principles, principle hierarchy, refusal categories, system prompts).

Measure 7.2: Reasons for proceeding

The report must provide clear justification for why systemic risks are deemed acceptable, encompassing: 

• Comprehensive rationale and incorporated safety margins. 
• Reasonably foreseeable circumstances under which the justification might become invalid. 
• Decision-making process details (including governmental input where applicable).

Measure 7.3: Documentation of systemic risk identification, analysis, and mitigation

The report must comprehensively document:

• Systemic risk identification and analysis outcomes, including:
  • Description of the systemic risk identification process. 
  • Explanation of the uncertainties and assumptions on model usage and integration into AI systems. 
  • Systemic risk modelling results summary. 
  • Detailed description of systemic risks posed by the model, including evaluation procedures, tests and tasks performed during evaluations, scoring methods, capability elicitation process, evaluation score comparisons with human baselines, across model versions and evaluation settings. 
  • Five randomly selected samples of inputs and outputs from each relevant model evaluation (e.g. text completions, content generations, or agent trajectories) to support independent interpretation of evaluation results and systemic risk assessment. Trajectories that play a significant role in explaining systemic risk must be included. Additional random samples must be provided upon request by the AI Office.
  • Description of resources and access provided to: internal model evaluation teams and independent external evaluators, which they can also provide themselves directly to the AI Office.
  • Where applicable, justification that the “safe reference model” and “similarly safe or safer model” criteria have been met.
• Description of all safety mitigations implemented; how they meet standards set out by Measure 5.1; and mitigation limitations. 
• Description of the Security Goal (Measure 6.1); all security mitigations implemented; how they achieve the Security Goal, including alignment with international standards; and justification of how alternative approaches achieve the intended security objective if any security mitigations in Appendices 4.1-4.5(a) were not followed. 
• High-level description of planned techniques and resources for model development over the next six months, including use of other AI systems; expected differences in capabilities and behaviour in future models; and planned new or significantly updated safety and security mitigations.

Measure 7.4: External reports

The report must incorporate: 

• Hyperlinks or citations to reports from independent external evaluators (Appendix 3.5) and independent security reviewers (Appendix 4.5), while respecting confidentiality requirements and evaluator oversight. 
• Justification when no external evaluator was engaged (per Appendix 3.5).
• Explanation of evaluator selection based on demonstrated qualifications.

Measure 7.5: Material changes to the systemic risk landscape

The report must describe significant alterations in the systemic risk environment resulting from model development or deployment, such as: 

• Novel scaling relationships. 
• Breakthrough architectural innovations. 
• Enhanced or diminished mitigation effectiveness. 
• New training methodologies that improve distributed training viability.

Measure 7.6: Model Report updates

Reports require updating when systemic risk acceptability justifications are materially undermined, including: 

• Activation of specified trigger conditions (capability shifts, new integrations, serious incidents). 
• Material changes in capabilities, propensities, or affordances due to additional post-training, integration with new tools, or increased inference compute. 
• A material change in how the model is used or integrated into AI systems.
• Serious incidents or near misses involving the model or a similar model.
• Developments that either:
  • Materially undermine the external validity of previously conducted model evaluations,
  • significantly improve the state of the art in model evaluation, or
  • otherwise indicate that the original systemic risk assessment is materially inaccurate.
• Updates should be completed within a reasonable timeframe. 
• Updates due to deliberate changes must be completed before the change is made available on the market. 
• For the most capable models currently on the market, the Signatory must provide the AI Office with an updated Model Report at least every six months, unless:
  • There has been no material change in the model’s capabilities, propensities, or affordances since the last report;
  • The Signatory intends to release a more capable model within one month; or
  • The model qualifies as “similarly safe or safer” under Appendix 2.2 for each systemic risk identified in accordance with Measure 2.1.
• The updated Model Report must include:
  • Updated content as specified in Measures 7.1 to 7.5, based on the most recent full systemic risk assessment and mitigation process; and
  • A changelog describing what was updated, why the changes were made, the new version number, and the date of the update.

Measure 7.7: Model Report notifications

• Reports must be delivered (unredacted except where restricted by national security legislation) by the time of market introduction.
• Updates must be submitted within 5 business days of confirmation.
• A 15-day extension is permitted when:
  • The AI Office determines the Signatory is operating in good faith; and
  • An interim report is submitted without delay, containing justification for proceeding (Measure 7.2), and changes in systemic risk landscape (Measure 7.5).

Commitment 8: Systemic risk responsibility allocation

Signatories pledge to clearly assigning responsibilities for managing systemic risks associated with their models across all levels of the organisation; allocating appropriate resources to the individuals or teams tasked with managing systemic risks; and fostering a sound risk culture within the organisation.

Measure 8.1: Definition of clear responsibilities

• Systemic risk oversight: Oversight of systemic risk assessment and mitigation processes.
• Systemic risk ownership: Day-to-day management of systemic risks, including assessments, mitigation, and incident response.
• Systemic risk support and monitoring: Ongoing support for and monitoring of systemic risk processes.
• Systemic risk assurance: Providing internal and/or external assurance on the adequacy of risk management to the supervisory management body or equivalent independent body.

Responsibilities must be allocated appropriately to the Signatory’s governance structure and complexity, including:

• Supervisory function of the management body (e.g. board, risk/audit committee);
• Executive function of the management body;
• Operational teams;
• Internal assurance providers (e.g. internal audit), if available;
• External assurance providers (e.g. third-party auditors), if available.

The Measure is presumed to be met if, proportionate to the model’s systemic risks:

• Oversight is handled by a dedicated committee or independent body (e.g. risk/audit committee). For SMEs/SMCs, an individual in the supervisory function may suffice.
• Ownership is assigned to suitable executive-level individuals (e.g. Head of Research/Product), with cascading responsibility to operational managers.
• Support & Monitoring is assigned to executive members not directly involved in risk-generating business (e.g. CRO or VP of Safety). SMEs/SMCs must have at least one executive member responsible for this function.
• Assurance is led by a designated individual or function (e.g. Head of Internal Audit), with support from internal/external audits. For SMEs/SMCs, periodic supervisory assessment is required.

Measure 8.2: Allocation of appropriate resources

Signatories’ management bodies must oversee and ensure the allocation of resources sufficient to support those assigned systemic risk responsibilities (per Measure 8.1), relative to the level of systemic risk. Types of resources include human resources, financial resources, access to information and knowledge, and computational resources.

Measure 8.3: Promotion of a healthy risk culture

• Leadership tone: Senior leadership communicates systemic risk frameworks clearly.
• Open communication: Staff can raise and challenge systemic risk decisions.
• Independence and incentives: Risk personnel are independent and incentivised to avoid under- or over-estimation of risk.
• Staff awareness: Surveys confirm awareness of risks and channels to raise concerns.
• Effective reporting channels: Reporting mechanisms are used and appropriately acted upon.
• Whistleblower policy: Workers are informed annually, and policies are publicly accessible.
• Non-retaliation: No adverse actions are taken against those who report systemic risks to authorities in good faith.

Commitment 9: Serious incident reporting

Signatories pledge to systematically track, document, and report serious incidents involving their models to the AI Office and national competent authorities without unnecessary delay. Reports must include corrective measures and be proportionate to incident severity.

Measure 9.1: Methods for serious incident identification

To identify serious incidents, Signatories must: 

• Apply the methods set out in Measure 3.5, including systematic post-market monitoring.
• Consult external sources, including police and media reports, social media content, academic research, and incident databases.
• Enable third-party reporting, by informing downstream providers, users, and other stakeholders of available direct reporting channels, and facilitating reporting to either the Signatory or directly to the AI Office and/or national authorities.

Measure 9.2: Relevant information for serious incident tracking, documentation, and reporting

Signatories must track, document, and report to the AI Office and, where applicable, to national competent authorities, at minimum and to the best of their knowledge, the following information (appropriately redacted to comply with Union data protection and other applicable laws):

• Start and end dates (or best approximations) of the incident.
• Description of resulting harm and the affected individuals or groups.
• The causal chain of events.
• Identification of the model involved.
• Evidence of the model’s involvement.
• Measures taken or intended by the Signatory.
• Recommendations for action by the AI Office or competent authorities.
• Root cause analysis, including:
  • The model outputs that caused or contributed to the incident.
  • Inputs used.
  • Systemic mitigation failures or circumventions. 
• Patterns from post-market monitoring reasonably linked to the incident (e.g. near misses, anomaly trends).

Note: If certain information is unavailable at the time of reporting, the report must record this explicitly. The level of detail must reflect the severity of the incident.

Measure 9.3: Reporting timelines

Initial report: Must include information in points (1)–(7) of Measure 9.2, submitted as follows:

• Disruption to critical infrastructure: ≤ 2 days from awareness)
• Serious cybersecurity breach (e.g. exfiltration, cyberattack): ≤ 5 days from awareness
• Death of a person: ≤ 10 days from awareness
• Serious harm to health, fundamental rights, property, or environment: ≤ 15 days from awareness

Awareness includes both established and reasonably suspected involvement of the Signatory’s model.

Intermediate report: Where an incident remains unresolved, Signatories must provide updated information, including additional details from Measure 9.2, at least every 4 weeks following submission of the initial report.

Final report: To be submitted no later than 60 days after the incident is resolved and must contain the full set of information required under Measure 9.2.

Consolidated reporting: If multiple similar serious incidents occur within a reporting window, they may be included in the same report as the first incident, provided individual reporting timelines are respected for that initial case.

Measure 9.4: Retention period

• All documentation and relevant information gathered under this Measure must be retained for a minimum of five (5) years from the later of the date of documentation, or the date of the serious incident – without prejudice to any applicable EU legal obligations regarding information retention.

Commitment 10: Additional documentation and transparency

Signatories pledge to document their implementation of the Safety and Security Chapter and publish summarized versions of their Framework and Model Reports when necessary for systemic risk mitigation.

Measure 10.1: Additional documentation

Core documentation to be maintained and provided upon request: Signatories must prepare and maintain the following records for provision to the AI Office upon request, ensuring that these documents remain up to date:

• A detailed description of the model’s architecture.
• A detailed explanation of how the model is integrated into AI systems, including how software components build on or feed into each other, and their integration into the overall processing pipeline, insofar as known to the Signatory.
• A detailed account of model evaluations conducted under this Chapter, including evaluation strategies, and evaluation results.
• A detailed description of safety mitigations implemented in accordance with Commitment 5.

This documentation must be retained for a minimum of ten (10) years after the relevant model is placed on the market.

Additional records to support compliance with systemic risk measures: To evidence adherence to this Chapter upon request by the AI Office, Signatories are further required to track and maintain the following, where not already included in the above documentation:

• Processes, measures, and key decisions forming part of the Signatory’s systemic risk assessment and mitigation efforts.
• Justifications for the selection of any particular best practice, state-of-the-art process or measure, or other innovative process or measure, if relied upon to demonstrate compliance with this Chapter.

Note: The above information need not be compiled or stored in a single repository. It must, however, be retrievable and made available upon request by the AI Office.

Measure 10.2: Public transparency

Where necessary to assess and/or mitigate systemic risks, Signatories must publish (e.g., via their website) a summarised version of their: framework (pursuant to Commitment 1), and Model Report(s) (pursuant to Commitment 7), including any updates thereof. 

The published version must include high-level summaries of systemic risk assessment results, and high-level descriptions of safety and security mitigations implemented. 

Any publication must exclude or redact information that would undermine the effectiveness of safety and/or security mitigations or compromise sensitive commercial information.

Publication is not required for:

• Frameworks – if all models of the Signatory qualify as “similarly safe or safer models” under Appendix 2.2.
• Model Reports – if the model in question qualifies as a “similarly safe or safer model” under Appendix 2.2.

Appendices

Appendix 1: Systemic risks and other considerations

Appendix 1.1: Types of Risks

To determine whether a systemic risk exists (as per Article 3(65) AI Act), risks are classified under five primary types, which may overlap:

• Risks to public health
• Risks to safety
• Risks to public security
• Risks to fundamental rights
• Risks to society as a whole

Examples include threats to critical infrastructure, public mental health, freedom of expression, data privacy, economic security, the environment, and democracy. Specific risks such as disinformation, non-consensual intimate imagery (NCII), and child sexual abuse material (CSAM) are also covered.

Appendix 1.2: Nature of systemic risks

Appendix 1.2.1: Essential characteristics 

A risk is systemic when it:

• Is specific to high-impact AI capabilities,
• Has significant effects across the EU market, and
• Can scale through the AI value chain.

Appendix 1.2.2: Contributing characteristics 

These include:

• Capability- or reach-dependence: Risk grows with model power or use.
• High velocity: Rapid onset, outpacing mitigations.
• Cascading impact: Triggers chain reactions.
• Irreversibility: Persistent or permanent harm.
• Asymmetry: Few actors can cause large-scale effects.

Appendix 1.3 Sources of systemic risks

Appendix 1.3.1 Model capabilities

Risk may arise from functionalities such as:

• Offensive cyber or CBRN capabilities,
• Persuasive or deceptive interaction,
• Autonomy, self-replication, or planning,
• Tool use and control of physical systems,
• Self-reasoning and evasion of oversight.

Appendix 1.3.2 Model propensities

These refer to tendencies such as:

• Misalignment with human intent or values,
• Discriminatory bias, hallucinations, or lawlessness,
• Goal persistence or power-seeking,
• Collusion or conflict with other systems.

Appendix 1.3.3 Model affordances and other systemic risk sources

Systemic risk may also stem from:

• Access to powerful tools or infrastructure,
• Weak security, poor oversight, or misuse,
• Wide-scale deployment or user base,
• Vulnerabilities in release strategies,
• Inadequate explainability or transparency.

Appendix 1.4 Specified systemic risks

The following are treated as specified systemic risks for the purpose of risk identification (Measure 2.1, point 2):

• CBRN risk: AI lowering barriers or increasing the impact of chemical, biological, radiological, or nuclear attacks.
• Loss of control: Human inability to modify or shut down models due to misalignment, autonomy, or resistance.
• Cyber offence: AI enabling advanced cyber-attacks, especially on critical infrastructure.
• Harmful manipulation: Strategic persuasion or deception targeting populations or decision-makers, potentially undermining democratic processes or fundamental rights.

Appendix 2: Similarly safe or safer models 

Appendix 2.1 Safe reference models

A model qualifies as a safe reference model in relation to a specific systemic risk if all of the following conditions are met:

1. Regulatory status:
   • The model was placed on the market before this Chapter’s publication; or
   • It has completed the full systemic risk assessment and mitigation process, and the AI Office has received its Model Report, with risks deemed acceptable.
2. Sufficient visibility:
   • The Signatory has full insight into the model’s architecture, capabilities, tendencies, affordances, and mitigations.
   • This is assumed for the Signatory’s own models or where full technical access is granted (including model parameters).
3. No contrary evidence:
   • There are no other reasonable grounds to believe the model’s systemic risks are not acceptable.

Appendix 2.2 Similarly safe or safer models

A model may be classified as similarly safe or safer in relation to a specific systemic risk when:

1. Risk comparison:
   • Following systemic risk identification, the Signatory does not reasonably foresee any materially different risk scenario compared to the safe reference model.
2. Benchmarking:
   • The model performs at or below the reference model on all relevant state-of-the-art, light-weight benchmarks, with only minor capability increases that do not materially elevate risk.
   • Benchmarks must be conducted in accordance with established procedures (Measure 3.2).
3. Technical equivalence:
   • There are no known architectural or behavioural differences that would reasonably result in increased systemic risk.
   • There are also no other reasonable grounds to believe risk is materially higher than the reference model.

Important note: Assessments in Appendix 2.2 points (2) and (3) and Appendix 2.1 point (2) must include appropriate safety margins to account for uncertainty, such as incomplete information or measurement error.

If a model previously used as a safe reference loses that status, the Signatory must act within six months to either:

• Identify a new safe reference model, or
• Apply full regulatory obligations to the related model, including completion of all previously exempted or reduced elements of the systemic risk assessment process.

Appendix 3: Model evaluations

Appendix 3.1: Rigorous model evaluations

All model evaluations must be carried out with a high level of scientific and technical rigour, ensuring:

• Internal validity (the results accurately reflect the tested scenario),
• External validity (results are generalisable to real-world use), and
• Reproducibility (independent replication is possible).

Appendix 3.2: Model elicitation

Evaluations must elicit the full capabilities, tendencies, and potential effects of the model using state-of-the-art techniques, designed to:

• Minimise under-elicitation (missing relevant behaviours),
• Prevent deception by the model during tests (e.g. sandbagging).
  Techniques may include changes to compute access, prompt design, scaffolding, and fine-tuning.

Signatories must:

• Match the elicitation capabilities of potential misuse actors, and
• Reflect the expected context of use, including tools and integrations that are planned or already used for similar models.

Appendix 3.3: Assessing Mitigation Effectiveness

Evaluations must test how well safety mitigations perform, especially when systemic risk acceptance depends on them. This includes:

• Whether mitigations work as intended,
• Whether they can be circumvented or subverted (e.g. by jailbreaking),
• Whether their effectiveness may degrade over time.

Testing must use state-of-the-art adversarial techniques to probe for vulnerabilities.

Appendix 3.4: Qualified Evaluation Teams and Resources

Evaluations must be conducted by multi-disciplinary teams with both technical and domain expertise related to the specific systemic risk. Indicative qualifications include:

• A relevant PhD or peer-reviewed work,
• Experience in developing model evaluation methods,
• At least 3 years of relevant work or research experience.

Teams must be provided with:

• Sufficient access to the model, including internal components (e.g. logits, activations) and unmitigated versions where appropriate,
• Model information, including specifications and training data,
• Time (e.g. at least 20 business days for most tasks), and
• Resources, including compute, engineering support, and staffing.

Security concerns must be accounted for when granting access to sensitive model components.

Appendix 3.5 Independent external model evaluations

In addition to internal reviews, Signatories must appoint qualified, independent external evaluators unless:

1. The model is already deemed “similarly safe or safer” (Appendix 2.2), or
2. Despite a good-faith effort (e.g. a 20-day public call), no suitable external evaluators can be identified.

Independent evaluators must:

• Have relevant domain and technical expertise,
• Follow strict security protocols, and
• Agree to protect commercially sensitive information.

They must be granted sufficient access, information, time, and resources, as outlined in Appendix 3.4. Signatories must not interfere with the integrity of external tests (e.g. by logging test data without permission).

Small and Medium Enterprises (SMEs/SMCs) may seek support from the AI Office to meet these requirements.

Appendix 4: Security mitigation objectives and measures

Appendix 4.1 General security mitigations

Signatories must adopt baseline cybersecurity measures to protect against common threats. These include:

• Network access control: Identity and access management (e.g. MFA, strong passwords, zero trust architecture, wireless security equal to wired, guest network isolation).
• Social engineering protection: Email filtering to detect phishing and suspicious attachments.
• Malware and removable media: Policies restricting the use of USBs and similar devices.
• Software security: Regular software updates and patch management to prevent exploits.

Appendix 4.2 Protection of unreleased model parameters

To safeguard sensitive model data, Signatories must:

• Track all stored copies: Maintain a secure registry of devices/locations holding model parameters.
• Restrict copying to unmanaged devices: Enforce access controls and monitor for unauthorized data transfer.
• Encrypt parameters in transit and at rest: Use 256-bit encryption and secure key storage (e.g. TPM).
• Secure temporary storage: Decrypt parameters only in non-persistent memory for legitimate use.
• Secure parameters in use: Deploy confidential computing techniques such as attested trusted execution environments.
• Control physical access: Limit access to sensitive environments (e.g. data centres) and perform inspections for unauthorised presence or devices.

Appendix 4.3 Hardening interface-access to unreleased model parameters

Signatories must harden all interfaces that access unreleased model parameters:

• Limit interface access: Restrict access to authorised users/software with MFA and review permissions at least every 6 months.
• Secure interface code: Perform in-depth manual or automated security reviews of code linked to model parameter access.
• Prevent exfiltration: Apply methods such as output rate limiting on interfaces.
• Minimise insider access: Limit who can access non-hardened interfaces with model parameters.

Appendix 4.4 Insider threats

To protect against sabotage or internal theft (including by or through models):

• Personnel vetting: Conduct background checks on those with access to sensitive model data/systems.
• Insider threat awareness: Train staff to recognise and report insider threats.
• Prevent self-exfiltration by models: Use sandboxing and code execution isolation.
• Safeguard model training: Inspect training data for tampering or sabotage.

Appendix 4.5 Security assurance

To verify that security measures are effective, Signatories must:

• Use independent external reviews if internal capacity is insufficient.
• Conduct red-teaming to identify security gaps in networks and facilities.
• Run bug bounty programs for public-facing endpoints where appropriate.
• Test insider mitigation protocols, including personnel integrity assessments.
• Facilitate issue reporting through secure third-party communication channels.
• Monitor systems actively with Endpoint Detection and Response (EDR) or Intrusion Detection Systems (IDS).
• Respond rapidly to threats using trained security teams for incident handling and recovery.

Applications are open until 14th of September.

Why join the Scientific Panel of Independent Experts?

The scientific panel plays an important role  in the enforcement of the EU AI Act, the most comprehensive AI governance framework globally.

The independent experts on the panel gain professional recognition and visibility as trusted advisors while influencing the development, deployment, and impact of advanced GPAI in Europe. Further, the panel is an opportunity to collaborate with and work alongside top experts from across the EU and beyond in a high-level, multidisciplinary setting. Perhaps most importantly, experts will engage in mission-driven, public-interest work that promotes the responsible and safe development and deployment of AI technologies in Europe.

Scientific panel tasks, powers and competences in more detail

Overview 

The Scientific Panel, established by the EU AI Act (Article 68 point 1), provides technical advice to the AI Office and national authorities on enforcing AI Act requirements for general-purpose AI models and systems. Key tasks include:

• Developing assessment tools and methodologies,
• Advising on model classification including systemic risk determination,
• Creating tools and templates, and
• Supporting market surveillance activities.

The panel can request information from AI model providers through the Commission while protecting trade secrets, and Commission experts may conduct model evaluations for the AI Office.

Qualified Alerts 

The panel can issue alerts (Article 90) that may require providers to conduct safety assessments and implement protective measures when models create EU-level risks, affect multiple member states, or meet systemic risk criteria (which are detailed in Article 51: requiring 10^25+ FLOPS to train, demonstrating high-impact capabilities, or equivalent capabilities based on parameters, dataset size, market reach of 10,000+ EU business users, etc.).

Alerts require simple majority approval and must include provider contact information, justification, and relevant facts. The AI Office has two weeks to process alerts and may designate models as systemically risky, subjecting providers to additional requirements (Article 55), including risk assessments, incident reporting, and cybersecurity obligations.

Structure and Composition 

The panel will comprise of up to 60 independent experts serving two-year renewable terms. Gender balance and geographical representation is ensured by having at least one expert per EU Member State and EFTA/EEA country (maximum three per country). At a minimum, 80% of the experts will be from EU/EFTA/EEA nations.

The structure includes a Secretariat for administrative support, a Chair and Vice-Chair for the full term, and compensated rapporteurs and contributors for specific tasks. The panel operates transparently by publicly sharing expert information, opinions, recommendations, and stakeholder hearing records while protecting confidential business information.

Selection Criteria

According to the AI Act experts must demonstrate:

• Multidisciplinary expertise – Up-to-date scientific, technical, or socio-technical knowledge related to AI systems, general-purpose AI models, or AI impacts relevant to enforcing the AI Act;
• Independence – No conflicts of interest with AI systems or general-purpose AI model providers;
• Impartiality and objectivity – Ability to work without bias as required by the AI Act;
• Professional capability – Ability to carry out work diligently, accurately, and objectively.

Required Expertise Areas

According to the call for applications, candidates must have substantiated expertise in at least one area:

• Model evaluation – Benchmarking, red teaming, human impact studies, deployment evaluations, fundamental rights assessments, economic impact analysis, AI capability forecasting;
• Risk assessment – Risk identification, analysis, modelling, evaluation, safety cases, risk taxonomies for AI and GPAI models;
• Technical mitigations – Safety fine-tuning, filters, guardrails, watermarking, data processing, risk management policies, scaling policies, incident response;
• Misuse and systemic risks – CBRN risks, population manipulation, loss of control, discrimination, public health/safety risks, fundamental rights risks;
• Cyber offence risks – Vulnerability exploitation, zero-day generation, social engineering, autonomous cyber operations, infrastructure targeting;
• Cybersecurity – Preventing model weight theft, unauthorised releases, safety measure circumvention;
• Emergent risks – Misalignment, deceptive behaviours, loss of control, emergent capabilities like self-replication;
• Compute measurement – Methodologies for measuring training compute, reporting frameworks, verification protocols.

Eligibility Requirements

• PhD in relevant field OR equivalent experience;
• Proven professional experience and scientific impact in AI/GPAI research or AI impact studies;
• Demonstrated independence from AI system or GPAI model providers.

Remuneration

Experts will be remunerated if they are appointed rapporteur or contributor for carrying out tasks that have been requested by the AI Office. The Commission may reimburse experts’ travel expenses and, if needed, subsistence costs related to panel duties, within available budget limits.

This resource will be regularly updated to reflect the latest training opportunities. If you offer or are aware of training programmes that promote AI literacy in line with Article 4 of the EU AI Act, please contribute to help us strengthen this living overview: taylor@futureoflife.org

How were the programs selected?

Each program included in this list was individually reviewed and selected based on the following criteria:

• Alignment with Article 4 of the EU AI Act – Programs must explicitly or demonstrably support the development of AI literacy in line with the regulation, including:
  • Understanding what AI is and how it works;
  • Awareness of the risks, benefits, and ethical considerations of AI;
  • Enabling informed human oversight and responsible use.
• Clear target audience – Programs are intended for professionals, organisations, or the general workforce (not limited to technical audiences).
• Accessible format – Online or blended learning, with reasonable duration and availability in the EU.
• Transparency – Publicly accessible descriptions, pricing (or clear “on request”), and duration.
• Geographic and sectoral diversity – Effort was made to include initiatives from different EU countries and provider types (public, private, legal, academic).

Submitting a program

If you provide program(s) that are designed to help users meet their AI Literacy obligations under the EU AI Act, we would love to include them in our database.

Submit a program

Database of AI Literacy programs

⚠️ This is a non-exhaustive selection based on publicly available information as of April 2025. No claims are made about legal compliance or endorsement. Readers are encouraged to verify details directly with each provider.

Author: Tânia Figueiredo is a strategic consultant and educator based in Lisbon, Portugal. With a background in business management and communications, she helps organisations — especially SMEs — adopt artificial intelligence responsibly and align with emerging EU regulations. Tânia leads AI training initiatives for professionals and companies, focusing on literacy, ethical implementation, and compliance with the EU AI Act.

This resource is a work in progress, and will be updated when new information is available. Please help us ensure the completeness and accuracy of this content by contributing any information you have about the authorities in your area: santeri@futureoflife.org.

AI regulatory sandboxes create controlled environments where AI systems can be developed and tested with regulatory guidance before market release. They improve legal certainty, support compliance, allow for processing of personal data, and facilitate market access for SMEs and startups. Importantly, the documentation from participating in a sandbox can be used to demonstrate compliance with the AI Act. Further, providers will not face administrative fines for infringements of the Act, as long as they follow the guidance of the national competent authority. Note that providers remain liable for damages to third parties caused by experimentation with AI systems in a sandbox.

Lessons from other fields highlight some potential positive impacts of regulatory sandboxes. For instance, companies that completed successful testing within the UK FCA sandbox received 6.6 times more fintech investment than their peers. Further, the UK FCA sandbox reduced the average time required for market authorisation by 40% compared to the regulator’s typical approval process.

The implementation status of the sandboxes varies significantly across Member States. Some, such as Denmark, have operational sandboxes and concrete plans, while others remain in early planning stages. Institutional approaches also differ: in some Member States, data protection authorities are leading the effort; elsewhere, new centralised AI agencies are being established. Some Member States are opting for decentralised models that coordinate existing regulators.

EU-wide support initiatives

At the EU level, several initiatives are underway to support the implementation of AI regulatory sandboxes across Member States. Their role is specified in the EU AI Act: Article 58(3) states that prospective providers in the AI regulatory sandboxes, in particular SMEs and start-ups, shall be directed, where relevant, to value-adding services such as Testing and Experimentation Facilities and European Digital Innovation Hubs. This connection is important because regulatory sandboxes are not intended solely for supporting compliance with the AI Act, but also to foster the development and testing of AI systems. This includes providing innovators with access to training, technical expertise, and infrastructure. Since the EU has already invested substantial funding for these purposes, it is important to ensure connections between regulatory sandboxes and existing instruments.

The EU Regulatory Sandboxes for AI (EUSAiR)

One of the key initiatives is the EU Regulatory Sandboxes for AI (EUSAiR), a two-year project funded by the European Union’s Digital Europe programme working in cooperation with the AI Office. EUSAiR aims to support the implementation of AI regulatory sandboxes by developing common frameworks, enhancing technical and legal capacities, and promoting collaboration among Member States. It aims to provide broad access to sandboxes for AI innovators, especially SMEs and startups, by lowering compliance costs and easing entry barriers to the market.

Testing and Experimentation Facilities (TEFs)

The EU has established specialised Testing and Experimentation Facilities (TEFs) that offer large-scale reference sites where technology providers across Europe can test state-of-the-art AI solutions in real-world environments. These projects will receive over €220 million in combined funding from the European Commission and Member States for a five-year period. These facilities support supervised testing and experimentation in cooperation with national authorities and can contribute to the implementation of regulatory sandboxes. Four sector-specific TEFs have been established:

• Agri-Food: project ‘agrifoodTEF’
• Healthcare: project ‘TEF-Health’
• Manufacturing: project ‘AI-MATTERS’
• Smart Cities & Communities: project ‘Citcom.AI’

European Digital Innovation Hubs (EDIHs)

European Digital Innovation Hubs (EDIHs) are regional one-stop shops that help companies and public sector organisations respond to digital challenges and improve their competitiveness. They offer access to technical expertise and testing (as well as a possibility to ‘test before invest’), innovation services (such as financial advice), and skills development. There are over 150 hubs operating across the EU.

The 2025 AI Continent Action Plan highlights the role of the EDIH network in facilitating companies’ access to regulatory sandboxes. It also mentions that EDIHs will expand their offering of practical AI training courses tailored to various technical and non-technical backgrounds. 

National implementation approaches

The AI Act gives Member States considerable flexibility in designing their regulatory sandboxes. Some Member States are creating centralised approaches with dedicated AI agencies, while others are adopting decentralised models that leverage existing regulatory bodies. Even where a Member State has yet to announce sandbox plans, responsibility rests with its national competent authority under the AI Act. Overview of all national implementation plans, including competent authorities, can be found here.

This resource tracks each Member State’s approach to implementing AI regulatory sandboxes, examining key aspects including:

• Overview: The current status and general approach to AI regulatory sandboxes.
• Key actors: Organisations responsible for sandbox design, implementation, and oversight.
• Legal framework: Laws, regulations, and policies establishing and governing the sandbox.
• Operational structure: How the sandbox functions, including the admission process, testing process, and the assistance provided.

The resource builds upon Nathan Genicot’s report ‘From Blueprint to Reality: Implementing AI Regulatory Sandboxes under the AI Act’ (2024).

This content is outdated – Draft guidelines have now been published by the AI Office, which you can learn more about here.

On 22 April 2025, the AI Office published preliminary guidelines clarifying the scope of the obligations for providers of GPAI models. These outline seven topics that are expected to be covered in the final guidelines along with some preliminary answers. The Commission also opened a consultation for input on the guidelines from stakeholders. 

This post gives an overview of why the category of GPAI model provider matters and summarises the content of the preliminary guidelines as of April 2025.

The value chain of general-purpose AI is notoriously complex and defining appropriate categories for entities across the value chain was no easy feat during the AI Act drafting process.¹ The AI Act lays down different obligations for providers of general-purpose AI models (GPAI models) and providers of AI systems including general-purpose AI systems (GPAI systems). Therefore, it will be important for actors developing, building on or integrating GPAI models to identify if and when they may qualify as a provider of such a model, as opposed to a downstream provider or deployer of an AI system.

Why the GPAI model provider category matters

The AI Act lays down particular obligations for providers of general-purpose AI models (GPAI models) in Article 53. These include keeping up-to-date model documentation and implementing a copyright policy. Providers of so-called GPAI models with systemic risk (GPAISR models) must comply with Article 53 as well as Article 55. The latter entails conducting model evaluations, adversarial testing, tracking and reporting serious incidents, and ensuring cybersecurity protections. How actors can comply with these obligations in practice is being detailed in the Code of Practice, as explained in another blog post. In contrast, downstream actors like system providers, deployers, importers, etc. are not subject to these obligations. Rather, these actors should consider whether the risk-based obligations under Articles 5, 16-27 and 50 apply.

1) What is a GPAI model?

A ‘general-purpose AI model’ is defined in Article 3(63) as an AI model that displays significant generality and is capable of competently performing a wide range of distinct tasks. Further, it can be integrated into a variety of downstream systems or applications.² The model release mode (open weights, API, etc.) does not matter for the sake of this definition, except if the model is solely used for research, development or prototyping activities prior to market placement.³ Recital 97 emphasises that while AI models may be essential parts of AI systems they do not constitute AI systems in themselves, as models require further components, such as a user interface, to become AI systems.

The preliminary approach of the AI Office is to set a threshold in terms of computational resources used to train or modify a model (training compute). In particular, the AI Office proposes to combine the number of parameters and the amount of training data into one number. If a model that can generate text and/or images uses training compute greater than 10^22 floating point operations (FLOP), the AI Office would presume that it is a GPAI model.

The AI Office sees the pre-training run as the beginning of a lifecycle for GPAI models. Later in the lifecycle GPAI models can be ‘modified’, including through ‘fine-tuning’. Such modifications can be carried out by the same entity that provided the original GPAI model or by ‘downstream modifiers’. In Recital 97, the AI Act states that GPAI models ‘may be further modified or fine-tuned into new models’. This begs the question: what kinds of modifications will qualify as a new GPAI model? The preliminary guidelines give us answers, both with regards to the same entity and downstream modifiers (see section 2). 

Modification by the same entity providing the original GPAI model: are considered to lead to a distinct model if those modifications use more than ⅓ of the compute required for a model to be presumed to be a GPAI model. With the current thresholds, that would be 3*10^21 FLOP. 

2) Who is the provider of a general-purpose AI model, and when is a downstream modifier a provider?

Under Article 3(3), ‘providers’ are natural or legal persons, public authorities, agencies, or other bodies that develop an AI system or a GPAI model or have such a system or model developed and place it on the market under its own name or trademark, whether for payment or for free.⁴ Thus, under the AI Act, a provider can provide two kinds of products – AI systems or GPAI models. The obligations of the provider hinge on whether their product qualifies as a system or a model. The preliminary document is only concerned with providers of GPAI models, including GPAI models with systemic risk, and not with providers of AI systems.

Modifications by a downstream modifier: The AI Office suggests that only those modifications that have a significant bearing on the rationales behind the obligations for GPAI models should lead to the downstream modifier being considered a provider of a new GPAI model. For example, for GPAI models with systemic risk, only modifications leading to a significant change in systemic risk should make downstream modifiers providers of GPAI models with systemic risk. To provide concrete guidance and increase legal certainty, the AI Office proposes computational thresholds with related presumptions of provider status.

GPAI models: a downstream modifier is presumed to be the provider of a GPAI model if the modifications exceed ⅓ of the compute required for a model to be presumed to be a GPAI model. With the current thresholds, that would be 3*10^21 FLOP. This is similar to the threshold for the same entity providing the original model. However, the provider obligations are limited to the modification conducted in line with Recital 109 in the AI Act.

GPAI models with systemic risk:⁵ here the AI Office proposes two conditions of which only one has to be met.

1. When the original model is presumed to be a GPAI model with systemic risk, a downstream modifier is presumed to become a provider if the amount of compute is greater than ⅓ of the compute threshold for a model to be presumed to be a GPAI model with systemic risk. With the current threshold, that is 3*10^24 FLOP.
2. When the original model was not a GPAI model with systemic risk, a downstream modifier is presumed to become a provider if the cumulative amount of compute from the original model and the modification exceeds the threshold for presumption that a model is a GPAI model with systemic risk. The current threshold is 10^25 FLOP. 

As of today, the AI Office assumes that no downstream modification significantly changes systemic risk. The AI Office further assumes that few or no modifications meet the specified threshold. The threshold in point 1 is thus forward-looking and in line with the risk-based approach of the AI Act.

Note that if a downstream modifier of a GPAI model becomes the provider of a GPAI model with systemic risk based on one of the above criterions, then its obligations are not limited to the modification conducted. 

3) What constitutes a placing on the market of a general-purpose AI model, and when do the open-source exemptions apply?

The AI Office provides a list of examples of what qualifies as placing a GPAI model on the market, including making it available through software libraries, application programming interfaces (APIs), cloud computing services, and similar distribution channels.

The preliminary guidelines also clarify when the exemptions for certain open-source releases apply by proposing definitions for the central concepts of ‘access’, ‘usage’, ‘modification’, ‘distribution’, and ‘free and open-source’. The document highlights that GPAI models with systemic risk are not exempt regardless of their release method.

4) Estimating the computational resources used to train or modify a model

Several of the above topics rely heavily on estimations of the computational resources used to train or modify a model (i.e., compute). Therefore, it is important that the preliminary guidelines include a section on estimating compute. The AI Office proposes two approaches: the hardware-based approach and the architecture-based approach. These are explained with formulas and with concrete examples from the industry in Annex A.1. 

What should be counted: the preliminary guidelines propose that the cumulative training compute is restricted to activities and methods carried out as part of the training of the model or directly feeding into the training. It thus excludes activities that are prior to the large pre-training run or which improve the model’s capabilities at inference time.

When should compute be counted: the AI Office expects providers to estimate the amount of pre-training compute ahead of commencing their large pre-training run and notify the Commission accordingly within two weeks of the estimate.

5) Transitional rules, grandfathering, and retroactive compliance

The AI Office recognises that the GPAI obligations in the AI Act can present challenges for companies who want to comply, especially in the early stages. The preliminary approach of the AI Office is to encourage GPAI model providers to enter into dialogue and get support from the AI Office early if they foresee difficulties in complying. For example, when companies are to provide a GPAI model with systemic risk for the first time on the European market, the AI Office will give special consideration to their challenging situation and in setting any deadlines. 

6) Effects of adherence to and signature of the Code of Practice

The preliminary approach of the AI Office indicates that signatories to the Code of Practice will benefit from increased trust by the Commission. Further, commitments under the Code of Practice may be taken into account as a mitigating factor when fixing the amount of fines. 

Non-signatories must demonstrate how they comply with their obligations under the AI Act via other adequate, effective, and proportionate means. They may also be subject to more requests for information and access to conduct model evaluations, since there will be less clarity regarding how they ensure compliance.

7) Supervision and enforcement of the general-purpose AI rules

The AI Office is in charge of supervising and enforcing obligations related to providers of GPAI models. The preliminary guidelines emphasise a collaborative and proportionate approach. This includes close informal cooperation with providers during the training to streamline compliance and ensure market placement without delays, especially for providers of GPAI models with systemic risk. The AI Office expects that providers of GPAI models with systemic risk report proactively without requests. 

The road ahead to increased clarity

The preliminary guidelines are an important first step, confirming that downstream industry is out of scope for obligations relating to GPAI models with systemic risk with the current thresholds. No publicly available model meets the modification threshold of one third of the GPAI model classification thresholds. With this targeted approach to GPAI models, the Commission weeds out central uncertainties and assures European downstream companies that they are unlikely to be in scope for the Code of Practice.

The guidelines are expected to evolve over time and will be updated as necessary, in particular in light of evolving technological developments. As the obligations for GPAI model providers begin to apply from 2 August 2025, pragmatic and cooperative enforcement by the AI Office of Article 53 and 55 will bring more clarity. Ultimately, the authoritative interpretation of the AI Act may only be given by the Court of Justice of the European Union.

Notes & References

1. The categories changed several times during the drafting. For example, the notion of ‘user’ was included in the original Commission proposal but has been replaced with the notion of ‘deployer’ in the final AI Act and the notion of ‘small-scale provider’ was removed altogether. Further, ‘downstream provider’ did not appear in any of the proposals from the three EU institutions and only appeared in the final version. ↩︎
2. Article 3(63) ↩︎
3. Recital 97 ↩︎
4. Article 3(3) ↩︎
5. Under Article Article 3(65), ‘systemic risk’ is defined as specific to the high-impact capabilities of GPAI models, having a significant impact on the Union market. This could be due to their reach or due to actual or reasonably foreseeable negative effects on public health, safety, public security, fundamental rights, or the society as a whole, that can be propagated at scale across the value chain. Models are presumed to qualify as having high impact capabilities when the cumulative amount of computation used for its training is greater than 10(^25) floating point operations (FLOP). This is a rebuttable presumption that does not automatically qualify models. Currently, it is estimated that 11 providers worldwide provide models that surpass this threshold. ↩︎

The AI Act has a particular focus on small and medium-sized enterprises (SMEs). This group of stakeholders is mentioned 38 times in the Act compared to 7 mentions of ‘industry’ and 11 mentions of ‘civil society’. More importantly, the EU AI Act has a range of measures that are specifically designed to support and simplify SME compliance with the product safety rules of the AI Act.

The category of ‘SMEs’ under EU law

Under EU law, SMEs are an overarching category of enterprises consisting of three subcategories. Medium-sized enterprises have less than 250 employees and an annual turnover of less than €50 million and/or not more than €43 million on their annual balance sheet. Small enterprises employ less than 50 persons and have an annual turnover and/or balance of less than €10 million. Microenterprises employ less than 10 persons and have an annual turnover and/or balance of less than €2 million. Note that the AI Act explicitly mentions start-ups as part of SMEs throughout the act, even though there is currently no separate or single definition of a start-up under EU law.

AI Act provisions tailored to SMEs

Regulatory sandboxes

All Member States will adopt at minimum one national regulatory sandbox. Regulatory sandboxes are used to test innovative products, technologies and services for a limited time under regulatory supervision outside normal regulatory structures. The concept is used in a range of industries including fintech, transport, energy, telecoms and health, in many different jurisdictions including the UK, Japan and Singapore. With regard to the AI Act, a regulatory sandbox is a framework that lets providers of AI systems lawfully develop, train, validate and test novel AI systems by following a sandbox plan agreed between the provider and the supervising authority. These sandboxes could be physical, digital, or hybrid. Testing in real world conditions may also be facilitated through the framework of AI regulatory sandboxes. The sandboxes are designed to support innovation by enabling a controlled experimentation environment to demonstrate compliance, increasing legal certainty for both innovators and authorities, and removing barriers to access markets for SMEs.

The documentation from participating in a sandbox can be used to demonstrate compliance with the AI Act. Further, if the prospective providers observe the sandbox plan and terms and conditions and follow in good faith the guidance of the national competent authority, they will not face administrative fines for infringements of the Act. Note that providers in the AI regulatory sandboxes are not exempt from liability for damages to third parties caused by experimentation with AI systems in a sandbox.

SMEs will have priority access to sandboxes. Moreover, these sandboxes shall be free of charge for SMEs and the procedures for application, selection, participation, and exiting the sandboxes shall be simple, easy to understand and communicated in a clear way. 

Examples of sandboxes: Several EU countries have already established AI sandboxes, including Luxembourg, Spain and Lithuania. While these sandboxes are nascent, lessons from other fields indicate some of the potential positive impacts of sandboxes. For example, companies that completed successful testing with the UK FCA sandbox received 6.6 times higher fintech investment. Further, compared with the regulator’s standard authorisation time, the UK FCA sandbox increased the average speed for market authorisation by 40%.

Reducing compliance costs and fees

The AI Act is focussed on limiting compliance costs for small actors, for example by requiring that national conformity assessment fees shall consider the needs of SME providers and ensure that those fees are proportional to the size, market size and other relevant factors. The European Commission will also carry out assessments of compliance costs for SMEs and collaborate with Member States to lower these costs. For example, with regard to translation costs related to mandatory documentation, Member States should try to ensure that they accept documentation and communication in languages broadly understood by the largest possible number of cross-border deployers.

In relation to fines, the Act sets the upper bound of fines based on whichever is higher – a fixed amount or a fixed percentage of total worldwide turnover. However, in the case of SMEs, the upper bound is set by whichever is lower.

Participation in standard setting and governance

Standards are an important part of any product safety legislation in the EU, and the AI Act is no exception. To ensure that the perspectives of SMEs are duly weighed in the standard setting process, the Commission and Member States must facilitate the participation of SMEs in the standardisation development process. 

The AI Act also ensures representation of SMEs in the AI Act implementation. For example, SMEs must be represented in the advisory forum, a body which advises and provides technical expertise to the European AI Board and the Commission.

Simplified documentation and targeted training

To simplify the technical documentation of high-risk AI systems for SMEs, the Commission will develop special, simplified technical documentation forms for the needs of small and microenterprises. These will be accepted by national authorities for the purposes of conformity assessments. With regard to microenterprises, certain elements of quality management systems for high-risk AI systems may be complied with in a simplified manner. Further, Member States must organise awareness raising and training activities tailored to SMEs regarding the application of the AI Act to support SMEs in understanding and complying with the AI Act.

Dedicated SME communication

Member States shall ensure dedicated communications channels for SMEs and other relevant actors, like local public authorities, to support SMEs throughout their development path. This support includes providing guidance and responding to queries about the implementation of the AI Act, ensuring synergies and homogeneity in the guidance to SMEs. Several Member States have already established relevant information channels, for example the Austrian Service Desk for AI.

Proportional obligations for SME providers of general-purpose AI models

Another aspect of the AI Act designed to support SMEs is the principle of proportionality. For providers of general-purpose AI models, the obligations should be “commensurate and proportionate to the type of model provider”. General-purpose AI models show significant generality, are capable of competently performing a range of different tasks, and can be integrated into a range of downstream systems or applications (Art. 3(63) AIA). The way these are released on the market (open weights, proprietary, etc) does not affect the categorisation.

A small subset of the most advanced general-purpose AI models are the so-called ‘general-purpose AI models with systemic risk’. That is, models trained using enormous amounts of computational power (more than 10^25 FLOP) with high-impact capabilities that have significant impact on the Union market due to their reach or negative effects on public health, safety, public security, fundamental rights or society as a whole (Art. 3(65) AIA). According to Epoch, there are only 15 models globally that surpass the compute threshold of 10^25 FLOP as of February 2025. These include models like GPT-4o, Mistral Large 2, Aramco Metabrain AI, Doubao Pro and Gemini 1.0 Ultra. Examples of smaller general-purpose AI models that would likely not qualify as having systemic risk include GPT 3.5, the models developed by Silo AI, Aleph Alpha’s Pharia-1-LLM-7B or Deepseek-V3.

The obligations of providers of general-purpose AI models and general-purpose AI models with systemic risk are laid down in Article 53 and 55 of the AI Act respectively, and fleshed out in the Code of Practice. Providers of general-purpose AI models have certain transparency obligations. Providers of general-purpose AI models with systemic risk have additional obligations to evaluate and test models, assess and mitigate possible systemic risk, carry out incident reporting and ensure adequate levels of cybersecurity. The Code is currently being drafted in an extensive multi-stakeholder process, so the final shape is yet to be determined. Because of the principle of proportionality, the Code should take due account of the size of the general-purpose AI model provider. This is recognised, for example, in the current second draft as one of the seven high-level principles, and is reflected in separate Key Performance Indicators for SMEs compared to larger companies.

Important note: For the purpose of compliance by downstream providers and deployers who are building applications or otherwise integrating general-purpose AI models into AI systems, the distinction between general-purpose AI models and general-purpose AI models with systemic risk does not matter. Here, the only thing that matters is the intended use of their AI system and whether this use falls under the scope of any of the risk categories in the AI Act: prohibited systems, high-risk systems, or systems with special transparency obligations. This will be the case for the vast majority of SMEs in the EU.

It all depends on implementation

Ultimately, the effects and ease of compliance for SMEs depend as much on the implementation of the AI Act as on the text itself. There are different resources that can help readers track implementation, including:

• The compilation of Guidance documents from the European Commission;
• The overview of national implementation plans;
• The AI Act compliance checker, which can help to start initial considerations about compliance with the AI Act.

The salary for this role is around €4100-8600 a month (limited taxes).

You can find out more and apply here: Legal Officer | Policy Officer

Skills required:

A candidate for the Policy Officer position should possess a minimum of three years of experience in EU digital policies, strong analytical and research skills, as well as the ability to translate findings into actionable policies.

A candidate for the Legal Officer position should hold a minimum of three years of experience in EU digital legislation and excellent analytical and communication skills.

Eligibility requirements:

• Must be a citizen of one of the Member States of the European Union
• Knowledge of one of the EU languages and a satisfactory knowledge of another of the EU languages
• University degree or diploma

A very important job opening has opened up at the European AI Office: They are hiring for the Lead Scientific Advisor for AI.

Application deadline is 13 December 2024.

Based on the European Union Employment Advisor, the monthly basic salary for this role (level AD13) is about 13,500-15,000 euros.

You can apply here.

“The Lead Scientific Adviser for AI should ensure an advanced level of scientific understanding on General-Purpose AI. They will lead the scientific approach on General-Purpose AI on all aspects of the work of the AI Office, ensuring scientific rigor and integrity of AI initiatives. They will particularly focus on the testing and evaluation of General-Purpose AI models, in close collaboration with the ‘Safety Unit’ of the AI Office.”

Eligibility requirements:

• Must be a citizen of one of the Member States of the European Union
• University degree or diploma
• Professional experience of at least 15 years
• Knowledge of one of the EU languages and a satisfactory knowledge of another of the EU languages
• Must not have reached regular retirement age

Read more about the role in the Vacancy Notice on this webpage.

Since the AI Act entered into force on the 1st of August, it has become crunch time for Member States to prepare the implementation of the Act. One of the first aspects of national implementation is to designate authorities. This post gives an overview of the national authorities to be designated under the AI Act and what we know about the national implementation plans.*

This resource is a work in progress, and will be updated when new information is available. Please help us ensure the completeness and accuracy of this content by contributing any information you have about the authorities in your area: tekla@futureoflife.org.

*Note: The AI Act has been proposed with possible EEA relevance and is currently under scrutiny by the EEA EFTA for incorporation into the EEA Agreement. Norway, Liechtenstein and Iceland are participating in AI Board meetings as observers. For completeness, we’ve included all three EEA EFTA states in the overview.

Three types of authorities in Member States under the AI Act

Member States are required to designate or establish three kinds of authorities as part of the implementation of the EU AI Act.

Market Surveillance Authority

First, a ‘market surveillance authority’ shall carry out activities and take measures known from Regulation (EU) 2019/1020 on market surveillance and compliance of products (Art 3(26)). Thus, this authority builds upon the pre-existing and well-established concept of market surveillance authorities within EU law and will be tasked with ensuring that only products compliant with EU law are made available on the Union market.

Notifying Authority

Second, a ‘notifying authority’ will be the national authority responsible for establishing and performing the procedure for assessment, designation and notification of conformity assessment bodies and for their monitoring (Art 3(19) and Art 28(1)). ‘Conformity assessment bodies’ are bodies that perform third-party conformity assessment activities, including testing, certification and inspection (Art 3(21)).

The notifying authority and the market surveillance authority are collectively referred to as the national competent authorities (Art 3(48)). They must function independently, impartially and without bias, have adequate technical, financial and human resources, as well as the infrastructure to effectively execute their tasks under the AI Act (Art 70(1)&(3)). The Commission will facilitate exchange of experience between national competent authorities (Art 70(7)). 

National Public Authority

Third, Member States must identify national public authorities that enforce the respect for fundamental rights obligation in Member States in relation to High-risk AI systems referred to in Annex III. Such authorities should have powers to request and access any documentation created or maintained under the AI Act, when such documentation is necessary to effectively fulfill their mandate within the limits of their jurisdiction (Art 77 (2)).

Wide discretions for Member States

The AI Act gives Member States discretion with regards to the structure and design of these three types of authorities. Accordingly, Member States have proposed or designated authorities that take a range of forms. For example, Spain has established a Spanish Artificial Intelligence Supervisory Agency (AESIA) acting as a single market surveillance authority under the Spanish Department of Digital Transformation. In contrast, Finland has proposed a decentralized model appointing 10 already existing market surveillance authorities, including the Energy Authority, The Transport and Communications Agency, and the Medicines Agency.

Timelines and status of implementation

See our full Implementation Timeline for all key dates and deadlines for the AI Act.

Member States must establish or designate competent authorities by the 2nd of August 2025 (Art 113(b)). As per the date this post was last updated, three Member States have designated both notifying and market surveillance authorities (‘clear’ in the table below). To our knowledge, ten Member States have pending legislative proposals or have appointed one competent authority (‘partial clarity’), whereas 14 Member States have yet to designate or establish any competent authority.

With regards to authorities protecting fundamental rights, Member States were required to publish a list of such authorities by 2 November 2024 (Art 77 (2)). The Commission has published a consolidated list of all identified authorities that is continuously updated. There are currently two Member States, Hungary and Italy, that have not yet designated authorities as per the time this post was last updated.

Table 1: Overall status of National Authorities

Table 2: Member States and their designated National Authorities

Crosspost from: The AI Act: responsibilities of the European Commission (AI Office) by Kai Zenner. We have reformatted the content for web and performed some editing for readability.

Tasks in 2024-2025

See a timeline of all key tasks required by the EU AI Act in 2024 and 2025, with references to the sources.

Tasks: AI Office | Tasks: EU Member States

Since the technical negotiations on the AI Act have been concluded in January 2024, I hear very different numbers and deadlines when it comes to secondary legislation but also other implementing and enforcement tasks for the EU and national level. The Commission, for instance, stated on panels that they have to draft around 70 implementing and delegated acts. At the same time, many external stakeholders mentioned contradicting deadlines for templates and guidelines. So, I spent the last two weeks reading the AI Act (and the Decision to establish an AI Office), while identifying all the obligations that the law gives the Commission and the respective time frames to fulfil those tasks.

The result: the estimates mentioned above are not so far off. The slow buildup of the AI Office and its bureaucratic procedures will make it moreover very hard to meet the tight deadlines stated in the AI Act. In total, I have identified 130 responsibilities for the Commission:

• Table A: 39 tasks with the aim to establish an AI governance system, to be executed between 21 February 2024 until 02 August 2026.
• Table B: 39 pieces of secondary legislation, some of which feature clear deadlines while others depend on the Commission’s discretion. They can be divided into:
  • 8 Delegated Acts;
  • 9 Implementing Acts;
  • 9 guidelines;
  • 8 templates / benchmarks;
  • 2 Codes of Practice;
  • 2 categories of Codes of Conducts;
  • 1 standardization request.
• Table C: 34 categories of enforcement activities on EU level, some of them will start on 2 February 2025.
• Table D: 18 tasks with the aim to conduct ex-post evaluation of the law, to be executed between 2025 and 2031.

I hope that this list is helpful for civil society, academics, and SMEs that do not have the necessary resources to monitor the implementation and enforcement of the AI Act on the EU level. These tables should allow them to identify their key priorities and to focus their activities with regards to monitoring the European Commission.

Introductory Remarks

1. Transition periods

According to Article 113, the EU AI Act enters into force on 1 August 2024, which is twenty days after its publication in the Official Journal of the European Union on 12 July 2024.

Consequently, the new law becomes applicable on 2 August 2026, which is twenty-four months from the date of the entry into force.

See here for a full implementation timeline which includes all key milestones listed here, and more.

There are however three special transition periods for certain categories of articles in the AI Act:

• Six months from the date of the entry into force of the AI Act (2 February 2025) Chapter I (Article 1 – 4 [Introduction]) and Chapter II (Article 5 [Prohibitions]) will apply.
• Twelve months from the date of the entry into force of the AI Act (2 August 2025) Chapter III (Article 28 -39 [Notified bodies]), Chapter V (Article 51 – 56 [GPAI]), Chapter VII (Article 64 – 70 [Governance]), Article 78 [Confidentiality], and Art 99 – 100 [penalties] will apply.
• Thirty-six months from the date of the entry into force of the AI Act (2 August 2027) Article 6(1), Annex I, and the corresponding obligations will apply.

2. AI systems or GPAI models that are already placed on the market or are put into service

Article 111 lays down specific rules for AI systems and GPAI models that have been already placed on the market / put into service before the AI Act entered into force. It presents three cases:

• AI systems which are components of large-scale IT systems (Annex X) and that have been placed on the market / put into service before 2 August 2027 need to be compliant with the AI Act by 31 December 2030.
• All other high-risk AI systems that have been placed on the market / put into service before 2 August 2026 need to be compliant with the AI Act once they are subject to significant changes in their design. If the provider or deployer of that high-risk AI system is however a public authority, it needs to be compliant with the AI Act by 2 August 2030.
• GPAI models that have been placed on the market / put into service before 2 August 2025 need to be compliant with the AI Act by 2 August 2027.

All time frames in the third column of the tables below assume that the AI system has been place on the market / put into service after 2 August 2026 or that the GPAI model has been placed on the market / put into service after 2 August 2025.

3. The role of the AI Office 

According to Article 3(47), the AI Office stands for the Commission’s function of contributing to AI governance as well as the implementation, monitoring and supervision of AI systems and GPAI models provided for in the Commission Decision of 24 January 2024. The definition also states that all references in the law to the AI Office shall be understood as references to the European Commission. 

The reader might ask why the AI Act features both terms, in particular since the AI Office should become the new single-point-of-contact for AI within the Commission. The reason is that the term was only added to the legal text during the trilogue negotiations, in an AI governance system that knew so far only the Commission and the AI Board. According to the political agreement in December 2023, the AI Office would have been integrated in that AI governance system, yet being only responsible for Chapter V (GPAI models). Unfortunately, its competences have been afterwards extended to many other parts of the AI Act.

The result is—at best—legal confusion. It might also lead to the exclusion of other departments of the Commission in the implementation and the enforcement of the AI Act. Since the ‘AI Board’ was replaced by the ‘AI Office’ in many chapters (also after the political agreement), the Member States have (probably without realizing) given up many of their competences as they are represented by the AI Board but not by the AI Office. 

Responsibilities and Time Frames

These tables can also be viewed as an infographic (courtesy of Simone Mohrs).

If you found this post useful, you may also wish to see our post on the responsibilities of the EU Member States.

Corrections: Please let us know if you find any mistakes. Due to the complexity of this project some details may have been overlooked. This post will be updated according to new information and user feedback.

Crosspost from: The AI Act: responsibilities of the EU Member States by Kai Zenner. We have reformatted the content for web and performed some editing for readability.

Tasks in 2024-2025

See a timeline of all key tasks required by the EU AI Act in 2024 and 2025, with references to the sources.

Tasks: AI Office | Tasks: EU Member States

Since the technical negotiations on the AI Act have been concluded in January 2024, I hear very different numbers and deadlines when it comes to secondary legislation and other implementing and enforcement tasks on the EU and national level. No one seems to know what role the AI Office, Member States, and public authorities have to play from now on. So, I spent the last two weeks reading the AI Act, while looking for the obligations that the law gives to Member States and the respective time frames to fulfil those tasks.

The result: similar to the AI Office, the national level faces many new obligations with sometimes very tight deadlines. In total, I have identified 88 responsibilities for the national level:

• Table A: 18 tasks with the aim to establish an AI governance system, to be executed between 2 November 2024 until 2 August 2026.
• Table B: 7 items of either new national laws and of secondary legislation that Member States could introduce or where they may support the Commission. Some of those items feature clear deadlines, others depend on the Member States’ discretion.
• Table C: 55 categories of enforcement activities on national level, some of them will need to be executed already from 2 February 2025 onwards.
• Table D: 8 tasks with the aim to conduct ex-post evaluation of the AI Act, to be executed between 2025 until at least 2031.

I hope that this list is helpful for civil society, academics, and SMEs that do not have the necessary resources to monitor the implementation and enforcement of the AI Act on the EU level. These tables should allow them to identify their key priorities and to focus their activities with regards to monitoring Member States.

Introductory Remarks

1. Transition periods

According to Article 113, the EU AI Act enters into force on 1 August 2024, which is twenty days after its publication in the Official Journal of the European Union on 12 July 2024.

Consequently, the new law becomes applicable on 2 August 2026, which is twenty-four months from the date of the entry into force.

See here for a full implementation timeline which includes all key milestones listed here, and more.

There are however three special transition periods for certain categories of articles in the AI Act:

• Six months from the date of the entry into force of the AI Act (2 February 2025) Chapter I (Article 1 – 4 [Introduction]) and Chapter II (Article 5 [Prohibitions]) will apply.
• Twelve months from the date of the entry into force of the AI Act (2 August 2025) Chapter III (Article 28 -39 [Notified bodies]), Chapter V (Article 51 – 56 [GPAI]), Chapter VII (Article 64 – 70 [Governance]), Article 78 [Confidentiality], and Art 99 – 100 [penalties] will apply.
• Thirty-six months from the date of the entry into force of the AI Act (2 August 2027) Article 6(1), Annex I, and the corresponding obligations will apply.

2. AI systems or GPAI models that are already placed on the market or are put into service

Article 111 lays down specific rules for AI systems and GPAI models that have been already placed on the market / put into service before the AI Act entered into force. It presents three cases:

• AI systems which are components of large-scale IT systems (Annex X) and that have been placed on the market / put into service before 2 August 2027 need to be compliant with the AI Act by 31 December 2030.
• All other high-risk AI systems that have been placed on the market / put into service before 2 August 2026 need to be compliant with the AI Act once they are subject to significant changes in their design. If the provider or deployer of that high-risk AI system is however a public authority, it needs to be compliant with the AI Act by 2 August 2030.
• GPAI models that have been placed on the market / put into service before 2 August 2025 need to be compliant with the AI Act by 2 August 2027.

All time frames in the third column of the tables below assume that the AI system has been place on the market / put into service after 2 August 2026 or that the GPAI model has been placed on the market / put into service after 2 August 2025.

3. The AI governance system on national level

Recital 153 / 154 and Article 70 underline that Member States play a key role in the application and enforcement of the AI Act. Each one of them should designate at least one notifying authority and at least one market surveillance authority as national competent authorities. The market surveillance authority or one of them should thereby act as single point of contact.

Member States can appoint any kind of public entity (i.e. competition authority, data protection authority, cybersecurity agency) to perform the tasks of the national competent authorities, in accordance with their specific national organizational characteristics and needs. For instance, Germany decided to appoint its Federal Accreditation Body (‘Deutsche Akkreditierungsstelle’) as notifying authority and its Federal Network Agency (‘Bundesnetzagentur’) as market surveillance authority.

The national competent authorities should exercise their powers independently, impartially and without bias, to safeguard the principles of objectivity of their activities and tasks and to ensure the application and implementation of the AI Act. The members of these authorities should refrain from any action incompatible with their duties and should be subject to confidentiality rules.

In Article 3, we find the legal definitions with regard to the national implementation and enforcement system. Point (19) defines that ‘notifying authority’ are the national authority responsible for setting up and carrying out the necessary procedures for the assessment, designation and notification of conformity assessment bodies and for their monitoring. Point (26) defines that ‘market surveillance authority’ are the national authority carrying out the activities and taking the measures pursuant to Regulation (EU) 2019/1020. Lastly, point (48) defines that ‘national competent authority’ are a notifying authority or a market surveillance authority.

This document lists the responsibilities of each Member State as well as its national competent authorities, meaning their designated notifying authority and market surveillance authority. It does not specify which of the entities is fulfilling the respective task.

Responsibilities and Time Frames

These tables can also be viewed as an infographic (courtesy of Simone Mohrs).

If you found this post useful, you may also wish to see our post on the responsibilities of the European Commission (AI Office).

Corrections: Please let us know if you find any mistakes. Due to the complexity of this project some details may have been overlooked. This post will be updated according to new information and user feedback.

As AI Act implementation gradually unfolds, it is important to understand the different mechanisms of enforcement included in the Regulation. One of the most important is the general-purpose AI Code of Practice, which was developed by the AI Office and a wide range of stakeholders.

This summary, detailing the Code of Practice for general-purpose AI model providers, was put together by Jimmy Farrell, EU AI policy co-lead at Pour Demain, and Tekla Emborg, Policy Researcher at Future of Life Institute. For further questions, please reach out to jimmy.farrell@pourdemain.eu. 

As AI Act implementation gradually unfolds, it is important to understand the different mechanisms of enforcement included in the Regulation. One of the most important is the general-purpose AI (GPAI) Code of Practice, which was developed by the AI Office and a wide range of stakeholders and published in July 2025.

Coming up in this post:

• Introduction
• Standards and the Need for a Code of Practice
  • Legal Requirements for the Code of Practice
• Brief Summary of Code of Practice Content
• Scope of the GPAI Model Provider Definition
  • GPAI Model Providers
  • GPAI Model with Systemic Risk Providers
• Signatures: Who Signed and What Does it Mean
• Enforcement of the Code of Practice
• Backstory: Drafting Process Paving the Road to the Code of Practice
  • Working Group Structure
  • Plenary
  • Chairs and Vice-Chairs

Introduction

This blog post explains the concept, process and significance of the Code of Practice, an AI Act tool to bridge the interim period between obligations for general-purpose AI (GPAI) model providers coming into force and the eventual adoption of harmonised European GPAI model standards. Following the publication of the final Code of Practice on 10 July, and the confirmation by the Commission and the AI Board of the adequacy of the final Code,  this post summarises the most important and up-to-date information. A comprehensive summary of the content of the Code is provided in another blog post.

Standards and the Need for a Code of Practice

Following the entry into force of the AI Act on 1 August 2024, obligations within the Regulation are phased-in gradually, as detailed in an earlier blog post, with provisions on prohibited AI systems in effect since February 2025 and provisions relating to GPAI models in effect since 2 August 2025. In the meantime, the complex process of developing harmonised European standards that operationalise AI Act obligations has begun. Whilst an official standardisation request has been adopted by the Commission and approved by CEN-CENELEC regarding standards for AI systems¹, an equivalent request on GPAI model standards is yet to be drafted. When such a standardisation request will be issued depends largely on how effectively the Code of Practice implements the relevant obligations under the AI Act. The standardisation process is detailed in a separate blog post. 

Under the AI Act, obligations for GPAI models, detailed in Articles 50-55, are enforceable twelve months² after the Act enters into force (2 August 2025). However, the European standardisation process, involving mostly³ the European Committee for Standardisation (CEN) and the European Committee for Electrotechnical Standardisation (CENELEC), often takes up to three years⁴. This process can last even longer with more technical standards, such as those for GPAI, and if drafted in coordination with International standards⁵, as prescribed in the AI Act⁶. The multi-stakeholder engagement and consensus building approaches characteristic of standards setting further prolong the time-line. Thus, GPAI model provider obligations are not likely to be operationalised as technical standards any time soon.

Legal requirements for the Code of Practice

Article 56 of the AI Act outlines the Code of Practice as a placeholder mode of compliance to bridge the gap between GPAI model provider obligations coming into effect (twelve months) and the adoption of standards (three years or more). While not legally binding, GPAI model providers can rely on the Code of Practice to demonstrate compliance with GPAI model provider obligations in Articles 53 and 55 until standards are developed. These obligations include⁷:

• Provision of technical documentation to the AI Office and National Competent Authorities
• Provision of relevant information to providers downstream that seek to integrate models into their AI or GPAI system (e.g. capabilities and limitations)
• Summaries of training data used
• Policies for complying with existing Union copyright law

For GPAI models with systemic risk (models trained above the threshold of 10^25 floating point operations, or FLOP), further obligations include⁸:

• State of the art model evaluations
• Risk assessment and mitigation
• Serious incident reporting, including corrective measures
• Adequate cybersecurity protection

Providers who do not demonstrate compliance with the Code of Practice will have to prove compliance to the above obligations to the Commission by alternative, possibly more burdensome and time-consuming means.⁹

Brief Summary of Code of Practice Content

Since the drafting process began in October 2024, three draft versions of the Code of Practice were published before the final version in July 2025. The drafting Chairs and Vice-Chairs have set up an interactive web-page with the full text, FAQ, and summaries. A comprehensive overview of the content of the Code is also provided in another blog post. Below you find a short summary.

Overall, the Code has three chapters. The first two, Transparency and Copyright, apply to all GPAI model providers. The third, Safety and Security chapter, only applies to providers of GPAI models with systemic risk (above the 10^25 FLOP threshold), currently a small group of 5-15 companies worldwide¹⁰. The Code lays down a total of 12 commitments – one for each of the two first chapters and 10 for the Safety and Security Chapter – and corresponding measures for how providers can live up to the commitments.

Transparency chapter (all GPAI model providers)

Under this chapter, signatories commit to maintaining up-to-date, comprehensive documentation for every GPAI model they distribute within the EU (except for models that are free, open-source, and pose no systemic risk). This documentation must follow a standardized Model Documentation Form, detailing licensing, technical specs, use cases, datasets, compute and energy usage, and more. This documentation should be securely stored for at least ten years and made available, upon request, to the AI Office and downstream users. Public release of this information is encouraged to promote transparency.

Copyright chapter (all GPAI model providers)

Signatories commit to develop and regularly update a robust copyright policy that clearly defines internal responsibilities and complies with legal standards. They must ensure that data collected via web crawling is lawfully accessible, respect machine-readable rights signals like robots.txt, and avoid accessing websites flagged for copyright infringement. Technical safeguards should minimize the generation of infringing content, and terms of service must clearly prohibit unauthorized use. A designated contact point must be provided for copyright holders to submit complaints, with efficient and fair processes for handling them. 

Safety and Security chapter (only GPAI model with systemic risk providers)

This chapter only concerns providers of GPAI models with systemic risk. Signatories must develop a state-of-the-art Safety and Security Framework before model release, outlining evaluation triggers, risk categories, mitigation strategies, forecasting methods, and organizational responsibilities. Systemic risks are to be identified through structured processes such as inventories, scenario analysis, and consultation with internal and external experts. Before progressing with development or deployment, signatories must evaluate whether identified risks are acceptable, applying defined risk-tier frameworks with built-in safety margins. A mandatory Safety and Security Model Report must be submitted prior to release and updated as risks evolve. To ensure organizational accountability, signatories must clearly assign oversight, ownership, monitoring, and assurance roles within their governance structures and ensure adequate resources, a strong risk culture, and protections for whistleblowers. Serious incidents must be promptly tracked, documented, and reported to regulators according to severity and tight deadlines. Finally, signatories are required to retain detailed records of safety and risk management activities for a minimum of ten years.

Scope of the GPAI Model Provider Definition

GPAI Model Providers

The Transparency and Copyright chapters of the Code are relevant to all providers of GPAI models. ‘General-purpose AI models’ are defined under the AI Act as models that display significant generality and are capable of competently performing a wide range of distinct tasks and that can be integrated into a variety of downstream systems or applications.¹¹ As an indicative criterion, the GPAI Guidelines suggest that models trained on more than 10^23 FLOP that can generate language, text-to-image or text-to-video are to be considered GPAI.¹² The model release mode (open weights, API, etc.) does not matter for the sake of the GPAI model definition, except when the model is used for research, development or prototyping activities prior to market placement.¹³ However, the release mode does matter for the applicable obligations as providers of GPAI models that are released under a free and open-source license are exempt from the obligations under Article 53 (1)(a) and (b).¹⁴ GPAI model providers are natural or legal persons, public authorities, agencies or other bodies that develop a GPAI model or have a GPAI model developed and place it on the market under its own name or trademark, whether for payment or for free.¹⁵

It is possible for a downstream modifier to become the provider of a GPAI model first provided by an upstream actor. The Commission guidelines suggest that this will only be the case if the modification leads to a ‘significant change in the model’s generality, capabilities, or systemic risk’.¹⁶ Such a change is presumed to happen if the downstream modifier uses more than one third compute for the modification relative to the compute used for the original model.¹⁷ If this value is unknown to the downstream provider, this threshold is replaced by one third of the threshold for the model being presumed to be a GPAI model, which is currently 10^23 FLOP.¹⁸ 

The GPAI Guidelines provide examples to clarify the scope. For instance, a model trained using more than 10^24 FLOP for the narrow task of increasing the resolution of images is not considered a GPAI model.¹⁹ While the model in the example satisfies the compute threshold, it can only competently perform a narrow set of tasks, so it is not considered general-purpose.

GPAI Model with Systemic Risk Providers

The Safety and Security chapter of the Code is relevant to entities providing GPAI models systemic risk. ‘Systemic risk’ is defined as specific to the high-impact capabilities of GPAI models, having a significant impact on the Union market.²⁰ This could be due to their reach or due to actual or reasonably foreseeable negative effects on public health, safety, public security, fundamental rights, or the society as a whole, that can be propagated at scale across the value chain. Models are presumed to qualify as having high impact capabilities when the cumulative amount of computation used for its training is greater than 10^25 FLOP. This is a rebuttable presumption. Currently, it is estimated that 11 providers worldwide provide models that surpass this threshold.

It is possible for downstream modifiers to become providers of a new GPAI model with systemic risk, based on similar considerations as outlined above for GPAI downstream modifiers. I.e. if the downstream modifier uses more than one third compute for the modification relative to the training compute for the original GPAI model with systemic risk, the downstream modifier becomes the provider.²¹ If the original amount of training compute is unknown to the downstream provider, the threshold is replaced by one third of the threshold for the model being presumed to be a GPAI model with systemic risk, which is currently 10^25 FLOP.

Providers of GPAI models with systemic risk can contest the classification by demonstrating that, despite surpassing the compute threshold, their model does not possess ‘high-impact capabilities’ that match or exceed the most advanced models.²²

Signatures: Who Signed and What Does it Mean

The Commission has published the signatory form, process description and a list of signatories on its website. The signatories include the majority of companies developing the most advanced GPAI models, with the notable exceptions of META and companies based in China. As per the date of this update, the following companies signed the Code of Practice:

• Accexible
• AI Alignment Solutions
• Aleph Alpha
• Almawave
• Amazon
• Anthropic
• Bria AI
• Cohere
• Cyber Institute
• Domyn
• Dweve
• Euc Inovação Portugal
• Fastweb
• Google
• Humane Technology
• IBM
• Lawise
• Microsoft
• Mistral AI
• Open Hippo
• OpenAI
• Pleias
• re-inventa
• ServiceNow
• Virtuo Turing
• WRITER

The GPAI Guidelines specify that providers of GPAI models (with systemic risk) can demonstrate compliance with their obligations under the AI Act by adhering to the Code of Practice, now that the AI Board and the AI Office have published their confirming assessments of the Code. For signatories, the Commission will focus their enforcement activities on monitoring adherence to the Code, show these increased trust, and may take commitments to the Code into account as mitigating factors when fixing the amount of fines.²³ Non-signatories, on the other hand, are expected to demonstrate compliance via other adequate means.²⁴ These may receive a larger number of requests for information, and will typically need to provide more detailed information.

Enforcement of the Code of Practice

The GPAI rules took effect on 2 August 2, 2025, meaning all new models released from that date must comply. However, the Commission’s enforcement actions – such as requests for information, access to models, or model recalls – will only begin a year later, on 2 August 2, 2026. This grace period gives providers time to work with the AI Office to ensure they meet the standards. For models released before 2 August 2, 2025, providers have until 2 August 2, 2027 to bring them into compliance.

According to the GPAI Guidelines, the Commission will take a collaborative, staged and proportionate approach to its supervision, investigation, enforcement and monitoring of the GPAI provisions.²⁵

The Commission may decide to approve of the Code by way of an implementing act, which would give it ‘general validity’ within the Union.²⁶ It is unclear whether the Commission will choose to do so and what the legal implications of such an implementing act would be.

Academics and civil society organisations, as well as independent experts involved in drafting the code, have pointed out that adequate enforcement of the Code would require substantially more resources and staff than currently allocated. In particular, almost a threefold increase, compared to mid-2025 levels, in the number of staff in the Regulation and Compliance unit and AI Safety units of the AI Office. It is not yet clear whether such resources will be allocated.

Backstory: Drafting Process Paving the Road to the Code of Practice

The drafting process began in October 2024 and included more than a thousand stakeholders, following an open call for expression of interest. These stakeholders provided written inputs on three different Code drafts. The participants included a range of actors including GPAI model providers, downstream providers, trade associations, academics, independent experts, and civil society organisations. This multi-stakeholder process was led by thirteen independent Chairs and Vice-Chairs. 

Working group structure

The Chairs divided the drafting into four different content categories in accordance with the GPAI model section of the AI Act:

• Working Group 1: Transparency and copyright-related rules

Detailing documentation to downstream providers and the AI Office on the basis of Annexes XI and XII to the AI Act, policies to be put in place to comply with Union law on copyright and related rights, and making publicly available a summary about the training content.

• Working Group 2: Risk identification and assessment measures for systemic risk

Detailing the risk taxonomy based on a proposal by the AI Office and identifying and detailing relevant technical risk assessment measures, including model evaluation and adversarial testing.

• Working Group 3: Risk mitigation measures for systemic risk

Identifying and detailing relevant technical risk mitigation measures, including cybersecurity protection for the general-purpose AI model and the physical infrastructure of the model.

• Working Group 4: Internal risk management and governance for general-purpose AI model providers

Identifying and detailing policies and procedures to operationalise risk management in internal governance of general-purpose AI model providers, including keeping track of, documenting, and reporting serious incidents and possible corrective measures.

Source: European Commission

Plenary

After each new draft iteration, the Chairs hosted plenary sessions to answer questions and allow for stakeholder presentations. The Plenaries were divided into four working groups, based on the different content categories outlined above, with only one representative allowed from each organisation in every working group. The “kick-off” plenary happened on 30 September 2024 – a virtual meeting featuring nearly a thousand attendees²⁷ across industry, rightsholders, civil society, and academia.²⁸ Three further plenaries took place for all working groups. In parallel to the four working groups, there were dedicated workshops featuring GPAI model providers and WG Chair/Vice-Chairs to inform each iterative drafting round, as these stakeholders were seen as the main addressees of the CoP. Further, there was a separate workshop for civil society organisations.

The early phases of the drafting process stuck to the timeline as initially set out. In the latter phase,  there was a two-week delay to the release of the third draft and plenary round, and a month delay in the publication of the final Code, presented in a  Closing Plenary on 3 July 2025 and published on 10 July.

Figure 1: CoP drafting process – Source: European Commission

Chairs and Vice-Chairs

The Chairs and Vice-Chairs were a crucial component of the Code of Practice drafting process. They were designated based on demonstrated expertise in relevant areas, ability to fulfill the role (time commitments and operational experience) and independence, referring to “no financial interest or other interest, which could affect their independence, impartiality and objectivity”. They were the “pen holders” responsible for collating the input from all stakeholders into one succinct Code of Practice. The Chairs, and their respective background, are listed below:

Working Group 1: Transparency and copyright-related rules

Working Group 2: Risk identification and assessment, including evaluations

Working Group 3: Technical risk mitigation

Working Group 4: Internal risk management and governance of General-purpose AI providers

The time commitment for these consequential positions was significant. However, for financial independence reasons, the Chair or Vice-Chair positions were all unpaid (this also applied to all Plenary participants), but they were supported by external contractors, namely a consortium of consultancies including French consultancy Wavestone.

Notes and references

1.  Standardisation request for AI systems ↩︎
2. Article 113(b) ↩︎
3.  The European Telecommunications Standards Institute (ETSI) may also be involved. ↩︎
4.  CEN-CENELEC ↩︎
5. ISO ↩︎
6.  Article 40(3) ↩︎
7.  Article 53 ↩︎
8.  Article 55 ↩︎
9.  Article 53(4) and 55(2) ↩︎
10.  Safety and Security FAQ ↩︎
11.  Article 3(63) ↩︎
12.  Commission Guidelines paragraph 17 ↩︎
13.  However, note that the release mode does matter for the applicable obligations as providers of GPAI models that are released under a free and open-source license are exempt from the obligations under Article 53 (1)(a) and (b) (see Article 53(2) and GPAI Guidelines chapter 4) ↩︎
14.  Article 53(2) and GPAI Guidelines chapter 4 ↩︎
15.  Article 3(3) ↩︎
16.  Commission Guidelines paragraph 62 ↩︎
17.  Commission Guidelines paragraph 63 ↩︎
18.  Commission Guidelines paragraph 64 ↩︎
19.  Commission Guidelines paragraph 20 ↩︎
20.  Article 3(65) ↩︎
21.  Commission Guidelines paragraph 63 ↩︎
22.  Article 52(2) ↩︎
23.  Commission Guidelines paragraph 94 ↩︎
24.  Commission Guidelines paragraph 95 ↩︎
25.  Commission Guidelines paragraph 102 ↩︎
26.  Article 56(6) ↩︎
27.  Number disclosed in Commission press release ↩︎
28.  Euractiv article discussing diversity of participants ↩︎

The AI Office’s tasks, powers and competences in more detail

Overview

• The European Commission has established the EU AI Office within Directorate-General CONNECT Directorate A to monitor, supervise, and enforce AI Act requirements on general-purpose AI (GPAI) models (and systems, the user-facing application, when it is the same provider as the model) across the EU.
• The AI Office will have 140 employees, including 60 current commission staff. The hope is to fill the remaining 80 positions by the end of 2025. Additional technology specialists, lawyers, economists, and administrators will be hired in the coming weeks and month.
• The AI Office will:
  • Analyse and raise awareness of emerging risks from GPAI development and deployment.
  • Conduct model evaluations.
  • Investigate non-compliance.
  • Produce voluntary codes of practice for model providers.
  • Lead international AI governance cooperation. 
  • Strengthen networks between the Commission, AI safety institutes in other jurisdictions, and the global scientific community, including through the EU Scientific Panel of Independent Experts. 
  • Support Member State enforcement cooperation and joint investigations.
  • Assist the Commission in preparing binding decisions and secondary legislation in relation to the AI Act.

Structure

The AI Act is the first horizontal hard regulation of its kind anywhere in the world. Unlike other AI safety institutes, such as in the US and UK, the AI Office has enforcement powers to compel non-compliant providers to take corrective measures. Its broader competences are reflected in its structure:

• Head of Office: Lucilla Sioli
• 5 units:
  • Excellence in AI and Robotics:
    • Headed by Cecile Huet.
    • This team will focus on R&D and the intersection of software and hardware.  
  • Regulation and Compliance:
    • Headed by Kilian Gross. 
    • This team will work closely with Member States to ensure a coherent application of the AI Act across the EU. 
  • AI Safety:
    • Leader has not been appointed.
    • This team will focus on model evaluations for GPAI models with systemic risk and will work with industry and other stakeholders to identify systemic risks and appropriate mitigation measures. 
  • AI Innovation and Policy Coordination:
    • Headed by Malgorzata Nikowska. 
    • This team will monitor trends and investments to foster innovation.
  • AI for Societal Good:
    • Headed by Martin Bailey.
    • This team will focus on beneficial applications, such as weather modelling, cancer diagnoses and digital twins for reconstruction.
• 2 advisors:
  • The Lead Scientific Advisor has yet to be appointed, but will focus on expertise for GPAI model oversight. 
  • Juha Heikkilä, The Advisor for International Affairs, will represent the AI Office in global conversations on convergence toward common approaches. 

Access to models for evaluations 

• The AI Office can request documentation and evaluation results from GPAI model providers to assess compliance. 
• If inadequate, it can initiate a structured dialogue to gather more information on internal testing, safeguards against systemic risks, and measures to mitigate systemic risks.
• If still insufficient, it can conduct model evaluations to assess compliance, or investigate systemic risks, especially after a qualified alert from the scientific panel, but also possibly following a compliant from a downstream deployer.
• Providers can be fined for failing to provide access. 
• The AI Office can also request providers to take corrective actions, implement mitigation measures for systemic risks, or restrict, recall, or withdraw models from the Single Market.
• The AI Office will develop tools, methodologies, and benchmarks for capabilities evaluations for GPAI models, particularly systemic models.

Leading on general-purpose AI standards globally through the codes of practice

• Between now and April 2025, the AI Office will develop codes of practice that will spell out how GPAI model developers can operationalise their requirements under the Regulation. 
• All GPAI model providers may demonstrate compliance with their obligations if they voluntarily adhere to the codes of practice until European harmonised standards are published, compliance with which will also lead to a presumption of conformity. 
• To develop the codes of practice, the AI Office may consult GPAI model providers, relevant national competent authorities, civil society, industry, academia, downstream providers, and independent experts.

The codes of practice will cover:

• Model evaluations, including conducting and documenting adversarial testing, to identify systemic risks.
• The identification of the type and nature of systemic risks at EU level, including their sources.
• The measures, procedures, and modalities for assessing, managing, and documenting systemic risks, proportionate to their severity and probability, and accounting for how they materialize throughout the value chain. 
• Tracking, documenting, and reporting serious incidents and possible corrective measures.
• Ensuring the model has adequate cybersecurity and physical protections. 
• The documentation developers should supply to the AI Office and national competent authorities to enable them to assess compliance, such as the tasks the model is intended to perform, key design choices, data and curation methodologies, acceptable use policies, etc. For systemic models (over 10^25 FLOPS), this information also includes evaluation results, a description of internal and/or external adversarial testing, model adaptations, including alignment and fine-tuning, etc.  
• The documentation developers should supply to their customers or downstream deployers to ensure transparency about model capabilities and limitations, such as how the model interacts with other software, instructions for use, the technical means for how it can be integrated into applications. 
• The codes will also cover the means to ensure the above documentation is kept up to date in light of market and technological developments. 
• Policies that developers can establish to respect the EU Copyright Directive that allows rightsholders to opt out of text and data mining (TDM) of their works. 
• The training data template developers should use to publish a sufficiently detailed summary about the content used for model training, which should be generally comprehensive in its scope, instead of technically detailed, to facilitate parties with legitimate interests in exercising their rights, particularly in relation to copyright.
• Watermarking techniques for labelling AI-generated content. 

Working with EU and international partners

• The AI Office represents the European Commission on all AI matters, liaising with Member State authorities, other relevant DGs and Commission services, particularly the European Centre for Algorithmic Transparency for GPAI model evaluation. 
• It will lead European efforts to contribute to international cooperation on AI governance and safety.

Working with the scientific and open source communities

• The Commission will select a scientific panel of independent experts that will advise and support the AI Office on:
  • Implementation and enforcement of GPAI models and systems. 
  • Development of tools, methodologies, and benchmarks for evaluating GPAI capabilities. 
  • Classification of different GPAI models and systems, including systemic GPAI models.
  • Development of tools and templates. 
• The panel can alert the AI Office if a GPAI model meets the threshold for systemic risk, or poses a systemic risk even without reaching the threshold. The AI Office can then decide to designate the model as such, imposing additional obligations on the provider. 
• The AI Office will also establish a forum to collaborate with the open-source community on developing best practices for the safe use and development of open-source AI models and systems.

The following provides a selective overview of the publication, with a particular focus on the AI Office and GPAI. It is important to note that this overview refrains from introducing new perspectives, but focuses solely on reiterating the most relevant findings of the publication for clarity and accessibility for policymakers.

The original publication is available at SSRN via the SSRN link, or DOI link.

1. Implementing and enforcing the AI Act: the remaining steps for the Commission

1.1 Guidelines for risk-based classification of AI

• Within the framework of risk assessments, the Commission is yet to define rules about “significant modifications” that alter the risk level of a system once it has been introduced to the market (Art 43(4) AIA). Novelli et al. expect that standard fine-tuning of foundation models should not lead to a substantial modification, unless the process explicitly involves removal of safety layers or other actions that clearly increase risk.
• A complementary approach to risk assessment that Novelli et al. offer is to adopt predetermined change management plans akin to those in medicine; these are documents outlining anticipated modifications (e.g. performance adjustments, shift in intended use) and methods for assessing such changes.

1.2 Classification of general-purpose AI (GPAI)

• The Commission has notable authority under the AIA to classify GPAI as exhibiting ‘systemic risk’ (Art 51 AIA). Novelli et al. consider this distinction crucial: only systemically risky GPAIs are subject to the more far-fetching AI safety obligations concerning evaluation and red teaming, comprehensive risk assessment and mitigation, incident reporting, and cybersecurity (Art 55 AIA). The Commission can initiate the decision to classify a GPAI as systemically risky, or do so in response to an alert from the Scientific Panel.
• The Commission is able to dynamically adjust regulatory parameters. Novelli et al. find this essential for a robust governance model, in particular because the trend in AI development moves towards creating more powerful, yet “smaller” models (that require fewer FLOPs).
• Art 52 outlines how GPAI providers may contest the Commission’s risk classification decisions. Novelli et al. foresee this potentially becoming a primary area of contention within the AI Act. GPAI providers whose models are trained with fewer than 10^25 FLOPs, yet esteemed systemically risky by the Commission, are expected to contest, possibly reaching the Court of Justice of the European Union (CJEU). This allows providers with deep pockets to delay the application of the more stringent rules. Simultaneously, this reinforces the importance of the rapidly outdating 10^25 FLOP threshold for GPAI.

1.3 Enforcement timeline: grace period and exemptions

• Existing GPAI systems already on the market are granted a grace period of 24 months before they must fully comply with the AIA (Art 83(3) AIA). Novelli et al. note that, more importantly, high-risk systems already on the market for 24 months after the entry into force are entirely exempt from the AIA until ‘significant changes’ (defined in section 3.2) are made in their designs (Art 83(2) AIA). They contend that this is arguably in deep tension with a principle of product safety law: it applies to all models on the market, irrespective of when they entered the market. Moreover, the grace period for GPAI and the exemption for existing high-risk systems favor incumbents over newcomers, which is questionable from a competition perspective.

3. Supranational authorities: the AI Office, the AI board, and the other bodies

3.1 The AI Office

1. Institutional composition and operational autonomy

• Novelli et al. note that the Office’s precise organizational structure and operational autonomy remain ambiguous. No provisions, either in the AIA or in the Commission’s decision, have been established regarding the composition of the AI Office, its collaborative dynamics with the various Connects within the DG, or the extent of its operational autonomy. Novelli et al. hypothesize that this absence is likely justified by the expectation that the Office will partially use existing infrastructure of DG-CNECT. Nevertheless, Novelli et al. underscore that expert hiring and substantial funding will present significant challenges, as the Office will compete with some of the best-funded private companies on the planet.
• Regarding its operational autonomy, the Office’s incorporation in DG-CNECT means that the DG’s management plan will guide the AI Office’s strategic priorities. Novelli et al. note that this integration directly influences the scope and direction of the AI Office’s initiatives.
  

2. Mission(s) and task

• The primary mission of the AI Office, according to the Commission Decision, is to ensure the harmonized implementation and enforcement of AIA (Art 2, point 1 of the Decision). The Decision also outlines auxiliary missions, such as enhancing a strategic EU approach to global AI “initiatives”, promoting actions that maximize AI’s social and economic benefits, supporting AI systems that boost EU competitiveness, and keeping track of AI market advancements. 
• Novelli et al. consider this very broad wording, one interpretation they propose is that the AI Office’s role could go beyond the scope of the AIA to include additional AI normative frameworks (such as the revised Product Liability Directive or the Artificial Intelligence Liability Directive (AILD)). In this case, Novelli et al. observe that the Office might need restructuring into a more autonomous body, like the CERT-EU, which could necessitate detaching it from the Commission’s administrative framework. 
• The ambiguity in the current normative framework regarding breath and scope of the AI Office is considered a crucial aspect by Novelli et al. They consider the responsibilities assigned to the AI Office to be broadly defined, with the expectation that their precise implementation will evolve based on practical experience.
• An important aspect to consider within the operational scope of the Office is the nature of its decisions. Novelli et al. note that the AI Office does not issue binding decisions on its own, but supports and advises the Commission. They raise concern that the effectiveness of mechanisms for appealing decisions of the Commission may be compromised by the opaque nature of the AI Office’s support to the Commission, its interactions within DG-CNECT, and its relationships with external bodies, such as national authorities. Novelli et al. find this issue particularly pertinent given the AI Office’s engagement with external experts and stakeholders. They emphasize that documentation and disclosure of the AI Office’s contributions become crucial. 

3.2 The AI Board, the Advisory Forum, and the Scientific Panel

1. Structures, roles and compositions of the three bodies

• For Novelli et al., having three separate entities with relatively similar compositions raises questions. The AI Board is understandable for ensuring representation and maintaining some independence from EU institutions. But why there is both an Advisory Forum and a Scientific Panel is not apparent. The Forum is intended for diverse perspectives of civil society and industry, essentially acting as an institutionalized form of lobbying while balancing commercial and non-commercial interests. In contrast, the Panel consists of independent and (hopefully) unbiased experts, with specific tasks related to GPAI. 

2. Mission(s) and tasks

• Novelli et al. note that the Board does not have the authority to revise decisions of national supervisory agencies. They believe this may prove a distinct disadvantage, hindering the uniform application of the law if certain Member States interpret the AIA in highly idiosyncratic fashions. For instance, one may particularly think of the supervision of the limitations on surveillance tools using remote biometric identification. 
• Novelli et al. consider the distinction between the Advisory Forum and the Scientific Panel less clear than the separation between the Board and the Office. They raise questions regarding the exclusivity of the Forum’s support to the Board and the Commission, given that the Panel exclusively supports the AI Office directly, and whether the Panel’s specialized GPAI expertise could benefit these entities. The participation of the AI Office in Board meetings is an indirect channel for the Panel’s expertise to influence broader discussions, but Novelli et al. consider this arrangement not entirely satisfactory. The Panel’s specialized opinion may become less impactful, since the AI Office lacks voting power in the Board meetings. 

4. Recommendations for robust governance of the AI Act

Building on their analysis, Novelli et al. envision the following important updates that should be made to the governance structure of the AI Act. 

4.1 Clarifying the institutional design of the AI Office

• Given the broad spectrum of tasks anticipated for the AI Office, more detailed organizational guidance is needed. Additionally, the Office’s mandate lacks specificity concerning the criteria for selecting experts that are to carry out evaluations (Recital 164 AIA). 
• Integrating the AI Office within the framework of the Commission may obscure its operational transparency, given the obligation to adhere to the Commission’s general policies on communication and confidentiality. For example, the right for public access to Commission documents (Regulation (EC) No 1049/2001) includes numerous exceptions that could impede the release of documents related to the AI Office. Novelli et al. give the exception of documents that would compromise “[…] commercial interests of a natural or legal person, including intellectual property,” a broadly defined provision lacking specific, enforceable limits. A narrower interpretation of these exceptions could be applied to the AI Office to help circumvent transparency issues. 
• Further clarification regarding the AI Office’s operational autonomy is required. Novelli et al. propose that this could come in the form of guidelines for decision-making authority, financial independence, and engagement capabilities with external parties.
• An alternative, potentially more effective approach would be establishing the AI Office as a decentralized agency with its legal identity, like EFSA and the EMA. This model would endow the AI Office with enhanced autonomy, including relative freedom from the political agendas at the Commission level, a defined mission, executive powers, and the authority to issue binding decisions. Novelli et al. observe some risk of agency drift, but state that empirical evidence suggests that the main interlocutors of EU agencies are “parent” Commission DGs. 

4.2 Integrating the Forum and the Panel into a single body

• Novelli et al. argue that consolidating the Forum and the Panel into a singular entity would reduce duplications and strengthen the deliberation process before reaching a decision. This combined entity would merge the knowledge bases of civil society, the business sector, and the academic community, which Novelli et al. expect to promote inclusive and reflective discussions of the needs identified by the Commission. They conclude that this approach could significantly improve the quality of advice to the Board, the Office, and the other EU institutions or agencies. 
• Should merging the Forum and the Panel prove infeasible, an alternative solution could be to better coordinate their operations, through clear separations of scopes, roles, tasks, but unified reporting. Novelli et al. suggest producing a joint annual report consolidating contributions from the Forum and the Panel, cutting administrative overlap and ensuring a more unified voice to the Commission, Board, and Member States. 
• Merging or enhancing coordination between the Forum and the Panel favors robust governance of the AIA by streamlining advisory roles for agility and innovation, also in response to disruptive technological changes. 

4.3 Coordinating overlapping EU entities: the case for an AI Coordination Hub

• As AI technologies proliferate across the EU, collaboration among regulatory entities becomes increasingly critical, especially when introducing new AI applications intersects with conflicting interests. A case in point is the decision by Italy’s data protection authority to suspend ChatGPT. Novelli et al. consider it crucial to incorporate efficient coordination mechanisms within the EU’s legislative framework. 
• Furthermore, they see the establishment of a centralized platform, the European Union Artificial Intelligence Coordination Hub (EU AICH), emerging as a compelling alternative. Novelli et al. argue that establishing such a hub will elevate the uniformity of AIA enforcement significantly, while improving operational efficiency and reducing inconsistencies in treating similar matters.

4.4 Control of AI misuse at the EU level

• The absence of authority for the AI Board to revise or address national authorities’ decisions, presents a notable gap in ensuring consistent AI regulations. This is concerning, especially regarding the AIA’s restrictions on surveillance tools, including facial recognition technologies. 
• Without the ability to correct or harmonize national decisions, there’s a heightened risk that AI could be misused in some Member States, potentially facilitating the establishment of illiberal surveillance regimes, and stifling legitimate dissent. Novelli et al. underscore the need for a mechanism within the AI Board to ensure uniform law enforcement and prevent AI’s abusive applications, especially in sensitive areas like biometric surveillance.

4.5 Learning mechanisms

• Given their capacity for more rapid development and adjustment, Novelli et al. see the agility of nonlegislative acts as an opportunity for responsive governance in AI. However, they note that the agility of the regulatory framework must be matched to the regulatory bodies’ adaptability. Inter- and intra-agency learning and  collaboration mechanisms are essential for addressing AI’s multifaceted technical and societal challenges. They suggest that specific ex-ante and ex-post review obligations could be introduced. 
• More importantly, Novelli et al. propose that a dedicated unit, for example, within the AI Office should be tasked with identifying best and worst practices across all involved entities (from the Office to the Forum). Liaising with Member State competence centers, such a unit could become a hub for institutional and individual learning and refinement of AI, within and beyond the scope of the AIA framework. 

References

Novelli, Claudio and Hacker, Philipp and Morley, Jessica and Trondal, Jarle and Floridi, Luciano, A Robust Governance for the AI Act: AI Office, AI Board, Scientific Panel, and National Authorities (May 5, 2024). Available at SSRN: https://ssrn.com/abstract=4817755 or http://dx.doi.org/10.2139/ssrn.4817755 

Deadline to apply is 12:00 CET on 27 March (application form). 

Role

This is an opportunity to work in a team within the Directorate-General for Communications Networks, Content and Technology (DG CNECT) in the European Commission, supervising the world’s largest consumer market for AI. This team will be directly involved in enforcing the AI Act, the first global AI law, by overseeing compliance of general-purpose AI (GPAI). 

The AI Office is empowered to request information from GPAI providers, analyse systemic risks stemming from these GPAI models, and investigate potential legal infringements as part of multi-disciplinary case teams. If necessary, it can require GPAI model providers to implement systemic risk mitigation measures, as well as restrict, recall, or withdraw the model from the market. Unlike other AI bodies that are monitoring the state-of-the-art, this Office will possess real regulatory enforcement powers not dependent on the grace of private corporations providing public access to their sought-after products.  

This role will help to shape codes of practice for GPAI models through consultation with GPAI model providers, civil society organisations, industry and academia, and thereby to the enactment of e AI safety measures with global impact. 

The AI Office will be at the frontier of developing tools, methodologies and benchmarks for capabilities evaluations, generating expertise within the European Commission and surfacing awareness of emergent dangerous model behaviours. It is a platform for converting the latest research into concrete actions that will improve AI safety for society.

Contingent on your experience, you may be involved in classifying models as systemic, as well as overseeing compliance with the more stringent measures that such classification entails (model evaluations, adversarial testing, cybersecurity-by-design, etc.), conducting evaluations and investigations when needed. 

The AI Office bridges the gap between the scientific and policymaking communities. It will coordinate with the forthcoming scientific panel of independent experts, which can provide qualified alerts if it identifies a model that presents concrete EU-level risks or meets the threshold for designation as systemic (currently 10^25 FLOPS and above). It also serves as a central contact point for international AI safety collaboration with institutions like the US and UK AI Safety Institutes. This means it will tap into global AI networks to ensure that regulation can keep up with the rapid evolution of AI.

Profile 

Essential requirements:

• EU citizenship;
• Thorough competence in one EU language and satisfactory competence in a second EU language;
• A pass in the EPSO CAST.
  • At this stage of the application, it is sufficient to be registered in the EPSO CAST database. To register, you must apply for (at least) one profile in the list of “Selection procedures for Contract Agents” for Contract Agent Function Group IV (FG IV). Please select the profile that best suits your education and experience. Every time a vacant position arises, we will consult this database, which contains the data of the persons that have expressed an interest to work for the Platforms directorate of DG CNECT. If your profile is among the “best matches”, you might be invited to sit the EPSO CAST Permanent computer-based multi-choice tests and/or might be contacted for an interview to further assess the competences required for the position that interests you.
  • For more information please see the following links:  
    • Registration: https://europa.eu/epso/application/passport/login.cfm?langsub=ok&lang=en and https://eu-careers.europa.eu/en/help/faq/epso-account-application
    • General information: https://eu-careers.europa.eu/en/cast-permanent-selection-procedure
    • Call for Expression of Interest: https://eu-careers.europa.eu/en/documents/call-expressions-interest-cast-p-2023.
• A master’s degree in IT, computer science, engineering/science or other relevant domain;
• At least one year of experience as a research scientist, computer scientist, software and data engineer, hardware specialist or other technical staff.

Additional expertise that would be advantageous:

• Experience in model evaluations, including alignment and red teaming;
• Professional experience in an international and multicultural environment;
• Knowledge/understanding of AI technologies;
• Knowledge/understanding of EU policies in the fields relevant to the profile;
• Knowledge/experience of regulatory supervision and enforcement in any related domain;
• Experience and understanding of audit & control systems;
• Additional expertise or academic background in legal matters.

Salary

• Two years of experience, moving to Belgium/Brussels without prior residence there, living together with someone, without children, would earn approx. 4,180 EUR as net salary.  
• For the same person with more than five years of experience, the net salary would be approx. 4,670 EUR.
• This experienced person but with two children under six years old, net salary would earn approx. 6,170 EUR.
• For more information on the salary of an FG IV contract agent, please see here. 

Process

Interviews will likely run from late spring to autumn 2024. The initial contract runs for one year for successful candidates.

The European Commission has established a new EU level regulator, the European AI Office, which will sit within the Directorate-General for Communication Networks, Content and Technology (DG CNECT) in the European Commission. 

The AI Office will monitor, supervise, and enforce the AI Act requirements on general purpose AI (GPAI) models and systems across the 27 EU Member States. This includes analysing emerging unforeseen systemic risks stemming from GPAI development and deployment, as well as developing capabilities evaluations, conducting model evaluations and investigating incidents of potential infringement and non-compliance. To facilitate the compliance of GPAI model providers and consider their perspectives, the AI Office will produce voluntary codes of practice, adherence to which would create a presumption of conformity. 

The AI Office will also lead the EU in international cooperation on AI and strengthen bonds between the European Commission and the scientific community, including the forthcoming scientific panel of independent experts. The Office will help the 27 Member States cooperate on enforcement, including on joint investigations, and act as the Secretariat of the AI Board, the intergovernmental forum for coordination between national regulators. It will support the creation of regulatory sandboxes where companies can test AI systems in a controlled environment. It will also provide information and resources to small and medium businesses (SMEs) to aid in their compliance with rules. 

Central coordinating and monitoring mechanism

What will the AI Office do to coordinate and monitor the implementation of the EU AI Act?

• The AI Office will monitor the implementation of rules by GPAI model developers, requiring them to take corrective measures when non-compliant. 
• Where the same provider develops the GPAI model and system (user-facing application), the AI Office will also supervise compliance of the GPAI system.
• When a GPAI system is used directly by deployers in a high risk context (Annex II or III), and is suspected of being non-compliant, the AI Office will cooperate with market surveillance authorities to assess compliance and inform the AI Board.
• The AI Office will facilitate uniform application of the AI Act across Member States.
• The Office will support coordinated enforcement of banned and high-risk AI by streamlining communication between sectoral bodies and national authorities, and creating central databases, particularly when a GPAI model or system is integrated into a high-risk AI system.
• It will ensure supervisory coordination for AI systems that fall under the AI Act as well as the Digital Services Act (DSA) and Digital Markets Act (DMA).
• It will coordinate the creation of a governance system, including preparing the establishment of advisory bodies at the EU level and monitoring the establishment of relevant national authorities.
• Finally, the Office will act as the Secretariat for the AI Board and its subgroups, providing administrative support to the advisory forum and scientific panel of independent experts, including organising meetings and preparing relevant documents.

AI Board

What is the AI Board, and what is it’s role in relation to the AI Office?

• Composed of one representative per Member State, with the EDPS and AI Office participating in meetings as non-voting observers, the Board should ensure consistency and coordination of implementation between national competent authorities.
• The AI Office will provide the Secretariat for the Board, convene meetings upon request of the Chair, and prepare the agenda. 
• The AI Board will assist the AI Office in supporting national competent authorities in the establishment and development of regulatory sandboxes and facilitate cooperation and information sharing among regulatory sandboxes.

Joint investigations

How will the AI Office play a role in ‘joint investigations’?

• The AI Office will provide coordination support for joint investigations conducted by one or more market surveillance authorities to identify non-compliance, where high risk AI systems are found to present a serious risk across several Member States.

Enforcement

The AI Office will support the Commission’s role as lead AI Act enforcer by preparing: 

• Decisions (legal acts that apply only to specific recipients, either generally or individually); 
• Implementing acts to provide detailed rules for the application of the AI Act;
• Delegated acts to supplement or amend non-essential elements of the AI Act; 
• Guidance and guidelines to support practical AI Act implementation, such as standardised protocols and best practices, in consultation with relevant Commission services, and EU institutions, bodies and agencies;
• Standardisation requests: the evaluation of existing standards and the preparation of common specifications to support AI Act implementation.

Codes of practice

How will the AI Office implement codes of practice for AI in the EU?

• By Q2 2025, the AI Office and AI Board must facilitate the development of codes of practice to cover GPAI obligations and watermarking techniques for labelling content as artificially generated, while accounting for international approaches. Codes must have specific, measurable objectives, including key performance indicators (KPIs), accounting for the differences in size and capacity of various providers. 
• The AI Office must monitor and evaluate the implementation and effectiveness of codes, which involves reports from the GPAI providers, while considering adaptations in light of emerging standards. This includes setting up forums for GPAI model and system providers to exchange best practices. It may involve consultation with relevant national competent authorities, civil society, industry, academia, downstream providers, and independent experts, who should be regularly consulted.
• All GPAI model providers may demonstrate compliance with their obligations if they voluntarily adhere to the codes of practice until European harmonised standards are published, compliance with which will also lead to a presumption of conformity.
• The AI Office will create a forum for cooperation with the open-source community to identify and develop best practices for the safe development and use of open-source AI models and systems.
• The Commission may give general EU validity to a code of practice through implementing acts. If a code of practice cannot be finalised when rules are legally applicable, or the AI Office judges it as inadequate, the Commission may provide common rules for implementation through implementing acts.

Model evaluations: Capabilities and risks

To assess the capabilities and risks of AI models, the AI Office will:

• Develop tools, methodologies, and benchmarks for capabilities evaluations for GPAI models, particularly the highly capable ones with the greatest impact that present possible systemic risks.
• Monitor emerging unforeseen risks of GPAI models, including responding to the scientific panel of independent experts’ qualified alerts. Systemic GPAI model providers are also required to report serious incidents and corrective measures to the AI Office. 
• Investigate possible infringements and systemic risks of upstream GPAI models and systems, including collecting complaints from downstream providers and deployers, as well as qualified alerts from the scientific panel of independent experts. 
• Require GPAI model providers, where necessary, to provide technical documentation on training and testing processes and evaluation results, any other additional information needed to assess compliance or for the scientific panel of independent experts to carry out their work. 
• Initiate structured dialogues with the GPAI model provider, where helpful, to gather more information on the model’s internal testing, safeguards for preventing systemic risks, and other procedures and measures the provider has taken to mitigate such risks.
• Conduct model evaluations, after consulting the AI Board, through APIs or other means, such as the source code, where documentation and information are insufficient to assess compliance.

Where these model evaluations have identified a serious and substantiated concern of systemic risk, the AI Office can require the provider to implement mitigation measures, which may be made binding through a Commission Decision. If such mitigation measures are unable to address the risk, the AI Office can restrict, recall, or withdraw the GPAI model from the market. 

Data governance

The AI Office will also develop a template for GPAI providers to use when publishing a sufficiently detailed summary about the content used for training the GPAI model, which should be broadly comprehensive in its scope, rather than technically detailed, to facilitate parties with legitimate interests in exercising their rights. The training data content summaries may list the main data collections or sets used, such as large private or public databases or data archives, while providing a narrative explanation about other data sources used.

Scientific panel of independent experts

The Commission will select experts that demonstrate expertise, independence from AI developers, and  the ability to execute their duties diligently, accurately, and objectively. 

The panel will advise and support the AI Office on: 

• Implementation and enforcement of GPAI models and systems. 
• Development of tools, methodologies, and benchmarks for evaluating GPAI capabilities. 
• Classification of different GPAI models and systems, including systemic GPAI models.
• Development of tools and templates. 

The panel can provide a qualified alert to the AI Office where it suspects a GPAI model poses concrete identifiable risk at the EU level, or meets the threshold for classifying GPAI models as systemically risky.On that basis, the AI Office, having informed the AI Board, may designate a GPAI model as systemically risky and therefore subject to more obligations. 

Collaboration

With regards to collaboration, the AI Office will also:

• Cooperate with relevant EU institutions, bodies and agencies, including the European High Performance Computing Joint Undertaking (EuroHPC JU), encouraging investment in development of GPAI to be deployed in beneficial applications; 
• Engage with Member State authorities on behalf of the Commission;
• Work with relevant DGs and Commission services, notably the European Centre for Algorithmic Transparency for GPAI model evaluation, and raising awareness of emerging risks within the Commission; 
• Evaluate and promote the convergence of best practices in public procurement procedures for AI systems; 
• Contribute to international cooperation on AI governance, advocate for responsible AI, and promote the EU approach. 

Sandboxes

The Office will contribute technical support, advice, and tools for the establishment and operation of AI regulatory sandboxes, coordinating with national authorities as needed to encourage cooperation among Member States. Twoyears after entry into force, Member States must establish at least one AI regulatory sandbox either independently or by joining other Member States’ sandbox(es).

This should foster innovation, particularly for SMEs, by facilitating AI training, testing, and validation, before the system’s market placement or introduction into service under regulators’ supervision. Such supervision is intended to provide legal clarity, improve regulatory expertise and policy learning, and enable market access. The AI Office is notified by national authorities of any suspension in sandbox testing due to significant risks. National authorities submit publicly available annual reports to the AI Office and AI Board detailing sandbox progress, incidents, and recommendations.

Supporting SMEs

What will the AI Office to do support SMEs in the EU?

• The AI Office will develop and maintain a single information platform providing easy to use information on this Regulation for all EU operators. 
• The AI Office will organise appropriate communication campaigns to raise awareness about the Regulation’s requirements. 

Review

How will the AI Office’s roles and responsibilities be reviewed and updated?

• 2 years after entry into force (June 2026), the Commission will assess if the AI Office has been given sufficient powers and competences to fulfil its tasks, and whether those need to be upgraded with increased resources. 

Compliance deadlines

This timeline was correct at the time of writing, but is now out of date – for an up-to-date timeline see this comprehensive implementation timeline.

By 6 months after entry into force:

• Prohibitions on unacceptable risk AI. (Article 113)

By 9 months after entry into force:

• Codes of practice for General Purpose AI (GPAI) must be finalised. (Article 113)

By 12 months after entry into force:

• GPAI rules apply. (Article 113)
• Appointment of Member State competent authorities. (Article 70)
• Annual Commission review and possible amendments on prohibitions. (Article 112)

By 18 months after entry into force:

• Commission issues implementing acts creating a template for high risk AI providers’ post-market monitoring plan. (Article 6)

By 24 months after entry into force:

• Obligations on high-risk AI systems specifically listed in Annex III, which includes AI systems in biometrics, critical infrastructure, education, employment, access to essential public services, law enforcement, immigration and administration of justice now apply. (Article 111)
• Member states to have implemented rules on penalties, including administrative fines. (Article 57)
• Member state authorities to have established at least one operational AI regulatory sandbox. (Article 57)
• Commission review, and possible amendment of, the list of high-risk AI systems. (Article 112)

By 36 months after entry into force:

• Obligations on Annex I high risk AI systems apply. (Article 113)
• Obligations for high-risk AI systems that are not prescribed in Annex III but are intended to be used as a safety component of a product, or the AI is itself a product, and the product is required to undergo a third-party conformity assessment under existing specific EU laws, for example toys, radio equipment, in vitro diagnostic medical devices, civil aviation security and agricultural vehicles. (Article 113)

By the end of 2030:

• Obligations go into effect for certain AI systems that are components of the large-scale IT systems established by EU law in the areas of freedom, security and justice, such as the Schengen Information System. (Article 111)

Secondary legislation

The Commission can introduce delegated acts on:

• Definition of AI system. (Article 96)
• Criteria that exempt AI systems from high risk rules. (Article 6)
• High risk AI use cases. (Article 7)
• Thresholds classifying General Purpose AI models as systemic. (Article 51)
• Technical documentation requirements for high risk AI systems and GPAI. (Article 11)
• Conformity assessments. (Article 43)
• EU declaration of conformity. (Article 47)

The Commission’s power to issue delegated acts lasts for an initial and extendable period of five years. (Article 97)

The AI Office is to draw up codes of practice to cover, but not necessarily limited to, obligations for providers of general purpose AI models. Codes of practice should be ready nine months after entry into force at the latest and should provide at least a three-month period before taking effect. (Article 97)

The Commission can introduce implementing acts on:

• Approving codes of practice for GPAI and generative AI watermarking. (Article 56)
• Establishing the scientific panel of independent experts. (Article 68)
• Conditions for AI Office evaluations of GPAI compliance. (Article 92)
• Operational rules for AI regulatory sandboxes. (Article 57)
• Information in real world testing plans. (Article 60)
• Common specifications (where standards do not cover rules). (Article 41)

Commission guidelines

The Commission can provide guidance on:

• By 12 months after entry into force: High risk AI serious incident reporting. (Article 73)
• By 18 months after entry into force: Practical guidance on determining if an AI system is high risk, with list of practical examples of high-risk and non-high risk use cases. (Article 6)
• With no specific timeline, the Commission will provide guidelines on: (Article 96)
  • The application of the definition of an AI system.
  • High risk AI provider requirements.
  • Prohibitions.
  • Substantial modifications.
  • Transparency disclosures to end-users.
  • Detailed information on the relationship between the AI Act and other EU laws.

The Commission is to report on its delegated powers no later than nine months and before five years after entry into force. (Article 112)

In this article we provide you with a high-level summary of the AI Act, selecting the parts which are most likely to be relevant to you regardless of who you are. We provide links to the original document where relevant so that you can always reference the Act text.

To explore the full text of the AI Act yourself, use our AI Act Explorer. Alternatively, if you want to know which parts of the text are most relevant to you, use our Compliance Checker.

View this content as a PDF

Prohibited AI systems (Chapter II, Art. 5)

The following types of AI system are ‘Prohibited’ according to the AI Act.

AI systems:

• deploying subliminal, manipulative, or deceptive techniques to distort behaviour and impair informed decision-making, causing significant harm.
• exploiting vulnerabilities related to age, disability, or socio-economic circumstances to distort behaviour, causing significant harm.
• biometric categorisation systems inferring sensitive attributes (race, political opinions, trade union membership, religious or philosophical beliefs, sex life, or sexual orientation), except labelling or filtering of lawfully acquired biometric datasets or when law enforcement categorises biometric data.
• social scoring, i.e., evaluating or classifying individuals or groups based on social behaviour or personal traits, causing detrimental or unfavourable treatment of those people.
• assessing the risk of an individual committing criminal offenses solely based on profiling or personality traits, except when used to augment human assessments based on objective, verifiable facts directly linked to criminal activity.
• compiling facial recognition databases by untargeted scraping of facial images from the internet or CCTV footage.
• inferring emotions in workplaces or educational institutions, except for medical or safety reasons.
• ‘real-time’ remote biometric identification (RBI) in publicly accessible spaces for law enforcement, except when:
  • searching for missing persons, abduction victims, and people who have been human trafficked or sexually exploited;
  • preventing substantial and imminent threat to life, or foreseeable terrorist attack; or
  • identifying suspects in serious crimes (e.g., murder, rape, armed robbery, narcotic and illegal weapons trafficking, organised crime, and environmental crime, etc.).

Notes on remote biometric identification:

Using AI-enabled real-time RBI is only allowed when not using the tool would cause considerable harm and must account for affected persons’ rights and freedoms.

Before deployment, police must complete a fundamental rights impact assessment and register the system in the EU database, though, in duly justified cases of urgency, deployment can commence without registration, provided that it is registered later without undue delay.

Before deployment, they also must obtain authorisation from a judicial authority or independent administrative authority[1], though, in duly justified cases of urgency, deployment can commence without authorisation, provided that authorisation is requested within 24 hours. If authorisation is rejected, deployment must cease immediately, deleting all data, results, and outputs.

↲ [1] Independent administrative authorities may be subject to greater political influence than judicial authorities (Hacker, 2024).

High risk AI systems (Chapter III)

Some AI systems are considered ‘High risk’ under the AI Act. Providers of those systems will be subject to additional requirements.

Classification rules for high-risk AI systems (Art. 6)

High risk AI systems are those:

• used as a safety component or a product covered by EU laws in Annex I AND required to undergo a third-party conformity assessment under those Annex I laws; OR
• listed under Annex III use cases (below), except if:
  • the AI system performs a narrow procedural task;
  • improves the result of a previously completed human activity;
  • detects decision-making patterns or deviations from prior decision-making patterns and is not meant to replace or influence the previously completed human assessment without proper human review; or
  • performs a preparatory task to an assessment relevant for the purpose of the use cases listed in Annex III.
• AI systems listed under Annex III are always considered high-risk if it profiles individuals, i.e. automated processing of personal data to assess various aspects of a person’s life, such as work performance, economic situation, health, preferences, interests, reliability, behaviour, location or movement.
• Providers whose AI system falls under the use cases in Annex III but believes it is not high-risk must document such an assessment before placing it on the market or putting it into service.

Requirements for providers of high-risk AI systems (Art. 8–17)

High risk AI providers must:

• Establish a risk management system throughout the high risk AI system’s lifecycle;
• Conduct data governance, ensuring that training, validation and testing datasets are relevant, sufficiently representative and, to the best extent possible, free of errors and complete according to the intended purpose.
• Draw up technical documentation to demonstrate compliance and provide authorities with the information to assess that compliance.
• Design their high risk AI system for record-keeping to enable it to automatically record events relevant for identifying national level risks and substantial modifications throughout the system’s lifecycle.
• Provide instructions for use to downstream deployers to enable the latter’s compliance.
• Design their high risk AI system to allow deployers to implement human oversight.
• Design their high risk AI system to achieve appropriate levels of accuracy, robustness, and cybersecurity.
• Establish a quality management system to ensure compliance.

General purpose AI (GPAI)

GPAI model means an AI model, including when trained with a large amount of data using self-supervision at scale, that displays significant generality and is capable to competently perform a wide range of distinct tasks regardless of the way the model is placed on the market and that can be integrated into a variety of downstream systems or applications. This does not cover AI models that are used before release on the market for research, development and prototyping activities.

GPAI system means an AI system which is based on a general purpose AI model, that has the capability to serve a variety of purposes, both for direct use as well as for integration in other AI systems.

GPAI systems may be used as high risk AI systems or integrated into them. GPAI system providers should cooperate with such high risk AI system providers to enable the latter’s compliance.

All providers of GPAI models must:

• Draw up technical documentation, including training and testing process and evaluation results.
• Draw up information and documentation to supply to downstream providers that intend to integrate the GPAI model into their own AI system in order that the latter understands capabilities and limitations and is enabled to comply.
• Establish a policy to respect the Copyright Directive.
• Publish a sufficiently detailed summary about the content used for training the GPAI model.

Free and open licence GPAI models – whose parameters, including weights, model architecture and model usage are publicly available, allowing for access, usage, modification and distribution of the model – only have to comply with the latter two obligations above, unless the free and open licence GPAI model is systemic.

GPAI models present systemic risks when the cumulative amount of compute used for its training is greater than 10²⁵ floating point operations (FLOPs). Providers must notify the Commission if their model meets this criterion within 2 weeks. The provider may present arguments that, despite meeting the criteria, their model does not present systemic risks. The Commission may decide on its own, or via a qualified alert from the scientific panel of independent experts, that a model has high impact capabilities, rendering it systemic.

In addition to the four obligations above, providers of GPAI models with systemic risk must also:

• Perform model evaluations, including conducting and documenting adversarial testing to identify and mitigate systemic risk.
• Assess and mitigate possible systemic risks, including their sources.
• Track, document and report serious incidents and possible corrective measures to the AI Office and relevant national competent authorities without undue delay.
• Ensure an adequate level of cybersecurity protection.

All GPAI model providers may demonstrate compliance with their obligations if they voluntarily adhere to a code of practice until European harmonised standards are published, compliance with which will lead to a presumption of conformity. Providers that don’t adhere to codes of practice must demonstrate alternative adequate means of compliance for Commission approval.

Codes of practice

• Will account for international approaches.
• Will cover but not necessarily limited to the above obligations, particularly the relevant information to include in technical documentation for authorities and downstream providers, identification of the type and nature of systemic risks and their sources, and the modalities of risk management accounting for specific challenges in addressing risks due to the way they may emerge and materialise throughout the value chain.
• AI Office may invite GPAI model providers, relevant national competent authorities to participate in drawing up the codes, while civil society, industry, academia, downstream providers and independent experts may support the process.

Governance

How will the AI Act be implemented?

• The AI Office will be established, sitting within the Commission, to monitor the effective implementation and compliance of GPAI model providers.
• Downstream providers can lodge a complaint regarding the upstream providers infringement to the AI Office.
• The AI Office may conduct evaluations of the GPAI model to:
  • assess compliance where the information gathered under its powers to request information is insufficient.
  • Investigate systemic risks, particularly following a qualified report from the scientific panel of independent experts.

Timelines

• After entry into force, the AI Act will apply by the following deadlines:
  • 6 months for prohibited AI systems.
  • 12 months for GPAI. 
  • 24 months for high risk AI systems under Annex III. 
  • 36 months for high risk AI systems under Annex I.
• Codes of practice must be ready 9 months after entry into force. 

See our full implementation timeline for all key milestones relating to the implementation of the AI Act.

This page aims to provide an easily accessible overview of AI safety standard setting under the EU AI Act. It covers the broader context and rationale for EU AI standard setting, the standard setting process, and questions of when AI Act standards might be finished.

This resource was first put together in 2023 by Hadrien Pouget, then AI policy expert at the Carnegie Endowment for International Peace. It was updated in June 2025 by Koen Holtman, standards expert at the AI Standards Lab, and Tekla Emborg, EU policy researcher at the Future of Life Institute.

Note: we focus on explaining the formal EU-based AI safety standard setting effort that is on-going in the so-called CEN-CENELEC JTC21 standards committee. Other AI standards writing efforts, like the ISO/IEC, are not covered.

1. Background: EU AI Standards Process Details

The EU has a particular mechanism that envisages the writing of technical standards that become officially approved ‘manuals’ that describe how companies and other actors can comply with EU safety regulation. The central idea is that such standards, known as ‘harmonized and cited standards’ when approved, can provide a presumption of conformity of legal requirements. If a company demonstrates that their product or system complies with a harmonized and cited standard, market surveillance authorities and courts will presume that they comply with the corresponding legal requirement. 

For the AI Act, the European Commission has requested an initial batch of such standards to be written for the AI Act and the writing is currently in process. This initial batch will cover the requirements for providers of high-risk AI systems. The Commission may request additional standards covering other parts of the AI Act in the future. 

The EU standards request mechanism implies a division of labour. It allows the EU legislator to simply specify in the AI Act that certain safety related outcomes have to be achieved by AI model or system providers, and specify that generally acknowledged state-of-the-art methods of safety engineering shall be applied when achieving these outcomes. The text of the Act does not go into technical detail about what these state-of-the-art methods actually are. The expectation is that technical experts writing standards will fill in these details. The legislator further anticipates that these standards will be updated if the state of the art changes.

We should note at the outset that standards are not the only documents that can detail how to comply with the AI Act. For example, requirements for general-purpose AI providers are clarified in a Code of Practice writing effort. Furthermore, some AI Act requirements will be further clarified in guideline documents penned by the European Commission.

The use of standards as a means of compliance remains voluntary. Providers may ignore the harmonised standards, and rely on independently interpreting the legal text. For their interpretation they may rely on books, guides, web sites, or legal opinions written by independent authors or industry alliances. Such independent work does not have the officially approved status of standards, and will not give a presumption of conformity, but it may be available earlier or be more customised to a specific situation.

2. Key Actors

To understand the development of European standards for the AI Act, it is helpful to start off with an overview of the central actors in the process.

1. The European Commission: It is composed of 27 Commissioners which are put forward by member states and approved by the European Parliament. It acts as the executive branch of the EU. The Commission is in charge of requesting and approving European standards from the European Standards Organisations.
2. The European Standards Organisations (ESOs): There are three organisations that are responsible for all EU standard-setting: CEN, CENELEC, and ETSI. The former two are leading on the creation of AI Act standards through their joint committee with the name CEN/CENELEC JTC21. These bodies are independent of the EU institutions, including the Commission, and they can also create other standards by their own initiative. The ESOs are required to bring together different stakeholders, some of which are introduced below.
3. National Standards Bodies (NSBs): These are responsible for standards in each of the Member States. See for example a list of all member NSBs in CEN. Each national body represents the interest of all stakeholders in the respective country: government, industry, and civil society by allowing national level parties to become members of their committees, typically requiring a participation fee. Such committees discuss and determine national votes and comments on draft standards. The committees can also appoint members as technical experts contributing to drafting inside ESO working groups. Such technical experts are bound by a code of conduct that requires them to ‘work for the net benefit of the European community¹, which may require setting aside preferences of the national stakeholders paying their salary, travel costs, and participation fees.
4. European Stakeholder Organisations: A variety of interests within the EU are represented in further organizations, for example those of Small and Medium-sized Enterprises (SMEs), trade unions, the environment, and consumers. Some of these are entitled to comment and participate without first becoming a member of a national body level committee, as well as some EU funding to participate, in accordance with Annex III of Regulation (EU) No 1025/2012. 
5. Harmonised Standards Consultants: For some standards drafting, private consultants are hired by the Commission to ensure that the standards developed by the ESOs are suitable for publication by the EU. However, for the AI Act, the Commission decided to perform the required suitability assessment itself. The role of harmonised standards consultants is described in more detail here.
   

3. Process Steps

The process for developing harmonised standards is complex. It starts with a standards request from the Commission, followed by drafting by the relevant ESO, enquiry, voting, and publication, before the final step of citation of the standards in the Official Journal of the European Union. Each step is explained below. For a more extensive overview, see the CEN website.

Step 1: The Commission Creates a Standardisation Request for the ESOs

Such a request includes details on which part of the corresponding legislation needs to be covered by the requested standards and a requested delivery date. A draft request is refined in consultation with ESOs and other stakeholders to be acceptable to all. Once approved by the Commission and representatives from EU governments, the request is published and ESOs must formally respond. While rejecting a request is possible, ESOs usually accept requests, even if they have doubts about the feasibility of completing the work by the requested delivery date. See Vademecum on European Standardisation for further details. 

Step 2: The ESOs Draft the Standards

Standards are drafted in technical committees with technical experts from the NSBs. A committee also includes a selection of stakeholders as observers. As mentioned above, the technical committee for the AI Act is a joint committee between CEN and CENELEC called CEN/CENELEC JTC21. Working groups are formed within the committee, where technical experts draft the standards documents. These experts are all volunteers, in the sense that they are not compensated from CEN and CENELEC for their time and effort. Experts are bound by confidentiality rules, for example they cannot reveal details of ongoing discussions or the contents of in-progress working drafts. Unanimous expert agreement, or expert consensus if unanimity is not possible, is needed to pass drafts to the next process step.

Usually the European ESOs try to leverage, and not overrule, existing work in international standards written by ISO/IEC (the Organization for International Standardization and the International Electrotechnical Commission). This is to ensure international consistency and is an important part of the WTO’s Technical Barriers to Trade agreement, which prevents countries from using standards to block international trade.

Step 3: Enquiry

Enquiry is a voting and commenting step where a complete draft standard prepared by a working group is evaluated by national stakeholders. The NSBs collect and send feedback, which is sent back to the experts in the working group who may update the draft based on the feedback. It is not uncommon that different NSBs give conflicting comments, with one country wanting a change in one direction, another country wanting a different change. It is up to the experts in the working group to handle such conflicts by finding a compromise or plainly rejecting certain comments. Plain rejections run the risk that the country will vote ‘no’ in the next step, formal vote. Very negative feedback during enquiry could trigger a process reset, where large parts of the draft are entirely re-written, with the new version then being submitted to a second enquiry vote. A working group may also decide to resolve concerns by just omitting material that has proven to be very controversial. This may yield a standard that does not fully cover the topics requested in the Standardisation Request anymore.

Step 4: Formal Vote

In this process step, the NSBs formally vote to either accept or reject the standard into which their feedback has been incorporated in the previous step. A ‘no’ vote can trigger another round of drafting and re-submission to a new vote. A ‘yes’ vote can still be accompanied by comments, but these should only propose minor edits.

Step 5: Publication

Based on a successful vote, the standard is published by CEN and CENELEC. Published standards are typically available for purchase in web shops, though some are available for free. A recent case in front of the European Court of Justice addressed the appropriateness of ESOs charging money for standards that directly support EU Law. At the time of writing, it is unclear what effects these lawsuits will eventually have on the fee-based funding model of the ESOs.

Step 6: Assessment Followed by Citation in the Official Journal of the European Union

In the final step, the European Commission will carry out an assessment of whether the published standards correctly satisfy the conditions in the Standardisation Request and correspond to the text in the AI Act. However, the European Commission is also involved during the drafting process, providing feedback in the form of preliminary assessments of the drafts. After completing a successful assessment, the Commission can adopt an implementing act citing the standard in the Official Journal of the European Union (OJEU). This makes the standard a harmonized and cited standard that brings a “presumption of conformity” with the applicable parts of the law.

The Commission maintains a website listing all cited harmonised standards for specific regulated fields. In mature fields, there can be tens or hundreds of such standards, developed and updated over decades.

Simplified view of the standard setting process for the EU AI Act

AI Act Standard Setting Timeline Highlights

The timeline below is based on publicly known information as of June 2025.

5. Examples of How Standards Can Clarify the AI Act

To understand how standards could clarify the text of the AI Act, let us look at Articles 9 and 8(1) of the AI Act as examples. 

Article 9 of the AI Act requires that a high-risk AI system is equipped with ‘risk management measures’ so that ‘relevant residual risk associated with each hazard, as well as the overall residual risk of the high-risk AI systems is judged to be acceptable’. Article 8(1) further specifies that this judgment must be made while taking into account ‘the generally acknowledged state of the art on AI and AI-related technologies’.

As a manual on how to fulfill these obligations, a standard could:

• Specify what ‘acceptable’ means: acceptable to whom?
• Detail how to make a judgement of acceptability of the remaining risk. For example, this could involve a cross-disciplinary team of experts who know both the application area, societal expectations around it, and the state of the art of AI technology.
• Outline what the state of the art says about if and when a stakeholder consultation process is appropriate to determine that risks are acceptable, and the design of such stakeholder consultations.
• Detail techniques that are appropriate to estimate residual risks in given situations
• Present checklists that enumerate specific risks, hazards, or considerations that are expected to be known to practitioners of the state of the art.

In mature and narrow fields like food safety or electrical engineering, the subject matter experts are often able to determine lab-tested and time-tested numerical thresholds for safe outcomes. For example, in the area of food safety, they may define that the risk of lead poisoning from a food of type A is at an acceptable level if a lab test on a representative sample shows that the lead content is below B parts per million. It is then for non-experts to use the safety standards and ensure safe outcomes according to the state of the art. 

In contrast, it is unlikely that the experts working on the high-risk AI standards under the AI Act will be able to come up with similar numeric prescriptions. The field of AI covered by the AI Act is simply too diverse, and unlike in food-safety, it cannot fall back on long-lasting experience with product types that have been in the market for decades or centuries. Thus, the state-of-the art processes defined in the AI safety standards will likely require the involvement of expertise and expert judgement in order to be run correctly.

6. Concerns and Controversies

6.1. Timing Concerns and Mitigations

According to the AI Act, the legal requirements on a first category of high-risk AI systems go into force in October 2026. Ideally, corresponding standards would be available by October 2025 to allow providers sufficient preparation time. However, as is clear from the timeline overview above, these standards are unlikely to be completed by then.

Historically, ESOs have often had difficulties delivering the requested standards on time, even when making an early start, for example relating to the update to the Medical Device Regulation and the Radio Equipment Directive. 

Article 41 of the AI Act anticipates potential delays in the development of standards. It allows the European Commission to establish “common specifications,” which would act as official interim guidance until the relevant standards are formally approved. As of the time this post was last updated, the Commission has not publicly indicated any intention to utilise this provision. As shown in the timeline above, the Commission has however indicated that the option of postponing the entry into force of the high-risk requirements, to a date beyond October 2026, could be considered.

6.2. Concerns About Democratically Valid Outcomes

The standards process, and the checks and balances inside and around it, have been designed with the intent to create trusted and democratic outcomes. However, the standards development process has been subject to critique on several points. This includes critique that the process happens behind closed doors without transparency. It has also been criticised for having gameable design features which in practice lead to well-resourced technology companies dominating the process and bad faith actors high-jacking the process. Some have also questioned whether the current process is fit for purpose to deliver law-clarifying standards for digital technologies as part of the EU’s digital agenda. This concern is particularly relevant to AI standards development, given the complex and sometimes controversial nature of AI technology.

6.3. Potential Reform of the European Standards System

The European Commission announced in 2022 that it would take actions to ‘improve the governance and integrity of the European standardisation system’. At this time of writing this improvement initiative is still ongoing. As part of this initiative, the Commission has collected input via open calls in 2023 and 2024. The 2024 written inputs have not been published in detail, but the 2023 written inputs can all be read here. These inputs show extensive diversity in opinions between stakeholders. Some stakeholders report that the EU standardisation system is working well, and see no need for significant updates, while others report that it is not working well at all, and that significant reforms are needed.

Among this second group, a common theme is the need to ensure greater participation from non-industry players, such as independent academic experts. The need for more funding to support such players and removing other barriers to participation is often mentioned. An important feature of the current process is that, while it is open to participation by representatives and experts from a very broad range of stakeholders, by default none of these representatives or experts get paid for their work, or reimbursed for associated travel costs. While there are some limited funding sources to support participants from academia, small medium enterprises, and civil society organisations, many stakeholders feel that much more funding would be needed, in order to overcome the problem of including more stakeholders and experts. Reasons for including more parties would be to create more (trust in) democratically balanced outcomes, and to ensure that there is enough expertise and workforce in the committee to finish the standards writing process within reasonable time.

7. Further Reading

Official information on JTC21:

• The ‘Joint Technical Committee 21: Artificial Intelligence’ page is here. 
• The JTC21 outreach website is here.
• JTC21 also publishes newsletters that report on, and raise awareness of, its standardization activities.
• Some additional information on the JTC21 work programme (also covering standards not related to the Standardisation Request, and the writing of some technical reports) is here.

On how standardisation works in the EU and AI Act context: 

• Regulation (EU) No 1025/2012, available here, has a full description of EU standardisation.
• The CEN-CENELEC internal regulations governing standards work are available here.
• For AI Act specific coverage, see also this paper from 2021 and this report from 2024.

Research papers and reports on various aspects of AI Act standards development, some of these include insights based on interviewing experts working in JTC21:

• Christine Galvagna Inclusive AI governance, Civil society participation in standards development. 2023. See also here for a summary of an event discussing this paper.
• Mélanie Gornet, Hélène Herman. A peek into European standards making for AI: between geopolitical and economic interests. 2024. hal-04784035
• Mélanie Gornet. Too broad to handle: can we ”fix” harmonised standards on artificial intelligence by focusing on vertical sectors?. 2024. hal-04785208

Notes and References

1.  Note that ‘European community’ is not the same as the European union, but refers to all countries who are CEN and CENELEC members. This for example includes the UK. ↩︎