AI-governance via de privacyfunctie: van intake tot FG-toezicht

Een uitvoeringsorganisatie, vierde kwartaal. Klantcontact test een AI-assistent die e-mails samenvat. HR heeft een wervingssysteem gekocht met een matchingfunctie die standaard aan staat. Het datateam bouwt een model dat aanvragen met een verhoogde kans op fouten markeert. Communicatie wil een chatbot op de website die vragen van burgers beantwoordt. Vier initiatieven, vier eigenaren, en niemand met het overzicht. Het bestuur vraagt wie "de AI Act gaat doen". De reflex: een nieuw programma, met een AI-board, een AI-officer, een eigen register en een eigen beoordelingsformulier. (Het voorbeeld is fictief, maar herkenbaar.)

Die reflex is naar mijn analyse meestal verkeerd. Een organisatie die de AVG serieus uitvoert, heeft het grootste deel van de machine al staan: een register, een risicobeoordeling, een moment vóór de aanschaf, vaak een onafhankelijke toezichthouder in huis, afspraken met leveranciers en een meldproces voor incidenten. AI-governance werkt het best als u die machine uitbreidt tot een operating model (TOM) voor AI, in plaats van ernaast een tweede machine te bouwen. Dit artikel laat zien hoe, en ook waar die machine tekortschiet.

Waarom de privacy officer het logische huis is voor AI-governance

De AI Act en de AVG overlappen op twee manieren. Ze gaan vaak over hetzelfde object: vrijwel elke AI-toepassing in een organisatie verwerkt persoonsgegevens, van prompts met namen tot modellen die over aanvragers oordelen. En ze werken met dezelfde methode: risicogericht, vooraf beoordelen, vastleggen, aantoonbaar maken. De wetgever heeft die verbinding zelf gelegd. Artikel 26 lid 9 AI Act bepaalt dat een gebruiksverantwoordelijke de informatie van de aanbieder gebruikt om zijn DPIA onder artikel 35 AVG uit te voeren. Artikel 27 lid 4 bepaalt dat de grondrechteneffectbeoordeling (FRIA) de DPIA aanvult als een deel van de plichten al via de DPIA is nagekomen. Dat is een uitnodiging om op de bestaande privacymachine voort te bouwen.

Hoe dat per instrument uitpakt:

Er is ook een praktische reden. De privacyfunctie heeft al wat een nieuw AI-programma eerst moet opbouwen: een mandaat, een lijn naar inkoop en informatiebeveiliging, een jaarcyclus met rapportage aan het bestuur, en mensen die gewend zijn om een projectleider op tijd lastige vragen te stellen. Opdrachtgevers die AI-governance willen inrichten, vragen in de praktijk steeds om dezelfde vier dingen: rollen en eigenaarschap, risicoclassificatie, een AI-register en controls. In privacyrollen staat kennis van de AI Act steeds vaker als pré. Die hybride rol, een privacy officer die de AI Act kent, is precies wat dit werkmodel vraagt.

Waar de privacyfunctie niet genoeg is

Het chassis is niet de hele auto. Wie AI-governance volledig in de privacyhoek legt, mist vier dingen.

AI zonder persoonsgegevens. Een onderhoudsvoorspeller voor pompen is meestal geen hoog risico, maar een AI-component die als veiligheidscomponent het beheer van een drinkwater- of energienet aanstuurt, kan dat wel zijn (bijlage III punt 2). Geen van beide verwerkt persoonsgegevens. Een intake die begint met "verwerkt het persoonsgegevens?" laat zulke toepassingen door. De eerste vraag moet daarom zijn: is het AI?

Productveiligheid en aanbiedersplichten. Wie zelf een AI-systeem ontwikkelt en onder eigen naam in gebruik stelt, is aanbieder (artikel 3 punt 3). Dat geldt ook voor een eigen chatbot of assistent op een taalmodel van een leverancier, met de transparantieplichten van artikel 50 lid 1 en lid 2 die nu al gelden. Daarnaast wordt een gebruiksverantwoordelijke aanbieder van een hoog-risicosysteem als zij er haar naam op zet, het wezenlijk wijzigt, of het beoogde doel zo wijzigt dat het hoog risico wordt (artikel 25 lid 1 onder a, b en c; zie de drie routes naar het aanbiederschap). Voor hoog-risicosystemen gelden dan plichten met een productveiligheidslogica: een kwaliteitsbeheersysteem (artikel 17), technische documentatie (artikel 11), een conformiteitsbeoordeling (artikel 43) en monitoring na het in de handel brengen (artikel 72). Dat is werk voor ontwikkeling en kwaliteitsborging. De privacyfunctie signaleert het, maar voert het niet uit.

