Grip op AI

Een praktisch raamwerk om AI te beheersen én te auditen, met volwassenheidsmodel, uitgewerkte casus en checklists.

Samenvatting

Het overgrote deel van het AI-risico in organisaties zit niet in de techniek. Het zit in governance, data, monitoring en uitkomsten, en in het informele AI-gebruik dat buiten elk register valt. Wie AI wil beheersen of auditen heeft dan ook geen data scientist nodig, maar een raamwerk dat structureert wat je inricht en wat je toetst.

Dit artikel introduceert dat raamwerk: het vijflagenmodel. Elk AI-systeem is op te delen in vijf lagen: governance en accountability, data en input, model en ontwikkeling, inzet en monitoring, en uitkomst en impact. Op elke laag passen twee brillen. De risk-bril stelt de inrichtingsvraag: staat het er, en werkt het? De audit-bril stelt de toetsvraag: hoe stellen we vast dat het werkt? Eén raamwerk dus, voor de eerste, tweede én derde lijn.

Het model staat niet op zichzelf. Het is de werkvloervertaling van de grote kaders: de EU AI Act, ISO/IEC 42001, het NIST AI RMF, de auditcriteria van ForHumanity en de beroepsguidance van IIA en NOREA. Een mappingtabel laat per laag zien waar elk kader raakt, zodat je gericht kunt verdiepen zonder in vijf documenten tegelijk te verdwalen.

De urgentie is er, ook nu de toepassing van een deel van de hoog-risicoverplichtingen uit de AI Act is verschoven naar eind 2027 en 2028. Uitstel is geen afstel: beheersing van AI is geen wetgevingsvraagstuk, het is een basisvoorwaarde voor verantwoord sturen, controleren en verantwoorden. Toezichthouders zoals de AP of DNB kijken nu al naar AI-risico's vanuit bestaande governance- en risicokaders. Intussen gebruikt een deel van de medewerkers AI-tools zonder toestemming of toezicht, grotendeels buiten het zicht van de organisatie.

Inleiding

Grip krijgen op AI is geen apart vakgebied dat alleen voor data scientists is weggelegd. Het is gewoon vakwerk voor risk-, compliance- en auditprofessionals, met een paar nieuwe accenten en een vaste structuur die je per laag kunt aflopen.

Dit is een doe-stuk. Het is geschreven voor twee lezers tegelijk. Voor de risk- of complianceprofessional die AI-governance moet inrichten en wil weten wat er minimaal moet staan. En voor de internal auditor die AI op de auditagenda krijgt en houvast zoekt bij het toetsen ervan. Beiden werken met hetzelfde raamwerk; alleen de vraag verschilt. Geen theorie, maar een werkwijze die je vandaag al kunt toepassen.

Model, agent of skill: wat bedoelen we?

In dit artikel gebruiken we 'AI-systeem' als overkoepelende term voor alles wat je inricht, beheerst en toetst. Waar het preciezer moet:

• Model: het getrainde AI-component dat voorspelt of genereert (bijvoorbeeld GPT, Claude of Gemini). Het rekent, maar handelt niet zelf.

• Agent: een systeem dat een of meer modellen inzet om zelfstandig taken uit te voeren. Het neemt stappen, roept hulpmiddelen aan en handelt.

• Skill: een afgebakende, herbruikbare capaciteit die een agent voor een specifieke taak inzet.

Kort gezegd: het model is de motor, de agent de bestuurder en de skills het gereedschap. Laag 3 gaat specifiek over het model zelf; de overige lagen gaan over het AI-systeem als geheel. De analyse-eenheid is in de praktijk meestal de concrete AI-toepassing of use case: het AI-systeem zoals het in de organisatie wordt ingezet. Bij agentic AI kan dat de agent zijn. De modelbeoordeling kan deels worden hergebruikt, maar moet opnieuw worden bezien bij materiële modelwijzigingen, nieuwe use cases, gewijzigde data, prompts, koppelingen of risicoclassificatie.

