Most EU AI Act guidance is written for companies using AI tools. If you are a tech company that builds AI-powered products, your obligations are fundamentally different — and far heavier. This guide covers the provider vs deployer distinction, the 7 provider obligations under Article 16, and what the conformity assessment process actually involves.
A natural or legal person who develops an AI system — or has one developed — and places it on the market or puts it into service under their own name or trademark.
Any natural or legal person using an AI system under their authority, except where the system is used in the course of a personal non-professional activity.
When your developers use GitHub Copilot to write code, you are a deployer. When a customer uses an AI feature you built into your product, you are a provider. The same company can be both — and each role triggers different obligations. Most founders only think about the deployer side and miss their provider obligations entirely.
Article 28 is the provision that catches out the most SaaS founders. Even if you think you are "just" using another company's AI, you may be reclassified as a provider — taking on all of Article 16's obligations — if any of these three conditions apply.
If you take GPT-4, Claude, or any other AI model/system and offer it to customers as your own product — even if the underlying model is made by another company — you are a provider of that AI system. The moment you brand it and sell it or offer it for free use, the provider obligations transfer to you. OpenAI's obligation is for their model; your obligation is for your product that uses it.
If you take an AI system that was not originally intended for a high-risk use case and deploy it in a high-risk context, you become a provider for that deployment. The system provider's original conformity assessment does not cover your new use case.
Fine-tuning, retraining, altering risk controls, or deploying in a new domain not covered by the original technical documentation can all constitute substantial modification. If you substantially modify a high-risk AI system, you inherit full provider obligations regardless of who built the base model.
These apply only if your system is classified as high-risk. Providers of limited-risk AI systems have transparency obligations (Article 50) but do not go through conformity assessment. Providers of minimal-risk systems have no product-level obligations (though the company still has the Article 4 AI literacy obligation as an employer).
Verify your system meets the AI Act's requirements before placing it on the market. For most Annex III systems, this is an internal process — you can do it yourself without a third-party body. Exception: biometric identification (Annex III Section 1) requires a notified body.
A standardised document covering: system architecture and design choices, training data and methodology, accuracy and robustness benchmarks, risk management approach, human oversight mechanisms, and the intended use context. Must be kept up to date and available to authorities on request.
Documented processes covering: your regulatory compliance strategy, development procedures, data governance, change management, risk management, post-market monitoring, customer support, and how you handle incidents. Proportionate to the size of your organisation.
Affix the CE conformity marking before placing the system on the market. This follows the conformity assessment. For AI systems embedded in regulated products (medical devices, machinery), the AI Act CE marking is part of the existing product regulation's conformity process.
Before placing a high-risk Annex III AI system on the market, register it in the public EU AI database. Exceptions: Annex III Section 2 (critical infrastructure) and Section 8 (law enforcement/migration) systems are registered by deployers/authorities, not providers.
Establish a plan and system to actively monitor your AI system's performance after deployment. Collect and analyse data on how the system performs in real-world conditions. Update your technical documentation and risk management when issues are found.
If your AI system causes or contributes to a "serious incident" — death, serious harm, fundamental rights violations, or significant disruptions to critical infrastructure — report it to the national competent authority. Timeframes: within 15 days of becoming aware for deaths, 10 days for other serious harm.
Annex IV specifies 10 sections. For a startup, the most labour-intensive parts are the data governance section (§9) and the accuracy benchmark section (§10). Budget 40–80 hours the first time; subsequent updates are lighter.
| Section | Content required |
|---|---|
| §1–2 | General description: trade name, version number, intended purpose, and use contexts |
| §3 | Detailed description: system architecture, design choices, key algorithms, and the role of each component |
| §4 | Monitoring, functioning, and control details: human oversight interface, logging capabilities, limitations |
| §5 | Risk management documentation: identified risks, risk control measures, and residual risk assessment |
| §6 | Description of any change throughout the system's lifecycle |
| §7 | Post-market monitoring plan: what you will track, how often, and what triggers an update |
| §8 | Declaration of conformity (reference to the signed document) |
| §9 | Data governance: training dataset description, data selection and labelling approach, bias assessment |
| §10 | Performance metrics: accuracy, robustness, and cybersecurity benchmark results |
For most Annex III AI systems, there is no mandatory pre-market third-party audit. National competent authorities can request it at any time. In practice, you need to have documentation that would satisfy a regulator if asked — not documentation that was approved before launch. This means a well-organised internal document is sufficient, but it must be complete, accurate, and current.
Find the scenario closest to your situation. Use the classifier to get a precise classification for your specific implementation.
AI literacy training (Article 4), prohibited practices check. No provider obligations.
Article 50 chatbot disclosure — identify as AI at start of every conversation. No conformity assessment required for limited-risk.
You placed an AI system on the market under your name. If the underlying AI task is high-risk (hiring, credit, healthcare), you have full provider obligations. If not high-risk, limited-risk transparency obligations only.
This is the most common SaaS blind spot. Many founders assume they are "just" using OpenAI's API as a deployer — but if you are selling the AI-powered output as a product, you are a provider.
Fine-tuning or training constitutes developing an AI system. You are unambiguously a provider. If the system is high-risk, full Article 16 provider obligations apply.
All 7 provider obligations: conformity assessment, technical documentation, QMS, CE marking, EU database registration, post-market monitoring, incident reporting.
This is the highest-scrutiny SaaS category. Employment AI is explicitly named in Annex III and is the area where regulators have the clearest enforcement basis.
All 7 provider obligations. Annex III Section 5(b) explicitly covers creditworthiness assessment and credit scoring AI.
Deployer obligations only (Article 26): use as intended, human oversight, FRIA, log retention, inform affected individuals. No conformity assessment — that is the provider's job.
For the majority of high-risk AI systems in Annex III, Article 43 allows self-assessment — no notified body required. The process has five steps.
With 48 days to August 2, 2026, this is the fastest compliant path for a tech company with an AI product.
List every AI system your company interacts with. For each one, ask: did we build this and put it on the market, or are we using something someone else built? Internal AI tools where you are a user are deployer scenarios. AI features in your product are (almost certainly) provider scenarios.
Use the classifier to determine whether each of your products is Prohibited, High-Risk, Limited Risk, or Minimal Risk. This determines which set of provider obligations applies. High-risk triggers conformity assessment; limited-risk triggers transparency obligations only.
Open the risk classifierFor most Annex III systems, this is an internal process: work through the Article 9 risk management requirements, prepare your technical documentation (Annex IV), ensure your quality management system (Article 17) is documented, and draw up an EU Declaration of Conformity. Third-party notified body involvement is only required for Annex III Section 1 (biometric identification) and Annex I safety-critical regulated products.
Annex IV specifies what goes in. At minimum: intended purpose, system architecture, training methodology and datasets, accuracy and robustness test results, risk management documentation, human oversight mechanisms, and a post-market monitoring plan. This document must be kept up to date and made available to national competent authorities on request.
Before placing a high-risk Annex III system on the market, register it at the EU AI Office's database. After conformity assessment, affix the CE marking. For systems in Annex I regulated products (medical devices, machinery), the AI Act CE marking integrates into those regulations' existing CE process.
The EU AI Act has a separate obligations framework for General-Purpose AI (GPAI) model providers under Articles 51–56. If you have trained a model from scratch or fine-tuned a model to a significant degree and offer it via API or publicly, you may also be subject to GPAI obligations in addition to the high-risk AI system obligations.
It depends on what the product does and who it serves. If you are using GPT-4 to add an AI writing assistant to your internal tooling, you are likely a deployer. If you are selling a product that uses GPT-4 to do something that falls under Annex III — such as screening job applicants, assessing creditworthiness, or making decisions about access to services — and you are placing that product on the market under your company name, you are a provider of a high-risk AI system under Article 28(1)(a). The critical question is: are you putting a high-risk AI capability on the market under your own brand? If yes, you are a provider and the full Article 16 obligations apply.
Yes. Fine-tuning a model with your own data and deploying it constitutes developing an AI system and places it on the market under your name. You are a provider. The underlying model provider (Meta for Llama, Mistral, etc.) is not responsible for the compliance of your fine-tuned version — that responsibility transfers to you entirely. This is one of the most important things for AI-native startups to understand: using another company's base model does not shield you from provider obligations if you modify and deploy it.
Article 3(23) defines substantial modification as a change that affects the compliance of an AI system or results in a change to the intended purpose for which the AI system has been assessed. A change is not substantial if it was anticipated and covered in the original technical documentation. In practice: changing the fine-tuning, retraining on new datasets, altering the risk management controls, or deploying the system in a new high-risk context (even without code changes) can all constitute substantial modification. Changing only the UI, updating documentation, or making adjustments explicitly described in the original technical documentation does not.
Yes. The EU AI Act applies based on what the AI system does and who it ultimately affects, not on whether the sale is B2B or B2C. If your B2B enterprise customer uses your AI system to make decisions affecting their employees (HR AI), their customers (credit AI, access to services), or individuals in high-risk sectors (healthcare, education), the Act still applies. In B2B contexts, Article 25 is also important: distributors and importers have their own obligations, and the chain of responsibility must be documented.
If you are placing an AI system on the market (including in beta, as a free product, or in a proof-of-concept), you are already subject to the obligations for the appropriate risk level. There is no revenue threshold or size exemption for providers — only the SME fine proportionality provision (Article 99(6)) exists, and that affects enforcement of fines, not the existence of the obligation. That said, regulatory sandboxes (Articles 57–63) exist specifically for startups and SMEs — they let you test and validate AI systems with regulatory supervision before full market launch, and they provide real guidance from national authorities.
Yes, if your product has customers or users in the EU or if your AI system's outputs are used within the EU. The Act has extraterritorial scope — it applies to providers outside the EU whose systems are deployed in or affect EU residents. UK AI regulation (currently developing under DSIT) takes a lighter-touch principles-based approach, but it does not override EU AI Act obligations for EU-facing activities. A UK SaaS company with EU customers selling an AI system that falls under Annex III must comply with the EU AI Act provider obligations for that product.
Use the free risk classifier to determine whether the AI features in your product are minimal-risk, limited-risk, or high-risk — and get a specific list of your provider obligations.
Start the Free Assessment