What Article 53(1)(a) and (b) require of general-purpose AI model providers
If you place a general-purpose AI model on the EU market, or your team builds on one, Article 53(1)(a) and (b) impose two documentation duties on the model provider. The first is technical documentation of the model, kept up to date and provided on request to the AI Office and national competent authorities. It must contain at least the information listed in Annex XI, covering intended tasks, acceptable use policies, release and distribution, architecture and parameters, modalities, license, training methodology, training data type and provenance, training compute and time, and known or estimated energy consumption. The second is information and documentation for downstream providers who integrate the model into their own AI systems. It must let them understand the model's capabilities and limitations and meet their own obligations, with at least the elements in Annex XII, while protecting intellectual property and trade secrets. These duties have applied since 2 August 2025, the date the general-purpose AI model provisions took effect.
The difficulty is less the wording than the ownership. The facts that Annex XI asks for sit across engineering (architecture, parameters, compute), data teams (sources, curation, provenance), evaluation teams (testing results), and legal and policy teams (license, acceptable use, release). Nobody owns the whole file by default, and it goes stale quickly once a model is retrained, fine-tuned or re-released. Start by assigning one accountable owner, then build a single versioned document with a named source for every field. Version control and role-based access in a self-hosted wiki can keep the file current and let you show the AI Office what changed and when, while limiting who can edit it. Confirm with your counsel which parts are shared externally, since Annex XII information goes to customers and must be separated from confidential training detail.
Which models, providers and documents fall under these duties
Before any documentation is written, four scope questions decide who owes what: whether the model is general-purpose, whether your organization is the provider or a downstream modifier, whether the Act reaches you from outside the EU, and whether an open-source exemption applies. Each answer changes which of the two documentation duties you carry and who receives the output.
General-purpose model test
The Commission's guidelines of 18 July 2025 treat a model as general-purpose, indicatively, when its training compute exceeds 10^23 FLOP and it can generate language, text-to-image or text-to-video output. Record the training compute figure for every model you build or adapt, including the source of the number. Because the test is indicative, ask counsel to confirm the classification for borderline models before you build the Annex XI file around it.
Provider or downstream modifier
An organization that modifies a general-purpose model becomes its provider when the modification compute exceeds a third of the original training compute, under the same guidelines. Below that line, you are typically a downstream integrator who receives the Annex XII information from the original provider. Track fine-tuning, continued pretraining and distillation runs separately, with compute estimates and run logs, so the classification can be justified to an assessor.
Article 2 reach to non-EU providers
Article 2 applies the Act to providers who place AI systems or general-purpose models on the EU market, wherever they are established, and to non-EU providers whose output is used in the EU. A company based outside the EU that releases a model to EU users may owe both documentation duties. Confirm with counsel which market placement triggers apply to your distribution model, and check whether you need an authorised representative under Article 54.
Open-source exemption limits
Article 53(2) exempts models released under a free and open-source license with public weights, architecture and usage information from points (a) and (b). The exemption does not apply where the model has systemic risk, and it does not remove the copyright policy or public training summary duties. Check the license wording against the public-weights condition, and confirm that the usage information you publish is complete before relying on the exemption.
Systemic risk carve-out
A model classified as having systemic risk loses the open-source exemption, so both documentation duties apply in full, and Article 55 adds further obligations. Identify early whether your model is near the systemic risk presumption, because a designation can arrive after release. Keep the training compute records that would support or rebut a classification, since they feed both the systemic risk analysis and the Annex XI file.
Items for legal review
Have counsel confirm the general-purpose classification, the provider or modifier boundary, the territorial reach under Article 2, and the license wording for the open-source exemption. Ask for written conclusions with the compute figures and dates they rely on. Keep these opinions with the technical file, because an assessor or the AI Office will ask how each scope decision was reached.
What Annex XI and Annex XII put in the documentation
Annex XI is the full technical file a general-purpose AI model provider keeps for the AI Office and national competent authorities, and it is organized around the model itself. Its first section asks for the intended tasks and acceptable use policy, the release and distribution route, the architecture and parameter count, the input and output modalities, the license, the training methodology, the type and provenance of training data, how that data was curated, the training compute and time, and the known or estimated energy consumption. Article 53(1)(a) adds that the documentation must also record training, testing and evaluation results. Assign an owner for each item now, because the training team usually holds the compute and data facts while product or legal owns the acceptable use policy and license terms.
Annex XII is the downstream-facing subset. It gives a company building an AI system on your model enough to understand what the model can and cannot do, and to meet its own obligations, without handing over the full training recipe. Article 53(1)(b) requires this information to be provided while protecting intellectual property and trade secrets, so the provider must decide what is disclosed and how it is protected. Practical steps include agreeing a confidentiality framework before release, marking which fields are shared under NDA, and keeping a version history so each downstream recipient can be shown the exact information they received. Confirm with counsel how the line between Annex XI and Annex XII disclosures applies to your model before publishing either document.
Both documents must stay current, so the working copy needs version control with a record of who changed what and when, and the ability to compare and restore earlier versions. Confirm which tool and access model your team will use, and how the Annex XII package will be issued to downstream customers with a matching version reference. Test a sample handover once, using a fictional downstream integrator, so that gaps in fields such as known limitations or evaluation results surface before a regulator asks for them.
How an assessor tests model documentation against Article 53
This table sets out how a supervisor or assessor would test the two documentation duties in Article 53(1)(a) and (b), what evidence each test requests, and where providers usually fall short. Read each row as a test the provider should be able to pass before a request arrives. The main takeaway is that documentation must exist, stay current, be retrievable on request and reach every downstream provider, and the open-source exemption applies only in narrow conditions.
| Test area | Evidence requested | Common findings |
|---|---|---|
| Annex XI documentation exists and is current | Versioned technical documentation covering the Annex XI Section 1 items, with dated revisions after each material model change | Documentation written once at release and not updated after fine-tuning, new data or new deployment modes |
| Documentation covers training and testing results | Training methodology, training data type and provenance, compute and energy figures, and evaluation results with their test conditions | Evaluation results reported without test setup, or compute and energy figures left blank because no one owns them |
| Documentation is available on request | A named owner, a retrieval procedure and a record that the file was provided to the AI Office or a national competent authority when asked | No defined owner or route, so the file cannot be produced within the time the authority sets |
| Annex XII information reaches each downstream provider | The information pack or model card as delivered, a distribution list or contract record, and the version each integrator received | Integrators on older versions with no notice of changes, or information shared only through public web pages |
| Downstream information covers capabilities and limitations | Stated intended tasks, known limitations, acceptable use policy and the elements the Annex XII list names | Limitations omitted or generic, so integrators cannot assess their own compliance |
| IP and trade secret protection is reasoned | A written rationale showing which details were withheld, why disclosure would harm protected interests, and what was still shared | Blanket refusals to share information, with no record of the balancing decision |
| Open-source exemption is claimed correctly | The license text, evidence that weights and architecture are public, and the usage information published, with a check that the model is not systemic risk | Exemption claimed for a model under a restrictive license, a model with public weights only, or a model above the systemic risk threshold |
| Modifiers and downstream providers are identified | Records of who modifies the model and the modification compute, against the Commission's one-third reference point | No check on whether a fine-tuning party has become a provider in its own right |
| Transparency chapter route is used | Evidence that the Model Documentation Form was completed and kept, mapped to the Annex XI and Annex XII items it covers | Form completed at launch and not maintained, or used without confirming it covers every required element |
How to build the documentation set in order
This sequence turns the two Article 53(1) documentation duties into a maintained set of records: one model-level technical file for the AI Office and one downstream package for integrators. Each step closes with a named output that the next step depends on.
Confirm model scope and provider role
Before drafting anything, decide whether your organization is the provider of the model under the Act. Check whether you developed the model or placed it on the EU market under your name, and whether a downstream modification would make you a provider under the Commission's scope guidelines (C(2025) 5045), which treat a modifier as a provider if modification compute exceeds a third of the original training compute. Record whether the model is general-purpose, and whether the open-source exemption in Article 53(2) could apply, which depends on the license, public weights and usage information. Output: a signed scope memo naming the provider role, the model version covered and the exemption position, reviewed by legal counsel.
Map each Annex element to an owner
Build a traceability register with one row for every element in Annex XI Section 1 and the Annex XII information set. For each row, name an accountable owner, the source system where the evidence lives (training pipeline logs, data registers, evaluation reports, license files, release records) and the review cadence. Include gaps openly, since a missing source is a finding to resolve, not a field to leave blank. Output: a register in which every Annex element has an owner, a source and a status, approved by the head of model development and the compliance lead.
Draft the Model Documentation Form content
Use the transparency chapter of the General-Purpose AI Code of Practice and its Model Documentation Form as the working template, because the Commission says it offers all providers a way to meet these obligations. Populate it from the register, writing each answer in plain terms that an assessor can trace to a source. Keep the model-level technical documentation for the AI Office separate from the downstream information so that IP-sensitive detail is not exposed to integrators by default. Output: a complete first draft of both documents, with each claim linked to a register row.
Establish versioning and approval controls
Place both documents in a system that keeps version history, records who changed what and when, and allows comparison and rollback. Wiki platforms with version control or document repositories with role-based permissions can support this, but confirm the audit trail and access model in your own environment before relying on it. Define an approval workflow that requires sign-off from the model owner and legal reviewer before any version is released. Output: an approved document baseline with a version identifier, a change log and named approvers, stored where the AI Office request process can retrieve it.
Define the downstream release package
Specify exactly what a downstream provider receives: the Annex XII information in the approved version, the license terms, the intended and restricted uses, and the known limitations that affect integration. Set a confidentiality marking for any content shared under IP and trade secret protection, and record which recipients received which version. Output: a release package template and a distribution log showing the version each integrator holds, which lets you reissue corrected information when the model changes.
Set request handling for the AI Office
Article 53(1)(a) requires the technical documentation to be provided on request to the AI Office and national competent authorities. Assign a single intake owner, define how requests are logged, and agree a internal route to legal, model and security teams so that a response can be assembled from the approved baseline rather than from memory. Confirm with counsel the internal deadline you will work to, since the Act sets none that this page can state. Output: a written request procedure with a named intake owner, a response checklist and a tested retrieval path to the approved documents.
Schedule updates on each model release
Tie the documentation to the model release process so that every new version, fine-tune, retraining or change to license or distribution triggers a register review. Re-run the scope check on each release, because a change in compute or modification may change your provider position. Log each update in the version history and reissue the downstream package where content has changed. Output: a release gate in your change process that cannot pass without a completed documentation review and an updated version record.
Evidence that shows the documentation exists and stays current
Article 53(1)(a) and (b) are only met if the documentation exists, reflects the model that was actually released, and can be produced on request. The cards below cover the artifacts that carry that proof and the routine that keeps each one current between releases.
Versioned Annex XI technical document
This is the master file covering Annex XI Section 1 items such as intended tasks, acceptable use, architecture and parameters, training methodology, and energy consumption. Keep it under version control so each release has a frozen copy tied to a model identifier and date. Check that every section names an owner and that the document states which model version it describes, since a document that drifts from the released weights fails the test of being up to date.
Training and evaluation result records
Article 53(1)(a) requires the technical documentation to include training, testing and evaluation results. Store these as dated records that link each result to the dataset version, training run and evaluation configuration that produced it. Keep raw outputs alongside summaries so an assessor can trace a headline figure back to its source. Any gap in a run should be recorded with the reason rather than silently dropped.
Annex XII downstream information package
Article 53(1)(b) requires information that lets downstream providers understand capabilities and limitations and meet their own obligations. Maintain a package sized to the Annex XII elements, with a known-limitations section that is reviewed at each release. Confirm with your legal team which contact channel downstream providers use to request updates, and log every delivery so you can show what each integrator received and when.
Release log and change history
A release log records each model version, what changed in weights, data, training method or intended use, and which documents were updated as a result. Pair it with a comparison of any two document versions and a documented rollback path. Ask whether a change to the model triggers a new documentation version, and whether a fine-tune by a downstream party could make that party a provider under the Commission's guidelines.
IP and trade secret rationale
Article 53(1)(b) asks for documentation while protecting intellectual property and trade secrets, so the justification for withholding or summarizing specific details needs to be written down. Record which items were redacted or generalized, the reason for each, and who approved the decision. An assessor will test whether the redactions are proportionate, so keep the reasoning specific to each item rather than a blanket statement.
Open-source exemption analysis and request log
Where a model is released under a free and open-source license with public weights, architecture and usage information, Article 53(2) may exempt it from points (a) and (b) unless it has systemic risk. Keep a dated analysis showing the license terms, what is public, and the systemic risk check that was run. Pair this with a request log recording each item given to the AI Office or national authorities, the date, the requester and the version supplied.
What meeting Article 53(1)(a) and (b) costs
This table lists the cost components of producing the Annex XI documentation and Annex XII downstream package, who is paid for each, whether it is one-time or recurring, and what drives it up or down. No prices or durations are stated because none were supplied, so use it to structure a quote request and to identify which costs your own team can absorb. The main takeaway is that most of the recurring cost comes from release cadence and the number of models, not from the first build of the documents.
| Cost component | Who is paid or who does the work | One-time or recurring | What drives it |
|---|---|---|---|
| Legal review of scope | Internal counsel or outside EU AI Act counsel | One-time, repeated when a model changes status | Number of models, whether any is open-source, and whether the model may meet the systemic risk threshold |
| Engineering time to extract training and evaluation records | Internal ML and data engineers, or an implementation partner | One-time build, recurring per release | Whether training logs, compute records and data provenance were kept at training time or must be reconstructed |
| Technical writing and review | Internal technical writers, reviewers and model owners | Recurring per release | Depth of the Annex XI sections, number of languages, and how many reviewers sign off |
| Version control tooling | Software licenses or self-hosted open-source platform, plus administration | Tooling set up once, administration recurring | Number of documents, required retention, and whether the platform is already in use for other controls |
| Redaction review for downstream packages | Internal IP, legal and product owners | Recurring per release and per downstream customer template | Volume of trade secret content, number of downstream recipients, and how often the Annex XII package changes |
| Recurring upkeep per model release | Internal model owners, documentation owners and compliance staff | Recurring | Release cadence, fine-tuned or derived variants, and changes to intended tasks or acceptable use policy |
| Assessment support (if requested) | Independent assessors or regulators' requests handled by the provider | Occasional | Requests from the AI Office or national competent authorities, which the provider must answer from the kept records |
| Reuse of existing records | Internal teams (savings rather than an outside fee) | Reduces both one-time and recurring effort | Whether training, evaluation and release records already exist in a structured, versioned form, such as those kept in a self-hosted wiki |
Who owns the documentation, who prepares it and who checks it
The organization that places the general-purpose AI model on the EU market remains the provider and carries the legal duty. Legal counsel decides which documents are required, how far each section must go, and what can be withheld to protect trade secrets while still meeting the Annex XII information duty for downstream providers. Model owners and research leads supply the facts that the documentation describes, and evaluation leads confirm the testing results. Responsibility stays with these people even when outside help drafts or formats the material.
- Legal counsel: interprets the Annex XI and Annex XII scope, decides what is confidential, and approves the final text before release.
- Model owners: state the intended tasks, acceptable use policy, release channels, license and architecture for each model version.
- Research and training leads: provide the training methodology, data types, provenance, curation steps, compute and energy figures.
- Evaluation leads: supply the testing and evaluation results that Article 53(1)(a) requires the documentation to include.
- Document owner: keeps one named person accountable for version control and for updating the record when the model changes.
Confirm with counsel, in writing, which named person signs off each section and how the sign-off is recorded.
An implementation partner can prepare the record system and help draft the documents, but it does not decide what the provider is required to disclose and it does not sign the documents on the provider's behalf. In practice the work is structural: a versioned repository where each model release has its own documentation set, templates that map to the Annex XI and Annex XII headings, and access rules so that only approved roles can edit or publish. Drafting support can turn engineering notes into readable text that the provider's own experts then verify.
- Repository setup: a wiki or document system with version history, so that every change records what changed, when and by whom, and earlier versions can be restored.
- Access control: role-based permissions so drafters, reviewers and approvers hold different rights, with the approval step recorded.
- Templates: section structures for each Annex XI and Annex XII item, linked to the Commission's transparency chapter where the provider chooses to follow it.
- Evidence capture: tooling that stores evaluation runs and training records next to the narrative documents they support.
- Drafting support: first drafts of technical sections, which the model owners must check line by line.
Ask any partner to state in the written scope which deliverables it prepares and confirm that it will not issue any compliance attestation.
Checking the documentation belongs to independent parties. The AI Office supervises the general-purpose AI model rules under Article 88, and it can request the technical documentation from providers. National competent authorities also have access under Article 53(1)(a). Where a provider seeks third-party assurance, an independent auditor or certification body tests the documentation against the requirements and issues any report. None of these parties is the implementation partner, and none of them can be replaced by a vendor's own review.
- Document review: the reviewer compares the published record with the Annex XI and Annex XII elements and asks for missing items.
- Sampling: the reviewer may trace claims, such as training compute or data provenance, back to the underlying records.
- Version testing: the reviewer checks that the documentation matches the model version in use and that updates were made when the model changed.
- Independence: partners prepare evidence, while only the independent party forms the conclusion and issues any report.
- Confidentiality: the reviewer handles trade secrets under the Act's protections, so the provider should agree on how sensitive material is shared.
Confirm with the AI Office or your chosen assessor what form of submission they expect and how they want version history presented.
Gaps that leave Article 53 documentation unfinished
Most Article 53(1)(a) and (b) files are not missing entirely. They are stale, split across teams, or disconnected from the model version they describe. The cards below cover the gaps we see most often, each with a closure step that an internal owner can verify before an AI Office or downstream request arrives.
Documentation frozen at release
The Annex XI file is written once, at launch, and never revised after fine-tuning, a new checkpoint, or a changed release channel. Article 53(1)(a) asks for documentation that is kept up to date, so a file describing an earlier architecture or parameter count becomes a liability the moment the model changes. Closure: assign a document owner, tie every revision to a model version identifier, and require a documentation review as a gate in each release checklist. Keep the prior version so changes can be shown over time.
Downstream packages leak IP or omit limits
Article 53(1)(b) packages often fail in one of two directions. Some disclose training recipes and proprietary data detail that the provider wanted to protect, while others state capabilities without the limitations a downstream integrator needs to comply with its own obligations. Closure: review each Annex XII package against a written split of what is disclosed, what is withheld for trade secrets, and which limitations and intended-use boundaries must appear. Have legal and engineering both sign the version sent to each recipient.
No owner for training data provenance
Annex XI asks for the type, provenance and curation of training data, yet in many organizations no single person holds that record. Datasets arrive from data engineering, licensed sources sit with procurement, and curation decisions live in notebooks. When an assessor asks where a dataset came from and how it was filtered, the answer is reconstructed from memory. Closure: name one accountable owner for provenance, keep a dataset register with source, license and curation steps, and check the register against each training run.
Open-source exemption claimed without a check
Article 53(2) relieves models released under a free and open-source license with public weights, architecture and usage information from points (a) and (b), but only where the model does not have systemic risk. Teams often claim the exemption from the license name alone and never test the systemic risk condition or confirm that every element is actually public. Closure: record a written exemption assessment for each release that lists the license, the public artifacts, and the systemic risk determination, and have it reviewed before publication.
Evaluation records not tied to the model
Training and testing results are required as part of the technical documentation, but evaluation reports often name a model family rather than an exact build. A result produced on one checkpoint can be quoted against a later release that behaves differently. Closure: log each evaluation with the exact model hash or version, the dataset and configuration used, and the date. Store results in the same version-controlled repository as the documentation so the two can be compared directly.
No request procedure for the AI Office
Article 53(1)(a) requires documentation to be provided on request to the AI Office and national competent authorities, and a request may arrive with a short deadline. Without a defined route, the file sits with one engineer, legal review takes weeks, and nobody knows which version the authority means. Closure: write a request procedure that names the intake contact, the approver, the disclosure review step, and the secure channel for transfer. Run a tabletop exercise against a sample request at least once a year.
Questions buyers ask about Article 53(1)(a) and (b)
Are open-source general-purpose AI models exempt from Article 53?
Partly. Under Article 53(2), a model released under a free and open-source license with publicly available weights, architecture and usage information is exempt from the documentation duties in points (a) and (b). That exemption does not apply if the model has systemic risk, and it does not remove the copyright policy or training content summary duties in points (c) and (d). Confirm with counsel whether your license and release meet every condition, because a restrictive license, withheld weights or missing usage information removes the exemption.
What does preparing Article 53(1)(a) and (b) documentation cost?
No public figure is supplied for this work, so treat any number you see with caution. Costs are driven by how much of the Annex XI and Annex XII content already exists in your records, how many models and versions you release, how often each one changes, and how much training data and evaluation history must be traced. Most of the spend is internal staff time for engineers, legal and product owners, with outside help for gap assessment and document drafting. Ask any provider for a fixed-scope quote that lists the models, the versions, the documents and the review rounds it covers.
How long does it take to prepare the documentation?
The timeline depends on how well your training and release history is recorded. Teams with complete training logs, evaluation results and license files usually need less time to assemble the technical file than teams reconstructing a model's history after release. Plan separately for the first build, which covers every item in Annex XI Section 1 and Annex XII, and for ongoing updates, because the documentation must be kept up to date as the model changes. Ask for a written schedule tied to named deliverables before work starts.
What must the team provide to produce the documentation?
The team must supply the facts that the documentation describes, because no outside party can invent them. Typical inputs include the intended tasks and acceptable use policy, release and distribution channels, the model architecture and parameter count, supported modalities, the license, a description of the training methodology, the type and provenance of training data, training compute and time, known or estimated energy consumption, and the testing and evaluation results. For downstream providers, the team also needs the capabilities, limitations and integration guidance covered by Annex XII, written so that IP and trade secrets stay protected.
Can a consultant or implementation partner prepare this for us?
Yes, an implementation partner can prepare the systems, records and draft documents, but your organization remains responsible for the model, its data and the accuracy of every statement. DeployOpen, for example, can help plan, implement and document self-hosted platforms in your own infrastructure, and it can help structure version-controlled documentation and evidence trails. It does not issue conformity statements or certifications. Confirm with counsel which roles your company holds under the Act, and confirm in writing which deliverables the partner owns and which remain with your staff.
Is the Model Documentation Form required to comply?
The Commission says the transparency chapter of the General-Purpose AI Code of Practice, including its Model Documentation Form, offers all providers a way to meet the Article 53(1)(a) and (b) obligations. Using it is a route to demonstrate compliance, not the only one. A provider that uses another method must still cover the Annex XI and Annex XII elements in full. Check the current status of the code and its signatories on the Commission's pages, and confirm with counsel whether the form fits your model before you rely on it.
Which models count as general-purpose and who is a provider?
The Commission's guidelines C(2025) 5045 of 18 July 2025 treat a model as general-purpose, indicatively, when training compute exceeds 10^23 FLOP and the model can generate language, text-to-image or text-to-video. Those guidelines also treat a downstream modifier as a provider when its modification compute exceeds a third of the original training compute. Because these are indicative tests, run the calculation on your own training records and have counsel confirm the classification before you decide which duties apply.
How DeployOpen prepares documentation evidence for this duty
DeployOpen prepares the documentation system and the evidence behind it, and only after the scope is agreed in writing. The first step is to fix which models the engagement covers, which versions of each model are in use or planned, and whether any model is fine-tuned or modified in a way that could make your organization a provider in its own right under the Commission's guidelines. The written scope then names the deliverables, such as an Annex XI file structure, an Annex XII information pack for downstream integrators, and the review cycle that keeps both current. Because the work happens inside your own cloud accounts, data centers or air-gapped networks, training records, evaluation outputs and model artifacts stay under your control throughout. On the technical side, the wiki or document platform is deployed in your infrastructure and configured so every revision to the Annex XI and Annex XII documents is kept under version control, with a record of what changed, when and by whom. Roles are set so that engineering owns the technical content, legal and compliance review the wording, and only approved versions are published to downstream teams. For evaluation records, the engagement can wire open-source tools such as garak to write its JSONL attempt reports and hit logs to a location you retain, and tracing such as Langfuse can capture the runs that support the testing and evaluation results Article 53(1)(a) asks you to keep. Confirm with your engineering team that retention periods for these logs match your own policy.
DeployOpen does not issue reports, attestations or certifications. An independent auditor or certification body issues those, and your own regulators decide how the documentation is judged. Whether a given model is in scope for an open-source exemption, whether it carries systemic risk, and how the public training summary and copyright duties interact with your documentation are legal determinations that stay with your counsel. Our role is to make the documentation accurate, complete against the annex elements, and traceable to evidence, so that counsel and any assessor can check it quickly. Before signing a scope, ask who in your organization will own sign-off on each Annex XI and Annex XII element and whether counsel will review the final pack.