1. De aanleiding: wetgeving komt eraan, beheersing was er altijd al

De meest zichtbare aanleiding is de wetgeving, en die is sector-agnostisch. De EU AI Act, in werking sinds 1 augustus 2024, raakt elke organisatie die AI ontwikkelt of gebruikt: van gemeente tot ziekenhuis tot verzekeraar. De verboden AI-praktijken en de verplichting tot AI-geletterdheid gelden al sinds februari 2025, de regels voor general-purpose AI sinds augustus 2025. De verplichtingen voor hoog-risico systemen zijn met het Digital Omnibus-akkoord van mei 2026 verschoven naar december 2027 en augustus 2028. De Act blijft risicogebaseerd, met vier klassen: onaanvaardbaar, hoog, beperkt en minimaal risico.

Maar wie de wetgeving als de reden ziet, mist een belangrijk punt: beheersing van AI is geen wetgevingsvraagstuk. Een organisatie die besluitvorming laat ondersteunen of beïnvloeden door systemen die zij niet begrijpt, niet monitort en niet kan uitleggen, heeft een beheersingsprobleem. Met of zonder wettelijke deadline. Een gemeente die uitkeringsaanvragen triageert en een verzekeraar die schades beoordeelt hebben exact hetzelfde vraagstuk. Voor gereguleerde sectoren komt daar een extra laag bovenop én kijkt er iemand mee: financiële instellingen hebben te maken met de verwachtingen van DNB en EIOPA, de publieke sector met toenemende transparantie-eisen rond algoritmen en het Algoritmeregister, en iedereen met de Autoriteit Persoonsgegevens; de AVG geldt onverkort voor elke AI-toepassing die persoonsgegevens verwerkt. Wie gereguleerd is, moet zijn zaken simpelweg eerder en aantoonbaarder op orde hebben.

De fundamenten van risicomanagement, compliance of audit veranderen niet door AI. Drie eigenschappen maken een AI-systeem wel anders dan een klassiek IT-systeem.

• Opaciteit. De redenering achter een uitkomst is niet altijd reproduceerbaar of uit te leggen. De vraag verschuift van "hoe werkt het?" naar "hoe weten we dat het werkt zoals bedoeld?"

• Autonomie. Het systeem ondersteunt, beïnvloedt of automatiseert besluitvorming die voorheen door mensen werd gedaan. Dat raakt direct aan beheersing, accountability, menselijke tussenkomst en herstel.

• Veranderingstempo. Een AI-systeem kan veranderen door modelupdates, gewijzigde prompts, nieuwe koppelingen, veranderende inputdata, leveranciersupdates of doorleren. Een control die vandaag effectief is, hoeft dat over drie maanden niet meer te zijn.

Uitstel is geen afstel

Het Digital Omnibus-akkoord geeft organisaties langer de tijd voor de formele hoog-risico-compliance. Maar: de verboden praktijken en AI-geletterdheid gelden al. De AVG geldt onverkort. DNB verwacht van financiële instellingen nu al gedegen vastlegging en passende monitoring van AI-toepassingen. Ook EIOPA plaatst AI-governance nadrukkelijk binnen bestaande sectorale governance- en risicomanagementkaders. Het uitstel geeft lucht voor de formele compliance, niet voor de beheersing.

2. Het landschap: vijf kaders, vijf verschillende vragen

Wie houvast zoekt, komt al snel vijf kaders tegen. Alle vijf zijn waardevol, maar ze beantwoorden elk een andere vraag. Wie dat onderscheid kent, kan ze gericht gebruiken in plaats van erin te verdwalen.

EU AI Act, de wet. Beantwoordt: wat móet er minimaal? De wet werkt risicogebaseerd en legt per risicoklasse eisen op, voor hoog-risico systemen onder meer aan risicomanagement, datakwaliteit, documentatie, menselijk toezicht en robuustheid. De beperking: de Act zegt wát er moet, niet hóe je het organiseert.

