EU AI Act's one-third test can make fine-tuners model providers

Under the EU AI Act, fine-tuning an open-weight model makes you a general-purpose AI model provider only when your modification uses more than a third of the original model's training compute. A LoRA or ordinary supervised fine-tune comes nowhere near that. The case that does cross it is continued pretraining on hundreds of billions of tokens, and it crosses fastest on a base model whose maker never published how much compute it used, because then the Commission's lower fallback threshold applies to you.

So the base model you pick decides how much room you have. Pick one whose training compute is published or can be estimated from published figures, keep your own GPU log from the first run, and run a before-and-after eval, because the compute test is indicative and a small fine-tune can still change what the model does.

All figures below were checked on each source's live page on October 24, 2026. Compute estimates use the architecture formula in the Commission's guidelines (C ≈ 6 × parameters × training tokens) unless marked otherwise.

Base model (maker)	Maker signed the GPAI Code?	What the maker publishes	Original training compute	Your one-third threshold	Tokens of further training to cross it	Verdict
Llama 3.1 8B (Meta)	No	1.46M H100-hours, ~15T tokens	~7.2 × 10²³ FLOP	~2.4 × 10²³ FLOP	~5T	Safe to estimate; custom licence
gpt-oss-120b (OpenAI)	Yes	2.1M H100-hours, "trillions" of tokens	~3.7 × 10²⁴ FLOP (hardware method)	~1.2 × 10²⁴ FLOP	~1.8T (counting all 116.8B params)	Best documented for heavy modification
Qwen3 8B (Alibaba)	Not among named signatories	36T tokens, parameter counts	~1.7 × 10²⁴ FLOP	~5.8 × 10²³ FLOP	~12T	Most headroom; estimate is yours to defend
Gemma 3 27B (Google)	Yes	14T tokens, TPU types, no hours	~2.3 × 10²⁴ FLOP	~7.6 × 10²³ FLOP	~4.7T	Estimable; custom terms
Mistral Small 3.1 24B (Mistral AI)	Yes	Parameter count only	Not published	3.3 × 10²² FLOP (fallback)	~230B	Loser for continued pretraining

---

What the One-Third Compute Test Actually Says

A downstream modifier is any company, distinct from the original provider and not acting for it, that changes a general-purpose AI model, and the Commission counts fine-tuning as one way of modifying one (guidelines, paragraph 60 and footnote 11). The guidelines, adopted on July 18, 2025 as C(2025) 5045, set the test in two steps.

The legal test is paragraph 62: a modifier becomes the provider of the modified model "only if the modification leads to a significant change in the model's generality, capabilities, or systemic risk." Paragraph 63 then gives the number most people quote: "an indicative criterion for when a downstream modifier is considered to be the provider of a general-purpose AI model is that the training compute used for the modification is greater than a third of the training compute of the original model."

Read two words in that sentence closely. "Indicative" means the compute figure is a presumption the Commission will use, and paragraph 9 says the guidelines are non-binding and "a case-by-case assessment will always be necessary." "Original model" means the threshold moves with the base you choose. The Commission explains why in paragraph 66: the compute needed for a modification scales with the model's parameter count, so a relative threshold treats a 1B model and a 400B model alike.

For a dense transformer the parameter count cancels out. If the original was trained on D tokens and you keep training the same model, you cross one-third when your own training tokens pass D/3. That is the quickest sanity check you can run: Llama 3.1 was pretrained on roughly 15 trillion tokens, so your fine-tuning data would need to pass about 5 trillion tokens before the indicative criterion bites.

The Commission itself expects this to be rare. Paragraph 67 says "currently few modifications may meet the criterion," and calls it "primarily forward-looking." Paul, Weiss describes the test as a high bar and notes that a modifier's obligations reach only the scope of the modification.

---

The Fallback When the Original Compute Is Unknown

If the base model's training compute is not published and you cannot estimate it, you lose the relative threshold and get a fixed, much lower one. Paragraph 64 of the guidelines reads:

"However, if the downstream modifier cannot be expected to know this value (for example because it has not been communicated by the provider of the original model) and cannot estimate it (see the Annexes A.1 and A.2 to these guidelines for how to estimate training compute) then the threshold should be replaced as follows. If the original model is a general-purpose AI model with systemic risk, the threshold should be replaced with a third of the threshold for a model being presumed to have high-impact capabilities (i.e. currently 10^25 FLOP, see Article 51(2) AI Act). Otherwise, it should be replaced with a third of the threshold for a model being presumed to be a general-purpose AI model (i.e. currently 10^23 FLOP, see Section 2.1)."

In numbers, the fallback is about 3.3 × 10²² FLOP for an ordinary base model and about 3.3 × 10²⁴ FLOP for a base with systemic risk.

The ordinary fallback is the one that bites. Mistral Small 3.1 is a 24B dense model, and its model card discloses the parameter count and the Apache 2.0 licence but neither the training tokens nor the compute. Mistral's launch post for Mistral Small 3 describes "a latency-optimized 24B-parameter model" and gives neither figure. At 6 × 24B FLOP per token, 3.3 × 10²² FLOP buys about 230 billion tokens of further training. A serious domain continued-pretraining run on a legal or clinical corpus can reach that. The same run on Qwen3 8B, whose technical report states pretraining on 36 trillion tokens, uses about 2% of the threshold.

Note the condition in paragraph 64: the fallback applies only when you cannot know the value and cannot estimate it. Qwen3 and Gemma 3 publish tokens and parameter counts, which is enough for the Annex A.2 architecture method, so you cannot claim the fallback for them and you do not need it. Mistral Small 3.1 is the one in this comparison where the fallback is the honest answer unless Mistral gives you the figure.

That gap is also why the Mistral result is a little surprising. Mistral signed the GPAI Code of Practice (Euronews, August 1, 2025) and files EU-template training summaries for newer models, including Ministral 3 8B, but the template only asks for a size band ("More than 10 trillions tokens") and not compute. A summary in the EU format does not give you the number this test needs.

---

What Each Fine-Tuning Technique Costs Against the Threshold

The workload for every row below is an 8B dense base model, Llama 3.1 8B, at 6 × 8B = 4.8 × 10¹⁰ FLOP per training token. That counts the full forward and backward pass even for LoRA, which is the conservative choice: the LoRA paper trains a small fraction of the weights, but the backward pass still runs through the whole network. Paragraph 125 says operations count equally "independently of floating-point precision," so training in FP8 or bf16 does not change the count.

Technique and data	Tokens processed	Compute	Share of the real threshold (2.4 × 10²³)	Share of the fallback (3.3 × 10²²)
LoRA, 5,000 examples × 1,000 tokens × 3 epochs	15M	7.2 × 10¹⁷ FLOP	0.0003%	0.002%
Full supervised fine-tune, 2B tokens	2B	9.6 × 10¹⁹ FLOP	0.04%	0.3%
Continued pretraining on a 200B-token domain corpus	200B	9.6 × 10²¹ FLOP	4%	29%
Continued pretraining, 1T tokens	1T	4.8 × 10²² FLOP	20%	144%

LoRA and ordinary supervised fine-tuning do not register. Continued pretraining at the trillion-token scale crosses the fallback while staying at a fifth of the real threshold, which is the whole case for documenting the original compute before you start.

Distillation needs two answers, depending on what you distil into. If you train a fresh student model from random weights, you are building a new model, the 10²³ FLOP indicative criterion for a general-purpose model (paragraph 17) applies to the student's whole run, and paragraph 122 lets you exclude the compute used to train the teacher. If you distil into an existing open model by fine-tuning it on a larger model's outputs, that is a modification. Paragraph 120 adds that for private synthetic data the forward passes used to generate it, "including discarded data," count toward cumulative training compute, so log the generation runs as well as the training runs. The guidelines do not spell out how paragraph 120 interacts with the modification test, and that ambiguity is a reason to over-record.

Mixture-of-experts bases are the other grey area. The 6PD formula in paragraph 132 is written for dense models. gpt-oss-120b has 116.8B total and 5.1B active parameters. Counting total parameters is the conservative reading and puts the crossing at about 1.8T tokens; counting active parameters would put it far higher. Use the total.

---

How the Five Base Models Compare

Llama 3.1 8B (Meta)

