Deployer of Provider? Waarom dit label uw AI-aansprakelijkheid volledig bepaalt

De EU AI Act is geen generieke wetgeving die voor iedere marktpartij gelijke verplichtingen oplegt. De regels, verantwoordelijkheden en sancties zijn volledig afhankelijk van de rol die uw organisatie inneemt in de AI-waardeketen. Toch zien we in de praktijk dat veel organisaties — van gemeenten tot middelgrote ondernemingen — geen helder antwoord hebben op de vraag: zijn wij een provider of een deployer?

Dat is geen onschuldige lacune. De juridische kwalificatie bepaalt niet alleen welk regime van verplichtingen op u van toepassing is, maar ook wanneer u — soms zonder het te beseffen — van rol wisselt en daarmee nieuwe, zware aansprakelijkheden op u neemt. In dit artikel ontleden we beide rollen, de bijbehorende verplichtingen, en het mechanisme waardoor een deployer onbedoeld provider wordt.

De juridische definities: waar de wet over spreekt

De EU AI Act hanteert twee kernbegrippen (Art. 3):

Een provider (in de Nederlandse vertaling: aanbieder) is een natuurlijke of rechtspersoon, overheidsinstantie, agentschap of ander orgaan dat een AI-systeem of een AI-model voor algemene doeleinden ontwikkelt of laat ontwikkelen, en dit systeem in de handel brengt of in gebruik neemt onder de eigen naam of het eigen merk — al dan niet tegen vergoeding.

Een deployer (in de Nederlandse vertaling: gebruiker of toepasser) is een natuurlijke of rechtspersoon, overheidsinstantie, agentschap of ander orgaan dat een AI-systeem onder eigen verantwoordelijkheid gebruikt — met uitzondering van gebruik in de persoonlijke, niet-professionele sfeer.

De meeste Nederlandse organisaties zijn deployer. Ze kopen AI-systemen in van commerciële aanbieders — Microsoft Copilot, een recruitment-SaaS, een creditscoringsmodel — en zetten die systemen in voor hun bedrijfsprocessen. Ze bouwen zelf niets. Dat is het klassieke deployer-profiel.

De Provider: de zwaarste compliance-lasten

Omdat de provider aan de oorsprong van de technologie staat, legt de AI Act de zwaarste verplichtingen bij deze partij. Art. 16 somt de verplichtingen van providers op; voor hoog-risico AI-systemen zijn ze aanzienlijk:

• Kwaliteitsmanagementsysteem (Art. 17) — Een gedocumenteerd, continu systeem voor risicobeheer, datakwaliteit, technische documentatie, incidentopvolging en post-market monitoring. ISO 42001 biedt hiervoor een erkend beheerkader.
• Technische documentatie (Art. 11 jo. Bijlage IV) — Een uitgebreid technisch dossier dat de werking, trainingsdata, validatiemethodiek, prestatiegrenzen en beveiligingsmaatregelen van het systeem beschrijft. Dit dossier moet minimaal tien jaar na ingebruikname worden bewaard.
• Logging en traceerbaarheid (Art. 12) — Ingebouwde automatische logging die het gebruik van het systeem gedurende de gehele levensduur registreert — inclusief invoerdata, beslissingen en toezichtsinterventies.
• Conformiteitsbeoordeling (Art. 43) — Voordat een hoog-risico AI-systeem in de handel wordt gebracht, moet een conformiteitsbeoordeling worden doorlopen. Voor systemen in Bijlage III (de meest voorkomende deployer-context) geldt doorgaans zelfbeoordeling met interne controle; voor systemen die vallen onder Bijlage I-productwetgeving (medische hulpmiddelen, luchtvaart) is inschakeling van een aangemelde instantie verplicht.
• EU-databank registratie (Art. 49) — Hoog-risico AI-systemen moeten vóór ingebruikname worden geregistreerd in de Europese AI-databank.
• Post-market monitoring (Art. 72) — Een actief systeem om de werking van het systeem in de praktijk te bewaken en incidenten te detecteren en te rapporteren.

Deze verplichtingen zijn substantieel. Ze veronderstellen toegang tot de technische architectuur van het systeem, inzicht in de trainingsdata, en de capaciteit om een kwaliteitsmanagementsysteem op te zetten en te onderhouden. Dat is precies waarom de provider de partij is die het systeem bouwt of laat bouwen — niet de partij die het koopt.

De Deployer: geen toeschouwer, maar ook geen ingenieur

