Wat de EU AI Act voor je product stack betekent in 2026

Op 2 augustus 2026 gaat de EU AI Act echt spelen. Dat is de datum waarop verplichtingen voor risicovolle AI-systemen afdwingbaar worden in de hele EU. Voor de meeste Nederlandse oprichters en product teams is het antwoord tot nu toe een variant van: "we pakken dat later."

Later is nu zes maanden weg.

Het ongemakkelijke deel is niet de deadline zelf. Het is dat een groot aantal bedrijven dat AI gebruikt voor personeelsscreening, kredietbeslissingen of klantsegmentatie niet realiseert dat die systemen onder Annex III als risicovolle AI vallen. Ze gaan ervan uit dat risicovolle AI gaat over robots die chirurgie uitvoeren of zelfrijdende auto's. Dat klopt niet. Het gaat over je recruitmenttool die cv's rankt. Het gaat over de creditflow in je fintech stack die aanvragen goedkeurt of afwijst. Het gaat over het scoringmodel dat klanten indeelt voor aanbiedingen.

Als je zo'n systeem runt, of bouwt voor klanten die dat doen, gelden de verplichtingen voor jou.

Wat de Digital Omnibus verandert, en wat niet

Er is een wetgevingsvoorstel dat je moet kennen. De Digital Omnibus, die momenteel door het EU-proces gaat, bevat bepalingen die bepaalde AI Act-verplichtingen kunnen uitstellen of afzwakken. Sommige product teams zetten daar op in. Dat is een vergissing.

Zelf als de Digital Omnibus in een vorm aangenomen wordt die de timing verschuift, komt het niet op tijd opdat je daar met vertrouwen op kunt plannen. De parlementaire timeline is echt onzeker. Je compliance-houding baseren op een wetgevingsuitkomst die nog niet vaststaat is geen strategie. Het is uitstel dat zich als strategie voordoet.

Plan op 2 augustus 2026 als een vaste datum. Als de Omnibus je later extra ruimte geeft, wordt dat een bonus. Als dat niet gebeurt, ben je klaar.

Drie dingen die je in de tweede helft van 2025 moet doen

1. Map je stack tegen Annex III, voordat je iets anders doet

Annex III is de lijst die bepaalt wat als risicovolle AI geldt. Die dekt acht domeinen: werk en personeelsmanagement, toegang tot krediet, onderwijs, essentiële privé- en overheiddiensten, rechtshandhaving, migratie en grenscontrole, justitie en kritieke infrastructuur.

Je eerste taak is niet de hele wet doorlezen. Het is om samen met wie je AI-systemen aanstuurt aan tafel te gaan en die lijst door te nemen. Wees specifiek. "We gebruiken een AI-ondersteunde ATS" is niet genoeg. Welke beslissingen beïnvloedt het? Rankt, scoort of filtert het kandidaten zonder dat een mens de onderliggende logica controleert? Die vraag telt.

Voor Nederlandse MKB-bedrijven liggen de meeste risicopunten bij recruitmenttools (ATS-platforms, performancescoring), krediet- of verzekeringssystemen en klantsegmentatie in financiële producten. Begin daar. Een eenpager die elk systeem aan Annex III-categoriëen koppelt is een nuttige output. Het hoeft geen juridisch document te zijn. Het moet wel kloppen.

Het addertje onder het gras hier zijn third-party tools. Als je een out-of-the-box SaaS-product gebruikt dat de scoring of ranking doet, ben je nog steeds in scope als degene die het inzet. De compliance van de leverancier wordt niet automatisch de jouwe.

2. Conformiteitsverklaringen, technische documentatie en CE-markering voor risicovolle systemen

Zodra je weet welke systemen in scope vallen, eist de wet drie concrete dingen voordat je iets inzet:

Conformiteitsverklaring. Voor de meeste risicovolle systemen buiten een handvol kritieke sectoren kun je zelf beoordelen. Dat wil zeggen: een gestructureerd proces doorlopen om te verifiëren dat je systeem aan de eisen van de wet voldoet op het gebied van transparantie, datagovernance, nauwkeurigheid en menselijk toezicht. Het is niet simpelweg een afvinkje. Het kost tijd en interne coördinatie.

Technische documentatie. De wet geeft aan wat hier in moet staan: het beoogde gebruik van het systeem, de prestatiekentallen ervan, de trainingsgegevens die gebruikt zijn, bekende beperkingen en hoe menselijk toezicht is geïmplementeerd. Deze documentatie moet onderhouden en up-to-date gehouden worden. Als het systeem verandert, verandert de documentatie mee.