ISO/IEC 42001:2023, het managementsysteem. Beantwoordt: hoe organiseer je AI-beheersing structureel? Het is de eerste certificeerbare internationale norm voor een AI-managementsysteem, met eisen en beheersmaatregelen voor beleid, rollen, risicobeheersing, levenscyclus en monitoring. De beperking: de norm werkt op organisatieniveau; een certificaat zegt niet alles over de kwaliteit van een individueel systeem.

NIST AI Risk Management Framework, het risicoraamwerk. Beantwoordt: hoe identificeer en weeg je AI-risico's? Het vrijwillige Amerikaanse raamwerk kent vier functies (Govern, Map, Measure, Manage) en wordt ook in Europa breed als referentie gebruikt. De beperking: het is niet normatief en laat veel invulruimte.

ForHumanity, de onafhankelijke auditcriteria. Beantwoordt: waartegen kan een onafhankelijke auditor toetsen? Deze non-profitorganisatie ontwikkelt openbare auditcriteria en certificeringsschema's voor AI- en algoritmische systemen, waaronder criteria rond de EU AI Act, geharmoniseerd met ISO/IEC 42001. De beperking: het materiaal is erg uitgebreid en primair gericht op formele third-party audits.

IIA- en NOREA-guidance, de auditberoepsgroep. Beantwoorden: wat betekent AI voor een auditfunctie? Het AI Auditing Framework van het IIA (2024) is opgebouwd langs het Three Lines Model en behandelt onder meer strategie, ethiek, datagovernance, derde partijen en monitoring. NOREA publiceert handreikingen en guidance voor IT-auditors rond algoritme- en AI-assurance. De beperking: richtinggevend en principle-based, geen uitgewerkt werkprogramma per systeem.

Geen van deze vijf vertelt een risk-, compliance- of auditprofessional wat hij maandagochtend concreet moet doen met dat ene schademodel, die chatbot of dat ingekochte triagesysteem. Daarvoor is het vijflagenmodel bedoeld: geen zesde concurrent, maar de werkvloervertaling van deze kaders. De tabel hieronder laat per laag zien waar elk kader raakt, zodat je weet waar de diepgang te vinden is.

Tabel 1. Gebruik de tabel als wegwijzer voor verdieping per laag.

De genoemde AI Act-artikelen zijn richtinggevend voor de betreffende laag, maar de toepasselijkheid hangt af van risicoclassificatie en rol: provider, deployer, importeur of distributeur.

3. Het vijflagenmodel: één raamwerk, twee brillen

Wie de drie eigenschappen uit hoofdstuk 1 herkent, begrijpt waarom een losse controle-checklist niet volstaat. Je hebt een raamwerk nodig dat bepaalt wat je inricht en wat je toetst, los van de techniek eronder. Dat raamwerk deelt elk AI-systeem op in vijf lagen. Op elke laag passen twee brillen: de risk-bril (inrichten en beheersen: staat het er, en werkt het?) en de audit-bril (toetsen en onderzoeken: hoe stellen we vast dat het werkt?). Eerste, tweede en derde lijn werken zo met hetzelfde model en dezelfde taal, ieder vanuit de eigen rol.

Figuur 1. Het vijflagenmodel met de twee brillen

Laag 1. Governance en accountability

Het fundament: is er beleid, is er overzicht, en is duidelijk wie verantwoordelijk is?

Inrichten (risk-bril): stel AI-beleid vast en houd een AI-register bij met alle bekende systemen, use cases en vormen van informeel gebruik. Beleg eigenaarschap per systeem (RACI), richt een goedkeuringsproces in voor nieuwe initiatieven met een risicoclassificatie, en zorg voor passende AI-geletterdheid.

Toetsen (audit-bril): welke AI-systemen zijn in gebruik, en hoe weten we dat zeker? Hoe wordt een nieuw initiatief beoordeeld en goedgekeurd? Wie draagt formele verantwoordelijkheid voor de uitkomsten? Evidence: AI-beleid, register met risicoclassificatie, RACI per use case, besluitvormingstrails.