Een hardnekkig misverstand is dat deployers compliance kunnen delegeren aan hun leverancier. "Wij hebben de software ingekocht bij een gerenommeerde aanbieder — hun CE-documentatie dekt ons" is een redenering die juridisch niet standhoudt. Art. 26 legt deployers een zelfstandige reeks verplichtingen op, los van wat de provider heeft gedaan:

• Instructies opvolgen (Art. 26.1) — Deployers zijn verplicht het AI-systeem te gebruiken conform de instructions for use van de provider. Afwijkend gebruik — ook als dat zakelijk aantrekkelijk lijkt — valt buiten de gedekte conformiteit en creëert een zelfstandige aansprakelijkheid.
• Menselijk toezicht (Art. 26.2) — Deployers moeten ervoor zorgen dat de personen die belast zijn met menselijk toezicht de bevoegdheid, capaciteit en scholing hebben om de werking van het systeem te begrijpen en beslissingen zo nodig te overrulen of het systeem stil te leggen. Dit vereist een aanwijzingsbesluit, een trainingsprogramma en een toezichtsprotocol.
• Inputdata (Art. 26.4) — Voor zover de deployer controle heeft over de invoerdata die aan het systeem worden aangeboden, is hij verantwoordelijk voor de relevantie en representativiteit van die data.
• Monitoring en incidentmelding (Art. 26.5 en Art. 73) — Deployers moeten de werking van het systeem actief monitoren op risico's in de eigen organisatiecontext. Ernstige incidenten — onverwachte schade, discriminatoire uitkomsten, systeemfalen met gevolgen voor personen — moeten worden gemeld aan de provider én aan de nationale toezichthouder (in Nederland: de ACM).
• Fundamental Rights Impact Assessment — FRIA (Art. 27) — Voor bepaalde categorieën deployers is de FRIA wettelijk verplicht: overheidsinstanties en private organisaties die hoog-risico AI inzetten voor de in Bijlage III genoemde toepassingen in de publieke sfeer (biometrische identificatie, kredietscoring, werkgelegenheid, onderwijs). De FRIA is een ex-ante beoordeling van de grondrechtenimpact van het beoogde gebruik — vergelijkbaar in structuur met een DPIA, maar breder van reikwijdte.
• Transparantie naar betrokkenen (Art. 50 jo. Art. 26.3) — Deployers zijn verplicht betrokkenen te informeren wanneer zij worden blootgesteld aan een hoog-risico AI-systeem, tenzij dit uit de context al duidelijk is. Per 2 augustus 2026 geldt dit ook voor systemen die met mensen interageren zonder dat dit direct zichtbaar is.
• AI Literacy (Art. 4) — Al van kracht per 2 februari 2025: deployers moeten aantoonbare inspanningen leveren om de AI-geletterdheid van hun medewerkers op peil te brengen. Dit betreft niet alleen technici, maar alle medewerkers die AI-systemen inzetten in hun werk.

De gevarenzone: wanneer een deployer onbedoeld provider wordt

Dit is het meest kritieke, en meest onderschatte, onderdeel van de AI Act voor veel organisaties. Art. 25 bevat een overgangsregel die bepaalt wanneer de volledige set provider-verplichtingen verschuift naar een deployer. Het gaat om drie situaties:

1. Naamswijziging (Art. 25.1.a)

Uw organisatie koopt een AI-systeem in en brengt dit op de markt of in gebruik onder uw eigen naam of merk — ook wel white-labeling genoemd. Vanaf dat moment bent u juridisch gezien de provider van dat systeem, met alle bijbehorende verplichtingen. De oorspronkelijke bouwer treedt terug; u neemt het stokje over. Dit geldt ook wanneer het product intern wordt ingezet (ingebruikneming), niet alleen wanneer het commercieel wordt gedistribueerd.

2. Aanzienlijke wijziging (Art. 25.1.b)

Uw organisatie brengt een aanzienlijke wijziging (substantial modification) aan in een hoog-risico AI-systeem. De AI Act definieert dit als een wijziging die het systeem buiten de oorspronkelijke conformiteitsbeoordeling brengt — omdat de prestaties, risicoprofielen of het beoogde gebruiksdomein fundamenteel veranderen.

Concrete voorbeelden: u neemt een algemeen taalmodel af via een API en finetunet dit model met uw eigen, domeinspecifieke data voor een hoog-risico toepassing (bijv. geautomatiseerde kredietselectie of sollicitantbeoordeling). Of u integreert een systeem op een manier die de inputdata structureel verandert ten opzichte van het oorspronkelijk gevalideerde gebruik. In beide gevallen bent u niet langer deployer — u bent provider geworden van het gewijzigde systeem.

