EU AI Act: wie maakt uw AI eigenlijk compliant?

Om EU AI Act-compliant te worden hebben de meeste bedrijven drie verschillende rollen nodig, niet één. Uw juridisch adviseur of functionaris voor gegevensbescherming legt de wet uit en vertelt u welke verplichtingen gelden en waar uw juridische risico zit. Een notified body of conformiteitsauditor (zoals TÜV, SGS of BSI) beoordeelt en certificeert hoog-risicosystemen onafhankelijk. De implementatiepartner bouwt het systeem dat aan de eisen voldoet: artikel 10-datagovernance, artikel 11-technische documentatie, artikel 14-UX voor menselijk toezicht, logging en monitoring. Een jurist of auditor kan u vertellen wat de wet eist en of u slaagt; geen van beiden kan het compliant systeem bouwen, en compliance achteraf aanbouwen na een mislukte audit kost veel meer dan het vanaf dag één inbouwen. Dit is algemene informatie, geen juridisch advies.

De vraag die elk bedrijf nu stelt

Als uw bedrijf een AI-systeem draait dat mogelijk onder de EU AI Act valt, is de eerste vraag zelden "hoe bouwen we het." Die vraag is "wie bellen we." Een advocaat? Een auditor? Een adviesbureau? De marketing is luid en de rollen lopen door elkaar, en het eerlijke antwoord is dat u vrijwel zeker meer dan één van hen nodig hebt, maar voor verschillende dingen en op verschillende momenten.

Dit artikel is een vergelijking, geen stappenplan. Wilt u de uitleg artikel voor artikel vanuit de techniek, dan is dat de aparte implementatiegids voor hoog-risicosystemen. Hier is het doel smaller en praktischer: de drie rollen scheiden die betrokken zijn bij het compliant krijgen van een AI-systeem, laten zien wat elk wel en niet kan, en uitleggen waarom de volgorde waarin u ze inschakelt bepaalt hoeveel het geheel kost.

Eén voorbehoud vooraf, en we herhalen het omdat het ertoe doet: dit is algemene informatie, geen juridisch advies. Crux Digits is een implementatiepartner, wij bouwen AI-systemen. Wij zijn geen advocatenkantoor en geen notified body, en een deel van nuttig zijn is helder zijn over waar onze rol ophoudt en die van een ander begint.

De drie rollen, netjes uit elkaar gehouden

Naleving van de EU AI Act is geen enkele taak. Het zijn drie taken die makkelijk te verwarren zijn omdat ze allemaal het woord "compliance" gebruiken. Ze uit elkaar houden is het nuttigste dat u kunt doen voordat u geld uitgeeft.

1. Juridisch adviseur of uw functionaris voor gegevensbescherming, legt de wet uit. Dit is de persoon die de verordening leest en u vertelt wat die betekent voor *uw* situatie. In welke risicocategorie valt uw systeem? Is bijlage III van toepassing? Bent u aanbieder of gebruiksverantwoordelijke? Wat is uw blootstelling als u het fout doet, en wat betekent de overlap met de AVG voor uw gegevens? Een adviseur vertaalt een verordening van meer dan honderd artikelen naar een lijst verplichtingen die op u van toepassing is, en draagt het oordeel over juridisch risico. Hij adviseert; hij bouwt niet, en in de meeste gevallen certificeert hij niet.

2. Notified body of conformiteitsauditor, beoordeelt en certificeert onafhankelijk. Voor bepaalde hoog-risicosystemen vereist de wet een onafhankelijke conformiteitsbeoordeling door een aangewezen notified body, het soort organisatie dat u kent van de CE-markering op fysieke producten, zoals TÜV, SGS of BSI. Zij toetsen uw systeem en het bewijs daarvan aan de eisen en ondersteunen, als het slaagt, het pad naar een CE-markering en een EU-conformiteitsverklaring. Hun onafhankelijkheid is het hele punt: zij mogen niet ook degenen zijn die het ding gebouwd hebben, want dan zou de beoordeling niet onafhankelijk zijn.

3. De implementatie- of engineeringpartner, bouwt het systeem daadwerkelijk. Dit is de rol die het werk doet dat de andere twee beschrijven. Artikel 10-datagovernance ontstaat niet doordat een jurist het opschreef, iemand moet de bestuurde, geversioneerde, op bias gecontroleerde datapijplijn bouwen. Artikel 11-technische documentatie verschijnt niet doordat een auditor erom vroeg, die wordt gegenereerd terwijl het systeem gebouwd wordt. Artikel 14-menselijk toezicht is geen beleidszin, het is UX met de mens in de beslislus die een engineeringteam ontwerpt en oplevert. Dit is compliant-by-build: het systeem wordt vanaf de eerste sprint gebouwd om aan de eisen te voldoen, zodat het juridisch advies en de audit iets echts hebben om naar te wijzen.

