EU AI Act for Fine-Tuners: What Documentation Does Article 53 Actually Require?

The EU AI Act entered into force in August 2024, with a phased implementation timeline. The provisions covering general-purpose AI (GPAI) models — the category that includes large language models used as foundation models for fine-tuning — apply from August 2025. If your organization is fine-tuning a GPAI model for internal use within the EU, or providing fine-tuning services to EU customers, the obligations under Chapter V of the AI Act are now in scope.

This post focuses specifically on what Article 53 requires of GPAI model providers, and how those requirements apply to organizations engaged in fine-tuning — including enterprise teams fine-tuning for internal deployment. The regulation is dense and the implementing guidance continues to develop, so this is an analysis of what the text says, not legal advice for your specific situation.

GPAI scope and where fine-tuners fit

The AI Act defines a GPAI model as an AI model trained on broad data at scale, capable of performing a wide range of distinct tasks. Commercial foundation models — large language models made available via API or open weights — clearly fall within this definition. The question for fine-tuners is: when you take a GPAI model and fine-tune it for a specific enterprise use case, are you a GPAI model provider subject to Chapter V obligations?

The answer depends on several factors. The AI Act's GPAI provisions primarily target providers who place GPAI models on the EU market. "Placing on the market" means making the model available for third-party use. If you fine-tune a model for internal use only — deployed within your organization, not made available to external parties — the GPAI provider obligations in Article 53 may be limited.

However, fine-tuners face obligations from two directions. First, if the fine-tuned model is used in a system that constitutes a high-risk AI application under Annex III (credit scoring, employment decisions, critical infrastructure management, certain medical applications), the high-risk AI system requirements under Articles 9-17 apply regardless of whether the GPAI-specific obligations apply. Second, even for internal use, the documentation that the EU AI Act's codes of practice and guidance expect of GPAI model users and fine-tuners is substantial and establishing itself as a market expectation.

Article 53 obligations unpacked

Article 53 sets out the obligations of GPAI model providers. The core requirements are:

Technical documentation (Article 53(1)(a)). Providers must draw up and keep up-to-date technical documentation of the model, including information as specified in Annex XI. This documentation must be made available to the AI Office and national competent authorities upon request. For fine-tuned models placed on the EU market, this means maintaining documentation that reflects the fine-tuned version, not just the base model.

Information and documentation for downstream providers (Article 53(1)(b)). When a fine-tuned model is made available to downstream providers (other parties who will build applications on top of it), the fine-tuner must provide sufficient information for those providers to comply with their own obligations. This creates a documentation chain: information about the fine-tuning process, the training data, and the model's intended use must flow downstream.

Copyright compliance policy (Article 53(1)(c)). GPAI providers must implement a policy to comply with EU copyright law, including Directive 2019/790, with respect to training data. For fine-tuners, this means documenting that the fine-tuning corpus was assembled with appropriate copyright clearance — a documentation requirement that needs to be addressed before training, not after.

Summary of training data (Article 53(1)(d)). Providers must publish a sufficiently detailed summary of the training data used to train the GPAI model, according to a template provided by the AI Office. For fine-tuners, this applies to the fine-tuning training data — the corpus used for the specific fine-tuning run, not just the base model's pretraining data.

Training data documentation requirements

The training data documentation requirements are among the most operationally demanding for fine-tuners. The Article 53 framework, read together with Annex XI and the GPAI code of practice guidance, expects documentation that covers:

• Data sources — where the fine-tuning data came from, including source type (proprietary, licensed, publicly available)
• Data selection criteria — why these data sources were chosen, what filtering was applied
• Data quantities — record counts, token counts, data volume
• Copyright status of training data — licensing terms for each data source
• Personal data handling — whether the fine-tuning corpus included personal data, and under what legal basis (GDPR compliance is a separate requirement but intersects with the AI Act documentation obligations)
• Data governance procedures — how data quality was assessed and what filtering was applied to remove harmful or inappropriate content

This level of training data documentation is more detailed than what most MLOps teams currently produce as a matter of course. A training dataset assembled from multiple internal sources with varying data source agreements and data governance histories requires significant upfront work to document at this level — and that work needs to happen before training begins, not as a post-hoc reconstruction exercise.

Technical documentation: Annex XI

Annex XI of the AI Act specifies the technical documentation requirements for GPAI models. For fine-tuned models, the relevant Annex XI elements include:

