Does Fine-Tuning Make You a Provider Under the EU AI Act?

The Act splits the world into providers, who place models on the market, and deployers, who use them. Chapter V, Articles 51 to 56, attaches four duties to providers of general-purpose AI models: technical documentation for the AI Office, documentation for downstream integrators, a copyright policy, and a public summary of training content. Deployers owe none of those. The Guidelines add the case the Act leaves implicit: a downstream actor who modifies an existing general-purpose AI model becomes the provider of a new one on an indicative criterion of compute, the modification's training compute greater than one third of the original's.

Two things make that harder than it reads. First, it is a ratio between two quantities you probably do not measure: your own cumulative training compute, and the base model's, which may not exist in public. Second, the Guidelines define training compute inclusively. It is the cumulative floating point operations across everything intended to enhance the model's capabilities before deployment, covering pre-training, fine-tuning and the forward passes used to generate synthetic training data, including synthetic data you later discarded.

That changes how you meter a project. A sweep that produced eleven abandoned checkpoints still burned compute aimed at improving the model. The conservative position, and the one we build ledgers for, is to sum the lineage that produced the shipped artifact and record discarded runs separately, so either figure is available without recomputing.

The estimate everyone uses is 6ND: roughly six floating point operations per parameter per token, N parameters, D tokens, two forward and four backward. The Guidelines accept architecture-based estimation alongside hardware-based estimation, so precision to two significant figures is not the point. Landing within an order of magnitude of a line you are four orders below, or one order above, is. Three corrections separate a usable number from a wrong one.

N is active parameters, not total. For a dense model they are the same. For a mixture-of-experts model only the routed experts fire per token, so a 235B-total, 22B-active model does 6 x 2.2 x 10^10 operations per token, not 6 x 2.35 x 10^11. Using total parameters overstates your compute by more than 10x, which sounds conservative until you notice it also inflates the denominator, and the errors do not cancel because the architectures differ.

D is tokens seen, not corpus size. Three epochs over a 412 million token corpus is 1.236 billion tokens of D. Packing, padding and gradient accumulation do not change that; only tokens that actually flowed through the model do.

Frozen weights cost less. Under LoRA or QLoRA the base weights receive no weight-gradient computation, removing half the backward cost and a third of the total, so 4ND is the closer estimate. Near the threshold, do not lean on that saving: compute the hardware-based estimate too, GPU-hours times the vendor's peak throughput for your numeric format times your measured model FLOPs utilisation, and file the larger of the two.

# flop_ledger.py: run this before the training job, not after the audit.

BASE = {
    "id": "meta-llama/Llama-3.1-405B",
    "active_params": 405_000_000_000,   # dense, so active equals total
    "published_train_flop": 3.8e25,     # disclosed by the model provider
}

def modification_flop(active_params, tokens_seen, method):
    coeff = 4 if method in ("lora", "qlora", "adapter") else 6   # 4ND if frozen
    return coeff * active_params * tokens_seen

def denominator_flop(base, base_has_systemic_risk=False):
    if base.get("published_train_flop"):
        return base["published_train_flop"] / 3
    return (1e25 if base_has_systemic_risk else 1e23) / 3        # Guidelines fallback

tokens_seen = 500_000_000 * 3                                    # corpus x epochs
flop = modification_flop(BASE["active_params"], tokens_seen, "lora")
print(f"{flop:.3g} FLOP, ratio {flop / denominator_flop(BASE):.6f}")
# 2.43e+21 FLOP, ratio 0.000192

You may already have most of this. Transformers accumulates a 6ND estimate into TrainerState.total_flos with embedding parameters excluded, so it under-reports embeddings and over-reports LoRA by using the dense coefficient. Log it next to your own figure, not instead of it. Trainer choice does not change the arithmetic, only how easy the number is to extract, which we compared in Unsloth vs Axolotl vs LLaMA-Factory vs TRL.

The fallback is simple and its consequences are not. Where the original model's training compute is unknown, the Guidelines direct you to substitute one third of the relevant threshold: 10^23 FLOP for a general-purpose AI model, 10^25 FLOP where the base has systemic risk.

