EU AI Act voor MKB: Wat Je Voor 2 Augustus 2026 Moet Regelen

Introductie

Op 2 augustus 2026 wordt het zwaarste deel van de EU AI Act handhaafbaar. Dat is over ruim tien weken vanaf het schrijven van deze post. Voor Nederlandse mkb-bedrijven die AI gebruiken in hun product, hun klantenservice of hun interne software is dat geen abstract Brussels onderwerp meer. Het is een concrete deadline met concrete verplichtingen en concrete boetes.

In de gesprekken die wij voeren met klanten merken we dat er twee uitersten zijn. Aan de ene kant ondernemers die denken dat de wet alleen voor Big Tech geldt. Aan de andere kant ondernemers die in paniek raken omdat ze ergens hebben gehoord dat alle AI verboden wordt. Geen van beide klopt. De wet is genuanceerd, en de meeste mkb-toepassingen vallen onder een lichte categorie. Maar wie wel onder de strengere regels valt, heeft serieus werk te doen voor augustus.

Wat de AI Act eigenlijk regelt

"De AI Act reguleert geen technologie. Hij reguleert toepassingen. Hetzelfde model kan in de ene context onder minimaal risico vallen en in de andere onder hoog risico."

— Samenvatting van Artikel 6 en Annex III, EU AI Act

De AI Act is een Europese verordening die AI-systemen indeelt naar risico en daar verschillende verplichtingen aan koppelt. Vier categorieën: onaanvaardbaar risico (verboden), hoog risico (zwaar gereguleerd), beperkt risico (transparantieplicht) en minimaal risico (geen verplichtingen). De wet kijkt naar het doel en de impact van het systeem, niet naar de gebruikte technologie. Een eenvoudig rule-based scoresysteem dat over hypothecaire leningen beslist valt onder dezelfde categorie als een geavanceerd neuraal netwerk dat hetzelfde doet.

Voor mkb is dat onderscheid cruciaal. Een chatbot die FAQ-vragen beantwoordt valt onder beperkt risico: u moet duidelijk maken dat de gebruiker met een AI praat. Een aanbevelingsalgoritme in uw webshop valt vaak onder minimaal risico: in principe geen verplichtingen. Een algoritme dat sollicitanten screent of klantkrediet beoordeelt valt onder hoog risico: dat is waar de zwaarste verplichtingen beginnen.

Wanneer raakt het uw mkb echt

De wet kent twee hoofdrollen: provider en deployer. Een provider ontwikkelt een AI-systeem of laat het ontwikkelen en brengt het op de markt onder eigen naam of merk. Een deployer gebruikt een bestaand systeem binnen de eigen bedrijfsvoering. De meeste Nederlandse mkb-bedrijven zijn deployer. Ze gebruiken Microsoft Copilot, ChatGPT Enterprise, Salesforce Einstein of een Nederlandse SaaS met AI-functies. Voor deployers van laagrisico systemen is de wet vooral een transparantie- en governance-oefening.

Het wordt anders zodra u maatwerksoftware laat bouwen waarin AI een rol speelt. Dan wordt uw bouwer mogelijk provider en u mogelijk deployer van een high-risk systeem. Het wordt ook anders als u een bestaande tool substantieel wijzigt of voor een nieuw doel inzet. Wie een chatbot bedoeld voor klantenservice gaat gebruiken voor sollicitatiescreening verandert volgens Artikel 25 van rol. U wordt dan zelf provider, met alle bijbehorende verplichtingen. Dat is precies het soort transitie waar mkb-organisaties onbewust in glijden zonder een legal review.

Voor MG Software klanten geldt: als wij voor u een AI-feature bouwen waarin we voor de eindgebruiker beslissingen nemen of materieel beïnvloeden, ontwerpen wij het systeem vanaf de eerste sprint met provider-verplichtingen in gedachten. Dat scheelt later honderden uren retrofitting van documentatie.

Annex III: wanneer is uw systeem high-risk

Annex III van de wet noemt acht categorieën waarin AI-systemen automatisch als high-risk gelden zodra ze beslissingen nemen of materieel beïnvloeden. Voor mkb zijn vooral relevant: werkgelegenheid en HR, toegang tot essentiële diensten zoals krediet en verzekering, biometrische identificatie, en in sommige gevallen onderwijs. Logistieke optimalisatie, voorraadbeheer, marketingsegmentatie en interne productiviteitstools vallen meestal buiten Annex III.

Een paar concrete voorbeelden uit onze klantbasis. Een SaaS die CV's scoort voor recruiters: high-risk onder Annex III sectie 4 (werkgelegenheid). Een platform dat met machine learning bepaalt welke klant in aanmerking komt voor termijnbetaling: high-risk onder Annex III sectie 5 (essentiële diensten, kredietbeoordeling). Een dashboard dat met AI verkoopprognoses maakt voor de inkoper: geen high-risk, want het beïnvloedt geen besluit over een persoon. Een chatbot voor klantenservice: beperkt risico, alleen transparantieplicht.

