De AI Act hoort bij IT: vier taken voor engineering- en datateams

Wie is verantwoordelijk voor de AI Act in een organisatie? De verordening legt haar plichten niet bij een afdeling, maar bij de organisatie in haar rol: aanbieder, gebruiksverantwoordelijke, importeur of distributeur. Legal bepaalt welke plichten gelden. Het bewijs dat u eraan voldoet ontstaat in het AI-register, de logs, de modelversies en de schermen waarop medewerkers een uitkomst kunnen overrulen. Dat is werk van IT, data en MLOps.

Publicatienoot: een eerdere, kortere versie van dit stuk verscheen in AG Connect (printeditie 4 - 2026, rubriek Tech & Toekomst, p. 52-54) en op 8 oktober 2026 online: De EU AI Act hoort niet thuis bij Legal, maar bij IT. Deze versie op Praxikon werkt elke taak verder uit, legt de koppeling met de AVG en is bijgewerkt naar de geldende tekst na de Digital Omnibus.

Het moment waarop het dossier van afdeling wisselt

Het patroon is in veel organisaties hetzelfde. De AI Act komt binnen als wetgeving, dus gaat hij naar Legal of Compliance. Daar ontstaat een AI-beleid, er komt een verantwoordelijke en het onderwerp krijgt een plek op de risicokaart. Dat werk is nodig. Het wordt pas een probleem als iedereen denkt dat het daarmee af is.

Dat blijkt op het moment dat iemand een concrete vraag stelt. Een interne auditor, een klant in een aanbesteding of een toezichthouder vraagt welke AI-systemen u gebruikt, welke daarvan hoog risico zijn en hoe u kunt laten zien dat een mens een uitkomst echt kan tegenhouden. Het beleidsstuk geeft daar geen antwoord op. Het antwoord staat in een CMDB die niet compleet is, in de configuratie van een SaaS-tool die een team zelf aanzette, en in logs waarvan niemand weet hoe lang ze bewaard worden.

De AI Act is juridisch van vorm en technisch van inhoud. Wie dat te laat ziet, moet achteraf reconstrueren wat vooraf vastgelegd had kunnen worden.

Eerst de rol, dan de afdeling

Voordat een team aan de slag gaat, moet één vraag beantwoord zijn: in welke rol zit uw organisatie per systeem? Een aanbieder ontwikkelt een AI-systeem of laat het ontwikkelen en brengt het onder eigen naam op de markt of in gebruik. Een gebruiksverantwoordelijke zet een systeem onder eigen gezag in. De meeste organisaties zijn vooral gebruiksverantwoordelijke, met hier en daar een eigen bouwsel waarvoor ze aanbieder zijn. Het verschil bepaalt welke plichten op tafel liggen; de vergelijking tussen provider en deployer zet ze naast elkaar.

Die rol staat niet vast. Wie een ingekocht hoog-risicosysteem substantieel wijzigt, het onder eigen naam aanbiedt of een algemeen systeem voor een hoog-risicodoel inzet, wordt volgens artikel 25 zelf aanbieder. Voor IT-teams is dat geen theorie: een fine-tune, een eigen RAG-laag of een nieuw doel voor een bestaande tool kan precies die verschuiving zijn. Hoe dat werkt staat in de drie routes van artikel 25.

Hier ligt de natuurlijke werkverdeling. Legal stelt per systeem de rol en de risicoklasse vast en vertaalt die naar eisen. IT, data en MLOps bouwen de voorzieningen die het bewijs leveren. De business is eigenaar van het gebruik en van de beslissingen die op een uitkomst volgen. Zolang die drie elkaar pas bij de audit spreken, gaat het mis.

Taak 1: een AI-register dat meebeweegt met uw deployments

Alles begint bij weten wat u draait. De AI Act noemt een intern AI-register nergens letterlijk, maar zonder inventarisatie kunt u geen systeem classificeren, geen documentatie bijhouden en niet aantonen dat u weet waar uw plichten liggen. Dat argument staat uitgewerkt in wat de AI Act echt eist van uw AI-inventarisatie.

Een register dat een audit overleeft, legt per systeem minimaal vast: de functionele eigenaar, de technische eigenaar, uw rol, het beoogde doel, de risicoklasse met de redenering erachter, de modellen en datasets die eronder liggen, de leverancier en of het om eigen bouw of inkoop gaat. Voor de classificatie helpt de Bijlage III-classifier of de beslisboom voor risicoclassificatie; leg de uitkomst en de datum vast, want een classificatie is een momentopname.

