What’s in the European Union’s Codes of Practice for Governing General-Purpose AI? 

After a nine-month drafting and review process, the European Commission’s AI Office published guidance on July 10, 2025 for how to comply with the EU AI Act’s provisions for General-Purpose AI (GPAI). 

First, let’s address a source of confusion. Comprising three chapters, the published Code of Practice should in fact be seen as three separate Codes, each tackling a different set of issues and different affected stakeholders. The three Codes cover Copyright, Transparency, and Safety and Security, with this analysis post predominantly focused on the latter. Contrary to the other two, the Code on Safety and Security applies only to “GPAI models that pose systemic risks.” These models are the most dangerous ones, built by only 5-15 different providers, and require significant capital investment. 

Below, we share background information on the creation of the three Codes and present our high-level view on the drafting process, and whether it lived up to its ambitions. We also highlight some measures that we consider particularly promising for bringing about safe and trustworthy AI, as well as identify remaining gaps.

An unworthy end to an inclusive Codes of Practice process

At its start, the European Commission committed to ensuring an inclusive drafting process of the Codes of Practice, reflecting the EU’s vibrant academic, civil society, and SME ecosystems. Unfortunately, the process’s end failed to deliver on its promise. Once the official drafting process concluded in March, a small number of leading U.S. tech providers gained exclusive access to a fourth drafting round. Through lobbying efforts, they secured significant changes to the text. The weakened version of the Codes, published on 10 July, comes at the cost of European citizens and businesses, and misses opportunities to advance safe AI worldwide. It also undermines all the other stakeholders who have seen their engagement and efforts to serve the public interest brushed aside due to corporate lobbying by U.S. Big Tech. 

Three measures in the GPAI Safety and Security Code that effectively reduce AI risk

The following measures in the Safety and Security Code can be considered particularly promising for bringing about safe and trustworthy AI. Subsequently, we identify three measures that we deem as particularly insufficient. We invite other organisations to conduct similar analysis, including by examining the merits and gaps of the Codes on Transparency and Copyright.

A broad set of systemic risks must be analysed

Appendix 1.1, Measure 2.1(1) The question of what kinds of systemic risks GPAISR providers must assess and mitigate has been one of the most heatedly debated issues throughout the drafting process. Draft versions introduced a tiered system, splitting systemic risks in two: mandatory and optional. As risks to fundamental rights were presented in the second tier, this resulted in a great public outcry, including from key lawmakers behind the AI Act. While the published Safety and Security Code maintains a list of pre-selected systemic risks (Appendix 1.4), it also requires providers to systematically analyse whether other risks amount to systemic risk, including  risks from child sexual abuse material (CSAM), risks to public mental health, or risks from major accidents (Annex 1.1). Providers must document this process as part of their Model Report (Measure 7.3(a)), inviting scrutiny on why certain risks were excluded from further assessment. This is an important step towards a broader understanding of GPAISR risks, going beyond the narrow focus currently propagated in the industry.

External evaluations are required for some GPAI models posing systemic risks

Appendix 3.5 There is broad consensus in the scientific community that independent testing of GPAI is crucial. The Safety and Security Code requires external evaluations, only allowing providers to claim exemption if they can show that their model is similarly safe to another model that has proven compliant with the Code. This notion of “similarly safe” hinges on similar performance on benchmarks and the comparability of other model characteristics, such as their architecture (Appendix 2.2). Importantly, the Code also acknowledges that this kind of information is normally only available for models from the same provider, or potentially for open-weights or open-source models. Taken together, this results in a stringent set of requirements. In an industry where every release has to be justified on the grounds of enhanced performance or some novel feature, the Code makes external evaluations de facto mandatory.

Public transparency is instantiated

Measure 10.2 The Code requires providers to publish a summarised version of their Model Report in their website, which includes important information such as the risks associated with a given model. In light of recent cutbacks on voluntary transparency from providers, this is a positive step forward. The inclusion of this commitment is largely the result of a last-minute, concerted effort from multiple stakeholders, following an earlier announcement that it would be removed from the Code. Not only does such transparency invite public scrutiny, but it also helps build the trust necessary for widespread, beneficial AI adoption. An important specification missing from Measure 10.2 is the timeline for publishing the Model Report. We urge providers to ensure minimal delay between releasing a new model and sharing critical information publicly.

Three key gaps in the GPAI Safety and Security Code

Official reporting timelines are delayed to the time of deployment

Measure 7.7 Providers must share their full Model Report with the EU AI Office only after deployment. This perpetuates providers’ “deploy first, question later” mentality, which means that potentially dangerous models get to European users without receiving any meaningful scrutiny from the AI Office. Furthermore, corrective action that the AI Office may request when a model fails to comply becomes very expensive both politically and financially. In the extreme, this may require withdrawing a model from the market, which disrupts its use, from end-users directly, or in thousands of downstream applications, which fuels the perception of overregulation. Instead, we believe reporting mechanisms should enable a constructive dialogue between the AI Office and providers throughout development, where an interim Model Report and other key information are shared at least eight weeks prior to release.

Emergency preparedness requirements have been removed

[Measure removed] Even though the development of plans and procedures to contain damage in case of emergencies is standard practice in other high-risk industries, providers of GPAISR no longer have to develop such protocols. This is concerning since the nature of these models means that harm can diffuse at unprecedented speed and scale. Such emergencies may entail a security breach in a model or a hazardous malfunction. Thus, we have been advocating for the creation of emergency plans, in which providers devise emergency scenarios, including early warning systems for their detection, and define specific mitigations in response to each scenario. Other high-risk industries only adopted emergency preparedness frameworks after major accidents. Learning from their mistakes, this means that we must mandate GPAISR providers to plan ahead for emergencies.

Providers are not held accountable during the development of their models

[Multiple measures removed] The removal of measures for systemic risk mitigation during development and for adequacy assessment are examples of how the Code has disempowered authorities and internal safety and security officers at various providers. Indirectly, the removal of explicit whistleblower protection and in-development go/no-go decisions requirements will also result in even less information about systemic risk mitigation being shared with the authorities, and therefore less oversight. 

From rules to outcomes

The published Safety and Security Code reflects a striking shift from a framework that is rule-based to one that is outcome-based. Whereas earlier drafts proposed specific Key Performance Indicators that would indicate adherence to the Code, similar to the Strengthened Code of Practice on Disinformation, the final version focuses on broad outcomes. This leaves it to providers to choose the appropriate means for achieving those. For example, it requires providers to “assess risks along the entire model lifecycle” (Measure 1.2), but gives providers full discretion over choosing the evaluation methods and defining appropriate milestones for conducting those.

We agree that the Code must be future-proof and able to keep up with new technological developments. While this means that the Code cannot be overly prescriptive, it now gives providers extreme leeway in all aspects of their risk management. This raise the bar for enforcement and requires providers to act in good faith.