Het gevaarlijke grijze gebied zit in tools die op het randje zitten. Een gepersonaliseerde verzekeringsofferte die door AI wordt berekend kan onder Annex III vallen. Een dynamische prijscalculator voor een webshop niet. Het verschil ligt in of de uitkomst een individu materieel beïnvloedt op een gebied dat de wet beschermt. Wie twijfelt, doet er goed aan dat te documenteren en met een jurist te laten toetsen.

De zeven documentatievereisten die u voor augustus moet hebben

Voor elk high-risk systeem schrijft de wet zeven concrete verplichtingen voor, vastgelegd in Artikel 9 tot en met Artikel 15. Ze zijn niet optioneel en ze hangen samen. Wie ze tijdens de bouw inbouwt heeft een werkbare hoeveelheid werk. Wie ze achteraf moet toevoegen aan een al draaiend systeem is regelmatig weken kwijt.

Een: een risicomanagementsysteem dat door de hele levenscyclus loopt (Artikel 9). Het systeem moet bekende en redelijk voorzienbare risico's identificeren en periodiek heroverwegen. Twee: data governance (Artikel 10). U moet kunnen aantonen waar trainings-, validatie- en testdata vandaan komen, of er bias is, hoe representativiteit is geborgd en hoe persoonsgegevens zijn behandeld. Drie: technische documentatie (Artikel 11). Annex IV geeft een gedetailleerde inhoudsopgave: systeemarchitectuur, ontwerpkeuzes, hardwarevereisten, monitoring en evaluatiemetrieken.

Vier: automatische logging (Artikel 12). Het systeem moet operationeel gedrag vastleggen op een manier die traceerbaar is voor toezichthouders. Vijf: transparantie naar deployers (Artikel 13). De gebruiksaanwijzing moet duidelijk maken wat het systeem wel en niet kan, wat de bekende beperkingen zijn en hoe het correct te gebruiken. Zes: menselijk toezicht (Artikel 14). De architectuur moet ingrijpen door een mens praktisch mogelijk maken, inclusief een stopknop. Zeven: accuraatheid, robuustheid en cybersecurity (Artikel 15). Het systeem moet meetbaar presteren, bestand zijn tegen fouten en beschermd tegen pogingen om met de uitkomsten te knoeien.

Voor onze klanten leveren wij deze zeven blokken inmiddels als standaard bouwpakket. Risicoregister in Markdown in de repo, datasheets per dataset, een Notion of Confluence template voor Annex IV, gestructureerde audit logs in een aparte database, een gebruikershandleiding gegenereerd uit code en docs, een human-in-the-loop interface waar nodig, en geautomatiseerde tests voor accuraatheidsdrift. Niet sexy, wel verkoopbaar tegenover enterprise inkopers en wel verdedigbaar tegenover toezichthouders.

Vijf typische mkb-scenarios en wat u moet doen

Scenario een: u gebruikt ChatGPT Enterprise voor interne productiviteit. Beperkt risico, transparantie naar medewerkers regelen, intern AI-beleid opstellen. Geen high-risk verplichtingen. Tijdsinvestering: enkele dagen.

Scenario twee: u laat een AI-chatbot bouwen voor klantenservice. Beperkt risico, mits het niet over essentiële diensten beslist. Toon bij eerste interactie dat het AI is. Log gesprekken voor kwaliteit. Werk een escalatieprocedure naar een mens uit. Tijdsinvestering: enkele weken bij ontwerp.

Scenario drie: u bouwt een SaaS waarin een AI-component sollicitanten screent. High-risk. Alle zeven verplichtingen van toepassing. CE-markering aanvragen via een notified body of via interne controle. Registratie in de EU-databank voor high-risk systemen. Tijdsinvestering: maanden, bij voorkeur ingebouwd vanaf het begin.

Scenario vier: u verkoopt verzekeringen en gebruikt machine learning voor premieberekening per individu. High-risk. Documenteer historische trainingsdata, monitor op gevoelige attributen, maak premieuitlegbaarheid mogelijk voor de klant. Werk samen met de actuariële afdeling aan datakwaliteit. Tijdsinvestering: substantieel, vooral data governance.

Scenario vijf: u laat een logistiek dashboard bouwen met AI voor routeoptimalisatie. Minimaal risico, mits het geen individuele werknemers beoordeelt. Geen verplichtingen onder de AI Act. Wel verstandig om uitlegbaarheid en monitoring te regelen, want klantvertrouwen en auditbaarheid blijven belangrijk.

Boetes en hoe handhaving er in de praktijk uitziet

