EU AI-verordening: compliance-engineering voor documentatie, logging, toezicht en datagovernance

Het meeste wat over de EU AI-verordening is geschreven gaat over reikwijdte: in welke risicocategorie u valt, of u aanbieder bent of gebruiksverantwoordelijke, of uw systeem onder bijlage III valt. Die vraag beantwoorden uw juristen.

Wat vrijwel niemand behandelt, is wat er ná dat antwoord gebeurt. Is uw systeem hoogrisico, dan vraagt de verordening om een risicobeheersysteem dat de hele levenscyclus meeloopt, om datagovernance die u kunt aantonen, om automatische logging met een vastgelegde bewaartermijn, om technische documentatie in een voorgeschreven structuur, om menselijk toezicht dat ontworpen is in plaats van beweerd, en om monitoring na het in de handel brengen die daadwerkelijk iets ophaalt. Dat zijn engineeringresultaten. Dat deel bouwen wij.

Waar de termijnen nu staan

De AI-verordening (Verordening (EU) 2024/1689) is in augustus 2024 in werking getreden en wordt gefaseerd van toepassing. Die fasering is in 2026 gewijzigd, en het loont om precies te zijn, want die wijziging heeft geld en aandacht verplaatst.

• 2 februari 2025: de verboden praktijken en de verplichtingen rond AI-geletterdheid zijn van toepassing geworden.
• 2 augustus 2025: de verplichtingen voor AI-modellen voor algemene doeleinden zijn van toepassing geworden.
• 2 augustus 2026: de transparantieverplichtingen uit artikel 50 zijn van toepassing geworden: kenbaar maken dat een gebruiker met een AI-systeem te maken heeft, markering van synthetische content, kenbaar maken van emotieherkenning en biometrische categorisering, en het labelen van deepfakes.
• 2 december 2027: de hoogrisicoverplichtingen voor zelfstandige systemen, na de Digital Omnibus. Raad en Parlement bereikten in mei 2026 overeenstemming over het uitstel; de definitieve bekrachtiging volgde in juni 2026.
• 2 augustus 2028: de hoogrisicoverplichtingen voor AI-systemen die in gereguleerde producten zijn ingebouwd.

Bent u aanbieder van een hoogrisicosysteem, dan heeft het uitstel u ruwweg zestien maanden opgeleverd. Het heeft het werk niet verkleind, en het heeft de twee verplichtingen die al gelden niet verschoven: transparantie onder artikel 50, en AI-geletterdheid voor de medewerkers die deze systemen bedienen.

Wat wij bouwen

Technische documentatie als gegenereerd artefact

Bijlage IV schrijft voor wat de technische documentatie moet bevatten: systeembeschrijving, ontwerpkeuzes, architectuur, data-eisen, trainingsmethodiek waar die van toepassing is, validatie- en testprocedures, metrieken, risicobeheersmaatregelen, en de wijzigingen die over de levenscyclus zijn doorgevoerd.

Met de hand geschreven is dat document de week na ondertekening al achterhaald. Wij bouwen het als iets dat uw pipeline oplevert: modelkaarten en datasheets die uit de trainings- en evaluatieruns komen, architectuur- en datastroombeschrijvingen die naast de code worden onderhouden, evaluatieresultaten die aan de versie hangen die ze beschrijven, en een wijzigingshistorie die uit uw versiebeheer komt in plaats van uit iemands geheugen. Het document wordt een buildresultaat.

Automatische logging die aan artikel 12 voldoet

Hoogrisicosystemen moeten gedurende hun levensduur automatisch loggen, op een niveau dat traceerbaarheid van de werking en monitoring na het in de handel brengen mogelijk maakt, met een bewaartermijn die past bij het doel, en in bepaalde gevallen ten minste zes maanden.

In de praktijk betekent dat: bepalen wat een "gebeurtenis" is voor uw systeem, invoer, uitvoer, modelversie, beslispad en de identiteit van de betrokken mens vastleggen, dat opslaan in een vorm die jaren later nog doorzoekbaar is, en dat doen zonder persoonsgegevens op te stapelen waarvoor u geen grondslag hebt. Die spanning (genoeg loggen voor de AI-verordening, weinig genoeg bewaren voor de AVG) is het eigenlijke ontwerpvraagstuk, en dat werken wij expliciet door met uw privacymensen.

Datagovernance onder artikel 10

Trainings-, validatie- en testdatasets moeten relevant zijn, voldoende representatief, en voor zover mogelijk foutenvrij en volledig, met onderzoek naar bias. Daaraan voldoen betekent: datalineage die u kunt tonen, gedocumenteerde herkomst, een biasbeoordelingsmethodiek met resultaten, en het vermogen te reproduceren welke data welke modelversie heeft opgeleverd.

