Fine-tuning a model under the AI Act: when you become a provider

When does fine-tuning a model make us its provider under the EU AI Act?

Under the Commission's guidelines of 18 July 2025 (C(2025) 5045), a downstream party that modifies a general-purpose AI model becomes its provider, indicatively, when the modification uses more than a third of the original model's training compute. That is the threshold to check first. The answer also depends on two other questions: whether the original model is general-purpose in the Commission's sense, which the guidelines treat as indicatively true when training compute exceeds 10^23 FLOP and the model can generate language, text-to-image or text-to-video, and whether the modified system ends up high-risk under the Act. The compute figures are indicative, not a safe harbor, so record the original training compute from the upstream provider's documentation and your own fine-tuning compute in the same units before you decide.

Confirm three things with your legal and technical teams. First, obtain the original model's training compute figure from the upstream provider, because you cannot estimate it reliably from the model card alone. Second, log the compute used in each fine-tuning or continued-training run, including runs that were discarded, since the ratio is measured against the whole modification. Third, check whether the modified model will be placed on the EU market or put into service under your own name, because provider duties attach to that act. If the modification crosses the threshold, duties such as technical documentation under Article 53(1)(a) and a public training-content summary under Article 53(1)(d) apply to you, and the open-source exemption does not remove the summary duty.

Your organization owns its compliance decisions and the evidence behind them. An implementation partner can help set up compute logging, model cards, a training-data register and the documentation pack, and can test the modified system against the requirements that apply to it. Only an independent auditor, assessor or other competent body issues reports or certificates, and no such body is named here as a substitute for your own legal analysis.

Which fine-tuning scenarios change our role?

Full or large-scale continued pretraining is the clearest case. The Commission's guidelines of 18 July 2025 treat a downstream party that modifies a general-purpose model as its provider, indicatively, when the modification uses more than a third of the original model's training compute. A continuation run on a large new corpus will often clear that line, so plan on becoming a provider of a general-purpose AI model from the start.

Compute ratio: Compare your modification compute with the original model's training compute. Ask the upstream provider to state the original figure, since the ratio cannot be calculated without it.
Technical documentation: Keep technical documentation under Article 53(1)(a), including training, testing and evaluation results and at least the Annex XI information, available to the AI Office and national authorities on request.
Copyright and training summary: Maintain a copyright policy and publish a sufficiently detailed summary of training content using the AI Office template. The open-source exemption does not cover the summary duty.
Systemic risk review: Confirm whether the modified model could fall under the systemic-risk duties in Chapter V, using its training compute and capabilities as the starting inputs.

Record how you measured the compute, because the ratio is the first thing an assessor or the AI Office will ask you to show.

What provider duties follow for a modified general-purpose model

Once a downstream modification makes you the provider of a general-purpose model, Article 53 applies to you in full. The duties below cover the technical file, the public training summary and the copyright policy, and they connect to the evidence you must keep ready for the AI Office and national authorities.

Technical documentation under Article 53(1)(a)

You must draw up and keep current technical documentation of the modified model, including its training, testing and evaluation results, with at least the information listed in Annex XI. Record the base model you started from, the datasets and compute used for your modification, and the evaluation runs that support your claims. The file must be available on request to the AI Office and national competent authorities, so assign an owner and a retention rule before the first fine-tuning run.

Public training content summary

Article 53(1)(d) requires you to draw up and publish a sufficiently detailed summary of the content used for training, following the template the AI Office provides. The open-source exemption does not remove this duty. Confirm which data sources your modification used, including any data you did not collect yourself, and check the current template before you draft the summary.

Copyright policy for the model

You must put in place a policy to comply with EU copyright law, including how you respect rights reservations expressed under EU law when collecting training data. Because Article 53(2) exempts open-source providers only from points (a) and (b), this policy still applies to an open-weight model you have fine-tuned. Document the sources you screened, how opt-outs were handled, and who reviews exceptions.

Open-source exemption scope

The open-source exemption in Article 53(2) covers only points (a) and (b) of Article 53(1). A modifier that releases the weights under a free and open-source licence still owes the copyright policy and the training summary. Check the licence terms and the exemption conditions against your release plan before you publish weights.

Systemic-risk duties apply separately

Article 53 is not the only layer. A general-purpose model with systemic risk carries additional duties for evaluation, risk assessment, incident reporting and cybersecurity, and the open-source exemption does not remove them. Confirm with counsel whether your modified model crosses the systemic-risk threshold, because the compute your modification uses is a factor in that assessment, not a substitute for it.

