Evidence ChecklistEU AI Act

GPAI evidence pack Article 53 and 55 records

Collect the records required when you provide a .

Start with model documentation, integration information, copyright and training summaries. Add systemic-risk records when Article 55 applies.

Author
Sorena AI
Published
May 9, 2026
Updated
Oct 21, 2026
Overview

A can support many different tasks and applications. First check whether you place such a model on the EU market as its provider or integrate another provider's model into a system. Model providers need Article 53 records, subject to its limited exceptions. Providers of models with systemic risk also need Article 55 testing, incident, mitigation and cybersecurity evidence. Classify each resulting AI system separately.

Section 1

1. Identify the model and its provider

Keep a model record separate from product-feature records. Article 53 applies to GPAI model providers; using a supplier's model does not by itself make your organisation that model's provider.

Record whether you originally supply the model, supply a modified or fine-tuned model, or only integrate it into a system. Keep the version, release and EU market dates, distribution, licence, dependencies, relevant authorised-representative status and authenticity evidence.

Chapter V duties apply to models placed on the market from 2 August 2025. Providers of older models have until 2 August 2027 to comply. Commission enforcement powers began to apply on 2 August 2026. Keep market-placement evidence for each model version.

  • 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.
  • Review again when: a new model version, material modification, fine-tuning path, new Union distribution channel, licence change, or provider-role change.
Section 2

2. Prepare the technical documentation

Article 53(1)(a) requires current model documentation, including training, testing and evaluation results. The AI Office and national competent authorities can request it.

Use Annex XI as the minimum contents list. Include intended tasks and integration contexts, acceptable use, release and distribution, architecture and parameters, input/output types and formats, licence, development process, data sources and preparation, training/testing/validation data, compute, training time, and known or estimated energy use.

The checklist below adds ownership and update details. Treat those fields as practical record-management advice; check the legal duty and any Article 53(2) exception separately.

  • Include: model description, intended tasks, integration contexts, acceptable use policy, release and distribution record, architecture and parameter summary, input and output types and formats, licence, development design choices, training methodology, data sources and preparation, bias-detection measures where applicable, evaluations, training compute, training time, and energy information.
  • For each field, record the source system or document, last update date, evidence owner and intended recipient: the AI Office, national competent authorities, integrating providers or the public.
  • Review again when: 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. Supply information for integration

Under Article 53(1)(b), providers must prepare, maintain and make information available to companies intending to integrate the model into their AI systems.

Use Annex XII to explain capabilities, limitations and integration requirements so those companies can meet their own duties. Include technical integration methods, input/output constraints, licence, acceptable-use policy and data-source information.

  • 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, input and output types, 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.
  • Review again when: 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 records for models with systemic risk

Article 55 adds duties for GPAI models classified or designated as having systemic risk. Maintain these records alongside the Article 53 and 54 records so their applicability is clear.

Training compute above 10^25 floating-point operations creates a presumption of high-impact capabilities. The Commission can also designate a model using Annex XIII criteria. Notify the Commission without delay and within two weeks after meeting the high-impact condition or learning it will be met.

Keep the compute method, assumptions, threshold date, notification and any reasoned argument against systemic-risk status. Add model evaluations, documented adversarial testing, EU-level systemic-risk assessment and mitigation, serious incidents, corrective measures, and cybersecurity for the model and its physical infrastructure.

Under Article 55(1)(c), track, document and report relevant serious-incident information and possible corrective measures without undue delay to the AI Office and, as appropriate, national competent authorities.

  • 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. Review completeness and exceptions

Give each required record an owner, evidence link and update trigger. Mark whether it is for authorities, integrating providers, public release or internal use.

Before claiming Article 55 readiness, check the added evaluation, mitigation, incident and cybersecurity records. Before relying on an open-source exception, document the licence and public access to parameters and architecture information, and check systemic-risk status.

A qualifying free and open-source model is exempt from Article 53(1)(a) and (b) technical and integration-documentation duties under Article 53(2). Copyright-policy and public-summary duties remain. Article 54(6) separately exempts a qualifying model from the authorised-representative duty. Neither exception applies to a model with systemic risk.

  • Article 53 records: the copyright policy and public training-content summary are present and current. Technical documentation and downstream-provider information are present and current, or the pack records why the limited Article 53(2) open-source exception applies to those two duties.
  • Recipients: every record is marked as public, for integrating providers, AI Office or national competent authority on-request, or internal confidential evidence.
  • For systemic-risk models: classification or designation rationale, Article 55 evaluation and mitigation records, serious-incident workflow, and cybersecurity evidence.
  • Change reviews: 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

ec.europa.eu4 citations
Referenced sections
  • Code chapter supporting technical documentation and downstream-provider information records, including the Model Documentation Form structure.
  • Supports using the Model Documentation Form to organize model identity, recipient, and downstream-provider records.
  • Provides the Code's practical transparency documentation structure and Model Documentation Form approach.
Show 1 more
  • Supports distinguishing information intended for downstream providers from information provided to the AI Office or national competent authorities on request.
"Transparency Chapter"
More quoted passages
"Model Documentation Form"
"downstream providers"
ec.europa.eu2 citations
Referenced sections
  • Commission template for serious-incident reporting by providers of GPAI models with systemic risk under Article 55(1)(c).
  • Supports the serious-incident report fields for GPAI models with systemic risk under Article 55(1)(c).
"Report for Serious Incidents"
More quoted passages
"serious incidents"
digital-strategy.ec.europa.eu2 citations
Referenced sections
  • Commission guidance page for interpreting the scope of GPAI provider obligations and provider-role analysis.
  • Supports using provider-role and model-scope analysis before assigning GPAI obligations.