Blinde vlek: het AI-register is in de praktijk vaak incompleet. Schaduw-AI (medewerkers die publieke AI-tools gebruiken) blijft buiten het formele overzicht. Begin met een test op de werkvloer, niet met de centrale lijst.

Laag 2. Data en input

Bij AI zit veel van het risico in de data, niet in het model.

Inrichten (risk-bril): leg de herkomst van trainings- en inputdata vast (data lineage), beoordeel representativiteit, voer waar nodig een DPIA uit en houd die actueel, test op bias en uitschieters, en monitor de inputdata in productie. Stel bij inkoop eisen aan de documentatie van de leverancier.

Toetsen (audit-bril): waar komt de trainingsdata vandaan en is die representatief? Hoe is omgegaan met persoonsgegevens, bias en uitschieters? Evidence: data lineage, DPIA's, bias-tests, kwaliteitsrapporten.

Blinde vlek: bij ingekochte systemen en foundation models (GPT, Claude, Gemini) is er geen of beperkt zicht op de trainingsdata. Lees de model card, draai eigen testcases en beoordeel uitkomsten op bias, hallucinaties, betrouwbaarheid, vertrouwelijkheid en passend gebruik.

Laag 3. Model en ontwikkeling

Hier zit het meeste technische werk, maar ook hier kom je verder dan je denkt zonder zelf modellen te bouwen.

Inrichten (risk-bril): vraag of verplicht model cards met aannames, beperkingen en bekende risico's. Organiseer onafhankelijke validatie, volg performance over de tijd (niet alleen bij oplevering), leg modelupdates vast in change logs. Voor ingekochte modellen: regel contractuele afspraken over auditrechten, wijzigingsmeldingen en exit.

Toetsen (audit-bril): hoe is het model gevalideerd, tegen welke benchmark, en door wie? Evidence: model cards, validatierapporten, performance-metrics, change logs, sign-off modeleigenaar.

Blinde vlek: foundation models laten zich niet valideren zoals traditionele modellen. De vraag verschuift naar: hoe is dit model ingebed in onze toepassing, en welke vangnetten staan eromheen?

Laag 4. Inzet en monitoring

In de praktijk vaak een zwakke laag, omdat operationele monitoring lastig grijpbaar is.

Inrichten (risk-bril): monitor actief op werking en op drift, met drempelwaarden en alerts. Beschrijf en beleg human oversight: wie grijpt wanneer in. Richt een incidentprocedure in, maak afspraken met leveranciers over het melden van modelwijzigingen en kwetsbaarheden, regel toegangsbeheer en logging, en beoordeel misbruikscenario's zoals prompt injection en datalekken via prompts.

Toetsen (audit-bril): hoe weten we dat het model in productie nog doet wat bedoeld was? Wanneer treedt een mens op, en wie? Wat gebeurt er bij fouten of drift? Evidence: monitoring-dashboards, drempelwaarden, incident-logs, escalatieprocedures en concrete voorbeelden van menselijke tussenkomst in de afgelopen periode.

Blinde vlek: drift wordt vaak pas zichtbaar als een klant klaagt of een uitkomst opvallend afwijkt. Proactieve drift-monitoring is zeldzaam, en dat is precies de zere plek waar de vinger op moet.

Laag 5. Uitkomst en impact

De laag waar regelgevers, klanten en betrokkenen het meest naar kijken, en waar reputatieschade ontstaat.

Inrichten (risk-bril): analyseer uitkomsten per doelgroep op verschillen in behandeling, zorg dat betrokkenen een casus-specifieke uitleg kunnen krijgen over een beslissing, richt een bezwaar- en correctiemechanisme in en leg per beslissing een audit trail vast.

Toetsen (audit-bril): worden uitkomsten per doelgroep geanalyseerd? Kan een betrokkene uitleg krijgen, en is die specifiek voor de eigen casus? Werkt het bezwaarmechanisme? Evidence: outcome-analyses, transparantierapporten, klachten- en bezwaarprocedures, audit trail per beslissing.

