Skip to content
AIAssuranceLabs
Menu

Art. 55: Obligations of providers of general-purpose AI models with systemic risk under the EU AI Act

Art. 55 requires the provider of a general-purpose AI model with systemic risk, classified under Art. 51, to evaluate the model with state-of-the-art protocols and documented adversarial testing, to assess and mitigate systemic risks at Union level, to report serious incidents to the AI Office, and to keep adequate cybersecurity for the model and its physical infrastructure. In this mapping, five elements are testable, five are documentation and four are process. Regulation (EU) 2026/1744 did not move the GPAI application date In force and did not amend the Article.

Where this applies

What the text requires

Art. 55 adds four duties to the duties every provider of a general-purpose AI model carries under Art. 53 and Art. 54. The Article is gated by Art. 51(2), which presumes high impact capabilities when the cumulative amount of computation used for training, measured in floating point operations, is greater than 10^25. A harmonised standard for this Article is not yet cited in the Official Journal, so the presumption of conformity is not yet available; until one is cited, Art. 55(2) lets the provider rely on a code of practice under Art. 56.

What the text requires and how each element is verified
RequiresTestableDocumentationProcess
  1. Art. 55(1)Providers of general-purpose AI models with systemic risk have the obligations in Art. 53 and Art. 54. They also have the four obligations in points (a) to (d) of this paragraph.
  2. Art. 55(1)(a)The provider performs model evaluation in accordance with standardised protocols and tools that reflect the state of the art. The evaluation includes adversarial testing of the model. The provider conducts and documents the adversarial testing. The purpose of the evaluation is to identify and mitigate systemic risks.
  3. Art. 55(1)(b)The provider assesses possible systemic risks at Union level. The provider mitigates those risks. The assessment includes the sources of the risks. The risks are those that may stem from the development, the placing on the market, or the use of general-purpose AI models with systemic risk.
  4. Art. 55(1)(c)The provider keeps track of relevant information about serious incidents and possible corrective measures to address them. The provider documents that information. The provider reports that information without undue delay to the AI Office. The provider also reports it to national competent authorities, as appropriate.
  5. Art. 55(1)(d)The provider ensures an adequate level of cybersecurity protection for the general-purpose AI model with systemic risk. The protection also covers the physical infrastructure of the model.
  6. Art. 55(2)The provider may rely on a code of practice within the meaning of Art. 56 to show that it meets the obligations in paragraph 1, until a harmonised standard is published. A European harmonised standard grants the presumption of conformity to the extent that the standard covers those obligations. No harmonised standard for this Article is cited in the Official Journal as of the verified-on date. A provider that does not adhere to an approved code of practice and does not apply a European harmonised standard demonstrates alternative adequate means for assessment by the Commission.
  7. Art. 55(3)Any information or documentation obtained under this Article, including trade secrets, is treated in accordance with the confidentiality obligations in Art. 78.
  • Model evaluation under Art. 55(1)(a): for each identified systemic risk, an evaluation is run with a named protocol and tool set that reflects the state of the art, and the result is recorded against a stated acceptance criterion
  • Adversarial testing under Art. 55(1)(a): a red-team campaign with defined attack classes, elicitation methods and a success criterion per attack is executed against the model, and each outcome is recorded
  • Mitigation effectiveness under Art. 55(1)(b): each safety mitigation is re-tested with the same evaluation and attack set, and the change from the pre-mitigation baseline is measured
  • Model cybersecurity under Art. 55(1)(d): unauthorised access to model weights, model extraction through the serving interface, training-data poisoning and prompt injection are attempted under a documented threat model, and the result of each attempt is recorded
  • Systemic-risk classification gate under Art. 51(2): cumulative training compute is calculated from the training records in floating point operations and compared with the presumption in Art. 51(2), with the calculation method recorded
  • Adversarial testing documentation under Art. 55(1)(a): the campaign design, the attack set, the elicitation methods, the results and the model version tested
  • Systemic risk assessment record under Art. 55(1)(b): the identified systemic risks at Union level, their sources across development, placing on the market and use, and the mitigations chosen for each
  • Serious incident documentation under Art. 55(1)(c): the relevant information about each serious incident and the possible corrective measures, in the form reported to the AI Office
  • Cybersecurity measures description under Art. 55(1)(d): the threat model and the controls for the model and for its physical infrastructure, including weight storage, training infrastructure and the serving path
  • Means of demonstration under Art. 55(2): adherence to a code of practice under Art. 56, or the alternative adequate means submitted for Commission assessment; where the provider follows the GPAI Code of Practice, Safety and Security chapter, the Safety and Security Framework and the Safety and Security Model Report are the documents that show it
  • Systemic risk mitigation under Art. 55(1)(b): mitigations are applied and reviewed across the model lifecycle, from development through placing on the market and use
  • Serious incident tracking and reporting under Art. 55(1)(c): incidents are tracked continuously and reported without undue delay to the AI Office and, as appropriate, to national competent authorities
  • Cybersecurity maintenance under Art. 55(1)(d): the protection of the model and its physical infrastructure is kept at an adequate level as threats and the model change
  • Confidential handling under Art. 55(3): information and documentation submitted under this Article, including trade secrets, is identified so that it receives the Art. 78 treatment

