Wanneer menselijk toezicht van toepassing is en wat nu te doen

Menselijk toezicht op grond van de EU AI Act is als een specifieke wettelijke vereiste van toepassing op risicovolle AI-systemen. Er wordt niet tevredengesteld louter omdat een werknemer een resultaat kan zien of omdat een beleid bepaalt dat een persoon verantwoordelijk blijft. Aanbieders moeten systemen met een hoog risico zo ontwerpen dat natuurlijke personen er effectief toezicht op kunnen houden, terwijl aanbieders het toezicht moeten toewijzen aan mensen met de noodzakelijke competentie, opleiding, autoriteit en ondersteuning.

Voor een SaaS-team is de praktische volgorde: classificeer het systeem, identificeer of het bedrijf optreedt als aanbieder of als implementeerder, definieer wat de mens daadwerkelijk kan begrijpen en veranderen, test het interventietraject en bewaar bewijsmateriaal. Als het systeem geen hoog risico met zich meebrengt, kan menselijke beoordeling nog steeds een passend product, veiligheid, privacy of contractuele controle zijn – maar dat is iets anders dan beweren dat artikel 14 van toepassing is.

Waarom menselijk toezicht in de praktijk van belang is

De AI Act beschouwt toezicht als een manier om risico's voor de gezondheid, veiligheid en fundamentele rechten te voorkomen of te minimaliseren die zelfs blijven bestaan nadat andere controles zijn toegepast. Artikel 14 zegt dat de maatregelen evenredig moeten zijn aan de risico's, de autonomie en de gebruikscontext van het systeem. Het verwacht ook dat de toegewezen persoon, waar nodig, de beperkingen kan begrijpen, de werking kan monitoren, automatiseringsvooroordelen kan herkennen, outputs kan interpreteren, een output kan negeren of omkeren, en het systeem veilig kan stoppen.

Dat maakt toezicht tot een operationele mogelijkheid, en niet tot een ceremoniële goedkeuring. Een reviewer die geen tijd, systeeminformatie, toegang of autoriteit heeft, kan geen zinvol toezicht bieden. Ook kan iemand niet effectief ingrijpen als het product een aanbeveling als definitief voorstelt, onzekerheid verbergt of geen bruikbare oplossing biedt.

Dit hangt nauw samen met de AI-governanceverwachtingen voor SaaS-leveranciers. Kopers vragen zich steeds vaker niet alleen af ​​of er sprake is van een mens, maar ook waar er wordt ingegrepen en welk bewijsmateriaal aantoont dat dit werkt.

Wanneer de AI Act-vereiste van toepassing is

Begin met classificatie, niet met een overzichtscontrolelijst. Volgens artikel 6 kan een systeem via twee hoofdroutes een hoog risico opleveren:

1. Het is een product, of een veiligheidscomponent van een product, dat onder de gespecificeerde EU-wetgeving inzake productveiligheid valt en onderworpen is aan conformiteitsbeoordeling door derden.
2. Het beoogde doel ervan valt binnen een gebruiksscenario met een hoog risico in bijlage III, onderworpen aan het filter van artikel 6, lid 3 en de uitzonderingen daarop.

Bijlage III heeft betrekking op gedefinieerde toepassingen op gebieden als biometrie, kritieke infrastructuur, onderwijs, werkgelegenheid, toegang tot essentiële diensten, wetshandhaving, migratie en rechtsbedeling. Het ‘door AI aangedreven’ zijn, het verwerken van persoonlijke gegevens of het beïnvloeden van een gewone zakelijke workflow betekent niet automatisch dat een systeem een hoog risico inhoudt op grond van artikel 6.

Voor sommige systemen uit bijlage III biedt artikel 6, lid 3, een mogelijke uitweg uit de classificatie met hoog risico wanneer het systeem geen significant risico op schade met zich meebrengt en aan de genoemde voorwaarden voldoet, bijvoorbeeld wanneer het een beperkte procedurele of voorbereidende taak vervult. Het profileren van natuurlijke personen binnen een bijlage III-gebruiksscenario blijft een hoog risico met zich meebrengen. Een aanbieder die op het filter vertrouwt, moet die beoordeling documenteren.