The middle row is the trap. The fallback is a fixed quantity while real training compute scales with parameter count and token budget, so the larger and better trained your undocumented base, the more punitive the substitution. A 70B model trained on 15 trillion tokens consumed roughly 6.3 x 10^24 FLOP under 6ND, and one third of that would be about 2.1 x 10^24, some 60 times the fallback you are forced to use instead. Headroom drops from roughly 5 trillion tokens to roughly 79 billion for no reason connected to the model. That makes base selection a compliance decision: between two open-weights models of similar quality, the one publishing its pre-training FLOP budget gives you one to two orders of magnitude more headroom. Add it to the criteria alongside licence terms, which is where most teams stop, and which we worked through in open source AI models versus custom models.

Distillation sits outside this frame and gets misread constantly. Training your own student on teacher outputs is not a modification of the teacher, so the one-third test does not apply; you are training a new model, and the question is whether your own cumulative compute crosses 10^23 FLOP. The teacher's inference counts toward that total, because the Guidelines include forward passes for synthetic data generation. Generating 10 billion tokens from a 405B teacher costs about 8.1 x 10^21 FLOP at 2ND, against 4.8 x 10^20 FLOP to train an 8B student on them. The generation step is roughly 17 times the training step, and it is the part nobody budgets.

Cross it and four obligations attach.

The scoping is the relief that makes this survivable. The obligations relate to the modification: the compute you spent and the data you used. No auditor asks you for a training-data summary of a base corpus you never saw. Your summary describes your corpus, your policy how you acquired it, your documentation what your training changed.

Note which two survive the open-source exemption. Releasing your fine-tune under a free and open-source licence with parameters, architecture and usage information public removes the two documentation duties and the Article 54 authorised representative requirement. It does not remove the copyright policy or the training-data summary, precisely the two that require knowing, per source, what you trained on and under what terms. Neither can be reconstructed six months after the run.

The copyright policy has a concrete technical limb: identifying and complying with machine-readable reservations of rights under Article 4(3) of Directive (EU) 2019/790, the text and data mining opt-out. Where your corpus includes crawled material, that is a crawler configuration and a stored record, not a paragraph in a PDF.

A general-purpose AI model is presumed to present systemic risk when its cumulative training compute exceeds 10^25 FLOP. If your modification pushes the result over that line, or you become the provider of a model already classified there, the limitation to the modification does not hold. You inherit the full Article 55 set for the whole model: adversarial testing and model evaluation, systemic risk assessment and mitigation, serious incident reporting to the AI Office, and cybersecurity protection for the model and its physical infrastructure. Article 52(1) also requires notifying the Commission within two weeks of knowing the threshold will be met.

The practical shape of the risk is a continued-pretraining programme on a large base. Reaching 10^25 FLOP at 405B active parameters takes about 4.1 trillion tokens under 6ND, a programme rather than an accident. The failure is not crossing the line; it is crossing it without having notified, because nobody tracked cumulative compute across runs.

The base's classification also moves your own threshold. If the base is already presumed systemic-risk, the fallback denominator when its compute is undisclosed is 3.3 x 10^24 FLOP rather than 3.3 x 10^22, a hundred times more headroom.

The most common error in current compliance plans is reading the Digital Omnibus as a general reprieve.

Regulation (EU) 2026/1744 entered into force on 27 July 2026 and moved the Chapter III high-risk obligations. Chapter V was left alone, in the same way Article 50 transparency in Chapter IV was left alone, which we covered in Article 50 content marking in production. The calendar for a downstream modifier is the original one, and it has already started.

Two enforcement details change how you read that. GPAI enforcement is centralised, with the Commission acting through the AI Office rather than national market surveillance authorities, so there is no forum-shopping between member states. And the Article 101 fine ceiling is 3% of total worldwide annual turnover or 15 million euro, whichever is higher, assessed against the group rather than the subsidiary that ran the training job. If your fine-tuned model went live before 2 August 2025 you have until 2 August 2027, the last transition.

