Een privacyfunctionaris krijgt van de manager Bedrijfsvoering een spreadsheet met de titel "AI-register". Er staan vier regels in: Copilot, ChatGPT, DeepL en een transcriptietool voor vergaderingen. Diezelfde week vraagt iemand bij de servicedesk of het account voor een presentatietool met AI ook via de organisatie kan lopen, want hij betaalt het nu zelf. Die tool staat nergens.
Dat is het AI-register in één beeld: een lijst van wat de organisatie kent, naast een werkelijkheid die groter is. Dit stuk gaat over wat er in die lijst hoort, hoe hij zich verhoudt tot het verwerkingsregister uit de AVG, en waarom hij zonder een tweede bron nooit klopt.
Wat bedoelen organisaties met een AI-register?
Meestal dit: een overzicht van de AI-tools en AI-toepassingen die in de organisatie worden gebruikt, met per regel wie ervoor verantwoordelijk is, waarvoor het wordt ingezet, welke gegevens erin gaan en wat de organisatie erover heeft besloten. Het is een intern werkdocument. Het bestaat als spreadsheet, als tabblad in het verwerkingsregister, als lijst in een GRC-tool of als module in een product.
De vorm doet er minder toe dan de vraag die het register beantwoordt: weten we welke AI hier wordt gebruikt, en hebben we daar iets van gevonden? Wie die twee vragen niet kan beantwoorden, kan ook geen beleid uitleggen aan medewerkers, geen verwerkersovereenkomst op de juiste tool afsluiten en geen antwoord geven als een toezichthouder of accountant ernaar vraagt.
Eén misverstand meteen uit de weg: de AI Act schrijft niet aan iedere organisatie voor dat zij één universeel AI-register in een vaste vorm bijhoudt. Er zijn wel registratie- en documentatieverplichtingen, en die hangen af van je rol en van de systemen die je inzet. Hoe dat zit, staat in is een AI-register verplicht onder de AI Act. Dit stuk gaat over het register dat organisaties bijhouden omdat ze anders niet weten wat er gebeurt.
Tool, toepassing of use case: waar gaat een regel over?
De meeste registers beginnen op toolniveau, want dat is het makkelijkst: Copilot, ChatGPT, DeepL. Daar zit een probleem in. Een tool zegt weinig over het risico. Copilot voor een intern memo en Copilot voor het samenvatten van een sollicitatiegesprek zijn dezelfde tool en twee heel verschillende situaties.
Daarom helpt het om drie lagen uit elkaar te houden.
De tool is het product van de leverancier: Microsoft 365 Copilot, ChatGPT Team, DeepL Pro. Op deze laag leg je vast wie de leverancier is, waar de gegevens worden verwerkt, of er op je gegevens wordt getraind en welke overeenkomst eronder ligt.
De toepassing is hoe de organisatie die tool voor een bepaald doel heeft ingericht: Copilot in Teams voor gespreksverslagen bij HR, DeepL voor klantcorrespondentie bij de servicedesk. Op deze laag zit de eigenaar, het doel en de gegevens die erin gaan. Dit is de laag waar het risico woont, en de laag die een register meestal mist.
De use case is het concrete werk: een sollicitatiegesprek samenvatten, een klacht in het Engels beantwoorden. Use cases zijn er te veel om stuk voor stuk vast te leggen. Ze horen thuis in het beleid, als voorbeelden van wat wel en niet mag, niet in het register.
Een bruikbare vuistregel: het register kent een regel per toepassing, met de tool als eigenschap van die regel. Eén tool komt dan meerdere keren voor, en dat is precies goed.
Welke velden horen erin?
Er is geen voorgeschreven formaat. Dit zijn de velden die in de praktijk het werk doen, met de reden waarom.
| Veld | Wat je vastlegt | Waarom |
|---|---|---|
| Leverancier | Naam, land van vestiging, waar de verwerking plaatsvindt, of er op jouw gegevens wordt getraind | Bepaalt welke overeenkomst nodig is en welk toezichtregime geldt |
| Doel | Waarvoor de toepassing wordt gebruikt, in één zin | Zonder doel is geen beoordeling mogelijk en geen doelbinding onder de AVG |
| Eigenaar | De functie die verantwoordelijk is voor de toepassing, niet IT | Iemand moet de vragen kunnen beantwoorden en de herbeoordeling trekken |
| Risicobeoordeling | De uitkomst, de datum en wie hem deed; bij persoonsgegevens de link naar een DPIA | Maakt het besluit navolgbaar |
| Gegevensgebruik | Welke categorieën gegevens erin gaan, en welke expliciet niet | Hier zit het verschil tussen een memo en een sollicitatiegesprek |
| Besluit | Toegestaan, beperkt toegestaan, nog geen besluit, niet toegestaan, plus de voorwaarde bij beperkt | Dit is wat medewerkers moeten kunnen terugvinden |
| Datum van beoordeling | Wanneer het besluit is genomen | Een besluit zonder datum is niet te verdedigen |
| Herbeoordeling | Wanneer het besluit opnieuw wordt bekeken, en bij welke gebeurtenis eerder | Voorwaarden van leveranciers veranderen; het besluit moet mee |
Twee velden verdienen een toelichting. Het besluit hoort vier waarden te kennen, niet twee. Tussen toegestaan en niet toegestaan zit "beperkt toegestaan" (alleen met deze gegevens, alleen voor dit doel) en "nog geen besluit". Die laatste is geen gat in het register, het is een eerlijke status. Een tool die is opgemerkt maar nog niet beoordeeld staat er zo wél in, en dat is beter dan dat hij ontbreekt.
De herbeoordeling is het veld dat het vaakst leeg blijft, en het veld dat het register levend houdt. Leveranciers passen hun voorwaarden aan, een gratis account wordt een zakelijk account, een tool krijgt een nieuwe functie die documenten kan lezen. Een besluit van een jaar geleden zegt daar niets over. Zet een termijn en zet erbij welke gebeurtenis een eerdere herbeoordeling afdwingt: gewijzigde voorwaarden, een incident bij de leverancier, een nieuw gegevensgebruik.
Wat je de leverancier vraagt om de velden te vullen, staat in een AI-tool goedkeuren: welke vragen stel je de leverancier. Of er een verwerkersovereenkomst onder moet liggen, in heb je een verwerkersovereenkomst nodig voor een AI-tool.
Hoe verhoudt het zich tot het verwerkingsregister uit de AVG?
Ze lijken op elkaar en worden daarom vaak in elkaar geschoven. Dat gaat mis, omdat ze een andere vraag beantwoorden.
Het verwerkingsregister uit artikel 30 AVG beschrijft verwerkingen van persoonsgegevens: het doel, de categorieën betrokkenen en gegevens, de ontvangers, de bewaartermijn en de beveiligingsmaatregelen. Het gaat over gegevens, niet over techniek. Een salarisadministratie staat erin, of er nu AI aan te pas komt of niet.
Een AI-register beschrijft AI-systemen en wat de organisatie ermee doet. Een vertaaltool voor openbare productteksten hoort erin, ook al gaan er geen persoonsgegevens in. Een tool die nog geen besluit heeft hoort erin. Het gaat over de inzet van een technologie, niet over een verwerking.
De twee raken elkaar op één punt: een AI-toepassing die persoonsgegevens verwerkt. Die toepassing is in het verwerkingsregister een verwerking met een ontvanger (de leverancier), en in het AI-register een regel met een leverancier en een gegevensgebruik. Zet in beide een verwijzing naar de andere. Meer is niet nodig, en minder klopt niet: wie de twee samenvoegt, krijgt een register waarin de helft van de regels de velden van de andere helft niet kan invullen.
Wat laat een register zien, en wat niet?
Hier zit het punt waar de spreadsheet van de manager Bedrijfsvoering op stukloopt. Een register wordt gevuld door mensen die van een tool afweten. Het beschrijft dus wat de organisatie kent. Wat er gebruikt wordt, is een andere verzameling, en die is groter.
Een gemeente heeft Microsoft 365 Copilot toegestaan, met een beperking op documenten uit het sociaal domein. Het register telt zes regels. Bij een inventarisatie in het voorjaar blijken naast Copilot ook Perplexity en ChatGPT in gebruik, plus drie gespecialiseerde tools: een transcriptietool voor raadsvergaderingen, een tool die beleidsstukken herschrijft naar B1-niveau, en een beeldgenerator voor de communicatieafdeling. Twee daarvan staan nergens.
Dat is geen incident. Niemand heeft iets gedaan dat niet mocht, want over die twee tools was nog niets besloten. Het laat wel zien wat een eenmalige inventarisatie is: een foto van één moment, gemaakt door te vragen. Wie niet weet dat zijn tool AI is, meldt hem niet. Wie hem privé betaalt, meldt hem niet. En wie hem vorige week is gaan gebruiken, was er bij de inventarisatie nog niet. Waarom dat structureel is en niet op te lossen met vaker inventariseren, staat in waarom een AI-toolcatalogus veroudert zodra je hem afdrukt.
Het register heeft dus een tweede bron nodig: wat er in de organisatie feitelijk aan AI-tools wordt geopend. Niet wie, niet wat erin wordt getypt, alleen welke tools. Het verschil tussen die lijst en het register is de werkvoorraad: tools die een besluit nodig hebben. Wat die verzameling ongeregistreerde tools precies is en wat er wel en niet onder valt, staat in wat is shadow AI.
BeeSensible koppelt een catalogus van 865 AI-tools, elk met leverancier, land, certificeringen, trainingsbeleid en een risicoscore, aan het gebruik dat in de organisatie wordt waargenomen: de extensie meldt alleen het domein van een geopende AI-tool, hooguit één keer per dag per apparaat, zonder gebruikers-id en zonder inhoud. Een beheerder ziet welke tools nog geen besluit hebben en legt dat besluit vast; elke tool begint op "nog geen besluit". Meer over die werking staat op de pagina over AI-tools.