De wet kent een driestaps boetestructuur, vastgelegd in Artikel 99. Maximaal 35 miljoen euro of 7 procent van de wereldwijde jaaromzet voor verboden praktijken zoals social scoring of manipulatieve technieken. Maximaal 15 miljoen euro of 3 procent voor het niet naleven van high-risk verplichtingen. Maximaal 7,5 miljoen euro of 1 procent voor het verstrekken van onjuiste informatie aan toezichthouders. Voor mkb mogen lidstaten een verlaagd maximum hanteren, maar het concept is duidelijk: serieuze overtredingen worden serieus aangepakt.

Belangrijker dan de theoretische maxima is hoe handhaving er in de praktijk uitziet. Onderzoeken starten zelden uit eigen beweging van de toezichthouder. Ze beginnen vrijwel altijd met een klacht: van een afgewezen sollicitant, een ontevreden klant, een ex-werknemer, een journalist of een concurrent. Daarnaast eisen enterprise inkopers in toenemende mate AI Act compliance als procurement-voorwaarde. Een softwareleverancier zonder geloofwaardige documentatie verliest binnenkort tenders bij grote klanten, lang voordat een boete in beeld komt.

Voor Nederland is de Autoriteit Persoonsgegevens aangewezen als coördinerend toezichthouder voor algoritmes en AI. Sectorale toezichthouders zoals de AFM (financieel) en NZa (zorg) houden zich aan hun eigen domein. In de praktijk betekent dat dat aanvragen om documentatie en proactieve audits via verschillende routes kunnen komen.

Praktische checklist voor 2 augustus 2026

Begin met een AI-inventarisatie. Welke AI-systemen gebruikt u, in welke processen, en wat is de uitkomst per gebruiker? Zonder dit overzicht is geen risico-inschatting mogelijk. Wij doen dit voor klanten in een halve dag met een gestructureerd interview en een review van de codebase. Daarna classificeert u per systeem het risiconiveau: verboden, hoog, beperkt of minimaal. Documenteer de redenering, ook als de uitkomst minimaal risico is.

Voor elk high-risk systeem start u de zeven Artikel 9-15 trajecten parallel. Wijs een interne eigenaar aan: niet IT, niet legal, maar iemand die beide kan vertalen. Plan tijd in voor CE-conformiteitsbeoordeling. Registreer u in de EU-databank zodra het systeem operationeel is. Stel een incident response procedure op en test hem. Train uw medewerkers, zowel de bouwers als de gebruikers.

Vergeet de externe contracten niet. Als u AI inkoopt bij een leverancier, moet uw contract de aansprakelijkheid en documentatieplichten duidelijk verdelen. Veel bestaande SaaS-contracten zwijgen hierover. Aanpassen kost tijd en goede wil van de leverancier. Begin daarmee voordat u in juli ontdekt dat uw leverancier niet kan leveren wat u nodig hebt.

Hoe wij AI-systemen AI Act compliant bouwen

Bij MG Software starten we elk AI-project met een risicoclassificatie tijdens de discovery-fase. Dat duurt typisch twee tot vier uur en bepaalt of we lichte compliance (transparantie, logging) of zware compliance (alle zeven verplichtingen) ontwerpen. De architectuur, de keuze van het model en de datalaag worden daar direct op afgestemd. Een high-risk systeem bouwen we niet op een blackbox-API zonder logging-mogelijkheden. We kiezen modellen waar we de inputs en outputs van kunnen vastleggen.

Documentatie schrijven we niet aan het einde van het project. Annex IV-velden vullen we op gedurende de sprints, hetzelfde moment waarop we de feature bouwen. De risico-analyse staat in dezelfde repo als de code. De datasheets staan bij de migraties. De gebruikersinstructie staat in de docs-folder. Bij oplevering hebben klanten een werkend systeem en een compliance-pakket dat een audit doorstaat.

Heeft u een bestaand AI-systeem zonder duidelijke documentatie? Dan voeren wij een compliance-audit uit met een concreet herstelplan en een tijdlijn voor 2 augustus 2026. Wij brengen in kaart wat ontbreekt, schatten in hoeveel werk nodig is en doen vaak de implementatie. Voor een snelle indicatie van scope en kosten kunt u onze project calculator gebruiken, of direct een gesprek inplannen.

Conclusie

De EU AI Act is geen reden om AI uit uw bedrijf te halen. Het is een reden om volwassener met AI om te gaan. Voor de meeste mkb-toepassingen is de last beperkt en de werkdruk redelijk. Voor high-risk systemen is het serieus werk, maar werk dat zich terugbetaalt in betrouwbaardere systemen en in geloofwaardigheid tegenover klanten en partners.

De deadline van 2 augustus 2026 is hard. Wie nu begint heeft tijd om het goed te doen. Wie wacht tot juli zit straks met overhaaste documentatie, last-minute architectuurkeuzes en het reële risico dat een belangrijke klant of toezichthouder eerder ingrijpt dan u verwacht. Compliance is geen kostenpost als u het vroeg inbouwt. Het is dan een onderdeel van goed ingenieurschap.