Provider-verplichtingen: een overzicht voor MKB

Bijgewerkt: juni 2026

Inleiding: provider-verplichtingen voor mkb

Als u als mkb-bedrijf een hoog-risicorisicoIn de termen van de EU AI Act de combinatie van de waarschijnlijkheid dat een schade optreedt en de ernst ervan als dat gebeurt. De schakel tussen een principe (via de schade die het zou schenden) en een control (de maatregel die het vermindert). Het benoemen van de schade en het inschatten van het risico is op grond van Art. 9 vereist voordat een maatregel wordt gekozen. Zie schade, control, restrisico.Open full entry → AI-systeemAI-systeemEen machinaal systeem dat voor expliciete of impliciete doelen uit invoer afleidt hoe het uitvoer genereert, voorspellingen, inhoud, aanbevelingen of beslissingen, die fysieke of virtuele omgevingen kunnen beïnvloeden. De OESO-achtige definitie die de EU AI Act volgt. Zie algoritme, machine learning.Open full entry → ontwikkelt, voor eigen gebruik of voor de markt, draagt u de volledige provider-verplichtingen van Art. 8-17 EU AI Act. Deze verplichtingen zijn aanzienlijk: ze omvatten risicobeheer, datakwaliteit, technische documentatietechnische documentatieRegistraties die een aanbieder voor een hoog-risico-AI-systeem moet samenstellen en bewaren om conformiteit aan te tonen, met dekking van het ontwerp, de data, het testen, het risicobeheer en de monitoring. Zie aanbieder, bewijs, model card.Open full entry →, logging, transparantietransparantieOpenheid over het feit dát AI wordt gebruikt en hoe het in het algemeen werkt: openbaarmakingen, documentatie, kennisgevingen. Vormt een paar met uitlegbaarheid, die over individuele uitkomsten gaat. Zie uitlegbaarheid, principe.Open full entry →, menselijk toezichtmenselijk toezichtHet ingebouwde vermogen van een mens om een AI-systeem te monitoren, erin in te grijpen, het te overrulen of stil te leggen, alleen betekenisvol wanneer de mens de bevoegdheid, de informatie en de tijd heeft om te handelen. Zie principe, human-in-the-loop, human-on-the-loop.Open full entry →, nauwkeurigheid en een kwaliteitsmanagementsysteem.

Het AI Omnibus Akkoord (mei 2026) heeft vereenvoudigingen ingevoerd voor micro-ondernemingen (<10 medewerkers, <€2 mln), maar voor de meeste mkb-bedrijven gelden de volledige verplichtingen. Deze gids legt de negen kernverplichtingen uit en geeft praktische handvatten voor mkb-implementatie.

Verplichting 1: risicobeheerssysteem (Art. 9)

Art. 9 verplicht providers tot het opzetten van een doorlopend risicobeheerssysteem gedurende de gehele levenscycluslevenscyclusDe spanne van een enkel AI-systeem van eerste intake tot uitfasering, waarover het bestuurd moet worden. De horizontale as van governance: waar de governance-keten één principe borgt, voert de levenscyclus één systeem door de tijd. Doorgaans getekend als zes fasen, plan en ontwerp, data en ontwikkeling, verifieer en valideer, uitrol, gebruik en monitoring, en uitfasering, elk met controls die er eigen aan zijn en een anker-artefact. Een lus in plaats van een lijn, want een systeem in productie voert nieuw risico terug naar een verse beoordeling. Zie artefact, control, governance-keten.Open full entry → van het hoog-risico AI-systeem. Dit betekent:

• Identificatie van bekende en voorzienbare risico's voor gezondheid, veiligheid en grondrechten
• Schatting en evaluatie van die risico's
• Evaluatie van risico's na marktintroductie (op basis van post-market monitoringpost-market monitoringDe plicht aan de aanbiederszijde om ervaring met systemen in gebruik systematisch te verzamelen en erop te handelen, de productregelgevingshelft van doorlopende monitoring. Zie doorlopende monitoring, aanbieder.Open full entry → data)
• Implementatie van passende risicobeheersmaatregelen