Classificatie hangt sterk af van het beoogde doel en de feitelijke rol. Een SaaS-bedrijf kan de aanbieder zijn als het een systeem ontwikkelt of laat ontwikkelen en dit onder eigen naam op de markt brengt of in gebruik neemt. Het kan een implementeerder zijn als het onder zijn gezag het AI-systeem van een andere aanbieder gebruikt. Een bedrijf kan ook leveranciersverplichtingen creëren door een systeem met een hoog risico substantieel aan te passen of door het beoogde doel ervan zodanig te veranderen dat het systeem een ​​hoog risico met zich meebrengt. Teams moeten de huidige overgangsregels bevestigen voordat ze een toekomstige verplichting als reeds van toepassing beschouwen.

Lees het praktisch overzicht van de EU AI-wet voor SaaS-aanbieders naast de classificatiebeoordeling.

Wanneer artikel 14 niet van toepassing is

Artikel 14 is geen universele regel voor elke chatbot, samenvatting, aanbevelingsfunctie, fraudesignaal of interne copiloot. Als een systeem buiten de reikwijdte van de AI-wet valt, geen AI-systeem in de zin van de wet is, of niet als hoog risico is geclassificeerd, is de risicosysteemvereiste van artikel 14 daarop niet van toepassing.

Dat betekent niet dat er ‘geen menselijke beoordeling nodig is’. Andere plichten kunnen voortvloeien uit gegevensbeschermings-, consumenten-, werkgelegenheids-, sectorspecifieke, veiligheids- of contractuele regels. Uit een risicobeoordeling kan ook blijken dat menselijke goedkeuring de meest evenredige controle is, zelfs zonder een specifiek wettelijk mandaat.

Gebruik nauwkeurig taalgebruik in documenten en klantantwoorden:

• Wettelijke vereiste: “Het systeem brengt een hoog risico met zich mee en deze maatregelen implementeren de artikelen 14 en 26.”
• Risicobeheersing: “Het systeem is momenteel niet geclassificeerd als een hoog risico, maar menselijke beoordeling is vereist door ons interne risicobeleid.”
• Open vraag: "Classificatie hangt af van het uiteindelijke beoogde doel en de implementatiecontext; de lancering wordt geblokkeerd totdat die beoordeling is goedgekeurd."

Dit onderscheid voorkomt dat teams de compliance overdrijven en maakt latere wijzigingen eenvoudiger te beheren.

Verantwoordelijkheden van provider en implementeerder

Providers en implementeerders hebben onderling verbonden maar verschillend werk.

Providers: ontwerp toezicht in het systeem

Een aanbieder moet de risicobeoordeling vertalen naar bruikbare technische en procedurele maatregelen. Afhankelijk van de gebruikssituatie kan dit het volgende omvatten:

• het tonen van relevant vertrouwen, beperkingen en inputcontext;
• het zichtbaar maken van afwijkingen en onverwachte prestaties;
• voorkomen dat de interface blinde acceptatie aanmoedigt;
• het toestaan ​​van bevoegde personen om uitgangen te negeren, te onderdrukken, om te keren of te onderbreken;
• het definiëren welke toezichtmaatregelen de uitvoerder moet implementeren; en
• het duidelijk uitleggen van die maatregelen in de gebruiksaanwijzing.

Het ontwerp moet overeenkomen met de te verwachten werkomstandigheden. Een overschrijving die verborgen zit achter de workflow van een beheerder kan nutteloos zijn als een eerstelijnsreviewer onmiddellijk moet handelen.

Uitvoerders: maak toezicht operationeel

Artikel 26 vereist dat exploitanten van systemen met een hoog risico het toezicht toewijzen aan natuurlijke personen met de noodzakelijke competentie, opleiding, autoriteit en ondersteuning. Implementeerders moeten het systeem gebruiken volgens de instructies ervan, toezicht houden op de werking ervan, handelen op basis van geïdentificeerde risico's of ernstige incidenten, en automatisch gegenereerde logboeken gedurende een passende periode van ten minste zes maanden onder hun controle houden, tenzij andere toepasselijke wetgeving anders bepaalt.

