AI Impact Assessment (FRIA): template + voorbeeld

Door Jasper van Horssen, Lead Auditor ISO 27001 · NIS2 Lead Implementer. Vakinhoudelijk gereviewd door Erik Bijkerk, Senior Consultant bij Dxfferent. Bijgewerkt juni 2026.

Een AI Impact Assessment, in de AI Act een Fundamental Rights Impact Assessment (FRIA), is een verplichte schriftelijke beoordeling vooraf van de risico’s die een hoog-risico-AI-systeem oplevert voor de grondrechten van de mensen die het raakt. De verplichting staat in artikel 27 van de AI Act (Verordening (EU) 2024/1689) en geldt vanaf 2 augustus 2026 voor een afgebakende groep gebruiksverantwoordelijken: publiekrechtelijke organen, particuliere entiteiten die openbare diensten verlenen, en deployers van AI voor kredietwaardigheidsbeoordeling of voor risicobeoordeling en prijsstelling bij levens- en ziektekostenverzekeringen. De inhoud ligt vast in zes elementen (artikel 27 lid 1, a tot en met f). Hieronder leest u wie de FRIA precies moet doen, hoe hij verschilt van een DPIA en van de provider-conformiteitsbeoordeling, plus een invulbaar template en een uitgewerkt, hypothetisch voorbeeld.

Laatst bijgewerkt: 8 juni 2026. De FRIA-verplichting (artikel 27 AI Act) treedt in werking op 2 augustus 2026, als onderdeel van fase 4 van de gefaseerde invoering. Het officiele template van het AI-bureau (artikel 27 lid 5) is medio 2026 nog niet gepubliceerd; de verplichting geldt niettemin vanaf de ingangsdatum.

Wat is een AI Impact Assessment (FRIA) volgens de AI Act?

Een FRIA is een gestructureerde beoordeling, opgesteld voor het eerste gebruik van een hoog-risico-AI-systeem, van de specifieke risico’s die dat systeem oplevert voor de grondrechten van betrokkenen. Anders dan veel andere documenten in een AI-dossier is de FRIA expliciet gericht op mensen: discriminatie, eerlijke procesgang, privacy, het recht op een effectief rechtsmiddel, niet op de technische werking van het model. Artikel 27 lid 1 van de AI Act bepaalt dat de gebruiksverantwoordelijke (in EU-jargon de “deployer”) de beoordeling uitvoert “voordat een AI-systeem met een hoog risico in gebruik wordt gesteld”.

De FRIA is bewust beperkt in reikwijdte. Hij ziet niet op alle AI, maar uitsluitend op hoog-risico-AI-systemen in de zin van artikel 6 lid 2 en bijlage III, en zelfs daarbinnen alleen voor de deployer-categorieen die artikel 27 noemt. Artikel 27 lid 1 zondert bovendien expliciet de hoog-risico-systemen uit bijlage III punt 2 (kritieke infrastructuur) uit van de FRIA-plicht. Voor andere AI-toepassingen kan een impactanalyse zinvol zijn als goed bestuur, maar wettelijk verplicht is hij dan niet.

Belangrijk verschil met de oude tekst van dit artikel: de FRIA staat niet “los van” de DPIA, maar vult die aan. Artikel 27 lid 4 bepaalt dat als al een gegevensbeschermingseffectbeoordeling (DPIA) op grond van artikel 35 AVG (of artikel 27 van Richtlijn (EU) 2016/680) is uitgevoerd, de grondrechten-effectbeoordeling “een aanvulling vormt” op die DPIA. In de praktijk betekent dit: een geintegreerd dossier waarin de DPIA de gegevensbeschermingsrisico’s afdekt en de FRIA de bredere grondrechten-impact, zonder dubbel werk.

Wanneer is een AI Impact Assessment verplicht?

Artikel 27 lid 1 begrenst de verplichting tot drie categorieen gebruiksverantwoordelijken die een hoog-risico-AI-systeem inzetten:

• Publiekrechtelijke organen: in de verordening “gebruiksverantwoordelijken die publiekrechtelijke organen zijn”, oftewel overheidsorganen en daarmee gelijkgestelde instellingen.
• Particuliere entiteiten die openbare diensten verlenen: in de verordening “particuliere entiteiten die openbare diensten verlenen”, bijvoorbeeld via een concessie of publieke taak (onderwijs, zorg, sociale zekerheid).
• Deployers van twee specifieke hoog-risico-toepassingen uit bijlage III, punt 5: AI voor het beoordelen van de kredietwaardigheid of het vaststellen van een kredietscore van natuurlijke personen (punt 5 b, “met uitzondering van AI-systemen die gebruikt worden om financiele fraude op te sporen”), en AI voor risicobeoordeling en prijsstelling met betrekking tot natuurlijke personen bij levens- en ziektekostenverzekeringen (punt 5 c).

Buiten deze drie categorieen is een FRIA wettelijk niet verplicht, ook niet voor andere deployers van hoog-risico-AI. Wij adviseren een grondrechten-beoordeling in die gevallen wel als goed bestuur: het is de meest directe manier om risico’s te identificeren en mitigatie te plannen voordat een systeem live gaat, en toezichthouders en certificerende instellingen zien zo’n beoordeling als waardevolle bewijslast. Maar presenteer hem dan als vrijwillig instrument, niet als artikel-27-plicht.

De verplichting geldt bij het eerste gebruik van het systeem (artikel 27 lid 2). De deployer mag in soortgelijke gevallen steunen op een eerder uitgevoerde FRIA of op bestaande effectbeoordelingen die de provider al heeft gemaakt, mits hij die actualiseert wanneer een van de in lid 1 vermelde elementen is gewijzigd of niet langer actueel is. In Nederland sluit de FRIA inhoudelijk aan op het al langer bestaande IAMA (Impact Assessment Mensenrechten en Algoritmen), dat de Universiteit Utrecht in opdracht van het ministerie van BZK ontwikkelde en in 2025 actualiseerde om beter aan te sluiten op de AI Act. Het IAMA is geen wettelijk verplicht AI-Act-instrument, maar een bruikbare onderlegger voor de FRIA.

Verschil tussen FRIA, DPIA en conformiteitsbeoordeling

Drie beoordelingen worden in de praktijk door elkaar gehaald. Ze hebben een ander doel, een andere verantwoordelijke en een andere wettelijke grondslag:

• DPIA (AVG artikel 35): gericht op gegevensbeschermingsrisico’s, verplicht bij verwerking met een hoog privacyrisico. Verantwoordelijke: de verwerkingsverantwoordelijke. Smaller dan de FRIA, en de FRIA vult de DPIA aan (artikel 27 lid 4), vervangt hem niet.
• FRIA (AI Act artikel 27): gericht op de bredere grondrechten-impact, verplicht voor de drie genoemde deployer-categorieen van hoog-risico-AI. Verantwoordelijke: de gebruiksverantwoordelijke (deployer).
• Conformiteitsbeoordeling (AI Act artikel 43 en risicobeheersysteem artikel 9): de formele check of een hoog-risico-systeem aan alle AI-Act-eisen voldoet voordat het op de markt komt, plus het lifecycle-brede risicobeheersysteem. Verantwoordelijke: de provider (aanbieder), niet de deployer.

De kern: de conformiteitsbeoordeling is een provider-plicht over het systeem zelf; de FRIA is een deployer-plicht over de inzet van dat systeem in een concrete context. Organisaties bundelen deze beoordelingen het beste in een geintegreerde risico-aanpak. Een werkend ISO 42001 managementsysteem levert het procesmatige kader waarin DPIA, FRIA en het AI-register samenkomen.

De zes verplichte elementen van een FRIA (artikel 27 lid 1)

Artikel 27 lid 1 schrijft de inhoud van de FRIA voor in zes elementen, a tot en met f. Dit zijn de zes die de wet noemt; de invulvragen erbij zijn onze praktische uitwerking, geen extra wettelijke eisen.