Wij bouwen de pipeline die zulke uitspraken controleerbaar maakt in plaats van aspirationeel: geversioneerde datasets, reproduceerbare splits, geautomatiseerde datakwaliteitscontroles, en biasevaluatie op de beschermde kenmerken die voor uw toepassing relevant zijn.

Menselijk toezicht, gebouwd in plaats van verklaard

Artikel 14 vereist dat hoogrisicosystemen zo zijn ontworpen dat een mens de uitkomst kan begrijpen, alert blijft op automation bias, het resultaat juist kan interpreteren, kan besluiten het niet te gebruiken, en kan ingrijpen of het systeem kan stoppen.

Dat is een specificatie voor de gebruikersinterface. Wij bouwen dat toezicht in het product: betrouwbaarheid en onzekerheid die eerlijk worden getoond, de factoren achter een uitkomst zichtbaar gemaakt, een override die net zo makkelijk is als accepteren, een stopknop die werkt, en logging van elke override zodat de monitoring daarna iets te leren heeft.

Monitoring na het in de handel brengen en incidentmelding

Een monitoringplan is verplicht, en ernstige incidenten moeten bij de bevoegde autoriteit worden gemeld. Wij bouwen de telemetrie die dat voedt: prestaties gemeten tegen de metrieken uit uw documentatie, driftdetectie op invoer en uitvoer, een kanaal voor door gebruikers gemelde problemen dat de engineering ook echt bereikt, en een incidentproces waarin de meldtermijnen zijn ingebouwd in plaats van dat ze tijdens een incident worden ontdekt.

Transparantieverplichtingen onder artikel 50

Die gelden al. Kenbaar maken dat een gebruiker met een AI-systeem te maken heeft, machineleesbare markering van synthetische audio, beeld, video en tekst, het labelen van deepfakes, en het kenbaar maken van emotieherkenning. Wij bouwen de kenbaarmakingsvlakken en de herkomstmarkering van content (C2PA content credentials waar dat het juiste mechanisme is), en zorgen dat ze de export- en hercodeerpaden overleven die ze doorgaans wegpoetsen.

Ondersteuning bij registratie en conformiteit

Hoogrisicosystemen op de gebieden van bijlage III moeten vóór het in de handel brengen worden geregistreerd in de EU-databank, en aanbieders moeten een conformiteitsbeoordeling doorlopen. Wij bereiden de technische input voor (de documentatie, het bewijsdossier, de artefacten van het kwaliteitsmanagementsysteem aan de engineeringkant), en werken samen met uw aangemelde instantie of uw interne beoordelingsproces.

Wat dit niet is

Wij geven geen juridisch advies, en wij bepalen niet in welke risicocategorie uw systeem valt. Dat oordeel is juridisch, heeft echte gevolgen, en hoort bij een advocaat of een gekwalificeerde compliance-adviseur.

Wij verkopen ook geen AI-governanceplatform. Dat aanbod is groot, en als uw behoefte een register van AI-systemen met een beleidsworkflow is, bedient zo'n platform u beter dan wij. Wat wij doen is het engineeringwerk in de systemen zelf.

Voor wie dit is

Aanbieders van hoogrisico-AI-systemen onder bijlage III (werving en personeelsbeheer, kredietscoring, verzekeringspremies, beoordeling in het onderwijs, toegang tot essentiële diensten, biometrische systemen), die nu tot december 2027 hebben en veel te bouwen.

Fabrikanten die AI in gereguleerde producten inbouwen (medische hulpmiddelen, machines, voertuigen), waar de AI-verordening bovenop een bestaand conformiteitsregime komt en de twee documentatiesets met elkaar moeten kloppen.

Bedrijven die hoogrisicosystemen van een ander afnemen, die hun eigen verplichtingen dragen: menselijk toezicht, relevantie van de invoergegevens, monitoring en het bewaren van logs.

Iedereen die generatieve functies aan EU-gebruikers levert, waar de transparantie uit artikel 50 vandaag al geldt, ongeacht risicocategorie.

Hoe trajecten lopen

Technische gapanalyse, twee tot vier weken. Wij nemen de indeling waar uw juristen op zijn uitgekomen als gegeven en toetsen uw systemen aan de engineeringverplichtingen die daaruit volgen. Het resultaat is een gapregister (verplichting, huidige stand, wat er gebouwd moet worden, inspanning), waar uw compliance- en engineeringverantwoordelijken beiden mee uit de voeten kunnen.