De grootste blinde vlek is zelden het model dat uw datateam bouwde. Het is de AI die via een update binnenkwam: de samenvattingsfunctie in het ticketsysteem, de assistent in het CRM, de copilot die een afdeling zelf activeerde. Daarom hoort de inventarisatie aan de bron te zitten en niet aan het eind. Drie koppelingen maken het verschil:

• Inkoop: geen contract voor software met AI-functionaliteit zonder registerregel. De vragen die u een leverancier stelt, staan in de inkoop- en due diligence-gids.
• Deployment: een nieuw model of een nieuwe modelversie in de registry levert automatisch een concept-registerregel op die de eigenaar moet bevestigen.
• Netwerk en SaaS-beheer: verkeer naar bekende AI-API's en nieuw geactiveerde AI-functies in bestaande tools worden periodiek tegen het register gelegd. Dat is de praktische kant van shadow AI.

Een register dat niet aan een proces hangt, klopt binnen een kwartaal niet meer. Begin klein en werkend: tien systemen die echt kloppen zijn meer waard dan tweehonderd regels die niemand vertrouwt. Voor aanbieders van Bijlage III-systemen komt daar later nog de registratie in de EU-databank van artikel 49 bij, maar die vult u alleen goed in als uw eigen register op orde is.

Taak 2: logging en traceerbaarheid als ontwerpeis

Een hoog-risicosysteem moet zo zijn gebouwd dat gebeurtenissen gedurende de levenscyclus automatisch worden vastgelegd. Dat staat in artikel 12, en het doel is traceerbaarheid: situaties herkennen waarin het systeem een risico gaat vormen of substantieel verandert, monitoring na het in de handel brengen mogelijk maken en de gebruiksverantwoordelijke in staat stellen de werking te volgen. De aanbieder bewaart de logs die onder zijn controle vallen ten minste zes maanden (artikel 19); de gebruiksverantwoordelijke doet hetzelfde voor de logs onder zijn controle (artikel 26, lid 6).

Wat dat in de praktijk betekent, wordt duidelijk met één vraag. Stel dat een klant in maart een lening is geweigerd en een toezichthouder vraagt in september waarom. Kunt u laten zien welk model toen draaide, welke versie, met welke invoer, welke score eruit kwam, welke drempel gold en wie de uitkomst heeft bekeken? Als dat antwoord uit uw model-registry en uw logplatform komt, heeft u bewijs. Als het in losse mails en verlopen notebooks zit, heeft u een reconstructie.

Een bruikbaar logontwerp legt per beslissing minimaal vast: een tijdstempel, de systeem- en modelversie, een verwijzing naar de invoer, de uitkomst en de gebruikte drempel, of er menselijke tussenkomst was en wat die opleverde. Dat zijn keuzes die bij de architectuur horen, niet bij de audit.

Hier raakt de AI Act direct aan de AVG. Logs over beslissingen over mensen bevatten persoonsgegevens, en de zes maanden zijn een minimum, geen vrijbrief. De bewaartermijnen in de AI Act gelden uitdrukkelijk onverminderd het gegevensbeschermingsrecht. Dataminimalisatie en opslagbeperking blijven dus gelden: log een verwijzing naar de invoer in plaats van de volledige invoer waar dat kan, pseudonimiseer, beperk de toegang tot wie het echt nodig heeft en leg de gekozen termijn met onderbouwing vast. Wie de logging met de privacy officer ontwerpt, hoeft hem later niet om te bouwen. Waar de twee regimes elkaar verder raken, staat op de pagina over de AVG naast de AI Act.

Taak 3: documentatie en data die uit de pipeline rollen

De aanbieder van een hoog-risicosysteem stelt technische documentatie op voordat het systeem op de markt komt en houdt die actueel (artikel 11). Welke elementen erin horen staat in bijlage IV: een beschrijving van het systeem en het beoogde doel, het ontwerp en de architectuur, de gebruikte data, de validatie- en testprocedures met resultaten, de maatregelen voor menselijk toezicht en de wijzigingen die vooraf zijn voorzien. Kmo's en start-ups mochten die elementen al vereenvoudigd aanleveren; sinds de Digital Omnibus geldt dat ook voor kleine midcapondernemingen, op een formulier van de Commissie.