Cooperation from the initial provider

As amended in 2026, Article 25(2) requires the initial provider to share technical documentation, known limitations and failure modes, and targeted technical access for testing, unless it clearly specified that the system must not be changed into a high-risk system. Request these inputs in writing before you start, because your Article 53 file depends on them for the base model.

When modifying an AI system makes us a high-risk provider

Modifying an AI system after it is on the market can make your organization its provider under Article 25(1) of the AI Act, even if you never built it. The trigger is not the fine-tuning itself but its effect. Under Article 3(23), a substantial modification is a change made after placing on the market that was not foreseen in the initial conformity assessment and that either affects compliance with the high-risk requirements or changes the intended purpose the system was assessed for. Three routes lead to provider status: you put your name or trademark on a high-risk system, you make a substantial modification that keeps it high-risk, or you change the intended purpose of a system that was not high-risk so that it becomes high-risk. The third route matters most for general-purpose AI systems, where a new use case can carry a model into Annex III.

For each change, record whether it touches the assessed intended purpose, the data used, the performance or accuracy claims, the human oversight design, or the risk controls documented for the original system. Compare the change against the instructions for use and the technical documentation the initial provider supplied. If the change was foreseen and assessed, it may not be substantial. If it was not, treat the system as modified and reassess its classification before it goes into service. Confirm the exact wording of the intended purpose in the provider's documentation, since that wording is the baseline for the comparison.

Article 25(2), as amended in 2026, requires the initial provider to cooperate with you by sharing technical documentation, known limitations and failure modes, and targeted technical access for testing, unless it clearly specified that the system must not be changed into a high-risk system. Ask for this information in writing before you start modification work, and check whether the supplier has excluded high-risk use in its terms. The high-risk rules in Chapter III Sections 1 to 3 apply from 2 December 2027 for Annex III systems and from 2 August 2028 for Annex I product systems, so plan the documentation, quality management and conformity assessment work against those dates. Confirm the applicable dates with the EUR-Lex consolidated text and with your own counsel.

How to establish which role applies before deployment

This sequence settles whether your organization is a provider, a deployer, or both before you put a fine-tuned model into use. Each phase produces a dated record that a regulator, auditor or upstream provider can check.

Inventory the base model and its licence
Name the base general-purpose model, its version, the provider that released it, and the licence terms that govern use, modification and redistribution. Confirm whether the release is open-weight, under what licence, and whether the provider has published its technical documentation and a training data summary. Your legal or compliance lead owns this record, with engineering supplying the model identifiers. The step is done when a single model record exists with the version, licence text reference, and the upstream provider's contact for AI Act cooperation. Confirm each fact against the provider's own release notes rather than secondary summaries.
Record training compute for the original and the modification
Engineering records the training compute used to build the original model, as the upstream provider reports it, and the compute your fine-tuning or other modification consumed, measured in the same units. Keep the job logs, hardware counts, run durations and the calculation method so the figure can be reproduced. If the upstream provider does not disclose original training compute, record that gap and ask for it in writing before you proceed. The step closes with a compute worksheet signed off by the model owner, showing both numbers and the calculation behind them.
Decide the general-purpose status of the model
Compliance counsel applies the Commission's guidelines to decide whether the base model is a general-purpose AI model, and whether your modified model remains one. The guidelines use an indicative training compute threshold together with the model's ability to generate language, text-to-image or text-to-video, so both facts from the previous steps feed this decision. Document the reasoning, including any assumptions about the indicative threshold, and record who approved it. The output is a short determination memo stating whether the model is general-purpose and why.
Compare modification compute against the one-third indication
Using the compute worksheet, the model owner calculates whether the modification used more than a third of the original model's training compute. The Commission's guidelines treat a downstream modifier as a provider at that point, though the threshold is indicative and not a bright line in every case. If the figure is close to the threshold, record the margin and seek a legal view before relying on it. The output is a recorded yes or no determination with its arithmetic attached, which becomes the basis for your provider duties if the answer is yes.
Classify the intended use against Annex III
Separately from the model question, compliance staff check whether the intended use of the system falls within an Annex III high-risk category, such as employment, credit assessment or education. Model-level provider status and system-level high-risk status are different tests, so a model can trigger provider duties while the system stays out of scope, or the reverse. Record the intended purpose in the words used in your product documentation, then record the Annex III category or the reason none applies. If a use sits near a category, document the Article 6(3) analysis and whether a qualified legal reviewer agreed with it.
Gather cooperation documentation from the upstream provider
Request in writing the information the upstream provider can share: technical documentation for the base model, known limitations and failure modes, and any technical access for testing. Under Article 25(2) as amended in 2026, the initial provider must cooperate with a new provider in these ways unless it clearly specified that the system must not be changed into a high-risk system, so check the licence and usage policy for that statement. Log each request, the response date, and any gaps. The step is complete when the cooperation file holds the documents received and a list of items the upstream provider declined or could not supply.
Agree written responsibilities before deployment
Legal, product and the upstream provider sign a written allocation of duties covering who maintains technical documentation, who publishes any required training content summary, who handles incident reporting and post-market monitoring, and who answers regulator requests. Where you are the provider of the modified model, the agreement records which duties you have taken on and which remain with the upstream provider. Keep the signed document with the determination memo and the cooperation file. The output is an approved responsibilities record that an assessor can trace back to each role determination made in the earlier steps.

