Public Summary of Training Content for a general-purpose AI model (EU official template)

Structure (12 sections)

1. 1. Version of the summary and last update (template header)

   Ahead of the body, the official template asks for two header fields: the version of the summary, with links to previous versions where applicable, and the last update date in DD/MM/YY form. Settle the versioning policy first: what prompts a new version (a new model version, a new category of data source, a change in crawler behaviour, a change in the rights-reservation mechanism, an added modality), how long previous versions are kept and under what URL structure. Rightsholders are among the most active readers of this document and will diff versions against each other; omitting links to previous versions, or quietly replacing the content of an old one, is the fastest route to a complaint. State plainly on the page which model versions this summary covers, so the public does not read it as covering the whole product line.

   Evidence to attach

   • · Versioning policy for the summary (release triggers, approver)
   • · Archive of previous versions and the list of their public URLs
   • · Change notes between versions, written for rightsholders
   • · Screenshot and timestamp of the published summary page

   Common pitfalls

   • · Overwriting the previous version so it is no longer reachable and rightsholders cannot check what changed;
   • · A last-update date frozen while the model has iterated several times;
   • · Not stating which model versions are covered, so one summary is read as covering the entire product line.

2. 2. 1.1 Provider identification

   Give the provider’s name and contact details; where the provider is established outside the Union, also give the name and contact details of the EU authorised representative (Art. 54). For Chinese companies this is the first field checked: placing a general-purpose AI model on the Union market without an authorised representative is itself a separate infringement, the mandate must be in writing, and its scope must at least match the statutory minimum in Art. 54. Give a contact channel that is real and staffed — rightsholders acting on the summary usually start here. State whether "questions about this summary" and "copyright enquiries" go to the same address, so rightsholder correspondence is not lost in product support.

   Evidence to attach

   • · Written mandate for the EU authorised representative, covering the Art. 54 scope
   • · The representative’s registered address and corporate registration details
   • · Response process and target turnaround for the contact channel
   • · Where a group has several entities: which entity is the provider placing the model on the market

   Common pitfalls

   • · A generic product-support mailbox as the contact, where rightsholder mail goes unrecognised;
   • · The authorised representative field left blank, or filled with a group affiliate that has no EU establishment;
   • · A mandate that does not cover the statutory Art. 54 tasks, and is therefore hollow.

3. 3. 1.2 Model identification

   Three fields. First, versioned model name(s): the unique identifier for the model or model versions this summary covers (for example Llama 3.1-405B); under point 30 of the Explanatory Notice the same summary may cover several models or versions provided their respective summaries would be identical, and where available a link to further public documentation such as the model card should be given. Second, model dependencies: where the model results from a modification, including fine-tuning, of one or more general-purpose AI models already placed on the Union market, name the model version(s) concerned and link to their summaries where available. Third, the date of placement on the Union market, given per model or version where the summary covers more than one, per point 30. For Chinese companies fine-tuning open-weight bases, the dependency field must be filled honestly — a missing upstream summary link routes rightsholder questions straight to you.

   Evidence to attach

   • · Model version identifier convention and the internal version register
   • · Base-model provenance and licence, with a record of checking the fine-tuning terms
   • · Link-check record for the upstream models’ summaries
   • · Evidence of the date each version was placed on the Union market (release records, contracts, launch announcements)
   • · Link to the model card (see the model card template)

   Common pitfalls

   • · A dependency field reading "based on an open-source model", with no name or version, so rightsholders cannot trace the upstream corpus;
   • · Using an internal codename as the public identifier, which nobody can match to a released model;
   • · Giving the global launch date as the date of placement on the Union market, which are often different;
   • · One summary covering several model versions whose content is not in fact identical, contrary to the premise of point 30.