Bijna alles wat bijlage IV vraagt, bestaat in een volwassen MLOps-omgeving al in een of andere vorm: modelkaarten, experiment-tracking, evaluatierapporten, data-lineage en releasenotes. Het werk zit in het verbinden. Behandel documentatie als code: genereer het grootste deel per release uit de registry en de evaluatiepipeline, versioneer het mee met het model en laat een mens alleen het oordeel toevoegen. Een document dat eenmaal per jaar met de hand wordt bijgewerkt, beschrijft binnen een maand een systeem dat niet meer bestaat.

Datagovernance hoort in dezelfde pijplijn. Artikel 10 vraagt van aanbieders dat datasets voor training, validatie en tests aan kwaliteitseisen voldoen: herkomst, relevantie, representativiteit, het opsporen van vertekening en het vastleggen van keuzes. De uitwerking staat in datagovernance onder artikel 10. Eén wijziging uit de Omnibus is voor datateams belangrijk: de grondslag om bijzondere persoonsgegevens te gebruiken voor het opsporen en corrigeren van bias staat sinds 27 juli 2026 in een nieuw artikel 4a, met dezelfde strikte voorwaarden als het oude artikel 10, lid 5, en een bredere kring van organisaties die zich erop kunnen beroepen. Dat is geen vrijbrief onder de AVG: de waarborgen en de vastlegging blijven nodig, en een DPIA ligt bij zulke verwerkingen voor de hand.

Bent u gebruiksverantwoordelijke en geen aanbieder, dan verschuift het werk, maar het verdwijnt niet. U gebruikt het systeem volgens de gebruiksaanwijzing van de aanbieder, zorgt dat invoerdata relevant en voldoende representatief zijn voor zover u die beheert, en gebruikt de informatie van de aanbieder voor uw DPIA (artikel 26, leden 1, 4 en 9). Uw documentatie is dan vooral bewijs van correct gebruik: welke versie, welke configuratie, welke instructies, en wat u deed toen het systeem afweek. Het volledige overzicht staat in de gids voor plichten van gebruiksverantwoordelijken.

Taak 4: menselijk toezicht dat in het scherm zit, niet in de procedure

Menselijk toezicht is in de AI Act geen werkinstructie maar een ontwerpeis. Artikel 14 vraagt dat een hoog-risicosysteem zo is gebouwd, met passende mens-machine-interfaces, dat natuurlijke personen er doeltreffend toezicht op kunnen houden. Die personen moeten de werking en de beperkingen begrijpen, bedacht zijn op de neiging om een uitkomst blind te volgen, de uitkomst kunnen negeren of terugdraaien en het systeem kunnen stoppen.

Neem een model dat sollicitaties voorsorteert. "Een recruiter kijkt er nog naar" is geen toezicht. Toezicht is een scherm dat laat zien waarop een score is gebaseerd en hoe zeker het model is, een knop waarmee de recruiter de volgorde kan overrulen, een verplichte toelichting bij een afwijking en een log die laat zien hoe vaak dat gebeurt. Overrulet niemand ooit iets, dan is dat geen bewijs dat het model goed is. Het is een signaal dat het toezicht een vinkje is geworden. Dit patroon heet rubberstamping en staat uitgewerkt in menselijk toezicht onder artikel 14.

De gebruiksverantwoordelijke wijst dat toezicht toe aan mensen met de nodige bekwaamheid, opleiding, autoriteit en ondersteuning (artikel 26, lid 2). Daar komt artikel 4 binnen. Sinds 2 februari 2025 moeten aanbieders en gebruiksverantwoordelijken maatregelen nemen voor de AI-geletterdheid van hun mensen. Sinds de Omnibus (27 juli 2026) luidt die plicht: maatregelen nemen die de ontwikkeling van AI-geletterdheid ondersteunen, en er staat uitdrukkelijk bij dat dit geen bepaald niveau per persoon vereist; de plicht om maatregelen te nemen staat er nog. Voor IT-teams is de koppeling concreet: een recruiter die niet weet waar het model de mist ingaat, kan een score niet zinvol overrulen. Leg per rol vast welke maatregelen u nam en waarom die passen bij het systeem en de context. Hoe dat dossier eruitziet, laat de pagina over bewijs voor artikel 4 zien.

De taak die vaak ontbreekt: wijzigingen en monitoring

AI-systemen veranderen voortdurend: een nieuwe modelversie, een andere drempel, extra trainingsdata, een nieuwe prompt. De AI Act heeft daar een eigen begrip voor. Een substantiële wijziging is een verandering na het in de handel brengen die de aanbieder niet had voorzien in de oorspronkelijke conformiteitsbeoordeling en die de naleving van de eisen raakt of het beoogde doel verandert. Een hoog-risicosysteem dat substantieel wordt gewijzigd, moet opnieuw door de conformiteitsbeoordeling (artikel 43, lid 4). Wijzigingen die de aanbieder vooraf heeft vastgelegd in de technische documentatie, bijvoorbeeld bij een systeem dat doorleert, tellen niet als substantieel.

