Over Open Loop en policy prototyping

Het Open Loop-project wordt omschreven als een "wereldwijd programma dat beleidsmakers en technologiebedrijven met elkaar in contact brengt om doeltreffend en op feiten gebaseerd beleid rond AI en andere nieuwe technologieën te helpen ontwikkelen". Het programma wil beleidsmakers, regeringen, technologiebedrijven, academici en vertegenwoordigers van het maatschappelijk middenveld bij het proces betrekken. Daarbij is het de bedoeling om "beleidsprototypes te creëren en nieuwe en verschillende manieren van wet- en regelgeving te testen, zodat de kwaliteit van wetgevingsprocessen op het gebied van technologiebeleid wordt verbeterd".

De interessantste term in dit verband is ‘policy prototyping’. Deze term verwijst naar een nieuwe manier van regelgeving, vergelijkbaar met product- of bèta-testen of een vorm van omgekeerde regulatory sandboxing. In tegenstelling tot de traditionele democratische beleidsvorming, waarbij allerlei belanghebbenden regels "slechts" bespreken voordat ze in werking treden, omvat policy prototyping een fase waarin ontwerp-/prototyperegels in de praktijk worden getest vooraleer zij worden gefinaliseerd en afgekondigd. Meer bepaald bestaat het proces van policy prototyping uit de volgende fasen:

Een dergelijk proefproces moet beleidsmakers in staat stellen de gevolgen, sterke punten en beperkingen van het voorgestelde beleid in kaart te brengen en moet leiden tot een meer doeltreffende en empirisch onderbouwde beleidsvorming, zodat de maatschappelijke kosten van "slecht beleid" kunnen worden vermeden. Als zodanig, is het een op gebruikersgerichte vorm van beleidsvoering of legal design denken toegepast op het wetgevingsproces, wat ook expliciet wordt bevestigd in het rapport.

Het beleidsprototype: een GBEB-wet en bijhorende handleiding

Het eerste beleidsprototype-experiment dat werd uitgevoerd door het Open Loop-programma betreft een prototype GBEB-kader.

Dit kader bestaat uit een prototype wet en een bijhorende handleiding (‘playbook’) die voorlichting omtrent naleving bevat en gebruikers helpt om zelf hun geautomatiseerde besluitvormingssystemen (“GB-systemen”) te beoordelen. Tien startende bedrijven waren betrokken bij het experiment en simuleerden de uitvoering van een GBEB met betrekking tot hun AI-gebaseerde producten of diensten. Vervolgens gaven zij feedback op de prototypewet en de handleiding met betrekking tot drie criteria: beleidsbegrip, beleidsdoeltreffendheid en beleidskosten. Deze feedback leidde tot negen beleidsaanbevelingen die in acht zouden moeten worden genomen wanneer er risicobeoordelingen voor AI zouden worden opgesteld.

Het algemene beleidsdoel van het prototype GBEB is om ontwikkelaars en gebruikers van GB-systemen ertoe aan te zetten de mogelijke risico’s van hun toepassingen te identificeren en te beperken en ervoor te zorgen dat er doeltreffende risicobeoordelingen worden uitgevoerd. Meer bepaald moet een GBEB de risico’s die het gebruik van een GB-systeem kan inhouden voor de rechten en vrijheden van de betrokkenen identificeren, het belang van dergelijke risico’s bepalen, ertoe leiden dat verzachtende maatregelen getroffen worden en de doeltreffendheid daarvan en het resterende risico op passende wijze beoordelen (zie afbeelding).

Om deze doelstellingen te bereiken, voorziet de prototypewet vijf artikels, drie daarvan bepalen het materiële bereik (artikels 1-3) en twee daarvan bevatten de eigenlijke verplichtingen.

Artikel 4 verplicht ‘gebruikers’ van AI-systemen om de risico’s en de impact op fundamentele rechten van een voorzien GB-systeem te beoordelen voorafgaand aan de ingebruikname.

Net als de AVG vereist artikel 4, lid 2, van de prototypewet een formele beoordeling in het geval van een waarschijnlijk hoog risico, met drie in de literatuur bekende voorbeelden: discriminatie, mogelijk verlies van controle of zeggenschap (manipulatie) of grootschalige profilering die gevolgen kan hebben voor bepaalde gemeenschappen of de samenleving. Indien het risico na het nemen van maatregelen hoog blijft, moet "de toezichthoudende autoriteit" worden "geraadpleegd". Met andere woorden, een GBEB (Geautomatiseerde Besluitvorming Effect Beoordeling) is een GEB (Gegevensbeschermingseffectbeoordeling) met een iets andere focus. Het is niet duidelijk of dergelijk raadpleging de goedkeuring van de toezichthoudende autoriteit vervolgens nodig maakt, noch welke toezichthoudende autoriteit wordt bedoeld.