What must be in place before we fine-tune

Fine-tuning can move you from downstream user to provider, so the records that decide your role need to exist before the first training run starts. The cards below cover the compute, upstream documentation, dataset provenance, evaluation and change records that an assessor will ask to see, and each one explains how to check it.

Compute logging per training run

Record the floating-point compute consumed by every fine-tuning run, including failed runs, restarts and hyperparameter sweeps, because the threshold test depends on the total. Compare that figure against the original model's training compute from the upstream provider's documentation. Check that the log is generated by the training infrastructure rather than estimated from memory, and keep it with the run configuration. Confirm with the upstream provider how they measured their own compute, since the two figures must be on the same basis.

Upstream model documentation record

Keep a dated copy of everything the upstream provider has shared about the base model: technical documentation, intended uses, known limitations, training data summaries and licence terms. Note what was supplied, what was withheld and the version identifier of each document. Check whether the provider has shared the information the AI Act expects a cooperating provider to hand over, and if not, record the gap and the request you made. Without this record, you cannot show what you inherited and what you added.

Dataset provenance register for copyright and training summary

List each dataset used for fine-tuning with its source, licence basis, collection method, personal data status and the date you obtained it. This register feeds the copyright policy and the public training content summary that a general-purpose model provider must publish. Check that every source has a documented right to use it, and flag any scraped or third-party material for legal review. Where you cannot trace a source, exclude it or record the risk decision in writing.

Evaluation records before and after tuning

Keep the evaluation plan, test sets, metrics, results and reviewer sign-off for the base model and each fine-tuned version. The records should show the benchmarks used, the safety and misuse tests run, and the regressions found. Check that test sets were kept separate from training data and that results can be reproduced from stored configurations. These records support the evaluation results the technical documentation must contain.

Change log linking modifications to intended purpose

Maintain a versioned log that records each modification, who approved it, the reason for it and the intended purpose it serves. Whether a change is substantial depends on whether it affects compliance with high-risk requirements or changes the intended purpose assessed, so each entry should state that effect explicitly. Check the log against the intended purpose statement at each release. A change that moves the system toward a high-risk use should trigger a review before deployment.

Questions about fine-tuning and provider status

Does fine-tuning a model always make us its provider under the AI Act?

No. Fine-tuning makes you the provider of the modified model only when the modification is large enough to cross the Commission's indicative test. Under its guidelines of 18 July 2025, a downstream party that modifies a model becomes its provider, indicatively, when the modification uses more than a third of the original model's training compute. Light instruction tuning, small adapters or a narrow domain adjustment often fall well below that line, but the outcome depends on the compute you actually used. The label your team gives the work does not decide it. Record the compute for every training run from the first experiment, keep the figures with the model documentation, and reassess whenever the dataset or method changes. This test sits alongside a separate question of whether the model is general-purpose at all, which the guidelines treat as indicatively met above 10^23 FLOP for a model that can generate language, text-to-image or text-to-video.

Can we stay under the threshold to avoid provider status?

