Art. 52 EU AI Act: the systemic-risk notification procedure
Art. 52 sets out the procedure that connects to the systemic-risk classification of Art. 51. A provider must notify the Commission without delay, and within two weeks, when its general-purpose AI model meets or is foreseen to meet the systemic-risk threshold. The provider can argue, with the notification, that its model does not present systemic risk despite crossing the threshold. The Commission maintains and publishes a list of GPAI models with systemic risk.
The notification duty
Art. 51 defines when a model has systemic risksystemic riskEU AI Act category for the most capable general-purpose models (presumed above a training-compute threshold), triggering extra duties: evaluations, adversarial testing, incident reporting, cybersecurity.Open full entry →; Art. 52 sets out what a providerproviderThe actor who develops an AI system (or has it developed) and places it on the market or into service under its own name. It carries manufacturer-style duties: design controls, documentation, conformity.Open full entry → must do about it. When a general-purpose AI modelgeneral-purpose AI modelEU AI Act term for a model displaying significant generality and capable of many distinct tasks, typically integrated into downstream systems; carries its own obligation set, with extra duties for models posing systemic risk.Open full entry → meets the condition for systemic riskriskIn the EU AI Act's terms, the combination of the likelihood that a harm occurs and the severity of it if it does. The link between a principle (via the harm that would breach it) and a control (the measure that reduces it). Naming the harm and assessing its risk is required by Art. 9 before any mitigation measure is chosen. See harm, control, residual risk.Open full entry →, that is, when it reaches or is reasonably foreseen to reach the 10^25 FLOP compute threshold, the provider must notify the Commission. The notification is due without delay and in any event within two weeks of the moment the provider knows or should foresee that the threshold is met. Reaching the threshold and failing to notify is itself a breach that the Commission's enforcement powers can address.
Contesting the presumption
The systemic-risk threshold is a presumption, and Art. 52 builds in the route to rebut it. Together with the notification, a provider may present arguments to demonstrate that, exceptionally, its model does not present systemic risk despite meeting the compute threshold, because it does not in fact have high-impact capabilities matching the most advanced models. The Commission assesses those arguments. If it does not accept them, the model is classified as systemic risk and the Art. 55 obligations apply.
The procedure also runs in the other direction over time. A provider whose model has been classified as systemic risk can request a reassessment based on new, concrete reasons if circumstances change, so the classification is not permanently fixed once made.
The Commission's list
Art. 52 requires the Commission to publish and keep up to date a public list of the general-purpose AIgeneral-purpose AIA model trained on broad data that can be adapted to many downstream tasks; the AI Act sets specific obligations for it, with extra duties when it poses systemic risk.Open full entry → models classified as having systemic risk. This list is the transparencytransparencyOpenness about the fact that AI is used and how it operates in general: disclosures, documentation, notices. Pairs with explainability, which addresses individual outcomes.Open full entry → mechanism for the systemic-risk tier: it makes visible which models are subject to the heavier Art. 55 regime, which matters to downstream providersdownstream providerA provider that builds an AI system on top of another party's model, often a general-purpose model, and takes on obligations for the system it ships.Open full entry → who integrate these models and need to know the regulatory status of what they build on.
Why it matters
For the small group of providers whose models reach the frontier, Art. 52 is the operational trigger that turns the Art. 51 classification into a concrete duty with a deadline. For everyone else, the published list is the useful artifactartifactThe concrete record that proves a control was carried out: a test report, an impact assessment, a monitoring log, a release sign-off. An artifact is the tangible form evidence takes, the thing an auditor reaches for to confirm that a control was not just designed but actually operated. Each stage of the AI life cycle produces its own anchor artifact. Distinct from evidence as a whole: evidence is the proof, an artifact is one piece of it. See evidence, life cycle.Open full entry →: it is how a downstream organization can confirm whether a foundation modelfoundation modelA model trained on broad data at scale that can be adapted to many downstream tasks; called a general-purpose AI model in EU AI Act terminology.Open full entry → it relies on is a systemic-risk model carrying the full Art. 55 obligations.
In the seven pillars of responsible AI
Art. 52 is an accountabilityaccountabilityThe principle that a named human or organization answers for an AI system's outcomes, through ownership, documentation, audit trails and redress; never the system itself. The EU AI Act attaches obligations to the role rather than the technology, with provider duties in Article 16 and deployer duties in Article 26, supported by technical documentation (Article 11) and record-keeping (Article 12). See provider, deployer, record-keeping, responsible AI.Open full entry → and transparency provision. The notification duty assigns clear responsibility to the model provider, and the published list operationalizes transparency at the level of the model market, letting downstream parties see the regulatory status of the models they integrate.