Wie tekent voor de foutmarge van een overheidsalgoritme?

In het Algoritmeregister staat Public Eye, een inmiddels buiten gebruik gesteld systeem waarmee de gemeente Amsterdam met camerabeelden mensen telde. Onder het kopje Prestatie staat dat het algoritme ongeveer 70 procent nauwkeurig moest zijn om er relevante inzichten uit te halen voor het reguleren van het verkeer en dat het in de praktijk ongeveer 90 procent haalde. Daarna volgt één zin: 'Dit leiden we af uit de trainingsbeelden.' Verderop staat dat kwaliteit en nauwkeurigheid periodiek werden geëvalueerd aan de hand van diezelfde trainingsdata, door een klein aantal medewerkers dat beoordeelde of het algoritme mensen terecht als mensen herkende.

Het systeem is niet meer in gebruik. De vermelding wel: het Algoritmekader voert Public Eye vandaag op als voorbeeld van hoe je de nauwkeurigheid van een algoritme evalueert.

Twee dingen vallen op. Een prestatie die is vastgesteld op het materiaal waarmee een model heeft leren kijken, zegt onvoldoende over hoe datzelfde model presteert op werkelijk ongeziene beelden. En nergens staat wie heeft bepaald dat 70 procent genoeg is. Het getal staat er. De afweging niet, en de naam al helemaal niet.

Die vraag reikt verder dan Amsterdam.

Ik val daarover niet omdat ik denk dat Amsterdam slordig werkt. Ik val erover omdat ik al maanden met weinig anders bezig ben. Voor mijn masteronderzoek bouw ik modellen die per dag voorspellen waar in Zweden een nieuwe bosbrand ontstaat. Het grootste deel van dit werk zit niet in het model maar in de evaluatie: wanneer mag je zeggen dat het ding iets waard is? Wie die vraag een half jaar met zich meedraagt, komt in publieke AI-dossiers steeds dezelfde drie punten tegen.

1. Een percentage is een uitspraak over een situatie, niet over een systeem

Het Algoritmekader noemt accuracy, precision, recall, F1 en de ROC-curve als manieren om prestaties te beoordelen. Nuttige maten, die verschillende dingen meteen: sommige gelden bij één gekozen drempel, andere vatten het gedrag over alle drempels samen. Maar geen van deze maten vertelt of een modelscore van 0,20 ook werkelijk betekent dat ongeveer één op de vijf van die gevallen raak is.

Dat verschil heet kalibratie. Een model kan uitstekend rangschikken en tegelijk geen betrouwbare kansschattingen produceren. Zolang je zo'n score alleen gebruikt om een werklijst te sorteren, kun je daarmee leven. Zodra je hem gebruikt om te bepalen wie nader onderzocht wordt, kun je dat niet meer — dan is de vraag wat die score betekent geen technisch detail maar de kern van de verantwoording. In de publiek doorzoekbare tekst van het kader kwam ik kalibratie niet expliciet tegen.

Daar komt bij dat één van die maten misleidend wordt zodra de gezochte gevallen zeldzaam zijn. Als één op de duizend dossiers werkelijk problematisch is, haalt een model dat altijd 'nee' zegt moeiteloos 99,9 procent accuraatheid.

2. Prestaties reizen niet mee

In mijn onderzoek ontwikkel ik de modellen op Zweedse gegevens en toets ik ze daarna in de Valenciaanse regio, zonder ze opnieuw te trainen of bij te stellen. De software blijft identiek. Het klimaat, het landschap en de frequentie waarmee brand ontstaat niet.

Of het model die overstap overleeft, weet ik nog niet — dat is nu juist waarom je het toetst in plaats van aanneemt. En precies daarom mag die stap bij publieke systemen niet worden overgeslagen. Een model dat bij de ene uitvoeringsorganisatie netjes is gevalideerd, kan bij een volgende dezelfde code en documentatie meekrijgen, maar wordt daar geconfronteerd met een andere populatie en andere registraties.

In registraties zit de tweede helft van dit probleem. Het Algoritmekader stelt de vraag zelf scherp: beschrijft de data wel het fenomeen dat je wilt onderzoeken? Een model dat leert van eerdere meldingen, controles of handhavingsdossiers, leert in de eerste plaats het patroon van díé registraties. Een wijk met meer geregistreerde incidenten kan meer incidenten kennen, of intensiever gecontroleerd zijn. Het model kan die twee niet uit elkaar houden. De bestuurder die op de uitkomst afgaat, moet dat wel.

Wie de drempel verschuift, kiest hoeveel mensen ten onrechte worden geselecteerd én hoeveel werkelijke gevallen worden gemist. Dat is geen neutrale software-instelling.

3. De drempel is beleid

Stel dat een risicomodel duizend dossiers beoordeelt. Verlaag de drempel en je vindt meer werkelijke gevallen, maar je selecteert ook meer mensen ten onrechte. Verhoog hem en dat beeld keert om. Welke stand de goede is, valt niet uit de data af te leiden — niet omdat de statistiek tekortschiet, maar omdat de vraag geen statistische vraag is.

Bij een model dat meldingen over losliggende stoeptegels sorteert, kost een misser vooral een verloren inspectierit. Bij een frauderisicomodel betekent dezelfde misser dat iemand een brief krijgt die hij niet had moeten krijgen. Het model kent dat verschil niet. Het kan alleen laten zien hoeveel fouten van elk type er bij welke drempel ontstaan.

Het Algoritmekader vraagt daarom expliciet om te bepalen welke foutmarge acceptabel is, met de bijbehorende vraag welke fouten erger zijn om te maken. Dat is precies de juiste vraag. Alleen: een kader kan eisen dát iemand haar beantwoordt, het kan het antwoord niet geven. Juist in een keten van leverancier, aanbesteding en uitvoering moet daarom vaststaan wie die afweging maakt. Het kader dringt daar ook op aan: taken en verantwoordelijkheden horen expliciet te worden belegd, bijvoorbeeld in een RACI-matrix. Maar welke rol welke taak krijgt, laat het aan de organisatie zelf. Op de kaderpagina zijn aan die maatregel de rollen ontwikkelaar en projectleider gekoppeld; een afzonderlijke bestuurlijke rol staat er niet bij.

Twee dingen die maandag anders kunnen

Er hoeft geen nieuw toetsingskader bij. Twee gewoonten volstaan.

Leg vóór ingebruikname vast welk bewijs volstaat om het systeem te accepteren. Niet één totaalscore, maar: op welke gegevens is gemeten, welke fouttypen zijn onderscheiden, wat betekenen de uitkomsten, en onder welke omstandigheden moet die prestatie gelden? Verhuist het model later naar een andere regio, doelgroep of uitvoerder, dan is dat geen implementatiebesluit, maar aanleiding voor nieuw bewijs.

Maak daarnaast van de foutafweging een besluit met een eigenaar. Niet omdat degene die tekent een ROC-curve moet kunnen lezen, maar omdat hij verantwoordelijk is voor wat er gebeurt met de mensen die in de verkeerde categorie belanden. Leg vast welke verhouding tussen fouten is geaccepteerd, op grond van welke cijfers, door wie, en wanneer die keuze opnieuw tegen het licht gaat.

Dan wordt ook zo'n vermelding in het Algoritmeregister bruikbaar. Niet 90 procent nauwkeurig, punt — maar: gemeten waarop, met welke fouten, en wie dat voldoende vond.

Compliance bewijst geen betrouwbaarheid. Betrouwbaarheid bewijst geen aanvaardbaarheid. Daartussen staat een besluit. En onder dat besluit hoort een naam.