4. 4. 1.3 Modalities, overall training data size and other characteristics

   This section covers the overall training data **after pre-processing and before training**. Tick the modalities present (text, image, audio, video, other) and, for each, select the range the estimated total falls in: text — less than 1 billion tokens / 1 billion to 10 trillion tokens / more than 10 trillion tokens; image — less than 1 million images / 1 million to 1 billion / more than 1 billion; audio and video alike — less than 10 000 hours / 10 000 to 1 million hours / more than 1 million hours. You may instead give an approximate size in another unit; dynamic datasets may be excluded from the estimate; for "other", specify the modality with an approximate size and unit. Each modality also needs a general description of the types of content, for which the template gives examples: text may be fiction and non-fiction, scientific text, press publications, legal and official documents, social media comments, source code; images may be photography, visual art works, infographics, social media images, logos and brands; audio may be musical compositions and recordings, audiobooks, radio shows and podcasts, private audio communication; video may be music videos, films, TV programmes, performances, video games, video clips, journalistic videos, social media videos. Then give: the latest date when data was collected or obtained for training (MM/YYYY), and whether the model continues to be trained on new or dynamic data after that date; a description of the linguistic characteristics of the training data, with particular attention to EU official languages; and, where readily available and so far as relevant and practicable, other relevant characteristics such as national, regional or demographic specificities. Note the two conventions the template sets for audio: audio that is part of video belongs in the video modality, and "audio" is understood to include speech.

   Evidence to attach

   • · Method and working for estimating the data size per modality, including tokenisation or compression assumptions
   • · Evidence of the latest data-collection date (job records, snapshot timestamps)
   • · Configuration notes on continuous training and dynamic data
   • · Language-distribution statistics, including coverage of EU official languages
   • · Content-type distribution statistics and the classification convention used
   • · Record of what was excluded as dynamic datasets

   Common pitfalls

   • · Counting the audio track of video again under the audio modality, so totals do not match reality;
   • · Linguistic characteristics given as "mainly Chinese and English", with nothing on EU official languages, which the template expressly asks you to focus on;
   • · Giving the model release date as the latest data-collection date, when they are months apart;
   • · Using "dynamic datasets may be excluded" to keep most of the corpus out of the estimate without saying what was excluded;
   • · A content-type description so general ("publicly available internet content") that rightsholders cannot tell whether their works may be included.

5. 5. 2.1 Publicly available datasets

   This section covers datasets compiled by a third party, made publicly available for free and readily downloadable as a whole or in predefined chunks — datasets and collections on public repositories and online platforms, specialised websites, and snapshots of common crawl. The template warns expressly that free public availability does not mean the content is free of rights: licensing arrangements or conditions of use may apply, and some free or open licences limit the permitted uses, including prohibiting model training. Start with yes/no on whether publicly available datasets were used, and if yes tick the modalities concerned. Then list the **large** publicly available datasets, where the template defines "large" as a dataset whose total size for any one modality exceeds 3% of the size of all publicly available datasets used for training in that modality; size is measured after pre-processing such as filtering, and datasets must not be split to circumvent reporting. For each large dataset give the identifier or name and a link through which it can be accessed; where no link is available, a general description including the approximate start and end dates of collection if known (otherwise "not known"); and, where only part of a dataset was used, the general approach to selecting those parts. For other publicly available datasets not listed, give a general description of their content, which may indicate the modalities, the nature of the content (such as personal data, copyright-protected content, or machine-generated data such as IoT or synthetic data), the linguistic characteristics where applicable, and the approximate start and end dates of collection if known.

   Evidence to attach

   • · Inventory of public datasets (name, version or snapshot, link, modality, post-processing size)
   • · The 3% threshold calculation and the "large" determinations
   • · Licence review records for each dataset, especially any no-training-use terms
   • · Where only part was used: the selection method and the selection script or configuration
   • · Evidence of collection start and end dates, or the basis for stating "not known"

   Common pitfalls

   • · Splitting one large dataset into sub-sets so each falls below 3% — circumvention the template expressly forbids;
   • · Computing the 3% on pre-processing size, which under-reports the large datasets;
   • · Assuming "publicly available" means free to use for training, without reviewing the licence;
   • · An "other public datasets" entry reading "various public corpora", which tells rightsholders nothing about scope;
   • · Dead links, or links pointing at a private page behind a login.