Operationeel betekent dit het kiezen van benoemde rollen, het beschermen van de beoordelingstijd, het controleren van de toegang, het definiëren van escalaties en het controleren of de instructies van de provider passen bij de echte implementatie. Een werknemer kan niet aansprakelijk worden gesteld voor een overschrijving waartoe hij/zij niet bevoegd is.

Een praktische workflow voor menselijk toezicht

1. Schrijf een scoped classificatierecord

Registreer het systeem, het beoogde doel, de gebruikers, de betrokken mensen, de input, de output, de impact op de besluitvorming, de rollen van de aanbieder/opdrachtgever en de beschouwde Artikel 6-route. Koppel de conclusie aan de productversie en de implementatiecontext. Beoordeel het opnieuw als een van beide verandert.

2. Breng beslissingen en faalwijzen in kaart

Identificeer waar de AI-output een persoon, veiligheid, toegang, prioritering of een gereguleerd proces kan beïnvloeden. Beschrijf voor elk punt realistische fouten: een valse overeenkomst, gemiste uitzondering, vertekende rangschikking, misleidende samenvatting, onveilige aanbeveling of prestatieafwijking.

3. Definieer de actie van de mens, niet alleen zijn aanwezigheid

Specificeer voor elke materiële beslissing:

• welke informatie de reviewer ziet;
• wat zij onafhankelijk moeten verifiëren;
• wanneer ze moeten afwijzen of escaleren;
• of ze het resultaat kunnen pauzeren, overschrijven of terugdraaien;
• hoe snel ze moeten handelen; en
• wie de uiteindelijke bevoegdheid heeft.

Vermijd vage controles zoals ‘een manager beoordeelt wanneer dat nodig is’. Een trigger en beslissingsregel maken de controle toetsbaar.

4. Train voor de eigenlijke taak

De training moet betrekking hebben op het beoogde doel van het systeem, de bekende beperkingen, relevante signalen, automatiseringsvooroordelen, verboden gebruik, interventie-instrumenten, het bijhouden van gegevens en escalatie. Bevestig de competentie door middel van scenario's, niet alleen door aanwezigheid. Dit vormt een aanvulling op de bredere vragen die teams moeten stellen voordat ze intern nieuwe AI-tools adopteren.

5. Test het volledige pad

Voer realistische oefeningen uit. Kan de recensent een slechte output ontdekken? Hebben ze voldoende context? Werkt de overschrijving? Zorgt het stoppen van het systeem ervoor dat het in een veilige staat blijft? Wordt de gebeurtenis geregistreerd? Bereikt de escalatie iemand die actie kan ondernemen?

Registreer defecten en test opnieuw na reparaties. Een screenshot van een goedkeuringsscherm bewijst veel minder dan een voltooid scenario met verwachte en waargenomen resultaten.

6. Monitor en verbeter

Houd overschrijvingen, terugboekingen, escalaties, klachten, gemiste detecties, meningsverschillen tussen recensenten en abnormale prestaties bij. Trends kunnen een zwakke training, een onbruikbare interface, gewijzigde invoer of een systeem dat buiten het goedgekeurde doel functioneert, aan het licht brengen. Definieer drempels die aanleiding geven tot onderzoek, opschorting of herbeoordeling.

Veelgemaakte fouten

• Classificatie op productlabel. Een kenmerknaam bepaalt niet of het beoogde gebruik een hoog risico met zich meebrengt.
• Het gebruik van “human in the loop” als volledige controle. Aanwezigheid zonder informatie, tijd of autoriteit is geen effectief toezicht.
• Beoordelen na de consequentie is onomkeerbaar. Het interventiepunt moet plaatsvinden terwijl de persoon de uitkomst nog kan veranderen.
• Dezelfde output zichzelf laten valideren. Onafhankelijke verificatie vereist aanvullend bewijs, niet een tweede lezing van de uitleg van de AI.
• Het negeren van vooringenomenheid op het gebied van automatisering. Herhaaldelijk nauwkeurige resultaten kunnen ervoor zorgen dat reviewers de uitzonderlijke fout minder snel zullen betwisten.
• Het eigendom bij “het bedrijf” laten. Noem een ​​verantwoordelijke rol en een operationele back-up.
• Geen bewijsmateriaal bijgehouden. Beleid alleen laat niet zien dat reviewers zijn getraind, overschrijvingen hebben gewerkt of problemen zijn geëscaleerd.

