← auditaisdk.com  ·  All articles

EU AI Act GPAI Obligations for Downstream Providers: What You Owe When You Build on GPT-4 or Claude (2026)

By Marc Dubois · May 2026 · 13 min read

TL;DR: If your product wraps OpenAI, Anthropic, Google or Mistral models, you are a downstream provider under the EU AI Act. Article 53 obligations sit on the upstream GPAI provider — not on you — but two things still hit your file: (1) you must obtain and pass through the upstream Article 53(1)(d) documentation, and (2) heavy fine-tuning or rebranding can flip you into the GPAI provider role under Article 25(1)(c). The flip threshold sits roughly at one third of the original training compute or a substantial change to intended purpose; LoRA, prompt engineering and standard fine-tuning stay safely below. This guide walks the regime end to end with a flowdown checklist enterprise procurement signs, the open-source carve-out, the systemic-risk regime under Article 55, and the documentation pack the €199 managed audit ships for downstream providers.

Why GPAI is the question procurement asks third

The first two questions an enterprise compliance officer asks an AI vendor are well-documented elsewhere on this site. "Are you high-risk under Annex III?" — answered in the classification decision tree and the Article 6(3) exemption deep dive. "What do we have to do as deployer?" — answered in the Article 26 deployer checklist.

The third question lands a beat later and surprises most vendors: "You said GPT-4 is in the loop. What does that mean for our liability?"

That is the GPAI question. It is short to ask and long to answer because it pulls in three separate regimes — the Article 53 base regime, the Article 55 systemic-risk regime, and the Article 25(1)(c) substantial-modification flip — plus an open-source carve-out, plus the GPAI Code of Practice that the major upstream providers signed in 2025. Procurement teams ask the question because their own legal department flagged "third-party model dependency" as a residual risk in the AI risk register. They are not after a treatise; they are after one paragraph confirming who owes what.

A correctly built downstream-provider file delivers that paragraph in three lines: which upstream model you use, what version of the Article 53(1)(d) documentation you hold for it, and how your fine-tuning posture keeps you below the Article 25(1)(c) substantial-modification threshold. Everything else in this guide unpacks those three lines.

Who is a GPAI provider, and who is a downstream provider

The Act splits the GPAI ecosystem into two roles. The naming sounds bureaucratic; the boundary is sharp once you see the test.

GPAI provider (Art. 3(63) + Art. 3(3))

Develops a general-purpose AI model and places it on the EU market under its own name. The model exhibits significant generality and is capable of competently performing a wide range of distinct tasks.

Owes: Article 53 (documentation, copyright policy, training summary, downstream flowdown). If systemic risk: Article 55 (evaluations, adversarial testing, incident reporting, cybersecurity).

Downstream provider (Art. 3(68))

A provider of an AI system that integrates a GPAI model, regardless of whether the GPAI model comes from the same entity or a third party. The wrapper around the model.

Owes: Nothing under Article 53 directly. But: must hold the Article 53(1)(d) flowdown package, and must not cross the Article 25(1)(c) substantial-modification line.

Four typical B2B SaaS shapes against this split:

  1. API wrapper. Your product calls the OpenAI Chat Completions API and adds RAG, a UI and a workflow on top. OpenAI is GPAI provider. You are downstream provider. Article 53 is OpenAI's file, not yours — you hold a copy of their model card and system card for your customer's audit folder.
  2. Fine-tuned API. You fine-tune gpt-4o-mini via the OpenAI fine-tuning API on a few thousand examples and serve the result through your own product. The fine-tune is light, parameter-efficient, and OpenAI hosts the weights. You stay downstream — OpenAI remains GPAI provider, you remain downstream provider, the file split is unchanged.
  3. Self-hosted open-weights model. You self-host Llama 3.1 405B on your own GPUs and serve it inside your product. Meta is GPAI provider (with the Article 53(2) open-source carve-out applying to most documentation duties — see below). You are downstream provider. If you fine-tune Llama lightly, you stay downstream; if you do continued pre-training on a 50B-token corpus, you may flip.
  4. Continued pre-training in-house. You take a base model and run another large training run on top — millions of dollars of compute, a meaningfully different corpus, a different release name and version. Article 25(1)(c) flips you into the GPAI provider role for the derived model. From that point, Article 53 is your file, plus Article 55 if the derived model crosses the systemic-risk threshold.