1. (a) Beschrijving van de processen van de deployer: in welk werkproces wordt het hoog-risico-AI-systeem ingezet, in lijn met het beoogde doel, en hoe wordt de output gebruikt.
2. (b) Periode en frequentie van gebruik: binnen welke periode en hoe vaak wordt het systeem ingezet.
3. (c) Categorieen betrokken natuurlijke personen en groepen: welke personen of groepen worden in de specifieke context waarschijnlijk geraakt (klanten, sollicitanten, burgers, leerlingen).
4. (d) Specifieke risico’s op schade aan grondrechten: welke specifieke risico’s op schade voor de onder (c) geidentificeerde personen of groepen waarschijnlijk zijn (discriminatie, privacy, eerlijke procesgang, recht op effectieve rechtsbescherming), rekening houdend met de informatie die de aanbieder op grond van artikel 13 verstrekt.
5. (e) Maatregelen voor menselijk toezicht: hoe het menselijk toezicht is ingericht, conform de gebruiksaanwijzing van het systeem, en wanneer mensen kunnen ingrijpen.
6. (f) Maatregelen bij materialisatie van de risico’s: wat de deployer doet als een risico zich voordoet, inclusief de regelingen voor interne governance en klachtenmechanismen.

Let op een veelgemaakte fout: het zijn er zes, niet acht. Onderwerpen die soms apart worden opgevoerd, zoals bezwaar- en herstelmechanismen of de governance-borging, vallen onder element (f) (“arrangements for internal governance and complaint mechanisms”). Houd in het document de zes wettelijke koppen aan, en werk bezwaar en governance daarbinnen uit. Dat voorkomt discussie met een toezichthouder over of u de wettelijke structuur volgt.

Na het uitvoeren van de FRIA volgt een procedurele stap die in de oude versie van dit artikel ontbrak: op grond van artikel 27 lid 3 stelt de deployer de markttoezichtautoriteit in kennis van de resultaten en dient hij daarbij het ingevulde sjabloon in (in het in artikel 46 lid 1 bedoelde geval kan de deployer van die kennisgeving worden vrijgesteld). Omdat het officiele template van het AI-bureau medio 2026 nog niet beschikbaar is, gebruikt u tot die tijd een eigen format dat de zes elementen volgt; vervang dat zodra het AI-bureau het sjabloon publiceert.

FRIA-template: invulbare structuur volgens artikel 27

Hieronder staat een invulbaar template dat de zes wettelijke elementen een-op-een volgt. Kopieer de koppen naar uw eigen document en vul per onderdeel de antwoorden in. Houd het feitelijk en verifieerbaar: een toezichthouder leest dit als bewijsdossier.

0. Identificatie (administratief)

• Naam en versie van het AI-systeem, provider, datum van de beoordeling, opsteller(s).
• Deployer-categorie (artikel 27 lid 1 a, b of c) en de grond waarop de FRIA-plicht geldt.
• Verwijzing naar de bijbehorende DPIA (indien aanwezig) en naar het AI-register.

(a) Beschrijving van het deployer-proces

• In welk werkproces wordt het systeem ingezet, en wat is het beoogde doel volgens de gebruiksaanwijzing?
• Welke output levert het systeem, en hoe wordt die output in de besluitvorming gebruikt?
• Welke beslissing volgt op de output, en wie neemt die beslissing?

(b) Periode en frequentie van gebruik

• Binnen welke periode wordt het systeem ingezet (continu, projectmatig, seizoensgebonden)?
• Hoe vaak draait het systeem, en op welk volume aan gevallen of personen?

(c) Categorieen betrokken personen en groepen

• Welke groepen worden geraakt (direct en indirect)?
• Bevinden zich daaronder kwetsbare groepen, en zo ja, welke?

(d) Specifieke risico’s op schade aan grondrechten

• Welke grondrechten kunnen in het geding komen (non-discriminatie, privacy, eerlijke procesgang, effectieve rechtsbescherming, overig)?
• Per risico: waarschijnlijkheid, ernst en de bron van het risico (bijvoorbeeld bias in trainingsdata).

(e) Maatregelen voor menselijk toezicht