Mkb-aanpak: Gebruik een risicoregisterrisicoregisterHet levende overzicht van de geïdentificeerde risico's van een AI-systeem, hun inschatting, respons, eigenaren en herzieningsdata, actueel gehouden van ontwerp tot uitfasering. Zie risico, control, governance-keten.Open full entry → dat voor elk geïdentificeerd risico bijhoudt: beschrijving, ernst (hoog/medium/laag), kans, mitigerende maatregel, en restrisicorestrisicoHet risico dat overblijft nadat controls het hebben verminderd. Geen control brengt een risico tot nul terug, en niet elke control is zijn kosten waard, dus wordt er een bewuste afweging gemaakt: of de kosten van verdere control opwegen tegen de risicovermindering die het oplevert, en of het resterende risico aanvaardbaar is tegen de risicobereidheid van de organisatie. Dit is een afweging op inrichtingsniveau, waar de uitvoering terugrapporteert en governance het restrisico aanvaardt, om meer control vraagt, of de use case afwijst. EU AI Act Art. 9(5) vereist dat het per gevaar en in totaal aanvaardbaar wordt geoordeeld. Zie risico, control, risicobereidheid.Open full entry → na mitigatie. Werk het register bij bij elke significante update van het systeem.

Verplichting 2: datakwaliteit (Art. 10)

Art. 10 verplicht dat de data die wordt gebruikt voor training, validatie en testing van hoog-risico AI-systemen voldoet aan kwaliteitscriteria: relevant, representatief, vrij van fouten, en volledig, voor zover dat redelijkerwijs haalbaar is.

Aanvullend verplicht Art. 10.2:

• Dataverzamelingsprocessen te documenteren
• Relevante kenmerken van de data-populatie te beschrijven
• Te onderzoeken op biassen die tot discriminatie kunnen leiden
• Maatregelen te nemen om geïdentificeerde bias te mitigeren

Mkb-aanpak: Maak een datasheetdatasheetEen document dat de herkomst van een dataset vastlegt: de bronnen, de rechten waaronder ze wordt gebruikt, de samenstelling en de bekende beperkingen. Het anker-artefact van de fase data en ontwikkeling, het maakt de data achter een model herleidbaar en is een voorwaarde voor het beoordelen van risico's zoals bias. Zie artefact, levenscyclus.Open full entry → (datablad) per dataset: herkomstherkomstDe gedocumenteerde oorsprong en geschiedenis van data of inhoud, gebruikt om vast te stellen waar ze vandaan komt en of ze betrouwbaar of rechtmatig te gebruiken is. Zie trainingsdata, datasheet.Open full entry →, grootte, populatiebeschrijving, bekende beperkingen, bias-checks uitgevoerd. Bewaar dit als onderdeel van de technische documentatie.

Verplichting 3: technische documentatie (Art. 11 + Bijlage IV)

Art. 11 verplicht providers een uitgebreid technisch document op te stellen vóór marktintroductie en bij te houden gedurende de levenscyclus. Bijlage IV beschrijft de vereiste inhoud in detail.

Kernonderdelen van de technische documentatie:

• Systeembeschrijving en beoogd gebruik
• Risicoklasse en classificatiegrondslag
• Ontwerp- en trainingsproces
• Beschrijving van training-, validatie- en testdata
• Risicobeheersmaatregelen
• Prestatiemetrieken en testresultaten
• Beperkingen en bekende risico's
• Wijzigingshistorie

Mkb-vereenvoudiging (Omnibus): Micro-ondernemingen mogen een vereenvoudigd formaat gebruiken. Voor andere mkb geldt de volledige Bijlage IV. Gebruik de EU AI Office-sjablonen om het schrijfwerk te structureren.

Verplichting 4: logboek (Art. 12)

