AI-act: de Verboden categorie en de Hoog risico-categorie

Door Mitzie Samuels | ICTrecht | 17 augustus 2026 | 9 min. leestijd

In mijn vorige blog heb ik ze al kort geïntroduceerd: de Verboden categorie en de Hoog risico-categorie. Als het AI-systeem in de eerste categorie valt, mag je deze niet op de markt brengen. Als jouw AI-systeem in de tweede categorie valt, ben je volgens de AI-Act verplicht om aan extra waarborgen te voldoen. In welke categorie valt jouw systeem? Wat zijn de waarborgen en de gevolgen voor jouw contracten? Lees hier meer over in mijn blog (deel 2/3).

Verboden categorie

Er geldt een absoluut verbod op: 

• Subliminale of manipulatieve technieken
• Uitbuiting van kwetsbaarheden
• Social scoring
• AI-risicobeoordeling voor criminaliteit op basis van puur profilering of persoonlijkheidskenmerken
• De aanleg van databanken voor gezichtsherkenning via ongerichte scraping
• Emotieherkenning op de werkplek of in het onderwijs
• Biometrische categorisering om ras, politieke opvattingen, vakbondslidmaatschap, religie, sekse of seksuele gerichtheid af te leiden
• Realtime biometrische identificatie op afstand in openbare ruimten voor rechtshandhaving

Als jouw systeem ziet op deze onderwerpen, dan is het verboden om het op de Europese markt te zetten.

Hoog risico-categorie

Bij de ‘hoog risico’-categorie zijn de grenzen vager. Wanneer valt jouw AI-systeem in deze categorie? De Europese Commissie heeft recent een concept van de Richtlijnen gepubliceerd, waarin meer uitleg wordt gegeven bij de categorieën. Bij het definiëren van de categorie komt het op het volgende neer:

De twee pijlers

• De eerste pijler ziet op systemen in bepaalde producten, of een veiligheidscomponent daarvan, zoals: liften, speelgoed, medische apparatuur en de luchtvaartsector.
  Daarnaast moet er volgens de wetgeving van dat product een conformiteitsbeoordeling door een derde partij worden uitgevoerd, voordat het in de handel wordt gebracht.
• De tweede pijler ziet op systemen die worden gebruikt in kritieke infrastructuren van de maatschappij.
  Denk aan software die wordt gebruikt als veiligheidscomponent bij het wegverkeer, de levering van water, gas of elektriciteit. Of aan software die het niveau van leerlingen meet op de middelbare school en die jouw kredietwaardigheid of premie vaststelt voor een levens- en ziektekostenverzekering. Maar ook aan systemen die bepalen of de politie, brandweer en ambulance in een bepaalde situatie wel of niet moeten uitrukken. Als jouw systeem onder deze pijler valt en daarnaast een “significant risico op schade voor de gezondheid, veiligheid of de grondrechten van natuurlijke personen” vormt, is het een hoog risico-systeem. Er is een significant risico als het systeem de uitkomst van de besluitvorming wezenlijk beïnvloedt. Dat is in ieder geval niet het geval bij:
  • beperkte procedurele taken, 
  • verbetering van resultaten van een eerder menselijke activiteit of 
  • het opsporen van besluitvormingspatronen/-afwijkingen van eerdere besluitvormingspatronen. 

Wanneer beperkt het systeem zich slechts tot een procedurele taak? 
Er is sprake van een procedurele taak als: de uitgevoerde taken door het systeem voorbereid zijn, het systeem de concrete voorliggende gevallen niet analyseert of evalueert en geen output genereert die van wezenlijke invloed is op het besluit.