"general-purpose AI models"
More quoted passages
"scope of the obligations"
digital-strategy.ec.europa.eu2 citations
Referenced sections
  • Commission template and explanatory notice for the Article 53(1)(d) public summary of training content.
  • Supports the public training-content summary structure and the Commission's baseline for information to make public.
"Public Summary of Training Content"
More quoted passages
"public summary of training content"
digital-strategy.ec.europa.eu2 citations
Referenced sections
  • Commission page explaining that the Code contains Transparency, Copyright, and Safety and Security chapters for demonstrating GPAI compliance.
  • Supports separating Transparency and Copyright obligations for all GPAI providers from Safety and Security obligations for systemic-risk GPAI providers.
"voluntary tool"
More quoted passages
"Transparency, Copyright, and Safety and Security"
ec.europa.eu2 citations
Referenced sections
  • Code chapter supporting the copyright-policy evidence items under Article 53(1)(c).
  • Supports concrete copyright-policy controls such as assigned responsibilities, rights-reservation handling, and crawler transparency.
"Copyright Chapter"
More quoted passages
"copyright policy"
ec.europa.eu2 citations
Referenced sections
  • Code chapter supporting systemic-risk evaluation, mitigation, governance, and cybersecurity evidence for Article 55 models.
  • Supports the systemic-risk management, evaluation, mitigation, security, and governance record structure for Article 55 models.
"Safety and Security"
More quoted passages
"Safety and Security Chapter"
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"
Show all related guides (34)

EU AI Act timeline and phased deadlines

See which AI Act rules apply now and what comes next. Check high-risk dates, older-model transitions and the difference between legal and standards dates.

EU AI Act vs ISO/IEC 42001

Compare AI Act legal duties with ISO/IEC 42001 management-system requirements. See which records can be reused and what certification does and does not cover.

EU AI Act vs NIST AI RMF

Compare AI Act legal duties with the voluntary NIST AI RMF. Map risk records to specific requirements and identify legal steps that need separate evidence.

EU AI Act: Check whether the Act applies

Use five checks to establish AI Act scope, exclusions, your role, risk categories and evidence for the decision.

EU AI Act: Choose a high-risk assessment route

Choose between provider-run internal control, notified-body assessment and a product-law procedure before release.

EU AI Act: Classify a tool before approval

Classify an AI tool or model before purchase or release. Check EU scope, prohibited uses, high-risk rules, transparency and GPAI duties.

EU AI Act: Compliance checklist

Check each AI tool, decide which duties apply, and give every action an owner and evidence link.

EU AI Act: Conformity assessment

Some high-risk systems use a provider-run assessment. Others need an authorised independent assessor or a product-law assessment.

EU AI Act: Does it apply to you?

Check whether the AI Act applies to your system or model, identify your provider or deployer role, and keep evidence for the decision.

EU AI Act: Duties for general-purpose AI models

Check GPAI provider duties for documentation, integrator information, copyright and training summaries, plus extra requirements for systemic-risk models.

EU AI Act: High-risk requirements

High-risk providers must meet system requirements before supply. Deployers must use and monitor the system under the provider's instructions.

EU AI Act: High-risk system checklist

Check the system's risk controls, data, documentation, logs, instructions, human oversight and testing before release.

EU AI Act: Is your use case high-risk?

Find high-risk AI examples in recruitment, banking, education, healthcare, public services and products. Check Article 6 conditions and exceptions.

EU AI Act: Plan your compliance work

Build a compliance plan for each AI tool: your role, the duties that apply, the evidence needed and the person responsible.

EU AI Act: Standards and quality management

Use EN 18286:2026 to organise provider quality-management procedures and keep evidence that they work for each high-risk system.

EU AI Act: Technical file and evidence templates

Build the technical file and provider records for a high-risk AI system, with owners and evidence links for each field.

EU AI Act: When must you disclose AI?

Check Article 50 chatbot notices, synthetic-output marking, biometric notices, deepfake disclosures and public-interest text exceptions.

EU AI Act: Which AI uses are banned?

Check Article 5 prohibited AI practices, the narrow exceptions, evidence to retain and the new content prohibitions from 2 December 2026.

Are you the provider or the deployer? | EU AI Act

Check provider, deployer, importer and distributor roles, when changes create provider duties, and how model and system responsibilities differ.

Do you need a notified body? | EU AI Act

Find the assessment route for high-risk AI, when a notified body is required, and which declaration, CE-marking and registration records you need.

Does this tool count as AI? | EU AI Act

Check whether software counts as AI, how models differ from systems, when embedded AI is high-risk, and which scope and role evidence to keep.

How do you monitor AI after release? | EU AI Act

Understand high-risk AI monitoring under Article 72: the provider plan, deployer feedback, logs, corrective action, incidents and change reviews.

Is this industry use high-risk? | EU AI Act

See which industry AI uses fall under Annex III, when Article 6(3) can apply, and what providers must document and register.

What belongs in the technical file? | EU AI Act

See what Article 11 and Annex IV require in high-risk AI technical documentation, from system identity and testing to monitoring and retention.

What must general-purpose model providers do? | EU AI Act

Check general-purpose model duties, systemic-risk classification, open-source conditions, copyright, training summaries, incidents and application dates.

When must you disclose AI use? | EU AI Act

Check AI interaction notices, technical content marking, biometric notices, deepfake and text disclosures, exceptions, accessibility and deadlines.

When must you report a serious incident? | EU AI Act

Check serious-incident outcomes, reporting roles, 15-, 10- and two-day deadlines, authority recipients, corrective action and the separate model route.

Who needs a rights impact assessment? | EU AI Act

Check who needs an Article 27 fundamental rights impact assessment, what it must cover, and how privacy assessments, notification and registration fit.