Blinde vlek: betrokkenen krijgen vaak wel uitleg, maar die is generiek en niet specifiek voor hun casus. Vraag altijd een paar concrete voorbeelden op van uitleg die mensen daadwerkelijk hebben ontvangen.

4. Waar staat jouw organisatie? Een beknopt volwassenheidsmodel

Voordat je inricht of toetst, helpt het om te weten waar de organisatie als geheel staat. Onderstaand model beschrijft per laag drie niveaus: ad hoc, in ontwikkeling en in control. Het is geen norm maar een gespreksinstrument: voor de riskfunctie om de inrichtingsagenda te bepalen, voor de auditfunctie om de auditaandacht te richten op de lagen waar de afstand tot 'in control' het grootst is.

Een organisatie hoeft niet op elke laag op het hoogste niveau te staan: de risicoweging van het systeem bepaalt wat passend en proportioneel is. Maar het model maakt zichtbaar waar de grootste kloof zit, en dat is waar inrichtings- en auditcapaciteit het meeste opleveren.

5. Het raamwerk toegepast: de casus TriageAI

Theorie wordt concreet zodra je een systeem door alle vijf lagen volgt. Neem een fictief maar herkenbaar voorbeeld: verzekeraar X gebruikt 'TriageAI', een door de organisatie ingerichte AI-toepassing die draait op een ingekocht model dat binnenkomende schademeldingen automatisch indeelt in standaard afhandelen, extra controle of mogelijke fraude. Internal audit zet TriageAI op de auditplanning. Zo ziet de toets er per laag uit.

Laag 1. Governance en accountability. TriageAI staat keurig in het AI-register, met een eigenaar en risicoclassificatie. Maar tijdens een korte test op de werkvloer blijkt dat de schadeafdeling een publieke AI-tool gebruikt om klantbrieven op te stellen. Dat gebruik staat nergens geregistreerd. De eerste bevinding zit niet in het systeem, maar in de schaduw-AI eromheen.

Laag 2. Data en input. TriageAI draait op een gespecialiseerd leveranciersmodel, dus de verzekeraar heeft geen direct zicht op de trainingsdata. De auditor leest de model card en draait eigen testcases door het systeem. Daaruit blijkt dat het model vooral is getraind op een buitenlandse schadeportefeuille. Of dat representatief is voor de Nederlandse klantenkring is nooit beoordeeld.

Laag 3. Model en ontwikkeling. Een leveranciersmodel laat zich niet valideren als een zelfgebouwd model. De auditvraag verschuift daarom naar de inbedding: is er een betrouwbaarheidsdrempel ingesteld, en wat gebeurt er met meldingen waar TriageAI onzeker over is? Die drempel blijkt te bestaan, maar er is geen onafhankelijke sign-off op de inrichting ervan.

Laag 4. Inzet en monitoring. Het dashboard toont alleen aantallen verwerkte meldingen. Het percentage meldingen dat als mogelijke fraude wordt gemarkeerd, wordt niet bewaakt. De auditor ontdekt dat dit percentage in één kwartaal is verdubbeld, zonder dat iemand het signaleerde of analyseerde. Dat is minimaal een belangrijk monitoringssignaal en mogelijk een aanwijzing voor drift.

Laag 5. Uitkomst en impact. Klanten die als mogelijke fraude worden gemarkeerd, krijgen een standaardbrief en vertraging. Een casus-specifieke uitleg ontbreekt, en de bezwaarroute loopt via het reguliere klachtenproces zonder koppeling aan de AI-beslissing.

Het patroon is veelzeggend. Vier van de vijf bevindingen zitten in governance, data, monitoring en uitkomst. Slechts één raakt het model zelf, en ook die gaat over inbedding, niet over wiskunde. Dat bevestigt de kern van dit raamwerk: het grootste deel van het risico zit niet in de techniek, en je hebt geen data scientist nodig om het te vinden.