The flip threshold most CTOs miss. The Commission's 2026 draft guidance on Article 3(63) and Article 25(1)(c) reads continued pre-training that exceeds one third of the original model's training compute as a presumptive substantial modification. Below that threshold, the safer reading is that you remain downstream. Document your compute budget per fine-tune so the customer's legal team can verify the ratio. A LoRA at 0.1% of original training compute is unambiguously below the line. A full mid-training run at 25% is borderline. At 35%+ you should plan to operate as GPAI provider.

Article 53 — what the upstream provider owes (and therefore what you can demand)

Article 53(1) imposes four base duties on every GPAI provider, regardless of systemic-risk status. Each one creates a downstream entitlement: a thing you can ask for and expect to receive.

DUTY 1 · ART. 53(1)(a)

Maintain technical documentation including the elements of Annex XI

Annex XI lists the elements every GPAI technical file must contain: a general description of the model (intended tasks, model architecture and parameter count, modalities, licence), training process (compute, data, training time, energy, methodology), known evaluations and benchmarking results, intended downstream use cases, model limitations, and a description of testing including adversarial testing where applicable.

What this means for you as downstream. Ask the upstream provider for their Annex XI file or the model-card equivalent. Most major providers ship a public model card plus an under-NDA technical appendix. The under-NDA piece is what enterprise customers want to see referenced in your compliance bundle (not the content — the existence and the access route).

DUTY 2 · ART. 53(1)(b)

Make information available to downstream providers via Annex XII documentation

Annex XII is the downstream-facing version of Annex XI. It is shorter and explicitly written for the entity integrating the model. Required elements include: tasks the model is intended to perform, acceptable use policy and prohibited uses, integration parameters, computational requirements, and a description of the technical means for integration.

What this means for you as downstream. This is the document your enterprise customers will reference by name. If the upstream provider does not publish a usable Annex XII pack, push back — non-supply is a breach of 53(1)(b) on the upstream side. In 2026 the major providers ship this as part of their developer documentation; you screenshot or hyperlink the relevant page in your bundle.

DUTY 3 · ART. 53(1)(c)

Put in place a policy to comply with Union copyright law

The upstream provider must have a written policy describing how it identifies and respects the rights of rightsholders, including the text-and-data-mining reservation under Article 4(3) of the CDSM Directive. This is the policy that says how the provider treats opt-outs (robots.txt, ai.txt, machine-readable reservations).

What this means for you as downstream. Your enterprise customer's legal team will ask whether the underlying training data respects copyright. You point them to the upstream provider's published copyright policy. You do not write your own — your inputs are user prompts, not a training corpus. Where you do generate fine-tuning data from your own customers' content, you need your own privacy and copyright notice for that data; this is a contract clause, not a GPAI duty.

DUTY 4 · ART. 53(1)(d)

Publish a sufficiently detailed summary of training content

The famous training-content summary. The upstream provider must publish — using a template adopted by the AI Office — a "sufficiently detailed" summary of the content used to train the GPAI model. This includes major datasets, web crawls, licensed corpora and the methodology for deduplication and filtering.

What this means for you as downstream. Reference the published summary. Provide the URL in your compliance bundle. If your customer asks "did the training set include our trade-secret documentation that leaked in 2023?" you forward the question to the upstream provider; you are not the appropriate respondent.

Article 53(2) — the open-source carve-out

Article 53(2) reduces the burden on GPAI models released under a free and open-source licence. The carve-out applies to Article 53(1)(a) and (b) — the Annex XI and Annex XII documentation duties — when three conditions hold:

What this means practically: Llama, Mistral and Gemma fall inside the carve-out for the documentation duties. The copyright duty (53(1)(c)) and the training summary duty (53(1)(d)) still apply to them. So if your product self-hosts Llama 3.1 8B, your enterprise customer can still find a Meta training-content summary and a Meta copyright policy — those are the load-bearing flowdown items, and they survive the carve-out.

The carve-out does not apply to systemic-risk models. Article 53(2) explicitly excludes GPAI models with systemic risk under Article 51. Llama 3.1 405B has been argued both ways; the AI Office's working list updates quarterly. Check the current designation before assuming open-source = light regime. Mistral's largest open-weights models sit at the same boundary.

Article 55 — when the upstream model has systemic risk

A GPAI model with systemic risk is one that meets the high-impact threshold in Article 51 — by default, cumulative training compute exceeding 10^25 FLOPs — or is designated by the Commission. The list as of 2026 includes GPT-4, GPT-4o, Claude Opus, Claude Sonnet (most recent), Gemini Ultra, and a handful of frontier-scale models from major providers.

Article 55 layers four additional duties on top of Article 53:

Art. 55 duty What it means upstream What flows down to you
55(1)(a) — Model evaluation including adversarial testing Red-teaming, evaluations, capability assessments before release and at major version updates. Reference the published evaluation report. Customers expect a hyperlink in your bundle.
55(1)(b) — Systemic risk assessment and mitigation Identify and mitigate Union-level risks: large-scale harm, fundamental rights, public security. Note your reliance on this. If your downstream use case touches a flagged risk, document the residual mitigation you layer on top.
55(1)(c) — Serious incident reporting to AI Office Track and report serious incidents and possible corrective actions without undue delay. References Article 73 for the substantive regime. Your incident channel routes upstream-model issues to the provider's serious-incident form. Keep that route documented. If you cross the GPAI-provider line via continued pre-training, this duty becomes yours; Article 73 thresholds and Annex IX template apply.
55(1)(d) — Cybersecurity protection Ensure adequate cybersecurity for the model and its physical infrastructure. Reference the upstream provider's SOC 2 / ISO 27001 status. Customer procurement reads this as "I see the basic stack is locked".

You do not perform any of these duties as downstream. You reference them, in your bundle, in the order the customer's compliance template asks for them.

The substantial-modification flip — when downstream becomes upstream

Article 25(1)(c) is the trap door. It flips an entity from deployer-or-downstream into provider when three triggers fire:

  1. Substantial modification of an AI system that is already on the market;
  2. Placing on the market under your own name or trademark;
  3. Modification of the intended purpose in a way that changes the risk classification.

Substantial modification for GPAI models specifically is defined in the Commission's 2026 draft guidance. The operative rules of thumb:

Below 10% of original training compute. Light fine-tunes, LoRA, prefix-tuning, instruction-tuning on small datasets. Unambiguously downstream. Document the ratio in your model registry; you will be asked.
10% to 33% of original training compute. Larger fine-tunes, domain adaptation runs, full-parameter fine-tunes on medium corpora. Defensible as downstream when the architecture and intended purpose are unchanged. Document the unchanged intended purpose explicitly.
Above 33% (one third) of original training compute. Presumptive substantial modification. Plan to operate as GPAI provider for the derived model. Update your Article 53 file (Annex XI + XII + copyright policy + training summary). If the resulting model crosses the systemic-risk threshold, Article 55 also applies.
Rebranding without compute change. Reshipping an upstream model under your own name flips you regardless of training delta. Article 25(1)(c) catches white-labelling. Do not rename the model in your customer-facing API responses unless you intend to take on the file.
Changing intended purpose. If you take a general-purpose chat model and ship it as a medical diagnostic assistant — without the upstream provider sanctioning that purpose — you have changed intended purpose. The flip applies, plus Annex III high-risk classification may kick in. This is the worst path: GPAI provider plus high-risk provider in the same file.

The 2026 GPAI Code of Practice — what it does and does not do