• Hoe is het menselijk toezicht ingericht conform de gebruiksaanwijzing?
• Op welk moment en op welke gronden kan een mens de output overrulen of het proces stoppen?

(f) Maatregelen bij materialisatie, governance en klachten

• Welke stappen gelden als een risico zich voordoet (escalatie, terugval naar handmatig proces, uitschakelen)?
• Interne governance: wie is verantwoordelijk, wie keurt af, hoe vaak wordt herbeoordeeld?
• Klachtenmechanisme: hoe kunnen betrokkenen bezwaar maken of een beslissing laten toetsen?

Na invulling: leg de uitkomst voor aan de verantwoordelijke binnen de governance-structuur, stel de markttoezichtautoriteit in kennis van de resultaten (artikel 27 lid 3), en neem de FRIA op in het AI-register. Een downloadbare versie van dit template als losse deliverable is in voorbereiding (zie de sectie “Template als losse deliverable” verderop).

Voorbeeld FRIA (hypothetisch): AI-voorselectie bij werving

Het volgende voorbeeld is fictief en uitsluitend bedoeld om de zes elementen te illustreren. Het beschrijft geen bestaand systeem en de cijfers zijn indicatief. AI voor werving en selectie staat overigens in bijlage III, punt 4, als hoog-risico; of een FRIA-plicht ontstaat hangt af van de deployer-categorie. We werken het voorbeeld uit om de structuur te tonen, niet om een verplichting te suggereren.

(a) Deployer-proces

Een middelgrote werkgever zet een AI-tool in die cv’s analyseert op vereiste competenties, ervaring en opleiding. De output is een score (0 tot 100) en een rangschikking. Recruiters gebruiken die als hulpmiddel bij de eerste selectie. De beslissing om iemand uit te nodigen neemt de recruiter, niet de AI.

(b) Periode en frequentie

Inzet bij alle externe vacatures, naar verwachting 80 tot 120 vacatures per jaar, gemiddeld 35 cv’s per vacature. Het systeem wordt elke zes maanden geherevalueerd.

(c) Categorieen betrokken personen

Sollicitanten op vacatures van de organisatie. De beoordeling raakt zowel mensen die wel als mensen die niet worden uitgenodigd. Aandachtsgroep: kandidaten met een niet-standaard cv-opbouw (loopbaanonderbreking, anderstalige opleiding), die door de tool systematisch lager kunnen scoren.

(d) Specifieke grondrechten-risico’s

• Non-discriminatie: risico op systemische bias tegen specifieke groepen (gender, etniciteit, leeftijd) door bias in de trainingsdata.
• Recht op werk en eerlijke arbeidsvoorwaarden: indirecte beinvloeding van de toegang tot werk.
• Privacy: verwerking van persoonsgegevens uit cv’s (overlapt met de DPIA, die de FRIA aanvult).
• Recht op effectieve rechtsbescherming: kan een afgewezen sollicitant de beslissing laten toetsen?

(e) Menselijk toezicht

• Geen automatische afwijzing op basis van de AI-score; de recruiter beslist.
• Maandelijkse steekproef (5 procent) waarbij een recruiter de beslissing toetst zonder de AI-score te zien.
• Recruiters worden getraind in het herkennen van AI-bias en het kritisch wegen van de output.

(f) Maatregelen bij materialisatie, governance en klachten

• Bij materialisatie: de leverancier levert een bias-auditrapport met analyse per demografische groep; kwartaalwijs vergelijkt de organisatie de uitnodigingspercentages per gender, leeftijd en herkomst; de scoredrempel wordt zo gekalibreerd dat er geen onevenredige uitval voor beschermde groepen ontstaat. Afkeurcriterium: meer dan 10 procent afwijking in uitnodigingspercentage per beschermde groep betekent dat het systeem uit productie gaat.
• Interne governance: de HR-directeur is business owner, de CISO compliance-eigenaar, de FG verzorgt de DPIA-laag; herbeoordeling halfjaarlijks en bij elke materiele wijziging.
• Klachtenmechanisme: sollicitanten worden geinformeerd dat AI wordt gebruikt (in de vacature en het privacy-statement); zij kunnen schriftelijk om herziening vragen, waarna een tweede recruiter de beslissing zonder AI-score beoordeelt; klachten worden geregistreerd en in de periodieke directiebeoordeling gerapporteerd.