Net zo veelzeggend is de spiegel voor de riskfunctie: elk van deze vijf bevindingen had de eerste of tweede lijn zelf kunnen voorkomen of signaleren met de inrichtingsvragen uit hoofdstuk 3. Een werkvloertest op schaduw-AI, een representativiteitsbeoordeling bij inkoop, een sign-off op de drempelinstelling, een alert op het markeringspercentage en een casus-specifieke uitlegroute: geen ervan vereist technische diepgang, allemaal zijn ze organiseerbaar.

6. Aan de slag: twee routes

Voor risk en compliance: de eerste 90 dagen

Weken 1 tot 4, overzicht. Breng in kaart wat er werkelijk draait. Stel het AI-register op of actualiseer het, en doe expliciet een uitvraag en werkvloertest op informeel gebruik. Zonder betrouwbaar overzicht is elke volgende stap kwetsbaar voor schijnzekerheid.

Weken 5 tot 8, ordening. Classificeer de use cases naar risico: gebruik het AI Act-schema als vertrekpunt, maar weeg ook klantimpact, financiële materialiteit, mate van automatisering, persoonsgegevens, leveranciersafhankelijkheid en herstelbaarheid. Beleg eigenaarschap en stel basisbeleid vast, inclusief spelregels voor publieke AI-tools.

Weken 9 tot 13, beheersing. Richt voor de systemen met het hoogste risico de monitoring-, oversight- en leveranciersafspraken in, en plan de DPIA's en validaties die nog ontbreken. Leg een ritme vast: AI-governance is een doorlopend proces, geen project.

Voor internal audit: een AI-audit plannen

Voorbereiding en scoping. Begin bij het AI-register. Is er geen overzicht, dan is dat zelf een bevinding. Combineer de AI Act-classificatie altijd met een eigen auditrisicoweging, zodat systemen die juridisch niet hoog-risico zijn maar voor de organisatie wel materieel, niet buiten beeld blijven. Bepaal per systeem welke lagen je diep toetst en welke licht, mede op basis van het volwassenheidsmodel uit hoofdstuk 4.

Veldwerk. Loop per laag de toetsvragen en de evidence langs. Combineer documentonderzoek met een korte test op de werkvloer, want dat is de enige manier om schaduw-AI in beeld te krijgen. Stuit je op technische evidence die je niet inhoudelijk kunt beoordelen, haal er dan een AI-specialist bij voor die specifieke laag. Dat hoeft geen volledige co-auditor te zijn; meekijken is vaak voldoende.

Rapportage en opvolging. Weeg de bevindingen en houd de drie eigenschappen in gedachten. Door het veranderingstempo veroudert een control sneller dan bij een klassiek systeem; neem in het advies expliciet een herhaal- of monitoringfrequentie op. Een AI-audit is zelden een eenmalige toets. Betrek naast de model owner ook de business owner, IT en de privacy officer: bevindingen verspreiden zich vrijwel altijd over die rollen.

7. Drie veelgemaakte fouten

Technocentrisme. De organisatie (of de risk manager of auditor) probeert de wiskunde te begrijpen en blijft hangen in de techniek, terwijl het overgrote deel van het risico in governance, data, monitoring en uitkomst zit.

Vertrouwen zonder verificatie. De eigenaar zegt dat alles is gevalideerd en iedereen knikt. De eerste validaties zijn in de praktijk vaak licht of niet onafhankelijk. Vraag de validatierapporten op; zijn ze er niet, dan is dat een bevinding.

Schaduw-AI vergeten. Beleid, register en audit richten zich op de officiëel gedocumenteerde systemen, terwijl medewerkers dagelijks publieke AI-tools gebruiken. Dat informele gebruik kan in de praktijk een groter risico zijn dan de formele systemen. Maak het altijd onderdeel van de scope, van het beleid én van de audit.

Over Ferocia, en hoe wij kunnen helpen