CE-markering. Risicovolle AI-systemen die op de EU-markt geplaatst worden hebben CE-markering nodig om conformiteit aan te tonen. Voor zelfgeëvalueerde systemen stel je een conformiteitsverklaring op en breng je de markering aan. Voor systemen in bepaalde gevoelige categorieën moet een aangestelde instantie betrokken zijn.

Het addertje. Documentatie die pas achteraf, vlak voor inspectie, opgesteld wordt ziet elke beoordelaar en is zwak in elk conflict. Schrijf het terwijl je bouwt of instelt, niet daarna.

3. Wijs een governance-persoon aan, niet een compliance-formulier

Hier gaan de meeste bedrijven het mis. Ze stellen een beleidsdocument op, slaan het ergens op en noemen het governance. Dat is geen governance. Dat is papierwerk.

De EU AI Act verwacht voortdurend menselijk toezicht op risicovolle systemen. Dat betekent dat iemand in je organisatie benoemde verantwoordelijkheid draagt om systeemgedrag te volgen, beslissingen die individuen raken te herzien, afwijkingen op te merken en alarm te slaan als iets mis lijkt te gaan. Bij een groot bedrijf kan dat een dedicated AI-officer zijn. Bij een Nederlands MKB of klein productteam is het eerder een bestaande rol met een gedefinieerde uitbreiding van scope.

Wat telt is dat de verantwoordelijkheid echt is, de persoon weet dat hij of zij die draagt, en er is een proces voor wat er gebeurt als iets ontspoor raakt. Een formulier doet dat niet. Een persoon met een mandaat wel.

Het addertje. maak dit niet puur een juridische of compliance-functie. De persoon die begrijpt hoe het systeem werkt moet erbij betrokken zijn. Dat is vaak een product manager of data lead, geen jurist.

Praktische checklist voor de komende 90 dagen

Dit is geen compleet compliance-programma. Het is het minimale bruikbare startpunt voor een oprichter of productleider die vooruit wil gaan zonder een leger consultants in te huren.

• Annex III audit. Noem elk AI-systeem dat je bedrijft of inzet. Koppel elk systeem aan de acht Annex III-domeinen. Markeer alles wat als risicovolle AI kan kwalificeren.
• Duidelijkheid over leverancier versus gebruiker. Voor elk tool: bepaal of je leverancier bent (je hebt het gebouwd of getraind) of gebruiker (je gebruikt een systeem van iemand anders). Je verplichtingen verschillen.
• Check datagovernance. Risicovolle systemen vereisen gedocumenteerde datagovernance. Voor elk in-scope systeem: kun je beschrijven welke gegevens gebruikt zijn, waar die vandaan kwamen en hoe bias beoordeeld werd? Zo niet, begin dat gesprek met je leverancier of datateam.
• Design menselijk toezicht. Voor elk risicovolle systeem schrijf je één paragraaf op waarin staat hoe een mens kan ingrijpen, overschakelen of het systeem stoppen. Kun je die paragraaf niet schrijven, is het toezicht niet echt.
• Governance-eigenaar. Noem de persoon. Schrijf het op. Vertel het ze.
• Startdatum documentatie. Kies een moment in de komende twee weken en begin met de technische documentatie voor je systeem met het hoogste risico. Wacht niet tot het compleet aanvoelt om te beginnen.

Niets hiervan vereist op dag één een juridisch contract. Het vereist ongeveer twee gerichte werkdagen en de juiste mensen in de kamer.

Waar Studio Hyra aansluit

We zijn geen advocatenkantoor. We vullen je conformiteitsverklaringen niet in en we geven geen juridische goedkeuring. Wat we doen is product en design teams helpen begrijpen welke van hun AI-systemen echt risico dragen, de governance rond die systemen op een manier structureren die operationeel realistisch is, en documentatie produceren die tussen de juridische eis en het echte product zit.

Voor Nederlandse MKB-bedrijven en kleine productteams is dat gat vaak het moeilijkste deel. De regelgeving was geschreven voor grote organisaties met aparte compliance-functies. Het vertalen naar iets waar een team van tien echt iets mee kan doen is een ander skill. Daar werken wij.

Als je je stack wilt doorspreken en wilt uitzoeken waar je echt staat, duurt dat gesprek een uur. Begin daar.