6. 6. 2.2 Private non-publicly available datasets from third parties (2.2.1 licensed / 2.2.2 other)

   This section covers third-party datasets that are not publicly available and were not disclosed under 2.1, which the template splits in two. 2.2.1 covers datasets commercially licensed by rightsholders or their representatives — datasets under transactional commercial licensing agreements concluded between the provider and rightsholders or their representatives, including collective management organisations and legitimate content aggregators entitled to license collectively on rightsholders’ behalf; answer yes/no on whether such agreements were concluded and, if yes, tick the modalities. 2.2.2 covers private datasets obtained from other third parties — through data intermediaries, non-publicly available databases, and third-party datasets for which no transactional commercial licence with rightsholders or their representatives exists; answer yes/no, tick the modalities, list the identifiers or names of the main such datasets that are **publicly known** with links to relevant information where available, and for those not publicly known give a general description of the content indicating the modalities, the nature of the content (personal data, copyright-protected content, machine-generated data such as IoT or synthetic data) and the linguistic characteristics where applicable. Both sub-sections carry an optional field for further detail such as the collection period and dataset size. A common pattern for Chinese providers is buying corpora through a data vendor without contracting with rightsholders — that belongs in 2.2.2, not 2.2.1, and mis-classifying it is something rightsholder organisations call out by name.

   Evidence to attach

   • · Inventory of commercial licences (counterparty, whether it is a rightsholder or its representative, scope including training use)
   • · Data-intermediary purchase contracts and an account of the rights chain (can the vendor show it had the right to license)
   • · Classification determinations distinguishing 2.2.1 from 2.2.2
   • · Determinations of public-knownness for each dataset and the reasoning
   • · Extracts of the vendor’s rights warranties and indemnities

   Common pitfalls

   • · Filing corpora bought from a data intermediary under 2.2.1, creating a false impression of rightsholder authorisation;
   • · Treating data as licensed where the vendor contract contains no express grant for training use;
   • · An arbitrary test of "publicly known" that moves datasets already reported in the press into the un-named bucket;
   • · Leaving the nature-of-content field silent on whether personal data is included — the very field data protection authorities enter through.

7. 7. 2.3 Data crawled and scraped from online sources

   This section covers data crawled, scraped or otherwise compiled from online sources directly by the provider or on its behalf, excluding publicly available datasets already compiled by third parties and made available on platforms such as common crawl, which fall under 2.1. The fields are: whether crawlers were used by or on behalf of the provider (yes/no); crawler names or identifiers; the purposes of the crawlers; a general description of crawler behaviour, for which the template instances respect for captchas, password-protected websites and paywalls, and respect for robots.txt and other protocols while crawling; the period of data collection (from MM/YYYY to MM/YYYY); a **comprehensive** description of the type of content and online sources crawled, including geographical, linguistic or demographic characteristics and the types of websites scraped (the template instances news, blogs, social media, forums, community websites, other user-generated content platforms, websites of cultural heritage institutions, educational sites, government portals, personal blogs, streaming, gaming platforms, online TV platforms, synthetic data libraries); the modalities covered; and a summary of the most relevant domain names — where content from internet domains has been crawled or scraped and used for training, list the most relevant domain names (top and second level, e.g. "example.com") by listing the top 10% of all domain names by size of content scraped, in a representative manner across all applicable modalities, while SMEs including start-ups disclose the top 5% or 1 000 domain names, whichever is lower; the list may be provided as a downloadable file or by explaining here how to access it. The optional field may disclose more domain names and/or URLs and the sources of individual works.

   Evidence to attach

   • · Crawler inventory (name or user-agent, purpose, operating period, owning entity)
   • · Technical configuration and sampled verification of robots.txt and other protocol compliance
   • · Technical account of how paywalls, login walls and captchas are handled
   • · Domain-size statistics and the script and output producing the top 10% list (or the SME top 5% / 1 000)
   • · Basis for SME status where the lower disclosure threshold is relied on
   • · The published domain list file and an accessibility check on it

   Common pitfalls

   • · Taking the top 10% by **count** of domain names when the template ranks by size of content scraped;
   • · A crawler-behaviour description that dodges robots.txt and paywalls, which rightsholders challenge immediately;
   • · Claiming the lower SME threshold with nothing to substantiate SME status;
   • · Treating crawling done on the provider’s behalf as "not our crawling" and omitting it — the template expressly includes it;
   • · Publishing the domain list as an image or in an unsearchable format, which guts its verifiability.