Artikel 5 van de prototypewet bepaalt dat ontwikkelaars en gebruikers moeten zorgen voor adequate en doeltreffende interne beheersstructuren om een degelijk toezicht te waarborgen op hun rol in het beheer van hun GB-systemen, waarbij ook het hoogste management moet betrokken zijn. Zij moeten verder ook zorgen voor een betrouwbaar systeem van risicobeheer en interne controles om eventuele risico's op te sporen en aan te pakken. Al deze inspanningen moeten worden gedocumenteerd.

Zoals kan worden vastgesteld, en vergelijkbaar met o.a. de AVG en de NIS-richtlijn, zijn de vereisten van de prototypewet zeer algemeen en missen ze operationele aanwijzingen. Dit wordt volledig overgelaten aan de handleiding.

Enkele opmerkingen bij het policy prototyping experiment en het GBEB-kader

Het werkelijke doel van dit eerste experiment oogt echter ambigu.

Enerzijds wordt het voorgesteld als een ‘policy prototyping experiment’ met als doel om te onderzoeken of ‘policy prototyping’ nuttig kan zijn in het domein van AI door middel van het testen van een fictieve prototypewet rond GBEBs. Dit volgt uit de titel van het rapport (‘The AI Impact Assessment: A Policy Prototyping Experiment’) en wordt meerdere malen benadrukt doorheen het document, bijvoorbeeld wanneer gesteld wordt dat de voorgestelde prototypewet ‘louter geschreven is met als doel om te kunnen wordt getest door een beperkte groep van rechtsonderhorigen’ (p.17).

Anderzijds zijn de conclusies en aanbevelingen die volgen uit dit experiment niet strikt beperkt tot het nut van het policy prototyping experiment. Zij geven immers expliciet aan hoe wetgevers AI-risicobeoordelingen (niet) zouden moeten reguleren. Het is duidelijk dat de initiatiefnemers van het experiment goed hebben nagedacht over de inhoud van hun "test-prototype-wet" en de resultaten van het experiment gebruiken als een instrument om beleidsmakers in de richting van hun prototypewet te duwen.

Inhoudelijk is het opmerkelijk dat de prototypewet een onderscheid maakt tussen GB-systemen met een "hoog risico" en "laag risico" (overweging 1 en artikel 4), terwijl het Witboek AI van de EU net bekritiseerd wordt omdat het een dergelijke binaire en prescriptieve benadering hanteert. Belangrijker is dat, waar het Witboek voorstelt om objectieve criteria (bv. sectoren) te gebruiken om AI-toepassingen met een hoog risico te onderscheiden van toepassingen met een laag risico, de prototypewet van dit onderscheid een subjectief onderscheid maakt. Zo wordt het in wezen aan de gebruiker overgelaten om daarover te beslissen.

De verantwoordelijkheid van de gebruiker om de risicobeoordeling uit te voeren en risicobeperkende maatregelen te treffen, is een ander interessant kenmerk van de prototypewet. In de praktijk zullen gebruikers immers vaak niet over de middelen beschikken om het GB-systeem technisch te wijzigen, in tegenstelling tot de ontwikkelaars. Dit kan worden verholpen door een verplichting voor ontwikkelaars op te nemen om samen te werken met gebruikers bij de risicobeoordeling en bijstand te verlenen bij de implementatie van risicobeperkende maatregelen, óf door alle verplichtingen uit te breiden tot ontwikkelaars en ervoor te zorgen dat GB-ontwikkelaars hun GB-systemen moeten evalueren vooraleer ze op de markt worden gebracht.

Daarenboven, en in tegenstelling tot bv. de AVG, de NIS richtlijn en het DSA voorstel, wordt goed beheer nauwelijks ondersteund door de verplichting om rekenschap af te leggen. De noodzaak om periodiek een her-evaluatie uit te voeren – iets wat voortvloeit uit het adaptieve karakter van AI-systemen – wordt enkel vermeld in overweging 17, en dus niet als een verplichting. Bovendien wordt in artikel 5 weliswaar bepaald dat interne maatregelen moeten worden genomen en dat moet kunnen worden aangetoond dat zij toereikend zijn, maar wordt er geen woord gerept over de kennisgeving of melding van incidenten.

Aangezien het om een prototype gaat, hoeven de inhoudelijke zwakke punten van het prototype geen afbreuk te doen aan de waarde ervan als beleidsexperiment. Een meer diepgaande analyse van policy prototyping als proces volgt in deel 2.