Module 1 of the AI Act Deployer certification: Art. 3(4), building the system inventory, classifying from the buyer's seat, and where the Art. 6(3) filter helps a deployer and where it cannot.
You cannot comply with obligations you have not identified, and you cannot identify them until you know which hat you are wearing for which system. This module is the sorting step. It is unglamorous and it is where most programmes go wrong, because they start from a list of vendors rather than a list of systems.
What makes you a deployer
Art. 3(4) is short: a deployer is a natural or legal person using an AI system under its own authority, except where the use is a purely personal, non-professional activity.
Two things follow that people miss.
"Under its own authority" is about control, not ownership. You do not need to own the system, host it, or have paid for it. A team using a free browser extension that summarises customer emails is deploying an AI system under the organisation's authority. So is a department that signed up to a SaaS trial without telling procurement.
The personal carve-out never applies to an organisation. It exists for an individual using AI in their private life. An employer, a public body, a charity, a sole trader acting professionally — all are deployers.
You are probably also a provider of something
Art. 3(3) defines the provider as whoever develops an AI system, or has one developed, and places it on the market or puts it into service under its own name or trademark — whether for payment or free of charge.
Read that last clause again. Putting a system into service for your own use makes you its provider. So an internal model built by your own data science team, never sold to anyone, has a provider: you. And because you also use it under your own authority, you are its deployer as well.
This is not a technicality. It decides whether the technical documentation of Annex IV is someone else's problem or yours.
| What you did | Provider? | Deployer? |
|---|---|---|
| Licensed a vendor system, used as sold | No | Yes |
| Licensed it, put your own brand on it | Yes (Art. 25) | Yes |
| Built it in-house for internal use | Yes | Yes |
| Built it and sold it to others | Yes | Only if you also use it |
| Resold a vendor system unchanged, under the vendor's brand | No — distributor (Art. 24) | No |
The inventory comes before the classification
The instinct is to start with the regulation and look for systems that match. Do the opposite. List what is actually running, then classify.
A workable inventory row records: the system, the business process it serves, who inside the organisation is accountable for it, the vendor and contract, whether outputs affect natural persons and how, whether personal data is processed, and — the field everyone forgets — the intended purpose as the vendor declares it, quoted from the instructions for use.
That last field is what lets you answer the Art. 25 question later, and it is the field you will not be able to fill in retrospectively without going back to the vendor.
Expect the inventory to surface systems nobody had listed: a recruitment screening add-on inside the ATS, a scoring feature switched on in a CRM, a transcription tool a team adopted on a company card. These are the ones that carry obligations, precisely because nobody assessed them.
Classification from the buyer's seat
The four tiers are the same whichever seat you sit in — that is Fundamentals. What changes is the order in which you should apply them, because a deployer's exposure is not evenly distributed.
First, Art. 5. A prohibited practice is not a compliance project, it is a stop. And two prohibitions catch ordinary corporate deployments far more often than people expect: inferring emotions in the workplace under Art. 5(1)(f), and untargeted scraping of facial images to build recognition databases. The Art. 5 band under Art. 99(3) is 35 million euro or 7% of worldwide turnover — the highest in the Regulation, and it applies to deployers, not only to providers.
Second, Art. 50. These duties are in force now, since 2 August 2026. They apply whatever the risk tier, and two of the four sit directly on the deployer. Most organisations owe something here today and owe nothing under Chapter III until December 2027.
Third, Annex III. Now check the high-risk list, and check the carve-outs before the categories:
- Point 1 covers remote biometric identification, but 1:1 verification against a document is excluded — the KYC selfie check is not caught.
- Point 5(b) covers creditworthiness and credit scoring, but AI used to detect financial fraud is excluded.
- Point 3 covers education and vocational training, including evaluating learning outcomes and monitoring prohibited behaviour during tests.
- Point 4 covers employment: recruitment, targeted job advertising, filtering applications, evaluating candidates, promotion and termination decisions, task allocation, and monitoring worker behaviour.
Fourth, everything else is minimal risk, and minimal risk means no mandatory obligation under this Regulation. It does not mean no obligation at all — the GDPR, sectoral law and your own contracts do not go away.
Where Art. 6(3) helps you, and where it cannot
Art. 6(3) lets an Annex III system be treated as not high-risk when it does not pose a significant risk of harm and meets one of four conditions: it performs a narrow procedural task; it improves the result of a previously completed human activity; it detects decision patterns without replacing or influencing human assessment; or it performs a preparatory task.
Two limits matter to a deployer.
The filter is the provider's to invoke. Art. 6(4) requires the provider claiming it to document the assessment before placing the system on the market and to register the system under Art. 49(2). If your vendor has relied on the derogation, that documentation exists and you should have a copy of it. If the vendor cannot produce it, the derogation has not actually been claimed.
Profiling voids it absolutely. Art. 6(3) states that a system is always high-risk where it performs profiling of natural persons. No condition survives that. If the system builds or applies a profile of a person to evaluate them, stop looking for a derogation.
Getting the determination on paper
For each system, write down: the tier you concluded, the Annex III point you checked and why it does or does not apply, the carve-out you relied on if any, who decided, and on what date against which text.
That last element is doing more work than it looks. The Digital Omnibus rewrote Article 4 and moved the Chapter III dates in July 2026. A determination that does not say which version of the law it was made against cannot be reviewed — it can only be redone.
Check yourself
- We only use AI internally, on our own staff. Are we in scope? — Yes. There is no internal-use exemption, and Annex III point 4 covers worker management specifically.
- Our data science team built a scoring model we never sold. Who is the provider? — You are. Art. 3(3) covers development for own use; you are simultaneously the deployer.
- Our KYC flow matches a selfie to a passport photo. Annex III point 1? — No. One-to-one verification against a document is excluded from the remote biometric identification category.
- The vendor says Art. 6(3) applies, so the system is not high-risk. — Ask for the Art. 6(4) documentation and the Art. 49(2) registration. If neither exists, the derogation has not been claimed, and if the system profiles natural persons it was never available.
Next: Module 2 — Article 26, paragraph by paragraph →
AI Act meets DORA and NIS2
Is your organisation subject to both the AI Act and DORA? The two regulations intersect on the operational resilience of financial AI systems. Our sister site regulation-dora.eu covers DORA in depth — including what the AI Act adds on top of an existing DORA programme.
The AI Act for financial institutions ↗ Explore regulation-dora.eu ↗Frequently Asked Questions
Routinely. If you build a system for your own internal use, you are its provider under Art. 3(3) — development for own use is inside the definition — and its deployer under Art. 3(4) because you use it under your own authority. Both obligation sets apply to the same organisation at the same time. Most in-house data science teams are in exactly this position without having noticed.
Yes. There is no internal-use exemption. The only personal carve-out in Art. 2 is for use by a natural person in a purely personal, non-professional activity, which an employer never satisfies. Annex III point 4 covers employment and worker management specifically, and Art. 5(1)(f) prohibits inferring emotions in the workplace outright.
The provider classifies, because classification follows the intended purpose the provider declares in the instructions for use. But the deployer lives with the consequences and must be able to defend its own reading, because using a system outside its declared intended purpose is an Art. 25 trigger that makes the deployer the provider. In practice you verify the vendor's classification rather than accept it.
Take compliance further with the AI Act Academy
A free course, a server-graded exam, a verifiable certificate — and the working templates.