Scope: when Article 55 applies and how systemic risk is determined
Article 55 applies exclusively to providers of general-purpose AI (GPAI) models classified as having systemic risk under Article 51. A model is presumed to present systemic risk when the cumulative training compute exceeds 10^25 floating-point operations. The European Commission may also designate models based on high-impact capabilities or other Article 51 criteria. Classification therefore depends on training-compute thresholds and capability assessments that may require provider disclosure of training details and evaluation results.
Most GPAI provider obligations, including Article 55 duties for systemic-risk models, become applicable 12 months after entry into force of Regulation (EU) 2024/1689, that is from August 2025, with codes of practice and supporting measures phased earlier. Detailed technical standards, evaluation protocols, and AI Office reporting templates were still maturing in the period after entry into force, so enterprise programs should stay adaptable as implementing guidance is published.
For AI governance leaders, the first operational step is inventory: identify which current or planned GPAI models meet or are likely to meet Article 51 indicators, and obtain provider attestation or compute disclosures where available. Fine-tunes, distilled models, and heavily modified derivatives may raise interpretation questions; treat borderline cases as elevated risk until provider position and guidance are clear.
Core Article 55 obligations and ongoing operational processes
Article 55 imposes four interconnected duty areas on systemic-risk GPAI providers.
Model evaluation. Providers must perform model evaluation using state-of-the-art standardised protocols and tools, including documented adversarial testing aimed at identifying and mitigating systemic risk. In practice this implies red-teaming, safety benchmarking, and written treatment of residual risks such as large-scale harmful capabilities or loss-of-control scenarios.
Systemic-risk assessment and mitigation. Providers must assess and mitigate possible systemic risks at Union level that may stem from development, placing on the market, or use of the model. This is not a one-time market-entry checkbox; it is an ongoing risk-management cycle tied to model versions, capability updates, and known misuse patterns.
Serious-incident tracking and reporting. Providers must track, document, and report without undue delay to the AI Office, and as appropriate to national competent authorities, relevant information about serious incidents and possible corrective measures. The EU AI Office is the primary body for receiving those reports and overseeing GPAI systemic-risk compliance at Union level. Precise definitions of serious incident and exact reporting timelines continue to depend on further guidance, so internal detection and escalation paths should be designed for short decision cycles.
Cybersecurity. Providers must ensure an adequate level of cybersecurity protection for the GPAI model with systemic risk and the physical infrastructure of the model. That scope reasonably extends to model weights, serving infrastructure, and supply-chain components that could enable extraction or misuse.
Enterprises do not perform these provider duties themselves, but they should map each obligation to the evidence they expect to receive contractually and to the residual controls they must run on their own side.
Provider duties versus enterprise deployer responsibilities
Article 55 obligations rest on the GPAI model provider. Enterprise deployers and integrators are not directly subject to Article 55. They may still carry separate AI Act duties, for example as deployers of high-risk systems when applicable, along with contractual and organisational risk-management responsibilities.
Clear accountability boundaries matter for regulators, auditors, and customers. Procurement documents, data-protection and AI risk assessments, and AI governance policies should state which party owns model evaluation, systemic-risk mitigation, serious-incident notification to the AI Office, and baseline cybersecurity of the foundation model. Provider-supplied model cards and evaluation summaries should be stored separately from enterprise-specific fine-tunes, retrieval corpora, agent orchestrations, and tool integrations so that evidence of each party’s role remains distinguishable.
| Duty area | GPAI provider (Art. 55) | Enterprise deployer |
|---|---|---|
| Model evaluation | State-of-the-art evaluation, adversarial testing, residual-risk treatment | Request summaries; retain versioned evidence; do not rely on unvalidated claims alone |
| Systemic-risk mitigation | Ongoing Union-level assessment and mitigation across model versions | Map residual use-case risk; control fine-tunes, RAG, and agent tooling |
| Serious incidents | Track, document, and report to the AI Office without undue delay | Detect anomalies; escalate to provider; support any other regulatory duties |
| Cybersecurity | Protect model weights, serving infrastructure, and related supply chain | Secure access paths, credentials, agent runtime, and enterprise integrations |
Contractually, organisations should seek rights to receive Article 55 evaluation summaries, systemic-risk assessment updates, serious-incident notices affecting the model, and cybersecurity assurances. Without those flows, downstream users cannot reconstruct what the provider knew, when they knew it, or which mitigations were claimed at the time of deployment.
Board-level or AI governance committee oversight should track which deployed models carry systemic-risk designation and the status of provider compliance evidence. Cross-functional ownership across security, legal, model risk, and incident response is required so that monitoring findings and escalation paths do not stall between teams.
Implementation considerations for AI governance leaders
Translate Article 55 awareness into a repeatable operating model rather than a one-off legal review. Start with model classification against Article 51 indicators and maintain a living register of systemic-risk status and provider evidence. Align contractual clauses to the four duty areas so evaluation summaries, incident notices, and cybersecurity assurances arrive on known channels and timelines.
Define internal serious-incident playbooks that cover detection thresholds, severity classification, escalation to the provider, and support for any regulatory notification the organisation may face under other AI Act roles or sector rules. Continuous monitoring should watch for anomalous agent behaviour, high-risk tool invocations, and output patterns that could indicate emerging issues in the enterprise context, even when root cause analysis still depends on provider investigation.
Retain versioned records of model IDs, evaluation results received, access policies, mitigation actions, and configuration baselines. Codes of practice and AI Office guidance will further specify evaluation protocols and reporting formats; keep governance frameworks modular so new templates can be adopted without redesigning the entire control stack.
Trussed AI provides runtime governance and security for enterprise AI agents, including policy enforcement, agent identity and permissions, tool governance, monitoring, and audit logging. Those capabilities can contribute evidence of controlled downstream use. They do not substitute for provider Article 55 compliance or for legal determination of role under the Act.