Aanbieder en gebruiksverantwoordelijke (AI Act)

Wat zijn aanbieder en gebruiksverantwoordelijke onder de AI Act?

De AI Act vraagt niet wat voor bedrijf je bent. Ze vraagt wat je met een welbepaald AI-systeem gedaan hebt, en geeft je op basis daarvan een rol. Twee rollen dragen bijna al het gewicht.

Artikel 3, punt 3 noemt aanbieder wie een AI-systeem of een AI-model voor algemene doeleinden "ontwikkelt of laat ontwikkelen" en het onder de eigen naam of het eigen merk in de handel brengt of in gebruik stelt, "al dan niet tegen betaling". Drie stukken van die zin beslissen echte dossiers. Laat ontwikkelen betekent dat je zelf geen regel code hoeft te schrijven: de opdracht geven volstaat. Onder de eigen naam of het eigen merk wijst naar het etiket op het product, niet naar wie de factuur betaalde. En al dan niet tegen betaling betekent dat iets gratis weggeven je niet uit die rol haalt.

Artikel 3, punt 4 noemt gebruiksverantwoordelijke wie "een AI-systeem onder eigen verantwoordelijkheid gebruikt, tenzij het AI-systeem wordt gebruikt in het kader van een persoonlijke niet-beroepsactiviteit". Onder eigen verantwoordelijkheid is de hele toets: jij hebt beslist om het aan te zetten, op jouw data, voor jouw doeleinden. De uitzondering dekt alleen het privéleven. Een boekhouder die een AI-assistent op klantendossiers loslaat, is gebruiksverantwoordelijke. Diezelfde persoon die op zondag een recept vraagt, niet.

De rol hangt aan het systeem, niet aan het bedrijf. In dezelfde week en hetzelfde gebouw kan je gebruiksverantwoordelijke zijn van een cv-screeningtool die je gekocht hebt, en aanbieder van een offertetool die je liet bouwen en nu doorverkoopt.

Waarom bijna elk bedrijf gebruiksverantwoordelijke is

Je koopt een licentie, je richt ze op je eigen data, en je laat ze werk doen. De softwareleveranciers zijn de aanbieders, de kopers zijn gebruiksverantwoordelijken, en de meeste bedrijven kopen in plaats van te bouwen.

Gebruiksverantwoordelijke is geen lege rol. Voor een hoog-risico systeem vraagt artikel 26 je om:

• Het systeem te gebruiken in overeenstemming met de gebruiksaanwijzing van de aanbieder.

• Het menselijk toezicht op te dragen aan natuurlijke personen "die over de nodige bekwaamheid, opleiding en autoriteit beschikken en de nodige ondersteuning krijgen".

• Ervoor te zorgen dat de inputdata "relevant en voldoende representatief" zijn voor het beoogde doel, voor zover jij daar controle over hebt. Een screeningtool voeden met een kandidatenpool die niets met de functie te maken heeft, is jouw probleem en niet dat van de leverancier.

• De logs die het systeem automatisch aanmaakt minstens zes maanden te bewaren, voor zover ze onder jouw controle staan.

• De werknemersvertegenwoordigers en de betrokken werknemers te verwittigen voor je een hoog-risico systeem op de werkvloer in gebruik neemt, en het te zeggen tegen de mensen over wie het systeem een beslissing neemt of mee bepaalt.

Artikel 25: hoe een gebruiksverantwoordelijke aanbieder wordt

Hier gaan bedrijven de mist in. Artikel 25, lid 1 zegt dat een distributeur, importeur, gebruiksverantwoordelijke of andere derde in drie situaties als aanbieder van een hoog-risico AI-systeem beschouwd wordt, en vanaf dat moment valt het volledige aanbiedersregime op hen.

Je zet er je naam of merk op. De tekst spreekt over wie "zijn naam of merk op een AI-systeem met een hoog risico zet dat reeds in de handel is gebracht of in gebruik is gesteld". Een sociaal secretariaat dat de evaluatietool voor werknemers van een leverancier onder eigen label als eigen product verkoopt, doet precies dat, en punt 4 van bijlage III zet systemen die de prestaties van werknemers opvolgen en beoordelen in de hoog-risico categorie. Het artikel voegt er wel aan toe dat contractuele afspraken de verplichtingen anders kunnen verdelen, maar een toezichthouder begint te lezen bij de naam op de doos.

Je brengt een substantiële wijziging aan. Een verandering nadat het systeem in de handel is gebracht, die de aanbieder niet voorzien had in zijn conformiteitsbeoordeling, en die de conformiteit raakt of het beoogde doel wijzigt. Een geleverd model bijtrainen op tien jaar eigen beslissingen komt daarvoor in aanmerking. Een drempelwaarde verzetten die de leverancier zelf als instelbaar documenteerde, niet.

Je verandert waar het voor dient. Je wijzigt het beoogde doel van een systeem dat geen hoog risico had, ook van een AI-systeem voor algemene doeleinden, zodat het wel een hoog risico krijgt. Een algemene tekstassistent kopen en er sollicitanten mee rangschikken is het schoolvoorbeeld. Aan de software is niets veranderd. Het doel wel, en werkgelegenheid staat in bijlage III.

Artikel 25, lid 2 zegt vervolgens dat de oorspronkelijke aanbieder niet langer als aanbieder van dat specifieke systeem geldt. De plicht wordt niet gedeeld, ze verhuist. Die aanbieder moet wel met je samenwerken en je documentatie, gekende beperkingen en technische toegang geven. Met één uitzondering die je twee keer mag lezen: dat geldt niet als de oorspronkelijke aanbieder duidelijk heeft aangegeven dat zijn systeem niet tot een hoog-risico systeem mag worden omgevormd. Staat die zin in de voorwaarden van je leverancier en verander je het doel toch, dan word je aanbieder en krijg je niets om mee te werken.