Samengelezen is het patroon helder. De adviseur zegt *wat* de wet vereist. De notified body zegt *of u slaagt*. De implementatiepartner maakt het systeem dat daadwerkelijk *doet* waar de eerste twee het over hebben.

Er is een vierde rol die het waard is te benoemen, zodat u er niet te veel voor betaalt: een algemeen managementadviesbureau dat een strategiedeck oplevert. Een deck is geen compliant systeem, geen juridisch oordeel en geen certificaat, het is een mening over wie van de andere drie u zou moeten inhuren. Voor de meeste bedrijven met een concreet AI-systeem dat al loopt is de deck-fase iets dat u kunt overslaan. Die zaak beargumenteren we uitgebreid in boutique versus Big Four AI-adviesbureau, dat gaat over de *omvang en stijl* van een adviesbureau in plaats van de juridisch-versus-bouwen-vraag van hier.

Een uitgewerkt voorbeeld: het hoog-risico wervingsmodel

Concreet is helderder dan abstract, dus neem een veelvoorkomend geval: een bedrijf dat een AI-tool bouwt die sollicitanten screent en rangschikt. AI die wordt gebruikt bij werving en personeelsbeheer is een vastgelegd hoog-risicogebruik onder bijlage III, wat betekent dat de zware verplichtingen gelden, en het is een goede toets voor wie wat doet.

Het deel van de adviseur. Uw jurist of functionaris voor gegevensbescherming bevestigt dat het systeem hoog-risico is, stelt vast dat u zowel *aanbieder* bent (u bouwt het) als *gebruiksverantwoordelijke* (u zet het in op uw eigen werving), en wijst op de overlap met de AVG omdat u persoonsgegevens van kandidaten verwerkt. Hij vertelt u dat de representativiteit uit artikel 10, het menselijk toezicht uit artikel 14 en de transparantie uit artikel 13 hier allemaal hard bijten, en adviseert over de informatieplicht die u tegenover kandidaten hebt. Wat hij u overhandigt is een heldere set verplichtingen, en niets dat ook maar één cv screent.

Het deel van de implementatiepartner. Iemand moet die verplichtingen nu echt maken. Dat betekent een geversioneerde trainingsdataset met een gedocumenteerd herkomstspoor; evaluatiemetrieken uitgesplitst naar geslacht, leeftijdscategorie en andere relevante groepen, zodat bias gemeten wordt in plaats van aangenomen; een interface voor de recruiter die toont waarom een kandidaat is gerangschikt waar die staat en die een mens de rangschikking laat overrulen; auditlogs van elke beslissing; en de technische documentatie uit bijlage IV die wordt samengesteld terwijl het systeem gebouwd wordt. Dit is het leeuwendeel van het werk, en het is engineering.

Het deel van de notified body. Waar beoordeling door een derde partij vereist is, toetst de auditor dat afgebouwde systeem en het bewijs daarvan en beslist of het aan de eisen voldoet, en ondersteunt vervolgens de CE-markering en de conformiteitsverklaring. Als de datagovernance en de documentatie ingebouwd waren, is dit een gestructureerde toetsing. Was dat niet zo, dan is dit het moment waarop het bedrijf ontdekt dat het opnieuw moet trainen op opnieuw verworven data, de duurste zin uit dit hele artikel.

Drie rollen, één systeem, en slechts één ervan raakt ooit de code aan. Verwart u ze, dan betaalt u óf een jurist om engineering te doen die hij niet kan doen, óf u ontmoet de auditor zonder iets echts om te beoordelen.

De vergelijking: rol voor rol

Hier staat hetzelfde beeld naast elkaar, want bij de onderscheiden worden beslissingen genomen en wordt geld verspild.

Juridisch adviseur / functionaris voor gegevensbescherming

• Wat zij doen: de verordening uitleggen, uw risicocategorie bepalen, verplichtingen koppelen aan uw bedrijf, adviseren over juridisch risico en de overlap met de AVG, contracten en informatieplichten toetsen.
• Wat zij niet kunnen: de datapijplijn bouwen, de technische documentatie schrijven, de toezichts-UX ontwerpen, of (meestal) de formele certificering afgeven.
• Wanneer u ze nodig hebt: helemaal aan het begin, om te weten óf en hóe de wet van toepassing is, en opnieuw vóór de lancering, om de juridische positie af te tekenen.

Notified body / conformiteitsauditor (TÜV, SGS, BSI)

• Wat zij doen: een hoog-risicosysteem onafhankelijk toetsen aan de eisen, het bewijs verifiëren, en de CE-markering en de conformiteitsverklaring ondersteunen.