Wie voert het AI Impact Assessment uit?

De gebruiksverantwoordelijke is wettelijk verantwoordelijk, maar in de praktijk vult een multidisciplinair team de FRIA in:

• Business owner: kent het proces en de use case.
• Compliance officer of CISO: bewaakt structuur en wettelijke vereisten.
• Privacy officer (FG): brengt de DPIA-overlap in.
• Juridisch adviseur: beoordeelt de grondrechten-aspecten.
• Technisch expert: kent het systeem en zijn beperkingen.
• Vertegenwoordiger van eindgebruikers of betrokkenen: brengt het perspectief van geraakte groepen in.

Na afronding stelt de deployer de markttoezichtautoriteit in kennis van de resultaten (artikel 27 lid 3). In Nederland regelt de Uitvoeringswet AI-verordening (op het moment van schrijven in consultatie) uitsluitend het nationale toezicht, niet de inhoud van de FRIA; die volgt rechtstreeks uit de EU-verordening. Het College voor de Rechten van de Mens wordt naar verwachting een van de autoriteiten die op grondrechten toeziet. Voor publieke instanties geldt bovendien dat de inzet van hoog-risico-AI transparant en navolgbaar moet zijn; voor commerciele deployers blijft de FRIA intern, maar opvraagbaar voor de toezichthouder.

Wat moet je doen na het assessment?

Een FRIA is geen eenmalig stuk. Artikel 27 lid 2 verlangt actualisatie wanneer een van de in lid 1 vermelde elementen is gewijzigd of niet langer actueel is. Concreet werkt u de FRIA bij wanneer:

• het AI-systeem materieel verandert (nieuw model, nieuwe trainingsdata, andere parameters);
• de use case wijzigt (andere doelgroep, andere proces-context);
• uit monitoring blijkt dat het risicoprofiel is verschoven;
• er een serieus incident heeft plaatsgevonden.

Een werkbaar ritme is een halfjaarlijkse herziening, plus ad-hoc updates bij wijzigingen. De FRIA wordt onderdeel van het AI-register (zie AI governance) en blijft opvraagbaar voor de toezichthouder.

Integratie met bestaande risicoprocessen

Voor organisaties met een werkend ISO 27001 ISMS is de FRIA goed in te bedden in bestaande risicoprocessen. Onze ervaring in de adviespraktijk: organisaties met een gecertificeerd ISMS hebben de risicobeoordelingsmethodiek al staan, en de FRIA voegt daar vooral het grondrechten-perspectief en een breder belanghebbenden-overleg aan toe (praktijkinschatting van Dxfferent, geen externe statistiek). Bij Dxfferent bouwen we de FRIA als laag bovenop de bestaande risicoanalyse, niet als een parallel proces. ISO 42001 levert daarbij het AI-specifieke managementkader; ISO 27001 het bredere informatiebeveiligingsfundament.

Template als losse deliverable

Het invulbare template hierboven is direct bruikbaar in uw eigen documentbeheer. Een downloadbare versie (Word en PDF) volgens dezelfde zes elementen, inclusief het hypothetische HR-voorbeeld als ingevuld referentievoorbeeld, is in voorbereiding als losse deliverable. Als interim-onderlegger, zolang het officiele template er nog niet is, kunt u de praktijkstructuur uit de FRIA-gids van ECNL en het Danish Institute for Human Rights gebruiken. Zodra het AI-bureau het officiele artikel-27-template publiceert, stemmen we onze versie daarop af, zodat u meteen in het verwachte formaat indient bij de markttoezichtautoriteit. Wilt u nu al sparren over uw FRIA-aanpak? Neem contact op via de bedrijfspagina.

Lees ook

• Wat is de AI Act? De EU-AI-verordening uitgelegd
• Risicoclassificatie onder de AI Act: van minimaal tot hoog risico
• AI governance: grip op AI-risico’s binnen uw GRC-raamwerk