Ferocia ondersteunt organisaties bij audit, risicomanagement en compliance, en leidt audit- en riskprofessionals op. Het vijflagenmodel uit dit artikel gebruiken wij zelf in de praktijk: bij nulmetingen AI-governance, bij de eerste inrichting van een AI-register en risicoclassificatie, en bij het opzetten of uitvoeren van AI-audits.

Wil je sparren over hoe jouw organisatie grip krijgt op AI, of weten waar je staat? Dat kan in de vorm van een afgebakend adviestraject, een nulmeting, een training of de tijdelijke inzet van een ervaren specialist die je team versterkt. We denken graag mee.

Bijlage A. Checklist inrichten (risk-bril)

Gebruik deze checklist om de inrichting van AI-governance op orde te brengen of te beoordelen. Proportionaliteit geldt: de risicoclassificatie van het systeem bepaalt hoe zwaar elk element wordt aangezet.

Laag 1. Governance en accountability

• Vastgesteld, actueel AI-beleid, inclusief spelregels voor publieke AI-tools

• AI-register of AI-inventarisatie met systemen en use cases, aangevuld met periodieke toets op schaduw-AI

• Risicoclassificatie per use case (AI Act-schema plus eigen weging)

• Eigenaarschap per systeem belegd (RACI)

• Goedkeuringsproces voor nieuwe AI-initiatieven

• Passende AI-geletterdheid voor ontwikkelaars, beheerders en gebruikers

Laag 2. Data en input

• Herkomst van trainings- en inputdata vastgelegd (data lineage)

• Representativiteit voor de toepassing beoordeeld

• DPIA uitgevoerd en actueel waar sprake is van een waarschijnlijk hoog privacyrisico

• Bias en uitschieters getest en gedocumenteerd

• Monitoring van inputdata in productie ingericht

• Bij inkoop: documentatie-eisen aan de leverancier gesteld

Laag 3. Model en ontwikkeling

• Model card met aannames, beperkingen en bekende risico's verplicht gesteld

• Passende validatie georganiseerd, waar mogelijk onafhankelijk en tegen een relevante benchmark

• Performance-metrics over de tijd ingericht

• Change logs voor model-updates

• Bij foundation- en leveranciersmodellen: inbedding beoordeeld, inclusief drempels, vangnetten en menselijke tussenkomst

• Contractuele afspraken: auditrechten, wijzigingsmeldingen, logging, incidentmelding, exit

Laag 4. Inzet en monitoring

• Actieve monitoring op werking en drift, met drempelwaarden en alerts

• Human oversight beschreven en belegd: wie grijpt wanneer in

• Incidentprocedure voor fouten, drift, misbruik en ongewenste uitkomsten

• Meldafspraken met leveranciers over wijzigingen, incidenten en kwetsbaarheden

• Toegangsbeheer, logging en autorisaties ingericht en periodiek beoordeeld

• Misbruikscenario's beoordeeld (prompt injection, datalekken via prompts, manipulatie van input)

• Maatregelen tegen het ongecontroleerd verwerken van vertrouwelijke gegevens in publieke AI-tools

Laag 5. Uitkomst en impact

• Analyse van uitkomsten per doelgroep op verschillen in behandeling

• Casus-specifieke uitleg voor betrokkenen beschikbaar

• Bezwaar- en correctiemechanisme ingericht

• Audit trail per beslissing

• Transparantierapportage waar passend

Bijlage B. Checklist toetsen (audit-bril)

Gebruik deze checklist als startpunt voor een AI-audit. Een vinkje betekent niet automatisch dat iets in orde is: het betekent dat je de evidence hebt gezien en inhoudelijk hebt beoordeeld.

Laag 1. Governance en accountability

• Er is vastgesteld, actueel AI-beleid

• Er is een AI-register of AI-inventarisatie met de bekende AI-systemen en use cases

• Het register bevat een risicoclassificatie per use case

• Per AI-systeem is een eigenaar benoemd (RACI)