• Wat zij niet kunnen: het systeem voor u bouwen of repareren, hun onafhankelijkheid verbiedt dat, en zij adviseren doorgaans niet over uw bredere juridische strategie.
• Wanneer u ze nodig hebt: voor hoog-risicosystemen die beoordeling door een derde partij vereisen, tegen het einde van de bouw, zodra er bewijs is om te beoordelen.

Implementatie- / engineeringpartner (compliant-by-build)

• Wat zij doen: het systeem bouwen om aan de specificatie te voldoen, bestuurde data (art. 10), technische documentatie (art. 11), gebeurtenislogging (art. 12), transparantie en UX voor menselijk toezicht (art. 13-14), nauwkeurigheid, robuustheid en monitoring (art. 15), en het bewijsspoor dat dit alles onderbouwt.
• Wat zij niet kunnen: u juridisch advies geven of een onafhankelijke certificering afgeven, beide zou de scheiding van rollen ondermijnen.
• Wanneer u ze nodig hebt: vanaf dag één van het bouwen of herstellen, naast uw adviseur en (waar vereist) uw notified body.

Merk op dat geen enkele kolom de hele tabel dekt. Dat is het punt, en het is waarom "we hebben een advocatenkantoor ingehuurd" of "we zijn door een audit gekomen" elk maar een derde van het antwoord zijn.

Waarom een jurist of auditor uw AI niet compliant kan maken

Dit is de kern, en die is het waard botweg te stellen: een advocatenkantoor en een notified body kunnen u vertellen wat de wet vereist en of u slaagt, maar geen van beiden kan het compliant systeem bouwen. Dat is geen kritiek op een van beide beroepen. Het is hun rol die werkt zoals bedoeld.

Een jurist kan u een memo schrijven met de tekst "uw wervingsmodel is hoog-risico, dus onder artikel 10 moet uw trainingsdata representatief en op bias gecontroleerd zijn, en onder artikel 14 moet een mens de beslissingen kunnen overrulen." Die memo is oprecht waardevol. Maar het is een specificatie, geen systeem. Iemand moet nog steeds de evaluatiemetrieken naar demografische groep uitsplitsen, de datasets versioneren, de beoordelaarsinterface bouwen die onzekerheid toont, en het stoppen-en-overrulen-pad inbouwen. De jurist doet dat niet, en zou dat ook niet beweren.

Een notified body heeft dezelfde grens vanaf de andere kant. Hun taak is naar een afgebouwd systeem kijken en het beoordelen aan de eisen. Zakt het, dan vertellen ze u dat het zakt, ze blijven niet om het te repareren, want op het moment dat ze dat deden konden ze het niet langer onafhankelijk beoordelen. Een audit is een oordeel, geen bouw.

Schakelt u dus alleen een adviseur en alleen een auditor in, dan blijft u zitten met de feitelijke engineering, het deel waar compliance óf echt is óf niet. Iemand moet de verplichtingen vertalen naar een werkend systeem. De enige vraag is of die iemand het bewust inbouwt, of dat u het gat ontdekt wanneer de audit rood terugkomt.

Compliant-by-build versus de dure retrofit

Er zijn twee manieren om bij een compliant hoog-risico AI-systeem uit te komen. U kunt het vanaf het begin op de specificatie bouwen, of u kunt bouwen wat het snelst oplevert en vervolgens proberen compliance achteraf aan te bouwen nadat een jurist of auditor de gaten signaleert. Het eerste is compliant-by-build. Het tweede is de retrofit, en dat is bijna altijd het duurdere pad.

De reden is structureel, geen verkooppraatje. Verschillende kerneisen van de wet zijn geen functies die u later kunt toevoegen, het zijn eigenschappen van hoe het systeem gebouwd is:

• Artikel 10 (datagovernance). Trainde u op data zonder herkomstspoor en zonder controles op representativiteit, dan kunt u dat achteraf niet documenteren. U moet de data mogelijk opnieuw verwerven en opnieuw trainen, het duurste op deze lijst.
• Artikel 11 (technische documentatie). Zes maanden aan ontwerp- en databeslissingen uit het geheugen reconstrueren in de week vóór een beoordeling is traag, onvolledig en precies de paniek die auditors het vaakst zien. Ingebouwd is de documentatie een bijproduct; achteraf aangebouwd is het archeologie.
• Artikel 12 (logging). Was logging op auditniveau en met manipulatiedetectie niet ingebouwd, dan hebt u geen verslag van wat het systeem deed vóór vandaag, en dat kunt u niet met terugwerkende kracht maken.
• Artikel 14 (menselijk toezicht). Echt toezicht is UX die door het product heen geweven zit. Het achteraf aanbouwen betekent meestal het herontwerpen van kernflows, niet het toevoegen van een vinkje.

