EU AI Act compliancechecklist: een 10-stappenplan

Een EU AI Act compliancechecklist is een gestructureerde reeks stappen waarmee u aan de verplichtingen van de verordening voldoet zonder iets over het hoofd te zien. In de praktijk komt het neer op tien dingen: inventariseer elk AI-systeem, bepaal per systeem de risicoklasse, stel technische documentatie op, breng uw trainings- en invoerdata op orde, ontwerp menselijk toezicht, wees transparant waar Artikel 50 dat eist, houd logbestanden bij, beoordeel uw leveranciers, monitor systemen na livegang en wijs duidelijk eigenaarschap toe met een vaste herzieningscyclus. De wet geldt in fasen — verboden toepassingen sinds februari 2025, regels voor generieke AI sinds augustus 2025 en de meeste hoog-risico verplichtingen vanaf augustus 2026 — dus het juiste startpunt is weten wat u heeft en waar elk systeem valt. Dit is algemene informatie, geen juridisch advies.

Waarom een checklist beter werkt dan de hele verordening lezen

De EU AI Act telt meer dan honderd artikelen en een flinke stapel bijlagen. Als u de hele tekst van voor naar achter probeert te lezen voordat u iets doet, loopt u vast of slaat de schrik u om het hart. Een checklist vertaalt de verordening naar een reeks beslissingen waar u echt mee aan de slag kunt, ongeveer in de volgorde die voor een implementeerder logisch is.

De wet is risicogebaseerd. Een spamfilter wordt niet hetzelfde behandeld als een AI-systeem dat sollicitaties scoort of patiënten triëert. Het zwaarste deel van de verplichtingen landt op een afgebakende set hoog-risico toepassingen en op generieke AI-modellen (general-purpose AI). Een groot deel van de alledaagse zakelijke AI valt in lichtere categorieën, waar de hoofdplicht eerlijke transparantie is. De hele kern van de stappen hieronder is om snel te bepalen in welke bak elk van uw systemen valt — zodat u uw inspanning steekt waar de wet die echt vraagt.

Eén kanttekening vooraf: dit is algemene informatie om het werk te ordenen, geen juridisch advies. Voor een bindende uitleg van hoe de wet op een specifiek systeem van toepassing is, wilt u een gekwalificeerd jurist inschakelen. Wat volgt is het perspectief van de implementeerder — het praktische werk dat hoe dan ook moet gebeuren, los van wie de juridische lezing aftekent.

De gefaseerde data waar u tegenaan werkt

Compliance is geen enkele deadline. De wet trad in augustus 2024 in werking en geldt in fasen, en dat is goed nieuws — het betekent dat u het werk kunt opdelen in plaats van alles tegelijk te doen.

• 2 februari 2025 — het verbod op verboden praktijken ging in (bijvoorbeeld social scoring en bepaalde manipulatieve of ongerichte gezichts-scraping). Draait u iets in de buurt hiervan, dan zou dat inmiddels uitgeschakeld moeten zijn.
• 2 augustus 2025 — de verplichtingen voor generieke AI (GPAI) modellen gingen in, samen met het governance- en boetekader. Bouwt u op foundation-modellen of biedt u er een aan, dan is dit nu actief.
• 2 augustus 2026 — het grootste deel van de hoog-risico verplichtingen wordt van kracht. Dit is de datum waar de meeste organisaties echt op plannen.
• 2 augustus 2027 — een verlengde overgangstermijn voor hoog-risico AI die is ingebouwd in producten die al onder andere EU-productveiligheidswetgeving vallen.

Behandel augustus 2026 als uw werkhorizon voor hoog-risico systemen. Alles wat u in stap twee als hoog-risico classificeert, moet dan zijn documentatie, toezicht en logging op orde hebben — en goede documentatie kost maanden, geen weken, om eerlijk samen te stellen.

Stap 1 — Inventariseer elk AI-systeem dat u bouwt, koopt of gebruikt

U kunt niet voldoen aan regels voor systemen die u niet hebt opgeschreven. Begin met een lijst van elk AI-systeem in de organisatie, inclusief de systemen die niemand "AI" noemt: de chatbot op de website, de cv-screeningtool bij HR, het vraagvoorspellingsmodel in operations, de fraudescoring-leverancier bij finance en de foundation-model-API die een ontwikkelaar vorig kwartaal even aansloot.