Article 56 invited the AI Office to facilitate codes of practice that operationalise Articles 53 and 55. The first GPAI Code of Practice was published in mid-2025 and signed by OpenAI, Anthropic, Google DeepMind, Microsoft, Meta and Mistral, among others.

The Code is voluntary and does not replace the statutory duty. What it does is collapse the compliance question into a single document the customer's legal team recognises: "is the upstream model provider a signatory to the GPAI Code of Practice?" If yes, that establishes a presumption of conformity with Articles 53 and 55 until the formal harmonised standards under Article 41 are published.

As a downstream provider, the practical workflow is short:

  1. Confirm your upstream model provider is a signatory (the AI Office maintains a public list).
  2. Reference the Code in your compliance bundle.
  3. If your upstream provider is not a signatory (a smaller European model lab, for instance), expect to do more documentation work yourself — collect the Annex XI/XII/copyright/training-summary items individually rather than gesturing at the Code.

GPAI deadlines after the May 2026 Omnibus

The Omnibus delayed Annex III (high-risk) to December 2027 and Annex I (regulated products) to August 2028, but left the GPAI regime untouched. The GPAI dates that matter:

Date Event Affects you?
2 August 2025 GPAI obligations (Art. 53, 55) entered into application. Yes — they are in force now. Enforcement ramps over 2026.
2 August 2026 End of the grace period for GPAI models placed on the market before 2 August 2025. By this date, pre-existing GPAI models must be in compliance. Yes — if your wrapped model has a pre-2025 lineage, the upstream provider must have completed remediation. Verify in their model card.
2 August 2026 Penalties enforceable. National authorities and the AI Office can issue fines. Indirect — fines hit the upstream provider, but supply disruption hits you.
December 2027 Annex III high-risk obligations applicable (delayed by Omnibus). Article 26 deployer duties bind in full. Yes — if your product is downstream of GPAI and high-risk, both regimes apply.
August 2028 Annex I regulated-product AI obligations applicable (delayed by Omnibus). Article 6(1) classification. Rarely. Annex I covers AI used in regulated products like medical devices and lifts.

Full timeline in the deadlines timeline post.

The downstream-provider documentation flowdown — the one-page version

Enterprise procurement does not want to read the regulation. They want a one-pager that maps the regime onto your specific stack. The template below is what fits in a compliance bundle and gets signed by the customer's legal team in one review cycle.

DOWNSTREAM-PROVIDER GPAI FLOWDOWN — <PRODUCT NAME>

1. Upstream model dependency
   - Model: <e.g. gpt-4o-2024-08-06>
   - Provider: <e.g. OpenAI>
   - GPAI status: <standard | systemic-risk per Art. 51>
   - Code of Practice signatory: <yes | no>
   - Article 53(1)(d) summary URL: <https://...>
   - Model card URL: <https://...>

2. Downstream modification posture
   - Modification type: <none | prompt engineering | LoRA | full fine-tune>
   - Training compute ratio vs base: <e.g. 0.1%>
   - Intended purpose unchanged: <yes — same conversational assistant scope>
   - Article 25(1)(c) self-assessment: <downstream provider — below 33% threshold>

3. Customer-visible artefacts
   - Acceptable use policy: <URL>
   - Prohibited uses passed through from upstream: <list>
   - Logging retention: <6 months minimum, configurable to 7 years>
   - Article 26 deployer support bundle: <yes — exported via auditai SDK>

4. Incident escalation
   - Serious incident channel for upstream model: <provider's report form>
   - Serious incident channel for product-level issues: <your form>
   - SLA for incident acknowledgement: <24h>

5. Versioning
   - Document version: <1.0>
   - Last reviewed: <2026-05-12>
   - Review frequency: quarterly or at every upstream model version update

That fits on one page. Enterprise legal signs one-pagers. They do not sign nine-pagers, and they especially do not sign nine-pagers in regulation-speak.

Common failure modes (audited in 2026)

FAILURE · 1

The "we are just an API wrapper" defence