Voorbeeld: AI-ondersteunde screening van kandidaten

Stel dat een SaaS-leverancier software aanbiedt die sollicitanten voor een werkgever rangschikt. Werkgerelateerd AI-gebruik vermeld in bijlage III kan een hoog risico met zich meebrengen, dus de aanbieder moet de artikel 6-beoordeling invullen en documenteren in plaats van ervan uit te gaan dat een recruiter die op ‘goedkeuren’ klikt het probleem oplost.

Zinvol toezicht kan van de recruiter vereisen dat hij de factoren ziet die relevant zijn voor de aanbeveling, broninformatie controleert, ontbrekende of misleidende gegevens identificeert, de rangschikking negeert, een kandidaat terugplaatst en vermoedelijke systematische vooringenomenheid escaleert. De werkgever zou als uitvoerder getrainde mensen met autoriteit aanwijzen en het systeem monitoren volgens de instructies.

Daarentegen valt een interne tool die een door een recruiter geschreven e-mail opnieuw formatteert zonder kandidaten te rangschikken of een arbeidsbeslissing te beïnvloeden mogelijk niet binnen deze risicovolle gebruikssituatie. Het team mag nog steeds gevoelige input verbieden en menselijke goedkeuring vereisen voordat het kan verzenden, maar het moet dat documenteren als een interne controle in plaats van het automatisch te omschrijven als naleving van artikel 14.

Veelgestelde vragen

Wat is het praktische doel van menselijk toezicht?

Het doel ervan is om competente mensen inzicht te geven, toezicht te houden en in te grijpen, zodat resterende risico's voor de gezondheid, veiligheid of fundamentele rechten kunnen worden voorkomen of verminderd. De workflow moet hen echte informatie, tijd, hulpmiddelen en autoriteit geven.

Wanneer is menselijk toezicht van toepassing op SaaS-teams?

De specifieke AI Act-taken zijn van toepassing wanneer het team een ​​AI-systeem met een hoog risico levert of inzet. Andere AI-systemen hebben mogelijk nog steeds menselijke beoordeling nodig vanwege een andere wet, contract, risicobeoordeling of intern beleid.

Is een definitieve menselijke goedkeuring voldoende?

Niet automatisch. Goedkeuring heeft alleen betekenis als de beoordelaar de relevante beperkingen kan begrijpen, problemen kan opsporen, de uitkomst kan betwisten en het resultaat kan veranderen of stoppen voordat er schade ontstaat.

Wat moeten teams eerst documenteren?

Begin met het classificatierecord en het beoogde doel. Documenteer vervolgens de verantwoordelijke mensen, bekijk triggers, getoonde informatie, toegestane interventies, escalatiepad, training, testresultaten en operationeel bewijs.

Moet elke AI-beslissing door twee mensen worden gecontroleerd?

Nee. Artikel 14 bevat een specifieke tweepersoonsverificatieregel voor bepaalde biometrische identificatiesystemen op afstand, met gedefinieerde uitzonderingen. Het is geen algemene regel voor alle AI-systemen met een hoog risico.

Wat nu te doen

Classificeer de use case voordat je belooft dat ‘menselijk toezicht’ het probleem oplost. Als het systeem een ​​hoog risico met zich meebrengt, koppel dan de technische maatregelen van de provider aan de echte mensen, machtigingen en procedures van de exploitant. Test vervolgens het pad en bewaar het bewijs dat een mens problemen kan herkennen en op tijd kan handelen.

Dat is het verschil tussen een persoon die dichtbij het systeem staat en effectief menselijk toezicht.

Bronnen

• Verordening (EU) 2024/1689 (Wet op de kunstmatige intelligentie)
• Artikel 6: Classificatieregels voor AI-systemen met een hoog risico
• Artikel 14: Menselijk toezicht
• Artikel 26: Verplichtingen van exploitanten van AI-systemen met een hoog risico