• Er is een goedkeuringsproces voor nieuwe AI-initiatieven

• Schaduw-AI op de werkvloer is in kaart gebracht en meegenomen in de scope

• Medewerkers beschikken over passende AI-geletterdheid

Laag 2. Data en input

• De herkomst van de trainings- en inputdata is gedocumenteerd (data lineage)

• De representativiteit van de data voor de toepassing is beoordeeld

• Er is beoordeeld of een DPIA verplicht is; waar nodig is die uitgevoerd en actueel

• Bias en uitschieters in de data zijn getest en gedocumenteerd

• De inputdata in productie wordt gemonitord op afwijkingen

• Bij ingekochte of foundation models: model card gelezen en eigen testcases uitgevoerd

Laag 3. Model en ontwikkeling

• Er is een model card met aannames, beperkingen en bekende risico's

• Het model is gevalideerd tegen een benchmark

• Er zijn performance-metrics beschikbaar over de tijd, niet alleen bij oplevering

• Model-updates worden vastgelegd in change logs

• Er is een sign-off van de modeleigenaar en, waar passend, een onafhankelijke validator

• Bij foundation models: inbedding en vangnetten in de toepassing zijn beoordeeld

• Bij ingekochte modellen zijn contractuele afspraken, auditrechten en exit-afspraken beoordeeld

Laag 4. Inzet en monitoring

• Het model in productie wordt actief gemonitord op werking

• Er zijn drempelwaarden en alerts ingericht

• Human oversight is geregeld: duidelijk wanneer en door wie wordt ingegrepen

• Er is een incidentprocedure voor fouten en drift

• Incident-logs en escalatieprocedures zijn aanwezig en actueel

• Drift-monitoring is proactief, niet pas reactief op klachten

• Voor leveranciersmodellen is geregeld hoe wijzigingen, incidenten en kwetsbaarheden tijdig worden gemeld en opgevolgd

• Toegangsbeheer, logging en autorisaties zijn ingericht en periodiek beoordeeld

• Misbruikscenario's zijn beoordeeld (prompt injection, datalekken via prompts, ongeautoriseerd gebruik, manipulatie van input)

• Er zijn maatregelen om vertrouwelijke of persoonsgegevens niet ongecontroleerd in publieke AI-tools te verwerken

Laag 5. Uitkomst en impact

• Uitkomsten worden geanalyseerd op verschillen in behandeling per doelgroep

• Betrokkenen kunnen een casus-specifieke uitleg krijgen over een beslissing

• Er is een bezwaar- en correctiemechanisme

• Transparantie-informatie of -rapportage is beschikbaar waar passend

• Er is een audit trail per beslissing

• Concrete voorbeelden van aan betrokkenen verstrekte uitleg zijn opgevraagd en beoordeeld

Bronnen en verder lezen

• EIOPA, marktcijfers bij de Opinion on AI governance and risk management: AI-adoptie bij Europese verzekeraars, begin 2025.

• DNB, 'Verzekeraars en AI: DNB deelt nieuwste inzichten', januari 2026, dnb.nl.

• EIOPA, Opinion on Artificial Intelligence governance and risk management (EIOPA-BoS-25-360), 6 augustus 2025, eiopa.europa.eu.

• Awareways, Trendrapport 2025 'De opmars van de onzichtbare collega: Shadow AI', 2025.

• Raad en Europees Parlement, politiek akkoord Digital Omnibus-pakket, 7 mei 2026. Formele bekrachtiging stond bij publicatie nog open.

• ISO/IEC 42001:2023, Artificial intelligence management system, iso.org.

• ISO/IEC 42005:2025, AI system impact assessment, iso.org.

• ForHumanity, Independent Audit of AI Systems en EU AI Act-certificeringsschema, forhumanity.center.

• The IIA, Artificial Intelligence Auditing Framework (update 2024), theiia.org.

• NOREA, guidance en publicaties rond algorithm- en AI-assurance, norea.nl.

• NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0), nist.gov.