Regingada
Playbook · AI Act

AI Act Role Quick-Check — five roles, one reversal trap

Deliverable · Source: Funk corpus (CELEX/ELI-anchored) · Status: 2026-08

Curated for orientation, produced with the Regingada deliverables pipeline. Not legal advice, not a legal assessment of your case.

  • Art. 3 · definitions
  • Art. 22 · 23 · 24 · 26
  • Art. 25 · role reversal
Why the role comes first

Nearly every duty hangs on the role

In the architecture of the AI Act almost every obligation hangs on the role. Before anyone asks which article applies, the question is which position in the chain a company occupies — and that position follows from behaviour, not from self-description.

A company that calls itself a user can be a provider. A company that calls itself a reseller can be an importer. The vocabulary of the contract does not decide it; what decides it is who develops, who places on the market under whose name, who deploys under whose authority, and who brings a third-country system across the border. This playbook lays out the five roles, five questions that sort a profile into them, and the one provision that turns a deployer into a provider overnight.

1 · Role matrix

Five roles, five duty sets

The definitions sit in Art. 3, the duty sets in the chapters that follow. The matrix is a reading aid, not a classification of your company.

Roles under the AI Act

Role and definition Core duties Typical case
Provider (Art. 3(3): develops or has developed and places on the market or puts into service under its own name) Inter alia Art. 9–15 (high-risk requirements), Art. 16 et seq., Art. 43 conformity assessment, Art. 47/48 declaration and CE marking, Art. 49 registration, Art. 72/73 post-market Software house with its own AI product
Deployer (Art. 3(4): uses an AI system under its own authority in a professional capacity) Art. 26 deployer duties (use in accordance with the instructions, oversight, logs, information to workers), where applicable Art. 27 FRIA Company deploying a bought-in HR tool
Importer (Art. 3(6)) Art. 23: verify conformity before placing on the market, marking, record-keeping EU company bringing a third-country system into the Union
Distributor (Art. 3(7)) Art. 24: due care along the chain, none of the provider's own conformity duties Reseller with no own brand on the product
Authorised representative (Art. 3(5)) Art. 22: written mandate for non-EU providers (see Representative Compass) EU representation of a non-EU provider

Roles can coexist in one company and can differ per product line. Which role a concrete company holds for a concrete system is an assessment — and that is a mandate.

2 · Five quick questions

Sorting a profile in five steps

Each question carries one line of answer logic. Several answers can be yes at once; that is not a contradiction, it is a stack of roles.

  1. Are you placing an AI system on the market under your own name or trademark?

    → Provider track.

  2. Are you using third-party AI professionally, under your own authority?

    → Deployer track.

  3. Established outside the EU, market inside the EU?

    → Additionally a designation under Art. 22/54.

  4. Is your system a general-purpose AI model?

    → GPAI track (Art. 51 et seq.) instead of, or alongside, Annex III.

  5. Does the intended purpose fall under Annex III (inter alia employment, creditworthiness, critical infrastructure)?

    → High-risk requirements.

3 · The reversal trap (Art. 25)

When a deployer becomes a provider

A deployer becomes a provider where it puts a high-risk system on the market under its own name or trademark, modifies it substantially, or changes the intended purpose so that the system becomes high-risk. The full provider duty catalogue then travels with it — and nobody has budgeted for that retroactively.

This is the provision that turns a procurement decision into a development project. Whether a given change is substantial within the meaning of Art. 25 is a legal question, not a product-management one.

4 · Temporal application

Deliberately no date table

The AI Act applies in stages between 2025 and 2027, and individual stages have moved. This playbook deliberately prints no date table — the current state lives in the Regingada Radar and in the twin, where it is maintained, not frozen.

5 · Step 2

Where the software stops

Everything above is orientation: a reading of the role architecture, drawn from a public corpus and readable back to its sources. It is structured self-assessment and decision support — it is not an evaluation of a specific company, and it is not legal advice.

The assessment is the second step, and it belongs to the law firm Theo Funk under a separate mandate: which role holds for which product line, whether a modification is substantial, what a mandate under Art. 22 has to say. Regingada UG (haftungsbeschränkt) builds the software and takes on appointed EU-representative functions; the firm does the legal work. The two are strictly separated.

Get this playbook by e-mail

We send this playbook once to the address below — as a document, no list, no follow-up. Fastest path stays Save as PDF above.

One-off use: we use your address to answer this request and for nothing else — no list, no marketing. Transmission details and your rights: privacy policy.

Disclaimer

Orientation, not legal advice

This playbook 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.