Elk hiervan is goedkoper als ontwerpbeslissing dan als hersteltraject. Een herkomstspoor voor data inbouwen kost een fractie van het later opnieuw verwerven van data. Toezichts-UX vooraf ontwerpen kost een fractie van het herwerken van een al opgeleverd product. De retrofit draagt ook een verborgen kost die de bouw niet heeft: het risico op vertraging van de time-to-market. Een rode audit vlak voor een deadline kan een lancering volledig stilleggen, en die vertraging overtreft vaak de engineeringrekening.

Compliant-by-build is ook op eigen merites betere engineering. Bestuurde data, geversioneerde evaluaties, echte logging en ingebouwd toezicht maken een betrouwbaarder, beter te debuggen systeem, of een toezichthouder er nu ooit naar kijkt of niet. De wet maakt ze simpelweg verplicht en vraagt u ze te bewijzen.

Hoe de drie rollen samenwerken

Deze rollen zijn geen rivalen, een goed geleid compliancetraject zet alle drie in volgorde in, en ze dragen aan elkaar over. De volgorde doet er evenveel toe als de bezetting.

Begin bij de adviseur. Voordat u iets bouwt of koopt, krijg een juridische lezing van óf de wet van toepassing is en in welke risicocategorie. Uw systeem verkeerd indelen is de duurste vroege fout: zware hoog-risicomaatregelen inbouwen in een systeem dat eigenlijk beperkt risico is verspilt geld, en andersom laat u blootgesteld. Onze gids over of mijn AI-systeem hoog-risico is en de compliance-checklist zijn nuttige startpunten voor zelfbeoordeling, maar de formele indelingsbeslissing hoort bij een adviseur.

Schakel de implementatiepartner vroeg in, niet na de audit. Zodra u de verplichtingen kent, zou de engineering met die verplichtingen in scope moeten beginnen. Hier betaalt compliant-by-build zich terug: de partner bouwt de datagovernance, de documentatie, de toezichts-UX en het bewijsspoor in de pas met het product, zodat er iets echts is voor de auditor om te beoordelen. Goed gedaan spreekt de partner ook beide talen, hij vertaalt de verplichtingen van de jurist naar engineeringtaken, en produceert de artefacten waar de notified body om zal vragen.

Betrek de notified body wanneer er iets is om te beoordelen. Voor hoog-risicosystemen die beoordeling door een derde partij vereisen, komt de auditor tegen het einde, zodra het systeem en het bewijs daarvan bestaan. Deden de eerste twee rollen hun werk, dan is de beoordeling een toetsing van goed georganiseerd bewijs in plaats van een zoektocht naar ontbrekende stukken. Hoe deze stukken specifiek in Nederland in elkaar passen behandelen we in ons overzicht EU AI Act-compliance in Nederland.

De faalmodus is dit in de verkeerde volgorde doen: het systeem bouwen zonder compliance in gedachten, laat een juridische memo krijgen, en de auditor koud ontmoeten. Dat is de volgorde die uitmondt in een retrofit.

Waar Crux Digits past, en waar niet

Crux Digits is de implementatiepartner in dit beeld. Wij zijn een boutique AI-adviesbureau in Nederland, gevestigd in de EU, en wij bouwen AI-systemen die standaard AI-Act-klaar zijn, bestuurde data, evaluaties met versiestempel, logging op auditniveau, ingebouwd menselijk toezicht, en de technische documentatie die dat onderbouwt. Wij werken naast uw adviseur en, waar vereist, uw notified body, niet in hun plaats.

We zijn expliciet over de grens: wij zijn geen advocatenkantoor en geen notified body. Wij leggen de verordening niet uit als juridisch advies en wij geven geen conformiteitscertificeringen af. Wat we wél doen is de verplichtingen die uw adviseur vaststelt omzetten in een werkend, verdedigbaar systeem, en u eerlijk vertellen wanneer het tijd is om een jurist of auditor erbij te halen.

Hoe we werken doet hier ook toe. Crux draait projecten met vaste scope en transparante prijzen, geen open-einde retainers: een AI-audit en strategie van EUR 2.500 om in kaart te brengen waar uw systeem staat ten opzichte van de wet, een proof of concept van EUR 20.000, en een productielancering vanaf EUR 50.000. U bent eigenaar van de modellen en code die wij bouwen, geen lock-in. Veel van dit werk landt in onze praktijk voor generatieve AI en data, waar menselijk toezicht en bestuurde data deel zijn van de bouw, geen bijzaak.

Weegt u af wie u eerst moet bellen, dan is de eerlijke volgorde: een juridische lezing over de indeling, dan een bouwpartner die compliance vanaf het ontwerp inbouwt, dan een auditor wanneer er iets is om te beoordelen. Wilt u een openhartige, vrijblijvende lezing van wie van die drie u feitelijk nodig hebt voor uw systeem, dan bent u welkom om een gratis adviesgesprek te boeken.

Veelgestelde vragen