Als een systeem bijvoorbeeld wordt ingezet bij het toekennen van overheidsuitkeringen, dan zijn verwijzingen naar de relevante wettelijke bepalingen, informatie over de rechtsbevoegdheid en eventuele bestaande interne richtlijnen, voorbereidende taken. Het systeem neemt zelf geen besluiten over welke kandidaat een uitkering krijgt, maar verwijst naar algemene informatie als aanvullende informatie die de beoordelaar bij de besluitvorming in overweging neemt. De software beïnvloedt de besluitvorming dan niet wezenlijk, waardoor het niet in de hoog risico-categorie valt. Hierbij valt op te merken dat in het geval dat er meerdere kleinere systemen deel uitmaken van een complexer systeem, de combinatie van die systemen voor de classificatie van een procedurele taak telt als één enkel systeem. Een systeem dat bijvoorbeeld bestaat uit module A (zoekopdrachten), module B (filteren) en module C (adviseren recruiter) maar ze samen in de markt zet voor één wervingsdoel, wordt dus als één systeem gezien. 

Samengevat: Valt jouw systeem onder de productwetgeving van Bijlage I en is een externe keuring verplicht voordat het op de markt komt? Dan valt het automatisch in de hoog risico-categorie. Valt jouw systeem onder de toepassingen van Bijlage III (zoals kritieke infrastructuren) én vormt het een significant risico op schade voor de gezondheid, veiligheid of grondrechten van natuurlijke personen? Dan valt jouw systeem eveneens in de hoog risico-categorie.

Hoog risico-systeem: wat nu?

Als jouw systeem in deze categorie valt, dan zijn er eisen gesteld aan je product en wettelijke verplichtingen. Ik ga in op deze laatste categorie. Voor de aanbieder van een hoog risico-systeem gelden o.a. de volgende verplichtingen:

• Conformiteitsbeoordeling
  Voordat het AI-systeem in de handel wordt gebracht, moet je een conformiteitsbeoordeling opstellen of dit laten doen door een externe partij.
  • Regelt jouw systeem één van de kritieke onderwerpen (werkgelegenheid, onderwijs, krediet, overheidsuitkeringen etc.)?
    Dan stel jij als aanbieder de technische documentatie op en beoordeel je zelf of het aan de AI-Act voldoet. Dit leg je vast en je ondertekent de EU-conformiteitsverklaring. De beoordeling moet een beschrijving bevatten van: het beoogde doel van het systeem, waarom het wel of niet als ‘hoog risico’ kwalificeert, of er sprake is van een beperkte procedurele taak en een beschrijving over waarom het systeem wel of geen geen profilering uitvoert.
  • Maakt jouw AI-systeem gebruik van biometrische systemen (identificatie op afstand, categorisering, emotieherkenning)?
    Dan heb je momenteel nog een externe beoordeling nodig.
  • Is jouw AI-systeem (onderdeel van) een product dat op de lijst van Bijlage I staat?
    Dan geldt de wetgeving van die sector (vaak een externe beoordeling).
• Registratie in EU-databank
  Het is ook de bedoeling dat je jouw hoog risico-systeem inschrijft in de EU-databank. Dit doe je met behulp van o.a. de handleiding en een conformiteitsbeoordeling. Inschrijvingen kunnen op dit moment nog niet worden gedaan.
• Bewaarplicht
  Je hebt tevens de plicht om tien jaar, nadat het AI-systeem met een hoog risico in de handel is gebracht, bepaalde documenten te bewaren. Dit is de documentatie over de techniek (hoe het werkt, hoe het is getraind en welke risico’s zijn beoordeeld), het kwaliteitsbeheersysteem (je interne procedures en beleid waarmee je de naleving van de AI-Act borgt), de goedgekeurde wijzigingen en besluiten en certificaten van de aangemelde instantie en de EU-conformiteitsverklaring waaruit blijkt dat je systeem voldoet aan de AI-Act.
• CE-markering aanbrengen
  Het CE-teken moet daarnaast zichtbaar zijn in de interface van je software. Denk aan een vermelding in het instellingenscherm, of een machineleesbare code (bijvoorbeeld een QR-code of metadata-tag) die naar de conformiteitsinformatie verwijst.
