EU AI Act voor hoog-risico AI: een bouwersgids

EU AI Act-naleving voor hoog-risico AI-systemen betekent dat u het systeem zo bouwt dat het voldoet aan de artikelen 9 tot en met 15: een gedocumenteerd risicobeheerproces, beheerde en representatieve trainingsdata, volledige technische documentatie (bijlage IV), automatische logging, transparantie met heldere gebruiksinstructies, ingebouwd menselijk toezicht, en aantoonbare nauwkeurigheid, robuustheid en cybersecurity. De formele conformiteitsbeoordeling en CE-markering worden afgetekend door een notified body of juridisch adviseur — maar elk van die verplichtingen vertaalt zich naar een concrete bouwpraktijk (model cards, evaluatieharnassen, audit logs, human-in-the-loop UX, monitoring) die in het systeem zelf moet bestaan. De eerste hoog-risicoverplichtingen gelden vanaf augustus 2026, de rest volgt in augustus 2027.

Voor wie deze gids is — en één eerlijke kanttekening

Dit is de hub voor implementeerders. Hij is geschreven voor de mensen die het systeem daadwerkelijk bouwen — ML-engineers, dataleads, product owners, oprichters — niet voor uw functionaris gegevensbescherming, uw jurist of de notified body. De gids legt artikel voor artikel en in heldere taal uit wat er nodig is om een hoog-risico AI-systeem te *bouwen* dat aan de EU AI Act-specificatie voldoet, en koppelt elke eis aan concrete engineeringpraktijk.

Eén ding vooraf glashelder: dit is algemene informatie, geen juridisch advies. De formele conformiteitsaftekening — de juridische vaststelling dat uw systeem conform is en een CE-markering mag dragen — wordt gedaan door een notified body of een gekwalificeerde juridische adviseur. Wat Crux Digits doet, is systemen bouwen die aan de specificatie voldoen, zodat die aftekening een formaliteit is en geen herbouw. Wilt u juist de regelgevende of sectorale invalshoek? Dat zijn aparte artikelen: begin met EU AI Act-naleving in Nederland, de AI Act-nalevingschecklist of de gids voor het mkb.

Controleer eerst of uw systeem werkelijk hoog-risico is. De verordening reserveert de hoog-risicocategorie voor AI die in afgebakende contexten wordt gebruikt — biometrie, kritieke infrastructuur, onderwijs, werkgelegenheid en personeelsbeheer, toegang tot essentiële diensten, rechtshandhaving, migratie en rechtspleging, plus AI die een veiligheidscomponent is van een gereguleerd product. Hoort uw systeem in geen van die contexten thuis, dan zit u waarschijnlijk in de categorie beperkt of minimaal risico en gelden de zware verplichtingen hieronder niet — al kunnen de transparantieregels van artikel 50 wel van toepassing zijn. Het vervolg gaat ervan uit dat u heeft vastgesteld dat u binnen de reikwijdte valt.

Artikel 9 — het risicobeheersysteem

Artikel 9 is de ruggengraat van het geheel. Het vereist een doorlopend, gedocumenteerd risicobeheerproces dat de volledige levenscyclus van het systeem bestrijkt: identificeer de redelijkerwijs te voorziene risico's voor gezondheid, veiligheid en grondrechten, schat ze in en evalueer ze, en tref maatregelen om ze tot een aanvaardbaar niveau terug te brengen. "Doorlopend" is het sleutelwoord — dit is geen eenmalig document dat u indient en vergeet.

In engineeringtermen is dit een levend risicoregister dat aan uw ontwikkelworkflow hangt, niet een PDF op een gedeelde schijf. De praktijken die het echt maken:

• Een risicoregister dat per geïdentificeerd gevaar de waarschijnlijkheid, de ernst, de maatregel en het restrisico na maatregel bijhoudt.
• Risicoreviews die in uw releaseproces zijn ingebouwd — een model- of datawijziging triggert een herbeoordeling, net zoals een security-gevoelige wijziging een review triggert.
• Testen tegen de risico's die u heeft benoemd, met het testbewijs teruggekoppeld aan het register, zodat een auditor een risico kan terugleiden naar de maatregel die het afdekt.
• Eigenaren en deadlines, zodat aan elk openstaand risico een naam hangt en het niet stilletjes wegrot.