AI-geletterdheid in de hele organisatie. Artikel 4 verplicht de organisatie maatregelen te nemen voor iedereen die namens haar AI-systemen bedient of gebruikt, of daar nu persoonsgegevens in zitten of niet. Sinds de Digital Omnibus (Verordening (EU) 2026/1744, in werking sinds 27 juli 2026) is het een plicht om maatregelen te nemen die de ontwikkeling van AI-geletterdheid ondersteunen, zonder dat de organisatie per persoon een bepaald niveau hoeft te garanderen. De lijn voert die maatregelen uit, de AI-lead is eindverantwoordelijk en HR of opleidingen organiseert ze; de privacy officer is er geen eigenaar van. Die kan wel het bewijs bundelen (zie de scorecard voor artikel 4-bewijs).

Grondrechten breder dan privacy. Een FRIA gaat ook over gelijke behandeling, toegang tot voorzieningen en de gevolgen voor kwetsbare groepen. Een privacy officer kan die beoordeling organiseren, maar heeft daarvoor domeinkennis uit het proces nodig, en soms de mensen om wie het gaat.

De grens is dus: de privacyfunctie draait het proces (intake, register, beoordeling, toezichtcyclus) en bewaakt de samenhang. De inhoud van plichten die niet over gegevensbescherming gaan, ligt bij de eigenaar van het systeem, ontwikkeling, informatiebeveiliging of HR. Leg dat onderscheid op papier vast, anders wordt de privacy officer stilzwijgend verantwoordelijk voor alles waar "AI" op staat.

Het werkmodel voor AI-governance: van AI-intake tot AI-register

Het werkmodel hieronder is mijn aanbevolen opzet, geen wettelijk voorgeschreven vorm. De AI Act schrijft geen register, intakeformulier of AI-officer voor; die maken de plichten wel aantoonbaar.

De triage uitgewerkt: vier fictieve aanvragen

De vier aanvragen uit de opening, door de triage gehaald. Het voorbeeld is fictief en de uitkomsten zijn mijn eigen analyse; in een echte casus hangt de klasse af van het beoogde doel en de feitelijke inzet.

Drie details uit de triage maken het verschil. Ten eerste de verboden praktijken: artikel 5 is van kracht sinds 2 februari 2025, en de nieuwe verboden op AI voor seksueel misbruik van kinderen en niet-consensuele intieme beelden gelden vanaf 2 december 2026. Ten tweede de uitzondering van artikel 6 lid 3: een systeem in een bijlage III-domein is geen hoog risico als het geen significant risico vormt en alleen een van vier taken uitvoert: een beperkte procedurele taak, het verbeteren van het resultaat van eerder voltooid menselijk werk, het opsporen van besluitpatronen of afwijkingen daarvan zonder de menselijke beoordeling te vervangen, of een voorbereidende taak. Een bijlage III-systeem dat profilering van natuurlijke personen uitvoert, blijft altijd hoog risico (artikel 6 lid 3, laatste alinea). De aanbieder documenteert die afweging en registreert ook een systeem dat hij als uitgezonderd beschouwt in de EU-databank (artikel 6 lid 4 met artikel 49 lid 2); als gebruiksverantwoordelijke vraagt u de afweging op en controleert u de registratie. Ten derde de rol: artikel 50 lid 1 en lid 2 rusten op de aanbieder, lid 3 en lid 4 op de gebruiksverantwoordelijke.

Wanneer de FRIA aanschuift, en wat er geldt voor systemen die al draaien

