AI providers — role first, duties second
An AI provider develops a system or a model and places it on the Union market under its own name. That one sentence decides more than any product feature, because the AI Act attaches its duties to roles rather than to companies, and the same code base can carry the provider role in one market act and the deployer role in another. Whether a system falls into the high-risk band depends on a listed use case in Annex III or on the product-safety route of Art. 6, not on how advanced the model is. A general-purpose model placed on the market runs on a separate strand with documentation duties of its own. Underneath all of it the GDPR keeps running: training data, evaluation data and output about individuals are personal data long before anyone calls the product AI.
- AI Act · provider track
- GDPR
- GPAI strand · only if a model is placed on the market
- NIS2 · only where a sector applies
- DSA · not activated by this profile
Sector profile for orientation. It describes what the norms provide for a role of this shape. Whether they reach a concrete company, and in which role, is a legal assessment and belongs to a mandate — not to a sector page.
What the provider role activates — and what it does not
The list below follows the order in which the questions actually arise: first the role, then the risk band, then the requirement catalogue, then conformity and market surveillance. The GPAI strand runs beside it, not inside it. Regimes that a provider role does not activate on its own stay out — a sector page that switches everything on is not orientation, it is noise.
Regime footprint
| Regime & norm | Why it applies | What to do first |
|---|---|---|
| AI Act · Art. 3 (roles) | The act defines provider, deployer, importer, distributor and authorised representative separately. Duties follow the role per system, not the company as a whole. | Record the role for each system in writing, including the cases where you are both provider and deployer of your own tool. |
| AI Act · Art. 6 and Annex III | The high-risk classification runs either through a product-safety route or through one of the listed use cases in Annex III. The band is decided by purpose, not by model size. | Test each system against Annex III and document the result with reasons — including a negative result, which is the harder one to defend later. |
| AI Act · Art. 9 to Art. 15 | The requirement catalogue for high-risk systems: risk management, data and data governance, technical documentation, record-keeping, transparency towards deployers, human oversight, accuracy, robustness and cybersecurity. | Build one gap list per article instead of one document per audit request; the articles are what the file has to answer to. |
| AI Act · Art. 16 ff., Art. 43, 47, 48, 49 | Provider obligations proper: quality management, conformity assessment, EU declaration of conformity, CE marking and registration in the EU database. | Decide the conformity route early — internal control or notified body — because it determines how much evidence has to exist before launch. |
| AI Act · Art. 72, Art. 73 | Post-market monitoring and the reporting of serious incidents keep running after launch. They are duties of the provider, and they have their own clock. | Name who may trigger an incident report, and where the evidence for it comes from, before the first incident. |
| AI Act · Art. 51 to Art. 56, Annex XI and XII | The GPAI strand addresses models, not systems: technical documentation, information to downstream providers, a copyright policy and a summary of training content; systemic risk adds further duties. | Settle first whether a model is placed on the market as a general-purpose model at all — that classification decides which of the two strands runs. |
| GDPR · Art. 6, Art. 9, Art. 22, Art. 35 | Training and evaluation data need a legal basis; special categories need Art. 9; automated decisions about individuals and impact assessments arise wherever the output touches people. | Document the legal basis for the training data before the next training round, not after the first supervisory-authority letter. |
| NIS2 · only where a sector applies | NIS2 attaches to sectors listed in its annexes and to size thresholds. Being an AI provider does not activate it; being, in addition, a cloud or managed-service provider may. | Check the sector and size classification first. Starting a NIS2 programme without that check is the most common way to spend a year on the wrong thing. |
Not activated by this profile on its own: the DSA, which addresses intermediary services, and the Data Act chapters on connected products. If a provider also runs a platform or ships connected hardware, those regimes arrive through that activity, not through the AI.
Three seams that cost coordination
-
Two Article 22s, one document set
Art. 22 GDPR governs automated individual decision-making. Art. 22 AI Act governs the authorised representative of a provider established outside the Union. The number is identical and the subject matter is unrelated, which is exactly why internal cross-references that name only the article and not the regime keep producing documents that cite the wrong rule. Two workstreams, kept apart on paper as well as in the head.
-
Data governance pulls where Art. 9 pushes back
Art. 10 AI Act asks for training, validation and test sets to be examined for bias, and a serious examination tends to want the very attributes that Art. 9 GDPR shields. The AI Act opens a narrow, conditioned door for exactly this purpose; the GDPR does not widen because the AI Act asked. The boundary has to be drawn while the dataset is being assembled, because afterwards it can only be documented, not chosen.
-
FRIA and DPIA live off the same facts
The fundamental-rights impact assessment under Art. 27 AI Act addresses certain deployers; the data protection impact assessment under Art. 35 GDPR addresses the controller. Different addressees, different tests — but both feed on the same factual basis, and both sets of facts come from the provider. Customers will ask for that input, and a provider who maintains it twice pays for the divergence a third time.
The full map of the seams, across all regimes: the collision map.
The appointment duty arrives before the product does
A provider established outside the Union that makes a high-risk AI system available on the Union market has to appoint an authorised representative under Art. 22 AI Act, by written mandate, before placing the system on the market. For general-purpose models the parallel duty sits in Art. 54. The two appointments have different triggers and are not interchangeable, and neither of them discharges the representative duty under Art. 27 GDPR.
Where the duties come from and how they stack: EU representation overview and the representative compass. Regingada UG (haftungsbeschränkt) takes on appointed representative functions; whether a concrete company owes one, and under which act, is a legal assessment in a separate mandate.
From a role answer to a working list
- Obligation cockpit, filtered by roleThe provider set for the risk band that actually applies, with deployer duties left out. Each entry carries its source node, so the list can be read back to the norm text instead of being trusted on faith.
- GPAI strand kept separateModel duties under Art. 51 ff. with Annex XI and XII sit on their own track. Merging them with an Annex III high-risk system is the classic mis-sale, and the twin refuses to make it.
- Collision mapThe seams between the AI Act and the GDPR shown as explicit connections — and the false friends shown as separated rather than linked, so an Art. 22 reference cannot silently change regime.
- Radar watchChange entries tagged to the profile rather than a general newsfeed: movement in the high-risk timetable, guidance on the GPAI strand, standardisation work. The radar reports the state of its watchlist with a date; it does not claim to be a live feed.
- Deliverables, marked DRAFTClassification memo, obligation register, gap report and an outline for the Annex IV documentation. Everything the suite produces is a DRAFT: no signature, no assessment, no liability. It becomes an assessment when the law firm Theo Funk takes it into a mandate and signs it off.
Where the software stops
Everything above is orientation: a map of what a role of this shape reaches in EU digital law, drawn from a public corpus and readable back to its sources. It is structured self-assessment and decision support, not an evaluation of a specific company and not legal advice. Whether the classification holds, how far the conformity assessment has to go and what the instructions for use must say is the second step and belongs to the law firm Theo Funk under a separate mandate. Regingada UG (haftungsbeschränkt) builds the software and takes on appointed EU-representative functions; the firm does the legal work.
Worked through on fictional demo profiles: a high-risk provider inside the EU and a GPAI provider outside it.
Orientation, not legal advice
This sector page and the suite provide orientation and information only. They are not legal advice. Individual-case advice is provided exclusively by the law firm Theo Funk under a separate mandate. Regingada UG (haftungsbeschränkt) — the software company and appointed EU representative — and the law firm are strictly separated.