Bouw, gefaseerd, meestal beginnend bij logging en documentatiegeneratie, omdat al het andere bewijs oplevert dat ergens moet landen.

Readinessbeoordeling vóór de conformiteitsbeoordeling, met het bewijsdossier samengesteld en de resterende gaten eerlijk benoemd.

Standaarden en kaders

Verordening (EU) 2024/1689 met bijlagen III en IV; de geharmoniseerde normen die uit CEN/CENELEC JTC 21 komen; ISO/IEC 42001 voor AI-managementsystemen en ISO/IEC 23894 voor AI-risicomanagement; het NIST AI Risk Management Framework waar een Amerikaans moederbedrijf afstemming vraagt; en de AVG, die niet verdwijnt en die de meeste loggingbeslissingen begrenst.

Veelgestelde vragen

Is de AI-verordening uitgesteld?

Gedeeltelijk. De Digital Omnibus heeft de hoogrisicoverplichtingen verschoven naar 2 december 2027 voor zelfstandige systemen en 2 augustus 2028 voor AI die in gereguleerde producten is ingebouwd. De verboden praktijken, de AI-geletterdheid, de verplichtingen voor AI-modellen voor algemene doeleinden en de transparantieregels uit artikel 50 zijn niet uitgesteld en gelden nu.

Wij gebruiken alleen AI-systemen die door anderen zijn gebouwd. Hebben wij verplichtingen?

Ja, als gebruiksverantwoordelijke. Daaronder vallen: het systeem gebruiken volgens de gebruiksaanwijzing, menselijk toezicht beleggen bij mensen met de bekwaamheid en de bevoegdheid om dat uit te oefenen, zorgen dat de invoergegevens relevant zijn voor het beoogde doel, de werking monitoren en de logs bewaren. Lichter dan de verplichtingen van een aanbieder, maar reëel, en let op: een systeem substantieel wijzigen of er uw eigen naam op zetten kan u tot aanbieder maken.

Ons systeem is geen hoogrisicosysteem. Valt er dan nog iets te doen?

Waarschijnlijk twee dingen. De transparantie uit artikel 50 geldt voor bepaalde systemen ongeacht risicocategorie, waaronder chatbots en het genereren van synthetische content. En de AI-geletterdheid uit artikel 4 geldt voor aanbieders en gebruiksverantwoordelijken in het algemeen. Daarnaast is het waardevol om de indelingsbeslissing te kunnen onderbouwen, mocht een toezichthouder er ooit naar vragen.

Kan de technische documentatie werkelijk worden gegenereerd?

Grotendeels wel. Architectuur, datasetbeschrijvingen, evaluatieresultaten, metrieken, modelversies en wijzigingshistorie zitten al in uw systemen; het werk zit in het vastleggen daarvan in een stabiele structuur op buildmoment. De echt beschrijvende onderdelen (beoogd doel, risicoanalyse, ontwerpmotivatie) worden door mensen geschreven, en daarna in dezelfde repository bewaard zodat ze met al het andere meeversioneren.

Hoe verhoudt de AI-verordening zich tot de AVG?

Ze overlappen en trekken soms de andere kant op, vooral bij logging. De AI-verordening wil traceerbaarheid; de AVG wil minimalisatie en verwijdering. De oplossing is meestal pseudonimisering, zorgvuldig afbakenen van wat er wordt gelogd, en een vastgelegde bewaartermijn die aan een gedocumenteerd doel hangt. Het is een ontwerpbeslissing, die u één keer bewust neemt.

Maakt het gebruik van een model van derden ons aanbieder van dat model?

Nee, maar er een AI-systeem bovenop bouwen kan u wel aanbieder van dát systeem maken, met de bijbehorende verplichtingen. Waar precies de grens ligt hangt af van wat u bouwt en hoe u het presenteert, en dat is een juridische vraag, maar het technische gevolg is dat u er hoe dan ook van moet uitgaan dat u documentatie van uw eigen systeem nodig hebt.

Aan de slag

Vertel ons wat uw systemen doen en waar uw juristen op zijn uitgekomen wat betreft de indeling. Wij beoordelen wat de verplichtingen in code betekenen en leveren u een gapregister met de inspanning per regel.

Neem contact op voor een technische gapanalyse AI-verordening.

Gerelateerde diensten

• AI-agents en MCP-integratie: het bouwen van de systemen waar dit regime over gaat
• EU market entry development: de bredere EU-stack voor digitale compliance
• Herstel van webtoegankelijkheid: de andere EU-verplichting die een engineeringproject blijkt te zijn