Het is zo ver: de AI Act is in werking getreden. Dit gebeurt echter geleidelijk. De verboden voor onacceptabel-risico-AI en de plicht tot AI-geletterdheid treden bijvoorbeeld al over zes maanden in werking, maar de regels voor hoogrisico-AI in hun volle omvang over twee jaar. Het zou echter onverstandig zijn om dit als "pás over twee jaar" te lezen, omdat twee jaar behoorlijk kort is om op te zetten wat de wet allemaal eist.
Drie risiconiveaus
Voordat we kunnen kijken wat een hoogrisico-AI allemaal voor eisen krijgt, krijgen we te maken met twee voorvragen: is dit systeem wel AI en vallen wij als aanbieder of gebruiker daarvan wel onder de AI Act. Deze hebben wij in januari behandeld. Heel kort: een AI-systeem leidt zelf beslisregels af om op basis van invoer de gevraagde uitvoer te realiseren. En een partij valt onder de AI Act als zij in Europa opereert, of uitvoer van AI buiten de EU haalt en in de EU gebruikt.
De AI Act kent drie risiconiveaus: verboden, hoogrisico en laagrisico. De meeste eisen gaan gelden voor AI-systemen die een hoog risico vormen voor de gezondheid, veiligheid, grondrechten of het milieu. Maar het is niet zo dat je zelf een risico-inschatting moet maken om te bepalen of je AI hoogrisico is. Het proces is formeel. In een eerste bijlage benoemt de AI Act gereguleerde producten. Als je AI daar een veiligheidscomponent van is, dan is je product per definitie hoogrisico. In een tweede bijlage worden use cases genoemd die de wetgever hoogrisico vindt. Als je die implementeert, dan ben je hoogrisico tenzij je in een van de vier beperkte uitzonderingen valt. En als je profiling doet in de zin van de AVG met behulp van AI, dan ben je ook hoogrisico. Andere smaken of uitkomsten zijn er niet.
Het beheersen van risico
De bulk van de regels uit de AI Act zijn voor hoogrisico-AI-systemen. Deze variëren van zeer specifiek naar zeer algemeen. Artikel 8 zet de toon: hoogrisico-AI moet aan de wet voldoen, “taking into account its intended purpose as well as the generally acknowledged state of the art on AI and AI related technologies.” Dit klinkt streng, maar biedt meteen ook ruimte: de wijze waarop de regels worden ingevuld en toegepast hangt dus af van je toepassing en de stand der techniek rondom jouw technische infrastructuur.
Hoe krijg je dat nu voor elkaar? Het begint met een risicomanagementsysteem. Algemeen gesproken is dat een bedrijfsproces waarbij risico’s worden geïdentificeerd, gemonitord en teruggedrongen met specifieke maatregelen. Dit is als middel dus niet uniek voor de AI Act, en een risico of compliance afdeling heeft dus de tools om hiermee aan de slag te gaan. Wel uniek is de focus van de AI Act: de term “risico’s” in deze wet slaat eerder op gezondheid, maatschappij of grondrechten dan op traditionele onderwerpen als fysieke veiligheid, defecten aan motoren of financiële verliezen.
De AI Act benoemt ook een aantal concrete maatregelen. Met de deur in huis valt artikel 10: wie met datasets werkt, moet zorgen dat deze “relevant, sufficiently representative, and to the best extent possible, free of errors and complete” is. De bal ligt bij de ontwikkelaar om de criteria hiervoor te formuleren én om aan te tonen dat die criteria leiden tot de gewenste hoge kwaliteit. Het gevaar van bias oftewel discriminatie ligt daarbij al snel op de loer. Een bijzonder aspect van de AI Act is dan ook dat men expliciet toestemming krijgt om bijzondere persoonsgegevens (zoals etnische afkomst of gezondheid) te gebruiken voor het bestrijden van bias bij de ontwikkeling van AI-modellen.
Naast een risicomanagementsysteem eist de AI Act ook het ontwikkelen en actueel houden van technische documentatie (artikel 11). Deze moet geschikt zijn om aan te tonen dat het systeem aan de AI Act voldoet. Dat gaat dus wel even een stukje verder dan enkel een gebruikershandleiding! Dit maakt artikel 11 een zware eis: wie niet met de documentatie kan aantonen AI Act compliant te zijn, is niet compliant. Gelukkig is er een bijlage (Annex IV) die alle verplichte elementen opsomt.
Als laatste algemene eis is er de verplichting om te loggen: het bijhouden van relevante events in het systeem tijdens het gebruik. Zulke logs zijn cruciaal bij het debuggen en opsporen van fouten.
Plichten voor partijen
In een eerdere blog heb ik de zogeheten ‘value chain’van partijen benoemd waar de AI Act op toeziet. Zie onderstaande afbeelding:
Het is de aanbieder die een AI-systeem op de markt brengt, en de gebruiksverantwoordelijke die er gebruik van maakt. Deze partijen kunnen overlappen, zoals bij een advocatenkantoor dat een eigen AI maakt om contracten samen te stellen of een autofabrikant die in-house autopilotsoftware ontwikkelt. In veel gevallen verschillen ze: een HR-afdeling neemt een tool in gebruik om cv’s mee te screenen of een inkoper laat ingekochte AI-leveringsvoorwaarden screenen.
De AI Act stelt dat gebruikende partijen (gebruiksverantwoordelijken) net zo goed aansprakelijk en verantwoordelijk zijn voor naleving van de AI Act. Hoogrisico-AI moet echter zo ontwikkeld en gedocumenteerd zijn dat gebruiksverantwoordelijken hiertoe ook daadwerkelijk in staat zijn. De wet (artikel 13) kent dan ook een fors aantal eisen voor de gebruikersdocumentatie (“instructions for use”). Zo moet het beoogd gebruik, de kwaliteit en voorzienbare risico’s expliciet beschreven worden en moet aangegeven worden welke vorm van menselijk toezicht aanbevolen wordt. Menselijk toezicht voor hoogrisico-AI is namelijk verplicht.
Er zijn vier niveaus van menselijk toezicht. De AI Act schrijft niet een bepaalde vorm voor, maar eist dat je motiveert en uitwerkt welke vorm geschikt is bij jouw toepassing. De aanbieder heeft daarbij de plicht om effectief toezicht mogelijk te maken.
- Human-in-the-Loop (HITL, Mens-in-de-lus): Dit type toezicht betekent dat een mens actief deelneemt aan het beslissingsproces van het AI-systeem. Elk besluit dat het systeem voorstelt, wordt door een mens geëvalueerd en goedgekeurd voordat het wordt uitgevoerd. Een voorbeeld is een AI-systeem voor gebouwtoegangsbeveiliging dat gezichtsherkenning gebruikt, vereist goedkeuring van een beveiligingsmedewerker voordat de deur wordt ontgrendeld.
- Human-on-the-Loop (HOTL, Mens-op-de-lus): Bij dit type is de menselijke rol meer passief. Het AI-systeem kan zelfstandig opereren en beslissingen nemen, maar een mens houdt toezicht op het systeem en kan ingrijpen wanneer nodig. In het voorbeeld zou de AI automatisch toegang geven op basis van badges, maar kan een beveiligingsmedewerker het systeem in real-time monitoren en ingrijpen indien nodig.
- Human-in-Command (HIC, Mens-in-commando): Dit concept benadrukt dat ongeacht de autonomie en capaciteiten van AI, de uiteindelijke controle en verantwoordelijkheid bij de mens liggen. De mens heeft de autoriteit om het AI-systeem te starten, te begeleiden en te stoppen. In het voorbeeld zou de AI de toegang autonoom regelen, maar ongebruikelijke activiteiten detecteren en melden bij de beveiligingsbeheerder, die vervolgens beslist over de te nemen actie.
- Human-out-of-the-Loop (Mens-buiten-de-lus): Hierbij is de rol van de mens minimaal of afwezig in het beslissingsproces van het AI-systeem, wat betekent dat het systeem volledig autonoom opereert. Deze laatste vorm hoort eigenlijk niet gebruikt te worden bij hoogrisico-AI.
Zowel de aanbieder als de gebruiksverantwoordelijke zijn verplicht een hoog niveau van cybersecurity en integriteit te waarborgen (artikel 15), en wel gedurende de gehele levensduur van het AI-systeem. Security is immers een continu proces. Dit komt je wellicht bekend voor uit de AVG (artikel 32) en dat klopt, want dit is een fundamenteel principe voor ICT-systemen in het algemeen.
Verplichtingen voor aanbieders
Specifiek voor de makers van AI-systemen (aanbieders) kent de AI Act nog een aantal extra eisen. Deze vatten we samen onder het kopje ‘certificering’, want het sluitstuk van dit proces is het mogen voeren van het bekende CE-logo bij je hoogrisico-AI. Hiertoe moeten aanbieders allereerst een kwaliteitsmanagementsysteem implementeren. Het doel hiervan is alle processen en stappen binnen de organisatie gestructureerd uit te werken, zodat de kwaliteit van de geleverde AI-systemen consistent en goed is. Een bekend voorbeeld van zo’n systeem is de ISO 9001 familie van certificeringen.
Een tweede verplichting is dat de aanbieder ervoor moet zorgen dat het AI-systeem transparant is.
De aanbieder is uiteindelijk altijd de partij die aan te spreken is bij schendingen van de AI Act. Ook als hij daarbij importeurs of distributeurs gebruikt. Deze hebben zelf de taak om na te gaan of het AI-systeem voldoet aan de AI Act, maar dat betekent niet dat de aanbieder vervolgens gevrijwaard zal blijven van aanspraken.
Verplichtingen voor gebruiksverantwoordelijke
De gebruiksverantwoordelijke heeft een bijzondere positie: hij zet de AI in, en dit zorgt er dus voor dat mensen schade kunnen ondervinden. Een gebruiksverantwoordelijke moet dan ook de fundamental rights impact assessment uitvoeren die soms onder de AI Act vereist is. De gebruiksverantwoordelijke is immers in de beste positie om na te gaan welke impact het systeem zal hebben bij gebruik. De gebruiksverantwoordelijke mag daarbij wel afgaan op wat de aanbieder aan informatie verstrekt.
Meer algemeen krijgen gebruiksverantwoordelijken de plicht om “passende technische en organisatorische maatregelen” te nemen om te zorgen dat het systeem op de juiste wijze wordt gebruikt. Dit omvat trainingen van gebruikers, en het alleen inzetten van personen voor menselijk toezicht die daartoe opgeleid zijn. Daarnaast moet de gebruiksverantwoordelijke ervoor zorgen dat de invoerdata waarmee het systeem werkt, voldoende relevant en representatief is voor het beoogde doel.
Aan de slag!
De nieuwe AI Act levert genoeg werk op, ook al is er nog twee jaar voordat alle regels afdwingbaar worden. Maar zoals gezegd, dat is niet “pas over twee jaar”, het is ál over twee jaar dat alles moet staan. En een goed werkend risicomanagementsysteem of kwaliteitssysteem heb je niet zomaar in een paar maanden opgericht. Het wordt dus tijd om aan de slag te gaan. Inventariseer processen, onderzoek tools en betrek collega’s die vanuit risicomanagement of kwaliteit mee willen denken. Een CAICO® AI compliance officer is natuurlijk ideaal. En vergeet de CISO niet, want dit heeft ook implicaties voor de cybersecurity in de organisatie.
