EU AI-wet voor bouwers: wat verandert er in uw code

De EU AI-wet trad in augustus 2024 in werking en haar verplichtingen rollen door in 2026 en 2027. Als u software bouwt die AI bevat — of een bedrijf adviseert dat dat doet — moet u begrijpen wat het werkelijk vereist. Niet het GDPR-stijl "we regelen het later wel". Echte verplichtingen, echte termijnen, echte gevolgen.

Dit is geen juridisch overzicht. Het is een gids voor bouwers: wat classificatie betekent voor uw systeem, welke documentatie u moet produceren, en wat er verandert in de manier waarop u code schrijft en deployt.

Het risicoklassificatiesysteem

De verordening verdeelt AI-systemen in vier risicocategorieën. Waar uw systeem valt bepaalt bijna al het andere.

Onaanvaardbaar risico — volledig verboden

Een kleine set systemen is volledig verboden: realtime biometrische surveillance op openbare plaatsen (met smalle uitzonderingen voor rechtshandhaving), sociale scorebepaling door overheden, subliminale manipulatie, exploitatie van kwetsbare groepen. Als u een van deze bouwt, stop dan.

Hoog risico — de categorie die de meeste serieuze bedrijfssoftware treft

Hier heeft de verordening het meeste praktische gewicht. AI-systemen met hoog risico omvatten:

• AI gebruikt in werving, prestatiebeheer of werkverdeling
• AI in kredietscoring, verzekeringsrisico of financiële diensten
• AI in het beheer van kritieke infrastructuur (energie, transport, water)
• AI in gezondheidszorg, medische hulpmiddelen of nooddiensten
• AI in onderwijsbeoordeling of toegang tot beroepsopleidingen
• AI gebruikt door rechtshandhaving of grensbeheer
• AI-systemen die fundamentele rechten beïnvloeden

Als uw systeem beslissingen neemt of substantieel ondersteunt in een van deze gebieden, bouwt u een AI-systeem met hoog risico en is het volledige nalevingskader van toepassing.

Wat "substantieel ondersteunt" in de praktijk betekent is bewust breed. Een systeem dat leningaanvragen classificeert voor een mens om te beoordelen is waarschijnlijk hoog risico. Een systeem dat werknemersprestaties markeert voor een manager om actie op te ondernemen is waarschijnlijk hoog risico. Neem bij twijfel hoog risico aan totdat juridisch advies anders zegt.

Beperkt risico — alleen transparantieverplichtingen

Chatbots en systemen die rechtstreeks met gebruikers communiceren, moeten bekendmaken dat ze AI zijn. Deepfakes moeten worden gelabeld. Als u een klantgerichte conversationele AI bouwt, heeft u een openbaarmakingsmechanisme nodig. Dat is hier de hoofdverplichting — en die is gemakkelijk te implementeren.

Minimaal risico — geen specifieke verplichtingen

De meeste AI-systemen die in bedrijven worden gebruikt — aanbevelingsengines, spamfilters, documentsamenvattingstools — vallen hier. U kunt deze bouwen en deployen zonder de nalevingslast van het hoog-risicokader, hoewel goede engineeringpraktijken en datagovernance nog steeds van toepassing zijn.

Wat hoog-risico naleving werkelijk vereist

Als uw systeem hoog risico is, is dit wat de verordening vereist. Dit is niet uitputtend — lees de verordening of haal juridisch advies in voor het volledige beeld — maar het dekt de engineeringgerichte verplichtingen.

Risicobeheersysteem

U heeft een gedocumenteerde risicobeheerprocedure nodig, gedurende de gehele levenscyclus van het systeem gehandhaafd. Niet één document — een levend proces dat risico's identificeert, hun waarschijnlijkheid en ernst schat, testresultaten evalueert, en restrisico's na mitigaties documenteert.

In engineeringtermen: dit is een geformaliseerde versie van wat goede teams al informeel doen. De verordening vereist dat u het opschrijft, actueel houdt, en koppelt aan uw testartefacten.

Datagovernance

