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-waardeketenwaardeketenDe reeks actoren van modelontwikkeling via levering tot uitrol en gebruik, waarlangs verantwoordelijkheden en AI Act-verplichtingen zich verplaatsen. Zie toeleveringsketen, AI-verplichtingen.Open full entry →. 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: aanbiederaanbiederDe actor die een AI-systeem ontwikkelt (of laat ontwikkelen) en het onder eigen naam op de markt brengt of in gebruik neemt, met fabrikantachtige plichten: ontwerpcontrols, documentatie, conformiteit. Zie gebruiksverantwoordelijke, AI-verplichtingen.Open full entry →) is een natuurlijke of rechtspersoon, overheidsinstantie, agentschap of ander orgaan dat een AI-systeemAI-systeemEen machinaal systeem dat voor expliciete of impliciete doelen uit invoer afleidt hoe het uitvoer genereert, voorspellingen, inhoud, aanbevelingen of beslissingen, die fysieke of virtuele omgevingen kunnen beïnvloeden. De OESO-achtige definitie die de EU AI Act volgt. Zie algoritme, machine learning.Open full entry → 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-risicorisicoIn de termen van de EU AI Act de combinatie van de waarschijnlijkheid dat een schade optreedt en de ernst ervan als dat gebeurt. De schakel tussen een principe (via de schade die het zou schenden) en een control (de maatregel die het vermindert). Het benoemen van de schade en het inschatten van het risico is op grond van Art. 9 vereist voordat een maatregel wordt gekozen. Zie schade, control, restrisico.Open full entry → AI-systemen zijn ze aanzienlijk:

• Kwaliteitsmanagementsysteem (Art. 17), Een gedocumenteerd, continu systeem voor risicobeheer, datakwaliteit, technische documentatietechnische documentatieRegistraties die een aanbieder voor een hoog-risico-AI-systeem moet samenstellen en bewaren om conformiteit aan te tonen, met dekking van het ontwerp, de data, het testen, het risicobeheer en de monitoring. Zie aanbieder, bewijs, model card.Open full entry →, incidentopvolging en post-market monitoringpost-market monitoringDe plicht aan de aanbiederszijde om ervaring met systemen in gebruik systematisch te verzamelen en erop te handelen, de productregelgevingshelft van doorlopende monitoring. Zie doorlopende monitoring, aanbieder.Open full entry →. ISO 42001 biedt hiervoor een erkend beheerkader.
• Technische documentatie (Art. 11 jo. Bijlage IV), Een uitgebreid technisch dossier dat de werking, trainingsdatatrainingsdataDe data die wordt gebruikt om de parameters van een AI-model te passen; de kwaliteit, de rechtmatige rechten en de representativiteit ervan zijn centrale governance-zorgen. Zie representativiteit, herkomst, datasheet.Open full entry →, 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.
• ConformiteitsbeoordelingconformiteitsbeoordelingHet proces vóór markttoelating waarmee wordt aangetoond dat een hoog-risico-AI-systeem voldoet aan de eisen van de EU AI Act, leidend tot CE-markering en registratie. Zie CE-markering, aangemelde instantie.Open full entry → (Art. 43), Voordat een hoog-risico AI-systeem in de handel wordt gebracht, moet een conformiteitsbeoordeling worden doorlopen. Voor systemen in Bijlage IIIBijlage IIIDe lijst van de EU AI Act met hoog-risico-toepassingsgebieden: biometrie, kritieke infrastructuur, onderwijs, werk, essentiële diensten, rechtshandhaving, migratie, justitie. Zie conformiteitsbeoordeling, conformiteitsverklaring.Open full entry → (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 instantieaangemelde instantieEen onafhankelijke conformiteitsbeoordelingsorganisatie die is aangewezen om te verifiëren dat een hoog-risico-AI-systeem aan de AI Act voldoet voordat het op de markt komt. Zie conformiteitsbeoordeling.Open full entry → 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 toezichtmenselijk toezichtHet ingebouwde vermogen van een mens om een AI-systeem te monitoren, erin in te grijpen, het te overrulen of stil te leggen, alleen betekenisvol wanneer de mens de bevoegdheid, de informatie en de tijd heeft om te handelen. Zie principe, human-in-the-loop, human-on-the-loop.Open full entry → (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 representativiteitrepresentativiteitHoe goed de trainingsdata de populatie en de omstandigheden weerspiegelt die het systeem bij inzet zal tegenkomen, de kern van datakwaliteit voor AI in termen van geschiktheid voor het doel. Zie eerlijkheid, trainingsdata.Open full entry → 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 schadeschadeDe concrete schade die een AI-systeem kan aanrichten en die een principe van verantwoorde AI beoogt te voorkomen: in de termen van de EU AI Act schade aan iemands gezondheid, veiligheid of grondrechten. Schade is de brug tussen een abstract principe en een bestuurbaar risico; governance wordt operationeel op het moment dat een organisatie de specifieke schades benoemt die ze wil voorkomen. Voor eerlijkheid is een schade dat een groep stelselmatig slechtere uitkomsten krijgt vanwege een kenmerk dat niet had mogen meetellen. Zie principe, risico.Open full entry →, 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, FRIAFRIAFundamental Rights Impact Assessment, vereist van publieke organen en bepaalde private gebruiksverantwoordelijken voordat ze sommige hoog-risico-AI-systemen onder de EU AI Act gebruiken. Zie grondrechten-impactassessment, gebruiksverantwoordelijke.Open full entry → (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 DPIADPIAData Protection Impact Assessment, vereist vóór verwerking met waarschijnlijk hoog risico (systematische profilering met aanzienlijke gevolgen, grootschalige bijzondere categorieën, publieke monitoring); AI-ontwikkeling roept het voortdurend op. Zie impactassessment, profilering.Open full entry →, maar breder van reikwijdte.
• TransparantietransparantieOpenheid over het feit dát AI wordt gebruikt en hoe het in het algemeen werkt: openbaarmakingen, documentatie, kennisgevingen. Vormt een paar met uitlegbaarheid, die over individuele uitkomsten gaat. Zie uitlegbaarheid, principe.Open full entry → naar betrokkenenbetrokkenenDe individuen of groepen die onderworpen zijn aan of geraakt worden door de uitkomsten of beslissingen van een AI-systeem, en wier rechten het governance-regime beoogt te beschermen. Zie schade, belanghebbendenanalyse.Open full entry → (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-geletterdheidAI-geletterdheidVoldoende begrip van de werking, mogelijkheden en risico's van AI voor de eigen rol, een expliciete verwachting voor medewerkers van aanbieders en gebruiksverantwoordelijken onder de EU AI Act. Zie aanbieder, gebruiksverantwoordelijke.Open full entry → 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 AIshadow AIAI-tools die door medewerkers of afdelingen buiten de officiële kanalen en governance worden aangeschaft, het voorspelbare product van processen die te zwaar of te traag zijn. Zie AI-inventaris, governance.Open full entry →): 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-tuningfine-tuningEen bestaand model verder trainen op je eigen data om zijn gedrag aan te passen, wat jou verantwoordelijk maakt voor de wijziging, mogelijk tot op aanbiederniveau. Zie aanbieder, foundation model.Open full entry →, 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 herbestemmingherbestemmingEen AI-systeem gebruiken voor een ander doel dan waarvoor het is gebouwd en beoordeeld, wat zijn risicoklasse en de geldende verplichtingen kan veranderen. Zie substantiële wijziging, AI-verplichtingen.Open full entry → 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.