De FRIA komt erbij als drie dingen samenvallen. Het systeem is hoog risico onder bijlage III, behalve punt 2 (kritieke infrastructuur). U bent een publiekrechtelijke instelling, een particuliere organisatie die openbare diensten verleent, of een gebruiksverantwoordelijke voor kredietwaardigheid of levens- en ziektekostenverzekering (bijlage III punt 5 onder b en c). En de toepassingsdatum is bereikt: 2 december 2027. Na de beoordeling meldt u de uitkomst met het sjabloon van het AI-bureau aan de markttoezichtautoriteit (artikel 27 lid 3), en u werkt de FRIA bij als de omstandigheden veranderen (artikel 27 lid 2). Maak er één document van, met de DPIA als basis (zie DPIA en FRIA vergeleken en het FRIA-sjabloon).

Voor een systeem dat al vóór 2 december 2027 in de handel of in gebruik was, gelden de hoog-risicoplichten, de FRIA inbegrepen, pas bij een aanzienlijke wijziging van het ontwerp. Is het systeem bedoeld voor gebruik door overheidsinstanties, dan moet het uiterlijk 2 augustus 2030 aan de eisen voldoen (artikel 111 lid 2). Artikel 4 en artikel 50 gelden voor die systemen gewoon nu al.

Controls en aansluiting op informatiebeveiliging

Een CISO of auditor wil geen werkmodel lezen, maar controls toetsen. De zes bouwstenen vertalen zich in zes controls die in de bestaande risico- en controlcyclus van de BIO2 of ISO 27001 passen. ISO/IEC 42001 is een bruikbaar kader voor een AI-managementsysteem, maar geen plicht onder de AI Act.

Het AI-register naast het verwerkingsregister: de velden

Dit is de minimale set die ik aanbeveel. De meeste velden bestaan al in een goed verwerkingsregister; de AI-velden komen ernaast.

Rollen en eigenaarschap: de RACI voor AI-governance

AI-governance strandt zelden op kennis en vaak op eigenaarschap. Onderstaande RACI is een startpunt, door mij opgesteld voor een middelgrote organisatie; pas hem aan op uw eigen structuur. R is uitvoerend, A eindverantwoordelijk, C geraadpleegd, I geïnformeerd. Eigenaar staat voor de proces- of producteigenaar, PO voor de privacy officer, IM voor de informatiemanager, en AI-lead voor de AI-lead, CDO of wie het AI-proces coördineert.

Drie keuzes in deze tabel zijn bewust. De eigenaar van het proces is eindverantwoordelijk voor de DPIA en de inzet, niet de privacy officer; onder de AVG rust de plicht op de organisatie als verwerkingsverantwoordelijke, en intern hoort die bij wie het proces runt. Het bestuur besluit over ingebruikname, in elk geval bij hoog risico; bij lichte toepassingen kunt u dat mandateren. En de FG staat nergens als eigenaar van een besluit. Twee regels vragen uitleg. De A van het bestuur bij toezicht op naleving betekent dat het bestuur verantwoordelijk is voor de naleving zelf, niet dat het stuurt hoe de FG toezicht houdt: de FG krijgt geen instructies. En de FG rapporteert naast de AI-lead langs een eigen lijn rechtstreeks aan het hoogste leidinggevende niveau (artikel 38 lid 3 AVG). HR staat niet in de tabel, maar organiseert de maatregelen voor AI-geletterdheid die de lijn uitvoert.

De meeste wrijving zie ik in de praktijk op één regel: wie de DPIA tekent. De proceseigenaar ziet de DPIA als iets van de privacy officer, de privacy officer ziet zich als schrijver van andermans risicoafweging. Leg vooraf vast dat de privacy officer de DPIA opstelt en de eigenaar het restrisico accepteert en tekent. Een bewerkbare versie staat in de RACI-matrix AI-governance, en een bredere opzet in het AI-governanceframework.

Wat de FG doet bij AI: adviseren en toezien, niet besluiten

De FG is de spil van deze opzet, juist omdat hij geen eigenaar is. Een FG is verplicht voor overheden en voor organisaties die als kernactiviteit op grote schaal monitoren of bijzondere of strafrechtelijke gegevens verwerken (artikel 37 AVG). Hebt u geen FG, beleg de toetsende rol dan bij een onafhankelijke functie, zoals compliance of interne audit, of bij een externe FG; een privacy officer is niet automatisch een FG. Wie vrijwillig een FG aanstelt, valt onder hetzelfde regime van de artikelen 38 en 39.