Veelgestelde vragen over de FRIA (AI Impact Assessment)

Wat is een FRIA en wanneer is hij verplicht?

Een FRIA (Fundamental Rights Impact Assessment) is een verplichte beoordeling vooraf van de grondrechten-risico’s van een hoog-risico-AI-systeem (artikel 27 AI Act). Hij is verplicht vanaf 2 augustus 2026 voor drie groepen gebruiksverantwoordelijken: publiekrechtelijke organen, particuliere entiteiten die openbare diensten verlenen, en deployers van AI voor kredietwaardigheidsbeoordeling of voor risicobeoordeling en prijsstelling bij levens- en ziektekostenverzekeringen.

Is een FRIA hetzelfde als een DPIA?

Nee. Een DPIA (AVG artikel 35) richt zich op gegevensbeschermingsrisico’s; een FRIA (AI Act artikel 27) op de bredere grondrechten-impact. Ze zijn niet inwisselbaar: artikel 27 lid 4 bepaalt dat de FRIA de DPIA aanvult. Voor een AI-systeem dat persoonsgegevens verwerkt, maakt u in de praktijk een geintegreerd dossier met DPIA-secties en FRIA-secties.

Uit hoeveel elementen bestaat een FRIA?

Uit zes, vastgelegd in artikel 27 lid 1 a tot en met f: (a) beschrijving van het deployer-proces, (b) periode en frequentie van gebruik, (c) categorieen betrokken personen en groepen, (d) specifieke grondrechten-risico’s, (e) maatregelen voor menselijk toezicht, en (f) maatregelen bij materialisatie van de risico’s, inclusief interne governance en klachtenmechanismen. Bezwaar- en governance-onderdelen vallen onder element (f), niet als losse zevende of achtste element.

Bestaat er een officieel FRIA-template?

Artikel 27 lid 5 verplicht het AI-bureau om een template-vragenlijst te ontwikkelen, onder meer via een geautomatiseerd instrument. Medio 2026 is dat officiele template nog niet gepubliceerd. Tot die tijd gebruikt u een eigen format dat de zes wettelijke elementen volgt; de verplichting zelf geldt onverkort vanaf 2 augustus 2026.

Moet de FRIA worden gedeeld met een toezichthouder of gepubliceerd?

Op grond van artikel 27 lid 3 stelt de deployer de markttoezichtautoriteit in kennis van de resultaten en dient hij daarbij het ingevulde sjabloon in. Een algemene publicatieplicht voor de volledige FRIA volgt niet uit artikel 27; wel geldt voor publieke instanties dat de inzet van hoog-risico-AI transparant en navolgbaar moet zijn. Voor commerciele deployers blijft de FRIA intern, maar opvraagbaar voor de toezichthouder.

Hoe lang duurt een AI Impact Assessment?

Voor een eerste FRIA op een hoog-risico-systeem rekent u in de praktijk op vier tot acht weken, afhankelijk van de complexiteit, de beschikbaarheid van leveranciersinformatie en het aantal betrokken disciplines. Vervolgupdates duren doorgaans een tot twee weken. Dit zijn praktijkindicaties (Dxfferent-praktijk), geen wettelijke termijnen.

Wat is de sanctie als ik geen FRIA heb terwijl die verplicht is?

De AI Act kent gelaagde boetes (artikel 99). De zwaarste categorie (tot 35 miljoen euro of 7 procent van de wereldwijde jaaromzet) geldt alleen voor verboden AI-praktijken uit artikel 5, dus niet voor een ontbrekende FRIA. Verplichtingen van gebruiksverantwoordelijken vallen onder het regime van tot 15 miljoen euro of 3 procent (artikel 99 lid 4, dat verwijst naar artikel 26). Artikel 27 wordt in die opsomming niet met name genoemd, dus de exacte boetekwalificatie van een FRIA-tekortkoming is een open punt dat per geval door de toezichthouder wordt bepaald. Belangrijker dan de boete: zonder FRIA mist u het risico-overzicht dat nodig is om een hoog-risico-AI-systeem verantwoord in productie te houden.