3. Wijziging van het beoogde doel (Art. 25.1.c)

U zet een AI-systeem in voor een ander doel dan het beoogde gebruik waarvoor de provider conformiteit heeft vastgesteld. Als dat andere doel valt onder een hoog-risico categorie in Bijlage III, dan draagt u de provider-aansprakelijkheid voor dat gebruik — ook als het systeem zelf ongewijzigd is.

Dit scenario is in de praktijk bijzonder verraderlijk. Een organisatie koopt een chatbot in voor algemene klantenservice (laag-risico gebruik), maar zet deze vervolgens in voor het begeleiden van sollicitatieprocedures of het beoordelen van kredietaanvragen. Het systeem is hetzelfde; het doel is radicaal veranderd — en daarmee de juridische positie van de organisatie.

Wat dit betekent voor uw compliance-strategie

De praktische consequentie van Art. 25 is dat het juridische label 'deployer' niet statisch is. Het is een status die kan veranderen als gevolg van beslissingen die doorgaans worden genomen in de IT-afdeling, bij een productmanager of in een innovatieteam — ver van de juridische of compliance-functie. Dat maakt bewustwording en procesintegratie essentieel.

Concreet betekent dit dat iedere organisatie die AI-systemen inkoopt, aanpast of hergebruikt, een intern beoordelingsproces nodig heeft dat bij elke relevante wijziging de vraag stelt: verandert dit onze juridische rol? Dat beoordelingsproces moet worden geborgd in het change management, het inkoopproces en het softwareontwikkelingsproces — niet alleen in de compliance-afdeling.

De boetes: wat staat er op het spel?

Art. 99 van de AI Act koppelt boetes aan de ernst van de overtreding. Voor providers die een verboden AI-praktijk inzetten (Art. 5) geldt een maximumboete van 35 miljoen euro of 7% van de wereldwijde jaaromzet. Voor schendingen van de hoog-risico verplichtingen door providers of deployers — waaronder het niet uitvoeren van een FRIA, het ontbreken van menselijk toezicht, of het niet melden van incidenten — bedraagt de maximumboete 15 miljoen euro of 3% van de wereldwijde jaaromzet.

Voor een deployer die onbedoeld de rol van provider op zich heeft genomen, zonder dat de bijbehorende verplichtingen zijn ingevuld, kan het gehele provider-sanctieregime van toepassing zijn — bovenop de deployer-verplichtingen die al golden. Dat is het dubbele risico van een verkeerd begrepen rolverdeling.

Praktische eerste stappen

Uw compliance-strategie begint met helderheid over uw rol per AI-systeem. Dat vereist een gestructureerde inventarisatie:

1. Breng alle AI-systemen in kaart — per afdeling, per leverancier, per beoogd gebruik. Registreer ook informele inzet (Shadow AI): tools die medewerkers zelfstandig gebruiken buiten de IT-organisatie om.
2. Bepaal per systeem uw rol — bent u zuiver deployer, of heeft u wijzigingen aangebracht of een ander doel nagestreefd dan het oorspronkelijke? Documenteer die beoordeling inclusief de onderbouwing.
3. Classificeer het risiconiveau — alleen voor hoog-risico systemen (Bijlage III) gelden de zwaarste verplichtingen. Classificeer conservatief bij twijfel: de wet verplicht dit (overweging 84).
4. Stel het beoordelingsproces in voor toekomstige wijzigingen — elk API-gebruik, elke fine-tuning, elke integratie moet worden getoetst aan de criteria van Art. 25. Dat is een proces, geen eenmalige check.
5. Documenteer doorlopend — de bewijslast bij een toezichtsonderzoek ligt bij u. Elke beslissing, elke beoordeling, elke toezichtsactie moet gedateerd en bewaard zijn.

Conclusie

De scheidslijn tussen deployer en provider is niet louter een juridisch label — het is de spil waaromheen uw volledige compliance-strategie moet worden gebouwd. Een verkeerde aanname over uw rol leidt tot blinde vlekken: deployers die de zwaardere provider-verplichtingen niet kennen, en providers die de specifieke deployer-verplichtingen voor menselijk toezicht en impact assessments over het hoofd zien.

Het mechanisme van Art. 25 maakt die rolverdeling bovendien dynamisch. Elke technische wijziging, elke herbestemming van een AI-systeem en elke white-label beslissing kan uw juridische positie onmiddellijk veranderen. De organisaties die dat begrijpen — en er een intern beoordelingsproces op inrichten — staan juridisch solide. De organisaties die het negeren, bouwen risico's op die pas zichtbaar worden wanneer een toezichthouder aanklopt.