Three weeks before launch, your team’s lawyer asks the question you’d been treating as administrative: “Are we the deployer or the provider?”
The instinct says deployer. Anthropic, or OpenAI, or whoever your model vendor is, built the model. You just wrote a system prompt, wired up retrieval and added guardrails. You’re using the thing they made.
The instinct could be wrong, and the EU AI Act has a specific clause about it.
Article 25 quietly makes you a provider
Article 25(1) of the Act describes three paths by which a company that started as something-other-than-a-provider becomes one: (a) putting your name on someone else’s system, (b) substantially modifying it, or (c) scoping a general-purpose model toward a high-risk use. The third is the one catching most teams shipping on a model API. Path (c) turns on intended purpose: a GPAI provider usually states its model’s intended purpose very broadly and well outside high-risk territory, so aiming the model at a high-risk use is itself the change of intended purpose that Article 25(1)(c) catches. You take a general-purpose AI model that is not, on its own, high-risk, and you scope it toward a use case that is. From that point, you are the provider of an AI system. Annex IV — the technical documentation requirement — is now your obligation, addressed to you, drawn up by you.
Most teams shipping enterprise AI in 2026 have never read this clause. They ship something that screens resumes, or routes benefits eligibility decisions, or pre-qualifies credit applications, and they think of themselves as integrators. They are providers. They just haven’t been told.
The wrong mental model
Most teams approach AI compliance documentation by asking “what does our system do, and how do we describe it?” That phrasing assumes the AI system is one thing, owned by one party, end-to-end. Under the regulation, that’s almost never how the obligations stack.
There are at least three different roles you might be in:
- Deployer. You are using a high-risk AI system under your own authority — typically one a vendor built and placed on the market, though as the strangest case below shows, that isn’t required. Your obligations live in Article 26: use as instructed, monitor, log, inform users. And if you’re a public body, a private entity delivering public services, or a deployer in one of a few specific Annex III categories (creditworthiness, life- and health-insurance pricing), you also owe a Fundamental Rights Impact Assessment. You do not draw up Annex IV.
- AI-system provider built on a GPAI model. You took a general-purpose model and wrapped it into a system that is high-risk on the way it gets used. You draw up Annex IV. You reference the GPAI provider’s Article 53 documentation for the model layer, and you fill in the system layer yourself.
- Provider via Article 25(1)(c). You bought or integrated something that wasn’t high-risk in the seller’s hands, but you scoped it toward a high-risk use, and the regulation now treats you as the provider of that system. Same Annex IV obligation as above. Different path to it.
(There’s also the baseline case — building a high-risk system from scratch, with no third-party model underneath — which makes you a provider the ordinary way. It’s just not the path catching teams who ship on a model API.)
Two of the three put you on the hook for Annex IV. Most teams assume they’re in the first one and freeze when the form starts asking about training data they don’t have. They’ve misclassified themselves.
Role isn’t the only axis that stacks. Even the risk classifications aren’t mutually exclusive: a system can be high-risk and carry Article 50 transparency obligations at the same time; Art. 50(6) is explicit that those duties apply without prejudice to the high-risk requirements. The regulation layers obligations; it doesn’t sort you into a single bucket. Reading the risk tiers as either/or is the same error as misreading your role, and it’s just as easy to make.
The Article 25(1)(c) trap, in plainer language
The clause sounds abstract; the trigger isn’t. Say you’re a health insurer. You ship a customer-service chatbot on top of an LLM API to answer coverage questions. Mid-quarter, product asks if it can also give prospects a preliminary premium estimate from what they describe about themselves. Two prompts and a lookup. Done.
You just modified the intended purpose of a general-purpose model and pointed it at risk assessment and pricing for health insurance — squarely an Annex III high-risk use (§5(c)). Article 25(1)(c) applies. You are the provider of a high-risk AI system. You owe Annex IV. Nothing about your codebase changed shape. Your role under the regulation did.
The strangest case: you’re both provider and deployer
Now run the same logic on a tool you build for internal use only. You wrote the system, you pointed it at a high-risk function, and you never sold or distributed anything. The instinct says “we never shipped it, so the Act doesn’t reach us.” It’s backwards. “Putting into service” is defined to include supply for your own use. Building the thing in-house is a trigger, not an exemption.
So you are both at once: the provider of the system (Annex IV is yours) and its deployer (the Article 26 monitoring, logging, and oversight duties are also yours). One company, one system, both legal roles, both obligation stacks. The model vendor is still upstream and keeps its own duties; Article 25 spreads responsibility along the chain rather than dumping it on you. But for the system you scoped, you wear both hats at once.
And if you’re a public body or in a covered category, your deployer-self owes a Fundamental Rights Impact Assessment on the very system your provider-self just documented — two assessments, same tool, one company. The model vendor’s paperwork shields neither.
What Annex IV actually wants from you
Once you accept you’re the provider, the Annex IV form stops looking weird. It’s asking you, the entity that aimed this thing at a high-risk function, to explain what you scoped, how you tested it, how you’ll keep an eye on it, and how someone who isn’t you could verify all of that.
The shape of the answer is consistent: you point to the model vendor’s documentation for the model layer, then explain and test what you built on top of it. And if the vendor’s documentation has holes, you are not on the hook to reverse-engineer the model or invent what they never disclosed. Your own tests and risk assessment, scoped to your use case, are what make the system defensible; gaps upstream don’t fall to you to fill.
Walking through Annex IV under the provider framing, with a worked example — a resume-screening assistant for a mid-size HR-tech firm, built on a GPAI API, with retrieval over the company’s competency framework and a system prompt that enforces evaluation criteria:
| Annex IV section | GPAI-model provider answers (referenced) | AI-system provider answers (your responsibility) |
|---|---|---|
| §1 General description | Model card from the GPAI provider | Intended purpose for your high-risk scoping, deployment context, user groups, limitations |
| §2 Development and data | Provider’s training-data documentation under Art. 53 | Your system prompt, retrieval corpus and provenance, guardrail configuration, the scoping decision itself |
| §3 Risk management | — | Risk register for your scoped use, identified failure modes (bias on protected attributes, hallucination on edge candidates), mitigations |
| §4 Performance metrics | Provider’s general benchmarks (referenced) | Your evaluation results on your use case, against your acceptance criteria. This is the load-bearing section. |
| §5 Human oversight | — | Where humans review, what they can override, how flagged outputs are surfaced |
| §6 Cybersecurity | Provider’s API security posture | Your access controls, secret management, network controls, audit trail |
| §7 Quality management | — | Your change management, deployment procedure, version history of prompts and corpora |
The performance-metrics section (§4) is where the framing earns its keep. As a provider, you are claiming the system performs adequately for the scoped high-risk use. The only honest evidence for that claim is evaluation results on your data, your prompts, your corpora, your acceptance criteria. The GPAI provider’s general benchmarks cannot answer it for you. They were never the right benchmark.
Role first, evidence second
Two consequences follow from putting the role question first. One: the rest of the documentation flows from that single classification — most tooling still asks “describe your system” when it should ask “which provider/deployer path are you on.” Two: evaluation evidence stops being a separate workstream — §4 of Annex IV simply is your pass rates and per-criterion judge scores.
And the same evidence base answers multiple frameworks. ISO 42001 governance asks provider-shaped questions about the same scoped system. Procurement diligence from your enterprise buyers asks the same questions in a different format. Once you have separated what you scoped from what your GPAI vendor trained, you can answer multiple frameworks from one input set.
At Germany’s AI Act Now conference this year, BNetzA officials signalled a “comply or explain” posture: reviews examine the technical documentation first, and reach for runtime testing only when the docs raise concerns. The question won’t be “did you train this responsibly”; they know you didn’t. It’s “did you scope and test it for this use, and can you show me?”
This post focuses on the Art. 25(1)(c) path. The other Article 25 triggers and the GPAI-provider side of the picture work similarly but aren’t covered here.
The first time you read Article 25(1)(c) and recognize your own deployment in it, the rest of Annex IV gets easier. The form was always asking the right questions. It just wasn’t asking them of who you thought it was.
Where elluminate fits
elluminate’s compliance documentation assistant, which we recently launched in beta, operationalizes the provider framing end-to-end, starting with the question this whole post is about. Before anything else it settles your role (provider, deployer, or both) and prunes the documentation to match: a deployer never drafts the Annex IV sections, a provider does. It doesn’t simply take your word for the answer that’s easiest to get wrong, either: say you’re a deployer who modified an upstream model for a high-risk use, and it raises the Article 25(1)(c) flag, suggesting you may in fact be a provider. You make the call. From there, two things keep the documentation honest. Each section header shows its legal basis as a chip: AI Act obligation for the Annex IV work, Complementary, beyond the AI Act for the modules the regulation doesn’t actually require (a BSI protection-needs analysis, say), so nothing masquerades as a hard requirement that isn’t one. And when the assistant fills a §4 performance field from an evaluation run, it records the source alongside the value (experiment ID, package, timestamp), so the evidence stays attached to the claim. Every remaining gap is marked rather than hidden.
If your team has shipped — or is about to ship — a system that scopes a general-purpose model toward something that looks like an Annex III use case, we can sit down with you and walk through Annex IV together. About thirty minutes. We’ll classify the role first, then go section by section: what you reference upstream, what you scoped yourself, where the operational gaps are, and where your evaluation evidence already covers more of §4 than you realized.