De taken staan in artikel 39 AVG: informeren en adviseren, toezien op naleving, desgevraagd advies geven over de DPIA en toezien op de uitvoering ervan, samenwerken met de AP en optreden als contactpunt voor de AP. Die DPIA-vraag is niet vrijblijvend: de organisatie moet het advies van de FG inwinnen (artikel 35 lid 2). Bij de uitvoering houdt de FG rekening met het risico van verwerkingen (artikel 39 lid 2): een goede grond om AI-toepassingen voorrang te geven in het toezichtplan. De positie staat in artikel 38: de FG krijgt geen instructies over de uitvoering van die taken, wordt niet ontslagen of gestraft voor het uitvoeren ervan en rapporteert rechtstreeks aan het hoogste leidinggevende niveau (lid 3). Een FG mag andere taken hebben, maar de organisatie zorgt ervoor dat die niet tot een belangenconflict leiden (lid 6). Of dat zo is, beoordeelt u per geval, zo bevestigde het Hof van Justitie in X-FAB (C-453/21, 9 februari 2023).

De richtsnoeren van de Europese toezichthouders over de FG (WP243, door de EDPB overgenomen) maken dat concreet: een FG kan geen functie hebben waarin hij de doelen en middelen van verwerkingen bepaalt. Voor AI betekent dat naar mijn analyse:

• De FG besluit niet of een AI-toepassing in gebruik gaat, en is geen eigenaar van het AI-programma.
• De FG schrijft de DPIA niet zelf; de organisatie voert hem uit, de FG adviseert en ziet toe op de uitvoering.
• De FG mag het register bijhouden onder verantwoordelijkheid van de organisatie (WP243 sluit dat niet uit), zolang de inhoudelijke keuzes bij de eigenaren liggen.
• Een gecombineerde rol als FG en "AI-toezichthouder" kan, als ook die AI-rol adviserend en toetsend is. Een FG die tegelijk AI-lead is en over inzet beslist, toetst zijn eigen werk.

De Europese Commissie kreeg in haar vragen en antwoorden over AI-geletterdheid precies de vraag of een AI-officer nodig is zoals onder de AVG, en of een FG en een AI-officer dezelfde persoon kunnen zijn. Haar antwoord: voor artikel 4 is geen specifieke governancestructuur verplicht, dus geen AI-officer en geen AI-board. Ook elders in de AI Act staat geen AI-officer (eigen analyse). De keuze om de FG een toetsende AI-rol te geven, ligt dus bij de organisatie. De AP benadrukte in haar uitgangspunten voor de positionering van de FG (2021) dat de organisatie de FG vroeg moet betrekken, met hem moet vastleggen wat er met zijn adviezen gebeurt en zijn onafhankelijke positie moet waarborgen. Bij AI is dat extra belangrijk, omdat de druk om snel te starten groot is. Betrek de FG dus bij de triage, niet pas bij de handtekening. Hebt u geen of een overbelaste FG, dan kan die rol ook worden ingevuld als externe FG met AI-toezicht.

Gemeenten: algoritmeregister, IAMA en de AP als coördinerend toezichthouder

Voor gemeenten en uitvoeringsorganisaties komt er een eigen laag bovenop, die goed op dezelfde machine past.

Het algoritmeregister. Registratie in het algoritmeregister van de Nederlandse overheid is voor geen enkele overheid een wettelijke plicht; het register zegt zelf dat aanleveren nu nog niet verplicht is. Wel is het beleid: het Algoritmekader vraagt overheden impactvolle algoritmes en hoog-risico-AI te publiceren, en de AP pleit voor een wettelijke registratieplicht. Het is ook de norm waaraan burgers, raad en toezichthouder u meten. Houd het intern bij in uw eigen register en publiceer daaruit. Verwar het niet met de registratie in de EU-databank, die wel verplicht is: een overheidsinstantie die een hoog-risicosysteem uit bijlage III gebruikt, moet zichzelf, het systeem en het gebruik daar vanaf 2 december 2027 registreren (artikel 49 lid 3 en artikel 26 lid 8; voor systemen die al draaien: artikel 111 lid 2), behalve bij kritieke infrastructuur. Eén intern register voedt dus twee publicaties. Zie registratie van AI-systemen en het overzicht van wat overheden al registreren.

