Evidence ChecklistEU AI Act

GPAI evidence pack Article 53 and 55 checklist

Assemble the records a GPAI model provider needs for EU AI Act Article 53 obligations, with Article 55 extensions when the model has systemic risk.

This page helps collect technical documentation, downstream-provider information, copyright-policy evidence, a public training-content summary, and systemic-risk testing, incident, and cybersecurity records where applicable.

Author
Sorena AI
Published
May 9, 2026
Updated
Jul 24, 2026
Sections
6

Structured answer sets in this page tree.

Primary sources
13

Cited legal and guidance references.

Publication metadata
Sorena AI
Published May 9, 2026
Updated Jul 24, 2026
Overview

First decide whether the organisation places a on the Union market as its provider or merely integrates another provider's model into an AI system. Providers need the Article 53 baseline pack; providers of GPAI models with systemic risk also need the Article 55 safety, incident, and cybersecurity records. The duties apply at model level and do not replace classification of each downstream AI system.

Section 1

1. Confirm the model and provider record

Start the pack with a model-level record that is separate from product feature records. Article 53 applies to providers of general-purpose AI models, and the Commission guidance explains who must comply and what is expected from them.

Record whether the organisation is the original model provider, has placed a modified or fine-tuned GPAI model on the Union market, or is only integrating another provider's model into an AI system. Keep the model version, release date, Union market release date, distribution method, licence, dependencies, authorised representative status where relevant, and evidence of model authenticity in one place.

Chapter V applied from 2 August 2025. Providers of GPAI models placed on the market before that date must comply from 2 August 2027, while models placed on the market from 2 August 2025 entered the applicable regime immediately. The Commission's enforcement powers apply from 2 August 2026. Keep the first Union market placement date and evidence for each model version because it controls that transition.

  • Evidence to keep: legal provider name, contact point, model name and version, model family coverage, model authenticity evidence such as a secure hash or endpoint, release date, Union market release date, model dependencies, licence, and distribution channels.
  • Owner: model governance or legal owns the role decision; model engineering owns model identity, dependencies, and authenticity evidence; product owns Union distribution channels.
  • Reopen trigger: a new model version, material modification, fine-tuning path, new Union distribution channel, licence change, or provider-role change.
Section 2

2. Build the Article 53 technical documentation file

Article 53(1)(a) requires providers to draw up and keep up-to-date technical documentation of the model, including training and testing process information and evaluation results, for provision to the AI Office and national competent authorities on request.

Use Annex XI as the minimum table of contents. The pack should show what the model is intended to do, the systems it can be integrated into, acceptable use policies, release and distribution details, architecture and parameter information, input and output modalities and formats, licence, development process, data provenance and curation, training/testing/validation data, computational resources, training time, and known or estimated energy consumption.

  • Required pack section: model description, intended tasks, integration contexts, acceptable use policy, release and distribution record, architecture and parameter summary, modalities and formats, licence, development design choices, training methodology, data provenance and curation, bias-detection measures where applicable, evaluations, training compute, training time, and energy information.
  • Evidence standard: each field should identify the source system or document, last update date, evidence owner, and whether the information is intended for the AI Office, national competent authorities, downstream providers, or public release.
  • Reopen trigger: a model architecture change, new training run, new evaluation result, new data-source class, changed acceptable use policy, updated licence, or changed energy or compute estimate.
Section 3

3. Prepare downstream-provider information under Annex XII

Article 53(1)(b) creates a downstream-facing documentation duty. Providers must draw up, keep up-to-date, and make available information and documentation to providers of AI systems that intend to integrate the GPAI model into their AI systems.

The downstream pack should be written for integration decisions. It should help downstream providers understand capabilities and limitations, comply with their own AI Act duties, and integrate the model with the technical means, input/output constraints, licence, acceptable use policy, and data provenance information listed in Annex XII.

  • Downstream bundle: model tasks, intended integration contexts, acceptable use policy, release and distribution method, licence, software versions where relevant, hardware or software interactions where relevant, architecture and parameters, modalities, formats, maximum input and output size, technical integration means, and data provenance information.
  • Delivery evidence: customer documentation link, developer portal page, model card, API documentation, release notes, terms or licence page, and a change log showing when downstream-facing information changed.
  • Reopen trigger: changed capabilities or limitations, changed input/output size, new integration method, licence or acceptable-use change, or a downstream-provider request showing that current documentation is unclear.