General description of the model. Architecture description, parameter count, training compute, training methodology. For fine-tuned models, this includes description of the base model and the fine-tuning approach (full fine-tuning, LoRA, instruction tuning, RLHF).

Description of training data. The documentation described in the previous section, presented in a structured format. The AI Office's template guidance continues to develop, but the expectation is structured documentation that could be reviewed by technical and non-technical evaluators.

Evaluation results. Results of model evaluation, including at minimum safety and capability evaluations. For fine-tuned models, this means evaluation of the fine-tuned version specifically — not just the base model's published evaluation results.

Known and foreseeable risks. Documentation of risks identified during development and evaluation, including misuse risks, limitations, and recommended safeguards. This is a risk documentation requirement, not a risk elimination requirement — the obligation is to document and communicate risks, not to prove the model has no risks.

Mitigation measures for risks. What technical and operational measures have been implemented to address identified risks. For a fine-tuned model used in a regulated context, this includes deployment safeguards (output filtering, human review processes, scope limitations) as well as model-level measures.

The high-risk AI system overlay

When a GPAI model is used in a system that constitutes a high-risk AI application under Annex III, the requirements are more extensive. Annex III of the AI Act lists high-risk AI system categories including: biometric identification and categorisation, management of critical infrastructure, educational assessment, employment and worker management, essential private and public services (including credit scoring and social scoring), law enforcement, migration and border control, administration of justice, and democratic processes.

Credit decisioning, clinical diagnosis support, and insurance underwriting are all plausibly within Annex III scope. If your fine-tuned model is used in any of these contexts, the high-risk system requirements under Chapter III apply — which include conformity assessment, registration in the EU database for high-risk AI systems, technical documentation meeting the more detailed requirements of Annex IV, and ongoing monitoring and post-market surveillance.

We're not saying that every enterprise LLM is automatically high-risk — the Annex III categories require careful analysis to determine whether a specific system falls within scope. The point is that the GPAI documentation obligations and the high-risk system obligations can stack: a fine-tuned GPAI model used in a high-risk context faces both sets of requirements.

The internal use exemption and its limits

The AI Act provides a modified regime for providers that use GPAI models under their own authority — including fine-tuning for internal deployment. Article 53(2) provides that providers integrating a GPAI model into their own AI system for their own use shall not be subject to the obligations regarding transparency and copyright compliance policy that apply to providers making models available externally, provided they comply with the relevant code of practice.

This exemption is real but limited. The technical documentation requirements in Annex XI still apply to high-risk AI systems that use GPAI models internally. And the exemption is conditioned on compliance with the applicable code of practice — codes of practice are being developed by the AI Office and are not yet finalized, so the specific conditions for the exemption are still being determined.

Practically, organizations relying on the internal use exemption should still maintain Article 53-level technical documentation for their fine-tuned models. The documentation provides the foundation for demonstrating compliance if the scope of the exemption is narrowed or if the model's deployment context changes in ways that bring it within full GPAI provider scope.

Where MLOps teams are not ready

Three readiness gaps appear consistently when we review how MLOps teams at EU-facing enterprises currently document their fine-tuning processes:

Training data documentation depth. Most teams can produce record counts and data source names. Few can produce per-source copyright clearance records, data quality assessment documentation, or content filtering procedure documentation at the level Article 53 expects. The gap isn't technical — the information exists in data governance systems and data source agreements — but assembling it into structured training data documentation is not currently part of the pre-training workflow.

Evaluation documentation completeness. Evaluation results are logged in experiment tracking tools but not always structured in ways that map to AI Act categories (safety evaluation, capability evaluation, risk evaluation). Connecting eval results to documented risk identification and mitigation decisions requires a documentation layer that experiment tracking doesn't currently provide.

Retention and accessibility. The AI Act requires technical documentation to be retained for ten years after the model is placed on the market or put into service (Article 18). Most MLOps artifact retention policies are driven by storage cost rather than regulatory retention requirements. Documentation that survives model lifecycle changes, team restructurings, and infrastructure migrations is a new organizational requirement for many teams.

The documentation pipeline needed for AI Act compliance is not fundamentally different from what well-run MLOps teams should be doing anyway — but it needs to be structured around regulatory categories rather than engineering convenience. Building that structure into the pipeline upfront, before fine-tuning begins, is significantly less work than reconstructing it after the fact during a compliance review.