Downstream providers sometimes argue they have no GPAI duties at all because they only call an API. This is correct for Article 53 duties — those sit upstream. It is not correct for the Article 25(1)(c) self-assessment and the flowdown package. Saying "we are just an API wrapper" without producing the one-pager above leaves a hole in the compliance bundle that procurement will catch. Build the one-pager even if it is short.

FAILURE · 2

Fine-tuning without tracking compute ratio

Many teams fine-tune in the OpenAI fine-tuning console or on a self-hosted cluster without keeping a record of training compute. Six months later they cannot answer "what was your fine-tune size relative to the base?" Without that number, you cannot defensibly claim you sit below the Article 25(1)(c) threshold. Log compute as a discipline from day one — model name, base parameter count, fine-tune dataset size, training time, GPU type, total FLOPs. Five fields in your model registry.

FAILURE · 3

Renaming the model in customer-facing APIs

A vendor wraps Claude Sonnet and exposes it to customers as "Acme AI Assistant v3". The customer-facing string never references Anthropic or Claude. Article 25(1)(c) reads this as placing the model on the market under your own name — flip triggered. The fix is small: keep an attribution string in the API metadata (upstream_model: "claude-sonnet-4-5") and in the public docs. You can still market your product as Acme AI; you just cannot deny that Claude is in the loop.

FAILURE · 4

Treating open-source models as zero-compliance

"We self-host Llama, so we have no GPAI exposure." Article 53(2) reduces the upstream duties on open-source GPAI but does not eliminate the copyright policy or training summary. And the Article 25(1)(c) flip rules apply identically to open-source bases. Self-hosting does not remove the file; it shifts which sections are short.

FAILURE · 5

Not naming the upstream model in your bundle

Some vendors anonymise the upstream model because they fear lock-in disclosure ("our customers do not need to know we use OpenAI"). Procurement disagrees — they need to evaluate the dependency. Name the upstream model, name the version, name the date you last reviewed the Article 53(1)(d) summary. Customers prefer specificity over flexibility on this one.

The auditai SDK and downstream-provider documentation

The auditai SDK ships an export tailored for downstream providers under Article 25(1)(c):

Three lines of code, one flowdown PDF per product version, ready to hand to enterprise procurement alongside your Article 26 deployer bundle.

pip install auditai-sdk

from auditai import AuditAI
audit = AuditAI(
    product="Acme AI Assistant",
    upstream_model="gpt-4o-2024-08-06",
    modification="prompt_engineering"
)
audit.export_gpai_flowdown("./gpai-flowdown.pdf")

FAQ

1. If I wrap GPT-4 or Claude in my SaaS, am I a GPAI provider under the EU AI Act?

By default no — you are a downstream provider. OpenAI and Anthropic are the GPAI providers; they bear the Article 53 obligations for their models. You inherit a much lighter regime: you must be able to show your enterprise customers the upstream provider's Article 53(1)(d) documentation and your own product file. The flip happens only if you substantially modify the model (heavy fine-tuning, rebranding under your own name, changing intended purpose) — Article 25(1)(c). API calls and prompt engineering do not flip you. LoRA adapters and light fine-tunes usually do not. Full continued pre-training on your own corpus does.

2. Does the Article 53 GPAI regime apply to open-source models like Llama or Mistral?

Article 53(2) carves out open-source GPAI models from the Article 53(1)(a) and (b) documentation duties, but only when the model is released under a free and open-source licence and the weights, architecture and usage information are publicly available. The copyright duty in Article 53(1)(c) and the summary of training content in Article 53(1)(d) still apply. The carve-out does not apply at all to GPAI models with systemic risk under Article 51 — those are inside the Article 55 regime regardless of licence.

3. What is a GPAI model with systemic risk under Article 51?

A GPAI model has systemic risk when it meets the high-impact capability threshold in Article 51(1)(a) — a default presumption when cumulative training compute exceeds 10^25 FLOPs — or when the Commission designates it under Article 51(1)(b). Systemic-risk models trigger the heavier Article 55 regime: model evaluations including adversarial testing, systemic risk assessment, serious incident reporting to the AI Office, and cybersecurity protections. As of 2026 the named designations include GPT-4, Claude Opus, Gemini Ultra and similar flagship models.