Yes, it is possible to stay under the indicative threshold, but only if you can show with measurements that you did. The one-third figure compares your modification compute with the original model's training compute, so you need that baseline in writing. Ask the upstream provider to state its training compute before you download or sign, and keep the statement with your records. Staying under the model-level test does not end your role. If you place the system on the market under your own name or trademark, or change its intended purpose so that a non-high-risk system becomes high-risk, Article 25(1) can make you the provider of that system. Also check the Article 3(23) definition of substantial modification, which turns on whether a change affects compliance with the high-risk requirements or changes the intended purpose assessed. Document each decision, because an assessor will test the reasoning as well as the outcome.

Do we need a notified body after becoming a provider?

Usually not. Most Annex III high-risk systems use internal-control conformity assessment under Annex VI, so the provider runs the assessment itself, maintains the technical documentation and signs the declaration of conformity. Notified bodies are involved for some biometric systems and for certain Annex I products, as Article 43 sets out. Confirm first whether your use falls in an Annex III category and when those rules apply: under the 2026 amendment, Annex III high-risk rules apply from 2 December 2027. Duties for general-purpose model providers follow a different path, since the AI Office supervises them. Cost drivers differ by route. An internal-control route costs mostly internal time, documentation work and any independent review you choose to buy. A notified body route adds that body's own fees and timeline, so request both in writing from each body you consider. Confirm your route with a legal adviser before you set the budget.

Who issues the evidence, and what does our implementation partner do?

Your organization owns its controls and its compliance position. An implementation partner prepares the systems and evidence: training records, logging, access control, evaluation results, documentation and the packs an assessor will request. DeployOpen works this way inside the client's own cloud accounts, data centers or air-gapped networks, but it does not issue audit reports, attestations or certifications. Only an independent auditor, assessor or certification body issues those. Upstream cooperation matters too. Under Article 25(2), as amended in 2026, the initial provider must share technical documentation, known limitations and failure modes, and targeted technical access for testing, unless it clearly specified that the system must not be changed into a high-risk system. Put that request in the contract with your model supplier before fine-tuning starts, and confirm in writing which items each party delivers. Read Article 25 of the AI Act

How much effort does fine-tuning compliance take for our team?

The effort depends on how much of the model you change, what you publish and whether the use is high-risk. The Act does not set hours, and no researched figure is available here, so ask for effort in the written scope rather than relying on a general estimate. The main workstreams are: measuring and logging training compute; technical documentation covering training, testing and evaluation results, with the information listed in Annex XI, kept current and available to the AI Office and national authorities under Article 53(1)(a); a public summary of training content using the AI Office template under Article 53(1)(d); a copyright policy; and, for high-risk uses, the evidence required by Articles 8 to 15. Machine learning engineers supply run logs and evaluation data, legal staff review the summary and copyright position, and security or platform staff own access control and log retention. Retraining triggers documentation updates, so ask your partner to split one-time setup from ongoing upkeep in the quote.

Does the open-source exemption remove our duties after fine-tuning?

No. The open-source exemption is narrower than many teams expect. Under Article 53(2), it covers only points (a) and (b) of Article 53(1), so an open-source model provider still needs a copyright policy. The training-content summary under Article 53(1)(d) is outside the exemption, so you must draw it up and publish it using the AI Office template. The Commission presented that template on 24 July 2025. The exemption concerns general-purpose model duties, so it does not settle whether a system built on the model is high-risk. Treat systemic-risk duties as a separate check, since they turn on a different test and are not covered in this answer. Ask your counsel whether your licence and distribution model qualify for any exemption at all, and whether the conditions in Article 53 fit your specific model before you rely on it. Read the AI Office training summary template announcement

How to choose a legal, compliance or implementation partner

A partner can help you scope AI Act duties after fine-tuning, but the outcome always rests with you and an independent body. The cards below set out what to verify before work starts, from legal qualifications and compute method to who issues any conformity outcome.

AI Act qualifications of the adviser

Ask who will do the legal analysis and whether that person has worked on the AI Act specifically, including Article 3 definitions and Article 25 value-chain duties. General privacy or security experience does not cover whether your fine-tune makes you a provider. Ask for named people, their role in the engagement, and who signs off the legal conclusion. Confirm that a qualified lawyer, not only a technical consultant, reviews the role analysis.

Documented compute estimation method

The Commission's indicative one-third threshold depends on measured training compute, so ask how the partner estimates the original model's training compute and your modification compute. Request the method in writing, the assumptions behind each figure, and the source of the original model's compute data. A partner who cannot show its arithmetic cannot defend the result to an authority.