Art. 12 verplicht dat hoog-risico AI-systemen zijn uitgerust met automatische logging-functionaliteit. De logging moet registreren: het gebruik van het systeem, de verwerkte data (of een referentie), en relevante operationele gebeurtenissen.

Mkb-aanpak: Implementeer logging als technische feature van het systeem, niet als een achteraf-gedachte. De logs moeten exporteerbaar zijn in een standaardformaat (JSON, CSV) zodat deployers hun bewaarverplichting kunnen naleven.

Verplichting 5: transparantie (Art. 13)

Art. 13 verplicht providers om hoog-risico AI-systemen zo te ontwerpen dat deployers de werking voldoende begrijpen om hun verplichtingen te kunnen nakomen. Art. 13.3 verplicht gedetailleerde gebruiksinstructies (zie het Art. 26.1-artikel voor de vereiste inhoud).

Mkb-aanpak: Schrijf gebruiksinstructies die compleet maar begrijpelijk zijn. Gebruik voorbeelden voor de beschrijving van beperkingen. Test de instructies op een deployer uit uw doelgroep die het systeem nog niet kent.

Verplichting 6: menselijk toezicht (Art. 14)

Art. 14 verplicht dat hoog-risico AI-systemen zo zijn ontworpen dat toezichthouders de werking kunnen begrijpen, afwijkingen kunnen detecteren, automatisch vertrouwen kunnen vermijden, en het systeem kunnen overrulen of stoppen.

Technische implementatie:

• Toon vertrouwensscores bij elke output
• Markeer outputs met lage betrouwbaarheid visueel
• Implementeer een "override" functie die de toezichthouder in staat stelt de AI-aanbeveling te negeren
• Implementeer een noodstop (Art. 14.4.e)

Verplichting 7: nauwkeurigheid, robuustheid en cyberbeveiliging (Art. 15)

Art. 15 verplicht dat hoog-risico AI-systemen een passend niveau van nauwkeurigheid bereiken en behouden, robuust zijn tegen fouten en onvoorziene omstandigheden, en beschermd zijn tegen aanvallen die de prestaties kunnen beïnvloeden.

Mkb-aanpak: Definieer vóór marktintroductie acceptabele prestatiegrenzen (nauwkeurigheid, foutpercentages) en test hierop. Documenteer de testresultaten in de technische documentatie. Beschrijf de cyberbeveiligingsmaatregelen (inputvalidatie, toegangscontrole, logging van aanvalspogingen).

Verplichting 8: kwaliteitsmanagementsysteem (Art. 17)

Art. 17 verplicht providers tot het opzetten van een kwaliteitsmanagementsysteem (KMS) dat de naleving van de EU AI Act borgt gedurende de gehele levenscyclus.

Mkb-vereenvoudiging (Omnibus voor micro): Micro-ondernemingen mogen volstaan met een proportioneel kwaliteitsbeleid. Voor andere mkb geldt een volledig KMS dat minimaal omvat: beleid voor naleving, procedures voor technische documentatie, procedures voor post-market monitoring, en procedures voor corrigerende maatregelen.

Verplichting 9: post-market monitoring (Art. 72)

Art. 72 verplicht providers tot een post-market monitoring plan dat actief data verzamelt over de prestaties van het systeem in productie. Deployers leveren input via hun Art. 26.5-verplichtingen.

Mkb-aanpak: Stel een eenvoudig monitoring-plan op dat beschrijft: welke metrieken worden gemonitord, via welk kanaal deployers bevindingen melden, en hoe u reageert op afwijkingen. Maak het plan onderdeel van uw leveranciersovereenkomst.

Samenvatting

Provider-zijn is zwaarder dan deployer-zijn. De negen verplichtingen van Art. 9-17 vereisen een gestructureerde aanpak van ontwerp tot post-markt. Start vroeg met de technische documentatie en het risicobeheerssysteem, deze vormen de kern van alle andere verplichtingen. Gebruik de EU AI Office-sjablonen om het werk te structureren en de naleving aantoonbaar vast te leggen.