IAMA en Algoritmekader. Het Impact Assessment Mensenrechten en Algoritmes is in februari 2026 vernieuwd: korter, met een apart toelichtingsdocument, en in lijn gebracht met artikel 27, met de vragen die direct met de AI-verordening samenhangen herkenbaar gemarkeerd. Gebruik het IAMA als methode voor de FRIA waar artikel 27 van toepassing is, maar controleer per onderdeel of alle elementen van artikel 27 lid 1 erin zitten; gebruik het vrijwillig voor andere impactvolle algoritmes. Het Algoritmekader van BZK bundelt de eisen en maatregelen per fase van de levenscyclus en is een bruikbare checklist naast uw eigen werkmodel. Meer in de FRIA voor gemeenten.

De AP als coördinerend algoritmetoezichthouder. De AP is sinds januari 2023 coördinerend algoritmetoezichthouder en publiceert een werkagenda voor dit toezicht. De formele aanwijzing van de Nederlandse toezichthouders onder de AI Act loopt via de Uitvoeringswet AI-verordening, die nog een wetsvoorstel is. Tot de aanname kan een Nederlandse toezichthouder geen AI Act-boete opleggen, maar de AP kan via de AVG nu al optreden waar persoonsgegevens in het geding zijn; zie wie in Nederland wat controleert. Voor de privacyfunctie maakt dat het gesprek eenvoudiger: de toezichthouder op de AVG is ook de partij die het algoritmetoezicht coördineert. Welke stukken u dan op tafel moet kunnen leggen, staat in het stuk over een AP-uitvraag.

Copilot als eerste test. Het advies van de AP over Microsoft 365 Copilot bij de gemeente Haarlemmermeer laat zien waarom het chassisdenken klopt. Het eerste blok maatregelen gaat helemaal niet over AI, maar over de basis: een actueel verwerkingsregister, het labelen van documenten, autorisaties en de cloudomgeving. Het tweede blok gaat over doelbinding, juistheid, geautomatiseerde besluitvorming en informatie aan burgers. Dat is privacywerk. Het derde blok gaat over Copilot zelf, met als harde voorwaarde dat Microsoft voldoende transparant is over servicegegevens en bewaartermijnen; dat lost u niet intern op, maar via inkoop en contract (bouwsteen 5). Wie zijn privacymachine op orde heeft, heeft dus een groot deel van het voorwerk al gedaan. De uitwerking staat in de Copilot-DPIA na het AP-advies en het Copilot-DPIA-pakket; voor menselijke tussenkomst bij besluiten over burgers, zie betekenisvolle menselijke tussenkomst in de praktijk en menselijk toezicht in de publieke sector.

Een startplan voor 90 dagen

Drie maanden is genoeg om het werkmodel te laten draaien, niet om alles af te hebben. Dit is de volgorde die ik aanraad. In de praktijk loopt het eerste kwartaal vooral vast op de inventaris: afdelingen melden wat ze zelf hebben gekocht, maar niet wat een leverancier in bestaande software heeft aangezet. Begin daarom bij de licentie- en leverancierslijsten, niet bij de uitvraag.

Dag 1 tot 30: afspreken en zichtbaar maken. Laat het bestuur op één pagina vastleggen dat AI-governance via de privacyfunctie loopt, wie AI-lead is en welke grens geldt voor wat niet over privacy gaat. Stel de RACI vast. Maak een eerste inventaris: de licentielijsten, de lijst van leveranciers met AI-functies in bestaande software en een korte uitvraag aan afdelingen (gebruik eventueel de inventarisatiehulp). Zet het aanmeldformulier live en voeg de AI-velden toe aan het register.

