Responsible AI Platform

FRIA voor gemeenten: gids voor publieke sector

··10 min leestijd

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 gids over hoog-risico AI-systemen.

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.

LearnWize2 minuten, geen account nodig

Leer de EU AI Act door te doen

Geen slides. Geen saaie e-learning. Probeer een interactieve module.

Interactive ChallengePowered by LearnWize LearnWize

Probeer het zelf

3 interactieve oefeningen. Verdien XP. Ontdek waarom dit beter werkt dan lezen.

LearnWizeDoe de volledige test op LearnWize
FlashcardsMatchingAudit

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 verplichtingen al zijn gedekt via een DPIA onder AVG Artikel 35, de FRIA die DPIA aanvult.

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.

  1. Classificeer de use case. Bevestig of het AI-systeem hoog-risico is onder Artikel 6 en Bijlage III.
  2. Vraag vroeg aanbiedersdocumentatie op. Vraag om de informatie uit Artikel 13, het beoogde doel, bekende beperkingen, testbewijs en vereiste toezichtmaatregelen.
  3. Beschrijf de gemeentelijke workflow. Breng in kaart waar het systeem het proces binnenkomt en waar mensen ingrijpen.
  4. Benoem getroffen groepen en risico's. Stop niet bij privacy. Beoordeel ook discriminatie, toegang, procedurele fairness en praktische schade.
  5. Verbind FRIA en DPIA. Waar persoonsgegevens worden verwerkt, moeten de beoordelingen elkaar versterken.
  6. Regel governance en bezwaar. Leg vast wie eigenaar is, wie kan pauzeren, wie klachten behandelt en hoe updates worden beoordeeld.
  7. Gebruik een echte template. Onze FRIA-generator en FRIA-template helpen structuur te brengen in plaats van te improviseren.

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.

Waar je nu het beste heen kunt

Heeft je team eerst de bredere juridische achtergrond nodig, begin dan met onze complete FRIA-gids. Heb je vooral een operationeel startpunt nodig, gebruik dan de FRIA-generator. Wil je het werk koppelen aan bestuurlijke praktijk, dan is de post over FRIA in de bestuurskamer van de publieke sector een nuttige brug.

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.

Op LearnWize:EU AI Act ComplianceProbeer het gratis

Van risicoclassificatie tot conformiteitsbeoordeling: leer het in 10 interactieve modules.

Met specialisatie voor de overheidssector.

Doe de gratis AI challenge