8. 8. 2.4 User data

   This section covers user data collected through all of the provider’s services and products, including mail services, social media platforms, content platforms, and interaction with the provider’s AI models and/or systems. The template expressly excludes two things: data licensed by users under the commercial transactional agreements described in 2.2.1, and customer data used to fine-tune models for specific purposes. The fields are: whether data from user interactions with the AI model (such as user input and prompts) was used to train the model (yes/no); whether data collected from user interactions with the provider’s other services or products was used (yes/no); if yes, a general description of the services or products used to collect it; the modalities covered; and optional further information. This is where the overlap with the GDPR is densest: where the user data includes personal data of people in the EU, that processing needs its own lawful basis, notice and — depending on the basis — an objection or opt-out route, and should be argued through in the DPIA. Enterprise customers care most about whether training feedback is on by default, so state the default and how to switch it off here or in a linked document.

   Evidence to attach

   • · Inventory of products and services whose user data feeds training, with the data flow
   • · Screenshots of the default training-feedback setting and the route to switch it off
   • · User notice text and evidence of the consent or opt-out mechanism
   • · Enterprise contract clauses on input data not being used for training, where applicable
   • · Cross-reference to the corresponding DPIA sections

   Common pitfalls

   • · Ticking "no" here while the product privacy policy says input "may be used to improve our models" — two public documents contradicting each other;
   • · Conflating enterprise fine-tuning data with consumer user data, when the template expressly excludes the former;
   • · Training feedback on by default with the off switch buried, which stalls almost every EU enterprise procurement;
   • · No cross-reference to the DPIA, so the lawful basis is stated differently here than in the privacy documentation.

9. 9. 2.5 Synthetic data

   This section covers synthetic data created by or on behalf of the provider to train the model directly on the outputs of another AI model, in particular through model distillation or model alignment such as AI feedback in reinforcement learning. The template excludes the use of AI models to clean or enrich data (AI-generated metadata enriching or modifying a dataset, such as depth maps or text descriptions of images); where this concerns publicly available datasets under 2.1 they are reported there; and where synthetic datasets are created by third parties on the provider’s behalf they are reported here rather than under 2.2.2. The fields are: whether synthetic AI-generated data was created by or on behalf of the provider for training (yes/no); if yes, the modality; if yes, the general-purpose AI model(s) used to generate it where available on the market, by name and with a link to their summaries where available; and information about other AI models used to generate synthetic data, including the provider’s own models not available on the market — this includes a general description of that model’s training data so far as known and to the extent needed for parties with legitimate interests to exercise their rights and to avoid circumventing the disclosure obligations in the other sections. That last clause is the point of the section: you cannot escape the disclosures in 2.1 to 2.4 by first generating data with an undisclosed in-house model and then training on the synthetic output.

   Evidence to attach

   • · Description of the synthetic-data generation pipeline (distillation, alignment, AI feedback, each configured)
   • · Inventory of generating models, including in-house models not on the market, with a general description of their training data
   • · Volume of synthetic data and its share of total training data
   • · Contracts for synthetic data generated by third parties on your behalf, and the classification record
   • · The criterion distinguishing "cleaning or enriching" from "generating synthetic training data", with the determinations made

   Common pitfalls

   • · Generating large synthetic corpora with an in-house, unreleased model and writing only "synthetic data was used", with no general description of that model’s training data — which the template requires precisely to prevent circumvention;
   • · Treating the distillation source model’s name as a trade secret and disclosing nothing, with no reasoning given;
   • · Reporting "AI labelling or captioning" as synthetic data, or conversely reporting genuine distillation output as data enrichment;
   • · Reporting third-party-generated synthetic data under 2.2.2, contrary to the template’s instruction.

10. 10. 2.6 Other sources of data

    This section covers data that does not fall under any earlier category; the template instances data collected from offline sources, self-digitised media such as digitised analogue text content and images, datasets labelled by humans commissioned by the provider, and human-generated data produced through reinforcement learning. The fields are: whether data sources other than those in 2.1 to 2.5 were used for training (yes/no); if yes, a narrative description of those sources and the data; and optional further information. For Chinese providers this section usually carries three real categories that fit nowhere earlier: material accumulated offline in the business (digitised paper archives, internal knowledge bases), human preference and instruction data produced by a commissioned labelling vendor, and data authored by in-house staff or crowd workers. Filling it in honestly costs little, and leaving it out costs a lot — when rightsholders and regulators reconcile the totals in 1.3 against the sources in 2.1 to 2.5 and the numbers do not add up, the first assumption is that this section was skipped.

    Evidence to attach

    • · Inventory of other sources (type, volume, how obtained, rights status)
    • · Commissioned-labelling contracts and the clauses assigning rights in the output
    • · Authorisation and provenance for digitised offline material
    • · Authorisation and labour-compliance records for in-house or crowd-authored data
    • · A reconciliation table tying the 1.3 totals to the volumes reported across 2.1 to 2.6

    Common pitfalls

    • · Ticking "no" while the 1.3 totals plainly exceed what 2.1 to 2.5 can account for, so the reconciliation fails;
    • · Treating commissioned labelling output as "our own data" and disclosing nothing;
    • · Saying nothing about the rights status of digitised offline material, leaving rightsholders unable to judge;
    • · A narrative description reduced to "some other internal data", which cannot be checked.