Voor engineering vertaalt dat zich naar change management met een AI-vraag erin. Elke wijziging aan een geregistreerd systeem krijgt een korte toets: valt dit binnen wat vooraf is beschreven, verandert het doel, raakt het nauwkeurigheid, robuustheid of toezicht? Leg vooraf vast welke wijzigingen binnen de marges vallen, zodat routine-updates routine blijven. En besef dat een gebruiksverantwoordelijke die zelf een hoog-risicosysteem substantieel wijzigt, via artikel 25 aanbieder wordt.

Monitoring sluit de cirkel. De aanbieder richt monitoring na het in de handel brengen in (artikel 72); de gebruiksverantwoordelijke monitort de werking aan de hand van de gebruiksaanwijzing en moet bij een risico de aanbieder of distributeur en de markttoezichtautoriteit zonder onnodige vertraging informeren en het gebruik onderbreken (artikel 26, lid 5). Dat onderbreken is geen keuze. Zorg dus dat er technisch een uitknop bestaat en dat iemand weet wanneer hij die moet gebruiken. De logging uit taak 2 is wat deze monitoring mogelijk maakt.

Waar de AVG het voorwerk al deed

Organisaties die de AVG serieus hebben ingericht, beginnen niet bij nul. Het verwerkingsregister is een goed startpunt voor het AI-register, omdat de meeste AI-toepassingen persoonsgegevens verwerken. De DPIA-praktijk levert de methode voor risicoanalyse, en voor de gebruiksverantwoordelijken die een grondrechteneffectbeoordeling moeten doen, mag die FRIA relevante delen van een DPIA overnemen of ernaar verwijzen. Het verschil tussen beide staat in de vergelijking van DPIA en FRIA. Ook de rol van de functionaris gegevensbescherming en de afspraken met verwerkers bieden een structuur waar de AI Act op kan aansluiten.

Wie daarnaast onder NIS2 of DORA valt, ziet dezelfde onderliggende processen terugkomen: logging, incidenten, leveranciers en wijzigingsbeheer. Bouw dan één set controls met een view per wet in plaats van drie parallelle trajecten; zie AI Act, NIS2 en DORA in één controlset.

De tijdlijn op 8 oktober 2026

De feiten in het AG Connect-artikel hebben als peildatum begin juli 2026, toen het uitstel voor hoog-risicosystemen politiek rond maar juridisch nog niet definitief was. Dat is inmiddels anders. De Digital Omnibus on AI is als Verordening (EU) 2026/1744 op 24 juli 2026 gepubliceerd en geldt sinds 27 juli 2026. De stand van vandaag:

Voor de meeste IT-teams betekent dit twee dingen. Artikel 50 is geen voorbereiding meer maar geldend recht: een chatbot die niet meldt dat de gebruiker met AI praat, of een generatief systeem zonder machineleesbare markering, is nu een nalevingsvraag. De beslisboom artikel 50 laat per rol zien welk lid geldt. En de hoog-risicoplichten hebben een vaste datum gekregen. Dat is runway, geen reden om te wachten: een register vullen, systemen classificeren, logging ombouwen en documentatie in de pipeline krijgen kost maanden. Het complete overzicht staat in AI Act-deadlines 2026, 2027 en 2028.

Een werkverdeling die standhoudt

Samengevat ziet een werkbare verdeling er zo uit:

Begin bij tien systemen

De AI Act voelt groot zolang hij als één juridisch blok wordt gepresenteerd. Voor een IT- of datateam valt hij uiteen in vier behapbare taken: weet wat u draait, leg vast wat het doet, documenteer het terwijl u bouwt en zorg dat een mens echt kan ingrijpen. Dat is geen compliance-project naast het werk. Het is goed vakmanschap met een auditspoor eraan.

Het slechtste wat u kunt doen, is wachten tot er een beleidsstuk ligt en denken dat u klaar bent. Het beste wat u vandaag kunt doen, is uw register openen en de eerste tien systemen erin zetten. Wilt u voor één systeem zien welke plichten, acties en bewijsstukken daarbij horen, met de bron bij elke stap, maak dan een implementatiekaart.

Dit stuk en de andere publicaties van Zahed Ashkara in de media staan bij elkaar op de perspagina.