You’re integrating GPT-4, Claude, or Gemini into your product. Maybe you’re using the API as-is, or maybe you’re fine-tuning it to better match what you actually need. Either way, you need to know if that makes you a “deployer” or a “provider” under the EU AI Act.
The difference matters.
This guide is part of our comprehensive EU AI Act implementation guide, where we explore the critical compliance tensions facing CTOs navigating regulatory uncertainty.
Deployers have light obligations – mostly transparency requirements. Providers face the full compliance burden. Model Documentation Forms, Code of Practice adherence, copyright policies, training data summaries, and ongoing documentation maintenance. It’s a lot.
Here’s the line in the sand: if your fine-tuning uses compute resources exceeding one-third of the original model’s training compute, you cross from deployer to provider. Simple in theory. In practice, calculating that threshold requires FLOP data most vendors haven’t published yet.
August 2, 2025 is your deadline. Unlike the Digital Omnibus deferrals for high-risk AI systems, GPAI obligations unaffected by Digital Omnibus remain certain. This article maps fine-tuning activities to provider/deployer classifications and shows you how to make architecture decisions that balance what you need against compliance costs.
What is the difference between a GPAI provider and a GPAI deployer under the EU AI Act?
Providers develop or substantially modify GPAI models. They face the full compliance burden under Articles 53 and 55. Submitting Model Documentation Forms to the European AI Office, adhering to the Code of Practice chapters on transparency, copyright, and safety, maintaining copyright compliance policies, publishing training data summaries, and keeping all documentation current. That’s the job.
Deployers use GPAI models under their own name without substantial modification. Their obligations are lighter. Transparency about GPAI usage in systems, impact assessments only if deployed in high-risk contexts, and monitoring model performance in deployment.
This is binary. No middle ground. You’re either a provider or a deployer.
The default is straightforward – API users without modification are deployers. Cross the substantial modification threshold and you become a provider, with all the obligations that entails.
The compliance cost difference affects resource allocation. Provider obligations average 40-60 hours of initial legal and technical work, plus ongoing maintenance. You’ll need dedicated resources. Legal counsel familiar with AI Act requirements, technical staff to compile documentation, and processes to maintain everything as models evolve. Deployers can manage with lighter documentation processes, typically handled within existing teams.
Misclassifying your role poses compliance risk. Fines reach up to €15 million or 3% of global annual revenue, whichever is higher. For broader context on navigating EU AI Act implementation tensions beyond GPAI obligations, see our comprehensive guide.
When does fine-tuning a foundation model make me a provider instead of a deployer?
The threshold sits at one-third. If you use compute resources exceeding 33% of the original model’s training compute, you’ve substantially modified the model. You’re now a provider.
Training compute gets measured in FLOPs – floating-point operations – across all training phases. That includes pretraining, fine-tuning, and reinforcement learning. If your modification work accumulates past that one-third mark, the classification changes regardless of your upstream provider’s status.
The European Commission set relatively high compute-based thresholds. They expect only a few modifiers to become GPAI model providers. But if you’re doing serious fine-tuning work, you need to calculate where you stand.
Parameter-efficient fine-tuning methods like LoRA or adapters typically stay under the threshold. These approaches freeze most model parameters and train small subsets, using a tiny fraction of the compute needed for full fine-tuning. Full fine-tuning or continued pretraining likely exceeds the threshold. You’ll need actual FLOP calculations to confirm. If you’re fine-tuning for HR use cases, note that you may face dual GPAI and high-risk obligations depending on your employment AI classification.
Here’s what doesn’t trigger provider status: RAG implementation, prompt engineering, and quantisation without retraining. None of these constitute substantial modification because they don’t retrain the model’s parameters.
API-based fine-tuning sits in ambiguous territory. If you’re using a vendor’s managed fine-tuning service – OpenAI’s fine-tuning API, for example – the classification depends on contractual terms and compute allocation. Who controls the compute? Who directs the fine-tuning? Current vendor contracts don’t clearly address this, leaving you to negotiate the allocation.
Your modification creates new provider obligations independent of the original model’s grandfathering status. If OpenAI placed GPT-4 on the market before August 2025, they get grandfathering until August 2027. Your fine-tuned version? No grandfathering. You face immediate August 2025 obligations if you cross the threshold.
Where original compute metrics are unavailable, alternative criteria apply. If the original model presents systemic risk, the threshold becomes one-third of 10²⁵ FLOPs. Otherwise it’s one-third of 10²³ FLOPs.
How do I calculate if my fine-tuning crosses the one-third compute threshold?
You need two numbers: the original model’s FLOP count and your fine-tuning FLOPs. The first should come from the upstream provider’s Model Documentation Form or technical specification. Upstream GPAI providers must disclose training compute by August 2025.
Should. The reality is that many providers haven’t published detailed compute data yet.
For your fine-tuning FLOPs, use this formula: (number of parameters trained) × (training tokens) × 2. The “2” accounts for forward and backward passes during training.
Let’s work through an example. Say you’re doing LoRA fine-tuning with 10 million adapter parameters across 100 billion tokens. That’s 10,000,000 × 100,000,000,000 × 2 = 2×10¹⁸ FLOPs.
GPT-4 training compute is estimated around 2×10²⁵ FLOPs. One-third of that is roughly 6.67×10²⁴ FLOPs. Your LoRA fine-tuning at 2×10¹⁸ FLOPs sits well below the threshold. You remain a deployer.
Now consider full fine-tuning: 175 billion parameters across 50 billion tokens. That’s 175,000,000,000 × 50,000,000,000 × 2 = 1.75×10²² FLOPs. Still under the GPT-4 threshold, but you’re using a meaningful fraction of the original compute. Multi-stage fine-tuning could push you over.
If your vendor doesn’t provide FLOPs, your contract should require disclosure or include conservative provider obligation allocation.
Multi-stage fine-tuning accumulates. If you fine-tune, then later perform reinforcement learning from human feedback, both stages count toward the threshold. Track cumulative FLOPs across your model’s lifecycle.
For distillation and quantisation, you must count the original model’s FLOPs, not just the distillation or quantisation compute. Smaller variants of larger models still count as GPAI if the larger variants met the relevant test.
What are the GPAI provider obligations under Articles 53 and 55?
Article 53 covers all GPAI providers. You need to document technical information for the AI Office and national authorities, make it available to downstream providers, publish training data summaries, maintain copyright compliance policies, and provide downstream user documentation.
The Model Documentation Form is your primary compliance artifact. It’s a standardised template within the Code of Practice Transparency chapter. You submit it to the European AI Office and keep it current as your model evolves.
Your copyright compliance policy needs documented procedures ensuring model development respects EU copyright law. That covers training data acquisition, fair use assessment, and rights clearance. Given ongoing litigation around training data copyright, this documentation matters.
The training data summary is public. You need sufficient detail for copyright holders and researchers to understand your corpus without compromising IP.
Downstream provider documentation gives your customers what they need to comply with their AI Act obligations. Capabilities, limitations, intended uses, known risks – the information that lets them assess whether their deployment context triggers additional requirements.
Article 55 applies only to systemic risk models – those trained with ≥10²⁵ FLOPs. That’s 100× the base GPAI threshold. If your fine-tuning crosses this higher bar, you face adversarial testing requirements, systemic risk mitigation measures, serious incident reporting to the AI Office, and cybersecurity safeguards.
The Code of Practice provides a voluntary but practically necessary safe harbour. More than 25 providers have signed up, including Amazon, Anthropic, Google, IBM, Microsoft, Mistral AI, and OpenAI. Adherence creates a presumption of compliance and smoother supervisory interactions.
Your ongoing obligations include maintaining documentation currency, updating as the model evolves, and responding to European AI Office information requests. Documentation drawn up for each model version must remain available for 10 years.
What is the Code of Practice and how does it protect me from compliance risk?
The Code of Practice is a voluntary compliance framework developed by the European AI Office with industry input, endorsed 1 August 2025.
It contains three chapters: Transparency (Article 53 obligations), Copyright (training data compliance), and Safety/Security (systemic risk models). The Transparency chapter includes the Model Documentation Form template.
This creates a safe harbour mechanism. Adherence demonstrates good faith compliance effort and reduces litigation risk. Signatories may benefit from greater trust and potentially lower fines. Non-signatories must independently demonstrate compliance through detailed explanations – expect more scrutiny.
The Code isn’t a harmonised standard, so signing doesn’t create automatic presumption of compliance. If you opt out of any chapter, you can’t rely on the Code to show compliance in that area.
How do RAG implementations differ from fine-tuning for EU AI Act classification?
RAG – Retrieval-Augmented Generation – augments model responses with external knowledge retrieval without modifying parameters or retraining. You’re changing inputs and outputs, not model weights.
RAG does not constitute substantial modification. Users remain deployers, not providers.
Fine-tuning changes model parameters through additional training, potentially crossing the one-third compute threshold. RAG achieves domain customisation – legal knowledge, medical references, financial data – without triggering provider obligations.
Hybrid approaches can balance customisation depth with compliance burden. RAG for knowledge augmentation plus parameter-efficient fine-tuning for behaviour modification, staying under the threshold.
If preserving deployer status is a priority, architect for RAG-first with optional PEFT under threshold.
What happens if my vendor doesn’t provide the FLOP data I need to calculate the threshold?
Upstream GPAI providers must disclose training compute by August 2, 2025. The reality is many haven’t published detailed compute data yet.
Your contract negotiation needs to address this gap. Require upstream providers to disclose FLOPs or contractually assume provider obligations for your downstream modifications. For comprehensive guidance on vendor contract terms for provider/deployer allocation, including specific clauses and verification checklists, see our vendor due diligence guide.
A safe harbour clause might read: “If Provider fails to disclose training compute within 30 days of request, Provider assumes all EU AI Act provider obligations for Customer’s model modifications.”
Major providers may resist FLOP disclosure for competitive reasons. If the vendor won’t disclose FLOPs, request written confirmation that your modifications won’t exceed the substantial modification threshold. That shifts classification responsibility to them.
Your contract should allocate liability to the vendor if they provide inaccurate FLOP data. The conservative approach: assume fine-tuning triggers provider obligations until vendor data confirms deployer status.
Do I need to comply with GPAI obligations if I’m a US company?
“Placing on market” means making the model available to EU users, regardless of your location or server location. If you’re offering a GPAI API to EU customers, licensing a model to EU entities, or EU users are accessing model outputs, the Act applies.
EU member state market surveillance authorities can enforce against non-EU providers. They can issue fines and restrict market access. The EU has precedent with GDPR extraterritorial enforcement.
Geographic workarounds are ineffective. Blocking EU IP addresses is insufficient if model outputs reach EU users through downstream systems.
Build one compliance framework that works everywhere rather than maintaining separate processes for different markets.
FAQ
Can I avoid provider obligations by keeping fine-tuning compute just under the one-third threshold?
Technically yes. Staying below the threshold preserves deployer status with lighter obligations. But this requires accurate FLOP calculation, tracking cumulative compute across modification stages, and vendor FLOP disclosure.
The risk: if your compute estimation is wrong and you’ve crossed the threshold, retroactive provider obligations apply. Design for a threshold margin – target 25% of original compute maximum to provide buffer.
Parameter-efficient techniques like LoRA, adapters, and prefix-tuning are designed to minimise compute. They typically use 0.1-1% of full fine-tuning FLOPs.
Monitor cumulative modifications. Each additional fine-tuning round adds to total FLOPs. Track across your model lifecycle to avoid threshold creep.
Will the Code of Practice protect me from fines if I make good faith compliance errors?
Partial protection. Code adherence demonstrates good faith effort, may reduce supervisory scrutiny, and could reduce fine severity. It’s not complete immunity.
Actual non-compliance – failing copyright obligations despite Code adherence, for example – can still result in fines. Supervisory discretion means enforcement authorities consider Code adherence when determining proportionate enforcement response.
What’s the actual compliance cost for GPAI provider obligations?
Initial implementation requires 40-60 hours of legal and technical work. That covers Model Documentation Form completion, copyright policy development, and training data summary preparation.
Ongoing maintenance runs 5-10 hours monthly for documentation updates, European AI Office information requests, and Code of Practice update tracking.
Legal review costs vary by firm and complexity, typically €15,000-€30,000 for specialised AI Act counsel to review your compliance framework.
Provider obligations are 5-10× more resource-intensive than deployer documentation requirements.
If my upstream provider is grandfathered until 2027, do my modifications inherit that grandfathering?
No. Grandfathering applies to original model placement on market, not to substantial modifications.
Downstream modifiers creating new models after August 2, 2025 have immediate provider obligations regardless of upstream grandfathering.
The timeline conflict: OpenAI places GPT-4 on market before August 2025, gets grandfathering until August 2027. You fine-tune GPT-4 after August 2, 2025, crossing the substantial modification threshold. You face immediate August 2, 2025 obligations.
How do I determine if API fine-tuning on OpenAI’s platform makes me a provider?
Ambiguous territory. Guidelines don’t clearly address managed fine-tuning services where the vendor controls infrastructure.
The compute control test helps: who allocates compute resources for fine-tuning? Customer-controlled compute suggests provider status. But with API services, the vendor manages infrastructure while you direct the fine-tuning work.
OpenAI API terms should specify whether customer or OpenAI is classified as provider for fine-tuned models. Most GPAI API providers haven’t published clear provider/deployer allocation for API fine-tuning scenarios yet.
Risk mitigation through contracts: require the vendor to assume provider obligations or disclose FLOPs enabling you to assess classification. If the contract is unclear and FLOPs are unavailable, the conservative approach assumes API fine-tuning triggers provider status.
Expected clarification from the European AI Office should come by mid-2025.
Can I contest systemic risk classification if my fine-tuned model crosses 10²⁵ FLOPs?
Models trained with ≥10²⁵ FLOPs are presumptively classified as systemic risk under Article 51(1).
A rebuttal procedure exists. You can present arguments to the European AI Office that your model doesn’t have high-impact capabilities justifying classification.
The burden of proof falls on you – you must demonstrate model capabilities don’t pose systemic risks despite the FLOP threshold. Factors the Office considers include model architecture limiting generality, domain specificity restricting use cases, and technical constraints preventing harmful applications.
The Commission may accept or reject rebuttals with reasons. Obligations remain in effect during review. Initial reassessment may be requested six months post-designation.
The alternative: architect fine-tuning to stay below 10²⁵ FLOPs, avoiding systemic risk classification entirely. Article 55 obligations – adversarial testing, incident reporting, cybersecurity – increase compliance burden significantly.
What documentation do I need to provide to the European AI Office as a provider?
Model Documentation Form covering technical specifications, training data description, capabilities, limitations, intended uses, and known risks.
Copyright compliance documentation with policies and procedures for respecting copyright in training data acquisition and use.
Training data summary as public disclosure describing corpus content with sufficient detail for transparency without IP compromise.
Downstream provider documentation – an information packet enabling your customers to comply with their AI Act obligations.
Submission format is email to the AI Office Service Desk with completed Model Documentation Form and supporting documents. Timing: initial submission by August 2, 2025. Updates when material model changes occur or annually, whichever is sooner.
Retention requirements: maintain documentation for 10 years after the model is withdrawn from market or until the end of supervisory proceedings.
How do model distillation and quantisation affect provider/deployer classification?
Distillation creates smaller models mimicking larger GPAI behaviour. The distilled model must count the original model’s FLOPs, preserving GPAI classification.
Quantisation reduces precision – 32-bit to 8-bit, for example – without significantly affecting model performance. This is efficiency optimisation without retraining. It does not constitute substantial modification.
Provider status: quantising a GPAI model without additional training preserves deployer status. Distillation creating a new model may trigger provider status depending on compute.
FLOP counting for distillation includes the original teacher model’s training FLOPs plus distillation process FLOPs. You can’t avoid provider obligations through distillation if the underlying model is GPAI and the distillation process crosses thresholds.
Post-training quantisation without weight retraining is a modification exempt from the substantial modification threshold.
Do prompt engineering and few-shot learning trigger substantial modification?
No. Prompt engineering crafts input prompts without modifying model parameters. No training compute is used. This is clearly deployer activity.
Few-shot learning provides examples in the prompt – an inference-time technique without training. No substantial modification occurs.
In-context learning processes examples during inference without weight updates, preserving deployer status.
Techniques that don’t update model weights or perform training cannot constitute substantial modification.
Sophisticated customisation is achievable through prompting strategies without crossing the provider threshold. Exhaust prompt engineering and few-shot learning capabilities before considering fine-tuning.
What happens if I discover mid-development that I’ve crossed the provider threshold?
Retroactive obligations apply. Provider status starts when substantial modification occurred, not when you discovered it.
The remediation pathway: immediately begin Article 53 compliance implementation – Model Documentation Form, copyright policy, training data summary. Proactively contact the European AI Office Service Desk explaining the situation and demonstrating good faith remediation effort.
If discovery occurs close to the August 2, 2025 deadline, prioritise Model Documentation Form completion and submission.
Voluntary disclosure and prompt remediation may reduce fine severity under proportionality principles.
Architectural reassessment becomes necessary: continue with provider-level fine-tuning or pivot to RAG/PEFT deployer approaches? The compliance cost difference might justify redesign.
How should I structure vendor contracts to allocate AI Act obligations with GPAI API providers?
For detailed contract templates and verification procedures, see our guide on third-party GPAI service agreements. Key provisions include:
FLOP disclosure clause requiring the vendor to disclose original model training compute, enabling your threshold calculations.
Obligation allocation specifying whether vendor or customer assumes provider obligations for API-based fine-tuning.
Documentation provision requiring the vendor to provide Model Documentation Form and copyright compliance documentation supporting your downstream use.
Indemnification: vendor indemnifies you for misclassification resulting from inaccurate FLOP data or documentation.
Grandfathering clarification stating whether your modifications inherit the vendor’s grandfathering status. The answer is typically no, but explicit contract language prevents disputes.
Update obligations: vendor commits to providing updated documentation when the model materially changes or annually.
Alternative provider assumption: if the vendor can’t or won’t provide FLOP data, the vendor assumes provider obligations for your modifications.
Next Steps
The August 2, 2025 deadline for GPAI provider obligations is certain – unlike the timeline uncertainty surrounding high-risk AI system requirements. Calculate your compute thresholds, review vendor contracts for FLOP disclosure and obligation allocation, and determine whether your fine-tuning approach preserves deployer status or triggers provider obligations.
For a complete overview of all aspects of AI Act implementation, including timeline scenarios, cost planning, and enforcement priorities, see our comprehensive guide.