Leg per regel de basis vast: wat het systeem doet, wie de eigenaar is, of u het zelf hebt gebouwd of hebt ingekocht, welke data het raakt, en of de uitkomst de rechten, het geld, de veiligheid of de toegang tot een dienst van een persoon beïnvloedt. Die laatste kolom bepaalt de risicoclassificatie in stap twee.

• Neem ook shadow AI mee — tools die afzonderlijke teams hebben ingevoerd zonder centrale goedkeuring.
• Noteer per systeem welke rol u vervult: bent u de aanbieder (u bouwt of rebrandt het) of de gebruiksverantwoordelijke (u zet andermans systeem in)? De verplichtingen verschillen.
• Houd de inventarisatie op één levende plek bij, niet in een slide die de dag na het overleg al achterhaald is.

De meeste teams schrikken van hoe lang de lijst is. Die schrik betekent dat de inventarisatie zijn werk doet.

Stap 2 — Bepaal per systeem de risicoklasse

De wet deelt AI in vier categorieën in. Haal elk item uit uw inventarisatie er doorheen.

• Verboden — volledig verboden (social scoring, bepaalde biometrische en manipulatieve toepassingen). Belandt iets hier, stop dan met het gebruik.
• Hoog-risico — systemen die worden gebruikt in gebieden als werving en personeelsbeheer, onderwijs, essentiële private en publieke diensten, kritieke infrastructuur, rechtshandhaving, en als veiligheidscomponent van gereguleerde producten. Deze dragen de volledige verplichtingen: documentatie, datagovernance, menselijk toezicht, logging en meer.
• Beperkt risico — systemen die met mensen communiceren of content genereren. De plicht hier is transparantie onder Artikel 50 (zie stap zes).
• Minimaal risico — al het overige, zoals spamfilters of voorraadoptimalisatie. Geen specifieke verplichtingen, al blijven goede gewoonten gelden.

Wees eerlijk in deze stap. De verleiding is om alles naar minimaal risico te praten; de prijs van een verkeerde inschatting is een systeem dat controles nodig had en die nooit kreeg. Waar een geval echt op het randje zit — en dat geldt voor meerdere — verdient een gekwalificeerde juridische lezing precies daar zijn geld.

Stap 3 — Stel technische documentatie op: doel, data, beslissingen

Voor hoog-risico systemen verwacht de wet technische documentatie waarmee een redelijke beoordelaar begrijpt wat het systeem is, hoe het is gebouwd en waarom het zich gedraagt zoals het doet. Zie het als het permanente dossier van het systeem, opgesteld vóór livegang en daarna actueel gehouden.

Documenteer minimaal het beoogde doel en de gebruiksvoorwaarden; de data die is gebruikt voor training, validatie en testen, en waar die vandaan komt; de ontwerpkeuzes en modelarchitectuur; bekende beperkingen en voorzienbaar misbruik; de nauwkeurigheids- en prestatiecijfers die u hebt gemeten; en de maatregelen voor menselijk toezicht die u hebt ingebouwd.

• Schrijf het zo dat iemand die het niet zelf heeft gemaakt het kan volgen. Documentatie die maar één engineer begrijpt is een risico, geen bezit.
• Versiebeheer het samen met het model. Verandert het model, dan verandert het dossier.

In deze stap zit het meeste echte werk. Heeft u modellen gebouwd zonder dit op te schrijven — en veel teams hebben dat — dan is dat gat dichten de langste afzonderlijke taak op de checklist.

Stap 4 — Breng uw data en de kwaliteit ervan op orde

Hoog-risico systemen moeten worden gebouwd op data die relevant is, voldoende representatief, en zo vrij van fouten en hiaten als het gebruik toelaat. Slechte data is onder de wet niet alleen een prestatieprobleem — het is een complianceprobleem, omdat vertekende of niet-representatieve data leidt tot uitkomsten die de mensen schaden die het systeem raakt.

Het praktische werk hier: ken de herkomst van uw datasets; onderzoek ze op vertekening die relevant is voor de context (een wervingsmodel en een kredietmodel vragen om andere toetsing); leg de hiaten vast die u kent; en bepaal hoe data wordt verzameld, gelabeld en in de loop van de tijd ververst.

• Leg dit naast het AVG-werk dat u waarschijnlijk al hebt gedaan — de twee kaders overlappen sterk op persoonsgegevens.
• Behandel datagovernance als doorlopend werk, niet als een eenmalige opschoning vóór livegang.

