Meer in de kennisbank over AI-compliance
AI-compliance / RegisterAI-register opzetten: alle AI-systemen inventariseren.
Praktische gids voor het bouwen van een compleet AI-register. Met template voor alle verplichte velden, een 8-stappen-aanpak, review-cyclus, tooling-vergelijking en een checklist met 45+ actiepunten om niets te missen.

- Artikel 49 verplicht registratie van high-risk AI in de EU-database
- 18 kernvelden per AI-systeem vormen de basis van je register
- Schaduw-AI opsporen voorkomt blinde vlekken bij toezichthouder
- Halfjaarlijkse review plus event-triggers houden het register actueel
Waarom elke organisatie een AI-register nodig heeft.
Een AI-register is de fundatie onder AI-compliance. Zonder overzicht van welke AI-systemen je organisatie gebruikt, ontwikkelt of distribueert, kun je geen enkele verplichting uit de AI Act (Verordening 2024/1689) betrouwbaar nakomen. Je kunt geen risicoclassificatie uitvoeren als je niet weet welke systemen je hebt. Je kunt geen deployer-verplichtingen naleven als je niet weet waar je deployer bent. En je kunt Artikel 4 AI-geletterdheid niet invullen als je niet weet op welke AI je medewerkers moet trainen.
De AI Act schrijft op meerdere plaatsen voor dat je informatie over je AI-systemen beschikbaar hebt. Artikel 49 verplicht aanbieders en bepaalde deployers van high-risk AI-systemen om hun systemen te registreren in de EU-database voordat het systeem op de markt of in gebruik wordt genomen. Artikel 26 verplicht deployers om AI-systemen conform het beoogde doel te gebruiken, te monitoren en logs te bewaren. Artikel 9 vereist een risicomanagement-systeem per high-risk AI-systeem. Al deze verplichtingen veronderstellen dat je weet welke AI je hebt, wie er verantwoordelijk voor is, en hoe het wordt ingezet.
In de praktijk zien we dat MKB-organisaties (10-250 FTE) gemiddeld 3 tot 25 AI-systemen in gebruik hebben, waarvan minstens de helft niet centraal bekend is. Dat is schaduw-AI: medewerkers die zelfstandig tools als ChatGPT, Copilot, Jasper of andere AI-diensten gebruiken zonder dat IT of management ervan weet. Een AI-register maakt dit zichtbaar en beheersbaar.
Deze gids beschrijft stap voor stap hoe je een AI-register opzet: welke velden erin moeten, hoe je alle systemen opspoort, hoe je het register bijhoudt, en welke tooling bij welke schaalgrootte past. Alle verwijzingen naar artikelen betreffen de AI Act tenzij anders vermeld.
Intern register versus EU-database
Je interne AI-register is breder dan de EU-database uit Artikel 49. De EU-database bevat alleen high-risk AI en bepaalde transparantie-eis-systemen. Je interne register bevat alle AI-systemen, inclusief minimal-risk. Zonder intern register kun je de EU-database niet correct vullen en heb je geen totaalbeeld voor governance.
De AI Act-artikelen achter het register.
Meerdere artikelen in de AI Act veronderstellen dat je een actueel overzicht van je AI-systemen bijhoudt. Hier zijn de belangrijkste.
Artikel 49 - EU-database registratie
Aanbieders van high-risk AI-systemen moeten hun systemen registreren in de EU-database voordat het systeem op de markt wordt gebracht of in gebruik wordt genomen. Deployers van high-risk AI moeten zich eveneens registreren waar dat van toepassing is. De informatie die je bij de EU-database moet aanleveren (Annex VIII) omvat onder meer: naam van het systeem, naam en adres van de aanbieder, beoogd doel, risicoclassificatie, status van conformity assessment, en lidstaten waar het systeem beschikbaar is. Opvallend: ook aanbieders die claimen dat hun Annex III-systeem niet high-risk is (via de Artikel 6 lid 3-uitzondering) moeten zich registreren.
Artikel 26 - Deployer-verplichtingen
Deployers van high-risk AI moeten het systeem gebruiken conform de Instructions for Use, zorgen voor menselijke controle, de werking monitoren en logs bewaren gedurende minimaal zes maanden. Dit alles vereist dat je per systeem weet: wat het is, hoe het wordt ingezet, wie het beheert en waar de IFU te vinden is. Zie ook onze pagina over deployer-verplichtingen.
Artikel 9 - Risicomanagement
Voor high-risk AI moet een risicomanagement-systeem worden ingericht en bijgehouden gedurende de hele levenscyclus. Per systeem moet je risico's identificeren, evalueren en mitigeren. Zonder register weet je niet voor welke systemen dit geldt. Meer over Artikel 9 op onze risicomanagement-pagina.
Artikel 4 - AI-geletterdheid
Alle aanbieders en deployers moeten zorgen voor een passend niveau van AI-geletterdheid bij personeel dat met AI werkt. Om te weten wie welke training nodig heeft, moet je eerst weten welke AI-systemen door welke teams worden gebruikt. Het register is de bron voor je trainingsplan.
Artikel 50 - Transparantieverplichtingen
AI-systemen die direct met personen interacteren (chatbots), synthetische content genereren, emoties herkennen of biometrisch categoriseren moeten aan specifieke disclosure-verplichtingen voldoen. Je register moet per systeem vastleggen of Artikel 50 van toepassing is, zodat je de juiste maatregelen treft.
De kernvelden van je AI-register.
Elk AI-systeem in je register krijgt minimaal deze 18 velden. De eerste 12 zijn verplicht voor elke entry; velden 13-18 zijn sterk aanbevolen en worden verplicht bij high-risk systemen.
| Veld | Naam | Wat je vastlegt | Voorbeeld |
|---|---|---|---|
| Veld 1 - Verplicht | Systeem-ID | Uniek identificatienummer per AI-systeem. Gebruik een vaste conventie, bijvoorbeeld AI-2026-001. Koppel dit ID aan je IT-asset-register en AVG-verwerkingsregister. | Voorbeeld: AI-2026-003 |
| Veld 2 - Verplicht | Systeemnaam | De commerciele of interne naam van het AI-systeem. Gebruik de naam waarmee het systeem intern bekend is, zodat iedereen het herkent. | Voorbeeld: Microsoft Copilot for M365 |
| Veld 3 - Verplicht | Aanbieder / leverancier | Naam van de partij die het AI-systeem heeft ontwikkeld en op de markt brengt. Bij SaaS: de vendor. Bij eigen ontwikkeling: je eigen organisatienaam. | Voorbeeld: Microsoft Corporation |
| Veld 4 - Verplicht | Versienummer | De actuele versie of release van het AI-systeem. Bij SaaS met rolling updates: noteer de laatst bekende versie of het updatebeleid van de leverancier. | Voorbeeld: v2.4.1 (maart 2026) |
| Veld 5 - Verplicht | Doel en beoogd gebruik | Waarvoor wordt het systeem ingezet? Beschrijf het concrete bedrijfsdoel. Dit veld is belangrijk voor risicoclassificatie. | Voorbeeld: Automatisch samenvatten van klantgesprekken voor CRM-registratie |
| Veld 6 - Verplicht | Risicoclassificatie | De classificatie onder de AI Act: verboden, high-risk (Annex I of III), transparantie-eis (Artikel 50), of minimal-risk. Documenteer de onderbouwing apart. | Voorbeeld: Minimal-risk (geen Annex III toepassing, geen Artikel 50 trigger) |
| Veld 7 - Verplicht | Rol onder de AI Act | Jouw rol ten aanzien van dit specifieke systeem: aanbieder, deployer, importeur of distributeur. Een organisatie kan per systeem een andere rol hebben. | Voorbeeld: Deployer |
| Veld 8 - Verplicht | Type data-input | Welke data gaat het systeem in? Tekst, beeld, audio, gestructureerde data, sensordata. Vermeld ook of het persoonsgegevens betreft. | Voorbeeld: Tekst (e-mails, chatberichten) met persoonsgegevens |
| Veld 9 - Verplicht | Type data-output | Wat levert het systeem op? Voorspellingen, classificaties, gegenereerde tekst, scores, aanbevelingen, beslissingen. Wees concreet. | Voorbeeld: Samenvatting (tekst), sentiment-score (numeriek) |
| Veld 10 - Verplicht | Persoonsgegevens (ja/nee) | Verwerkt het systeem persoonsgegevens in de zin van de AVG? Zo ja: koppel aan het AVG-verwerkingsregister (Artikel 30 AVG). Bij bijzondere persoonsgegevens: extra markering. | Voorbeeld: Ja - gewone persoonsgegevens (naam, e-mail) |
| Veld 11 - Verplicht | Datum ingebruikname | Wanneer is het systeem voor het eerst operationeel ingezet? Bij pilots: de startdatum van de pilot. Relevant voor timeline van verplichtingen. | Voorbeeld: 15 januari 2026 |
| Veld 12 - Verplicht | Status | Huidige status van het systeem: in-evaluatie, pilot, actief, bevroren (tijdelijk gestopt), of uitgefaseerd. Uitgefaseerde systemen blijven in het register met einddatum. | Voorbeeld: Actief |
| Veld 13 - Aanbevolen | Functioneel eigenaar | De business-verantwoordelijke die het systeem inhoudelijk aanstuurt. Dit is de persoon die beslissingen neemt over het gebruik en de scope van het systeem. | Voorbeeld: Hoofd klantenservice - M. de Vries |
| Veld 14 - Aanbevolen | Technisch eigenaar | De persoon of het team dat verantwoordelijk is voor technisch beheer, configuratie en het contact met de leverancier. | Voorbeeld: IT-beheer - J. Bakker |
| Veld 15 - Aanbevolen | Laatste review-datum | Wanneer is deze register-entry voor het laatst beoordeeld op juistheid en volledigheid? Belangrijk voor de audit trail. | Voorbeeld: 1 april 2026 |
| Veld 16 - Aanbevolen | Link naar DPIA / risicoanalyse | Verwijzing naar de DPIA (bij persoonsgegevens) of de AI Act-risicoanalyse. Bij high-risk AI: verwijzing naar het Artikel 9-risicomanagement-dossier. | Voorbeeld: SharePoint/Compliance/DPIA-AI-2026-003.pdf |
| Veld 17 - Aanbevolen | Link naar leverancierscontract | Verwijzing naar het contract of de SLA met de leverancier. Check of AI Act-clausules zijn opgenomen. Zie onze pagina over AI-contractclausules. | Voorbeeld: ContractDB/Microsoft-Enterprise-2025.pdf |
| Veld 18 - Aanbevolen | Artikel 50 disclosure-status | Is Artikel 50 van toepassing (chatbot, synthetische content, emotieherkenning, biometrische categorisering)? Zo ja: welke maatregelen zijn genomen? | Voorbeeld: Ja - chatbot-disclosure geimplementeerd in UI |
Deze 18 velden vormen de kern. Afhankelijk van je situatie kun je velden toevoegen: afdeling/team dat het systeem gebruikt, kosten per jaar, aantal gebruikers, integraties met andere systemen, trainingsdata-herkomst (relevant voor aanbieders), en Fundamental Rights Impact Assessment-status (Artikel 27, voor deployers van bepaalde high-risk AI). Begin met de 18 kernvelden en breid uit wanneer dat nodig blijkt.
Stap voor stap naar een compleet AI-register.
Van nul naar een werkend register. Reken op 2-4 weken doorlooptijd voor een MKB-organisatie van 20-200 medewerkers.
- 1 Dag 1-2
Stel een registereigenaar aan
Wijs een persoon aan die eindverantwoordelijk is voor het AI-register. In MKB-organisaties is dit vaak de compliance-officer, IT-manager of CISO. Bij grotere organisaties: de AI-officer. Zonder eigenaar verwatert elk register binnen zes maanden. De eigenaar bewaakt volledigheid, actualiteit en kwaliteit. Alles zelf doen hoeft niet. Leg de verantwoordelijkheid vast in een functiebeschrijving of apart mandaat van het management.
Deliverable Benoeming registereigenaar met mandaat en scope
- 2 Dag 2-3
Definieer wat AI is voor jouw organisatie
Artikel 3 lid 1 AI Act definieert een AI-systeem als een machinaal systeem dat autonoom opereert, aanpasbaarheid toont na inzet, en output genereert die fysieke of virtuele omgevingen kan beinvloeden. Bepaal of je breder registreert: neem je ook regelgebaseerde automatisering mee, of alleen machine-learning-systemen? Wij adviseren breed te registreren. Een systeem dat nu regelgebaseerd is kan morgen AI-componenten krijgen. Door alles te registreren voorkom je dat je steeds opnieuw moet classificeren.
Deliverable Interne definitie en scope-document (1 A4)
- 3 Week 1-2
Inventariseer via vier kanalen
Gebruik vier methoden parallel. Afdelingsgesprekken: interview elke teamlead. Vraag "welke tools gebruik je voor automatisering, tekst genereren, data-analyse, klantcontact?" in plaats van "gebruik je AI?" Medewerkers herkennen AI niet altijd als AI. IT-inventaris: doorloop alle SaaS-licenties, API-keys en cloud-diensten. Inkoop-administratie: zoek op leveranciers die AI, ML of automation in hun productbeschrijving vermelden. Medewerkerssurvey: stuur een korte vragenlijst uit om schaduw-AI te vangen.
Deliverable Ruwe lijst van alle gevonden AI-systemen
- 4 Week 2-3
Vul de registervelden in per systeem
Neem je template met de 18 kernvelden en vul per gevonden systeem alle velden in. Begin met de 12 verplichte velden. Sommige informatie moet je bij de leverancier opvragen (versienummer, type data-verwerking, beschikbare documentatie). Plan hier voldoende tijd voor: leveranciers reageren niet altijd snel. Bij eigen ontwikkeling: raadpleeg de ontwikkelaars en product owners. Wees specifiek: "klantdata" is te vaag, "naam, e-mailadres, bestelhistorie" is bruikbaar.
Deliverable Gevuld register met alle kernvelden per systeem
- 5 Week 2-3
Classificeer risico en rol per systeem
Doorloop per AI-systeem de risicoclassificatie-workflow. Toets eerst Artikel 5 (verboden?), dan Artikel 6 lid 1 (Annex I product-veiligheid?), dan Artikel 6 lid 2 (Annex III domein?), dan Artikel 50 (transparantie-eis?), anders minimal-risk. Bepaal ook je rol per systeem: ontwikkel je het zelf (aanbieder) of gebruik je het (deployer)? Documenteer de classificatie-onderbouwing, met name voor systemen waar je claimt dat Artikel 6 lid 3 uitzondering van toepassing is.
Deliverable Risicoclassificatie en rol per systeem gedocumenteerd
- 6 Week 3
Koppel documentatie en verantwoordelijkheden
Link per register-entry naar bestaande documenten: DPIA, Instructions for Use van de leverancier, technisch dossier (bij eigen ontwikkeling), leverancierscontract, risicoanalyse. Wijs per systeem een functioneel eigenaar en technisch eigenaar aan. Bij systemen die door meerdere afdelingen worden gebruikt: kies de afdeling met het primaire gebruik als functioneel eigenaar. Maak afspraken over wie wijzigingen in de entry doorvoert.
Deliverable Documenten gelinkt, eigenaren aangewezen per systeem
- 7 Week 3-4
Stel review-cyclus en triggers in
Bepaal de vaste review-frequentie. Wij adviseren minimaal elke zes maanden een volledige review van het complete register. Definieer daarnaast triggers die een directe update vereisen: nieuw systeem aangeschaft, systeem uitgefaseerd, doel of gebruik gewijzigd, grote software-update, incident, wetswijziging (bijvoorbeeld aanpassing Annex III), contractwijziging. Leg deze triggers vast in een procedure-document en communiceer ze naar alle systeem-eigenaren.
Deliverable Review-procedure met triggers en frequentie
- 8 Week 4
Kies tooling en automatiseer
Selecteer de tooling die past bij je schaalgrootte en budget. Voor de meeste MKB-organisaties met minder dan 15 AI-systemen is een goed gestructureerde spreadsheet voldoende. Bij 15-50 systemen: overweeg een GRC-platform. Bij meer dan 50 of bij hoge compliance-druk: dedicated AI-governance-software. Automatiseer waar mogelijk: review-herinneringen per e-mail, dashboard met status-overzicht, notificaties bij verlopen review-datum. Zie de tooling-vergelijking verderop.
Deliverable Tooling geselecteerd, ingericht en in gebruik
Review-frequentie en update-triggers.
Een register dat je eenmaal vult en daarna niet bijhoudt is waardeloos bij een audit. De AI Act gaat uit van voortdurend onderhoud. Hier zijn de momenten waarop je het register moet bijwerken.
Vaste review-momenten
Plan minimaal twee keer per jaar een volledige review van het complete register. Tijdens deze review controleert de registereigenaar samen met de systeem-eigenaren of alle entries nog kloppen. Zijn er systemen bijgekomen die niet zijn geregistreerd? Zijn er systemen uitgefaseerd die nog als actief staan? Klopt de risicoclassificatie nog? Is het versienummer actueel? Zijn de eigenaren nog de juiste personen? Documenteer de review met datum, namen van betrokkenen en bevindingen.
Voor organisaties met high-risk AI-systemen adviseren wij een kwartaalreview vanwege de hogere eisen uit Artikel 9 (risicomanagement) en Artikel 72 (post-market monitoring). Daarnaast: plan jaarlijks een volledige audit door een onafhankelijke persoon die niet de dagelijkse registereigenaar is.
| Moment | Wat je doet |
|---|---|
| Nieuw AI-systeem | Elke nieuwe aanschaf, proef of ontwikkeling van een AI-systeem moet direct in het register. Maak registratie onderdeel van het inkoopproces en het software-goedkeuringsproces. |
| Systeem uitgefaseerd | Verwijder het systeem niet uit het register. Zet de status op uitgefaseerd en noteer de einddatum. Voor high-risk AI: bewaar logs en documentatie minimaal zes maanden na uitfasering. |
| Doel of gebruik gewijzigd | Als een AI-systeem voor een ander doel wordt ingezet dan oorspronkelijk geregistreerd, kan de risicoclassificatie wijzigen. Herclassificeer en update het register. Let op Artikel 25: substantiele modificatie kan je rol wijzigen. |
| Grote software-update | Een update die de werking van het AI-systeem fundamenteel verandert (nieuw model, andere trainingsdata, nieuwe output-typen) vereist hercheck van risicoclassificatie en registervelden. |
| Incident of near-miss | Bij een incident gerelateerd aan een AI-systeem: update het register met het incident, de genomen maatregelen en eventuele wijzigingen in gebruik of classificatie. Artikel 73 vereist melding van ernstige incidenten. |
| Wetswijziging | De Europese Commissie kan Annex III uitbreiden via delegated acts (Artikel 7). Monitor officiele kanalen. Bij wijziging: herclassificeer alle systemen die mogelijk onder de nieuwe scope vallen. |
| Contractwijziging leverancier | Als de leverancier voorwaarden wijzigt, het product overdraagt aan een andere partij, of wezenlijke veranderingen in het AI-systeem aanbrengt: update het register en hercheck de contractclausules. |
| Personele wijziging | Als een functioneel of technisch eigenaar de organisatie verlaat of van functie wijzigt: wijs direct een nieuwe eigenaar aan en update het register. Onbeheerde systemen zijn een compliance-risico. |
Opties voor je AI-register-tooling.
De beste tool is de tool die daadwerkelijk wordt gebruikt. Een goed bijgehouden spreadsheet is beter dan een leeg GRC-platform.
| Criterium | Spreadsheet (Excel/Sheets) | GRC-platform | Dedicated AI-governance tool |
|---|---|---|---|
| Geschikt bij | < 15 AI-systemen | 15 - 50 AI-systemen | > 50 AI-systemen |
| Kosten per jaar | Gratis - 500 euro | 5.000 - 25.000 euro | 15.000 - 60.000 euro |
| Opstartsnelheid | Uren | Weken | Weken tot maanden |
| Versiebeheer | Handmatig / beperkt | Ingebouwd | Ingebouwd |
| Workflow / goedkeuringsproces | Niet aanwezig | Volledige workflows | AI-specifieke workflows |
| Automatische herinneringen | Handmatig instellen | Geautomatiseerd | Geautomatiseerd |
| Rapportage / dashboard | Zelf bouwen (pivot) | Standaard dashboards | AI-specifieke dashboards |
| Integratie met IT-assets | Handmatig | Via koppelingen | Native integraties |
| EU-database export | Handmatig klaarzetten | Vaak niet standaard | Specifiek ontworpen |
| Risicoclassificatie-ondersteuning | Zelf invullen | Generieke frameworks | AI Act-specifiek |
| Audit trail | Beperkt (versie-historie) | Volledig | Volledig |
| Voorbeelden | Excel, Google Sheets, Notion | OneTrust, ServiceNow GRC, Archer | Holistic AI, Credo AI, IBM OpenPages |
Onze aanbeveling per schaalgrootte
5-50 medewerkers, minder dan 10 AI-systemen: start met een spreadsheet. Gebruik onze template-structuur met de 18 velden als kolommen. Bewaar het bestand op een gedeelde locatie (SharePoint, Google Drive) zodat meerdere personen toegang hebben. Stel kalenderherinneringen in voor de halfjaarlijkse review.
50-200 medewerkers, 10-30 AI-systemen: een spreadsheet werkt nog, maar wordt kwetsbaar. Overweeg een GRC-platform als je er al een hebt (veel organisaties gebruiken al een GRC-tool voor ISO 27001 of AVG). Voeg een AI-register-module toe in plaats van een nieuw systeem te kopen.
200+ medewerkers of meer dan 30 AI-systemen: investeer in een dedicated AI-governance-tool of een GRC-platform met AI-module. De complexiteit van risicoclassificatie, documentatie-koppelingen en multi-stakeholder-beheer rechtvaardigt de investering. Let bij selectie op: AI Act-specifieke templates, EU-database-export, en integratie met je bestaande IT-landschap.
Welke tool je ook kiest: de discipline om het register bij te houden is belangrijker dan de tool zelf. Een ongebruikte tool op welk platform dan ook is nutteloos.
De verborgen AI in je organisatie opsporen.
Schaduw-AI is het gebruik van AI-tools door medewerkers zonder dat IT, management of de compliance-afdeling ervan op de hoogte is. Dit is in de meeste organisaties geen kwade opzet: medewerkers ontdekken tools die hun werk versnellen en beginnen ze te gebruiken. Maar voor AI Act-compliance is onbekende AI een serieus probleem: je kunt geen risicoclassificatie uitvoeren op systemen waarvan je het bestaan niet kent.
Waar schaduw-AI zich verstopt
| Waar | Voorbeelden en hoe het ontstaat |
|---|---|
| Browser-gebaseerde AI-tools: | ChatGPT, Claude, Gemini, Perplexity en tientallen andere tools die medewerkers via de browser gebruiken zonder installatie of IT-goedkeuring. |
| AI-functies in bestaande software: | Salesforce Einstein, HubSpot AI, Canva Magic, Grammarly, Adobe Firefly. Medewerkers zetten AI-functies aan in software die al goedgekeurd is, zonder te beseffen dat dit apart geregistreerd moet worden. |
| Persoonlijke AI-assistenten: | Copilot in Windows, Siri, Google Assistant. Op werkdevices, maar niet centraal beheerd. |
| API-koppelingen door power users: | medewerkers die via Zapier, Make of eigen scripts AI-API's aanroepen om workflows te automatiseren. |
| AI in mobiele apps: | vertaalapps, transcriptie-apps, spraakassistenten die voor werkdoeleinden worden gebruikt op persoonlijke of zakelijke telefoons. |
Methoden om schaduw-AI te vinden
| Methode | Hoe je het aanpakt |
|---|---|
| Anonieme survey: | stuur een korte vragenlijst naar alle medewerkers. Formuleer de vragen als inventarisatie. "Welke tools gebruik je om je werk te versnellen?" werkt beter dan "Gebruik je ongeautoriseerde AI?". Maak het veilig om eerlijk te antwoorden: zeg erbij dat je alleen wilt weten wat er gebruikt wordt. |
| Netwerk-analyse: | IT kan via DNS-logs of proxy-logs zien welke AI-domeinen worden bezocht (api.openai.com, claude.ai, gemini.google.com, etc.). Dit laat zien welke AI-tools in gebruik zijn; voor de omvang heb je andere bronnen nodig. |
| Expense-rapport check: | zoek in declaraties en creditcard-afschriften naar abonnementen op AI-tools. Medewerkers die zelf een ChatGPT Plus-abonnement declareren gebruiken dat voor werk. |
| Software-asset-management: | als je een SAM-tool hebt (Zylo, Productiv, Torii), voeg AI-tools toe aan de monitored-lijst. |
Na de inventarisatie: beoordeel elk gevonden systeem op risico en beslis per systeem of het wordt geaccepteerd (en geregistreerd), of wordt verboden (en geblokkeerd), of wordt vervangen door een centraal goedgekeurd alternatief.
Koppeling met bestaande compliance-processen.
Een AI-register staat niet op zichzelf. Het versterkt bestaande compliance-inspanningen en wordt er ook door versterkt. De drie belangrijkste koppelingen:
1. AVG-verwerkingsregister (Artikel 30 AVG)
AI-systemen die persoonsgegevens verwerken moeten zowel in het AI-register als in het AVG-verwerkingsregister staan. Gebruik een gemeenschappelijk Systeem-ID om de twee registers te koppelen. Als je een DPIA hebt uitgevoerd voor een AI-systeem, link dan vanuit het AI-register naar dat DPIA-document. Wijzigingen in het ene register moeten het andere triggeren: als het AI-systeem andere persoonsgegevens gaat verwerken, update je zowel het AI-register als het verwerkingsregister.
2. IT-asset-register / CMDB
Je IT-afdeling beheert waarschijnlijk al een overzicht van alle software en systemen. Zorg dat elk AI-systeem in het AI-register hetzelfde ID of dezelfde naam gebruikt als in de IT-CMDB. Bij nieuwe AI-aanschaf: maak registratie in beide systemen onderdeel van het inkoopproces. Als je ISO 27001 volgt: de AI-systemen zijn onderdeel van je scope of applicability en moeten in je Statement of Applicability worden meegenomen.
3. Risicomanagement-framework
Als je een formeel risicomanagement-framework hebt (ISO 31000, COSO, of sectorspecifiek), koppel dan elk AI-systeem aan een risico-entry. Voor high-risk AI is dit sowieso verplicht via Artikel 9. Voor minimal-risk AI is het aan te bevelen. De risicoanalyse in je bestaande framework en de risicoclassificatie in je AI-register versterken elkaar: de AI Act-classificatie bepaalt welke controls verplicht zijn, je risicoanalyse bepaalt de prioriteit van implementatie.
4. Inkoopproces
Voeg een AI-check toe aan je inkoopproces. Bij elke nieuwe software-aanschaf: bevat dit product AI-componenten? Zo ja: registreer het direct in het AI-register, voer de risicoclassificatie uit, en check de contractclausules voordat je tekent. Dit voorkomt dat AI-systemen buiten het register om de organisatie binnenkomen.
Completeness-checklist voor je AI-register.
Loop deze 47 punten na om te controleren of je register volledig en bruikbaar is. Verdeel over zes categorieen.
| Deel | Onderdeel | Doel | Checkpunten |
|---|---|---|---|
| A | Governance en eigenaarschap | Organisatorische basis voor het register |
|
| B | Inventarisatie en volledigheid | Alle AI-systemen gevonden en opgenomen |
|
| C | Registervelden per systeem | Alle 18 kernvelden per entry gevuld |
|
| D | Documentatie-koppelingen | Links naar ondersteunende documenten |
|
| E | Procesintegratie | Register ingebed in dagelijkse processen |
|
| F | Tooling en automatisering | Technische ondersteuning van het register |
|
Veelgemaakte fouten bij het AI-register.
1. Eenmalig vullen, daarna vergeten
De meest voorkomende fout. Een team investeert twee weken in het opzetten van het register, en daarna wordt het niet meer bijgewerkt. Na zes maanden is het register verouderd en onbetrouwbaar. Oplossing: bouw de review-cyclus in je agenda. Maak het onderdeel van een bestaand overleg (MT-vergadering, IT-overleg). Automatiseer herinneringen.
2. Alleen "officiele" AI registreren
Organisaties registreren de AI-systemen die formeel zijn ingekocht, maar missen schaduw-AI. Een medewerker die dagelijks klantdata in ChatGPT plakt is een groter compliance-risico dan het officieel aangeschafte analyse-platform. Oplossing: voer de vier inventarisatiemethoden uit, met name de medewerkerssurvey.
3. Te vage beschrijvingen
"CRM-systeem met AI" is geen bruikbare registratie. Bij een audit moet je precies kunnen uitleggen wat de AI doet, welke data erin gaat en wat eruit komt. Oplossing: dwing specificiteit af in je template. Het veld "doel en beoogd gebruik" moet minimaal twee zinnen zijn. "Automatisch prioriteren van support-tickets op basis van tekstanalyse van het klantverzoek" is bruikbaar.
4. Risicoclassificatie overslaan of uitstellen
Sommige organisaties vullen alle velden in behalve de risicoclassificatie, omdat ze die "later" willen doen. Maar het register zonder classificatie is als een voorraadlijst zonder locatie-aanduiding: je weet wat je hebt, maar niet wat je ermee moet. Oplossing: classificeer direct bij registratie. Gebruik de risicoclassificatie-werkflow. Bij twijfel: classificeer conservatief als high-risk.
5. Geen eigenaar per systeem
Het register heeft een registereigenaar, terwijl individuele systemen geen eigenaar hebben. Als niemand verantwoordelijk is voor de juistheid van een specifieke entry, wordt die entry niet bijgewerkt. Oplossing: wijs per systeem een functioneel en technisch eigenaar aan. Maak de eigenaren medeverantwoordelijk voor de halfjaarlijkse review van hun entries.
Over het AI-register.
Is een AI-register wettelijk verplicht?
Ja, indirect. De AI Act schrijft niet voor dat je een "intern AI-register" bijhoudt in een specifiek format. Wel verplicht Artikel 49 registratie in de EU-database voor high-risk AI, Artikel 26 verplicht deployers om systemen te monitoren en logs te bewaren, en Artikel 4 vereist dat je weet welke AI je medewerkers gebruiken. Zonder intern register kun je geen van deze verplichtingen aantonen. Een toezichthouder die vraagt "welke AI-systemen gebruikt jullie organisatie?" verwacht een concreet antwoord. Het AI-register is de praktische voorwaarde om compliant te zijn.
Welke AI-systemen moet ik registreren?
Alle AI-systemen die je organisatie gebruikt, ontwikkelt of distribueert in professionele context. Inclusief ingekochte SaaS-tools, AI-functies in bestaande software, API-koppelingen, intern ontwikkelde modellen en tools die medewerkers zelfstandig gebruiken. Registreer ook minimal-risk systemen: bij herclassificatie of wetswijziging heb je dan al een basis. Twijfel je of iets AI is? Registreer het met een notitie "classificatie te bevestigen". Beter te veel dan te weinig.
Hoeveel velden moet een AI-register minimaal bevatten?
Wij adviseren 18 kernvelden per systeem. De eerste 12 zijn verplicht voor elke entry, ongeacht risicoclassificatie. Velden 13-18 zijn sterk aanbevolen en worden in de praktijk verplicht bij high-risk systemen. De AI Act specificeert geen exact format. De benodigde datapunten volgen uit de informatie-eisen van Artikel 26, 49, 9 en 11. Begin met de 18 velden en breid uit als je situatie dat vraagt.
Hoe vind ik alle AI-systemen in mijn organisatie?
Combineer vier methoden: afdelingsgesprekken met teamleads, doorlopen van IT-inventaris en SaaS-licenties, doorzoeken van inkoop-administratie op AI-leveranciers, en een medewerkerssurvey voor schaduw-AI. De survey is belangrijk: in onze ervaring komt een deel van de AI-systemen in MKB-organisaties alleen boven via de medewerkerssurvey en niet via de andere drie kanalen. Plan twee weken voor een organisatie van 50-200 medewerkers.
Hoe vaak moet ik het AI-register bijwerken?
Minimaal elke zes maanden een volledige review. Bij organisaties met high-risk AI: elk kwartaal. Daarnaast: direct bij triggers zoals nieuw systeem, uitfasering, doel-wijziging, grote update, incident, wetswijziging of contractwijziging. Jaarlijks: een onafhankelijke audit van het complete register. In de praktijk is de halfjaarlijkse review het minimum; de event-triggers zorgen ervoor dat het register ook tussentijds actueel blijft.
Kan ik een spreadsheet gebruiken als AI-register?
Ja, voor organisaties met minder dan 15 AI-systemen is een spreadsheet prima werkbaar. Gebruik de 18 velden als kolommen, elk AI-systeem als rij. Bewaar op een gedeelde locatie met toegangscontrole. Nadelen: geen automatisch versiebeheer, geen workflows, geen automatische herinneringen. Bij meer dan 15 systemen of bij meerdere mensen die het register beheren: overweeg een GRC-platform of dedicated AI-governance-tool.
Wat is het verschil tussen het interne AI-register en de EU-database?
Het interne register is je eigen administratie van alle AI-systemen, ongeacht risicoclassificatie. De EU-database (Artikel 49) is een publieke database van de Europese Commissie voor high-risk AI en bepaalde transparantie-eis-systemen. Je interne register is breder en gedetailleerder. De EU-database bevat een subset van je interne informatie. Zonder goed intern register kun je de EU-database niet correct en tijdig vullen.
Wie is verantwoordelijk voor het AI-register?
Er moet een registereigenaar zijn die het totaalbeeld bewaakt: volledigheid, actualiteit, kwaliteit. In MKB: vaak de compliance-officer, IT-manager of CISO. Per systeem wijs je een functioneel eigenaar (business) en technisch eigenaar (IT/beheer) aan. De registereigenaar organiseert de reviews; de systeem-eigenaren zorgen dat hun entries kloppen. Bij MT-rapportage: de registereigenaar rapporteert over status en eventuele risico's.
Moet ik AI in proeffase ook registreren?
Ja. Pilots en proof-of-concepts worden geregistreerd met status "in-test" of "pilot". De AI Act maakt geen uitzondering voor testsituaties waarin echte data of echte personen betrokken zijn. Bovendien: pilots die slagen worden vaak direct productie gezet. Als het systeem al in het register staat, vergeet je de formele beoordeling bij opschaling niet. Registreer vanaf het moment dat het systeem wordt aangesloten op echte data of echte gebruikers.
Hoe koppel ik het AI-register aan de AVG?
Gebruik een gemeenschappelijk Systeem-ID in zowel het AI-register als het AVG-verwerkingsregister. AI-systemen die persoonsgegevens verwerken staan in beide registers. Link vanuit het AI-register naar de DPIA. Wijzigingen in het ene register moeten het andere triggeren. Voor organisaties met ISO 42001: het AI-managementsysteem integreert het AI-register met het privacy-managementsysteem. Praktisch: plan de review van beide registers op hetzelfde moment.
Gerelateerde pagina's.
AI Act compliance-roadmap voor het MKB
→Risicoclassificatie AI Act: high-risk of limited risk?
→AI Act voor deployers: jouw verplichtingen als gebruiker van AI
→Artikel 9 AI Act: risicomanagement-systeem voor high-risk AI
→High-risk AI-systemen: wat valt onder de AI Act?
→AI Act uitgelegd: wat betekent de wet voor jouw bedrijf?
→AI-contractclausules voor inkoop en levering van AI-tools
→AI Act tijdlijn: deadlines 2024, 2025, 2026 en 2027
Opgesteld met AI-ondersteuning door de redactie van Prometheus21. Hoe wij content maken
Verder lezen
- Kennisartikel
- Kennisartikel
- Kennisartikel
Hulp bij je AI-register?
Prometheus21 helpt MKB-organisaties bij het opzetten van een compleet AI-register, inclusief inventarisatie, risicoclassificatie en de koppeling met bestaande compliance-processen. In twee tot vier weken een werkend register.