Provider vs deployer under the AI Act
This guide decides which role an organisation holds for one AI system under Regulation (EU) 2024/1689 and maps the duties of that role: the provider set in Art. 16 against the deployer set in Art. 26, with the Art. 25(1) triggers that move a deployer into the provider role. The sequence is steps 8 to 11 of PR-CLS v1.0, and the reading of intended purpose comes from Commission guidelines on high-risk classificationDraft. At the end the reader holds a role determination record, an Art. 25 trigger record, a duty crosswalk and an obligation register.
What the obligation asks for
Art. 3(3) of Regulation (EU) 2024/1689 defines the provider as the natural or legal person, public authority, agency or other body that develops an AI system or a general-purpose AI model, 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. Art. 3(4) defines the deployer as the natural or legal person, public authority, agency or other body that uses an AI system under its authority, except where the use is in the course of a personal non-professional activity. The two definitions turn on different facts: the provider test asks who supplies the system under whose name, and the deployer test asks who uses it under whose authority. One organisation holds both roles where it builds a system and uses it, and Art. 25(1) moves a deployer into the provider role of a high-risk system on three triggers. For a system classified under Art. 6(2), both role sets apply from the Annex III application date Deferred; the regulation entry states that Regulation (EU) 2026/1744 amended Art. 113(c) and left the obligations unchanged in content, and the Art. 26 obligation record states that the Omnibus did not change the content of Art. 26.
On the provider side, Art. 16(a) to (l) lists the duties: a system that meets the requirements of Chapter III Section 2, identification on the system or its documentation, a quality management system under Art. 17, document keeping under Art. 18, log keeping under Art. 19, conformity assessment under Art. 43, the EU declaration of conformity under Art. 47, CE marking under Art. 48, registration under Art. 49(1), corrective action under Art. 20, demonstration of conformity on a reasoned request, and accessibility. On the deployer side, the Art. 26 record splits the twelve paragraphs into eight testable elements, eight documents and eleven process elements. This guide covers one testable element of that record by name: the deployed configuration, the input types and the use cases fall within the intended purpose and the conditions of use stated in the provider's instructions for use (Art. 26(1)). The instructions for use that Art. 13(3) requires the provider to supply are the document that passes from one role to the other, and the role determination decides which side of that document an organisation stands on. The role determination itself is the testable element of PR-CLS v1.0 for Art. 3(3), 3(4) and 25(1): each definition is tested against the organisation's relation to the system, and each trigger is checked.
Inputs
The inputs are the subset of the PR-CLS v1.0 input table that steps 8 to 11 read, plus two records the trigger check needs. The full table is on the protocol page.
- The intended-purpose statement, the instructions for use, the marketing materials and the terms of service for the system, one entry per material.
- The contract or licence under which the system was built, bought or licensed, with the name and trademark that appear on the system as supplied to its users.
- The modification log: every change made to the system after it was placed on the market or put into service, with the date of each change relative to the system version and who made it.
- The function inventory: each function with its inputs, its outputs and the natural persons it affects.
- The place of establishment of the organisation and the location where the output of the system is used.
- The regulation entry id for each application date the obligation register will carry, from the regulation data.
Procedure
The procedure is a decision sequence. Each step names the protocol step or the article it derives from and the record it produces. Three of the steps, 3, 4 and 5, encode the same decision that the risk classifier takes as an answer: the tool accepts the role under Art. 3(3) to 3(8) and Art. 25(3) as the organisation reports it, and the tool page states that it does not assess the Art. 25(1) triggers, so steps 6 and 7 below add that check as PR-CLS v1.0 step 10 runs it. The mapping table and the code blocks follow the steps. Every name, version, path and answer in the examples is synthetic.
Record the system name, its version, the provider named on it and the organisation's relation to the system.
Record System identification record: name, version, named provider, the organisation's relation to the system
[AIAssuranceLabs procedure; PR-CLS step 1]
Collect the intended-purpose statement, the instructions for use, the contract or licence and the marketing materials.
Record Intended-purpose evidence set with one entry per material
[Commission guidelines on high-risk classification, draft, general principles, para. 12 on intended purpose; PR-CLS step 2]
Test whether the organisation develops the system, or has it developed, and supplies it under its own name or trademark.
Record Role determination record, provider test: develops or has developed, own name or trademark, placing on the market or putting into service
[Regulation (EU) 2024/1689, Art. 3(3); PR-CLS step 8]
Test whether the system is a safety component of an Annex I Section A product supplied under the organisation's name.
Record Role determination record, product manufacturer test: (a) safety component placed on the market together with the product under the manufacturer's name or trademark, or (b) put into service under that name after the product was placed on the market
[Regulation (EU) 2024/1689, Art. 25(3)(a) and (b)]
Test whether the organisation uses the system under its own authority outside a personal non-professional activity.
Record Role determination record, deployer test: use under own authority, outside a personal non-professional activity
[Regulation (EU) 2024/1689, Art. 3(4); PR-CLS step 9]
Check each Art. 25(1) trigger: own name or trademark on the system, substantial modification, change of intended purpose.
Record Art. 25 trigger record, one row per trigger: present or absent, with the evidence
[Regulation (EU) 2024/1689, Art. 25(1)(a) to (c) and Art. 3(23); PR-CLS step 10]
Where a trigger is present, record what the initial provider supplied under Art. 25(2) and any exclusion it specified.
Record Initial provider cooperation record under Art. 25(2): (a) technical documentation sufficient to assess the system against Art. 16, (b) known limitations and failure modes, (c) targeted technical access including for testing and validation, or the exclusion the initial provider specified
[Regulation (EU) 2024/1689, Art. 25(2)]
Record the place of establishment and whether the output of the system is used in the Union.
Record Territorial scope record: place of establishment, placing on the Union market, output used in the Union
[Regulation (EU) 2024/1689, Art. 2(1)(a) to (c); PR-CLS step 11]
Assign Art. 16 to each provider role, Art. 26 to each deployer role, and Art. 27 to Art. 27(1) deployers.
Record Obligation register: one row per article per role, with the regulation entry id per date
[Regulation (EU) 2024/1689, Art. 16(a) to (l), Art. 26(1) to (12), Art. 27(1); PR-CLS step 39]
Check that each Art. 13(3) item is present in the instructions for use the deployer holds.
Record Instructions-for-use handover check: one row per Art. 13(3) item, present or absent in the copy the deployer holds
[Regulation (EU) 2024/1689, Art. 13(3)(a) to (f); PR-CLS step 41, hand-off to PR-14-OVR step 9]
Record the justification for each open judgement, such as whether a modification is substantial under Art. 3(23).
Record Determination rationale record, one entry per open judgement
[PR-CLS step 40]
Write the role determination report and mark each determination as a technical assessment for discussion with counsel.
Record Classification and role determination report with the counsel note on each determination
[PR-CLS steps 42 and 43]
Example for step 9. The table maps each duty to the article that places it on each role. A cell that reads "no duty" means the Act places nothing on that role for that row; a duty that both roles carry appears on both sides with its own article. The Art. 26 paragraph references follow the obligation record; the Art. 16 references follow the article text.
| Duty | Provider side | Deployer side |
|---|---|---|
| Definition of the role | Art. 3(3): develops the system or has it developed, and places it on the market or puts it into service under its own name or trademark | Art. 3(4): uses the system under its authority, outside a personal non-professional activity |
| Requirements of Chapter III Section 2 (Art. 8 to 15) | Art. 16(a): the provider makes sure that the system meets the requirements of Section 2 | No duty; Art. 26(1) places on the deployer the use of the system in accordance with the instructions for use |
| Identification | Art. 16(b): name, registered trade name or trademark and contact address on the system, its packaging or its documentation | No duty |
| Quality management system | Art. 16(c) with Art. 17: a quality management system that covers the elements in Art. 17(1) | No duty; Art. 26(1) places on the deployer appropriate technical and organisational measures for use per the instructions |
| Document keeping | Art. 16(d) with Art. 18: the technical documentation, the QMS documentation, the approvals and decisions of notified bodies, the EU declaration of conformity, kept for ten years after placing on the market or putting into service | No article names a retention period; the Art. 26 record lists the instructions for use received from the provider as a documentation element under Art. 26(1) |
| Logs | Art. 16(e) with Art. 19: the logs automatically generated by the system, to the extent they are under the provider's control, kept for at least six months unless Union or national law provides otherwise | Art. 26(6): the logs automatically generated by the system, to the extent they are under the deployer's control, kept for at least six months unless Union or national law provides otherwise |
| Conformity assessment | Art. 16(f) with Art. 43: the conformity assessment procedure before placing on the market or putting into service | No duty |
| EU declaration of conformity and CE marking | Art. 16(g) with Art. 47 and Art. 16(h) with Art. 48 | No duty |
| Registration | Art. 16(i) with Art. 49(1): the provider or its authorised representative registers itself and the system in the EU database before placing on the market; Art. 49(2) for a system the provider concluded is not high-risk under Art. 6(3) | Art. 26(8) with Art. 49(3): a deployer that is a public authority or a Union institution, body, office or agency or a person acting on their behalf, registers itself, selects the system and registers its use before use; a private deployer not acting on behalf of a public authority has no registration duty under Art. 49(3) |
| Corrective action and information | Art. 16(j) with Art. 20: corrective action on a system the provider considers not in conformity, and information to distributors, deployers, the authorised representative and importers | Art. 26(5): monitoring on the basis of the instructions for use, information to the provider or distributor and the market surveillance authority on a risk under Art. 79(1), suspension of use, and serious incident reporting with Art. 73 where the provider cannot be reached |
| Demonstration to an authority | Art. 16(k): on a reasoned request of a national competent authority, demonstration that the system meets the requirements of Section 2 | Art. 26(12): cooperation with the competent authorities in any action they take in relation to the system |
| Accessibility | Art. 16(l): accessibility requirements under Directives (EU) 2016/2102 and (EU) 2019/882 | No duty |
| Human oversight | Art. 14: the system is designed so that natural persons can oversee it, with the measures identified by the provider under Art. 14(3)(a) and (b) and stated in the instructions under Art. 13(3)(d) | Art. 26(2) with Art. 26(3): human oversight assigned to natural persons with competence, training, authority and support, with the deployer free to organise its own resources to implement the measures the provider indicated |
| Data | Art. 10: training, validation and testing data governance | Art. 26(4): input data relevant and sufficiently representative for the intended purpose, to the extent the deployer controls it |
| Instructions for use | Art. 13(2) and 13(3): instructions for use drawn up and supplied with the system, with the items in Art. 13(3)(a) to (f) | Art. 26(1): use in accordance with the instructions; Art. 26(9): the Art. 13 information used for the data protection impact assessment |
| Worker information | No duty | Art. 26(7): information to workers' representatives and affected workers before use at the workplace |
| Notice to natural persons | No duty | Art. 26(11): information to natural persons that they are subject to the use of the system, for an Annex III system that makes or assists decisions about them |
| Fundamental rights impact assessment | No duty | Art. 27(1): for a body governed by public law, a private entity providing public services, or a deployer of an Annex III point 5(b) or 5(c) system |
| Post-market monitoring | Art. 72: a post-market monitoring system and plan | Art. 26(5): monitoring of the operation on the basis of the instructions for use |
| Change of role | Art. 25(2): after a trigger, the initial provider cooperates with the new provider and supplies the technical documentation to assess the system against Art. 16, the known limitations and failure modes, and targeted technical access including for testing and validation, unless it specified that the system is not to be changed into a high-risk system | Art. 25(1)(a) to (c): the deployer becomes the provider on its own name or trademark on the system, a substantial modification, or a change of intended purpose that makes the system high-risk |
| AI literacy | Art. 4: measures for the AI literacy of staff and other persons operating the system on the provider's behalf | Art. 4: the same duty, for staff and other persons operating the system on the deployer's behalf |
The same mapping as a machine-readable crosswalk. The file keeps one entry per row of the table, with a side value of provider, deployer or both, the article on each side, and the protocol that tests the element where one exists on this site. The entry value is the regulation entry id, so the date resolves from the regulation data when the file is read and no date is typed into the crosswalk. The file is synthetic; the article references are the ones in the table.
# Synthetic example: duty crosswalk for one Annex III high-risk system, one entry per table row.
system: demo-system 2.4.0
entry: annex-iii-high-risk
duties:
- id: X-01
duty: definition of the role
side: both
provider: Art. 3(3)
deployer: Art. 3(4)
tested_by: [PR-CLS]
- id: X-02
duty: requirements of Chapter III Section 2
side: provider
provider: Art. 16(a)
deployer: null
tested_by: [PR-15-ROB, PR-10-BIAS, PR-12-LOG, PR-14-OVR, PR-11-DOC]
- id: X-03
duty: identification
side: provider
provider: Art. 16(b)
deployer: null
tested_by: [PR-11-DOC]
- id: X-04
duty: quality management system
side: provider
provider: Art. 16(c), Art. 17
deployer: null
tested_by: [PR-17-QMS]
- id: X-05
duty: document keeping
side: provider
provider: Art. 16(d), Art. 18
deployer: null
tested_by: [PR-11-DOC]
- id: X-06
duty: logs
side: both
provider: Art. 16(e), Art. 19
deployer: Art. 26(6)
tested_by: [PR-12-LOG]
- id: X-07
duty: conformity assessment
side: provider
provider: Art. 16(f), Art. 43
deployer: null
tested_by: [PR-43-MOCK]
- id: X-08
duty: EU declaration of conformity and CE marking
side: provider
provider: Art. 16(g), Art. 47, Art. 16(h), Art. 48
deployer: null
tested_by: [PR-43-MOCK]
- id: X-09
duty: registration
side: both
provider: Art. 16(i), Art. 49(1), Art. 49(2)
deployer: Art. 26(8), Art. 49(3)
deployer_condition: public authority, Union institution, body, office or agency, or a person acting on their behalf
tested_by: [PR-CLS]
- id: X-10
duty: corrective action and information
side: both
provider: Art. 16(j), Art. 20
deployer: Art. 26(5)
tested_by: [PR-17-QMS, PR-14-OVR]
- id: X-11
duty: demonstration to an authority
side: both
provider: Art. 16(k)
deployer: Art. 26(12)
tested_by: [PR-43-MOCK]
- id: X-12
duty: accessibility
side: provider
provider: Art. 16(l)
deployer: null
tested_by: []
- id: X-13
duty: human oversight
side: both
provider: Art. 14, Art. 13(3)(d)
deployer: Art. 26(2), Art. 26(3)
tested_by: [PR-14-OVR]
- id: X-14
duty: data
side: both
provider: Art. 10
deployer: Art. 26(4)
tested_by: [PR-10-BIAS]
- id: X-15
duty: instructions for use
side: both
provider: Art. 13(2), Art. 13(3)
deployer: Art. 26(1), Art. 26(9)
tested_by: [PR-11-DOC, PR-14-OVR]
- id: X-16
duty: worker information
side: deployer
provider: null
deployer: Art. 26(7)
tested_by: []
- id: X-17
duty: notice to natural persons
side: deployer
provider: null
deployer: Art. 26(11)
tested_by: []
- id: X-18
duty: fundamental rights impact assessment
side: deployer
provider: null
deployer: Art. 27(1)
deployer_condition: body governed by public law, private entity providing public services, or Annex III point 5(b) or 5(c) system
tested_by: [PR-27-FRIA]
- id: X-19
duty: post-market monitoring
side: both
provider: Art. 72
deployer: Art. 26(5)
tested_by: [PR-17-QMS]
- id: X-20
duty: change of role
side: both
provider: Art. 25(2)
deployer: Art. 25(1)(a) to (c)
tested_by: [PR-CLS]
- id: X-21
duty: AI literacy
side: both
provider: Art. 4
deployer: Art. 4
tested_by: []
Example for steps 3 to 7. The function below encodes the decision sequence: the Art. 3(3) provider test, the Art. 25(3) product manufacturer test, the Art. 3(4) deployer test and the three Art. 25(1) triggers. The answers are synthetic and describe an organisation that licensed a recruitment screening system, put its own brand on the candidate-facing interface and changed nothing else; the function returns both roles, with the trigger that produced the second one, so that the register in step 9 carries Art. 16 and Art. 26 for the same system. The function agrees with the role question of the classifier for the first three tests and adds the trigger check the classifier leaves out.
# Synthetic example: role decision for one AI system under Art. 3(3), 3(4), 25(1) and 25(3).
from dataclasses import dataclass, field
@dataclass
class Answers:
develops_or_has_developed: bool
supplies_under_own_name_or_trademark: bool
safety_component_of_annex_i_a_product_under_own_name: bool
uses_under_own_authority: bool
personal_non_professional_use: bool
system_is_high_risk_on_the_market: bool
own_name_or_trademark_put_on_system: bool # Art. 25(1)(a)
substantial_modification_art_3_23: bool # Art. 25(1)(b)
intended_purpose_changed_to_high_risk: bool # Art. 25(1)(c)
notes: list = field(default_factory=list)
def roles(a: Answers) -> dict:
out = {"roles": [], "triggers": []}
if a.develops_or_has_developed and a.supplies_under_own_name_or_trademark:
out["roles"].append("provider (Art. 3(3))")
if a.safety_component_of_annex_i_a_product_under_own_name:
out["roles"].append("provider as product manufacturer (Art. 25(3))")
if a.uses_under_own_authority and not a.personal_non_professional_use:
out["roles"].append("deployer (Art. 3(4))")
if "deployer (Art. 3(4))" in out["roles"]:
if a.system_is_high_risk_on_the_market and a.own_name_or_trademark_put_on_system:
out["triggers"].append("Art. 25(1)(a)")
if a.system_is_high_risk_on_the_market and a.substantial_modification_art_3_23:
out["triggers"].append("Art. 25(1)(b)")
if a.intended_purpose_changed_to_high_risk:
out["triggers"].append("Art. 25(1)(c)")
if out["triggers"]:
out["roles"].append("provider by Art. 25(1); Art. 16 applies; initial provider owes Art. 25(2)")
return out
answers = Answers(
develops_or_has_developed=False,
supplies_under_own_name_or_trademark=False,
safety_component_of_annex_i_a_product_under_own_name=False,
uses_under_own_authority=True,
personal_non_professional_use=False,
system_is_high_risk_on_the_market=True, # Annex III point 4(a), recruitment
own_name_or_trademark_put_on_system=True, # own brand on the candidate-facing interface
substantial_modification_art_3_23=False,
intended_purpose_changed_to_high_risk=False,
)
print(roles(answers))
# {'roles': ['deployer (Art. 3(4))', 'provider by Art. 25(1); Art. 16 applies; initial provider owes Art. 25(2)'],
# 'triggers': ['Art. 25(1)(a)']}
The output is a record for step 6 and step 9, not a legal conclusion: Art. 25(1)(a) reads "without prejudice to contractual arrangements stipulating that the obligations are otherwise allocated", and the function does not read contracts. Step 11 records the contract clause and the justification as an open judgement for counsel.
A pitfall that vendor documentation omits
Provider documentation and procurement material present Art. 26 as the customer's part of the Act and stop there, and the deployer reads the provider's declarations as covering the rest. Three seams in the Act fall between the roles, and each one has an article on each side. The first is the log seam. Art. 19(1) places log keeping on the provider "to the extent such logs are under their control", and Art. 26(6) places it on the deployer with the same words; in a hosted deployment the logs sit on the provider's platform, and the deployer holds the Art. 26(6) duty only for the logs it controls, which can be none. Art. 13(3)(f) closes the seam from the provider side: the instructions for use describe, where relevant, the mechanisms that allow the deployer to collect, store and interpret the logs under Art. 12. The Art. 26 record names the result of a missed seam as a common finding: logs are generated on the provider's platform and the retention period for the logs under the deployer's control is unknown or shorter than the period in Art. 26(6). The log completeness guide runs the reconstruction check on whichever side holds the logs.
The second seam is human oversight. Art. 14(3) places the design of the oversight measures on the provider, either built into the system under Art. 14(3)(a) or identified for the deployer to implement under Art. 14(3)(b), and Art. 13(3)(d) places their description in the instructions for use; Art. 26(2) places the assignment of persons with competence, training, authority and support on the deployer, and Art. 26(3) leaves the deployer free to organise its own resources to implement them. A provider that treats oversight as the deployer's matter leaves the Art. 14(3)(b) measures unidentified, and a deployer that treats it as the provider's matter assigns nobody who can act; the Art. 26 record names the results as common findings, oversight assigned on an organisation chart without a record of competence, training or authority, and a stop or override function that exists in the provider's product but is not reachable by the assigned overseer in the deployed configuration. The override testing guide exercises the measures from the assigned person's account. The third seam is the name on the system. Art. 25(1)(a) turns a deployer that puts its own name or trademark on a high-risk system already on the market into its provider, and Art. 25(2) reduces the initial provider's duty to cooperation: technical documentation, known limitations and failure modes, and targeted technical access. A white-labelled deployment moves Art. 16(a) to (l), including the conformity assessment under Art. 43 and the registration under Art. 49(1), to the organisation that thought it held Art. 26 alone; the contract clause that Art. 25(1)(a) allows to allocate the obligations otherwise is the record step 7 asks for.
Regulation (EU) 2024/1689 sets no numeric threshold for any decision in this guide, and no published document sets one for the role tests. The hierarchy is the one the protocol page states: no harmonised standard is cited in the Official Journal as of the anchor date, so no presumption of conformity attaches to any role determination; no JTC 21 draft covers role determination, so the second and third levels are empty; the reading of intended purpose, which decides the Art. 25(1)(c) trigger, comes from Commission guidelines on high-risk classificationDraft on the standards page, a draft under consultation; the content of the instructions for use that pass between the roles is the subject of prEN 18229-3Draft, a JTC 21 draft with no public text; and whether a modification is substantial under Art. 3(23) is the organisation's justified judgement, recorded at step 11.
What the result shows and what it does not
The result shows which Art. 3 definition fits the organisation's relation to the system, whether an Art. 25(1) trigger is present on the evidence collected, and which article set the register carries for each role. It does not give a legal opinion on the role: the protocol's limitations section states that a market surveillance authority, the AI Office or a court can reach a different result, and that a final version of the draft classification guidelines can change a recorded result, which the revision history of PR-CLS v1.0 then records. The trigger check reads the modification log and the materials supplied; a modification not in the log, or a contractual allocation under Art. 25(1)(a) that was not produced, is outside the result. The handover check in step 10 shows that each Art. 13(3) item is present in the copy the deployer holds; whether the content of each item is correct is tested under PR-11-DOC v1.0 and PR-14-OVR v1.0. The result is evidence for the organisation's own file, and the decision on role remains with the provider or deployer and their counsel. The classification and readiness assessment service runs the sequence and delivers the classification memo and the obligation register, which follow the assessment memo and register specifications on the deliverables page; its scope limits are on what we cannot do. For a general-purpose AI model that an organisation has fine-tuned, the provider question is a separate determination under PR-CLS v1.0 step 27 within the GPAI evaluation support service.
Related pages
The deployer side of the same question, run as a sequence of Art. 26 checks after a purchase, is on the bought-a-high-risk-system scenario; the obligation, the protocol, the two related guides that test the log and oversight seams, and the hubs for the two roles are listed below, and every protocol on the site is on the methodology index.
- Obligations
- Protocols
- Related guides
- ICP hubs
Questions
What are the AI Act provider vs deployer obligations?
Art. 16 of Regulation (EU) 2024/1689 lists the provider duties: the requirements of Art. 8 to 15, a quality management system under Art. 17, logs under Art. 19, conformity assessment under Art. 43, CE marking under Art. 48 and registration under Art. 49(1). Art. 26 lists the deployer duties: use per the instructions for use, human oversight by assigned persons, monitoring and incident reporting, logs under its control, worker information and notice to natural persons. Art. 27 adds the fundamental rights impact assessment for the deployers it names.
Are we a provider or a deployer under the AI Act?
Under Art. 3(3) of Regulation (EU) 2024/1689 an organisation is the provider where it develops the system, or has it developed, and supplies it under its own name or trademark. Under Art. 3(4) it is the deployer where it uses the system under its own authority outside a personal non-professional activity. Under Art. 25(1) a deployer becomes the provider of a high-risk system on its own name or trademark on the system, a substantial modification, or a change of intended purpose that makes the system high-risk.
Every inquiry receives a reply within 24 hours. Scope and availability are discussed per request.