Art. 14 EU AI Act: hoog-risico AI ontwerpen voor menselijk toezicht

Bijgewerkt: juni 2026

Dit is een expliciete providerproviderThe actor who develops an AI system (or has it developed) and places it on the market or into service under its own name — carrying manufacturer-style duties: design controls, documentation, conformity.Open full entry →-verplichting onder de EU AI Act. De provider moet de toezichtsvoorzieningen inbouwen; deployers bedienen ze onder Art. 26.2.

Inleiding: toezicht begint in het ontwerp

Menselijk toezicht heeft twee artikelen, en het verschil daartussen is het verschil tussen bouwen en gebruiken. Art. 26.2 is de deployerdeployerAn organization using an AI system under its own authority in its activities — carrying operator duties: use per instructions, oversight, input relevance, monitoring, notices.Open full entry →-verplichting: zorg dat de personen die het systeem moeten overzien competent, getraind en bevoegd zijn. Art. 14 komt eerder in de keten: het vereist dat de provider het systeem zo ontwerpt en bouwt dat effectief menselijk toezicht überhaupt mogelijk is. Een deployer kan geen systeem overzien dat hem geen manier biedt om te begrijpen, te bevragen of te stoppen, hoe competent de toezichthouder ook is. Art. 14 is wat Art. 26.2 haalbaar maakt.

Het artikel kadert toezicht als een eigenschap die het systeem zo gebouwd moet zijn dat het die ondersteunt. De provider moet de technische middelen voor toezicht inbouwen, of de maatregelen identificeren die de deployer moet implementeren, voordat het systeem op de markt wordt gebracht. Toezicht is daarmee een ontwerpeis, beoordeeld bij conformiteit, geen operationele bijzaak.

Wat het systeem mogelijk moet maken

Art. 14 vereist dat hoog-risico AI-systemen zo zijn ontworpen dat natuurlijke personen die ze overzien het volgende kunnen, voor zover passend bij het risico:

• De capaciteiten en beperkingen begrijpen van het systeem en de werking ervan bewaken, inclusief het detecteren en aanpakken van afwijkingen en onverwacht gedrag.
• Bewust blijven van automation biasautomation biasThe human tendency to over-trust automated outputs — accepting a system's recommendation without genuinely weighing the case, which hollows out human oversight.Open full entry →, de neiging om te veel te vertrouwen op de output van een geautomatiseerd systeem, en zich daartegen wapenen.
• De output juist interpreteren, rekening houdend met de beschikbare hulpmiddelen en methoden voor interpretatie.
• Besluiten het systeem niet te gebruiken in een bepaalde situatie, of de output te negeren, overrulen of terugdraaien.
• Ingrijpen in of onderbreken van de werking van het systeem via een stopmechanisme dat het naar een veilige staat brengt.

Dat laatste punt is Art. 14(4)(e), de noodstop. Het systeem moet een mens in staat stellen het te stoppen, in één handeling, naar een veilige staat, en de handeling van het ingrijpen moet zelf deel uitmaken van het verslag. Dit is de concrete, ingebouwde uitdrukking van menselijke controle: geen beleid dat zegt dat een mens de leiding heeft, maar een knop die het bewijst.

De noodstop als geïnstrumenteerde control

Het stopmechanisme verdient stilstaan, omdat het de plek is waar het verschil tussen beleid en instrumentatie het scherpst is. Een governance-document kan beweren dat de organisatie menselijke controle over haar AI behoudt. Art. 14(4)(e) vereist dat die controle reëel en onmiddellijk is: een middel om het systeem in één handeling naar een veilige staat te brengen, beschikbaar voor de toezichthouder, met de ingreep gelogd. Een organisatie die het stopmechanisme kan demonstreren, en het logboek van wanneer het is gebruikt kan overleggen, heeft menselijk toezicht als geïnstrumenteerde control. Een die naar een alinea in een beleid wijst, heeft een aspiratie.

De relatie met Art. 26.2 en Art. 13

Art. 14 verbindt met twee artikelen aan weerszijden. Richting de deployer linkt het naar Art. 26.2: de toezichtsmaatregelen die de provider inbouwt, zijn de maatregelen die de deployer bedient, en de gebruiksinstructies moeten uitleggen hoe. Richting informatie linkt het naar Art. 13: de provider moet de deployer de informatie geven die nodig is om toezicht uit te oefenen, inclusief de grenzen van het systeem, de omstandigheden waaronder het onbetrouwbaar kan zijn, en hoe de outputs te interpreteren. Toezicht dat onder Art. 14 is ingebouwd maar onder Art. 13 niet wordt uitgelegd, laat de deployer machteloos om het te gebruiken.

Waarom het ertoe doet

Voor de provider wordt Art. 14 beoordeeld bij conformiteit: een hoog-risico systeem dat niet betekenisvol kan worden overzien, of dat een stopmechanisme mist, conformeert niet en kan de CE-markering niet dragen. Voor de deployer bepaalt Art. 14 of het systeem dat ze kopen daadwerkelijk bestuurbaar is. Een deployer die een hoog-risico systeem beoordeelt, moet het ontbreken van echte toezichtsvoorzieningen, met name een werkend stopmechanisme, behandelen als een conformiteitsgebrek om bij de provider aan te kaarten, niet als een beperking om omheen te werken.

Toezicht via ontwerp besturen

Voor providers zorgen de controls dat toezicht is ingebouwd en bewezen: het systeem toont zijn vertrouwen en grenzen, signaleert afwijkingen, maakt de override en de noodstop beschikbaar en bruikbaar, en logt ingrepen. Deze voorzieningen worden getest vóór marktintroductie en gedocumenteerd in het technisch dossier.

Voor deployers gaan de controls over verificatie bij inkoop: bevestig dat het systeem de Art. 14-toezichtsvoorzieningen biedt, dat het stopmechanisme werkt en een veilige staat bereikt, en dat de instructies uitleggen hoe outputs te interpreteren en wanneer het systeem onbetrouwbaar is. Een hoog-risico systeem dat niet door zijn toezichthouder kan worden gestopt, is er niet een die een deployer rechtmatig kan bedienen.

Checklist

1. Stelt het hoog-risico systeem een toezichthouder in staat de capaciteiten en beperkingen te begrijpen en de werking te bewaken?
2. Helpt het de toezichthouder afwijkingen te detecteren en automation bias te weerstaan?
3. Kan de toezichthouder de output juist interpreteren, met de hulpmiddelen die de provider levert?
4. Kan de toezichthouder besluiten het systeem niet te gebruiken, of de output overrulen of terugdraaien?
5. Is er een stopmechanisme (Art. 14(4)(e)) dat het systeem in één handeling naar een veilige staat brengt, met de ingreep gelogd?
6. Leggen de gebruiksinstructies (Art. 13) uit hoe deze toezichtsvoorzieningen uit te oefenen?