11. 11. 3.1 Respect of reservation of rights from the TDM exception or limitation

    This section concerns the measures the provider implements to identify and comply with reservations of rights from the text and data mining exception or limitation expressed under Art. 4(3) of Directive (EU) 2019/790, as set out in the copyright policy the provider puts in place under Art. 53(1)(c) of the AI Act. The fields are: whether the provider is a signatory to the Code of Practice for general-purpose AI models that includes commitments to respect reservations of rights from the TDM exception or limitation (yes/no); and a description of the measures implemented before model training to respect those reservations before and during data collection, including the opt-out protocols and solutions honoured by the provider or, as applicable, by the third parties from which datasets were obtained. The optional field encourages disclosure of a summary of the Art. 53(1)(c) copyright policy, for instance by linking to the relevant web page. Write it concretely: name the opt-out signals honoured (robots.txt directives, page-level metadata, location-based signals, the machine-readable reservation conventions in use), say whether the block happens at collection or as a filter before training, and explain how the requirement is passed through for content obtained indirectly via third-party datasets. Where content has already been removed from the corpus, state when and how broadly.

    Evidence to attach

    • · The full copyright policy and where it is published (Art. 53(1)(c))
    • · Technical description of the opt-out protocols and signals honoured, and when each took effect
    • · Sampled verification of rights-reservation detection (detection rate and misses)
    • · Third-party dataset vendors’ commitments on TDM reservations and your verification of them
    • · Register of rightsholder removal requests and how each was resolved
    • · Evidence of Code of Practice signatory status, if applicable

    Common pitfalls

    • · Writing only "we respect robots.txt" without an effective date, which invites the question of what happened to data collected before it;
    • · No pass-through verification of TDM reservations for third-party datasets, which effectively absorbs the risk;
    • · Claiming Code of Practice signatory status without appearing on the signatory list, or having signed chapters that carry no such commitment;
    • · A copyright policy that is unpublished or behind a dead link, which reduces this section’s credibility to zero;
    • · A single pre-training filter for rights reservations, with no standing mechanism for newly crawled data.

12. 12. 3.2 Removal of illegal content (and 3.3 other information)

    Section 3.2 concerns the measures taken to avoid or remove content that is illegal under Union law from the training data — the template instances blacklists, keywords and model-based classifiers — without requiring disclosure of specific details about internal business practices or trade secrets. The template notes that such measures are advisable where the training data is likely to include illegal or unlawful content under Union law, in particular child sexual abuse material and terrorist content and the non-authorised use of material protected by intellectual property rights, and that they do not include data selection practices aimed at increasing the model’s capability. Provide a general description of the measures taken. Section 3.3 is an optional "other information" field, encouraging voluntary disclosure of further relevant data-processing measures taken before or after training that bear on the respect and exercise of rights protected under Union law. Mind the boundary of a public document: show the regulator and rightsholders that the measures exist and operate in layers (blocking at collection, filtering the corpus, post-training evaluation, output-side protection in production) without publishing classifier thresholds or blacklist entries that would simply be evaded.

    Evidence to attach

    • · Description of the illegal-content screening approach and what each layer covers
    • · Effectiveness evaluation (recall and false-positive rates, sampled human review)
    • · Dedicated handling process and external reporting channel for CSAM and terrorist content
    • · Records of identifying and removing IP-infringing content
    • · Internal approval of what is voluntarily disclosed under 3.3, confirming the trade-secret boundary is respected

    Common pitfalls

    • · Writing only "we take the necessary measures", with no layers or types, so nothing can be judged;
    • · Presenting capability-driven data selection as illegal-content removal, which the template expressly separates;
    • · Publishing classifier thresholds and blacklist details in a public document, which simply assists evasion;
    • · Disclosing material under 3.3 that legal never reviewed, which later contradicts other public statements.