De aftelling naar augustus

2 augustus 2026. Dat is de datum waarop de bepalingen voor hoog-risico AI-systemen van de AI-verordening van de EU volledig van kracht worden. Niet de GPAI-modelbepalingen en governanceregels — die gelden sinds 2 augustus 2025. Niet de verboden praktijken — die traden in werking in februari 2025. De hoog-risico bepalingen. Die met tanden.

Vijf maanden vanaf vandaag.

Dit is niet weer een “wat de AI-verordening van de EU betekent voor jouw bedrijf”-artikel. De markt heeft er duizenden van geproduceerd. Ze zijn abstract, uitgebreid en operationeel nutteloos — ontworpen om de bekendheid van de auteur met de regelgeving te demonstreren, niet om een bedrijf te helpen bij de voorbereiding op compliance.

Dit is een specifieke, artikel-voor-artikel uitsplitsing van wat een bedrijf dat AI-systemen inzet op orde moet hebben voor 2 augustus 2026. Het is geschreven voor bedrijven met 50 tot 500 werknemers die AI-systemen hebben geimplementeerd of implementeren die onder hoog-risico classificatie kunnen vallen. Het gaat ervan uit dat je nog niet begonnen bent met voorbereiden. Vijf maanden is genoeg — als je nu begint.

Is jouw systeem hoog-risico?

Artikel 6 definieert hoog-risico AI-systemen in twee categorieen:

Categorie 1 (Artikel 6(1)): AI-systemen die veiligheidscomponenten zijn van producten, of zelf producten zijn, die vallen onder EU-harmonisatiewetgeving vermeld in bijlage I. Dit omvat machines, medische hulpmiddelen, speelgoed, radioapparatuur, burgerluchtvaart, voertuigen, maritieme apparatuur, spoorwegsystemen en andere. Als jouw AI-systeem is ingebouwd in of fungeert als veiligheidscomponent van een product dat onder deze richtlijnen valt, is het standaard hoog-risico.

Categorie 2 (Artikel 6(2) en Bijlage III): AI-systemen die worden gebruikt in specifieke hoog-risicogebieden vermeld in bijlage III. De acht gebieden zijn:

1. Biometrische identificatie en categorisering. Biometrische identificatiesystemen op afstand, emotieherkenning, biometrische categorisering.
2. Beheer en exploitatie van kritieke infrastructuur. AI-systemen die worden gebruikt als veiligheidscomponenten bij het beheer van wegverkeer, water-, gas-, verwarmings- en elektriciteitsvoorziening.
3. Onderwijs en beroepsopleiding. AI-systemen die toegang tot onderwijs bepalen, leerresultaten evalueren, verboden gedrag tijdens examens monitoren.
4. Werkgelegenheid, personeelsbeheer en toegang tot zelfstandig ondernemerschap. AI-systemen voor werving en selectie, targeting van vacatureadvertenties, aannamebeslissingen, taakverdeling, monitoring en evaluatie van werknemersprestaties, en beslissingen over promotie of ontslag.
5. Toegang tot essentiele private en publieke diensten. Kredietscore, verzekeringsprijsstelling, geschiktheid voor sociale uitkeringen, dispatching van hulpdiensten.
6. Rechtshandhaving. Individuele risicobeoordelingen, leugendetectie, bewijsbeoordeling, profilering.
7. Migratie, asiel en grenscontrole. Risicobeoordelingen, documentverificatie, aanvraagverwerking.
8. Rechtsbedeling en democratische processen. AI-systemen die bijstaan bij juridisch onderzoek, zaakanalyse of strafoplegging.

Voor een EU mkb-bedrijf met 50-500 werknemers zijn de meest voorkomende hoog-risicoclassificaties: werkgelegenheid (elke AI-tool die wordt gebruikt bij werving, prestatiebeoordeling of personeelsbeheer) en essentiele diensten (elke AI-tool die wordt gebruikt bij kredietbeslissingen, verzekeringsbeoordelingen of uitkeringsgeschiktheid).