Meta publishes both inputs the test needs: 1.46M H100-hours for the 8B model and about 15T training tokens. The two Annex A methods disagree, though. The architecture formula gives about 7.2 × 10²³ FLOP; the hardware formula with the Commission's own assumptions (989 TFLOP/s per H100 and 50% utilisation, paragraphs 138 and 144) gives about 2.6 × 10²⁴. The higher figure would more than triple your headroom, which is exactly why you should not use it without evidence: paragraph 123 allows any method that is "accurate within an overall error margin of 30%," and you must document your assumptions. Use the lower estimate. Meta declined to sign the Code of Practice (TechCrunch, July 18, 2025), and the Llama 3.1 Community License is a custom licence, so do not assume your modified model qualifies for the open-source exemptions in paragraphs 76 to 78 without counsel testing the licence against them. Do not pick Llama 3.1 405B for heavy modification at all: Meta's Llama 3 paper states 3.8 × 10²⁵ FLOP of pretraining, above the 10²⁵ presumption, and a modifier who becomes its provider inherits systemic-risk duties (more on that below). Meta's models are also covered on our Llama tool page.

gpt-oss-120b (OpenAI)

OpenAI's model card says the training run "required 2.1 million H100-hours," the weights are Apache 2.0, and OpenAI signed the Code. It is the best-documented base here for a team planning large continued pretraining, because the compute figure comes from the maker. The weakness is the token count, given only as "trillions of tokens," and the MoE question above. Do not pick it if you need a multimodal base: it is text-only.

Qwen3 8B (Alibaba)

Apache 2.0 and 36T pretraining tokens give it the most headroom of any base here, about 12T tokens. Alibaba does not publish the pretraining compute, so the estimate is your own work and you defend it. Alibaba was not among the Code signatories named in reporting on the first list; check the Commission's live list before you rely on that. Teams with a Chinese-origin model policy should not pick it regardless of the compute math; our Kimi and Qwen alternatives guide covers that decision.

Gemma 3 27B (Google)

The model card gives tokens per size ("The 27B model was trained with 14 trillion tokens") and the TPU generations, but no hours. That is enough for the architecture estimate. Google signed the Code. Gemma 3 ships under Google's own Gemma terms, and teams that need a plain Apache licence can look at the newer Gemma 4, which moved to Apache 2.0, and redo this arithmetic on its card.

Mistral Small 3.1 24B (Mistral AI)

It loses this comparison on one fact: nothing public lets you compute or estimate its training compute, so you sit on the 3.3 × 10²² fallback. For LoRA and supervised fine-tuning that costs nothing, and Mistral is a fine choice. The fallback is crossed at about 230B tokens, so do not pick it for continued pretraining past about 100B tokens, which leaves margin for estimation error, unless Mistral states the original training compute in writing, in the contract.

---

The Obligations You Take On If You Cross

Crossing makes you the provider of a general-purpose AI model, with duties limited to what you changed. Paragraph 68 of the guidelines says the documentation under Article 53(1)(a) and (b) "is limited to information on the modification, while the copyright policy required by Article 53(1), point (c), AI Act and the summary of the content used for training required by Article 53(1), point (d), AI Act are limited to the data used as part of the modification." Paragraph 69 adds Article 54: a modifier outside the EU needs an authorised representative in the Union.

In practice that means four artefacts: technical documentation of your modification, downstream-provider documentation, a copyright policy covering your fine-tuning data (including respect for text-and-data-mining opt-outs), and a public training-content summary on the Commission template for the data you added. Mistral's own Ministral 3 8B summary shows the shape: it lists Mistral Small 3.1 as a "model dependency." Filing practice across providers is uneven; one tracker counted 11 models from seven providers on the template when it last refreshed.

The systemic-risk case is heavier. Under paragraphs 70 and 71, if you modify a model already classified as having systemic risk and you become its provider, "the resulting model is presumed to have high-impact capabilities as well," and you "must notify the Commission in line with Article 52(1)." That brings Article 55: model evaluations, systemic-risk assessment and mitigation, serious-incident reporting and cybersecurity.

The penalties are live. Paragraph 106 sets fines of up to 3% of global annual turnover or EUR 15 million, whichever is higher, "starting on 2 August 2026." Models placed on the market before August 2, 2025 have until August 2, 2027 (paragraph 109), which covers Llama 3.1, Qwen3, Gemma 3 and Mistral Small 3.1. A model you modify and release today is a new placement and gets no such grace.