Trainings-, validatie- en testdata moeten voldoen aan specifieke kwaliteitsnormen: geschikt voor het doel, representatief voor de operationele omgeving, onderzocht op biassen, gedocumenteerd met hun herkomst en verwerkingsgeschiedenis.

Dit is het onderdeel dat de meeste teams onderschatten. Als u op publieke datasets hebt getraind, moet u ze documenteren, hun representativiteit onderzoeken, en — als uw systeem mensen in beschermde categorieën beïnvloedt — op bias onderzoeken. Dat onderzoek moet schriftelijk worden vastgelegd.

Technische documentatie

Voor het deployen van een hoog-risico systeem moet u technische documentatie produceren die het volgende dekt: het beoogde doel van het systeem, de technische kenmerken van het AI-model, de trainingsaanpak en gebruikte data, prestatiemetrieken en testresultaten, menselijke toezichtmechanismen, en maatregelen voor veiligheid en nauwkeurigheid.

Dit is substantieel. Als u denkt "we documenteren na het bouwen," dan is dat niet-conform. De documentatie is onderdeel van het deploymentartefact.

Logging en transparantie

AI-systemen met hoog risico moeten voldoende informatie loggen om hun beslissingen achteraf te controleren. Welke invoer welke uitvoer triggerde. Welke versie van het model draaide. Wanneer en hoe het systeem werd gebruikt.

Logbewaartermijnen hangen af van het gebruiksscenario. Voor sommige hoog-risico categorieën moeten logs jaren worden bewaard.

Menselijk toezicht

Hoog-risico systemen moeten zijn ontworpen om menselijk toezicht toe te staan — niet alleen in theorie, maar in de praktijk. Dit betekent:

• Het systeem moet kunnen worden onderbroken, overschreven of losgekoppeld
• De outputs moeten voldoende informatie bevatten zodat een mens ze kan begrijpen en beoordelen
• Het systeem moet zijn eigen onzekerheid signaleren waar relevant

Een systeem ontworpen om volledig autonome beslissingen te nemen zonder menselijk beoordelingsmechanisme voldoet niet aan het hoog-risicokader. Punt.

Conformiteitsbeoordeling

Voor marktdeployment vereisen hoog-risico systemen een conformiteitsbeoordeling — een formele evaluatie of het systeem voldoet aan de vereisten van de verordening. Voor de meeste hoog-risico categorieën is dit een zelfbeoordeling door de aanbieder (gedocumenteerd). Voor sommige categorieën (biometrie, kritieke infrastructuur, rechtshandhaving) is certificering door derden vereist.

Wat er verandert in de manier waarop u bouwt

De EU AI-wet verplicht geen specifieke technologieën of architecturen. Maar het legt beperkingen op die engineeringbeslissingen beïnvloeden.

Verklaarbaarheid is niet optioneel. Als uw systeem hoog-risico beslissingen neemt, moet het mogelijk zijn uit te leggen waarom. Black-box modellen die niet bevraagd kunnen worden zijn niet-conform voor hoog-risico gebruiksscenario's. Dit duwt naar architecturen waarbij de redenering auditeerbaar is — gestructureerde outputs, vertrouwensscores, beslisbomen, RAG met broncitaties — en weg van "het model zei gewoon zo."

Versioning is verplicht, niet een goede praktijk. U moet precies kunnen identificeren welke versie van het model draaide toen een beslissing werd genomen. Modelversioning, deploymentrecords, en de mogelijkheid om historische beslissingen te reproduceren zijn nalevingsvereisten, geen nice-to-haves.

Biastests zijn een deliverable. Voor hoog-risico systemen kunt u niet shippen zonder biastests en gedocumenteerde resultaten. Als uw systeem mensen beïnvloedt, moet u testen of het beschermde groepen anders beïnvloedt en documenteren wat u vond — en wat u eraan deed.