De classificatie gaat niet over het model. Het gaat over de use case. Hetzelfde taalmodel dat marketingteksten genereert (minimaal risico) wordt hoog-risico wanneer het sollicitaties beoordeelt. Het model is niet veranderd. De use case is veranderd. De verplichtingen volgen.

De uitzondering van Artikel 6(3): AI-systemen vermeld in bijlage III kunnen worden uitgesloten van hoog-risicoclassificatie als ze geen “aanzienlijk risico op schade” vormen voor gezondheid, veiligheid of grondrechten. Het bedrijf moet documenteren waarom de uitzondering van toepassing is. Bij twijfel: classificeer als hoog-risico. De kosten van overclassificatie zijn compliance. De kosten van onderclassificatie zijn handhaving.

De vijf vereisten — artikel voor artikel

Als jouw systeem hoog-risico is, gelden vijf sets vereisten. Hier zijn ze, met specifieke operationele acties voor elk.

Vereiste 1: Risicobeheersysteem (Artikel 9)

Je hebt een gedocumenteerd risicobeheersysteem nodig dat de risico’s van jouw AI-systeem identificeert, analyseert, evalueert en mitigeert. Dit is geen eenmalige risicobeoordeling. Het is een “continu iteratief proces” dat loopt gedurende de gehele levenscyclus van het systeem.

Wat dit in de praktijk betekent:

Voor 2 augustus: Documenteer de bekende risico’s van jouw AI-systeem. Niet generieke AI-risico’s. De specifieke risico’s van jouw systeem. Wat gebeurt er als het het antwoord fout heeft? Wie wordt getroffen? Hoe ernstig? Welke categorieen fouten zijn het meest waarschijnlijk? (De modelkaart — waarover ik eerder schreef — is je primaire bron voor risico’s op modelniveau.)

Maak een risicoregister dat elk geidentificeerd risico koppelt aan een mitigatiemaatregel. De mitigatie moet specifiek zijn: “Wij voeren handmatige beoordeling uit van alle geautomatiseerde beslissingen die individuele werkgelegenheid beinvloeden” is een mitigatie. “Wij monitoren het systeem op risico’s” is dat niet.

Stel een proces vast voor het bijwerken van het risicoregister wanneer het systeem verandert, wanneer de use case uitbreidt, of wanneer een nieuw risico wordt geidentificeerd in productie. Het proces moet specificeren wie verantwoordelijk is, hoe vaak het register wordt beoordeeld, en wat een ad-hoc beoordeling triggert.

Geschatte inspanning: 2-3 weken toegewijd werk voor een typische mkb-implementatie. Een persoon, parttime, met domeinexpertise in het toepassingsgebied van het AI-systeem.

Vereiste 2: Data-governance (Artikel 10)

Training-, validatie- en testdatasets moeten voldoen aan kwaliteitscriteria gespecificeerd in de verordening. De data moet “relevant, voldoende representatief, en voor zover mogelijk vrij van fouten en volledig” zijn. Je moet de kenmerken van de data documenteren, de bron, het dataverzamelingsproces en eventuele voorverwerkingsbewerkingen.

Wat dit in de praktijk betekent:

Als je het model hebt gefinetuned: Documenteer de finetuning-dataset. Welke data is gebruikt? Waar kwam het vandaan? Welke kwaliteitscontroles zijn toegepast? Waren beschermde kenmerken (leeftijd, geslacht, etniciteit, handicap) aanwezig in de data? Zo ja, hoe zijn die behandeld? Waren er bekende biases in de data? Zo ja, welke mitigaties zijn toegepast?

Als je een voorgetraind model via API gebruikt: De modelkaart en datadocumentatie van de modelleverancier dragen bij aan deze vereiste, maar je bent nog steeds verantwoordelijk voor de data die jouw systeem verwerkt. Documenteer de data die jouw systeem binnenkomt: klantgegevens, operationele data, de documenten in je RAG-pipeline. Dezelfde kwaliteitscriteria gelden.

