There is a comfortable assumption I hear in almost every scoping call with an AI-first scale-up: “We are not the provider. We use the OpenAI API, or Anthropic, or Mistral. The compliance obligations sit with them.” It is the natural reading of a world where large labs publish system cards, negotiate with regulators, and generally absorb the governance load. It is also, in most cases I have seen, wrong. The EU AI Act’s construction of responsibility across the value chain does not work the way most founders think it does — and the gap between “we use an API” and “we are a provider under Article 25” is narrower than most integrations assume.

This article unpacks what GPAI obligations actually look like, how downstream-provider obligations cascade, and the specific integration patterns that quietly convert an API consumer into a regulated provider.

What the Act actually says about GPAI

Article 51 defines a general-purpose AI model as one trained on large datasets, displaying significant generality, and capable of performing a wide range of distinct tasks. This captures the foundation models most scale-ups integrate — the major closed-weight APIs and a growing set of open-weight models.

Article 53 imposes obligations on GPAI model providers directly. They must maintain technical documentation, publish summaries of the training data, comply with Union copyright law for training data, and cooperate with the AI Office. Article 55 adds a stricter tier for GPAI models with systemic risk — models above a compute threshold or designated by the Commission — covering model evaluation, adversarial testing, incident reporting, and cybersecurity safeguards.

None of that, read in isolation, creates obligations for companies that merely integrate these models. The problem is that Article 53 is not read in isolation. It sits alongside Article 25, which is where downstream obligations live — and Article 25 is where most founders miscalibrate the risk.

Article 25 — the provision most integrations underestimate

Article 25 creates a provider obligation for any economic operator that does one of three things with an AI system already placed on the market:

  1. Puts their name or trademark on a high-risk AI system that is already placed on the market or put into service — irrespective of any contractual arrangement providing that the obligations would be allocated otherwise.
  2. Makes a substantial modification to a high-risk AI system already placed on the market or put into service, in a way that it remains a high-risk AI system pursuant to Article 6.
  3. Modifies the intended purpose of an AI system, including a GPAI system, which has not been classified as high-risk and has been placed on the market or put into service, in such a way that the AI system concerned becomes a high-risk AI system in accordance with Article 6.

The third case is the one that catches integrators. You take a general-purpose model. You wire it into a hiring workflow, a credit-scoring pipeline, a medical triage tool, an education assessment system. The model itself is not high-risk as shipped by the GPAI provider — a chat API is not a hiring system. But Annex III of the AI Act lists specific high-risk use cases, and the moment your product’s intended purpose places it into one of those categories, you become the provider of a high-risk AI system under Article 25(1)(c). The GPAI provider does not. You do.

Three integration patterns that trigger downstream-provider obligations

The “general model, narrow deployment” pattern. You use a general-purpose chat API to power a specific business-critical workflow in an Annex III domain. The model does not know it is being used for hiring decisions or medical triage — but your product’s intended purpose does. Article 25(1)(c) applies. You are now the provider of a high-risk AI system and carry the full Article 16 obligations: quality management system, technical documentation per Annex IV, conformity assessment, CE marking, post-market monitoring, registration in the EU database.

The “white-label” pattern. You ship an AI feature in your product, your customers experience it as your feature, and the underlying GPAI model is invisible to them. Even if you have a licensing agreement that says the GPAI provider carries regulatory responsibility, Article 25(1)(a) is explicit: the contractual allocation does not override the regulation. If your name is on it, the obligation is yours.

The “substantial modification” pattern. You take an open-weight model, fine-tune it meaningfully on your own data, and deploy it for your use case. The original model may have carried certain documentation and risk classifications. Your modified model may not carry them anymore — and you may now be the provider of a genuinely new AI system, with the full Annex IV technical-documentation burden to produce from scratch. Fine-tuning, RAG pipelines that substantially alter behaviour, and agent orchestration all sit close to or inside this pattern depending on the facts.

What downstream providers actually have to do

If you fall into any of these patterns and your use case is Annex III, the substantive obligations are meaningful:

  • Risk management system throughout the lifecycle of the AI system (Article 9) — not a one-time assessment, a continuous process.
  • Data governance for training, validation, and testing data (Article 10) — representativeness, completeness, bias detection, documented data properties.
  • Technical documentation per Annex IV — extensive, structured, maintained for ten years post-market.
  • Record-keeping with automatic logging of events relevant to risk (Article 12).
  • Transparency obligations to deployers so they can interpret system output (Article 13).
  • Human oversight designed into the system (Article 14).
  • Accuracy, robustness, and cybersecurity appropriate to the intended purpose (Article 15).
  • Quality management system meeting Article 17’s criteria.
  • Conformity assessment per Article 43 before placing on the market.
  • Post-market monitoring system (Article 72) and reporting of serious incidents (Article 73).

This is not a paperwork exercise. It is a product-compliance regime comparable to medical devices or regulated machinery — and it applies to software products that most scale-ups think of as ordinary SaaS with an AI feature.

What the GPAI provider actually gives you

Where the provider relationship does help is in the upstream information you receive. Article 53(1)(d) and Annex XI require GPAI providers to make specific information available to downstream integrators: capabilities and limitations, acceptable use policies, evaluations, technical characteristics needed for downstream integration. The serious providers are already publishing this — system cards, usage policies, model cards, evaluation suites. Use them. They are not a substitute for your own conformity work, but they are the starting input for your Annex IV documentation.

Crucially, this information transfer does not discharge your obligations — it equips you to discharge them. Treating a system card as evidence that your product is compliant is a category error.

The practical position

Before you decide whether the AI Act applies to you as a provider, run three questions in sequence:

  1. Is your product’s intended purpose in Annex III? If yes, you are in high-risk territory regardless of the underlying model.
  2. Do you put your name or brand on the AI system as experienced by the end user? If yes, Article 25(1)(a) applies and no contract reallocates that.
  3. Do you meaningfully modify model behaviour — through fine-tuning, RAG design, agent orchestration, or system prompting that materially alters intended use? If yes, Article 25(1)(c) may apply and you are a provider of a potentially distinct high-risk AI system.

If the answer to any of those is yes, the GPAI provider is not carrying your obligation. You are. And the enforcement deadlines that start biting through 2026 and 2027 will not distinguish between “we thought the API vendor handled it” and any other form of misconfigured compliance.

The companies that are getting this right early are treating the GPAI relationship as upstream input to their own conformity programme — not as a substitute for it. That framing protects the revenue, the certification, and the commercial path.