This is where on-premise teams get the wrong answer with the most confidence. The reasoning goes: the weights never leave the building, we do not sell the model, nothing is distributed, so nothing was placed on the market. The Guidelines do not support that. A general-purpose AI model is placed on the Union market when first made available in the course of a commercial activity, for payment or free of charge, and the Guidelines explicitly include internal processes essential to providing a product or service to third parties, or that affect the rights of natural persons in the Union. A privately hosted model that scores credit applications, triages patients, prices policies or ranks job candidates falls inside that description with the weights in your own rack. Development genuinely outside commercial activity is out of scope, and very little production AI in a regulated firm qualifies. The AI Act is also not the only EU regime that reaches into a private cluster: a pharmaceutical manufacturer running a model anywhere near batch release answers whether the draft GMP Annex 22 permits an LLM in a critical GMP application as a separate question, against a determinism requirement the AI Act never imposes.

What on-premise deployment does change is the evidence position, in your favour. Own the cluster and you own the scheduler logs, the accelerator-hours, the dataset snapshots and the checkpoint lineage. Every input the one-third test needs is already inside your perimeter, under your retention policy.

Contrast a managed fine-tuning API. You send a JSONL file, you get a model identifier back, and the inputs the calculation needs (tokens actually seen after the vendor's packing and truncation, epochs actually run, active parameters of the base revision) may never be exposed. You are the provider if the threshold is crossed, and the numbers proving it sit on someone else's balance sheet. That asymmetry belongs in the build-versus-buy conversation next to residency, set out in EU AI Act data residency and sovereignty, and next to GDPR and AI for EU customer data.

Owning the ingestion path is the second advantage. The training-data summary and copyright policy both need per-source provenance, and inside your own boundary you enforce it at the loader: no corpus enters the training set without a licence field and, for crawled material, a rights-reservation check.

The problem is cheap if you record four things at training time rather than reconstructing them at audit time: active parameters, tokens seen, estimated FLOPs, and a dataset manifest with a licence per source. Write them into the run artifact, next to the checkpoint.

run_id: ft-2026-08-11-clinical-sft-r64
base_model:
  id: meta-llama/Llama-3.1-70B-Instruct
  active_params: 70_600_000_000        # total for dense, per-token for MoE
  published_train_flop: null           # nothing disclosed, fallback applies
  denominator_flop: 3.33e22            # one third of 1e23
  base_systemic_risk: false
modification:
  method: lora
  lora_r: 64
  target_modules: [q_proj, k_proj, v_proj, o_proj]
  num_train_epochs: 3
  corpus_tokens: 412_000_000
  tokens_seen: 1_236_000_000           # corpus x epochs, the number that counts
  flop_coefficient: 4                  # 4ND, base weights frozen
  estimated_flop: 3.49e20
  trainer_total_flos: 5.05e20          # 6ND, embeddings excluded
  hardware_flop_upper_bound: 1.9e21    # gpu_hours x peak_flops x mfu
  ratio_to_denominator: 0.0105
lineage:
  discarded_sweep_runs: 11
  lineage_flop_total: 3.15e21          # shipped run plus discards
  lineage_ratio_to_denominator: 0.0946
data:
  - source: internal_clinical_notes_2019_2025
    tokens: 310_000_000
    licence: proprietary
  - source: licensed_journal_corpus_2024
    tokens: 102_000_000
    licence: negotiated_publisher_agreement
    tdm_reservation_checked: 2026-08-10
copyright_policy_version: cp-2026.2

The file answers the provider question twice: for the shipped run at 0.0105 of the denominator, and for the full lineage including discarded sweeps at 0.0946. Both are an order of magnitude clear of 1.0. Where the two straddle the line you have a decision to escalate rather than a surprise.

The bottom rows carry the two insights worth keeping. Quantisation, pruning and weight merging consume almost no training compute, so no amount of them makes you a provider under this test. And distillation is measured on the teacher's forward passes, the expensive and invisible part. The data volume most teams need for a useful fine-tune sits four to five orders of magnitude below the threshold, which is why the answer is almost always no: see how much data you need to fine-tune an LLM, and the AI for business pillar for the strategic frame.

This week, add four fields to the run configuration of every fine-tune you launch: active parameters, tokens seen, the FLOP estimate, and the denominator you measured it against. Under an hour of work in whatever trainer you already use, and it turns a question that costs a lawyer and a week of log archaeology into a number you read off the checkpoint directory.