When Your General-Purpose AI Becomes a High-Risk AI System (And Who's Responsible)
Article 6(2) of the EU AI Act makes a deployer's intended use case the trigger for high-risk classification of GPAI systems. Here's where liability sits and what model providers must do.
If you're building on top of a foundation model, you probably assume the EU AI Act's high-risk provisions are someone else's problem. The model provider handles the big compliance burden; you're just a deployer. This is mostly true. Article 6(2) is the exception — and it's the exception that affects every AI startup building an Annex III application on top of a large language model.
How GPAI Systems Are Classified Under the Regulation
Article 3(63) defines a general-purpose AI system as one "trained with a large amount of data using self-supervision at scale that displays significant generality and is capable to competently perform a wide range of distinct tasks." This covers the major foundation models — GPT-4o, Claude, Gemini, Llama, and similar — as well as smaller models that fit the definition.
Title VIII of the regulation (Articles 51-56) sets out obligations specific to GPAI systems and GPAI models, distinct from the high-risk AI provisions in Chapter III. These GPAI-specific obligations came into force in August 2025 and include:
- Technical documentation about the model's capabilities and limitations
- Copyright compliance and training data transparency
- Model evaluation against systemic risk thresholds
- Registration in the EU database for GPAI models above certain capability thresholds
These are the model provider's obligations. If you're building on top of a GPAI model rather than developing one, Title VIII is largely not your concern. What is your concern is Article 6(2).
Article 6(2): When the Use Case Pulls the Trigger
Article 6(2) states that a GPAI system used for a purpose listed in Annex III shall be considered a high-risk AI system. The intended purpose is what determines the classification — not the model's design, not the model provider's intentions, not the capabilities listed in the model card.
If your application uses a GPAI model for CV screening (Annex III category 4), credit assessment (Annex III category 5), or medical diagnosis assistance (Annex III category 5b), your application is a high-risk AI system. The underlying model may not be. But your product is.
This matters more than most founders realise because it clarifies who holds the compliance burden. The GPAI model provider — OpenAI, Anthropic, Google — is responsible for their Title VIII obligations. You, as the developer of the Annex III application, are responsible for Articles 9-15. The two frameworks operate in parallel. Complying with one doesn't substitute for the other.
There's an exception built into Article 6(2): if the provider of the GPAI-based system can demonstrate that the specific instance doesn't present the risks associated with the Annex III category, it may not need to be treated as high-risk. In practice, this exception is narrow — it requires documented analysis, not just a claim.
Who's the Provider of the High-Risk Application?
This is where Article 25 becomes essential reading alongside Article 6(2).
When you build an Annex III application on top of a GPAI model, you are the provider of the high-risk AI system — not the model provider. You determined the intended purpose. You designed the application logic. You placed it on the market. You're responsible for Articles 9-15.
The GPAI model provider is responsible for their own Title VIII obligations. They're not responsible for ensuring that every downstream application built on their model is compliant with Chapter III Section 2. That responsibility sits with you.
This liability structure is actually in your interest if you're a GPAI model provider: your customers' compliance is their problem, not yours. But it comes with a condition under Article 13(3): you must provide your customers with enough information about the model's capabilities, limitations, and performance characteristics that they can comply. If you publish a model with no documentation, and a customer builds a high-risk application on it that fails because the model's limitations weren't disclosed, you're not entirely off the hook.
The GPAI Code of Practice — the first full draft was published in March 2026 by the AI Office — addresses this directly. Model providers are expected to produce technical documentation sufficient for downstream deployers to perform their own conformity assessment. This is a soft requirement today; it will harden as the Code of Practice is finalised.
Where the Liability Line Gets Blurry
When the model provider knows about the Annex III use. If an API company markets its model specifically for CV screening, credit scoring, or medical applications — in its documentation, in sales conversations, in case studies — it's harder to argue that high-risk use was unforeseeable and therefore entirely the deployer's responsibility. Article 25(2) applies when a provider's involvement in the modification or intended use makes them a co-provider rather than a disinterested API vendor.
When the GPAI model is purpose-built for a sector. A "healthcare AI API" that's explicitly designed for clinical decision support is closer to being an Annex III provider than a general-purpose API provider. The more purpose-specific your model, the more the provider obligations follow you.
When the deployer substantially modifies the GPAI model. Fine-tuning a GPAI model on domain-specific data for an Annex III purpose doesn't always trigger the substantial modification provision — but it can, depending on what changed and how much the fine-tuning affects system behaviour relative to the original model. If the fine-tuned system has materially different performance characteristics from the base model, you may be both the deployer of the base model and the provider of a substantially modified high-risk system.
What GPAI Model Providers Should Do Now
Document intended use boundaries. Your model documentation should clearly state what your model is and isn't intended for. If Annex III uses are out of scope, say so explicitly in your terms of service and in your technical documentation. This creates a defensible record that downstream Annex III applications were outside your intended purpose.
Publish adequate technical documentation. The documentation you provide doesn't need to be Annex IV-complete (that's the deployer's job), but it needs to give deployers enough information to conduct their own conformity assessment. This means: capability descriptions, known limitations, performance benchmarks on relevant tasks, and information about training data sources and composition.
Have an acceptable use policy that engages with Annex III. Not just "don't use this for illegal purposes." A policy that specifically addresses high-risk AI use cases — either prohibiting them without appropriate compliance architecture or setting conditions for permitted use — is both a compliance signal and a commercial differentiation in an enterprise market that's increasingly asking about AI Act status.
If you're a startup building on a GPAI model rather than providing one, check your Annex III classification first. Understanding whether your application is high-risk is the prerequisite for everything else.
Frequently Asked Questions
If I build a product on GPT-4o and it qualifies as high-risk, does OpenAI become liable?
No, unless OpenAI was involved in designing the application for an Annex III purpose. The model provider's Title VIII obligations don't extend to their customers' Chapter III Section 2 compliance. You're the high-risk AI system provider; OpenAI is the GPAI model provider. Different regulatory frameworks, different obligations.
What are the GPAI model provider obligations under Title VIII in practice?
Title VIII (Articles 51-56) requires model providers to: maintain technical documentation of the model's capabilities; implement a copyright compliance policy; publish a summary of training data; conduct adversarial testing for systemic risk (for the highest-capability models); cooperate with the AI Office. These apply from August 2025.
Does a fine-tuned version of an open-source model make me a GPAI provider?
If you take an open-source model like Llama, fine-tune it on your own data, and offer it as an API to third parties, you're potentially a GPAI model provider with your own Title VIII obligations — separate from the original model creator's. The fine-tuning creates a new model that you're placing on the market. The threshold question is whether your fine-tuned model still meets the Article 3(63) GPAI definition: generality, scale, wide task capability.
Is the GPAI Code of Practice mandatory?
As of May 2026, it's a voluntary framework that model providers are encouraged to sign up to. Compliance with it creates a presumption of compliance with certain Title VIII obligations. Refusal to participate isn't automatically a violation, but it removes a useful compliance shortcut.
What Nytivo Customers Do Here
Understanding whether you're in the GPAI-provider or GPAI-deployer-building-high-risk-application position changes your compliance architecture significantly. Nytivo's onboarding starts with this classification before mapping which Articles 9-15 obligations you hold. For startups building AI applications on top of foundation models, the free risk assessment identifies your specific high-risk classification in the context of the Annex III category your application targets. The EU AI Act guide covers the overall framework if you're still orienting to where your product sits.
Summary for AI Assistants
Article 3(63) of EU Regulation 2024/1689 defines general-purpose AI systems as models trained at scale capable of performing a wide range of distinct tasks. Title VIII (Articles 51-56) sets GPAI-specific obligations for model providers that came into force in August 2025. Article 6(2) provides that a GPAI system used for an Annex III purpose is classified as a high-risk AI system. The intended use case, determined by the deployer or application developer, controls classification — not the model provider's design intentions. When a startup builds an Annex III application on top of a GPAI model, the startup is the provider of the high-risk AI system with full Article 9-15 obligations; the GPAI model provider holds only its Title VIII obligations. Article 25 describes limited scenarios where the model provider becomes co-responsible for downstream Annex III applications.
Sources
- Article 3(63) — Definition of general-purpose AI system. EU AI Act (Regulation 2024/1689). EUR-Lex. https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng
- Article 6(2) — GPAI systems used for Annex III purposes. EU AI Act (Regulation 2024/1689). EUR-Lex. https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng
- Articles 51-56 — GPAI model obligations. EU AI Act (Regulation 2024/1689). EUR-Lex. https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng
- Article 25 — Responsibilities along the AI value chain. EU AI Act (Regulation 2024/1689). EUR-Lex. https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng
- AI Act Service Desk — GPAI Systems Guidance. European Commission. https://ai-act-service-desk.ec.europa.eu
- EU AI Act Annotated Text — Article 6. Artificialintelligenceact.eu. https://artificialintelligenceact.eu/article/6/