What Article 53(1)(d) asks providers to publish about training data
Article 53(1)(d) requires a provider of a general-purpose AI model to draw up and publish a sufficiently detailed summary of the content used to train the model, using the template the AI Office presented on 24 July 2025. The open-source exemption that relieves some providers of other Chapter V duties does not cover this one, so an open-weight model published under a free licence still needs a public summary. If your organization places a general-purpose model on the EU market, treat the summary as a publication deliverable with its own owner, review step and version history, not as a paragraph written once by the legal team.
The duty exists because the training data behind a model is usually opaque to everyone outside the provider. The Commission states that the template also helps parties with legitimate interests, such as copyright holders, to exercise their rights under EU law, so the summary is read by people who may want to check whether their works were used. The hard part is the level of detail. The template asks for a comprehensive overview that lists the main data collections and explains other sources, but it does not ask for a file-by-file inventory. Article 56(2)(b) asks codes of practice to address the adequate level of detail, so check how the code of practice you rely on handles that question before you draft the text. Confirm with your counsel where the line falls for your own datasets.
Models placed on the market before 2 August 2025 have a transition under Article 111(3): their providers must comply by 2 August 2027. If you are maintaining an older model, decide now which datasets, collection records and licence terms you can still reconstruct, because a summary written from memory two years later is hard to defend. For any new version or fine-tuned release placed on the market after that date, the summary duty applies from the start. Keep the source collection records alongside each published version so you can show which summary matched which model.
Which models and providers the summary duty covers
Article 53(1)(d) applies to a provider of a general-purpose AI model, and a handful of scoping questions decide whether you are that provider, when the duty starts and whether an open-source exemption helps you. Work through these before you estimate effort, because each answer changes what you must publish and by when.
Provider or downstream modifier
The duty falls on the provider that develops a general-purpose AI model or has one developed and places it on the market under its own name. An organization that only calls a model through an API, or that adapts a model without substantially changing it, is usually a downstream party. Confirm your role against the Commission's guidance on who counts as a provider, and record the reasoning in writing, because the answer determines whether this duty is yours at all.
Placed on the market before or after 2 August 2025
Models placed on the market before 2 August 2025 have a later compliance date than new models. Providers of those models must comply by 2 August 2027 under Article 111(3). Establish the first placement date for each model version you control, since that date, not the date of your latest training run, decides which deadline applies.
Open-source status does not remove the duty
The open-source exemption covers some documentation duties for providers, but the training content summary is not exempted. An openly licensed model still needs a published summary built on the AI Office template. Confirm with counsel which parts of the open-source exemption apply to your release, and do not assume that releasing weights under an open license reduces this work.
Fine-tuned model as a new model
A fine-tuned model may be a new model with its own provider, training data and summary, or it may be a modification of an existing model whose summary already covers the base training. The answer depends on how much compute the modification used and whether you substantially changed the model. Document the test you applied, the compute involved and the base model you relied on, and confirm the approach against the Commission's guidance.
Risk level does not change the duty
Article 53(1)(d) applies to every general-purpose AI model provider, whether or not the model is classified as having systemic risk. Systemic risk adds duties under Article 55, but it does not replace or reduce the training content summary. Plan the summary for every model in scope, then add the systemic risk work on top where it applies.
Confirm model inventory and versions
Build a register of every general-purpose AI model you place on the market, including each version, release date, license and the base model it came from. Without this register, you cannot tell which summary covers which release or which models fall under the 2 August 2027 date. Assign an owner to keep the register current as new versions ship.
How much detail the AI Office template expects
The AI Office template asks for a comprehensive overview of the training data, not a list of every file a model saw. In practice, the summary should name the main data collections that shaped the model and then explain, in prose, any other sources used. The Commission presented the template on 24 July 2025, and it is the format a provider must follow when publishing. Before drafting, read the current template itself, since the level of detail it expects is set by that document and by any codes of practice that address it, not by a summary written from memory.
The Commission also says the summary helps parties with legitimate interests, such as copyright holders, to exercise their rights under EU law. That purpose shapes the detail level: a reader who wants to know whether their works were used needs enough description to recognize a collection or a source category, but the summary does not have to expose every dataset line by line. Article 56(2)(b) makes the adequate level of detail for the training content summary a subject that codes of practice must address. Check whether the code of practice your organization relies on sets out expectations on granularity, and record which interpretation you adopted and why.
Write each description in your own words. Do not paste template wording, standard text or a competitor's summary into your document, and do not copy another provider's categories without checking that they match your data. Describe what your team actually collected, licensed, crawled or generated, the broad categories it falls into, and the decisions that shaped the mix. Ask the engineers who built the training pipeline to confirm each statement against their records, and keep those records so the summary can be traced back to evidence if the AI Office or a rights holder asks how it was produced.
How an assessor tests the training content summary
This table sets out how a market surveillance reviewer, AI Office reviewer or independent assessor would check a published training content summary, the evidence they would ask for, and the findings that usually come up. Read each row as a test the summary has to pass, and use the evidence column to decide what your records must contain before a review starts.
| Test or check | What the assessor does | Evidence requested | Common finding |
|---|---|---|---|
| Comparison with the template | Checks that every section of the AI Office template is present and filled in, and that the summary follows the template's structure rather than a free-form document | The published summary, the template version used, and the publication date | Sections left blank or reworded so the template structure is no longer recognizable |
| Trace listed data collections | Picks named data collections from the summary and follows each back to internal records showing the data was used to train the specific model | Data inventories, dataset manifests, training run configuration and data lineage logs tied to a model version | Collections named in the summary cannot be matched to any training run |
| Check other sources are explained | Looks for data sources beyond the main collections, such as user data, synthetic data, web crawl or licensed material, and checks each is described | Records of supplementary sources, collection methods, licences and any opt-out handling applied | Minor or secondary sources omitted because the team considered them immaterial |
| Specificity of category names | Judges whether the summary gives enough detail for a copyright holder or downstream party to understand what was used | Internal data taxonomy, mapping from categories to source datasets, and the reasoning for the level of detail chosen | Vague labels such as "publicly available data" or "various web sources" with no further breakdown |
| Model version match | Confirms the summary describes the exact model version placed on the market, including later versions trained on different data | Model version register, release notes, training dates and a record of which summary belongs to which version | Summary describes an earlier model or a previous training set, so it does not match what is in use |
| Publication and version history | Checks that the summary was published where it is accessible, when it was published, and how later changes were recorded | Publication records, dated copies of each version, change logs and approval records | No record of when the summary was first published or what changed in an update |
| Licensing and provenance records | Asks how rights to the listed data were obtained and whether text and data mining opt-outs were respected for web-sourced content | Licence agreements, provenance logs, crawler configuration and copyright policy references | Licences missing for named collections, or no evidence of how opt-outs were handled |
| Open-source model check | Confirms the open-source exemption does not remove the summary duty, and that the summary was still published for the model | The published summary and records showing it was prepared and kept current for the open model | Team assumes an open release is exempt and publishes nothing |
Steps to produce and publish the summary
The sequence turns a model's training history into a public summary that follows the AI Office template, passes internal legal and data review, and stays current as the model changes. Each step ends with a named output so the team can show how the summary was built.
Inventory every training data collection
Start by listing each dataset, corpus, crawl, licensed collection and synthetic or third-party source used to train the specific model version you are publishing. Engineering and data teams own this list, because they hold the pipeline manifests, data loaders and preprocessing records. Record the dataset name, the training stage it fed, its approximate role in training and the system that stores it. The output is a versioned training data register tied to one model version, with a named owner for each entry. Confirm the model version identifier before you start, since the summary describes one model and changes between versions can alter the sources.
Classify each source by origin and rights position
For each entry in the register, record where the data came from, such as data licensed from a vendor, data collected from the public web, user-provided data, internal data or data generated by other models. Then record the rights position: the license or contract terms, whether the data was obtained under a text and data mining exception, and whether any opt-out signals were honored. Legal or copyright counsel should review entries with unclear rights. The output is a classified register that shows origin and rights status for every collection, with open questions flagged for resolution before drafting.
Map each collection to the template sections
Walk through the AI Office template section by section and assign each data collection to the section where it belongs. The template asks for a comprehensive overview of the training data, so the main data collections must be listed and other sources explained. Mark any collection that does not fit neatly, and decide how to describe it at a level of detail that remains accurate without disclosing protected business information. The output is a section-by-section mapping that shows which register entries feed each part of the summary and where gaps remain.
Draft the summary against the template
Write the summary in the template's structure, using the mapping to describe the main data collections and to explain other sources used. Keep the language factual and consistent with the register, and avoid claims about data quality or safety that the register does not support. The writer should check every figure, date and name against the register and record each source of truth. The output is a complete draft with a short source note for each section that a reviewer can trace back to the register.
Complete internal legal and data review
Route the draft to legal, copyright and data protection reviewers who check the description against the rights classification, the personal data content of the sources and the template requirements. Engineering confirms that the described sources match the training pipeline for the model version. Reviewers record their comments and the changes made in response. The output is a signed-off draft with a review record showing who reviewed which sections and when. Decide in advance who has final sign-off inside the organization.
Publish in the chosen location and format
Publish the approved summary in the location and format the provider has chosen, such as a documentation page on the provider's website or a downloadable document, and keep the version date visible. Make sure the page is accessible without a login, that the model version it describes is stated clearly, and that the publication is linked from the model documentation the provider already maintains. The output is a live public summary with a recorded publication date, a retained copy of the exact published text and a note of where it is hosted.
Set triggers to update the summary
Define the events that require an update, including a new model version, a material change to the training data, a change in the rights position of a major collection, or a correction raised by a rights holder or regulator. Assign an owner who monitors those triggers and reruns the register, mapping and review steps when one fires. Keep the version history of each published summary so the previous text can be shown to an assessor. The output is a documented update procedure, a trigger list with owners and a versioned archive of all published summaries. Ask your counsel whether any update timing applies to your model, since the researched facts do not set a specific update interval.
Evidence that shows the summary is complete and current
Article 53(1)(d) asks for a summary that is sufficiently detailed, and a summary that drifts from the training data it describes is hard to defend. The six records below link the published text to the data, the people who approved it and the model releases it covers, so each can be checked at any point between reviews.
Published summary with version and date
Keep every issued version of the summary as a separate, dated record, with the model name and release it describes. Record the template version used, so a reader can tell which AI Office template structure applies. Before each release, confirm that the live text matches the approved version and that no older text remains online. The version and date on the summary must match the model release it covers, or the document describes data the model may not have been trained on.
Training data register linked to collections
Maintain a register with one entry per main data collection named in the summary, showing its source, volume, collection period, and the training runs that used it. Each published heading should trace back to a register entry, and any source described as other data should also have its own entry. Check the register against the summary whenever a collection is added, removed or filtered, because gaps between the two are the most common reason a summary becomes incomplete.
Provenance and licence records
For each collection, keep records that show where the data came from, the terms under which it was obtained, and any opt-out or machine-readable reservation the provider honored. These records support the statement of other sources and let a copyright holder or auditor verify a claim about where data came from. Ask the data team to record the date each record was checked, because licence terms and reservation signals can change after training has finished.
Legal review sign-off
Store a dated approval from legal or compliance counsel for each published version, stating which register entries and provenance records were reviewed. The sign-off should name the reviewer, the version approved and any open questions that were accepted with a reason. Because the Commission says the template helps copyright holders exercise their rights, the sign-off is the record that shows the summary was checked against that purpose before publication.
Change log tied to model releases
Log each change to the training data, the summary and the model release in one place, with the reason and the owner. A change to a collection, such as adding a new source, removing a filtered dataset or retraining on a new corpus, should trigger a review of the summary before the release ships. Set a rule that no model version is released without a matching summary version, and check the log at each release to confirm this.
Record of publication location
Keep a record of where the summary was published, the URL, the date it went live, the person who published it and each later update or removal. Capture a dated copy or screenshot of the live page at each release, so you can show what the public saw at a given time. Confirm the publication location with your own legal team and with any model hosting platform you use, because the duty concerns what is published, not only what is written internally.
What meeting the summary duty costs and what drives it
This table lists the cost components of preparing and publishing an Article 53(1)(d) training content summary, who is paid for each, and whether it is one-time or recurring. No price or duration is supplied for this duty, so use the drivers column to scope a written quote and compare proposals on the same basis.
| Cost component | Who is paid | One-time or recurring | What drives it |
|---|---|---|---|
| Data inventory and provenance work | Internal data, ML and records staff, or an implementation partner under a fixed scope | One-time, then recurring with each retrain | Number of main data collections, and whether source records already exist |
| Legal and copyright review | In-house counsel or external copyright lawyers | One-time, then recurring with each new source type | Licensing terms, opt-out handling and how many sources raise questions |
| Technical writing against the AI Office template | Model or documentation owners, sometimes a technical writer | One-time draft, recurring updates | Level of detail the template asks for and how many sources need explaining |
| Publication and hosting | Internal web or publishing team | Recurring, usually low effort per release | Where the summary must sit and how many model versions are published |
| Maintenance after model changes | Model owners and documentation staff | Recurring | How often the model is retrained or fine-tuned and how many versions remain on the market |
| External legal or assessment review | Outside counsel or an independent reviewer, if engaged | Optional, usually one-time per release | Scope of the review requested and the internal readiness of the records |
| Documentation tooling | Software licenses or self-hosted platform operation | Licenses recurring; self-hosting removes license spend but not staff time | Wiki or versioning platform choice, hosting model and integration effort |
Who owns the summary, who prepares it and who checks it
The duty under Article 53(1)(d) sits with the provider of the general-purpose AI model. If your organization places a model on the EU market, your name is on the obligation, and no partner, consultant or auditor takes it over. Your team decides whether the published summary is accurate, whether it follows the AI Office template of 24 July 2025, and when it goes live. Your team also answers for the training data records behind every statement in the summary.
- Legal accountability: Your leadership signs off that the summary is complete and that the provider has met its obligation, including for open-source releases.
- Data record accuracy: Your data owners confirm the main data collections and the other sources described in the summary actually trained the model.
- Publication decision: Someone with authority approves each version before it is published, and approves updates when training data changes.
- Level of detail: Your legal and product leads decide what counts as a sufficiently detailed overview for your model, with reference to the codes of practice under Article 56.
- Ownership of questions: Your team answers questions from regulators, copyright holders and downstream users about the summary.
Before engaging anyone, confirm internally who holds each of these five decisions in writing.
An implementation partner can do the operational groundwork that makes a summary accurate and repeatable. In a fixed-scope engagement, the partner prepares the data inventory, the evidence structure, the publication workflow and the update process. These are the parts that fail quietly when nobody owns them, such as training data sources that are never recorded or versions that are published without review. The partner works inside your infrastructure and your document systems, so the records stay under your control.
- Data inventory: The partner helps catalog datasets, their origin and the processing steps, so your data owners can confirm each entry.
- Evidence structure: The partner sets up how records are kept, linked and versioned, so each statement in the summary traces to a source.
- Publication workflow: The partner defines the review steps, approvers and release checks that your team signs off.
- Update process: The partner designs how changes in training data trigger a revised summary and a new version.
- Limit on attestation: The partner cannot certify that the summary is legally sufficient. Ask in writing which of these deliverables carry that limit in your scope.
An independent auditor or assessor tests the summary and reports on it. The assessor is not part of the team that built the records, and that separation is what gives the report weight. For the AI Act, the Commission's AI Office enforces the general-purpose AI model rules, so your team should expect that any formal review is tied to that supervision. Confirm with the relevant authority and your legal advisers how independent review is expected to work for your model, because the Act and its codes of practice are still being applied in practice.
- Independent testing: The assessor samples statements in the summary and traces them back to records you can produce.
- Consistency checks: The assessor compares the published summary with internal records and prior versions.
- Reporting: The assessor issues its own findings, and the partner does not write or edit that conclusion.
- Separation of duties: If the partner prepared the evidence, the assessor still tests it independently, and your team should not ask the partner to pre-approve the findings.
- Scope agreement: Agree the assessment scope and evidence list with the assessor before preparation starts.
Ask your assessor to state in writing which parts of the summary it will test and what evidence it will accept.
Keeping the summary under version control with self-hosted tools
A self-hosted wiki can hold the public summary and its evidence trail, but it cannot make the summary accurate. The useful work of a wiki here is recordkeeping: every published version of the training content summary, every draft, and every approval should be traceable to a person and a date. XWiki keeps every change to a page under version control, recording what changed, when and by whom. Users can compare any two versions and roll back to an earlier one. For Article 53(1)(d), that means a compliance lead can show an assessor exactly what the summary said at the time of a given model release, who changed the data collection descriptions, and when a previous wording was replaced. Confirm the exact version history behavior, export options and retention settings in the XWiki release you deploy, since the history is only as useful as your retention policy makes it.
BookStack handles the other half of the problem: who may change approved text. Its user abilities come from the roles assigned to each user, and permissions can be overridden per role at the shelf, book, chapter or page level. A practical pattern is to let model teams edit draft pages in one chapter while restricting edit and publish rights on the final, approved summary to a small compliance or legal group. Decide before deployment which roles can publish, which can edit drafts, and whether the publish step is a separate permission from editing. Test those rules with a non-admin account, because a permission granted at a parent level can be inherited in ways that are easy to miss. Neither tool identifies training data. The data register, listing the main data collections and other sources, must come from the provider's own records of dataset acquisition and curation, and the wiki should only store and version what that register says. Finally, check the license of each tool against your intended use, including any obligations on modified code, before you make either one a dependency of your compliance process.
Where providers usually fall short on the training summary
Most gaps in a training content summary come from treating it as a one-time publication rather than a record that must match the model. The cards below cover where summaries tend to fail under Article 53(1)(d) and the action that closes each gap.
Data collections named only by category
A summary that says the model was trained on "web data" or "licensed content" gives an assessor and a rights holder nothing to check. The template expects the main data collections to be listed, with the source of each. Build a register that names each collection, its origin, its volume range and the date it was collected, and confirm that every category in the published summary traces back to a register entry.
Summary not tied to the model version
Training content summaries are often written for a product name rather than a specific checkpoint, so readers cannot tell which weights the description covers. Record the model identifier, version and release date in the summary, and keep the training data record under the same version control as the model artifacts so the two can be compared at any point.
Licensing and opt-out status not recorded
The template helps copyright holders exercise their rights, so a summary that omits how each collection was licensed or whether machine-readable opt-outs were honored weakens that purpose. For each source, record the license or legal basis, the opt-out check performed and its outcome. Confirm that these records feed the copyright policy required by Article 53(1)(c), so the two documents do not contradict each other.
No update after retraining or fine-tuning
A summary written at launch becomes inaccurate once the model is retrained, fine-tuned on new data or combined with additional sources. Set a rule that any change to the training data triggers a review of the published summary before the new version is released. Ask the provider to show, for the current model, which changes in the training data are reflected in the publication and when the summary was last revised.
No legal review trail
Assessors and rights holders will ask who decided what the summary says and on what basis. Without a dated record of the review, reviewers and approvals, the summary is hard to defend. Keep a sign-off log per version that names the reviewers, the data sources they assessed, the open questions and the decision. Store the log in a system that records every edit and approval, so each published version can be traced to its review.
Summary hard to find or compare
A summary buried in a PDF on a product page, or published in a format that differs between model releases, is difficult for regulators and the public to locate and compare. Publish each summary at a stable, dated address using the AI Office template structure, keep prior versions accessible, and use consistent headings across releases. Check that the summary can be found from the model's documentation page and that two versions can be read side by side.
Questions buyers ask about the training content summary
Do open-source general-purpose AI models have to publish a training content summary?
Yes. The open-source exemption that applies to some of the other provider duties does not cover the duty to publish a sufficiently detailed summary of the training content. Article 53(1)(d) requires every provider to draw up and publish that summary using the template the AI Office presented on 24 July 2025. The template asks for a comprehensive overview of the training data, including the main data collections and an explanation of any other sources used. If your model is open source, the summary is still due, and you should confirm with counsel whether any other exemption you rely on applies to your specific release.
How long does a training content summary take to prepare?
No fixed duration applies, and the effort depends on how well your training data is already documented. The main drivers are the number of data collections used, whether you can trace their origin and licensing, how many other sources you must explain, and how many people must review the wording. Teams that keep dataset records during training usually spend less time than teams that must reconstruct them afterward. Ask any partner to state the assumed effort, the data sources in scope and the review rounds included in a written quote, rather than accepting a general estimate.
Can we prepare the training content summary in-house?
Yes, in most cases the organization can prepare the summary itself, because the template is public and the content must reflect your own training data. The work that usually needs internal ownership is the record of data collections, the sign-off by legal and compliance, and the publication decision. External help is most useful for building the dataset inventory, drafting plain-language descriptions, and checking the summary against the template and your records. Keep a versioned copy of each published summary so you can show what changed between model releases.
What can an implementation partner sign for us, and what can it not?
A partner can help prepare the systems and evidence behind the summary, such as dataset registers, version-controlled documentation and review workflows. It cannot make the legal determinations, approve the publication, or issue any attestation or certificate. Under the Act, the provider owns the duty and the content of the summary. Only an independent auditor, assessor or certification body issues reports or certificates. DeployOpen prepares systems, controls and evidence for assessments and does not issue audit reports or attestations, so the signatory of the summary should remain a named person inside your organization.
Does the 2 August 2027 date apply to models placed on the market before August 2025?
Yes. Under Article 111(3), providers of general-purpose AI models placed on the market before 2 August 2025 must comply by 2 August 2027. Models placed on the market on or after 2 August 2025 are not given that later date, so they should be compliant at placement. Confirm the placement date of each model version you distribute, since a new version may count as a new placement. Use the dates in the Official Journal text and check your own legal analysis before relying on the transition for any specific model.
What should a fixed-scope quote for a training content summary include?
A fixed-scope quote should list the models covered, the version and placement date of each, and the data collections in scope. It should also name the deliverables, such as the completed template, the supporting dataset register and the review record. Ask the partner to state what is excluded, including legal review, publication and any third-party data licensing work. Request the assumed review rounds, the responsibilities of your team, and how changes after the first draft are priced. Written scope agreed before work starts makes the cost and timeline comparable across bidders.
How does the summary relate to the copyright policy and technical documentation?
The summary is one of several linked duties. Article 53(1)(c) requires a copyright policy that complies with EU copyright law and honors machine-readable text and data mining opt-outs. The Commission says the template also helps parties with legitimate interests, such as copyright holders, exercise their rights. Article 53(1)(a) and (b) require technical documentation and information for downstream providers. The dataset records behind the summary should feed these documents, so one source of truth prevents contradictory statements. Keep the summary, policy and documentation under the same version control.
How DeployOpen prepares the evidence for this duty
DeployOpen works on Article 53(1)(d) as a systems and evidence partner. We help a provider organize the training content record, the publication workflow and the version history behind the public summary, while the provider keeps ownership of the summary's content and its legal position. DeployOpen does not issue reports or certify compliance.
How we scope
- Engagements are fixed-scope, with the scope, deliverables and timeline agreed in writing before work starts.
- The written scope names which models, versions and training data sources the public summary will cover.
- Scope also states who signs off the summary text, typically legal, data governance and the model owner.
How we build
- We set up a controlled wiki or documentation space where each training data collection is recorded with its source and owner.
- Permissions are configured by role so that only named reviewers can edit or approve the published summary.
- We connect the model's training pipeline records to the documentation so that data changes trigger a documented update.
How we hand over
- Handover includes the summary draft in the AI Office template structure, with a clear record of the main data collections and other sources.
- Every revision is kept under version control, showing what changed, when and by whom, with the ability to compare and roll back.
- We document the review and publication steps so the provider can show how the summary was produced and kept current.
How we support
- Ongoing support is available as a retainer for updates when the model is retrained, fine-tuned or replaced.
- We can help track the 2 August 2027 deadline for models placed on the market before 2 August 2025 (Article 111(3)).
- Questions on the adequacy of detail or copyright positions should be confirmed with qualified legal counsel and the relevant AI Office guidance.