De valkuil waar teams in lopen, is artikel 9 als documentatietheater behandelen. De verordening verwacht dat het restrisico na uw maatregelen als aanvaardbaar wordt beoordeeld, en dat oordeel moet verdedigbaar zijn. Kunt u het bewijs achter "aanvaardbaar" niet tonen, dan heeft u geen risicobeheersysteem — dan heeft u een wens.

Artikel 10 — data en datagovernance

Artikel 10 gaat over de data die het model traint, valideert en test. Trainings-, validatie- en testsets moeten relevant, voldoende representatief en zo veel mogelijk foutloos en volledig zijn voor het beoogde doel. U moet de data onderzoeken op mogelijke bias en op gaten die tot schade of discriminatie kunnen leiden, en u moet rekening houden met de specifieke geografische, gedragsmatige of functionele setting waarin het systeem zal werken.

Dit is waar goede data-engineering zich terugbetaalt, want het grootste deel van de verplichting zit vóór het model:

• Een gedocumenteerd dataherkomstspoor — waar elke dataset vandaan komt, hoe die is verzameld, welke licenties en toestemmingen erop rusten.
• Representativiteitscontroles tegen de werkelijke populatie waarin het systeem wordt ingezet, niet alleen tegen de data die u toevallig had. Een aannamemodel dat vooral op één demografische groep is getraind, is het schoolvoorbeeld van een artikel 10-fout.
• Biasonderzoek als gemeten stap: splits uw evaluatiemetrieken uit naar de groepen die ertoe doen en leg de verschillen vast, in plaats van eerlijkheid te beweren.
• Geversioneerde datasets (denk aan DVC of een gelijkwaardig instrument), zodat elk model herleidbaar is tot de exacte datasnapshot waarop het is getraind.
• Gedocumenteerde keuzes rond preprocessing, labeling en opschoning — die bepalen de uitkomst net zo sterk als de modelarchitectuur.

Het eerlijke aan dit artikel is dat "foutloos en volledig" wordt genuanceerd met "zo veel mogelijk". Perfecte data bestaat niet. Wat de toezichthouder wil, is bewijs dat u heeft gekeken, gemeten en bewuste, vastgelegde keuzes heeft gemaakt over de gaten die u vond.

Artikel 11 — technische documentatie (bijlage IV)

Artikel 11 vereist technische documentatie die aantoont dat het systeem aan de eisen voldoet, en die moet bestaan voordat het systeem op de markt komt. Bijlage IV is de inhoudsopgave: een algemene beschrijving van het systeem en het beoogde doel; het ontwerp, het ontwikkelproces en de methoden; de data en datagovernance; de monitoring, werking en besturing; de risicobeheermaatregelen; en de validatie- en testresultaten, inclusief metrieken voor nauwkeurigheid en robuustheid.

De vergissing is dit te zien als een document dat u aan het eind schrijft. De teams die het zwaar krijgen, zijn de teams die de week voor de lancering een half jaar aan beslissingen uit hun geheugen moeten reconstrueren. De teams die er soepel doorheen gaan, produceren eu ai act technische documentatie als bijproduct van hoe ze al werken:

• Model cards en dataset-datasheets die naast de code worden onderhouden en bij elke significante wijziging worden bijgewerkt.
• Een spoor van architectuurbeslissingen (ADR's), zodat het *waarom* achter elke ontwerpkeuze wordt vastgelegd op het moment zelf, niet achteraf bedacht.
• Evaluatierapporten die uw testharnas automatisch genereert — nauwkeurigheid, robuustheid en de metrieken daarachter, voorzien van de model- en dataversies die ze beschrijven.
• Een experiment-trackingsysteem (MLflow, Weights & Biases of vergelijkbaar) dat het grootste deel van bijlage IV al bevat als u het op de juiste velden richt.

Op deze manier wordt bijlage IV grotendeels samengesteld in plaats van geschreven. Daar draait alles om: maak nalevingsdocumentatie een afgeleid artefact van gedisciplineerde engineering.

Artikel 12 — logging en registratie

Artikel 12 vereist dat hoog-risicosystemen gedurende hun levensduur automatisch gebeurtenissen (logs) registreren, in een mate die past bij het doel van het systeem. Het gaat om traceerbaarheid: kunnen reconstrueren wat het systeem deed, wanneer en op welke input, zodat incidenten kunnen worden onderzocht en lopend risico kan worden gemonitord.

Dit is gewone observability-discipline, maar dan met opzet toegepast. Hoe het er in de praktijk uitziet:

• Append-only, manipulatiebestendige audit logs van inferenties — verwijzing naar de input, modelversie, output, confidence of score, en een tijdstempel.
• Correlatie-ID's die één beslissing over uw services heen koppelen, zodat een onderzoek niet doodloopt op een servicegrens.
• Bewaartermijnen die passen bij de verwachte levensduur van het systeem en de relevante sectorregels — en die dataminimalisatie respecteren, dus u logt verwijzingen en hashes in plaats van ruwe persoonsgegevens op te potten.
• Monitoring en alertering op de gelogde signalen, wat later ook uw post-market verplichtingen voedt.

Heeft u productiesoftware met fatsoenlijke observability gedraaid, dan heeft u het meeste hiervan al. Het verschil onder de verordening is dat logging geen optionele finishing touch meer is — het is een wettelijke eis, en het ontwerp moet er rekening mee houden dat een auditor of toezichthouder die logs ooit kan lezen.

Artikel 13 en 14 — transparantie en menselijk toezicht

Deze twee artikelen gaan over de mensen rond het systeem, en hier raakt engineering het meest direct aan UX.

Artikel 13 — transparantie en gebruiksinstructies. Het systeem moet transparant genoeg zijn dat een gebruiksverantwoordelijke de output kan begrijpen en het systeem juist kan inzetten, en het moet met heldere gebruiksinstructies worden geleverd: de identiteit van de aanbieder, het beoogde doel, het nauwkeurigheidsniveau en de bekende beperkingen, de omstandigheden waarvoor het is ontworpen, en elk voorzienbaar misbruik. In de praktijk is dit een echt instructiedocument plus, waar het helpt, uitleg in het product — confidence-indicatoren, de factoren achter een beslissing, duidelijke waarschuwingen waar het model zwak is. "Het model zei het" is geen transparantie.

Artikel 14 — menselijk toezicht. Dit is een van de meest verkeerd begrepen eisen, dus de moeite waard om het ronduit te stellen: de eisen voor menselijk toezicht onder artikel 14 van de AI Act zijn een ontwerpverplichting, geen personeelsmemo. U voldoet er niet aan door "een mens beoordeelt de output" in een beleidsstuk te zetten. Het *systeem* moet zo zijn gebouwd dat de mensen die er toezicht op houden het ook echt kunnen begrijpen, monitoren, kunnen bepalen wanneer ze erop vertrouwen, kunnen ingrijpen of onderbreken, en de output kunnen overrulen of terugdraaien. Ontwerppraktijken die echt toezicht opleveren:

• Human-in-the-loop ijkpunten voor zwaarwegende beslissingen — het systeem adviseert, een mens beslist, en die beslissing wordt vastgelegd.
• Onzekerheid zichtbaar maken, zodat beoordelaars weten wanneer ze beter moeten opletten. Gekalibreerde confidence en het duidelijk markeren van randgevallen maken van een stempelmachine een echte review.
• Een werkend stop- en overrulepad — een onderbreekbare besturing die naar een veilige toestand terugkeert, getest zoals elke andere kritieke functie.
• Ontwerpen tegen automatiseringsbias: de interface mag mensen niet standaard naar de machine laten leunen.

Toezicht dat alleen op papier bestaat, is precies het faalpatroon waartegen de verordening is geschreven. Kan een beoordelaar een goede output niet van een slechte onderscheiden, dan heeft u de beslissing geautomatiseerd en dat toezicht genoemd. Dit is exact de human-in-the-loop UX die wij vanaf de eerste sprint inbouwen in generatieve AI en agentische systemen.

Artikel 15 — nauwkeurigheid, robuustheid en cybersecurity

Artikel 15 vereist dat het systeem een passend niveau van nauwkeurigheid, robuustheid en cybersecurity bereikt en consistent presteert gedurende zijn levenscyclus. De nauwkeurigheidsniveaus en de relevante metrieken moeten in de gebruiksinstructies worden vermeld, dus u kunt zich niet verschuilen achter een vaag "het werkt goed".

Elk van de drie heeft een concreet engineeringantwoord:

• Nauwkeurigheid — definieer de metrieken die voor uw taak tellen (precision en recall, F1, foutpercentage, wat ook past), meet ze op een held-out set die de werkelijke populatie weerspiegelt, en vermeld de cijfers. Een reproduceerbaar, van versie voorzien evaluatieharnas is het op te leveren product.
• Robuustheid — het systeem moet omgaan met fouten, storingen en inconsistenties, inclusief input waarop het niet is getraind. Test randgevallen en out-of-distribution data, voeg fallbacks toe voor output met lage confidence, en bouw redundantie in waar een storing schadelijk zou zijn. De verordening benoemt expliciet feedbackloops, dus waak voor een model dat verslechtert doordat het van zijn eigen output leert.
• Cybersecurity — verdedig tegen de AI-specifieke aanvallen die de verordening noemt: data poisoning (het corrumperen van trainingsdata), model poisoning, adversarial examples (input die het model bewust misleidt) en model evasion. Threat-model de ML-pijplijn net zo zorgvuldig als de applicatie eromheen.

En omdat artikel 15 consistentie *gedurende de levenscyclus* eist, hoort driftmonitoring hier ook thuis. Een model dat bij lancering nauwkeurig was en zes maanden later stilletjes is verouderd, is niet langer conform — en dat is de brug naar post-market monitoring.

Conformiteitsbeoordeling, CE-markering en post-market monitoring

Zodra het systeem volgens de specificatie is gebouwd, draaien de verplichtingen naar buiten — en dit is het deel waar de formele aftekening uit engineeringhanden gaat.

Conformiteitsbeoordeling is de procedure die bevestigt dat het systeem aan de eisen voldoet. Voor veel hoog-risicosystemen is dit een zelfbeoordeling door de aanbieder tegen de normen; voor sommige categorieën is een notified body — een onafhankelijke, officieel aangewezen beoordelaar — betrokken. Hoe dan ook steunt het op de documentatie van artikel 11 en het risicobewijs van artikel 9 dat u onderweg heeft opgebouwd. Zijn die artefacten op orde, dan is de beoordeling een review; zijn ze dat niet, dan is het paniek.

CE-markering is het zichtbare resultaat. Een hoog-risico AI-systeem dat de conformiteitsbeoordeling doorstaat, draagt een CE-markering en een EU-conformiteitsverklaring, en wordt (voor de meeste categorieën) geregistreerd in de EU-databank voor hoog-risicosystemen. De markering is een claim dat het systeem aan de verordening voldoet — en precies daarom moet het engineeringbewijs erachter echt zijn.

Post-market monitoring (artikel 72) is de verplichting dat het werk na de lancering doorgaat. U moet actief prestatiedata uit het veld verzamelen en beoordelen, wat direct steunt op uw logs uit artikel 12 en uw driftmonitoring uit artikel 15. Ernstige incidenten en storingen die grondrechtenverplichtingen schenden, moeten aan de autoriteiten worden gemeld, doorgaans zonder onnodige vertraging. Bouw de monitoring en het incidentpad vóórdat u live gaat, niet na het eerste incident.

Voor de duidelijkheid nogmaals: de notified body en uw juridisch adviseur zijn eigenaar van de formele aftekening. Crux bouwt het systeem en het bewijs zodat wat zij aftekenen werkelijk conform is.

Tijdlijn: wat moet klaar zijn in augustus 2026 en augustus 2027

De AI Act is in 2024 in werking getreden en de verplichtingen worden over meerdere jaren gefaseerd ingevoerd, niet in één keer. Twee data zijn voor hoog-risicobouwers het belangrijkst:

• Augustus 2026 — het hoofddeel van de hoog-risicoverplichtingen wordt van toepassing, voor de hoog-risicosystemen die onder bijlage III vallen (de lijst met use-cases: werkgelegenheid, essentiële diensten, biometrie, enzovoort). Bouwt u in een van die domeinen, dan is dit uw harde deadline.
• Augustus 2027 — de deadline voor hoog-risico AI die een veiligheidscomponent is van producten die al onder EU-productveiligheidswetgeving vallen (machines, medische hulpmiddelen en dergelijke). Die krijgen de langere aanloop omdat ze meeliften op bestaande conformiteitsregimes.

Behandel de eu ai act verplichtingen van augustus 2026 als de datum waarop de specificatie ophoudt vrijblijvend te zijn, niet als de datum om te beginnen. Een goed gebouwd hoog-risicosysteem — risicoregister, beheerde data, levende documentatie, echt toezicht — kost maanden om op te zetten, en naleving achteraf inbouwen in een systeem dat het negeerde, is veel duurder dan het meteen goed doen.

Er loopt ook een vereenvoudigingsdraad die kwalitatief het vermelden waard is. Eind 2025 opende de Commissie een "Digital Omnibus"-pakket dat erop gericht is delen van het digitale regelboek te verlichten, waaronder enkele AI Act-tijdlijnen en administratieve lasten, met aandacht voor kleinere aanbieders. De richting is minder wrijving op documentatie en fasering — maar de kern van de hoog-risico-eisen hierboven verdwijnt naar verwachting niet, en de data kunnen verschuiven. Bouw dus naar de specificatie en bevestig de actuele stand met een juridisch adviseur in plaats van op verlichting te gokken.

Hoe Crux Digits vanaf dag één AI-Act-klaar bouwt

De rode draad door elk artikel is dezelfde: de verordening beloont teams die naleving behandelen als een engineeringeigenschap van het systeem, niet als een document dat er achteraf op wordt geschroefd. Een beheerde datapijplijn, van versie voorziene evaluaties, audit-waardige logging, ingebouwd menselijk toezicht en doorlopende monitoring zijn op zichzelf al goede ML-engineering. De AI Act maakt ze simpelweg verplicht en vraagt u ze te bewijzen.

Crux Digits is een boutique, in de EU gevestigde AI-consultancy in Nederland, en wij bouwen standaard naar deze specificatie. Wij werken in projecten met vaste scope en transparante prijzen — een AI-audit en -strategie voor EUR 2.500 om in kaart te brengen waar u staat ten opzichte van de artikelen 9 tot en met 15, een Proof of Concept voor EUR 20.000 en een Production Launch vanaf EUR 50.000. U bent eigenaar van de modellen en de code die wij bouwen; er is geen vendor lock-in. Wij doen niet de juridische aftekening, en wij zeggen het u wanneer het tijd is om een notified body of jurist erbij te halen.

Bent u een hoog-risicosysteem aan het scopen en wilt u het meteen goed bouwen, dan is een goede volgende stap de nalevingschecklist om uzelf te beoordelen, de gids over transparantie onder artikel 50 als een van uw functies raakt aan een meldplicht, en daarna een gesprek. U bent welkom om een vrijblijvend adviesgesprek in te plannen — geen verplichtingen, gewoon een eerlijke inschatting van wat uw systeem nodig heeft om augustus-2026-klaar te zijn.

Veelgestelde vragen