Auditlogs zijn een eerste-klas engineeringvraagstuk. Loggen voor naleving verschilt van loggen voor debuggen. Nalevingslogs moeten manipulatiebestendig zijn, voor bepaalde perioden worden bewaard, en gestructureerd zijn voor bevragen door toezichthouders. Dit is infrastructuurwerk, niet een nagedachte.

De EU AI-wet en Belgische bedrijven

België is in de EU, dus de verordening is van toepassing. Wat dat in de praktijk betekent voor een Belgische KMO:

Als u een AI-systeem deployt dat uw bedrijf heeft gebouwd — zelfs een intern hulpmiddel — en het valt in een hoog-risico categorie, bent u de aanbieder onder de verordening en is het volledige nalevingskader op u van toepassing.

Als u een AI-hulpmiddel van derden gebruikt (een SaaS-product, een API) in een hoog-risico context, bent u de deployer. Uw verplichtingen zijn lichter — voornamelijk ervoor zorgen dat het hulpmiddel wordt gebruikt binnen zijn beoogde doel, uw werknemers informeren wanneer AI beslissingen neemt die hen beïnvloeden, en menselijk toezicht hebben waar nodig. Maar de risicoklassificatie is nog steeds belangrijk: als u een hulpmiddel van derden gebruikt om hoog-risico beslissingen te nemen, kunt u de verplichtingen niet volledig afwijzen.

Voor de meeste Belgische KMO's die AI gebruiken in documentverwerking, klantcommunicatie of operationele analyses is de praktische realiteit:

• Het systeem is waarschijnlijk minimaal of beperkt risico — transparantieverplichtingen en goede datagovernance, maar niet het volledige hoog-risicokader
• Bij twijfel heeft u een gedocumenteerde classificatiebeslissing nodig, geen gok

Dit is waar de AI Readiness Audit relevant wordt: een eerlijke beoordeling van wat u draait, waar het valt in het classificatiekader, en welke hiaten bestaan.

De tijdlijn die u moet kennen

• Februari 2025: Verboden AI-praktijken zijn van toepassing. Als u een verboden systeem draait, is het al illegaal.
• Augustus 2025: GPAI (General-Purpose AI) modelverplichtingen zijn van toepassing — relevant als u basismodellen bouwt of modellen deployt die niet speciaal voor uw gebruiksscenario zijn gebouwd.
• Augustus 2026: Hoog-risico AI-systeemverplichtingen zijn van toepassing. Dit is de grote deadline. Als u een hoog-risico systeem bouwt of deployt, moet u hieraan voldoen.
• Augustus 2027: Aanvullende hoog-risico categorieën (Bijlage I-systemen — ingebed in gereguleerde producten) zijn van toepassing.

Als u dit leest in medio-2026, is de deadline van augustus 2026 onmiddellijk. Hoog-risico systemen moeten nu voldoen.

Wat te doen als u niet weet waar u staat

1. Classificeer wat u draait. Bepaal voor elk AI-systeem in gebruik of in ontwikkeling de risicocategorie. Documenteer die bepaling en de redenering.

2. Voer voor hoog-risico systemen een gapanalyse uit. Vergelijk uw huidige documentatie, logging, testartefacten en menselijke toezichtmechanismen met de vereisten van de verordening. Identificeer hiaten.

3. Prioriteer hiaten die architectuurwijzigingen vereisen. Logging en versioning zijn retrofitbaar. Verklaarbaarheid niet — als u een black-box model heeft in een hoog-risico gebruiksscenario, is dat een architectuurbeslissing die u nu moet nemen.

4. Schrijf de documentatie. Technische documentatie, datagovernancerecords, risicobeheerdocumentatie — dit kost tijd om goed te produceren en moet bestaan vóór deployment, niet erna.

WDC's AI Readiness Audit is precies ontworpen voor deze situatie: een eerlijke beoordeling van wat u draait, waar het valt onder de EU AI-wet, en een schriftelijk herstelplan. Vaste prijs, twee weken. Als u begint aan een nieuw AI-project en de classificatie meteen goed wilt krijgen, is dat wat de AI Opportunity Assessment dekt. Boek een gesprek als u het eerst wilt bespreken.