Ja, een gemeente moet een FRIA (grondrechtentoets) doen zodra zij een hoog-risico AI-systeem uit bijlage III van de AI Act inzet, behalve voor kritieke infrastructuur (bijlage III, punt 2). Voor nieuwe systemen geldt dat vanaf 2 december 2027; voor systemen die de gemeente al vóór die datum gebruikt, pas bij een aanzienlijke wijziging en uiterlijk op 2 augustus 2030 (artikel 111 lid 2). Wat een FRIA precies is en hoe u hem invult, staat in FRIA onder de AI Act: wat het is, wie hem moet doen en hoe u hem invult. Deze pagina gaat over de vraag hoe een gemeente of andere publieke organisatie dat in de praktijk regelt, tot en met het bestuur.
Gemeenten worstelen meestal niet met het idee dat AI grondrechten kan raken. Ze worstelen met het moment waarop die abstracte juridische vraag operationeel wordt. De aanbesteding is rond, de leverancier zegt dat het systeem compliant is, het beleidsteam wil live, en dan stelt iemand de ongemakkelijke vraag: hebben we de FRIA eigenlijk al gedaan?
Die vraag doet ertoe, want onder Artikel 27 is de FRIA geen taak van de aanbieder. Het is een verplichting voor de deployer, dus voor de gebruiksverantwoordelijke. Voor gemeenten, publieke instellingen en andere publieke teams die hoog-risico AI gebruiken, is dit een van de duidelijkste momenten waarop de EU AI Act zegt: het vendor-dossier is niet genoeg, je hebt je eigen beoordeling nodig.
Wanneer een gemeente echt een FRIA nodig heeft
De korte versie is niet “altijd” en ook niet “nooit.” Het hangt af van twee dingen.
Ten eerste moet het AI-systeem een hoog-risico AI-systeem zijn als bedoeld in Artikel 6 lid 2, dus een systeem dat onder de Bijlage III-logica valt en niet onder de productveiligheidsroute.
Ten tweede moet de deployer vallen in een van de categorieën uit Artikel 27. Dat zijn lichamen die worden beheerst door publiek recht, private entiteiten die publieke diensten leveren, en deployers van hoog-risico AI-systemen uit punten 5(b) en 5(c) van Bijlage III.
Voor gemeenten is de eerste categorie het belangrijkst. Een gemeente is een publiek lichaam. Als zij dus een kwalificerend hoog-risico AI-systeem uit Bijlage III inzet, dan komt de FRIA in beeld.
Er staat wel één belangrijke uitzondering rechtstreeks in Artikel 27 lid 1: hoog-risico AI-systemen die zijn bedoeld voor het gebied genoemd in punt 2 van Bijlage III vallen buiten de FRIA-plicht. Dat is de carve-out voor kritieke infrastructuur.
De gemeentelijke vraag is dus nooit alleen “zijn wij een publieke instantie?” De echte vraag is: “zijn wij een publieke instantie die een kwalificerend hoog-risico AI-systeem uit Bijlage III inzet buiten de uitzondering van punt 2?”
Als die classificatie nog mistig is, gebruik dan de risicobeoordelingstool en leg de use case naast de categorieën uit onze uitleg bij bijlage III van de AI Act.
Vanaf wanneer geldt de FRIA voor een gemeente?
Voor een nieuw systeem vanaf 2 december 2027. Sinds de Digital Omnibus (Verordening (EU) 2026/1744) gelden de hoog-risicoregels van bijlage III, en daarmee artikel 27, vanaf die datum.
Voor een systeem dat de gemeente al vóór 2 december 2027 gebruikt, geldt een overgangsregel. Volgens artikel 111 lid 2 raakt de verordening zo'n systeem pas bij een aanzienlijke wijziging in het ontwerp. Voor systemen die bedoeld zijn voor gebruik door overheidsinstanties geldt in elk geval een uiterste datum: aanbieder en gemeente moeten uiterlijk op 2 augustus 2030 voldoen. Voor een algoritme dat al jaren draait, is 2 december 2027 dus niet automatisch de deadline. Wacht toch niet tot 2030: een aanzienlijke wijziging, zoals een nieuw model of een nieuw doel, haalt die datum naar voren.
Publieke teams moeten stoppen met FRIA behandelen als een eindformulier
Een FRIA is niet het laatste document voor go-live. Het hoort juist de inzetbeslissing te vormen.
Dat blijkt ook als je Artikel 27 goed leest. De beoordeling moet plaatsvinden vóór de inzet van het hoog-risico AI-systeem. Simpel gezegd: voor eerste gebruik.
Als een gemeente pas met de FRIA begint nadat de inkoop dichtgetimmerd is, workflows al zijn ontworpen en intern eigenaarschap al is verdeeld, dan wordt de beoordeling snel defensief. Het team vraagt dan niet meer of de inzet nog moet veranderen. Het team zoekt vooral argumenten om de al gekozen inzet te verdedigen.
Dat is precies de verkeerde mindset voor publieke AI.
Wat Artikel 27 in de praktijk vereist
Artikel 27 lid 1 noemt zes onderdelen. De beste manier om die te lezen is niet als zes juridische vakjes, maar als zes operationele vragen.
1. In welk gemeentelijk proces wordt het AI-systeem gebruikt?
De FRIA moet de processen beschrijven waarin het systeem wordt gebruikt, in lijn met het beoogde doel.
Je hebt dus een echte procesbeschrijving nodig, geen productbeschrijving.
Als een AI-systeem wordt gebruikt in het sociaal domein, waar precies komt het dan in de keten binnen? Intake? Prioritering? Risicoscoring? Menselijke review? Escalatie? Ondersteuning bij het eindbesluit?
Als het systeem in HR wordt gebruikt, screent het dan kandidaten, rangschikt het sollicitanten of ondersteunt het interviews?
Een FRIA die alleen marketingtaal van de leverancier herhaalt, is al zwak.
2. Hoe vaak en hoe lang wordt het gebruikt?
Artikel 27 vraagt ook om een beschrijving van de gebruiksduur en gebruiksfrequentie.
Dat klinkt administratief, maar dat is het niet. Een tool die één keer per maand in een pilot wordt gebruikt heeft een ander risicoprofiel dan een systeem dat dagelijks op schaal door gemeentelijke processen draait.
3. Welke personen en groepen worden geraakt?
Hier blijven veel gemeenten te generiek. “Inwoners” is niet genoeg.
De FRIA moet concrete categorieën benoemen. Denk aan uitkeringsaanvragers, sollicitanten, ouders, leerlingen, mensen in schuldhulp, inwoners in kwetsbare wijken of gemeentemedewerkers. En die groepen worden niet allemaal op dezelfde manier geraakt.
Indirect effect telt ook. Als een systeem dossiers prioriteert, kunnen mensen die structureel lager op de stapel belanden net zo goed geraakt worden als mensen die actief worden geflagd.
4. Wat zijn de specifieke risico's op schade?
Dit is het analytische hart. Artikel 27 lid 1, onderdeel d, eist een beoordeling van de specifieke risico's op schade voor de geïdentificeerde personen of groepen, mede in het licht van de informatie die de provider op grond van Artikel 13 moet verstrekken.
Dat betekent dat de gemeente niet blind hoeft te gokken, maar ook niet mag stoppen bij het aanbiedersdossier. Leveranciersinformatie is input, geen vervanging van contextspecifieke analyse.
Voor publieke teams is de grondrechtenlens meestal breder dan privacy alleen. Non-discriminatie, toegang tot diensten, menselijke waardigheid, behoorlijk bestuur en toegang tot bezwaar of beroep wegen vaak net zo zwaar als gegevensbescherming.
5. Hoe is menselijk toezicht echt geregeld?
Artikel 27 vraagt om een beschrijving van de implementatie van menselijk toezicht, in lijn met de gebruiksinstructies.
Hier worden Artikel 14 en onze gids over menselijk toezicht direct relevant. Publieke teams moeten benoemen wie output beoordeelt, welke competentie die persoon heeft, wanneer die persoon kan overrulen en wat er gebeurt als mens en systeem botsen.
Een gemeentelijke FRIA wordt snel dun als “menselijk toezicht” een losse zin blijft in plaats van een echte workflow.
6. Wat gebeurt er als risico's werkelijkheid worden?
Artikel 27 lid 1, onderdeel f, vereist maatregelen voor het geval risico's zich materialiseren, inclusief interne governance en klachtenmechanismen.
Hier laten publieke organisaties vaak zien of ze het menen. Als een inwoner een AI-ondersteunde uitkomst wil aanvechten, is er dan een route? Als het systeem na livegang subgroepbias laat zien, wie grijpt dan in? Als aannames van de leverancier niet meer bij de praktijk passen, wie pauzeert het systeem?
Zonder die antwoorden is de FRIA in feite niet af.
FRIA en DPIA zijn niet hetzelfde, maar moeten wel met elkaar praten
Publieke teams vragen vaak of de FRIA de DPIA vervangt. Nee.
Artikel 27 lid 4 zegt juist dat wanneer een verplichting al is nagekomen via een DPIA onder AVG artikel 35, de gemeente in de FRIA mag verwijzen naar de relevante delen van die DPIA of die delen mag overnemen. Sinds de Digital Omnibus staat die kruisverwijzing uitdrukkelijk in de tekst.
Dat is een nuttige juridische aanwijzing. Privacy is niet het hele publieke grondrechtenplaatje, maar wel vaak een onderdeel daarvan. De praktische move is dus om de twee beoordelingen te verbinden in plaats van ze in gescheiden silo's te laten draaien.
Als je gemeente al een stevige DPIA-praktijk heeft, bouw daar de FRIA omheen. Breid daarna uit naar non-discriminatie, procedurele rechtvaardigheid, toegankelijkheid, uitlegbaarheid, menselijk toezicht en klachtenroutes. De vergelijking tussen DPIA en FRIA helpt als je team die twee nog door elkaar haalt.
Typische gemeentelijke use cases die direct serieuze review verdienen
Niet elke AI-tool bij de overheid is automatisch hoog-risico. Maar sommige categorieën moeten je team wel direct wakker maken.
Toegang tot essentiële publieke diensten
Als een gemeente AI gebruikt in processen die raken aan toegang tot essentiële publieke diensten of voorzieningen, dan moet de Bijlage III-analyse vroeg op tafel komen. Dit is een van de duidelijkste zones waar grondrechtenrisico concreet wordt.
HR en recruitment
Gemeentelijke tools voor werving, rangschikking van kandidaten of personeelssturing kunnen in de hoog-risicocategorie voor werk en arbeid vallen. Publieke organisaties vergeten soms dat ook “interne” HR-toepassingen grote AI Act-plichten kunnen oproepen.
Onderwijs en jeugddomein
Waar gemeentelijke functies raken aan onderwijsplaatsing, beoordeling of jeugddienstverlening, moet de rechtenanalyse zorgvuldig en concreet zijn, zeker wanneer minderjarigen of kwetsbare groepen betrokken zijn.
Handhaving, openbare orde en risicoscoring
Alles wat lijkt op risicoclassificatie, prioritering van handhaving of profilering in een publieke context verdient meteen juridisch en grondrechtelijk scherptewerk.
In al deze gevallen moet de Bijlage III-classificatie en de FRIA worden bekeken voordat operationeel enthousiasme sneller gaat dan juridische discipline.
Een praktische FRIA-workflow voor gemeenten
Als je een werkbaar gemeentelijk proces wilt, houd het dan eenvoudig en serieus.
- Classificeer de use case. Bevestig of het AI-systeem hoog-risico is onder Artikel 6 en Bijlage III.
- Vraag vroeg aanbiedersdocumentatie op. Vraag om de informatie uit Artikel 13, het beoogde doel, bekende beperkingen, testbewijs en vereiste toezichtmaatregelen.
- Beschrijf de gemeentelijke workflow. Breng in kaart waar het systeem het proces binnenkomt en waar mensen ingrijpen.
- Benoem getroffen groepen en risico's. Stop niet bij privacy. Beoordeel ook discriminatie, toegang, procedurele fairness en praktische schade.
- Verbind FRIA en DPIA. Waar persoonsgegevens worden verwerkt, moeten de beoordelingen elkaar versterken.
- Regel governance en bezwaar. Leg vast wie eigenaar is, wie kan pauzeren, wie klachten behandelt en hoe updates worden beoordeeld.
- Gebruik een echte template. Onze FRIA-generator en FRIA-template helpen structuur te brengen in plaats van te improviseren.
De FRIA in de bestuurskamer
Een FRIA die alleen in een vakteam leeft, verandert zelden iets. De beslissing om een systeem wel, niet of anders in te zetten, ligt uiteindelijk bij het bestuur. Zo brengt een gemeente de FRIA daar naartoe.
Een team met meer dan privacy
Privacyspecialisten hebben geen alleenrecht op de FRIA. Een werkbaar kernteam bestaat uit een jurist, een data-specialist die het model begrijpt, een beleidsadviseur die het domein kent en waar mogelijk een ethicus en een vertegenwoordiger van inwoners, bijvoorbeeld uit een wijk- of cliëntenraad. Overweging 96 van de AI Act noemt uitdrukkelijk het raadplegen van vertegenwoordigers van getroffen groepen, onafhankelijke deskundigen en maatschappelijke organisaties, met name bij gebruik in de publieke sector.
Van grondrechten naar een risicokaart
Leg per grondrecht de werking van het systeem naast de mogelijke schade. Wordt iemand gecategoriseerd? Krijgt hij een label dat moeilijk te weerleggen is? Scoor elk risico op impact (hoe ernstig is de schade bij een fout?) en waarschijnlijkheid (hoe groot is de kans dat het misgaat?). Zo ontstaat een kleurcodering die bestuurders direct begrijpen. Bij elk rood risico hoort een maatregel: datakwaliteitscontroles, bias-tests, een menselijk mandaat om beslissingen terug te draaien, uitleg aan inwoners.
Laat het model fout gaan, op papier
Het belangrijkste werk gebeurt in het gesprek, niet in het sjabloon. Werk scenario's uit waarin het systeem fout zit. Een voorbeeld: een alleenstaande vader met onregelmatige inkomsten wordt onterecht als frauderisico aangemerkt en raakt tijdelijk inkomensondersteuning kwijt. Hoe ziet de gemeente die fout? Welke noodrem heeft de inwoner? Zulke scenario's maken zichtbaar of menselijk toezicht en de klachtenroute echt werken.
Wat het college of de directie te zien krijgt
Geen rapport van veertig pagina's, maar een overzicht: de risicokaart, de genomen maatregelen en de restrisico's. Daarmee kan het college van B&W, of de directie van een andere publieke organisatie, een echt besluit nemen. Scoort een systeem nog rood op non-discriminatie, dan is uitstel of pauzeren tot er aanvullende bias-tests zijn een legitieme uitkomst van de FRIA.
Wat er openbaar wordt
De AI Act verplicht een gemeente niet om de volledige FRIA te publiceren. Wel geldt:
- de gemeente meldt de resultaten bij de markttoezichtautoriteit (artikel 27 lid 3);
- als overheidsinstantie registreert zij zich en het gebruik van een hoog-risicosysteem uit bijlage III in de EU-databank (artikel 49 lid 3), met een samenvatting van de bevindingen van de FRIA (bijlage VIII, afdeling C, punt 4). Voor rechtshandhaving, migratie, asiel en grenstoezicht gebeurt die registratie in een beveiligd, niet-openbaar deel (artikel 49 lid 4).
Publicatie in het algoritmeregister van de Nederlandse overheid is daarnaast een nationale route om in begrijpelijke taal uit te leggen welke risico's er zijn en welke waarborgen zijn getroffen.
Waar gemeenten meestal de fout ingaan
De eerste fout is de FRIA behandelen als vendor-paperwork. Dat is het niet. De provider kan input leveren, maar de deployer is eigenaar.
De tweede fout is te laat beginnen. Een FRIA die start nadat alle inhoudelijke keuzes al gemaakt zijn, produceert meestal vooral compliance-theater.
De derde fout is de analyse beperken tot privacy. Bij publieke inzet zijn rechten als non-discriminatie, behoorlijk bestuur en effectieve rechtsbescherming vaak net zo belangrijk.
De vierde fout is menselijk toezicht vaag houden. Als niemand kan uitleggen wie het systeem kan overrulen, dan is toezicht waarschijnlijk niet echt geregeld.
De vijfde fout is vergeten dat klachten en governance ook na livegang tellen, niet alleen ervoor.
De zesde fout is schijnparticipatie. Een inspraakavond met vijf bewoners is geen verankerde inwonersstem. Betrek een representatieve groep in meer dan één fase en laat zien wat er met hun inbreng is gedaan.
De zevende fout is één sjabloon voor alles. Een model voor jeugdhulp vraagt andere waarborgen dan een tool voor parkeervergunningen. Het format mag hetzelfde zijn, de inhoud nooit.
Waar je nu het beste heen kunt
Heeft je team eerst de bredere juridische achtergrond nodig, begin dan met FRIA onder de AI Act: wat het is, wie hem moet doen en hoe u hem invult. Heb je vooral een operationeel startpunt nodig, gebruik dan de FRIA-generator of download de FRIA-template. Twijfel je of een concrete toepassing onder bijlage III valt, leg hem dan voor in de casus-check.
En als je nog in de fase zit waarin je niet zeker weet of de use case überhaupt hoog-risico is, doe dat werk eerst. Een rommelige FRIA begint vaak met een rommelige classificatie.
Veelgestelde vragen
De belangrijkste vragen en antwoorden bij dit onderwerp.
Bronnen
Nieuwsbrief
Elke dinsdag de AI Act-week vooruit in 5 minuten
Praktische duiding van deadlines, richtsnoeren en toezicht, zodat u weet wat er deze week toe doet. Geen spam en u schrijft zich met één klik weer uit.
Praktisch en kort · Geen spam · Met één klik uitschrijven