De meeste artikelen over de EU AI Act gaan over wat hij betekent voor nieuwe AI-projecten. Dat is de makkelijkste helft van de vraag.
De moeilijkere helft (en degene die op engineeringteams terechtkomt) is wat hij betekent voor de systemen die u al draait. Het ERP met een scoringsmodule die iemand in 2022 toevoegde. Het supportplatform met geautomatiseerde triage. De klantgerichte assistent die vorig jaar live ging. Die draaien vandaag in productie, en de AI Act raakt ze.
Dit artikel behandelt wat de AI Act in grote lijnen is, wat hij verandert voor het onderhouden en doorontwikkelen van bestaande systemen, en hoe u dat praktisch aanpakt.
Een kanttekening: dit is praktische begeleiding vanuit engineeringperspectief, geen juridisch advies. Betrek uw juridisch adviseur bij classificatiebeslissingen en alles wat zwaarwegend is.
De AI Act in grote lijnen
De EU AI Act is de eerste allesomvattende horizontale regelgeving voor kunstmatige intelligentie. Hij trad op 1 augustus 2024 in werking en wordt gefaseerd van toepassing in plaats van in één keer.
Twee ideeën doen het meeste werk.
Ten eerste: hij is risicogebaseerd. Verplichtingen hangen af van wat het AI-systeem doet, niet van welke technologie het gebruikt:
- Verboden praktijken: een kleine set toepassingen die ronduit verboden zijn. Deze zijn van toepassing sinds februari 2025.
- Hoogrisicosystemen: een omschreven lijst met onder meer AI bij werving, kredietscoring, onderwijs, biometrische categorisatie, rechtshandhaving, en AI ingebed in gereguleerde producten zoals medische hulpmiddelen en machines. Deze dragen de zwaarste verplichtingen: risicobeheer, datagovernance, technische documentatie, logging, menselijk toezicht en conformiteitsbeoordeling.
- Beperkt risico / transparantie: systemen die met mensen communiceren of synthetische inhoud genereren. De kernverplichting is openheid: mensen moeten weten dat ze met AI te maken hebben of AI-gegenereerde inhoud zien.
- Minimaal risico: al het overige, zonder specifieke verplichtingen.
Ten tweede: uw rol telt. De Act onderscheidt aanbieders (die een AI-systeem ontwikkelen en op de markt brengen) van gebruiksverantwoordelijken (die het onder eigen gezag inzetten). De meeste mkb-bedrijven zijn gebruiksverantwoordelijke, maar zodra u een AI-systeem op maat laat bouwen, of er substantieel aan wijzigt, kunt u zich met aanbiedersverplichtingen geconfronteerd zien.
Waar de tijdlijn staat
De fasering is sinds de aanname verschoven, dus precisie is op zijn plaats:
- Verboden praktijken en de AI-geletterdheidsverplichting: van toepassing sinds 2 februari 2025.
- Regels voor general-purpose AI-modellen: van toepassing sinds 2 augustus 2025.
- Transparantieverplichtingen (artikel 50): van toepassing vanaf 2 augustus 2026. Deze zijn nu actief en raken een breed scala aan organisaties die generatieve AI gebruiken. Voor systemen die synthetische inhoud genereren of manipuleren en die vóór die datum al op de markt waren, is de eis van machineleesbare markering uitgesteld tot 2 december 2026.
- Hoogrisicoverplichtingen: uitgesteld door de Digital Omnibus van 2026. Zelfstandige hoogrisicosystemen (bijlage III: werving, kredietscoring en dergelijke) gelden nu vanaf 2 december 2027; AI ingebed in gereguleerde producten (bijlage I) vanaf 2 augustus 2028.
Het uitstel van de hoogrisicodeadlines geeft echte ademruimte, maar moet goed gelezen worden: niet alles is uitgesteld. Verboden, GPAI-regels en transparantieverplichtingen bleven op hun oorspronkelijke data staan. Praat uw systeem met klanten of genereert het inhoud, dan is de relevante datum al gepasseerd.
Wat dit verandert voor het onderhoud van bestaande systemen
Hier wordt het concreet voor engineeringteams. Zes dingen veranderen.
1. U kunt niet naleven wat u niet in kaart heeft
Het eerste praktische probleem is niet juridisch maar archeologisch. De meeste bedrijven hebben geen volledige lijst van waar AI al in hun systemen zit. Hier een aanbevelingsengine, daar een classificatiemodel, een OCR-pipeline, een leveranciersmodule waarvan de “slimme” functie een model bleek te zijn. Een deel is jaren geleden toegevoegd door mensen die inmiddels vertrokken zijn.
Voordat een classificatievraag beantwoord kan worden, moet iemand het in kaart brengen: welke AI draait er, wat doet die, welke data raakt die, van wie is het model, en in welk systeem zit het ingebed. Voor een bedrijf met legacysystemen is dit werkelijk een onderhouds- en documentatie-oefening, geen juridische.
2. Transparantieverplichtingen raken systemen die al in productie draaien
Artikel 50 vereist het vaakst codewijzigingen in software die u al draait. Communiceert een systeem met mensen, dan moeten zij doorgaans weten dat ze met AI te maken hebben. Genereert of manipuleert het inhoud, dan moet die output doorgaans gemarkeerd worden als kunstmatig gegenereerd.
Voor een chatbot of assistent die twee jaar geleden live ging, is dat geen beleidsbeslissing. Het is een wijziging aan de interface, de outputpipeline en mogelijk het datamodel. Dat is onderhoudswerk, aan een live systeem, met een deadline eraan vast.
3. “Substantiële wijziging” kan uw verplichtingen veranderen
Dit is het punt dat het meest relevant is voor onderhoud, en het makkelijkst over het hoofd wordt gezien.
De verplichtingen hangen aan systemen zoals ze op de markt zijn gebracht, maar significante wijzigingen in het beoogde doel of ontwerp van een AI-systeem kunnen het terug binnen het toepassingsgebied brengen, of u van gebruiksverantwoordelijke tot aanbieder maken. In de praktijk betekent dit dat een onderhoudsbeslissing een regulatoir gevolg kan hebben: een triagemodel uitbreiden zodat het ook sollicitanten rangschikt is niet zomaar een feature; het kan dat systeem in een hoogrisicocategorie duwen.
Praktisch gevolg voor engineering: wijzigingen aan AI-functionaliteit vragen om een classificatiecheck vóór ze live gaan, niet erna. Dat verandert hoe een onderhoudsbacklog wordt beoordeeld.
4. Documentatie en logging zijn geen optionele hygiëne meer
Voor hoogrisicosystemen zijn technische documentatie, registratie en automatische logging expliciete eisen. Maar ook onder die drempel wordt het kunnen beantwoorden van “wat doet dit model, op welke data, en wat besloot het afgelopen maart” het verschil tussen een beheersbaar verzoek en een brandoefening.
De meeste legacysystemen zakken vandaag voor deze test, niet uit slordigheid, maar omdat het niemand eerder gevraagd werd. Logging en documentatie achteraf inbouwen in een draaiend systeem is klassiek onderhoudswerk, en het kost tijd die een deadline niet met terugwerkende kracht geeft.
5. Menselijk toezicht moet in de workflow zitten, niet in het beleid
Waar verplichtingen gelden, moet menselijk toezicht effectief zijn: een persoon die de output kan begrijpen, volgen en overrulen. Dat is een architectuureigenschap, geen alinea in een handboek. Keurt een systeem automatisch goed, af of verstuurt het automatisch zonder praktisch interventiepunt, dan is er een wijziging nodig aan de workflow en vaak aan het systeem zelf.
6. De grond beweegt onder u
Het model dat uw systeem aanroept wordt uitgefaseerd. De leverancier wijzigt voorwaarden, of de verwerkingsregio. Een nieuwe modelversie gedraagt zich anders op dezelfde invoer. Normen en richtsnoeren blijven verschijnen, en de tijdlijnen zelf zijn al één keer verschoven.
Een AI-systeem is geen “bouwen en vergeten”-bezit. Het vraagt dezelfde doorlopende aandacht als elk kritiek systeem, plus een compliancedimensie die er eerder niet was.
Hoe Dink kan helpen
Dit is in de kern het werk dat we al doen, toegepast op een nieuwer probleem. Dink onderhoudt en moderniseert de systemen waar mkb-bedrijven in België en Nederland op draaien, en de AI Act maakt van verschillende van onze gewoonten een vereiste.
Vinden wat er werkelijk is. Onze technology assessment is een gestructureerde review van een bestaand platform: wat draait er, waarop, geïntegreerd met wat. Die uitbreiden naar een inventaris van AI-componenten en de data die ze raken, is de natuurlijke eerste stap naar elke classificatiebeslissing.
De wijzigingen veilig doorvoeren. Transparantiemeldingen toevoegen, logging achteraf inbouwen, een toezichtsstap inbouwen: dat zijn wijzigingen aan live systemen die niet mogen uitvallen. Gefaseerde uitrol, omkeerbare wijzigingen en testen: zo werken we al aan kritieke software.
Documenteren wat alleen in hoofden zit. Technische documentatie is nu een compliance-artefact. Het is ook wat we standaard opleveren wanneer we een systeem overnemen, omdat het langdurig onderhoud pas mogelijk maakt.
Wijzigingen beoordelen vóór ze live gaan. “Verandert dit wat de AI doet?” behandelen als onderdeel van de onderhoudsworkflow, zodat een routineverbetering niet stilletjes een systeem herclassificeert.
Het daarna werkend houden. Modellen worden uitgefaseerd, leveranciers wijzigen voorwaarden, richtsnoeren evolueren. Doorlopend onderhoud is wat een AI-systeem zowel functioneel als verdedigbaar houdt.
Weet u niet zeker welke AI in uw systemen draait, of wat de AI Act betekent voor de wijzigingen op uw roadmap? Dan is dat een goed eerste gesprek, en een goede reden om met een assessment te beginnen in plaats van met een herbouw.
Veelgestelde vragen
Geldt de EU AI Act ook voor AI-systemen die we al in productie hebben? Ja. De Act raakt systemen die al in gebruik zijn, al hangen de verplichtingen af van de risicocategorie en de toepasselijke datum. Transparantieverplichtingen onder artikel 50 gelden sinds 2 augustus 2026 en kunnen wijzigingen vereisen aan systemen die al draaien, zoals melden dat een gebruiker met AI communiceert of AI-gegenereerde inhoud markeren.
Zijn de hoogrisicodeadlines uitgesteld? Ja, maar alleen die. Onder de Digital Omnibus van 2026 gelden zelfstandige hoogrisicosystemen (bijlage III) vanaf 2 december 2027 en AI ingebed in gereguleerde producten (bijlage I) vanaf 2 augustus 2028. Verboden praktijken, GPAI-regels en transparantieverplichtingen blijven op hun oorspronkelijke data.
Zijn de meeste bedrijfssystemen hoogrisico onder de AI Act? Nee. De meeste gewone zakelijke toepassingen (documentextractie, interne kennisbank-zoekfuncties, samenvatten, routing) vallen in lagere risicocategorieën waar transparantie de belangrijkste eis is. Hoogrisicocategorieën dekken omschreven toepassingen zoals werving, kredietscoring, onderwijs, biometrie en AI in gereguleerde producten. Raakt uw systeem die gebieden, behandel het dan als hoogrisico tot het tegendeel bevestigd is.
Kan het wijzigen van een bestaand AI-systeem nieuwe verplichtingen creëren? Dat kan. Significante wijzigingen in het beoogde doel of ontwerp van een AI-systeem kunnen het binnen het toepassingsgebied brengen of uw rol veranderen van gebruiksverantwoordelijke naar aanbieder. Daarom hoort een classificatiecheck in het onderhoudsproces thuis, vóór wijzigingen live gaan in plaats van erna.
Wat is de eerste praktische stap voor een bedrijf met bestaande systemen? Inventariseren. Breng in kaart welke AI er werkelijk draait, wat die doet, welke data die raakt en wie de aanbieder is. U kunt niet classificeren of naleven wat u niet gecatalogiseerd heeft, en voor de meeste bedrijven met legacysystemen is die inventarisatie eerst een engineeringoefening en pas daarna een juridische.