Waarom moet ik als externe professional de AI-training van mijn opdrachtgever volgen?
25 aug 2026

Waarom moet ik als externe professional de AI-training van mijn opdrachtgever volgen?
Ik werk regelmatig in de systemen van opdrachtgevers. En wie toegang krijgt tot de digitale werkomgeving van een grotere organisatie kent het ritueel waarschijnlijk wel.
Eerst de privacytraining. Daarna security awareness. Phishing, sterke wachtwoorden, verdachte situaties melden, geen gegevens naar privéaccounts sturen. En tegenwoordig komt daar steeds vaker een derde categorie bij: AI-awareness of AI-geletterdheid.
Dat roept een interessante vraag op.
Ik ben geen werknemer van die opdrachtgever. Ik heb vanuit mijn eigen organisatie al kennis van privacy, informatiebeveiliging en AI. Waarom zou een opdrachtgever mij dan óók moeten instrueren?
En sinds de wijzigingen van de AI Act door de AI Omnibus is de algemene verplichting rond AI-geletterdheid bovendien gewijzigd. Is zo'n AI-training dan juridisch nog wel nodig?
Het korte antwoord is: AI-geletterdheid is maar een deel van het verhaal.
De interessantere verklaring ligt op het snijvlak van privacy, security en AI-governance.
Toegang tot een systeem betekent toegang tot risico's
Neem een vrij alledaags voorbeeld.
Een externe adviseur krijgt een account in de Microsoft 365-omgeving van een opdrachtgever. Daarmee krijgt hij toegang tot Teams, SharePoint en bepaalde dossiers. Binnen diezelfde omgeving is inmiddels ook generatieve AI beschikbaar.
Technisch gezien is dat vooral een autorisatievraagstuk.
Juridisch gebeurt er veel meer.
De externe gebruiker kan persoonsgegevens raadplegen. Hij kan documenten downloaden of delen. Hij kan informatie in een AI-systeem invoeren. Afhankelijk van de configuratie kan een AI-assistent informatie uit verschillende bronnen ophalen en combineren. En de output kan vervolgens worden gebruikt voor werkzaamheden of zelfs besluitvorming.
Daarom is alleen vaststellen wie toegang krijgt onvoldoende.
Een organisatie moet ook bepalen onder welke voorwaarden iemand die toegang mag gebruiken.
Dat is precies waar training en instructie een rol krijgen.
Bij privacy volgt die verantwoordelijkheid niet uit één trainingsartikel
De AVG bevat geen artikel waarin staat dat iedere externe gebruiker jaarlijks een privacytraining moet afronden.
Toch kan training wel degelijk onderdeel zijn van AVG-compliance.
Artikel 5 lid 2 AVG verplicht de verwerkingsverantwoordelijke naleving van de gegevensbeschermingsbeginselen te kunnen aantonen. Artikel 24 verlangt passende technische en organisatorische maatregelen. Artikel 25 brengt privacy by design en by default mee en artikel 32 verlangt passende beveiligingsmaatregelen, afgestemd op het risico.
Daarbij bestaat een belangrijk onderscheid tussen technische en organisatorische maatregelen.
Een opdrachtgever kan technisch afdwingen dat mijn account alleen bepaalde dossiers kan openen. Dat is toegangsbeveiliging.
Maar techniek voorkomt niet noodzakelijk dat ik persoonsgegevens in een verkeerde applicatie plak, informatie naar een verkeerde ontvanger stuur of een AI-functie gebruik voor een doel waarvoor deze niet is toegestaan.
Daarvoor zijn ook organisatorische maatregelen nodig: beleid, instructies, autorisaties, training, toezicht en procedures voor incidenten.
Een privacytraining is vanuit dat perspectief dus geen doel op zichzelf. Het is één van de middelen waarmee een organisatie probeert haar gegevensverwerking beheerst te organiseren.
Bij security zien we hetzelfde patroon
Hetzelfde geldt voor informatiebeveiliging.
Stel dat een externe professional toegang krijgt tot een netwerk waarin behalve werkstations ook printers, camera's en andere connected devices aanwezig zijn.
Dan wil je niet alleen dat technisch maatregelen zijn getroffen. Je wilt ook dat gebruikers begrijpen waarom bijvoorbeeld standaardwachtwoorden moeten worden gewijzigd, ongebruikte functionaliteiten worden uitgeschakeld, updates belangrijk zijn en afwijkend gedrag moet worden gemeld.
Daarachter zitten bekende beveiligingsprincipes: least privilege, netwerksegmentatie, beperking van het aanvalsoppervlak, vulnerability management en incident response.
Ook hier is awareness dus maar één laag.
Een training die vertelt dat een standaardwachtwoord gevaarlijk is, compenseert niet voor een organisatie die vervolgens overal standaardwachtwoorden laat staan.
Bewustzijn vervangt technische beheersmaatregelen niet.
En precies daar wordt de vergelijking met AI interessant.
En toen kwam AI-geletterdheid
De oorspronkelijke AI Act introduceerde namelijk iets dat veel leek op een expliciete wettelijke awarenessverplichting.
Artikel 4 verplichtte aanbieders en gebruiksverantwoordelijken van AI-systemen maatregelen te nemen om, rekening houdend met onder meer technische kennis, ervaring, opleiding en gebruikscontext, een voldoende niveau van AI-geletterdheid te waarborgen bij personeel en andere personen die namens hen met AI-systemen werken.
Dat was relevant voor externen.
De bepaling keek immers niet uitsluitend naar werknemers, maar ook naar andere personen die namens een organisatie met AI-systemen werkten.
Maar inmiddels is het juridische speelveld veranderd.
De AI Omnibus verandert de discussie
Met de AI Omnibus is de algemene regeling over AI-geletterdheid vereenvoudigd. De nadruk verschuift naar de Europese Commissie en de lidstaten, die AI-geletterdheid moeten bevorderen en organisaties daarbij moeten ondersteunen, in plaats van een weinig gespecificeerde algemene verplichting voor operators te handhaven.
Tegelijkertijd verdwijnen opleidingsverplichtingen niet volledig uit de AI Act. Voor gebruiksverantwoordelijken van hoog-risico-AI blijven specifieke verplichtingen relevant.
Dat maakt de vraag voor mijn opdrachtgever eigenlijk interessanter.
Als de algemene AI-literacyverplichting wordt afgezwakt, waarom mij dan nog een AI-training laten volgen?
Omdat AI-governance groter is dan AI-geletterdheid.
Een AI-training kan een passende organisatorische maatregel zijn
Stel dat ik toegang krijg tot een door mijn opdrachtgever goedgekeurde generatieve AI-assistent.
Dan moet ik bijvoorbeeld weten of ik daarin cliëntgegevens mag verwerken. Of bijzondere persoonsgegevens zijn toegestaan. Of ik vertrouwelijke documenten mag uploaden. Welke databronnen het systeem kan benaderen. Of output altijd moet worden gecontroleerd. En wat ik moet doen wanneer het systeem onverwacht persoonsgegevens toont.
Dat zijn gedeeltelijk AI-vragen.
Maar het zijn tegelijkertijd privacy- en securityvragen.
Bij verwerking van persoonsgegevens blijft de AVG immers gewoon van toepassing. De EDPB heeft bovendien benadrukt dat bij AI-modellen niet zonder meer kan worden aangenomen dat persoonsgegevens door opname in of verwerking met een model hun karakter als persoonsgegevens verliezen. Ook de vraag of een model als anoniem kan worden beschouwd, vergt een concrete beoordeling.
Pseudonimisering lost dat evenmin automatisch op: gepseudonimiseerde gegevens kunnen nog steeds persoonsgegevens zijn.
Vanuit de AVG kan het daarom heel goed verdedigbaar zijn dat een opdrachtgever gebruikers instrueert over verantwoord AI-gebruik als onderdeel van zijn organisatorische maatregelen.
Niet omdat iedere externe professional noodzakelijk dezelfde algemene AI-cursus nodig heeft, maar omdat de opdrachtgever moet beheersen hoe zijn eigen systemen en gegevens worden gebruikt.
Dat maakt context belangrijker dan een certificaat
Daar zit wat mij betreft ook de zwakte van veel compliance-trainingen.
Ik kan een algemene AI-training afronden waarin wordt uitgelegd wat een Large Language Model is, dat AI kan hallucineren en dat ik voorzichtig moet zijn met persoonsgegevens.
Prima.
Maar daarmee weet ik nog niet:
welke AI-systemen deze opdrachtgever heeft toegestaan;
welke gegevens ik daarin mag verwerken;
welke AI-functionaliteiten in zijn omgeving actief zijn;
voor welke werkzaamheden AI wel en niet mag worden gebruikt;
wanneer menselijke controle verplicht is;
welke output ik moet verifiëren; en
bij wie ik een AI-, privacy- of securityincident moet melden.
Juist die informatie maakt een training relevant voor de concrete organisatie.
Een generieke cursus kan mijn AI-geletterdheid vergroten. Een organisatiespecifieke instructie helpt de opdrachtgever zijn AI-governance daadwerkelijk uit te voeren.
Dat onderscheid wordt naar mijn mening na de AI Omnibus alleen maar belangrijker.
En wie is eigenlijk verantwoordelijk?
Daarmee komen we bij een juridisch interessantere vraag dan alleen “moet ik deze training volgen?”
Een opdrachtgever kan zijn verantwoordelijkheid niet volledig naar de gebruiker verschuiven.
Wanneer een organisatie AI beschikbaar stelt aan medewerkers en externen, moet zij zelf nadenken over de inrichting daarvan. Welke toepassing wordt toegestaan? Welke leverancier wordt gebruikt? Welke persoonsgegevens worden verwerkt? Welke rollen bestaan onder de AVG en AI Act? Welke toegang is noodzakelijk? Welke logging vindt plaats? Welke contractuele afspraken gelden? Is een DPIA noodzakelijk? En zijn aanvullende technische maatregelen mogelijk?
Een vinkje achter “gebruiker heeft AI-awarenesstraining voltooid” is geen vervanging voor die analyse.
Dat kennen we al uit cybersecurity.
Als een organisatie iedere medewerker een phishingtraining geeft maar geen MFA implementeert waar dat redelijkerwijs noodzakelijk is, wordt een beveiligingsprobleem niet ineens het probleem van de medewerker.
Bij AI zou hetzelfde uitgangspunt moeten gelden.
Train waar menselijk handelen een beheersmaatregel is. Beperk technisch waar menselijk handelen niet de enige verdedigingslinie zou mogen zijn.
Privacy, security en AI komen daarmee steeds dichter bij elkaar
Mijn verplichte trainingen bij opdrachtgevers lijken dus misschien drie afzonderlijke complianceonderwerpen.
In werkelijkheid vertellen ze steeds meer hetzelfde verhaal.
Privacy vraagt dat persoonsgegevens rechtmatig en beheerst worden verwerkt.
Security vraagt dat systemen en informatie passend worden beschermd.
AI-governance voegt daar vragen aan toe over het verantwoord inzetten en beheersen van AI-systemen en hun output.
En bij alle drie geldt uiteindelijk hetzelfde principe: een organisatie moet niet alleen regels op papier hebben, maar deze vertalen naar de mensen en techniek die de verwerking daadwerkelijk uitvoeren.
Ik blijf daarom bij al mijn opdrachtgevers braaf alle trainingen volgen. Maar zullen we er dan ook voor zorgen dat de mensen die toegang hebben tot systemen en gegevens daadwerkelijk weten wat zij met AI mogen doen, welke persoonsgegevens en andere data zij daarbij wel en niet mogen gebruiken, én dat de omgeving zo is ingericht dat zij dat veilig kunnen doen?
Dat is geen kwestie van alleen AI-geletterdheid.
Dat is privacy, security en AI-compliance in samenhang.