EU AI Act Article 51: GPAI Models With Systemic Risk Explained

# EU AI Act Article 51: GPAI Models With Systemic Risk Explained Article 51 of the EU AI Act establishes the criteria for classifying a general-purpose AI model as a model with systemic risk, and understanding this classification determines whether your organisation faces a significantly heavier compliance burden under Article 53. ## What the EU AI Act Says Article 51 sets out two routes by which a GPAI model is designated as having systemic risk. **The compute threshold (Article 51(1)(a)):** A GPAI model is presumed to carry systemic risk if it was trained using a cumulative compute exceeding 10^25 floating point operations (FLOPs). This is a hard, objective number. It does not require a regulator to make a qualitative judgement about the model's capabilities. If training crossed that compute line, the model is in scope. **The Commission designation route (Article 51(1)(b)):** The European Commission can also designate a GPAI model as having systemic risk based on its capabilities or actual impact, even if the training compute falls below the threshold. This catch-all exists because compute is a proxy for capability, not a perfect measure. Models trained more efficiently could still present systemic risks. **The notification obligation (Article 51(2)):** Providers whose models reach or exceed the 10^25 FLOPs threshold must notify the Commission without delay. The Commission then has the ability to confirm or adjust that designation. **What "systemic risk" means in context:** Recitals and Article 51 itself clarify that the concern is about models whose capabilities are broad enough that a failure, misuse, or vulnerability could propagate across many downstream applications simultaneously, affecting large numbers of people or critical systems at scale. ## Which Models Qualify At 10^25 FLOPs, the threshold is set at or above the training compute estimated for GPT-4 class models. Publicly available estimates place GPT-4 training in the low 10^24 to mid 10^25 range. Models trained at that scale or larger, including large multimodal models and frontier language models, are the intended targets. If your organisation is training a model, the compute question is internal: you will know whether you crossed 10^25 FLOPs during the training run. If you are deploying a third-party model, you need to determine whether the provider has classified it as a systemic risk model under Article 51, because that classification changes what your provider must give you and what you may need to do internally. ## Who This Applies To **Providers of GPAI models with systemic risk:** These are organisations that develop and place the model on the EU market or put it into service in the EU. The obligations in Article 52 and Article 53 fall primarily on the provider. This means the entity that trained and released the model, not the business deploying it downstream in a product. **Downstream deployers:** If you build a product on top of a systemic risk GPAI model, you are not the Article 51 obligee. However, you are affected in two ways. First, you depend on your provider meeting their Article 52 and Article 53 obligations, which means transparency documentation and incident reporting systems need to exist upstream. Second, if your downstream use case also triggers Annex III high-risk classification, those obligations stack independently of what the GPAI provider is doing. **Company size does not exempt you from Article 51.** The systemic risk designation follows the model, not the size of the organisation. A startup that trains and releases a frontier model crosses the same threshold as a large enterprise. ## What the Obligations Actually Require Article 51 classification triggers the Article 53 obligation layer on top of the Article 52 baseline. Article 52 applies to all GPAI model providers regardless of systemic risk and covers technical documentation, transparency to downstream providers, and copyright policy. Article 53 adds four additional obligations specific to systemic risk models: **Adversarial testing (Article 53(1)(a) and 53(1)(b)):** Providers must perform model evaluations, including adversarial testing, to identify and mitigate systemic risks. This is standardised red-teaming at the model level, not just application-level testing. The AI Office is developing protocols, and the General-Purpose AI Code of Practice is the primary mechanism for translating this into practical steps. **Incident reporting (Article 53(1)(c)):** Providers must report serious incidents and possible corrective measures to the AI Office without undue delay. A serious incident is defined in Article 3 as an incident that results in, or has a reasonable likelihood of resulting in, death, serious injury, serious disruption to critical infrastructure, or significant damage to property or the environment. **Cybersecurity measures (Article 53(1)(d)):** Providers must ensure adequate cybersecurity protection for the model itself, the infrastructure, and physical access to the model. This goes beyond standard software security and extends to protecting model weights and training infrastructure. **Energy and resource reporting (Article 53(1)(e)):** Providers must document and report the known or estimated energy consumption of the model. This feeds into the Commission's ability to monitor the aggregate environmental impact of frontier AI. ## Key Deadlines **August 2, 2026:** This is the application date for GPAI obligations, including Article 51, Article 52, and Article 53. All GPAI providers, including those with systemic risk models, must be compliant by this date. The AI Office has been building the General-Purpose AI Code of Practice in the lead-up to this date, and providers are expected to participate. **February 2, 2025:** Article 5 prohibitions on unacceptable risk AI practices have already been in force since this date. If your model or application touches prohibited use cases, that obligation is not upcoming, it has already applied. **December 2, 2027:** High-risk AI systems under Annex III face their compliance date. If a systemic risk GPAI model is embedded in a high-risk application (for example, an AI system used for employment decisions or credit scoring), the Annex III obligations apply to that application separately, with a deadline of December 2, 2027. ## What to Do Now 1. **Determine your compute position.** If you have trained or are training a large model, audit your training run compute and document it. If you are uncertain whether you crossed 10^25 FLOPs, get a number from your ML infrastructure team. This is not a grey area: you either crossed the threshold or you did not. 2. **Identify your systemic risk models in your supply chain.** If you deploy products built on third-party GPAI models, ask your model provider directly whether their model has been designated or self-classified as a systemic risk model under Article 51. Get this in writing and document it in your compliance file. 3. **Engage with the GPAI Code of Practice.** The AI Office's Code of Practice is the primary path to demonstrating Article 52 and Article 53 compliance before formal standards are published. If you are a GPAI provider, participation is the practical route to compliance readiness by August 2, 2026. 4. **Build your incident reporting pipeline.** Article 53 incident reporting requires a defined internal process: who decides what constitutes a serious incident, who notifies the AI Office, and within what timeframe. That process does not exist by default. It needs to be designed and tested before August 2, 2026. 5. **Map your downstream risk surface.** If you are a deployer using a systemic risk model, understand which of your use cases might independently trigger Annex III high-risk classification. Your Article 53 obligations sit with your provider, but your Annex III obligations sit with you. ## Check Your Obligations Use the free ActComply risk screener to see which obligations apply to your system: https://www.getactcomply.com/check