Als je deze documentatie niet hebt: Begin nu met opbouwen. De inspanning is retrospectieve documentatie van beslissingen die al genomen zijn. Het is saai. Het is niet complex. Een stagiair met een template en toegang tot het datateam kan 80% van de vereiste documentatie produceren in twee weken.

Geschatte inspanning: 1-2 weken voor een systeem dat een voorgetraind model via API gebruikt. 3-4 weken voor een systeem met aangepaste finetuning.

Vereiste 3: Technische documentatie (Artikel 11 en Bijlage IV)

Je moet technische documentatie produceren voordat het systeem op de markt wordt gebracht of in gebruik wordt genomen. Bijlage IV specificeert de inhoud in detail:

• Algemene beschrijving van het AI-systeem en het beoogde doel
• Gedetailleerde beschrijving van de elementen van het AI-systeem en het ontwikkelingsproces
• Gedetailleerde informatie over monitoring, werking en controle van het systeem
• Beschrijving van het risicobeheersysteem
• Beschrijving van wijzigingen aan het systeem gedurende de levenscyclus
• Een lijst van toegepaste geharmoniseerde normen
• Een beschrijving van de maatregelen om ervoor te zorgen dat het systeem voldoet aan de relevante vereisten

Wat dit in de praktijk betekent:

Dit is een documentatie-oefening. Het systeem bestaat al (of wordt gebouwd). De technische documentatie beschrijft wat er bestaat. Het kernprincipe: schrijf het zo dat een competente technische beoordelaar kan begrijpen wat het systeem doet, hoe het dat doet, welke risico’s het met zich meebrengt en welke beheersmaatregelen er zijn.

Het document hoeft niet mooi te zijn. Het moet nauwkeurig, volledig en onderhouden zijn. Een levend document dat wordt bijgewerkt wanneer het systeem verandert, voldoet. Een gepolijst document dat zes maanden geleden nauwkeurig was en niet is bijgewerkt, voldoet niet.

Geschatte inspanning: 3-4 weken voor de initiele documentatie. Doorlopend onderhoud: 2-4 uur per maand.

Vereiste 4: Registratie en logboekregistratie (Artikel 12)

Het AI-systeem moet automatisch gebeurtenissen loggen die relevant zijn voor het identificeren van risico’s en het faciliteren van post-markt monitoring. Logboeken moeten bevatten: de periode van elk gebruik, de referentiedatabase waartegen inputdata is gecontroleerd, inputdata waarvoor de zoekopdracht tot een match leidde, en de identificatie van de natuurlijke personen die betrokken waren bij de verificatie van de resultaten.

Wat dit in de praktijk betekent:

Jouw AI-systeem moet audittrails produceren. Elke beslissing die het systeem neemt (of aanbeveelt) moet worden gelogd met voldoende detail om de beslissing achteraf te kunnen reconstrueren. Het logboek moet bevatten: de input, de output, de tijdstempel en de identiteit van elke menselijke beoordelaar.

Voor een mkb-bedrijf dat een klantenservice-AI of HR-screeningtool inzet, betekent dit het implementeren van gestructureerde logging in de applicatielaag. De engineeringinspanning is bescheiden — de meeste moderne AI-implementatieframeworks ondersteunen gestructureerde logging. De opslagkosten zijn evenredig aan het volume: een systeem dat 500 beslissingen per dag verwerkt, genereert ongeveer 15MB aan gestructureerde logs per maand bij gemiddelde uitgebreidheid.

Geschatte inspanning: 1-2 weken engineering voor implementatie. Minimale doorlopende kosten.

Vereiste 5: Menselijk toezicht (Artikel 14)

Ik heb hier een volledig artikel over geschreven (“De fout van EUR 500.000”). Samengevat: het systeem moet ontworpen zijn om doeltreffend te worden overzien door natuurlijke personen. Het toezicht moet betekenisvol zijn — onafhankelijke beoordeling, praktische overschrijvingsbevoegdheid, voldoende tijd en aangetoonde variatie in uitkomsten.

Wat dit in de praktijk betekent:

Bouw de beoordelingsinterface. Ontwerp de workflow. Train de beoordelaars. Monitor de overschrijvingspercentages. Dit alles moet op orde zijn voor 2 augustus.

Geschatte inspanning: 3-5 weken voor interfaceontwikkeling, workflowontwerp en beoordelaarstraining.

De conformiteitsbeoordeling

Artikelen 16-22 definieren de verplichtingen van aanbieders van hoog-risico AI-systemen — de vereisten waaraan een bedrijf moet voldoen om aan te tonen dat zijn hoog-risico AI-systeem compliant is.

Voor de meeste mkb-implementaties (die niet vallen onder specifieke EU-harmonisatiewetgeving in bijlage I) is de conformiteitsbeoordeling een interne beoordeling onder artikel 43(2). Je hebt geen externe auditor nodig. Je hebt geen aangemelde instantie nodig. Je beoordeelt je eigen compliance op basis van de vereisten in artikelen 8-15, documenteert de beoordeling en geeft een EU-conformiteitsverklaring af (artikel 47).

Dit is belangrijk: voor de meeste mkb-use cases is conformiteit zelfbeoordeeld. De verordening vertrouwt erop dat de inzetter zijn eigen compliance evalueert — mits de evaluatie is gedocumenteerd, de documentatie wordt onderhouden en het systeem onderworpen is aan post-markt monitoring.

De conformiteitsverklaring is een document van een pagina dat stelt: dit AI-systeem, gebruikt voor dit doel, voldoet aan de vereisten van de AI-verordening van de EU. Het verwijst naar de technische documentatie, het risicobeheersysteem en het kwaliteitsbeheersysteem.

De verklaring moet tien jaar worden bewaard nadat het AI-systeem op de markt is gebracht.

De registratievereiste

Artikel 49 vereist dat hoog-risico AI-systemen worden geregistreerd in de EU-database voor zelfstandige hoog-risico AI-systemen (opgezet onder artikel 71) voordat ze op de markt worden gebracht of in gebruik worden genomen.

Registratie is elektronisch, via een portaal dat wordt beheerd door het AI-bureau. De vereiste informatie is: de naam en contactgegevens van de aanbieder, een beschrijving van het beoogde doel, de status van het AI-systeem (op de markt, teruggetrokken, teruggeroepen), een beschrijving van hoe het systeem beschikbaar wordt gesteld, en de EU-conformiteitsverklaring.

Registratie is geen poortwachtersmechanisme. Het is een transparantiemechanisme. De database is openbaar. Het registreren van jouw systeem toont compliance-intentie. Het niet registreren van een operationeel hoog-risico systeem is op zichzelf een overtreding.

De tijdlijn

Vijf maanden. Hier is een realistische tijdlijn voor een mkb-bedrijf dat nog niet begonnen is met voorbereiden:

Maanden 1-2 (maart-april 2026): Risicoclassificatie. Bepaal of jouw AI-systemen hoog-risico zijn onder artikel 6 en bijlage III. Inventariseer alle AI-systemen in gebruik binnen het bedrijf — inclusief tools die door individuele teams zijn aangeschaft zonder centraal IT-toezicht. Begin met de risicobeheerdocumentatie (artikel 9) en data-governance documentatie (artikel 10) voor elk systeem dat als hoog-risico is geclassificeerd.

Maand 3 (mei 2026): Technische documentatie. Produceer de bijlage IV technische documentatie voor elk hoog-risico systeem. Implementeer gestructureerde logging (artikel 12) als dat nog niet gedaan is. Begin met het ontwikkelen van de menselijke toezichtinterface en workflow (artikel 14).

Maand 4 (juni 2026): Implementatie menselijk toezicht. Voltooi de beoordelingsinterface, train beoordelaars, stel de workflow vast. Begin met de interne conformiteitsbeoordeling. Identificeer lacunes en herstel ze.

Maand 5 (juli 2026): Voltooiing conformiteitsbeoordeling. Geef de EU-conformiteitsverklaring af. Registreer hoog-risico systemen in de EU-database. Stel het post-markt monitoringproces vast. Documenteer alles.

