Foundation model providers face a layered compliance stack under the EU AI Act. Article 53 sets baseline obligations for all general-purpose AI (GPAI) models: technical documentation, downstream transparency information, copyright policy, and a public training-data summary. Article 55 adds stricter duties for GPAI models designated as having systemic risk, including standardized evaluation, adversarial testing, Union-level risk mitigation, serious incident reporting, and cybersecurity protections.
EU AI Act Article 55 matters because the largest frontier labs and several open-weight releases cross the systemic risk threshold. Enforcement RFIs sent to more than 30 providers in September 2026 focused heavily on security evaluation and monitoring, the same themes Article 55 encodes. This guide explains what Article 55 covers, how systemic risk is designated, technical documentation under Annex XI, open-source carve-outs, how US labs are responding, and provider versus deployer duties. Evaluate your AI chatbot and API vendors against EU AI Act compliance expectations before integrating frontier models into EU-facing products.
What Article 55 Covers for Foundation Model Providers
Article 55 applies in addition to Articles 53 and 54; it governs providers of GPAI models with systemic risk, not every SaaS wrapper or narrow fine-tuned model. A GPAI model displays significant generality and can perform a wide range of distinct tasks. Systemic risk means the model's capabilities could cause large-scale negative effects at Union level if misused or if safety measures fail.
Article 55(1) requires providers of systemic-risk GPAI models to:
- Perform model evaluation using standardized state-of-the-art protocols, including documented adversarial testing to identify and mitigate systemic risks.
- Assess and mitigate possible systemic risks at Union level, including their sources across development, placement on market, and use.
- Track, document, and report serious incidents without undue delay to the AI Office and relevant national authorities, including corrective measures.
- Ensure adequate cybersecurity protection for the model and its physical infrastructure.
Providers may demonstrate compliance through approved codes of practice under Article 56 until harmonized standards publish. Compliance with European harmonized standards grants presumption of conformity. Providers who skip approved codes or standards must show alternative adequate means of compliance to the Commission.
Article 55 does not replace Article 53. Systemic-risk providers must still maintain copyright policies, publish training-data summaries, keep technical documentation, and provide Annex XII information to downstream integrators unless a narrow open-source exception applies (and even then, copyright and summary duties remain).
Systemic Risk Designation and the Compute Threshold
A GPAI model is presumed to have systemic risk when training compute exceeds 10^25 floating-point operations (FLOPs), unless the provider rebuts the presumption with evidence. The European Commission can update this threshold and designate additional models based on capabilities, impact, and criteria in Annex XIII, even below the compute line.
| Designation path | Trigger | Article 55 applies? |
|---|---|---|
| Compute presumption | Training FLOPs > 10^25 | Yes, unless provider successfully rebuts |
| Commission designation | High-impact capabilities per Annex XIII criteria | Yes, even below compute threshold |
| Standard GPAI | Below threshold, not designated | Article 53 only (plus Article 54 for non-EU reps) |
| Open-source GPAI | Free license, public weights and architecture | Article 53 partial exemption; Article 55 still applies if systemic risk |
Serious incidents under GPAI rules include outcomes such as death or serious health harm, serious disruption of critical infrastructure, infringement of EU fundamental-rights protections, or serious harm to property or the environment. Providers must document near-misses that inform risk assessment even when reporting thresholds are not met.
Technical Documentation Requirements Under Annex XI
Annex XI defines technical documentation for all GPAI providers under Article 53(1)(a); Section 2 adds evaluation, adversarial testing, and architecture detail for systemic-risk models under Article 55. Documentation must stay current across the model lifecycle and be available to the AI Office on request.
Section 1: All GPAI providers
| Documentation element | Required content |
|---|---|
| General model description | Intended tasks, acceptable use policies, release date, distribution, architecture, license |
| Development process | Training methodology, design choices, optimization targets, integration requirements |
| Training and evaluation data | Provenance, curation, bias detection, data volume and scope |
| Compute and energy | FLOPs, training time, known or estimated energy consumption |
| Copyright policy | Article 53(1)(c) policy to respect rights reservations and Union copyright law |
| Training data summary | Public summary per AI Office template (Article 53(1)(d)) |
Section 2: Systemic-risk providers (Article 55)
- Detailed evaluation strategies with results, metrics, limitations, and methodologies (public benchmarks or proprietary protocols).
- Description of internal and external adversarial testing (red teaming), plus alignment and fine-tuning measures.
- System architecture diagram explaining how software components integrate into overall processing.
Annex XII separately requires information for downstream providers integrating the GPAI model into AI systems. Buyers should request Annex XII packets during procurement, not wait for a regulator RFI to expose gaps.
Provider Duties Versus Deployer Duties Under GPAI Rules
Providers build or place GPAI models on the market; deployers use AI systems in professional or operational contexts. Article 55 binds providers of systemic-risk GPAI models, while deployers inherit obligations based on how they apply any model.
| Obligation | GPAI provider (Art. 53/55) | Deployer (e.g., SaaS buyer) |
|---|---|---|
| Technical documentation (Annex XI) | Create and maintain; provide to AI Office on request | Request summary from provider; keep internal use-case records |
| Training data summary | Publish publicly per AI Office template | Review before procurement; not required to publish own summary |
| Adversarial testing | Required for systemic-risk models (Art. 55) | May run application-level red teams; not a substitute for provider duties |
| Serious incident reporting | Report model-level incidents to AI Office (Art. 55) | Report high-risk system incidents to national authorities (Art. 73) |
| Cybersecurity | Protect model weights, training infra, release pipeline | Secure integrations, API keys, customer data flows |
| Transparency to end users | Downstream info via Annex XII; public training summary | Disclose AI interaction for chatbots; label synthetic content |
| High-risk conformity | Provider duties if placing high-risk AI system on market | Human oversight, logging, monitoring, FRIA where applicable |
When the same organization both trains a foundation model and deploys it in products, it may hold both provider and deployer roles simultaneously. US frontier labs typically act as providers to EU deployers via APIs. Contractual pass-through of Annex XII information and incident notification SLAs closes the most common gap.
Open-Source GPAI Exceptions and Their Conditions
Article 53(2) exempts qualifying open-source GPAI releases from technical documentation duties (Article 53(1)(a)) and downstream integrator documentation (Article 53(1)(b)), but not from copyright policy or public training-data summaries. The exemption does not apply to systemic-risk models.
To qualify for the open-source carve-out, a model must be:
- Released under a free and open-source license permitting access, use, modification, and distribution without monetization restrictions on the model itself.
- Published with parameters including weights, architecture information, and usage information publicly available.
- Below systemic risk designation (not above 10^25 FLOPs presumption and not Commission-designated).
Open release does not automatically satisfy transparency goals. Training data may remain opaque even when weights are public, which is why Article 53(1)(c) and (d) still apply. A popular open-weight model that crosses the compute threshold becomes a full Article 53 plus Article 55 provider overnight, with no documentation exemption.
Non-EU open-source providers may also use the Article 54 authorized representative exemption when open-source conditions are met. Systemic-risk open models must appoint representatives and comply with full documentation, evaluation, and reporting duties like closed frontier labs.
How US Frontier Labs Are Responding to Article 55
US-based frontier labs face direct EU supervision because GPAI obligations attach to models placed on the EU market, regardless of corporate headquarters. September 2026 RFIs reportedly reached OpenAI, Google, Anthropic, and other global providers, though Brussels has not confirmed names. Observable industry responses cluster into four patterns.
Expanded transparency publications
Leading labs updated system cards, model specs, and safety reports to align with training-data summary templates and Annex XII downstream packets. Public summaries remain high-level; regulators may request fuller Annex XI files privately.
External evaluation partnerships
Labs commission or publish third-party red-team and benchmark results to satisfy Article 55 evaluation duties. Independent evaluation was a named theme in Virkkunen's August 29 enforcement statement. Buyers should ask whether evaluations cover the exact model version they deploy.
Code of practice signatories
Many frontier providers signed the GPAI Code of Practice to demonstrate compliance pathways under Article 56 while harmonized standards remain in development. Signatory status does not immunize providers from RFIs or Article 101 penalties for incomplete replies.
EU authorized representatives and legal entities
Non-EU providers appoint authorized representatives under Article 54 unless a valid open-source exemption applies. Legal teams map which corporate entity answers AI Office requests and how incident escalation reaches US engineering teams across time zones.
Deployers consuming US APIs should verify: (1) training-data summary URL and update cadence, (2) whether the served model version is systemic-risk tier, (3) incident notification commitments in enterprise agreements, and (4) geographic data processing terms affecting EU user data in fine-tuning or logging pipelines.
Model Evaluation, Adversarial Testing, and Cybersecurity Under Article 55
Article 55(1)(a) requires standardized evaluation plus documented adversarial testing; paragraph (d) requires adequate cybersecurity for the model and physical infrastructure. These duties overlap in practice because the same red-team findings often drive both evaluation reports and security control roadmaps.
Evaluation protocols and metrics
Providers should document which benchmarks, internal harnesses, and third-party audits cover capability, misuse, and robustness dimensions. State-of-the-art protocols evolve quickly; the Act expects reflection of current practice, not a fixed checklist from 2024. Evaluation strategies in Annex XI Section 2 must include criteria, metrics, and methodologies for identifying limitations, including known failure modes on multilingual, multimodal, and agentic tasks.
Adversarial testing means structured attempts to elicit harmful, illegal, or security-relevant behaviors, including jailbreaks, tool misuse in agent settings, and data exfiltration paths. External red teams strengthen credibility for regulators reviewing summer 2026 security incidents. Internal teams should still run continuous regression suites because external reports snapshot a single model version.
Cybersecurity measures regulators expect
Commission guidance and codes of practice reference protections against accidental weight leakage, unauthorized releases, circumvention of safety filters, cyberattacks, and model theft. Concrete measures may include:
- Segmented access to training clusters, weight stores, and release pipelines with role-based controls.
- Monitoring for anomalous export patterns from research environments to public repositories.
- Secure evaluation sandboxes with network egress policies reviewed after agent escape incidents.
- Incident response playbooks that distinguish security events from model quality regressions.
- Physical security for data centers hosting frontier training and inference at scale.
Energy consumption documentation under Annex XI point 2(e) supports environmental transparency and can inform systemic risk discussions about resource concentration. Where direct energy measurement is unavailable, providers may estimate from computational resources (FLOPs, GPU hours). This is documentation for authorities, not a standalone public marketing metric, though some labs publish sustainability reports voluntarily.
Copyright Policy and Training Data Transparency (Article 53 Baseline)
Even Article 55 providers must satisfy Article 53(1)(c) and (d): a copyright compliance policy and a public training-data summary using the AI Office template. September 2026 copyright-track RFIs targeted providers that skipped informal dialogues and had not published detailed summaries.
Copyright policies must address text and data mining opt-outs under Directive (EU) 2019/790, including state-of-the-art technical measures to identify rights reservations. Training summaries must be sufficiently detailed for rightsholders to exercise their rights, covering data sources, curation, and main characteristics without necessarily listing every URL in the public document.
Downstream deployers rely on these public summaries for procurement diligence but remain responsible for their own use-case compliance. A provider summary does not absolve a deployer from high-risk obligations or from ensuring that fine-tuning on proprietary customer data respects contract and GDPR requirements.
Frequently Asked Questions
What is the difference between Article 53 and Article 55?
Article 53 sets baseline GPAI provider duties for all general-purpose models. Article 55 adds systemic-risk requirements: standardized evaluation with adversarial testing, Union-level risk mitigation, serious incident reporting, and cybersecurity. Every Article 55 provider must also comply with Article 53.
Does my fine-tuned 7B model trigger Article 55?
Only if it qualifies as GPAI with systemic risk, typically via the 10^25 FLOPs training presumption or Commission designation. Many fine-tuned narrow models are GPAI under Article 3 but fall below systemic risk. Compute used only for fine-tuning counts toward thresholds depending on legal interpretation; consult counsel for borderline cases.
Is energy reporting a separate public obligation?
Known or estimated energy consumption belongs in Annex XI technical documentation provided to authorities on request, not necessarily in the public training-data summary. If energy is unknown, providers may estimate from computational resources used during training.
If a model is open source, is it exempt from Article 55?
No. Open-source status removes only Article 53(1)(a) and (b) documentation duties for non-systemic-risk models. Systemic-risk open models face full Article 55 obligations plus copyright policy and training summary requirements.
What should deployers verify from Article 55 providers?
Request Annex XII integration documentation, confirmation of systemic risk tier, serious incident notification clauses, and evidence of adversarial testing for the model version in production. Browse EU AI Act resources and compare AI chatbot vendors before signing multi-year EU contracts.
When did Article 55 become enforceable?
GPAI provider obligations, including Article 55 for systemic-risk models, became enforceable on August 2, 2026. The Commission's September 2026 RFIs were among the first public enforcement actions under those powers.
What is Annex XII and who needs it?
Annex XII specifies information GPAI providers must give to downstream integrators building AI systems on top of foundation models. Deployers and system integrators should receive Annex XII packets during technical onboarding. Missing Annex XII documentation is a procurement red flag distinct from public training summaries.
Can providers rebut the 10^25 FLOPs systemic risk presumption?
Yes. The Act allows providers to present evidence that a high-compute model does not pose systemic risk under Annex XIII criteria. Rebuttal requires substantive technical and impact analysis, not marketing assertions. Until rebuttal succeeds, providers must comply with full Article 55 duties as if the presumption stands.