Dag 31 tot 60: beoordelen wat er al draait. Trieer de inventaris en kies de drie tot vijf toepassingen met het hoogste risico. Voer daarop de DPIA-AI-aanvulling uit of werk de bestaande DPIA bij, en stuur de leveranciersvragen uit. Stel het AI-gebruiksbeleid vast. Controleer de transparantieplichten die nu al gelden: een chatbot die met burgers of klanten praat (de meldplicht van artikel 50 lid 1 rust op de aanbieder; controleer dat uw leverancier die heeft ingebouwd, of dat u zelf aanbieder bent), en als gebruiksverantwoordelijke deepfakes en AI-tekst die u publiceert om het publiek te informeren (lid 4; zie artikel 50 geldt nu). Leg per rol de maatregelen voor AI-geletterdheid vast (artikel 4-bewijsdossier).

Dag 61 tot 90: de cyclus sluiten. Voeg AI-incidenten toe aan het meldproces en test het met één oefencasus. Lever het eerste kwartaalrapport aan het bestuur: aantal aanmeldingen, risicoverdeling, open maatregelen, besluiten. Laat de FG een eerste toezichtronde op het AI-proces doen en rapporteren. Maak voor elke toepassing die na de triage hoog risico is een plan richting 2 december 2027: het dossier van de gebruiksverantwoordelijke (sjabloon hoog-risico-AI) en de FRIA waar die geldt. Voor een systeem dat nu al draait, valt het onder artikel 111 lid 2; toets dan bij elke geplande model- of ontwerpwijziging of dat een aanzienlijke wijziging is, en houd bij overheidssystemen 2 augustus 2030 als uiterste datum aan.

Wilt u dit startplan niet alleen lezen maar laten draaien, dan kunt u mij inhuren als AI- en privacyjurist om het samen met uw privacy officer op te zetten.

Zeven fouten die het werkmodel ondermijnen

1. Een tweede register naast het verwerkingsregister. Twee registers lopen binnen een jaar uit elkaar, en dan klopt geen van beide.
2. De intake laten afgaan op persoonsgegevens. Dan mist u precies de AI zonder persoonsgegevens die hoog risico kan zijn, en de AI-geletterdheid die voor elk systeem geldt.
3. De FG eigenaar maken van AI-besluiten. Dat schept een belangenconflict (artikel 38 lid 6 AVG), ondergraaft zijn onafhankelijke positie (artikel 38 lid 3) en haalt de eigenaar uit zijn verantwoordelijkheid.
4. Ingebouwde AI-functies overslaan. Een update die een AI-assistent aanzet in uw zaaksysteem of kantoorsoftware is een nieuwe toepassing, ook zonder aanbesteding.
5. De FRIA overal of nergens. Artikel 27 geldt niet voor elke gebruiksverantwoordelijke van een hoog-risicosysteem, niet voor kritieke infrastructuur en pas vanaf 2 december 2027 (voor systemen die al draaien: artikel 111 lid 2); maar wie in scope is en wacht, heeft straks een dossier zonder fundament.
6. Pilots buiten de governance houden. Het Copilot-advies ging over een pilot met 15 tot 20 medewerkers, en de AP wees de gedachte af dat zo'n pilot geen nieuwe verwerking oplevert: "ook een pilot aan de AVG moet voldoen." Een pilot is bovendien het goedkoopste moment voor de intake.
7. Artikel 4 afvinken met één cursus. De plicht vraagt maatregelen die passen bij rol, kennis en context. Leg vast wat u per groep doet, niet alleen wie een video heeft gezien.

AI-governance laten inrichten door een AI- en privacyjurist

Dit werkmodel is bewust gebouwd op wat een privacyfunctie al kan. De lastige stappen zitten in de overgangen: de triage tussen AVG en AI Act, de grens tussen advies en besluit, en de eerste beoordelingen van wat al draait. Daar help ik organisaties mee. Wilt u dat iemand die beide wetten kent dit samen met uw privacy officer en FG opzet, dan kunt u mij inhuren als AI- en privacyjurist, interim of per project. Hebt u geen of een overbelaste FG, dan kan het ook als externe FG met AI-toezicht. En wilt u een onafhankelijk oordeel over een DPIA, FRIA of classificatie, met mijn naam eronder, kijk dan naar de beoordeling met handtekening.