2 augustus 2026: Volledige bepalingen van kracht. Jouw systemen zijn compliant, geregistreerd en gemonitord — of ze zijn dat niet, en je opereert in overtreding.

Het kwaliteitsbeheersysteem

Artikel 17 vereist dat aanbieders van hoog-risico AI-systemen een kwaliteitsbeheersysteem implementeren. Deze vereiste wordt vaak over het hoofd gezien in aftellingsartikelen omdat het generiek klinkt. Dat is het niet.

Het kwaliteitsbeheersysteem moet omvatten: beleid en procedures voor de implementatie van de vereisten van de AI-verordening, technieken en procedures voor het ontwerp, de ontwerpcontrole en de ontwerpverificatie van het hoog-risico AI-systeem, technieken en procedures voor de ontwikkeling, kwaliteitscontrole en kwaliteitsborging, onderzoeks-, test- en validatieprocedures die voor, tijdens en na de ontwikkeling van het systeem worden uitgevoerd, en databeheerprocedures.

Voor een mkb-bedrijf hoeft het kwaliteitsbeheersysteem geen ISO 9001-certificering te hebben. Het moet gedocumenteerd, geimplementeerd en onderhouden zijn. Een praktisch kwaliteitsbeheersysteem voor een mkb AI-implementatie is een document van 10-15 pagina’s dat specificeert: wie verantwoordelijk is waarvoor, hoe wijzigingen aan het systeem worden beheerst, hoe het systeem wordt getest voor updates, hoe post-markt incidenten worden gerapporteerd en onderzocht, en hoe de documentatie actueel wordt gehouden.

Het document kost ongeveer een week om te produceren. Het moet bestaan voor 2 augustus. Het moet worden nageleefd na 2 augustus. De kloof tussen het hebben van het document en het naleven van het document is de kloof waarop handhavingsacties zich richten.

Het boetekader

Artikel 99 definieert de sancties voor non-compliance:

• Overtredingen van verboden AI-praktijken (artikel 5): tot EUR 35 miljoen of 7% van de jaarlijkse wereldwijde omzet.
• Overtredingen van hoog-risico vereisten (artikelen 8-15): tot EUR 15 miljoen of 3% van de jaarlijkse wereldwijde omzet.
• Het verstrekken van onjuiste informatie aan toezichthouders: tot EUR 7,5 miljoen of 1% van de jaarlijkse wereldwijde omzet.

Voor mkb-bedrijven voorziet de verordening in proportionele sancties — boetes worden berekend in verhouding tot de omvang van het bedrijf en de ernst van de overtreding. Maar “proportioneel” is niet “verwaarloosbaar.” Een boete van 3% op de omzet voor een bedrijf met EUR 10 miljoen jaaromzet is EUR 300.000. Voor veel mkb-bedrijven is dat existentieel.

De verordening voorziet ook in niet-financiele handhaving: bevelen om AI-systemen van de markt terug te trekken, bevelen om AI-systemen aan te passen, en openbare verklaringen die non-compliante bedrijven en hun systemen identificeren.

De positie

Vijf maanden is genoeg tijd om te voldoen. Vijf maanden is niet genoeg tijd om te treuzelen, een werkgroep te vormen, een adviesopdracht uit te zetten, en vervolgens te voldoen.

De verordening is specifiek. De vereisten zijn opsombaar. De conformiteitsbeoordeling is intern. De registratie is elektronisch. Niets hiervan vereist een leger advocaten of een zescijferig adviesbudget.

Wat het vereist is een beslissing: wij voldoen voor 2 augustus. Die beslissing, vandaag genomen, geeft je vijf maanden gestructureerd werk. Die beslissing, genomen in juni, geeft je vijf weken paniek.

De AI-verordening van de EU is niet dubbelzinnig over wat het vereist. Het is alleen dubbelzinnig over of je het serieus neemt voordat de deadline aanbreekt.

Vijf maanden. De aftelling loopt.