Section 5

5. Add Article 55 records for systemic-risk GPAI models

If the model is classified or designated as a GPAI model with systemic risk, Article 55 adds obligations on top of Articles 53 and 54. Keep these records in a separate systemic-risk annex so teams can see which controls apply only to systemic-risk models.

A model is presumed to have high-impact capabilities when the cumulative amount of computation used for training exceeds 10^25 floating-point operations. That presumption is not the only route: the Commission may designate a model as presenting systemic risk based on the Annex XIII criteria, and a provider that meets the compute threshold must notify the Commission without delay and within two weeks. Keep the compute method, assumptions, threshold date, notification, and any reasoned argument that the model does not present systemic risk.

The annex should cover model evaluation, documented adversarial testing, assessment and mitigation of Union-level systemic risks and their sources, serious-incident tracking and reporting, corrective measures, and adequate cybersecurity protection for the model and its physical infrastructure.

  • Systemic-risk testing file: evaluation strategy, criteria, metrics, results, limitations, internal and external adversarial testing where applicable, red-team records, model adaptation or alignment records, and sign-off on systemic-risk acceptance or mitigation.
  • Serious-incident file: start and end dates or best approximations, resulting harm and affected group, chain of events, model involved, available evidence of the model's involvement, provider response, recommendation to the AI Office or national competent authorities, root-cause analysis, and post-market monitoring patterns such as near misses.
  • Cybersecurity file: protection objectives, access controls for model weights and infrastructure, monitoring and response evidence, security testing, vulnerability handling, and records showing how the security level is adequate for the systemic-risk profile.
Section 6

6. Evidence-pack closeout checklist

Close the pack only when every required section has an owner, source, update trigger, and evidence location. Separate authority-facing documentation, downstream-provider material, public summaries, and systemic-risk evidence instead of mixing all records into one policy document.

Do not claim Article 55 readiness unless the model has been assessed against the systemic-risk obligations and the evidence pack includes the extra testing, incident, mitigation, and cybersecurity records. Do not claim open-source exemptions without documenting the licence, public availability of parameters and architecture information, and whether the model presents systemic risk.

The Article 53(2) free and open-source exception is limited. When its conditions are met, it removes Article 53(1)(a) and (b) technical and downstream-documentation duties, but not the copyright policy or public training-content summary duties in Article 53(1)(c) and (d). Article 54(6) separately removes the authorised-representative duty for a qualifying free and open-source model. Neither exception applies to a GPAI model with systemic risk.

  • Article 53 baseline complete: technical documentation, downstream-provider information, copyright policy, and public training-content summary are present and current.
  • Recipient markings complete: every record is marked as public, downstream-provider-facing, AI Office or national competent authority on-request, or internal confidential evidence.
  • Systemic-risk annex complete if applicable: classification or designation rationale, Article 55 evaluation and mitigation records, serious-incident workflow, and cybersecurity evidence.
  • Change controls complete: model release, modification, data-source, evaluation, incident, licence, public-summary, and downstream-documentation changes each have a named review owner.
Primary sources

References and citations

digital-strategy.ec.europa.eu
Referenced sections
  • Supports separating Transparency and Copyright obligations for all GPAI providers from Safety and Security obligations for systemic-risk GPAI providers.
"Transparency, Copyright, and Safety and Security"
ec.europa.eu
Referenced sections
  • Supports concrete copyright-policy controls such as assigned responsibilities, rights-reservation handling, and crawler transparency.
"copyright policy"
ec.europa.eu
Referenced sections
  • Supports distinguishing information intended for downstream providers from information provided to the AI Office or national competent authorities on request.
"downstream providers"
eur-lex.europa.eu
Referenced sections
  • Primary legal source for systemic-risk GPAI model obligations on evaluation, systemic-risk mitigation, incident reporting, and cybersecurity.