Two scoping points catch teams out. Internal use can count: paragraph 53 lists a model "used for internal processes that are essential for providing a product or service to third parties or that affect the rights of natural persons in the Union" as placed on the market. And fine-tuning through a vendor's API may leave the original provider as the modifier; footnote 12 names "who has the control over the model's weights" as an important factor.

---

What a Low FLOP Count Does Not Settle

Staying under one-third does not end the analysis, for two reasons.

The first is in the guidelines. The legal test is a significant change in generality, capabilities or systemic risk, and the compute figure only indicates it. DLA Piper's review points out that fine-tuning on open weights has "rapidly had a material impact on model capabilities" even "when the tuning data set is not particularly large," and that a significant change could happen "well before" the threshold. The research agrees: Qi et al. removed GPT-3.5 Turbo's safety behaviour by fine-tuning on 10 adversarial examples for under $0.20, and found that benign datasets also degraded alignment. OpenAI's gpt-oss card concedes the same risk, which is why it ran adversarial fine-tuning against its own model before release. A fine-tune that strips refusals or adds an offensive capability is the scenario where a tiny compute count will not protect you.

The second is a different article. Even if you never become a GPAI provider, Article 25(1) makes you the provider of a high-risk AI system if you "make a substantial modification" to a high-risk system or "modify the intended purpose" of a system, "including a general-purpose AI system," so that it becomes high-risk. A LoRA that turns a general chat model into a credit-scoring or hiring screener can trigger that with almost no compute at all. For most enterprise fine-tunes, Article 25 is the obligation that actually applies.

---

Evidence to Collect Before You Start

From the original provider, in writing:

1. The training compute of the exact checkpoint you will modify, in FLOP, with the estimation method. If it is only on a model card, archive the card with a date, because cards change.
2. The model's date of placement on the EU market, and whether the provider treats it as a model with systemic risk or has notified the Commission.
3. The provider's public training-content summary and copyright policy, which your own documentation will reference as the dependency.
4. The licence version, and counsel's view of whether it meets the open-source conditions in paragraphs 76 to 78.

From your own runs, kept from day one:

1. GPU type and count, wall-clock hours per phase, and measured utilisation, so you can apply the hardware formula C = N × L × H × U from paragraph 127.
2. Tokens processed per epoch and epoch count, so you can apply the architecture formula as a cross-check.
3. Logs of synthetic-data generation runs, including discarded samples.
4. Before-and-after evaluations on capability and safety benchmarks relevant to your use, which are your evidence that no significant change happened, or your early warning that one did.

---

What to Do About It

This Week:

1. Write down, for each fine-tuning project aimed at an EU product, the base checkpoint, the technique and the planned token count, then run the D/3 check from this article. Anything under 1% of the threshold is a documentation task.
2. Ask your legal lead whether any of those projects changes a model's intended purpose into an Annex III use. That is the Article 25 question, and it matters more for LoRA projects than the compute test does.

This Month:

1. Turn on per-job GPU-hour and token logging in your training stack, and keep it for the life of the model.
2. For any base without published compute, Mistral Small 3.1 among them, ask the provider for the figure in writing before you plan a continued-pretraining run.

Before You Ship in the EU:

1. Run the safety and capability eval before and after the fine-tune and file the results with the compute log.
2. If a project will cross one-third, budget for the four Article 53 artefacts and, for a non-EU entity, the Article 54 representative, before training begins.

---

The Bottom Line

The one-third test turns a vague legal question into arithmetic, and for almost every enterprise fine-tune the arithmetic says you are not a GPAI provider. The risk sits in two places: heavy continued pretraining on a base whose compute nobody published, and small fine-tunes that change behaviour or purpose. Choose a base model with a documented compute figure, keep your own GPU log, and treat the eval as part of the compliance file.

Get the original compute figure in writing before the first training job starts.

Continue Reading

• Training Data Provenance: Indemnity Stops at Your Fine-Tuning Data
• Fine-Tuning vs RAG Cost: The Training Bill Isn't the Bill
• Prompt Optimization vs Fine-Tuning: Run GEPA Before You Train
• EU AI Act Governance Tools: Buy Inventory, Not Policy Packs
• Meta's Muse Spark Open License Bans Running Critical Infrastructure
• UK ICO Asks AI Agent Deployers for Evidence by November 20