Als uw datafundament wankel is, veranderen veel complianceprogramma's hier stilletjes in data-engineering-programma's. Dat is normaal — u kunt geen data besturen die u niet kunt herleiden.

Stap 5 — Ontwerp menselijk toezicht dat echt werkt

Hoog-risico systemen moeten zo zijn ontworpen dat een persoon er betekenisvol toezicht op kan houden — de uitkomst begrijpen, zien wanneer die fout is, en ingrijpen of overrulen. De wet is expliciet dat het toezicht echt moet zijn, geen formaliteit waarbij iemand honderd beslissingen per uur op "goedkeuren" klikt.

Ontwerpvragen die u moet beantwoorden: wie is per systeem de aangewezen toezichthouder, welke informatie ziet die persoon, kan hij of zij een beslissing stoppen of terugdraaien, en is die persoon getraind en uitgerust om dat ook echt te doen? Een beoordelaar die de redenering van het model niet kan begrijpen, houdt geen toezicht.

• Voorkom automatiseringsbias — bouw wrijving in waar een mens moet nadenken, niet alleen bevestigen.
• Maak het overrulen duidelijk en snel. Als overrulen lastig is, doen mensen het niet.

Goed toezicht is een ontwerpbeslissing die vroeg wordt genomen, geen vinkje dat vlak voor livegang wordt aangeschroefd.

Stap 6 — Transparantie en informatieplicht (Artikel 50)

Artikel 50 stelt transparantieverplichtingen die veel meer systemen raken dan de hoog-risico regels. Het principe is eenvoudig: mensen horen te weten wanneer ze met AI of met door AI gegenereerde content te maken hebben.

• Communiceert iemand met een AI-systeem zoals een chatbot, vertel het dan — tenzij het uit de context al duidelijk is.
• Genereert of bewerkt u beeld, audio of video (inclusief deepfakes), label het dan als kunstmatig gegenereerd of gemanipuleerd.
• Door AI gegenereerde tekst die het publiek informeert over zaken van algemeen belang moet als zodanig kenbaar worden gemaakt.
• Systemen voor emotieherkenning en biometrische categorisering moeten de blootgestelde personen informeren.

Deze verplichtingen gelden breed, zelfs voor systemen die u in stap twee als beperkt risico hebt geclassificeerd. Voor de meeste organisaties is de praktische actie een korte audit van elk klantgericht AI-contactpunt en een heldere, begrijpelijke melding op elk daarvan. Het kost weinig moeite en is zeer zichtbaar — zowel toezichthouders als klanten merken het als het ontbreekt.

Stap 7 — Logging en registratie

Hoog-risico systemen moeten gebeurtenissen automatisch vastleggen — logbestanden — gedurende hun hele levensduur, zodat incidenten te herleiden zijn en gedrag achteraf te reconstrueren is. Logging is wat "het model deed vorige dinsdag iets vreemds" verandert in een antwoord waar u achter kunt staan.

Bepaal vroeg wat elk systeem logt, waar de logbestanden worden bewaard, hoe lang u ze bewaart en wie ze mag inzien. De bewaartermijn moet passen bij het doel van het systeem en bij uw overige wettelijke verplichtingen.

• Log genoeg om een beslissing te reconstrueren: invoer, modelversie, uitkomst en de genomen menselijke actie.
• Bescherm de logbestanden zelf — ze bevatten vaak persoonsgegevens en vallen onder de AVG.

Logging is goedkoop om vooraf in te bouwen en pijnlijk om achteraf in te bouwen. Behandel het als onderdeel van het systeem, niet als toevoeging.

Stap 8 — Due diligence op leveranciers en toeleveranciers

De meeste organisaties zijn gebruiksverantwoordelijke, geen bouwer — u koopt meer AI dan u maakt. De wet laat u verantwoordelijkheid niet uitbesteden door een contract te tekenen. Zet u een hoog-risico systeem in, dan draagt u de verplichtingen van de gebruiksverantwoordelijke, ongeacht wie het heeft gebouwd.

Beoordeel dus uw leveranciers. Vraag of hun systeem als hoog-risico is geclassificeerd, of ze de technische documentatie en gebruiksaanwijzing leveren die u nodig heeft, hoe ze met data omgaan, en wat ze toezeggen op het gebied van monitoring en incidentmelding. Bouw deze antwoorden in contracten en verlengingen in.