"general-purpose AI models with systemic risk"
eur-lex.europa.eu
Referenced sections
  • Primary legal source for GPAI provider obligations in Article 53, systemic-risk obligations in Article 55, and Annex XI/XII documentation content.
"Obligations for providers of general-purpose AI models"
Related guides

Explore more topics

Are industry AI use cases high-risk under EU AI Act Annex III?
FAQ answer on when an industry AI use case falls under EU AI Act Annex III, how Article 6 classification works, when Article 6(3) can support a non-high-risk conclusion, and what evidence providers should keep.
EU AI Act AI System Classification Edge Cases FAQ
Answers for EU AI Act edge cases: AI system definition, inference versus simple rules, GPAI models, embedded products, territorial scope, roles, and classification evidence.
EU AI Act Applicability and Roles: Scope, Actor Map, and Evidence
Determine whether the EU AI Act applies to an AI system or GPAI model, map provider, deployer, importer, distributor, and product manufacturer roles, and record evidence for classification.
EU AI Act applicability test: scope, role, and risk classification
Stepwise EU AI Act applicability test for AI-system status, exclusions, territorial scope, operator role, prohibited uses, high-risk systems, GPAI models, transparency duties, and evidence records.
EU AI Act Article 5 Prohibited AI Practices Screening Guide
Screen AI systems against EU AI Act Article 5, including manipulation, social scoring, biometrics, law enforcement, and the new prohibited-content category.
EU AI Act Article 50 transparency disclosures FAQ
Article 50 FAQ for EU AI Act transparency duties covering chatbot notices, synthetic content marking, biometric and emotion notices, deepfakes, public-interest text, timing, accessibility, and exceptions.
EU AI Act Article 50 transparency, labeling, and user disclosures
Source-backed guide to EU AI Act Article 50 duties for user interaction notices, synthetic content marking, deepfake labels, emotion recognition notices, biometric categorisation notices, and related high-risk AI instructions for use.
EU AI Act Article 73 serious incident FAQ
FAQ on EU AI Act serious incident handling for high-risk AI systems, including Article 73 reporting, deployer escalation, corrective action, and GPAI systemic-risk distinctions.
EU AI Act Compliance Checklist by Risk Class
A practical EU AI Act checklist for classifying AI systems, assigning operator roles, screening prohibited practices, and collecting evidence for high-risk, GPAI, transparency, monitoring, and incident duties.
EU AI Act Compliance Program: roles, high-risk evidence, GPAI and incidents
Build an EU AI Act compliance program around provider, deployer, importer, distributor, high-risk, GPAI, transparency, monitoring, and incident evidence duties.
EU AI Act conformity assessment and notified bodies for high-risk AI
Source-backed guide to EU AI Act high-risk AI conformity assessment routes, provider evidence, EU declaration of conformity, CE marking, and notified body involvement.
EU AI Act deadlines and compliance calendar | Article 113 dates
EU AI Act compliance calendar for Regulation (EU) 2026/1744, Article 113 dates, Article 111 transitions, GPAI enforcement, Article 50, and high-risk systems.
EU AI Act FAQ: scope, roles, high-risk AI, GPAI, FRIA, and dates
Source-backed EU AI Act FAQ covering scope, roles, risk classification, GPAI, transparency, AI literacy, rights and complaints, sandboxes, authorities, SME provisions, and current legal status.
EU AI Act FRIA FAQ: Article 27 Scope, Contents, and Notification
Source-backed FAQ on when Article 27 requires a fundamental rights impact assessment, which deployers are covered, what the FRIA must contain, and how it relates to DPIAs and registration.
EU AI Act FRIA for high-risk AI systems: Article 27 scope and evidence
Source-backed guide to EU AI Act Article 27 fundamental rights impact assessments: who must run a FRIA, Article 6(2) triggers, Annex III carveouts, DPIA overlap, notification, and registration evidence.
EU AI Act GPAI and Systemic-Risk Duties: Article 53 and 55 FAQ
FAQ on EU AI Act duties for general-purpose AI model providers, including Article 53 documentation, copyright and training-summary duties, Article 55 systemic-risk duties, serious incidents, cybersecurity, and staged enforcement.
EU AI Act GPAI Provider Obligations: Articles 53 and 55
Source-backed guide to EU AI Act duties for general-purpose AI model providers: Article 53 documentation, copyright policy, training-content summary, downstream information, and Article 55 systemic-risk controls.
EU AI Act High-Risk AI Requirements: Articles 8-16 and 26
Map the EU AI Act requirements for high-risk AI systems: risk management, data governance, technical documentation, logs, transparency, human oversight, accuracy, robustness, cybersecurity, and deployer duties.
EU AI Act high-risk AI use cases by industry | Article 6 and Annex III guide
Industry-by-industry guide to EU AI Act high-risk classification under Article 6, Annex III, Annex I product safety routes, exclusions, and provider/deployer boundaries.
EU AI Act high-risk conformity assessment route selector
Select the EU AI Act Article 43 conformity assessment route for a high-risk AI system, including Annex I product legislation, Annex III categories, notified body triggers, standards, declaration, CE marking, registration, and evidence.
EU AI Act high-risk requirements checklist: Articles 8-15
Checklist for EU AI Act high-risk AI system requirements in Articles 8-15: risk management, data governance, documentation, logs, transparency, human oversight, accuracy, robustness, and cybersecurity.
EU AI Act penalties and fines: Article 99 tiers and GPAI exposure
EU AI Act penalties explained: Article 99 fine tiers, prohibited-practice exposure, incorrect information, SME caps, Member State rules, and GPAI model fines.
EU AI Act post-market monitoring and serious incident reporting
Source-backed guide to EU AI Act Articles 72 and 73 for high-risk AI: monitoring plans, serious incident reporting, deployer escalation, corrective action, and GPAI distinctions.
EU AI Act post-market monitoring FAQ for high-risk AI systems
Answer to how providers and deployers should handle EU AI Act post-market monitoring for high-risk AI systems under Article 72, with serious-incident, log, corrective-action, and lifecycle-change triggers.
EU AI Act provider vs deployer role boundaries: Article 3 and Article 25 FAQ
FAQ on EU AI Act provider, deployer, operator, importer, distributor, authorised representative, product manufacturer, downstream provider, and GPAI model provider boundaries.
EU AI Act risk classification intake workflow
A source-based intake structure for classifying EU AI Act scope, prohibited practices, high-risk routes, Annex III use cases, GPAI model status, roles, and reassessment triggers.
EU AI Act serious incident reporting triage workflow: Article 73 and Article 55
Triage EU AI Act serious incidents by definition, actor, reporting route, deadline, deployer escalation, corrective action, and separate GPAI systemic-risk reporting.
EU AI Act Technical Documentation and Provider Evidence Templates
Build AI Act evidence templates for high-risk AI providers: Article 11 technical documentation, Annex IV fields, quality management, conformity, CE marking, registration, logs, and post-market monitoring.
EU AI Act technical documentation FAQ | Article 11 and Annex IV
What Article 11 and Annex IV require in high-risk AI technical documentation: system identity, intended purpose, architecture, data, testing, oversight, cybersecurity, conformity, and post-market monitoring.
EU AI Act Timeline Roadmap: Dates, Legal Status, Owners, and Evidence
Turn EU AI Act milestones into an implementation roadmap by separating enacted dates, political agreements, draft guidance, consultations, and voluntary codes, then assigning actions and evidence.
EU AI Act vs ISO/IEC 42001: legal duties, controls, and evidence limits
Compare the EU AI Act and ISO/IEC 42001:2023, including legal status, Article 17 quality management, high-risk duties, GPAI, evidence reuse, and assurance limits.
EU AI Act vs NIST AI RMF: legal duties, risk controls, and evidence boundaries
Compare the EU AI Act with NIST AI RMF 1.0 across legal status, GOVERN-MAP-MEASURE-MANAGE, high-risk duties, GPAI, evidence reuse, and revision limits.
FAQ: EU AI Act conformity assessment procedures and notified body selection
cited FAQ on EU AI Act Article 43 conformity assessment routes, Annex VI internal control, Annex VII notified-body review, CE marking, declarations, and registration.