• Corrigerende maatregelen bij non-conformiteit
  Als het systeem non-conform is (omdat het bijvoorbeeld geen passend, consistent niveau van nauwkeurigheid, robuustheid en beveiliging heeft), dan geldt de plicht om corrigerende maatregelen te nemen. Naargelang het geval kan dit ook betekenen: het systeem uit de handel nemen, deactiveren of terugroepen.
• Gebruiksaanwijzing
  Het systeem moet vergezeld gaan met een gebruiksaanwijzing die jouw klant in staat stelt het systeem te begrijpen en correct te gebruiken.

Wat betekent dit voor de afspraken met jouw klant?

• Om te beginnen rusten de verplichtingen die hierboven staan, in principe op jou als aanbieder.
  Als jouw klant zijn eigen naam of merk echter op jouw AI-systeem plaatst en het systeem substantieel aanpast of het voor een ander doel gebruikt dan waarvoor jij het hebt ontworpen, neemt hij jouw plaats als aanbieder in. De verplichtingen van de aanbieder rusten dan op jouw klant. Dit kun je niet uitsluiten. Als jouw klant het systeem weliswaar overneemt zónder het systeem aan te passen (white labeling), dan kun je hier wel contractueel van afwijken. Je kan dan in het contract afspreken dat de klant in dat geval aanbieder wordt in plaats van jou of dat jij het zelf blijft. Het kan handig zijn om dit vast te leggen, zodat je weet wie welke rol vervult en op wie welke verplichtingen komen te rusten.
• Als “gebruiksverantwoordelijke” moet de klant het systeem daarnaast monitoren op basis van de gebruiksaanwijzing. Hij heeft daarbij de plicht om jou (en zo nodig de toezichthouder) te waarschuwen als hij een risico signaleert. Aangezien op de aanbieder de plicht rust om in geval van een niet werkend systeem corrigerende maatregelen te nemen en dat te melden, valt het aan te raden om deze verplichting contractueel vast te leggen. Op deze manier informeer je de klant van deze verplichting en kun je extra invulling geven aan de manier waarop hij het kan melden, zodat je zo snel mogelijk op de hoogte wordt gesteld van eventuele risico’s aan je systeem.
• Je wil daarnaast ook vermijden dat jij aansprakelijk wordt gesteld voor al het ongeoorloofde gebruik van jouw software. Het is dan ook raadzaam om in het contract vast te leggen dat gebruik buiten het beoogde doel, zoals vastgelegd in de gebruiksaanwijzing, voor rekening van de klant komt.
• Tot slot is het handig om je klant te verplichten om steeds de laatste versie van de instructies te gebruiken en deze ongewijzigd door te geven aan derden partijen.

Sancties: welke en vanaf wanneer?

De datum waarop kan worden gehandhaafd is verschoven naar december 2027 (Bijlage III) en augustus 2028 (Bijlage I). Als jouw software in de hoog risico-categorie valt, is het aan te raden om voor die tijd een conformiteitsbeoordeling en een EU-databankregistratie te hebben. Boetes voor het niet naleven van de verplichtingen die op de aanbieder rusten, kunnen oplopen tot €15 miljoen of 3% van de wereldwijde jaaromzet (afhankelijk van welk bedrag hoger is). Daarnaast riskeer je als aanbieder dat de toezichthouder het AI-systeem per direct laat stilleggen en verplicht uit de markt laat terughalen. Ook bestaat er een groot risico voor civielrechtelijke schadeclaims van benadeelde gebruikers.

Conclusie

De AI-Act is dus niet alleen een technische, maar ook een juridische uitdaging. Valt jouw software in de hoog risico-categorie, dan is het zaak om je Algemene Voorwaarden en contracten in orde te maken. Hoewel de handhaving pas eind 2027 start, zijn de risico’s door niet-naleving van de regelgeving te groot om de keuzes hierover voor je uit te schuiven. Twijfel je over jouw specifieke situatie of wil je je contracten laten beoordelen? Neem dan gerust contact op met ons kantoor!

Naar blog overzicht