• Bewaar bewijs van de due diligence — een opgeslagen ingevulde vragenlijst is meer waard dan een mondelinge toezegging.
• Controleer opnieuw wanneer een leverancier zijn model wezenlijk bijwerkt; hun classificatie of garanties kunnen verschuiven.

Kan een belangrijke leverancier geen basisvragen beantwoorden over hoe hun model is gebouwd of bestuurd, dan is die stilte zelf een bevinding waar u op moet handelen.

Stap 9 — Monitor en handel incidenten af na livegang

Compliance stopt niet bij livegang. Hoog-risico systemen vereisen monitoring na het in de handel brengen — u kijkt hoe het systeem zich in de echte wereld gedraagt en grijpt in als de prestaties afdwalen of er schade ontstaat. Modellen verouderen naarmate de wereld om hen heen verandert, en een systeem dat bij livegang nauwkeurig was, kan een jaar later ongemerkt oneerlijk worden.

Zet de monitoring op: volg de cijfers die ertoe doen, definieer hoe "buiten de marges" eruitziet, en bepaal vooraf wie wordt gewaarschuwd en wat die persoon doet. Ernstige incidenten en storingen die verplichtingen rond grondrechten schenden, kennen meldplichten — ken uw meldroute voordat u die nodig heeft.

• Definieer drempelwaarden die een herziening starten, niet alleen dashboards die niemand leest.
• Schrijf een kort incident-draaiboek: detecteren, indammen, melden, herstellen, vastleggen.

Dit is de stap die de meeste teams onderschatten. Een POC of pilot bewijst eenmalig dat een model werkt; monitoring is wat het compliant houdt voor de jaren dat het in productie draait.

Stap 10 — Wijs eigenaarschap toe en stel een herzieningscyclus in

Een checklist zonder eigenaar verloopt op het moment dat het project dat hem opleverde eindigt. Wijs een verantwoordelijk eigenaar aan voor AI Act-compliance — vaak één persoon die juridisch, data en engineering coördineert — en geef ook elk systeem een eigen aangewezen eigenaar.

Stel daarna een ritme in. Voer de inventarisatie opnieuw uit en controleer de classificaties op een vast schema (per kwartaal is een verstandige standaard), en telkens wanneer u een nieuw systeem lanceert of een bestaand systeem wezenlijk wijzigt. Er ontstaan voortdurend nieuwe toepassingen; de inventarisatie uit stap één is alleen nuttig als hij levend blijft.

• Zet de compliance-herziening in de agenda, niet in iemands goede voornemens.
• Koppel het aan uw bestaande governance — risicocommissies, change management, inkooppoorten.

Goed uitgevoerd is deze laatste stap wat een eenmalige rush verandert in een proces dat u stilletjes compliant houdt naarmate de latere deadlines van de wet aanbreken.

Waar Crux Digits van pas komt

Het grootste deel van deze checklist is organisatorisch werk dat u zelf kunt leiden. Waar teams meestal vastlopen, is bij de stappen twee tot en met vier — systemen eerlijk classificeren, technische documentatie schrijven die standhoudt, en datagovernance op orde krijgen — omdat die raken aan hoe de modellen daadwerkelijk zijn gebouwd.

Dat is het soort werk dat Crux Digits als project met vaste scope doet. Onze AI Audit & Strategie (EUR 2.500, vast) is een praktische manier om de inventarisatie, de risicoclassificatie en een geprioriteerde gappenlijst in één afgebakend stuk werk af te ronden, met concrete vervolgstappen in plaats van een vaag retainer. Brengt de audit echte engineering-tekorten aan het licht — ongedocumenteerde modellen, niet-herleidbare data — dan kunnen we de bouw scopen om die te dichten.

We zijn een boutique AI-bureau in Nieuwegein, in de provincie Utrecht, en werken met klanten in heel Nederland en Europa. Wilt u richting over waar uw AI onder de wet valt en wat u eerst moet doen, dan is een vrijblijvend gesprek de makkelijkste plek om te beginnen. Voor het Nederlandse beeld gaat onze gids over EU AI Act-compliance in Nederland dieper, en onze pagina over AI-consultancy legt uit hoe we werken. Niets hiervan vervangt juridisch advies — maar het vertelt u wel concreet wat u als eerste moet aanpakken.

Veelgestelde vragen