Menselijke controle bij AI wordt een ontwerpeis, geen handtekening

U moet aantonen dat personen die AI-besluiten toetsen, het systeem werkelijk begrijpen, afwijkingen herkennen, outputs kunnen negeren en noodstop kunnen activeren — en dat alles gelogd is.

De aanleiding is een analyse van 25 augustus 2026 over menselijke controle bij AI-systemen, die stelt dat artikel 14 van de EU AI Act menselijke controle van een geruststellende formulering naar toetsbare technische en organisatorische eisen verschuift. Het voorbeeld is de regelgeving rond AI in Medicare Advantage prior-authorisation in de zorg, waar AI mag ondersteunen maar beslissingen de unieke klinische context van de arts moeten weerspiegelen en niet op generieke datasets mogen leunen. In onze beoordeling betekent dit dat menselijke controle niet langer een rol aan het einde van een proces mag zijn, maar een expliciet ontworpen architectuurlaag die vanaf de systeembouw moet worden ingebouwd.

Wat verstaat artikel 14 onder menselijke controle?

Menselijke controle is niet langer een handtekening of een goedkeuringsvak. Artikel 14 verplicht dat aangewezen personen het systeem effectief kunnen overzien: afwijkingen herkennen, outputs negeren of override'n, en de werking veilig onderbreken. Bij bepaalde toepassingen — met name biometrische — schrijft artikel 14 bovendien een twee-personen-verificatieplicht voor. Dit betekent dat menselijke verificatie als voorwaarde voor besluiten wordt verankerd, niet als nacheck.

De verschuiving is fundamenteel. Waar "human in the loop" vroeger kon betekenen dat een mens ergens in het proces betrokken was, eist artikel 14 nu dat die betrokkenheid werkelijk effectief is: de persoon moet het systeem begrijpen, moet kunnen zien wat het doet, moet kunnen ingrijpen en moet kunnen stoppen.

Welke technische capaciteiten moet het systeem hebben?

De praktische vertaling van artikel 14 draait om vier kernfuncties: understand, detect, override en stop. Dit betekent concreet:

• Override-API met rol-gebaseerde autorisatie — het systeem moet override technisch mogelijk maken en registreren wie wat wanneer override't.
• Verplichte override-redenen — elke override moet een reden hebben die wordt gelogd.
• Noodstop op twee niveaus — zowel op besluit- als op systeemniveau moet een mens kunnen stoppen.
• Tamper-evidente logging — alle menselijke interventies moeten als onveranderbare sporen worden vastgelegd.
• Interpretatie-ondersteuning — het systeem moet de redenering achter outputs inzichtelijk maken zodat toezichthouders afwijkingen kunnen herkennen.

Zonder deze functies kan menselijke controle niet werkelijk plaatsvinden. Een systeem dat override niet toestaat, of waarvan de logs achteraf kunnen worden gewist, voldoet niet aan artikel 14.

Wie draagt verantwoordelijkheid voor menselijke controle?

De verantwoordelijkheid is verdeeld over de hele keten. De provider van het systeem moet de technische mogelijkheden voor oversight inbouwen. De organisatie die het systeem inzet — de deployer — moet per systeem aangewezen personen aanstellen met aantoonbare competentie, training, autoriteit en ondersteuning. Die personen moeten daadwerkelijk toezicht uitoefenen, en de organisatie moet kunnen aantonen dat dit gebeurt: via logs, override-records, escalaties.

Dit betekent dat u niet kunt zeggen dat menselijke controle "in het systeem zit". U moet kunnen aantonen dat uw organisatie personen heeft aangewezen, hen heeft getraind, hen de autoriteit heeft gegeven om in te grijpen, en dat zij dit daadwerkelijk doen.

Hoe bepaal je per workflow wat menselijke controle vereist?

Niet elke AI-output vereist voorafgaande menselijke goedkeuring. Het gaat erom dat u per workflow expliciet bepaalt welke acties een systeem autonoom mag uitvoeren, wanneer een waarschuwing volstaat en wanneer een mens vooraf moet goedkeuren of moet kunnen blokkeren. Dit hangt af van:

1. Autoriteit van de actie — wie mag deze beslissing nemen en onder welke voorwaarden.
2. Consequentie van de actie — wat gebeurt er als het fout gaat.
3. Omkeerbaarheid — kun je de actie terugdraaien.
4. Datagevoeligheid — welke gegevens zijn betrokken.
5. Vertrouwensniveau van het systeem — hoe zeker is het systeem van zijn output.
6. Downstream-impact — wat zijn de gevolgen verder in het proces.

Acties die op meerdere van deze dimensies hoog scoren, vereisen voorafgaande menselijke goedkeuring of blokkade. Dit is geen bureaucratie; het is een ontwerp-vraagstuk.

Wat kan tooling doen en wat niet?

Systemen kunnen helpen door per workflow zichtbaar te maken welke controlepunten bestaan, wie daarvoor verantwoordelijk is, welke training daarbij hoort en hoe overrides en noodstops zijn gelogd. Zij kunnen ook waarschuwen wanneer een override niet is geregistreerd of wanneer een persoon zonder bevoegdheid ingreep. Maar het professionele eindoordeel — of een override terecht was, of een noodstop nodig was, of een systeem voldoende begrijpelijk is — blijft altijd bij u. Tooling kan transparantie geven; zij kan verantwoordelijkheid niet overnemen.