Experience with model documentation

Provider duties under Article 53 require technical documentation that is kept current and available on request, plus a training content summary published on a template. Ask for examples of documentation packs the partner has prepared for models, and how they handle version control, evaluation results and Annex XI information. Confirm they know the difference between documents you keep and summaries you publish.

Independent assessors issue outcomes

Your partner can prepare systems, controls and evidence, but it cannot issue a conformity outcome, certificate or attestation. For Annex III systems, conformity assessment is generally internal control under Annex VI, and notified bodies apply only to certain biometric systems and Annex I products. Ask the partner to state in writing which parts of the work it does and which parts you or a third party must perform.

Written scope before work starts

Agree the scope, deliverables and timeline in writing before any work begins. A useful scope names the model and version, the fine-tuning runs counted, the intended purpose of any downstream system, and the copyright policy and training summary you need. Ask how changes to scope are priced and approved, and what happens to evidence if a later fine-tune changes the analysis.

Questions to ask before signing

Before signing, ask who owns the legal conclusion, which regulator views you would need to satisfy, and what the partner will not do. Ask whether they will work with your counsel, what they need from the original model provider, and how Article 25(2) cooperation would be requested and recorded. Ask what recurs after delivery, such as updates when new fine-tunes or guidance appear.

Where the answer changes for our organization

The answer depends on where your model starts. Training from scratch makes you the provider of a general-purpose AI model by default, so the Article 53 duties (technical documentation, a copyright policy and a public training-content summary) apply to you from the start. Adapting open weights is different: the open-source exemption in Article 53(2) relieves you of some documentation duties, but not the copyright policy or the training summary. Adapting a closed API model usually means you are a downstream modifier, and the one-third compute indication in the Commission's guidelines decides whether you become the provider of the modified model. Only prompting or retrieving (retrieval-augmented generation, system prompts, few-shot examples) normally does not modify the model at all, so the provider duties stay with the model supplier. Confirm the compute arithmetic against the Commission's guidelines (C(2025) 5045) and the consolidated text on EUR-Lex before you rely on any of these routes.

Your first decision is a measurement, not a legal opinion. Record the training compute of the original model as your engineering team can document it, record the compute of your own adaptation run, and keep both figures with the training logs. If you adapt a closed model, ask the supplier in writing whether its documentation covers the original compute and what it will share under Article 25(2) if you move toward high-risk use. If the supplier will not give you that information, plan for a gap in your own file. Also decide whether the adapted model is intended for a high-risk purpose, because that choice can make you a high-risk provider even when the model-level rules would not.

Your organization owns these decisions and the controls behind them. An implementation partner can prepare the training records, the documentation pack, the data lineage evidence and the test results that the file will rely on. Only an independent auditor, assessor or certification body issues reports or certificates, and no provider of implementation services can stand in for that role. Ask your legal and compliance leads to sign off the classification of each adaptation project, and ask the partner to show how each piece of evidence maps to the duty it supports.

How DeployOpen prepares compute, documentation and evidence

DeployOpen works on fine-tuning projects by first measuring how much training compute your modification uses against the original model's training compute, then preparing the documentation and evidence that follow if you become a provider. We work inside your own infrastructure, and the compliance determination and the obligations remain yours to own and confirm with counsel.

How we scope

The written scope records the original model, the compute planned for modification, and the measurement method used to compare it.
We document which compute figures come from your training logs and which are estimates, so the provider determination rests on traceable data.
Scope states which documentation, copyright policy and training content summary deliverables are in or out, and who signs off on them.

How we build

We configure the fine-tuning environment to record compute usage, dataset lineage, hyperparameters and evaluation runs as they happen.
Training and evaluation results are captured in a structured technical documentation set mapped to the Annex XI information items.
Where the modified model may be placed on the EU market, we set up access controls and retention on the documentation store inside your environment.

How we hand over

You receive the technical documentation, compute records, dataset inventory and evaluation reports in a versioned repository you control.
A written handover explains which items support the provider determination, which are open for your counsel to review, and what must be kept up to date.
Documentation is delivered with a runbook describing how to produce it for the AI Office or national authorities on request.

How we support

Ongoing support covers updates to documentation when you retrain, change datasets or modify the model again.
Retainers can cover periodic review of compute records and evaluation evidence as your models change.
Upgrades to the logging and documentation tooling are available under a support agreement, with changes agreed in writing first.