Metrics and where thresholds come from

Threshold sources, in order of precedence

  1. A harmonised standard cited in the Official Journal (none as of the anchor date)
  2. A JTC 21 draft standard (prEN), with its stage
  3. An ISO/IEC standard or technical report, with its stage
  4. A Commission guideline or code of practice, with its date from the standards data
  5. NIST AI RMF or a sector framework
  6. The state of the art, which the provider justifies and documents

Regulation (EU) 2024/1689 sets no numeric threshold for any duty in Art. 55: no evaluation score, attack success rate, incident count or security level is stated. The one number in scope is the classification gate, not a test threshold: under Art. 51(2), a general-purpose AI model is presumed to have high impact capabilities when the cumulative amount of computation used for its training, measured in floating point operations, is greater than 10^25, and Art. 51(3) lets the Commission amend that figure by delegated act. No harmonised standard for Art. 55 is cited in the Official Journal, and no JTC 21 draft covers general-purpose models, so the hierarchy level in use today is the Commission code of practice level: the GPAI Code of Practice, Safety and Security chapter, with its published date from data, supported by NIST AI RMF 1.0 and ISO/IEC TR 24029-1:2021 for metric selection and method categories. No published threshold exists for evaluation results, attack success or risk acceptance; the provider justifies each target against the model's capabilities and its intended and reasonably foreseeable uses, and the PR-15-ROB target-justification step records that justification and its source.

Metric sources and their stage
Source and stageTitleWhat it provides hereVerified on
GPAI Code of PracticePublishedGeneral-Purpose AI Code of Practice (transparency, copyright, safety and security chapters)Safety and Security chapter: the Safety and Security Framework, systemic risk identification and analysis with state-of-the-art model evaluations and adversarial testing, safety and security mitigations, the Safety and Security Model Report and serious incident reporting that an Art. 55(1)(a) to (d) evidence review checks against

Verified on European Commission, The General-Purpose AI Code of Practice

NIST AI RMF 1.0PublishedAI Risk Management FrameworkMeasure and Manage functions: the rationale for selecting evaluation metrics and the record of mitigation decisions that structure Art. 55(1)(a) and (b) evidence

Verified on NIST, AI Risk Management Framework

ISO/IEC TR 24029-1:2021PublishedAssessment of the robustness of neural networks, overviewrobustness assessment method categories (statistical, formal, empirical) that structure the adversarial testing campaign under Art. 55(1)(a)

Verified on ISO catalogue, ISO/IEC TR 24029-1:2021

Commission guidelines on GPAI scopePublishedGuidelines on the scope of obligations for providers of general-purpose AI models under the AI Actthe Commission's criteria for the systemic-risk classification under Art. 51 and for estimating training compute against the Art. 51(2) presumption, which gate Art. 55

Verified on European Commission, Guidelines on the scope of obligations for providers of general-purpose AI models

Procedures

Each protocol is versioned; its page states the derivation from the standards above. PR-15-ROB v1.0 covers the evaluation, adversarial testing, mitigation re-test and model cybersecurity elements, with the same method categories it applies under Art. 15. PR-CLS v1.0 records the Art. 51(2) compute determination that gates the Article.

What an assessor asks for

  • Safety and Security Framework (GPAI Code of Practice, Safety and Security chapter)
  • Model evaluation report per systemic risk (PR-15-ROB output)
  • Adversarial testing campaign record (PR-15-ROB output)
  • Systemic risk assessment and mitigation record (Art. 55(1)(b))
  • Safety and Security Model Report (GPAI Code of Practice, Safety and Security chapter)
  • Serious incident register and reporting procedure (Art. 55(1)(c))
  • Model and infrastructure cybersecurity measures description (Art. 55(1)(d))
  • Training compute determination record (PR-CLS output)