Wat er verandert op het moment dat je omslaat

Een gebruiksverantwoordelijke houdt een handvol operationele plichten over. Een aanbieder van een hoog-risico systeem draagt artikel 16, en dat is werk van een andere orde: een kwaliteitsbeheersysteem, technische documentatie, de conformiteitsbeoordeling voor het systeem op de markt komt, een EU-conformiteitsverklaring, CE-markering, registratie in de EU-databank, en je naam en contactadres op het systeem. Die beoordeling moet gebeuren voor het systeem in de handel gebracht wordt, dus de dag waarop je vaststelt dat je de lijn overgestoken bent, is het al te laat om ze in de juiste volgorde te doen.

Een uitgewerkt voorbeeld: de tool die je herlabelde

Een hr-dienstverlener van veertig mensen neemt een licentie op een matchingtool voor kandidaten bij een Nederlandse softwareleverancier. Die leverancier is de aanbieder en levert de gebruiksaanwijzing. Het hr-bedrijf is gebruiksverantwoordelijke.

Dan gebeuren er over achttien maanden drie dingen, elk op zich verdedigbaar. Het bedrijf traint het matchingmodel bij op tien jaar eigen plaatsingsresultaten, omdat generieke matching in zijn niche te zwak presteert. Het zet zijn eigen merk op de interface waarop klanten inloggen, want daar betalen klanten voor. En het verkoopt toegang tot die interface aan klantbedrijven als een eigen abonnement.

Samen raken die stappen de eerste twee gevallen van artikel 25, zonder dat iemand in dat bedrijf ooit beslist heeft om aanbieder te worden. Kandidaten matchen voor aanwerving staat in bijlage III, dus het systeem is hoog risico. Het bedrijf heeft nu een conformiteitsbeoordeling nodig voor iets dat het al een jaar verkoopt, technische documentatie voor een model dat het bijtrainde zonder bij te houden waarop, en een registratie die het nooit gedaan heeft.

De goedkope oplossing zit vooraan. Voor je herlabelt of bijtraint, vraag je de leverancier schriftelijk of de wijziging aan het beoogde doel raakt of verder gaat dan wat zijn documentatie als instelbaar beschrijft.

Importeur, distributeur, en het model achter je assistent

Er duiken nog twee rollen op in toeleveringsketens. Een importeur is in de Unie gevestigd en brengt een systeem in de handel dat de naam of het merk draagt van een bedrijf buiten de EU. Een distributeur is iedereen anders in de keten die een systeem op de markt van de Unie aanbiedt. Hun plichten zijn nakijkwerk, geen bouwwerk: is de CE-markering er, is er een EU-conformiteitsverklaring, zit de gebruiksaanwijzing erbij, heeft de aanbieder zijn eigen verplichtingen nageleefd. Een Amerikaanse hr-tool ongewijzigd doorverkopen in België brengt je hier terecht.

Een assistent kopen die op andermans model gebouwd is, maakt je geen aanbieder van dat model. Dat blijft bij wie het ontwikkeld en op de markt gebracht heeft. De richtsnoeren van de Commissie van juli 2025 zeggen dat een bedrijf dat een model voor algemene doeleinden aanpast, pas aanbieder van een model wordt als de wijziging groot genoeg is in algemeenheid of capaciteit, waarbij de rekenkracht die in de aanpassing gaat afgewogen wordt tegen die achter het oorspronkelijke model. Bijtrainen op je eigen documenten zit daar nergens in de buurt. Artikel 25 gaat over het systeem, en daar struikel je veel makkelijker over.

Aanbieder tegenover gebruiksverantwoordelijke: wie moet antwoorden als het misloopt

Een afgewezen kandidaat vraagt waarom. Wat de twee rollen uit elkaar houdt, is welk bedrijf dat antwoord klaar moet hebben.

De aanbieder antwoordt voor het systeem. Was het ontworpen en getest voor dit doel, op welke data is het getraind, beschrijft de documentatie de grenzen ervan, zit toezicht ingebouwd. Die antwoorden staan in de technische documentatie of ze bestaan gewoon niet, en geen enkele gebruiksverantwoordelijke maakt ze achteraf.

De gebruiksverantwoordelijke antwoordt voor het gebruik. Is het gebruikt zoals de gebruiksaanwijzing zegt, wie keek mee, mocht die persoon overrulen, wat ging erin als inputdata, staan de logs er nog, zijn de betrokkenen ingelicht. Een volledig conform systeem kopen beantwoordt daar geen enkele van.

Beide kunnen tegelijk fout zitten, en beide worden apart beboet. De lijn van artikel 25 oversteken legt er dus geen beetje papierwerk bovenop: het maakt jou de partij die zowel de systeemantwoorden als de gebruiksantwoorden klaar moet hebben.

Over de timing: de hoog-risico verplichtingen waar deze rollen aan hangen, zijn verschoven. Verordening (EU) 2026/1744, de digitale omnibus rond AI, van kracht sinds 27 juli 2026, duwde losstaande hoog-risico systemen uit bijlage III naar 2 december 2027 en AI die in producten uit bijlage I zit naar 2 augustus 2028. Artikel 3 en artikel 25 zijn niet herschreven. Wat verschoven is, is de datum waarop de plichten bij die rollen beginnen te knellen.