Ben je aanbieder of gebruiksverantwoordelijke onder de EU AI Act?
De aanbieder bouwt het AI-systeem en brengt het onder zijn eigen naam op de markt. De gebruiksverantwoordelijke zet het in binnen zijn eigen organisatie. Bij een ingekocht assessment is de leverancier de aanbieder en de werkgever de gebruiksverantwoordelijke. Bouw je zelf, dan ben je allebei.
Koopt een werkgever een AI-assessment in en gebruikt hij dat om kandidaten voor te selecteren, dan ontstaan er twee rollen onder Verordening (EU) 2024/1689, de EU AI Act. De ene partij heeft het systeem gebouwd en op de markt gebracht. De andere draait er dagelijks mee. De wet noemt ze aanbieder en gebruiksverantwoordelijke, in het Engels provider en deployer, en legt bij allebei andere verplichtingen neer.
Dit verkeerd inschatten levert geen administratief hiaat op maar een gat in je proces. Niemand is eigenaar van de incidentafhandeling, niemand heeft de logbestanden bewaard, en niemand kan de technische documentatie laten zien die een auditor opvraagt. Dit artikel legt de twee rollen naast de praktijk van recruitmenttechnologie, zodat je de verplichtingen kunt verdelen voordat er een handtekening onder een contract staat.
Nog even over de timing. De hoog-risico verplichtingen uit artikel 16 en 26 gaan pas gelden vanaf 2 december 2027, nadat ze via de Digital Omnibus zijn uitgesteld. Dat is geen reden om te wachten. De rolverdeling bepaalt nu al welke documentatie je straks moet kunnen laten zien, en die vraag je makkelijker op tijdens een implementatie dan erna.
Artikel 3 van de EU AI Act bevat de definities die de hele verordening sturen. De geconsolideerde tekst staat op EUR-Lex onder Verordening (EU) 2024/1689. De AI Act Service Desk van de Europese Commissie geeft er een uitleg in gewone taal bij.
Aanbieder, artikel 3(3). De natuurlijke persoon, rechtspersoon, overheidsinstantie of ander orgaan dat een AI-systeem ontwikkelt of laat ontwikkelen en het onder eigen naam of merk op de markt brengt of in gebruik stelt.
In recruitmenttermen is dat de assessmentleverancier. Bouwt een bedrijf AI-gescoorde assessments en brengt het die commercieel in licentie, dan is het de aanbieder. De merknaamtoets is hier bepalend. Wordt een model van een derde ingebouwd en onder een andere naam opnieuw uitgebracht, dan neemt de partij die dat doet de verplichtingen van de aanbieder over.
Gebruiksverantwoordelijke, artikel 3(4). De natuurlijke persoon, rechtspersoon, overheidsinstantie of ander orgaan dat een AI-systeem onder eigen verantwoordelijkheid gebruikt in een professionele context. Persoonlijk, niet-professioneel gebruik valt erbuiten.
Dat is de werkgever of het HR-team dat het assessment inricht en in de funnel laat draaien. Je hoeft niets gebouwd te hebben. Het systeem gebruiken om kandidaten te scoren, te rangschikken of aan te bevelen is genoeg.
Eén organisatie kan allebei zijn. Een werkgever die een eigen AI-screeningtool bouwt en intern uitrolt, is aanbieder en gebruiksverantwoordelijke tegelijk, voor verschillende delen van de wet.
Deze vier situaties kom je het vaakst tegen.
| Situatie | Waarschijnlijk aanbieder | Waarschijnlijk gebruiksverantwoordelijke |
|---|---|---|
| Assessmentleverancier levert AI-scoring via een ATS-koppeling | De assessmentleverancier | De werkgever |
| ATS-leverancier bundelt assessmentlogica van een derde onder zijn eigen merk | De ATS-leverancier, als herlabelde aanbieder | De werkgever |
| Werkgever stelt eigen scoredrempels in op het model van de leverancier | De assessmentleverancier, voor het basissysteem | De werkgever, ook voor de configuratiekeuzes |
| Werkgever bouwt zelf een screeningtool en rolt die uit naar HR | De werkgever | De werkgever |
De twee beslissende vragen zijn wie het systeem op de markt of onder eigen merk in gebruik heeft gesteld, en wie de operationele instellingen beheert en de uitkomsten gebruikt om over kandidaten te beslissen. Daar ligt het antwoord.
Assessmenttools die worden gebruikt voor beslissingen over werk vallen in de regel in de categorie hoog risico. Artikel 16 legt de aanbieder daarvan verplichtingen op die al af moeten zijn voordat het systeem bij een gebruiksverantwoordelijke terechtkomt. De AI Act Service Desk vat ze samen als onder meer het volgende.
Voor een inkoopteam dat een assessmentleverancier beoordeelt, vertaalt zich dat in een concrete uitvraag. Voor de livegang moet de leverancier zijn technische documentatie, zijn risicodossier, zijn gebruiksaanwijzing en het bewijs van zijn conformiteitstraject kunnen laten zien. Kan hij dat niet, dan is dat een compliancesignaal en niet alleen een inkoopongemak.
Artikel 26 gaat over het gebruik zelf. Volgens de AI Act Service Desk komt het neer op het volgende.
Voor recruitment zit hier iets ongemakkelijks in. Dit zijn geen IT-taken. De verplichting om te zorgen dat getrainde, bevoegde beoordelaars een automatische aanbeveling kunnen overrulen of stopzetten, ligt bij HR. Een HR-directeur kan het toezicht uit artikel 26 niet volledig bij een technisch team neerleggen en tegelijk het eigenaarschap loslaten over wie de uitkomsten beoordeelt en wanneer een besluit wordt teruggedraaid. Hoe dat uitpakt bij een automatische afwijzing staat in onze blog over artikel 22 AVG en automatisch afwijzen.
Een aantal onderwerpen valt niet netjes aan één kant. Het informeren van kandidaten dat er een AI-beoordeling in het spel is, het bewaren van logbestanden, de incidentmelding en het beheer van wijzigingen als je wervingsbeleid verandert, vragen allemaal afstemming tussen leverancier en werkgever.
Een werkbare verdeling ziet er zo uit. De aanbieder is verantwoordelijk voor de gebruiksaanwijzing en de compliancedocumentatie. De gebruiksverantwoordelijke keurt de interne governance goed en voert het menselijk toezicht uit. De incidentroute en de bijbehorende reactietijden delen ze.
Bepalingen die het overwegen waard zijn.
Eén punt wordt vaak over het hoofd gezien. Het instellen van een scoredrempel is een compliancebeslissing, geen productinstelling. Verlaagt een werkgever een afkapscore of past hij weegfactoren aan, dan verandert het gedrag van het systeem op een manier die de eerlijkheid en de verdedigbaarheid raakt. Leg vast dat configuratiewijzigingen gedocumenteerd worden gevalideerd voordat ze live gaan. Over wat je de kandidaat dan precies vertelt, gaat onze blog over open communiceren over AI in je sollicitatieproces.
Voor de leverancier, als aanbieder
Voor de werkgever, als gebruiksverantwoordelijke
Wat je opvraagt voordat je tekent
Compliancedocumentatie verzamel je niet nadat een systeem live is. Werk je met een assessmentpartner aan een implementatie van 2 tot 10 weken, dan loopt de uitwisseling van documentatie parallel aan de technische koppeling. Dat venster is realistisch voor een geïntegreerde oplossing zoals het platform van Selection Lab, waarin SmartChat, de assessments en de ATS-rapportage in één stroom zitten.
Wacht je tot er gebruikers live staan voordat je de technische documentatie van je leverancier opvraagt, dan ontstaat er een gat dat je achteraf moeilijk dicht krijgt. Een leverancier die tijdens de implementatie vlot levert, is trouwens zelf ook een signaal. Wie het dan al niet op orde heeft, heeft het over twee jaar ook niet.
Wat is het verschil tussen een aanbieder en een gebruiksverantwoordelijke?
De aanbieder ontwikkelt het AI-systeem of laat het ontwikkelen en brengt het onder eigen naam of merk op de markt. De gebruiksverantwoordelijke gebruikt het systeem onder eigen verantwoordelijkheid in een professionele context. In recruitment is de assessmentleverancier meestal de aanbieder en de werkgever de gebruiksverantwoordelijke.
Ben ik als werkgever ook aanbieder?
Alleen als je het systeem zelf bouwt of laat bouwen en het onder je eigen naam in gebruik stelt. Koop je een assessment in, dan ben je gebruiksverantwoordelijke. Bouw je intern en rol je het uit naar je eigen HR-teams, dan ben je allebei.
Wat als mijn ATS-leverancier een assessment van een derde meelevert?
Brengt de ATS-leverancier die logica onder zijn eigen merk uit, dan neemt hij daarmee de verplichtingen van de aanbieder over. Blijft het assessment herkenbaar van de oorspronkelijke leverancier, dan blijft die de aanbieder. De merknaam is de toets.
Welke verplichtingen liggen bij HR en niet bij IT?
Het menselijk toezicht uit artikel 26. Wie de uitkomsten beoordeelt, met welke kennis en bevoegdheid, en wanneer een besluit wordt opgeschaald of teruggedraaid, is een HR-proces. Een technisch team kan dat niet voor je invullen.
Wanneer gaan de verplichtingen uit artikel 16 en 26 in?
De hoog-risico verplichtingen gelden vanaf 2 december 2027, nadat ze via de Digital Omnibus zijn uitgesteld. De transparantieplicht uit artikel 50 geldt al sinds 2 augustus 2026.
De indeling in rollen is feitelijk van aard. Merkafspraken, contractstructuren en de mate van controle die elke partij over de werking heeft, kunnen verschuiven wie waarvoor verantwoordelijk is. Is de rolverdeling in jouw situatie echt onduidelijk, leg het dan voor aan een jurist. Dat geldt zeker waar een ATS-leverancier, een assessmentleverancier en de configuratielaag van de werkgever elkaar raken.
Ben je aanbieder of gebruiksverantwoordelijke onder de EU AI Act?
De aanbieder bouwt het AI-systeem en brengt het onder zijn eigen naam op de markt. De gebruiksverantwoordelijke zet het in binnen zijn eigen organisatie. Bij een ingekocht assessment is de leverancier de aanbieder en de werkgever de gebruiksverantwoordelijke. Bouw je zelf, dan ben je allebei.
Koopt een werkgever een AI-assessment in en gebruikt hij dat om kandidaten voor te selecteren, dan ontstaan er twee rollen onder Verordening (EU) 2024/1689, de EU AI Act. De ene partij heeft het systeem gebouwd en op de markt gebracht. De andere draait er dagelijks mee. De wet noemt ze aanbieder en gebruiksverantwoordelijke, in het Engels provider en deployer, en legt bij allebei andere verplichtingen neer.
Dit verkeerd inschatten levert geen administratief hiaat op maar een gat in je proces. Niemand is eigenaar van de incidentafhandeling, niemand heeft de logbestanden bewaard, en niemand kan de technische documentatie laten zien die een auditor opvraagt. Dit artikel legt de twee rollen naast de praktijk van recruitmenttechnologie, zodat je de verplichtingen kunt verdelen voordat er een handtekening onder een contract staat.
Nog even over de timing. De hoog-risico verplichtingen uit artikel 16 en 26 gaan pas gelden vanaf 2 december 2027, nadat ze via de Digital Omnibus zijn uitgesteld. Dat is geen reden om te wachten. De rolverdeling bepaalt nu al welke documentatie je straks moet kunnen laten zien, en die vraag je makkelijker op tijdens een implementatie dan erna.
Artikel 3 van de EU AI Act bevat de definities die de hele verordening sturen. De geconsolideerde tekst staat op EUR-Lex onder Verordening (EU) 2024/1689. De AI Act Service Desk van de Europese Commissie geeft er een uitleg in gewone taal bij.
Aanbieder, artikel 3(3). De natuurlijke persoon, rechtspersoon, overheidsinstantie of ander orgaan dat een AI-systeem ontwikkelt of laat ontwikkelen en het onder eigen naam of merk op de markt brengt of in gebruik stelt.
In recruitmenttermen is dat de assessmentleverancier. Bouwt een bedrijf AI-gescoorde assessments en brengt het die commercieel in licentie, dan is het de aanbieder. De merknaamtoets is hier bepalend. Wordt een model van een derde ingebouwd en onder een andere naam opnieuw uitgebracht, dan neemt de partij die dat doet de verplichtingen van de aanbieder over.
Gebruiksverantwoordelijke, artikel 3(4). De natuurlijke persoon, rechtspersoon, overheidsinstantie of ander orgaan dat een AI-systeem onder eigen verantwoordelijkheid gebruikt in een professionele context. Persoonlijk, niet-professioneel gebruik valt erbuiten.
Dat is de werkgever of het HR-team dat het assessment inricht en in de funnel laat draaien. Je hoeft niets gebouwd te hebben. Het systeem gebruiken om kandidaten te scoren, te rangschikken of aan te bevelen is genoeg.
Eén organisatie kan allebei zijn. Een werkgever die een eigen AI-screeningtool bouwt en intern uitrolt, is aanbieder en gebruiksverantwoordelijke tegelijk, voor verschillende delen van de wet.
Deze vier situaties kom je het vaakst tegen.
| Situatie | Waarschijnlijk aanbieder | Waarschijnlijk gebruiksverantwoordelijke |
|---|---|---|
| Assessmentleverancier levert AI-scoring via een ATS-koppeling | De assessmentleverancier | De werkgever |
| ATS-leverancier bundelt assessmentlogica van een derde onder zijn eigen merk | De ATS-leverancier, als herlabelde aanbieder | De werkgever |
| Werkgever stelt eigen scoredrempels in op het model van de leverancier | De assessmentleverancier, voor het basissysteem | De werkgever, ook voor de configuratiekeuzes |
| Werkgever bouwt zelf een screeningtool en rolt die uit naar HR | De werkgever | De werkgever |
De twee beslissende vragen zijn wie het systeem op de markt of onder eigen merk in gebruik heeft gesteld, en wie de operationele instellingen beheert en de uitkomsten gebruikt om over kandidaten te beslissen. Daar ligt het antwoord.
Assessmenttools die worden gebruikt voor beslissingen over werk vallen in de regel in de categorie hoog risico. Artikel 16 legt de aanbieder daarvan verplichtingen op die al af moeten zijn voordat het systeem bij een gebruiksverantwoordelijke terechtkomt. De AI Act Service Desk vat ze samen als onder meer het volgende.
Voor een inkoopteam dat een assessmentleverancier beoordeelt, vertaalt zich dat in een concrete uitvraag. Voor de livegang moet de leverancier zijn technische documentatie, zijn risicodossier, zijn gebruiksaanwijzing en het bewijs van zijn conformiteitstraject kunnen laten zien. Kan hij dat niet, dan is dat een compliancesignaal en niet alleen een inkoopongemak.
Artikel 26 gaat over het gebruik zelf. Volgens de AI Act Service Desk komt het neer op het volgende.
Voor recruitment zit hier iets ongemakkelijks in. Dit zijn geen IT-taken. De verplichting om te zorgen dat getrainde, bevoegde beoordelaars een automatische aanbeveling kunnen overrulen of stopzetten, ligt bij HR. Een HR-directeur kan het toezicht uit artikel 26 niet volledig bij een technisch team neerleggen en tegelijk het eigenaarschap loslaten over wie de uitkomsten beoordeelt en wanneer een besluit wordt teruggedraaid. Hoe dat uitpakt bij een automatische afwijzing staat in onze blog over artikel 22 AVG en automatisch afwijzen.
Een aantal onderwerpen valt niet netjes aan één kant. Het informeren van kandidaten dat er een AI-beoordeling in het spel is, het bewaren van logbestanden, de incidentmelding en het beheer van wijzigingen als je wervingsbeleid verandert, vragen allemaal afstemming tussen leverancier en werkgever.
Een werkbare verdeling ziet er zo uit. De aanbieder is verantwoordelijk voor de gebruiksaanwijzing en de compliancedocumentatie. De gebruiksverantwoordelijke keurt de interne governance goed en voert het menselijk toezicht uit. De incidentroute en de bijbehorende reactietijden delen ze.
Bepalingen die het overwegen waard zijn.
Eén punt wordt vaak over het hoofd gezien. Het instellen van een scoredrempel is een compliancebeslissing, geen productinstelling. Verlaagt een werkgever een afkapscore of past hij weegfactoren aan, dan verandert het gedrag van het systeem op een manier die de eerlijkheid en de verdedigbaarheid raakt. Leg vast dat configuratiewijzigingen gedocumenteerd worden gevalideerd voordat ze live gaan. Over wat je de kandidaat dan precies vertelt, gaat onze blog over open communiceren over AI in je sollicitatieproces.
Voor de leverancier, als aanbieder
Voor de werkgever, als gebruiksverantwoordelijke
Wat je opvraagt voordat je tekent
Compliancedocumentatie verzamel je niet nadat een systeem live is. Werk je met een assessmentpartner aan een implementatie van 2 tot 10 weken, dan loopt de uitwisseling van documentatie parallel aan de technische koppeling. Dat venster is realistisch voor een geïntegreerde oplossing zoals het platform van Selection Lab, waarin SmartChat, de assessments en de ATS-rapportage in één stroom zitten.
Wacht je tot er gebruikers live staan voordat je de technische documentatie van je leverancier opvraagt, dan ontstaat er een gat dat je achteraf moeilijk dicht krijgt. Een leverancier die tijdens de implementatie vlot levert, is trouwens zelf ook een signaal. Wie het dan al niet op orde heeft, heeft het over twee jaar ook niet.
Wat is het verschil tussen een aanbieder en een gebruiksverantwoordelijke?
De aanbieder ontwikkelt het AI-systeem of laat het ontwikkelen en brengt het onder eigen naam of merk op de markt. De gebruiksverantwoordelijke gebruikt het systeem onder eigen verantwoordelijkheid in een professionele context. In recruitment is de assessmentleverancier meestal de aanbieder en de werkgever de gebruiksverantwoordelijke.
Ben ik als werkgever ook aanbieder?
Alleen als je het systeem zelf bouwt of laat bouwen en het onder je eigen naam in gebruik stelt. Koop je een assessment in, dan ben je gebruiksverantwoordelijke. Bouw je intern en rol je het uit naar je eigen HR-teams, dan ben je allebei.
Wat als mijn ATS-leverancier een assessment van een derde meelevert?
Brengt de ATS-leverancier die logica onder zijn eigen merk uit, dan neemt hij daarmee de verplichtingen van de aanbieder over. Blijft het assessment herkenbaar van de oorspronkelijke leverancier, dan blijft die de aanbieder. De merknaam is de toets.
Welke verplichtingen liggen bij HR en niet bij IT?
Het menselijk toezicht uit artikel 26. Wie de uitkomsten beoordeelt, met welke kennis en bevoegdheid, en wanneer een besluit wordt opgeschaald of teruggedraaid, is een HR-proces. Een technisch team kan dat niet voor je invullen.
Wanneer gaan de verplichtingen uit artikel 16 en 26 in?
De hoog-risico verplichtingen gelden vanaf 2 december 2027, nadat ze via de Digital Omnibus zijn uitgesteld. De transparantieplicht uit artikel 50 geldt al sinds 2 augustus 2026.
De indeling in rollen is feitelijk van aard. Merkafspraken, contractstructuren en de mate van controle die elke partij over de werking heeft, kunnen verschuiven wie waarvoor verantwoordelijk is. Is de rolverdeling in jouw situatie echt onduidelijk, leg het dan voor aan een jurist. Dat geldt zeker waar een ATS-leverancier, een assessmentleverancier en de configuratielaag van de werkgever elkaar raken.
