Veel organisaties denken dat de AI Act vooral een probleem is voor de techbedrijven die de modellen bouwen. Dat klopt voor een deel. Maar de wet is bewust zo opgezet dat ook de partij die hoog-risico AI in de praktijk inzet, een eigen pakket aan verplichtingen heeft. Dat is u, als deployer. En artikel 26 is het hart van wat u moet regelen.
Hieronder leest u wie deployer is, welke twaalf concrete verplichtingen artikel 26 oplegt, hoe u logging en werknemerinformatie regelt, en wanneer u opeens provider wordt zonder dat u dat doorheeft.
Wat is een deployer onder de AI Act?
De AI Act definieert in artikel 3 punt 4 een deployer als de natuurlijke of rechtspersoon die een AI-systeem onder eigen gezag gebruikt in het kader van een professionele activiteit. Het sleutelwoord is professioneel. Een burger die thuis met ChatGPT speelt, is geen deployer. Een advocatenkantoor dat dossiers door een AI-tool laat samenvatten, een gemeente die fraudemodellen draait, een ziekenhuis dat AI-diagnostiek inzet, een uitzendbureau dat AI-cv-screening gebruikt: dat zijn allemaal deployers.
Het verschil met een provider is fundamenteel. De provider ontwikkelt en brengt het AI-systeem op de markt. De deployer past het toe binnen de eigen organisatie of dienstverlening. In de praktijk komen deze rollen vaak in een keten voor. OpenAI is provider van GPT-modellen. Een Nederlandse SaaS-leverancier die GPT inbouwt in een eigen recruitment-product is downstream provider. Een uitzendbureau dat dat product gebruikt, is deployer. Elk van hen heeft eigen artikelen om aan te voldoen.
Voor de meeste Nederlandse bedrijven en publieke organisaties is de deployer-rol de relevante. U bouwt waarschijnlijk geen eigen foundation model, maar u zet wel AI in. En wanneer die AI hoog-risico is, op grond van artikel 6 en bijlage III, dan komt artikel 26 in beeld.
De twaalf kernverplichtingen uit artikel 26
Artikel 26 telt tien leden, met daarbinnen een serie concrete verplichtingen. Samengevat zijn dit de twaalf dingen die u als deployer moet regelen:
- Gebruik conform de instructies van de provider. U mag het hoog-risico AI-systeem alleen gebruiken voor het doel en in de context waarvoor het bedoeld is. Wijkt u substantieel af, dan kunt u zelf provider worden (zie verderop).
- Menselijk toezicht inrichten. U wijst gekwalificeerde mensen aan die het systeem in de praktijk monitoren, kunnen ingrijpen en uitkomsten kunnen overrulen. Artikel 26 lid 2 verwijst hiervoor naar artikel 14.
- Inputdata-kwaliteit waarborgen. Voor zover u zelf inputdata aanlevert, moet die data relevant en representatief zijn voor het beoogde doel. Slechte data leidt tot foute uitkomsten en die zijn uw verantwoordelijkheid.
- Monitoring tijdens gebruik. U moet actief volgen of het systeem werkt zoals verwacht en risico's signaleren. Geen passieve afwachting van klachten.
- Logs bewaren (lid 6). De automatisch gegenereerde logs die het systeem produceert, moet u bewaren voor zover ze onder uw controle vallen. Minimaal zes maanden, of langer als sectorwetgeving dat eist.
- Incidenten melden aan provider en toezichthouder. Bij ernstige incidenten of een risico voor gezondheid, veiligheid of grondrechten informeert u direct de provider en, in Nederland, de Autoriteit Persoonsgegevens als coordinerend toezichthouder.
- Werknemers informeren (lid 7). Voordat u hoog-risico AI inzet op de werkvloer, informeert u betrokken werknemers en hun vertegenwoordigers.
- Transparantie naar betrokkenen (lid 11). Natuurlijke personen die door een beslissing van het AI-systeem worden geraakt, moeten weten dat AI is gebruikt en wat dat voor hen betekent. Dit hangt samen met artikel 86 (recht op uitleg).
- FRIA waar verplicht (lid 9). Bepaalde deployers, met name publieke organisaties en partijen die hoog-risico AI inzetten in essentiele particuliere diensten, moeten voor ingebruikname een Fundamental Rights Impact Assessment uitvoeren. Zie ons aparte stuk over artikel 27 en de FRIA.
- Registratie in de EU-databank (lid 8). Publieke deployers van hoog-risico AI moeten zich registreren in de centrale EU-databank voor hoog-risico AI-systemen.
- AVG-rechten respecteren. Persoonsgegevens die het systeem verwerkt vallen onder de AVG. U blijft verwerkingsverantwoordelijke met alle bijbehorende plichten (grondslag, DPIA, betrokkenenrechten).
- Recht op uitleg ondersteunen. Wanneer iemand vraagt waarom een beslissing zo is uitgevallen, moet u dat onder artikel 86 kunnen toelichten. U moet zelf de inputs en factoren begrijpen die tot het besluit leidden.
Onthoud: deze twaalf punten zijn cumulatief. U kunt niet kiezen welke u wel of niet doet. Voor elk hoog-risico AI-systeem dat u inzet, moet u ze allemaal kunnen aantonen.
Logging: artikel 26 lid 6 in detail
Logging is een van de meest onderschatte onderdelen van artikel 26. De wet zegt dat u de logs die het systeem automatisch genereert moet bewaren, voor zover die onder uw controle staan. Bewaartermijn is minimaal zes maanden, tenzij sectorwetgeving (zoals voor banken, ziekenhuizen of kritieke infrastructuur) langer eist.
Wat moet er minimaal in die logs? Praktisch komt het neer op informatie die traceerbaarheid van uitkomsten mogelijk maakt: tijdstempel van het besluit of de output, welke versie van het model is gebruikt, de gebruikte inputs of een hash daarvan, het door het systeem geproduceerde resultaat, en wie of welk proces het besluit vervolgens heeft toegepast.
Een voorbeeld: een gemeente zet een AI-model in voor het beoordelen van bijstandsaanvragen. De provider levert standaard logs aan met aanvraag-ID, modelversie, scoreoutput en confidence-niveau. De gemeente moet die logs bewaren, koppelen aan het uiteindelijke besluit van de behandelaar, en op verzoek van de aanvrager of toezichthouder kunnen reproduceren waarom het systeem die uitkomst gaf.
Bouw vanaf dag een een logregister dat per AI-systeem aangeeft: welke logs worden vastgelegd, waar ze staan, hoe lang ze bewaard blijven en hoe ze opvraagbaar zijn. Zonder dit register kunt u in een audit niet aantonen dat u voldoet aan lid 6.
Medewerkers informeren: artikel 26 lid 7
Lid 7 is een typische bepaling die in de praktijk vaak wordt vergeten. Voordat u als deployer een hoog-risico AI-systeem inzet op de werkvloer, moet u de betrokken werknemers en hun vertegenwoordigers vooraf informeren. Het gaat niet om een algemene aankondiging in de nieuwsbrief, maar om gerichte uitleg: welk systeem is het, wat doet het, op welke beslissingen heeft het invloed, hoe wordt menselijk toezicht ingericht, en wat zijn de rechten van werknemers.
Voor Nederland komt hier een tweede laag bij: de Wet op de ondernemingsraden. De inzet van een AI-systeem dat personeelsbeslissingen ondersteunt valt onder het instemmingsrecht van de OR (artikel 27 WOR). Dat betekent dat u zonder OR-instemming geen recruitment-AI, prestatiebeoordelings-AI of monitoring-AI mag invoeren. De informatieplicht uit artikel 26 lid 7 en het instemmingsrecht uit de WOR vullen elkaar aan.
Wanneer wordt u opeens provider in plaats van deployer?
Artikel 25 AI Act geeft drie situaties waarin een deployer automatisch provider-status krijgt, met alle bijbehorende zwaardere verplichtingen:
- U brengt uw naam of handelsmerk aan op een bestaand hoog-risico AI-systeem.
- U brengt een substantiele wijziging aan, zodanig dat het systeem hoog-risico blijft maar materieel anders functioneert.
- U wijzigt het beoogde doel van het systeem, waardoor het in een andere hoog-risico categorie valt of nieuw hoog-risico wordt.
Het klassieke voorbeeld is een werkgever die een generiek AI-model gaat finetunen op eigen personeelsdata om er een prestatievoorspeller van te maken. Dat is een substantiele wijziging van doel en context. Zodra u die stap zet, gelden voor u de provider-verplichtingen uit artikel 16 tot en met 22: technische documentatie, kwaliteitsmanagementsysteem, conformiteitsbeoordeling, CE-markering en registratie.
Veel organisaties bouwen RAG-systemen op bestaande LLM's en denken dat ze deployer blijven. Of dat klopt hangt af van of de finetuning of de prompting tot een ander gebruik leidt dan oorspronkelijk bedoeld. Twijfelt u, ga uit van provider-status en regel de zware verplichtingen.
FRIA: wanneer en hoe
Voor sommige deployers is een FRIA verplicht voor ingebruikname. Dat geldt voor publiekrechtelijke organisaties en voor private deployers die hoog-risico AI inzetten in essentiele particuliere diensten zoals krediet- en verzekeringsbeoordeling. De FRIA brengt impact op grondrechten in kaart en moet vooraf bij de toezichthouder worden gemeld. We hebben dit volledig uitgewerkt in een apart artikel over artikel 27.
Praktische checklist deployer-naleving
Acht stappen om artikel 26 te halen
- Inventariseer welke AI-systemen u inzet en classificeer ze (hoog-risico ja of nee).
- Verzamel per hoog-risico systeem de instructies en documentatie van de provider.
- Wijs per systeem een verantwoordelijke voor menselijk toezicht aan en train deze persoon.
- Richt logging in en bewaar minimaal zes maanden (langer waar nodig).
- Informeer werknemers vooraf en regel OR-instemming waar relevant.
- Stel een FRIA op waar verplicht en registreer in de EU-databank.
- Maak een transparantietekst voor betrokken burgers of klanten en zorg voor een klachtroute.
- Plan jaarlijkse review en koppel signalen terug naar de provider.
Veelgemaakte fouten van deployers
In de praktijk zien we vier fouten steeds terugkomen.
Fout een: aannemen dat de provider alles regelt. Veel deployers gaan ervan uit dat zolang ze een hoog-risico AI-product van een gerenommeerde leverancier kopen, ze klaar zijn. Onjuist. De provider regelt zijn eigen verplichtingen, u regelt artikel 26.
Fout twee: geen logregister. Logs worden vaak wel gegenereerd, maar nergens centraal vastgelegd of structureel bewaard. Bij een incident of audit kan dan niet worden gereproduceerd wat het systeem heeft gedaan.
Fout drie: substantiele wijziging zonder providerstatus aan te nemen. Een organisatie finetunt een model op eigen data en blijft zichzelf deployer noemen. Bij een toezichtactie blijkt dat ze al lang provider hadden moeten zijn, met bijhorende boetes.
Fout vier: werknemers pas informeren bij de livegang. Lid 7 verplicht informatie vooraf. Vlak voor of na de livegang is te laat en kan leiden tot OR-bezwaar en handhaving.
Bent u deployer en weet u of u alles geregeld heeft?
De gratis ActCheck-scan loopt artikel 26 met u door en geeft u een rapport met openstaande punten per systeem.
Start de gratis check