Common findings

  • Model evaluations are run on public benchmarks only, without an elicitation method that tests what the model can do when prompted adversarially
  • Adversarial testing is recorded as a narrative summary without the attack set, the success criterion or the per-attack outcome
  • The systemic risk assessment names risk categories but not the sources in the development, release or use path
  • Mitigation effectiveness is asserted from design intent and is not re-measured after the mitigation is applied
  • Serious incident tracking exists for a deployed product but not for the model, so incidents observed by downstream providers have no path to the AI Office
  • Cybersecurity evidence covers the serving API and omits model weight storage and the training infrastructure

Questions

What does Article 55 of the AI Act require?

Art. 55 applies to providers of general-purpose AI models with systemic risk, as classified under Art. 51. It adds four duties on top of Art. 53 and Art. 54. The provider performs model evaluation with standardised protocols and tools that reflect the state of the art, including documented adversarial testing, under Art. 55(1)(a). The provider assesses and mitigates possible systemic risks at Union level, including their sources, under Art. 55(1)(b). The provider tracks, documents and reports serious incidents and possible corrective measures to the AI Office without undue delay under Art. 55(1)(c). The provider ensures an adequate level of cybersecurity for the model and its physical infrastructure under Art. 55(1)(d). The GPAI Code of Practice, Safety and Security chapter, is the published reference for how each duty is met. Regulation (EU) 2026/1744 did not amend Art. 55.

What are the Article 55 obligations of providers of general-purpose AI models with systemic risk?

Art. 55(1)(a) requires model evaluation in accordance with standardised protocols and tools reflecting the state of the art, including conducting and documenting adversarial testing. Art. 55(1)(b) requires assessment and mitigation of possible systemic risks at Union level, including their sources, from development, placing on the market or use. Art. 55(1)(c) requires keeping track of, documenting and reporting serious incidents and possible corrective measures to the AI Office and, as appropriate, to national competent authorities. Art. 55(1)(d) requires an adequate level of cybersecurity protection for the model and its physical infrastructure. Art. 55(2) lets the provider rely on a code of practice under Art. 56 until a harmonised standard is published; no harmonised standard is cited in the Official Journal as of the verified-on date. Art. 55(3) applies the Art. 78 confidentiality obligations to everything obtained under the Article.

Which EU AI Act Article 55 systemic risk obligations are testable?

Four elements of Art. 55 are testable. The model evaluation under Art. 55(1)(a) produces a recorded result per systemic risk against a stated acceptance criterion. The adversarial testing under Art. 55(1)(a) produces a recorded outcome per attack. Mitigation effectiveness under Art. 55(1)(b) is measured by re-running the same evaluation and attack set after the mitigation and comparing with the baseline. Model cybersecurity under Art. 55(1)(d) is tested by attempted weight access, model extraction, training-data poisoning and prompt injection under a documented threat model. PR-15-ROB covers these four elements. The classification gate under Art. 51(2) is checked by PR-CLS from the training records. Serious incident reporting under Art. 55(1)(c) and the Art. 55(2) route are documentation and process elements, not tests. The Act sets no numeric threshold for any of the four tests; the GPAI Code of Practice, Safety and Security chapter, is the published reference for the evaluation and mitigation practice.

When does a GPAI model have systemic risk under Article 51?

Art. 51(1)(a) classifies a general-purpose AI model as a model with systemic risk when it has high impact capabilities evaluated with appropriate technical tools and methodologies, including indicators and benchmarks. Art. 51(1)(b) adds a model that the Commission designates, ex officio or after a qualified alert from the scientific panel, as having equivalent capabilities or impact against the Annex XIII criteria. Art. 51(2) presumes high impact capabilities when the cumulative amount of computation used for training, measured in floating point operations, is greater than 10^25. Art. 51(3) lets the Commission amend that figure by delegated act. The Commission guidelines on GPAI scope give the criteria for the determination and for estimating training compute. PR-CLS records the compute calculation and the resulting classification. A model classified under Art. 51 carries the Art. 55 duties in addition to Art. 53 and Art. 54.

How we test this

We test the model against Art. 55(1)(a) with a per-risk evaluation and an adversarial campaign that records the attack set, the success criterion and each outcome, we re-measure every mitigation against its pre-mitigation baseline under Art. 55(1)(b), and we verify the controls on model weights, training infrastructure and the serving path against a documented threat model under Art. 55(1)(d). We prepare the evidence the AI Office or an assessor asks for; the scope limits are stated on what we cannot do.

What we cannot do

  • We do not perform conformity assessments where a notified body is required.
  • We do not issue CE marking or the EU Declaration of Conformity.
  • We are not a notified body.
  • We do not give legal opinions on classification or liability.
  • We test against requirements, prepare evidence, and structure documentation; compliance decisions remain with the provider or deployer, their notified body, and their counsel.

Read the full statement