4. Will heavy fine-tuning of an upstream GPAI flip me into the GPAI provider role?

Article 25(1)(c) flips the downstream entity into the provider role when there is a substantial modification, the system is placed on the market under their own name, or the intended purpose changes. The Commission's draft guidance treats continued pre-training on a large corpus, modifications that change the systemic risk profile, or any modification that exceeds one third of the original training compute as substantial. Below that threshold — LoRA, prefix-tuning, light instruction fine-tunes — you stay downstream. Document where you sit before procurement asks.

5. What must OpenAI or Anthropic give me as a downstream provider?

Article 53(1)(d) requires GPAI providers to provide information and documentation to downstream providers so the downstream can comply with their own obligations. Annex XII lists the minimum: model architecture and parameter count, intended tasks and prohibited uses, evaluation results, training process summary, computational resources used, and a summary of training content. The 2026 GPAI Code of Practice template signed by the major providers operationalises this as a model card plus a system card available to enterprise customers under NDA.

6. Are GPAI obligations enforced yet in 2026?

Yes. The GPAI regime in Articles 53 through 55 entered into application on 2 August 2025 — twelve months after the Act entered into force. The May 2026 Omnibus did not delay GPAI; it delayed Annex III high-risk to December 2027 and Annex I to August 2028, but kept the GPAI deadlines intact. Penalties for GPAI breach can reach 3% of global annual turnover or EUR 15 million, whichever is higher (Article 101).

7. Does the GPAI Code of Practice replace Article 53 obligations?

No. The Code of Practice is a voluntary instrument that provides one way to demonstrate compliance with Article 53 and 55 — it does not replace the statutory duty. Until the harmonised standards under Article 41 are published, adherence to the Code creates a presumption of conformity. The major upstream providers (OpenAI, Anthropic, Google DeepMind, Microsoft, Meta, Mistral) signed the Code in 2025. Non-signatories can still comply with Article 53 directly but bear the burden of proof.

8. How does GPAI flowdown interact with Article 26 deployer obligations?

GPAI duties (Article 53) sit upstream of you; Article 26 deployer duties sit downstream of you. As a downstream provider you build the bridge: you receive the GPAI Article 53(1)(d) package from the upstream model provider, layer your own product documentation on top, and pass an enterprise-ready compliance bundle to your customer who carries Article 26 obligations. The cleanest packaging is one PDF the customer can hand to their legal team, with the upstream model card attached as an annex.

The bottom line

The GPAI regime is one of the few parts of the EU AI Act that is already enforceable in 2026. The Annex III delay does not touch it. The deadlines and penalties are real, and procurement teams are now asking the third question — "GPT-4 is in the loop, what does that mean for us?" — as routinely as they ask the first two.

The good news for downstream providers is that the regime is far lighter than the regimes that sit on either side. Article 53 is the upstream provider's file. Article 26 is the customer's file. Your file is a one-page flowdown that names the upstream model, references the upstream documentation, and self-assesses against the Article 25(1)(c) substantial-modification threshold. Five fields in your model registry, one PDF in your compliance bundle, and the question stops blocking deals.

If you want the file done for you — five business days, signed, defensible, with the upstream Article 53(1)(d) package mapped explicitly — the €199 managed audit delivers the one-pager above, populated with your real product details.

Ship the GPAI flowdown your customer signs in one review

One PDF. Three lines of code. Article 25(1)(c) self-assessment + upstream model references + flowdown bundle.

Get the managed audit — €199 →

Related reading

This article is informational and reflects the EU AI Act as in force after the May 2026 Omnibus delay. It is not legal advice. The managed-audit deliverable is a compliance memo, not a legal opinion; engage qualified counsel for binding interpretation. Article references are to the EU AI Act consolidated text. The one-third training-compute threshold for substantial modification reflects the Commission's 2026 draft guidance and may be revised in the final delegated act.