Meer in de kennisbank over AI-compliance
AI risicoanalyse: zo beoordeel je jouw AI-systemen.
Een AI-risicoanalyse legt drie lagen op elkaar: regulatorische classificatie onder de AI Act, de zeven operationele risicocategorieën en de ethische impact op betrokkenen. Operationeel gaat het om bias, hallucinatie, privacy, security, drift, leverancier-afhankelijkheid en IP; je loopt ze alle zeven langs en beargumenteert waar een risico niet speelt. De analyse wordt minimaal jaarlijks herzien, plus bij elke wijziging in systeem, context of regelgeving.
Prometheus21 werkt met een pragmatische template die AI Act-classificatie koppelt aan operationele risicobeoordeling. Onderdeel van onze AI-compliance-aanpak.
Geschreven door Prometheus21, AI-strategiepartner voor het MKB
Regulatorisch, operationeel, ethisch: alle drie in een serieuze AI-risicoanalyse
Operationele risicocategorieen: bias, hallucinatie, privacy, security, drift, afhankelijkheid, IP
Minimaal jaarlijks herzien, plus bij elke wijziging in systeem, context of regelgeving
De lagen in een risicoanalyse: eentje alleen is onvolledig.
Een AI risicoanalyse die alleen regulatorisch classificeert (AI Act-klasse bepalen), mist operationele werkelijkheid. Een analyse die alleen operationeel naar bias en hallucinatie kijkt, mist de juridische context. Een analyse die alleen ethische principes noemt, mist concreetheid. Serieuze analyses combineren drie lagen: regulatorisch (AI Act, AVG, sectorale regelgeving), operationeel (de zeven grote risicocategorieen) en ethisch (impact op betrokkenen). Alleen met deze drie samen heb je een document dat bij audit standhoudt en in de praktijk bruikbaar is voor besluitvorming.
| Laag | Wat erin zit | Wat je mist als je alleen deze laag doet |
|---|---|---|
| Regulatorisch | AI Act, AVG en sectorale regelgeving | De operationele werkelijkheid |
| Operationeel | De zeven grote risicocategorieën | De juridische context |
| Ethisch | De impact op betrokkenen | Concreetheid |
AI risk assessment als Engelse term wordt soms synoniem gebruikt, soms specifieker voor de operationele laag. We hanteren in deze gids de bredere Nederlandse uitleg. Wat in AI Act-context formeel Fundamental Rights Impact Assessment (Artikel 27) of algemene risicobeoordeling (Artikel 9, voor aanbieders) heet, plus de DPIA uit AVG (Artikel 35), samen met interne operationele risicomatrices vormen verschillende instrumenten die doorgaans overlappen. Onze aanpak is de overlap te benutten: een gecombineerd document dat meerdere verplichtingen tegelijk invult. Dit voorkomt dubbel werk en inconsistenties tussen documenten.
Voor MKB geldt nog: houdt het uitvoerbaar. Er bestaan AI-risicoanalyse-formats van 80+ paginas, overgenomen uit enterprise-contexten. Die worden in MKB zelden compleet ingevuld en als ze wel worden ingevuld, ligt het document ongelezen. Pragmatisch format voor MKB: vier tot acht paginas per AI-systeem. Strakke structuur, concrete risicopunten, meetbare maatregelen. Een document dat gelezen wordt is waardevoller dan een document dat volledig is maar niemand opent. Koppeling met onze bredere AI-compliance-aanpak.
Specifiek voor AI risico classificatie: twee niveaus onderscheiden. Regulatorische classificatie (verboden/high-risk/transparantie/minimaal onder AI Act) is gegeven door wet en eigenschap van het systeem; je kiest het niet, je stelt het vast. Operationele classificatie (laag/midden/hoog intern risico) bepaal je zelf op basis van eigen impact-schatting en risicomanagement-beleid. Deze twee classificaties kunnen uiteenlopen: een minimal-risk AI onder AI Act kan intern hoog risico hebben (bijvoorbeeld een spell-check-AI die stiekem bedrijfsgeheimen naar de leverancier stuurt). Beide documenteren. Zie ook onze high-risk-gids voor de regulatorische kant.
Het belangrijkste advies voor wie net start: doe de eerste risicoanalyse kort en pragmatisch. Denk niet 'ik wacht tot we het perfect kunnen'. Een zes-paginas-analyse per systeem, gebaseerd op een template, ingevuld in een halve tot hele werkdag, is honderd keer beter dan geen analyse. Pas later, bij herzieningen, verfijn je waar nodig. Dit is ook verdedigbaar bij toezichthouders: een proportioneel-volwassen proces dat doorontwikkelt, is begrijpelijk; geen proces is niet. Onze AI risicoanalyse template is ontworpen voor deze pragmatische eerste-ronde-realiteit. Koppeling met ons governance-framework.
AI Impact Assessment: Verzamelterm voor verschillende risicoanalyse-instrumenten onder AI Act (FRIA), AVG (DPIA) en branchestandaarden. Onze template bundelt de overlap.
Risico-matrix: Hulpmiddel om kans en impact te plotten, naast een beschrijving in tekst per risico. Gebruik beide.
Drie lagen samen
Regulatorisch plus operationeel plus ethisch. Alleen een van de drie maakt de analyse onvolledig en audit-kwetsbaar.
Beter kort en gedaan
Zes paginas ingevuld is oneindig beter dan vijftig paginas niet-ingevuld. Proportionaliteit is de MKB-vriend.
Bundeling voorkomt dubbel werk
Koppel AI Act-risicoanalyse, AVG-DPIA en interne matrix in een document. Meerdere verplichtingen, een bron.
De operationele risicocategorieen
Voor elk AI-systeem doorloop je deze zeven. Niet elk risico is relevant voor elk systeem. Check toch alle zeven en beargumenteer waar het niet speelt.
| Categorie | Waar het om gaat | Maatregelen uit de praktijk |
|---|---|---|
| Bias en discriminatie | Systematische afwijking in AI-output die groepen benadeelt | Bronnen van data-bias zoeken, fairness-metrics, monitoring in productie |
| Hallucinatie | Onjuiste output die zelfverzekerd klinkt | RAG met bronverankering, een testset, menselijke review bij hoge impact |
| Privacy en gegevenslekken | Persoonsgegevens die worden verwerkt of onbedoeld uitlekken | DPIA waar nodig, DPA met de leverancier, prompts zonder gevoelige data |
| Security en adversarial | Prompt injection, data poisoning, model theft en jailbreaking | Prompt injection testen, input-sanitatie en output-filter, rate-limiting |
| Model drift | Een model veroudert als de wereld eromheen verandert | Periodiek een holdout-testset, KPI-monitoring, drempels voor alerts |
| Leverancier-afhankelijkheid | De leverancier stopt, verlaagt de kwaliteit of verhoogt de prijs | Uitwijkbepalingen, data-portabiliteit, een abstractielaag voor kritieke systemen |
| IP en aansprakelijkheid | Output die inbreuk maakt op auteurs- of merkrechten | IP-garanties in het contract, review van publieke output, verzekering checken |
Bias en discriminatie
Bias is systematische afwijking in AI-output die bepaalde groepen benadeelt. Bronnen: niet-representatieve trainingsdata, menselijke labels met vooringenomenheid, onbedoelde correlaties in features. Gevolgen: discriminatie (juridisch risico onder AWGB en AVG), reputatieschade, slechte besluitvorming. Grootste aandacht bij HR-AI, kredietverlening, marketing-segmentatie. Documentatie: welke soorten bias gecheckt, via welke tests, welke maatregelen (data-balancering, fairness-metrics, human-oversight), welk restrisico. Meetbaar maken voorkomt vaag schrijven. Voor high-risk AI onder AI Act is bias-documentatie expliciet vereist (Artikel 10).
- Data-bias bronnen identificeren
- Fairness-metrics toepassen
- Jurdiisch raakvlak AWGB
- Monitoring in productie
Hallucinatie en feitelijke onjuistheid
Generatieve AI produceert onjuiste output die zelfverzekerd klinkt. Oorzaken: training-distributie-grenzen, gebrek aan bronverankering, prompt-mismatch. Impact bij klantenservice-chatbots, juridisch advies-AI, medische informatie-AI, financieel advies. Maatregelen: RAG-architectuur met bronverankering, citaat-verplichting, prompt-instructies om niet te verzinnen, output-validatie op onmogelijke claims, human-in-the-loop bij hoge impact, continue evaluatie via testset. Documenteer welke controles, wat het restrisico is, wie verantwoordelijk is voor monitoring. Voor klant-gerichte AI is dit vaak het grootste operationele risico. Koppeling met onze RAG-gids.
- RAG met bronverankering
- Testset voor evaluatie
- Prompt expliciet anti-verzin
- Human-review bij hoge impact
Privacy en gegevenslekken
AI-systemen kunnen persoonsgegevens verwerken, opslaan of onbedoeld lekken. Risico's: gebruik van persoonsgegevens zonder rechtsgrond, trainingsdata bevat persoonsgegevens die naar output uitlekt, prompts bevatten gevoelige info die bij leverancier belandt. AVG-raakvlak (Artikel 5, 6, 25, 32, 35). Maatregelen: DPIA uitvoeren bij high-risk verwerkingen, pseudonimisering/minimalisatie van input, DPA met AI-leverancier, beperking wie prompts mag insturen, technische controle op output-lekken. Voor Nederlandse MKB is de AVG-laag hier soms zwaarder dan de AI Act-laag. Documenteer welke persoonsgegevens betrokken zijn, rechtsgrond, bewaartermijn, ontvangers.
- DPIA waar nodig (AVG Art. 35)
- DPA met AI-leverancier
- Prompt-beleid zonder gevoelige data
- Output-monitoring op lekken
Security en adversarial
AI-systemen kennen specifieke security-risico's naast de gewone infra-risico's. Prompt injection: kwaadwillige input die het model instructies ontfutselt. Data poisoning: aanvallen op trainingsdata. Model theft: reverse-engineering van bedrijfsgeheimen via model-query's. Jailbreaking: omzeilen van guardrails. Maatregelen: input-sanitatie, output-filtering, rate-limiting, monitoring van verdachte patronen, adversarial testing. Voor customer-facing AI is prompt injection een reeel risico; check vooraf hoe de gebruikte AI-tool hier op reageert. Voor interne AI is data poisoning zelden aan de orde. Documenteer welke security-tests zijn gedaan en wat de bevindingen waren.
- Prompt injection testen
- Input-sanitatie en output-filter
- Rate-limiting
- Adversarial test voor release
Model drift en degradatie
AI-modellen verouderen als de wereld om hen heen verandert. Drift-types: concept drift (de werkelijkheid verandert, bijvoorbeeld nieuwe productcategorieen), data drift (input-distributie verandert, bijvoorbeeld ander klanttype), label drift (wat 'goed' betekent verandert). Zonder monitoring verslechtert AI stil. Maatregelen: periodieke evaluatie op holdout-testset, KPI-monitoring in productie, alerts bij afwijkingen, retraining-schema. Voor non-triviale productie-AI is dit belangrijk; zonder drift-monitoring wordt een eerst-werkende AI na maanden een risicobron. Documentatie: welke metrics, welke drempels, wat is het re-trainingsproces.
- Holdout-testset periodiek
- Productie-KPI's monitoren
- Drempels voor alerts
- Retraining-schema gedefinieerd
Leverancier-afhankelijkheid
Voor ingekochte AI (het meeste MKB-AI): wat als de leverancier stopt, kwaliteit verlaagt, prijs verhoogt of in faillissement raakt? Vendor lock-in via specifieke integraties verhoogt risico. Maatregelen: DPA met uitwijkbepalingen, data-portabiliteit geregeld contractueel, voor kritieke use cases architectuur die migratie tussen providers mogelijk maakt (abstractie-laag), leverancier-continuiteitscheck. Voor grote providers (OpenAI, Microsoft, Google) is leverancier-faillissement onwaarschijnlijk maar product-wijzigingen of prijs-escalatie wel degelijk risico. Documenteer migratie-plan voor kritieke systemen.
- Contract met uitwijkbepalingen
- Data-portabiliteit vooraf
- Abstractie-laag voor kritiek
- Migratie-plan gedocumenteerd
Intellectual property en aansprakelijkheid
AI-output kan inbreuk plegen op auteursrechten (gegenereerde content die op beschermd werk lijkt), merkrechten (gegenereerde namen) of andere IP. Trainingsdata kan onrechtmatig gebruikt zijn door de aanbieder, wat indirect deployer-risico's met zich meebrengt. Aansprakelijkheid voor AI-besluiten is juridisch in ontwikkeling, maar huidige lijn is dat de inzetter (deployer) aansprakelijk blijft voor gevolgen, behoudens contractuele aansprakelijkheidsverdeling met aanbieder. Maatregelen: leverancier-garanties over training-data-rechtmatigheid (contractueel), outputs niet klakkeloos gebruiken, human-review bij publieke publicatie, aansprakelijkheidsverzekering checken of AI-gebruik gedekt is. Documenteer contractuele bepalingen over IP en aansprakelijkheid. Koppeling met deployer-verplichtingen-gids.
- Contract met IP-garanties
- Human-review publieke output
- Aansprakelijkheidsverzekering
- Contractuele verdeling
Instrumenten die vaak verwarren
Verschillende regelgevingen eisen verschillende documenten die deels overlappen. Hier wat wel en niet hetzelfde is.
Fundamental Rights IA
Artikel 27 AI Act. Verplicht voor specifieke deployers van high-risk AI (publieke autoriteiten, private met publieke dienst). Focus: impact op fundamentele rechten (non-discriminatie, privacy, waardigheid, rechtsbescherming, enz.). Uitgevoerd voor ingebruikname. Voor commerciele MKB-deployers vaak niet verplicht. De inhoud kan wel relevante best practice zijn. Verwar FRIA niet met DPIA of algemene risicoanalyse.
Artikel 27 AI Act Beperkt publiek-gericht Fundamentele rechten Pre-use
Data Protection IA
Artikel 35 AVG. Verplicht voor verwerkingen met waarschijnlijk hoog privacy-risico. Focus: verwerking van persoonsgegevens. Voor high-risk AI onder AI Act vaak ook DPIA vereist. Inhoud overlapt met risicoanalyse maar specifiek privacy-gericht. Voor MKB relevanter dan FRIA omdat breder toepasselijk. Koppel AI-risicoanalyse en DPIA in een gecombineerd document waar mogelijk.
Artikel 35 AVG Breed toepasselijk Privacy-focus Bij hoog risico
Operationele risicoanalyse
Intern instrument; de wet schrijft het niet specifiek voor. Wel onderdeel van governance en voor high-risk AI onder AI Act (Artikel 9 voor aanbieders, impliciet voor deployers via Artikel 26 monitoring). Focus: de zeven operationele risico's uit deze gids. Onze template combineert dit met AI Act-classificatie en DPIA-elementen tot een gecombineerd document dat meerdere verplichtingen tegelijk invult.
Intern + governance 7 categorieen Combineerbaar MKB-format
| Instrument | Grondslag | Verplicht voor | Focus |
|---|---|---|---|
| FRIA | Artikel 27 AI Act | Specifieke deployers van high-risk AI, zoals publieke autoriteiten | Fundamentele rechten, vóór ingebruikname |
| DPIA | Artikel 35 AVG | Verwerkingen met waarschijnlijk hoog privacy-risico | Verwerking van persoonsgegevens |
| Operationele risicoanalyse | Intern instrument; voor aanbieders van high-risk AI Artikel 9 | Niet specifiek wettelijk verplicht | De zeven operationele risico's |
Stappen per AI-systeem
Een werkdag per systeem voor de eerste analyse. Daarna jaarlijkse herziening in twee tot vier uur.
- 01
Beschrijf systeem
Doel, input, output, gebruikers, beoogde baten, zonder dit geen zinvolle risicoanalyse. Halve dag werk.
- 02
Classificeer AI Act
Artikel 5, Annex III of Annex I, Artikel 50. Plus AVG-raakvlak, juridische laag vastleggen.
- 03
Risico's doorlopen, vastleggen en herzien
Per categorie kans, impact, maatregelen, restrisico, eigenaar. Halve dag tot een dag werk afhankelijk van complexiteit.
Maatregelen in governance, cadans voor herziening, monitoring-KPI's, incident-proces. Dit maakt de analyse levend.
Onze belofte: Per AI-systeem een pragmatische risicoanalyse van zes tot tien paginas, in een tot twee werkdagen. Audit-gereed, herhaalbaar, in begrijpelijke taal. Gekoppeld aan onze AI governance-gids.
Risicoanalyses uit praktijk
Hoe de methode er bij drie verschillende AI-systemen uit zag, en wat de voornaamste bevindingen waren.
Hallucinatie-risico dominant
Systeem: RAG-chatbot op eigen handleidingen en FAQ, voor klantenservice, draait op een grote LLM-API met Europese hosting.
AI Act: Limited risk (Artikel 50 transparantie-eis: moet als AI identificeren). Geen high-risk. AVG: verwerkt basis-persoonsgegevens in klantvragen, DPIA niet verplicht, eenvoudige risicobeoordeling uitgevoerd.
Operationele risico's: Hallucinatie dominant (kans: middel, impact: hoog bij foute klant-info); privacy (kans: laag, impact: middel). Bias beperkt relevant omdat content redelijk uniform is. Maatregelen: strikte prompt anti-verzin, citaat-verplichting, menselijke escalatie-optie, wekelijkse evaluatie op foutresponses, dagelijks drift-dashboard. Restrisico geaccepteerd door directie met gedocumenteerde rationale. Gecombineerd document van acht paginas, halve werkdag opstellen, jaarlijks herzien.
Bias als centrale zorg, high-risk onder AI Act
Systeem: Ingekochte AI-tool voor CV-screening, deployer-rol. Annex III lid 4 onderdeel a: werving/selectie van personen. High-risk onder AI Act.
Analyse-lagen: AI Act: high-risk deployer-verplichtingen Artikel 26 (human oversight, monitoring, logs). FRIA niet verplicht (geen publieke dienst). AVG: DPIA verplicht (Artikel 35 lid 3 onderdeel a). AWGB: non-discriminatie vereist. Bias-risico dominant.
Maatregelen: Leverancier-documentatie opgevraagd (Artikel 13 AI Act), bias-tests maandelijks op output-verdeling (fairness-metrics per beschermde categorie), human-in-the-loop voor elk kandidaat-besluit, kandidaten informeren dat AI wordt ingezet, maandelijks review door HR-director, incident-proces. Analyse-document twaalf paginas, gecombineerd DPIA plus AI-risicoanalyse. Audit-verklaarbaar.
IP en security als kernzorgen
Systeem: GitHub Copilot-achtige code-AI voor eigen developers. Gemiddelde kennisdeling met leverancier (via prompts). Deployer-rol.
Analyse: AI Act: minimal risk (niet Annex III, niet Artikel 5, geen Artikel 50-trigger). AVG: beperkt omdat geen persoonsgegevens in prompts als bedrijfsbeleid volgt. Operationele risico's dominant: IP (kans: middel, impact: hoog omdat gegenereerde code op bedrijfskritieke producten komt), security (prompts kunnen bedrijfsgeheimen bevatten), leverancier-afhankelijkheid (wat als tool stopt).
Maatregelen: Enterprise-plan met data-privacy-garanties van leverancier, DPA getekend, intern beleid over wat wel/niet in prompts mag (geen geheimen), developer-training over IP-hygiene bij gegenereerde code, regelmatige license-scans op gegenereerde code. Zes-paginas-analyse, halve werkdag werk, jaarlijks herzien. Les: 'minimal risk onder AI Act' betekent niet 'geen analyse nodig'. Interne risico's kunnen groot zijn zonder dat de Act het eist. Koppeling met onze compliance-aanpak.
Risicoanalyses voor jouw AI-systemen?
Plan een kennismaking om scope en tijdspad te bespreken. Start per systeem, bouw dossier op.
Valkuilen bij AI risicoanalyse
Wat risicoanalyses nutteloos of juist beter maakt.
Alleen juridische classificatie
Een analyse die alleen de AI Act-klasse bepaalt (high-risk of niet) en dan stopt, mist 80 procent van de operationele werkelijkheid. Bias, hallucinatie, drift en leverancier-afhankelijkheid spelen ook bij minimal-risk onder de Act. Altijd drie lagen: regulatorisch, operationeel, ethisch.
Vaag schrijven
'We voorkomen bias door zorgvuldig om te gaan met data' is vaag. Concreet: 'We meten demographic parity op output voor beschermde categorieen gender, leeftijd, herkomst, maandelijks op een sample van 500 output-cases, alertgrens bij pariteits-ratio onder 0,8. Maatregelen bij alert: review door HR-director, eventueel retraining.' Meetbaar maken maakt de analyse bruikbaar.
Niet herzien
Een analyse uit 2024 voor een AI die in 2026 vernieuwd is, is papier. Herzie bij elke wijziging in systeem, context of regelgeving. Minimaal jaarlijks. Agendeer dit in governance-cadans zodat het niet vergeten wordt.
Overgenomen templates
Een enterprise-template van 80 paginas kopieren en niet invullen is nutteloos. Kies een template dat past bij MKB-schaal. Liever zes paginas goed ingevuld dan 80 leeg. Vul alleen wat relevant is voor jouw systeem; markeer 'niet van toepassing' met rationale bij de rest.
ROI van goede risicoanalyse
Wat levert een goed uitgevoerde risicoanalyse op, meetbaar:
Investering
Per systeem: begeleiding, vooraf besproken
Interne tijd: 1-2 werkdagen
Jaarlijkse herziening: 2-4 uur per systeem
Opbrengst
Audit-gereedheid: within days overlegging
Vroege risicodetectie: voorkomt incidenten
Bewuste besluitvorming: MT beslist met cijfers
Bescherming en inzicht, geen klassieke financiele ROI. De alternatief-kosten (incident, boete, reputatie) maken het waarde-vol.
Veelgestelde vragen over AI risicoanalyse
Tien vragen die compliance-officers en directies ons vaak stellen.
Wat is een AI risicoanalyse?
Een AI risicoanalyse is een systematische beoordeling van de risico's die een specifiek AI-systeem met zich meebrengt voor de organisatie, gebruikers, betrokkenen en maatschappij. Het combineert drie lagen. Juridisch: classificatie onder de AI Act (verboden, high-risk, transparantie-eis, minimaal) en raakvlakken met AVG, sectorale regelgeving en contracten. Operationeel: bias, hallucinatie, privacy-lekken, security-kwetsbaarheden, model-drift, afhankelijkheid van leverancier. Ethisch: fairness naar betrokkenen, transparantie, menselijke controle. De analyse levert een document met geidentificeerde risico's, beoordeling op kans en impact, en bijpassende maatregelen. Dit document is onderdeel van AI Act-compliance en input voor governance-beslissingen.
Hoe beoordeel je het risico van een AI-systeem?
In drie stappen. Stap een: beschrijf het AI-systeem ondubbelzinnig. Doel, input-data, output, wie de output gebruikt, welke beslissingen erop worden gebaseerd. Stap twee: classificeer onder AI Act. Vanuit de Annex III-gebieden en Artikel 5-verbodspunten check je of het systeem onder een specifieke regulatorische categorie valt. Stap drie: beoordeel operationele risico's. Per categorie (bias, hallucinatie, privacy, security, drift) score je kans en impact op bijvoorbeeld een schaal van 1-5, en bepaal je maatregelen, eigenaar en cadans. Dit document wordt onderdeel van je AI-dossier en basis voor audit-overlegging.
Wat is AI risicoclassificatie?
AI risicoclassificatie heeft twee betekenissen die vaak door elkaar worden gebruikt. Ten eerste: de regulatorische classificatie onder de AI Act in vier klassen (verboden Artikel 5, high-risk Annex III of Annex I-producten, transparantie-eis Artikel 50, minimaal). Ten tweede: de operationele classificatie per AI-systeem op basis van eigen risicomatrix (laag, midden, hoog) voor intern risicomanagement. De eerste is gegeven door de wet; de tweede bepaal je zelf op basis van impact op de organisatie en stakeholders. In de praktijk doe je beide en combineer je ze in een samenvattend overzicht per systeem.
Welke AI-risico's moet je documenteren?
Voor high-risk AI onder AI Act: alle risico's die significant zijn voor de voorzienbaarheid van schade aan gezondheid, veiligheid of fundamentele rechten (Artikel 9 voor aanbieders, Artikel 26-27 voor deployers). Voor andere AI: minimaal de grote operationele risico's per categorie. Concreet: bias en discriminatie (met name bij HR- en kredietgebruik). Hallucinatie (onjuiste, maar zelfverzekerde output). Privacy-lekken (ongewenste uitgave van persoonsgegevens). Security-risico's (prompt injection, data-exfiltratie). Model-drift (kwaliteit die daalt over tijd). Afhankelijkheid van leverancier (wat als leverancier stopt). Intellectual property-risico (inbreuk op bronnen). Documentatie per risico: beschrijving, impact, waarschijnlijkheid, maatregelen, restrisico, eigenaar.
Wat is een AI Impact Assessment?
AI Impact Assessment is een verzamelterm die afhankelijk van context naar verschillende dingen verwijst. Onder de AI Act: Fundamental Rights Impact Assessment voor bepaalde deployers van high-risk AI (Artikel 27). Onder AVG: Data Protection Impact Assessment (DPIA, Artikel 35 AVG) voor verwerkingen met hoog privacyrisico. Onder ISO 42001: impact assessment als onderdeel van AI management system. Onder branchestandaarden: algoritme-impact-assessments zoals gepubliceerd door NL-overheid voor publieke sector. Voor MKB-private sector zijn de eerste twee meest relevant. Onze risicoanalyse-template bundelt de elementen zodat je in een document aan meerdere verplichtingen voldoet.
Wat is een Fundamental Rights Impact Assessment?
Een FRIA (Artikel 27 AI Act) is verplicht voor bepaalde deployers van high-risk AI, specifiek: publieke autoriteiten, overheidsinstellingen en private partijen die publieke diensten uitvoeren met impact op natuurlijke personen. De FRIA beschrijft doel en context van het AI-gebruik, betrokken categorieen personen, specifieke risico's voor fundamentele rechten (non-discriminatie, privacy, waardigheid, rechtsbescherming, enzovoort), menselijke controle, en maatregelen om risico's te beperken. De FRIA moet worden uitgevoerd voordat het systeem in gebruik wordt genomen. Voor commerciele MKB-deployers die geen publieke dienst leveren, is FRIA niet automatisch verplicht. De methodiek kan wel als best practice worden toegepast.
Wat is een AI risico-matrix?
Een risico-matrix is een visueel hulpmiddel dat kans en impact per risico plot op een raster, meestal 3x3, 4x4 of 5x5. Risico's in het hoge-kans-hoge-impact-kwadrant krijgen prioriteit voor maatregelen; risico's in lage-kans-lage-impact worden geaccepteerd. Voor AI-risicoanalyses is de matrix vooral bruikbaar als overzicht: welke risico's gedomineerd hoe de totaalblik. Let op: een matrix is een hulpmiddel, geen vervanging van diepere analyse. Risico's met zeer hoge impact (bijvoorbeeld massale discriminatie) verdienen maatregelen zelfs bij lage waarschijnlijkheid. Onze template combineert een matrix met textuele beschrijving per risico.
Hoe vaak herzie je een AI risicoanalyse?
Minimaal een keer per jaar, plus bij elke van deze triggers. De eerste is een wijziging in AI-systeem (update van model, nieuwe feature). De tweede is een wijziging in gebruiksdomein of gebruikersgroep. De derde is een incident. De vierde is een wijziging in regelgeving (implementatiedecreten AI Act, nieuwe richtsnoeren AI Office). De vijfde is een wijziging in risicoperceptie of externe aanleiding (bijvoorbeeld publicatie over nieuw type AI-risico). Voor high-risk AI onder AI Act is monitoring continu (Artikel 9 voor aanbieders, Artikel 26 voor deployers); herziening van risicoanalyse is bevestigingsmoment. Voor minder kritische AI volstaat jaarlijks. Documenteer herzieningsmomenten in governance-cadans.
Kan ik een AI risicoanalyse sjabloon downloaden?
Er bestaan publieke templates (onder meer van de AP, NIST in VS, ISO 42001-related frameworks). Geen van deze is een 1-op-1 AI Act-compliant template. Onze aanpak is: een pragmatische template die AI Act-classificatie combineert met operationele risicobeoordeling. We delen deze template bij intake-gesprekken. Belangrijk: een template werkt alleen als er iemand is die er kritisch mee werkt. Ingevulde templates zonder reviewer zijn cosmetisch. Gebruik de template dus als structuur; het denkwerk doe je zelf.
Hoe documenteer je AI-bias?
Per AI-systeem documenteer je welke soorten bias potentieel spelen (demografisch, selectie, confirmation, automation). Je documenteert waar bias kan intreden (trainingsdata, labeling, model-architectuur, gebruikscontext). Ook documenteer je wat je hebt gedaan om bias te meten (tests, fairness-metrics zoals demographic parity of equal opportunity). Daarnaast documenteer je wat je vindt (resultaten, gevonden disparities) en welke maatregelen je neemt (data-balancering, algoritme-aanpassing, human-oversight). Tot slot documenteer je welke restrisico's blijven en hoe je die bewaakt. Voor HR- en kredietgebruik-AI is dit in combinatie met Artikel 10 AI Act verplichte documentatie voor aanbieders; deployers erven een deel via Artikel 26 en moeten zelf monitoren. Documenteer concreet en blijf weg van abstracte principes.
Opgesteld met AI-ondersteuning door de redactie van Prometheus21, laatst bijgewerkt op . Hoe wij content maken
AI risicoanalyse laten uitvoeren
Plan een kennismaking om scope en tijdpad te bespreken. Per systeem een pragmatische risicoanalyse in een tot twee werkdagen, met onze template als basis.
