GovCompass

Provider-verplichtingen: een overzicht voor MKB

Door GovCompass.ai· Laatst bijgewerkt augustus 2026· Afgestemd op de geconsolideerde EU AI Act, inclusief de Omnibus-wijzigingen van 2026.

Een mkb-bedrijf dat zelf een hoog-risico AI-systeem ontwikkelt, draagt de volledige provider-verplichtingen van Art. 8-17 EU AI Act: risicobeheer (Art. 9), datakwaliteit (Art. 10), technische documentatie (Art. 11), logging (Art. 12), transparantie (Art. 13), menselijk toezicht (Art. 14), nauwkeurigheid (Art. 15) en een kwaliteitsmanagementsysteem (Art. 17). Micro-ondernemingen mogen een vereenvoudigd formaat gebruiken.

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 ActEU AI ActVerordening (EU) 2024/1689, in het Nederlands de AI-verordening, de Europese wet over artificiële intelligentie. Ze hanteert een risicogebaseerde aanpak: verboden praktijken, eisen voor hoogrisico-AI-systemen, transparantieverplichtingen voor specifieke toepassingen en een apart regime voor AI-modellen voor algemene doeleinden (general-purpose AI). Verplichtingen zijn verdeeld tussen aanbieders en gebruiksverantwoordelijken. Zie hoogrisico-AI-systeem, general-purpose AI, conformiteitsbeoordeling.Open full entry →. 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 biasbiasEen systematische scheefheid in data, modelgedrag of uitkomsten die de ene groep zonder rechtvaardiging anders behandelt dan de andere. Bias sluipt meestal binnen via trainingsdata die historische patronen weerspiegelen. Voor hoogrisico-AI-systemen vereist Artikel 10 van de EU AI Act onderzoek van datasets op mogelijke bias en maatregelen om die te detecteren, te voorkomen en te beperken. Zie eerlijkheid.Open full entry → 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.

Lees verder metAccountability
Delen Deel op LinkedIn

Meer over Accountability

Agentic AI en governance: waarom autonomie de beheersingsvraag verscherpt

Analysis

Agentic AI heeft geen nieuw soort governance nodig. Autonomie vergroot de afstand tussen wat een systeem doet en wie ervoor accountable is, wat de bestaande governance-keten, control die naar risico traceert en vooruit naar bewijs, belangrijker maakt, niet minder. De acties zijn echt en soms onomkeerbaar, dus de inzet op elke control stijgt.

AI governance en enterprise risk management: waar ze samenkomen

Analysis

AI governance is geen parallelle structuur die naast enterprise risk management staat. Het hoort erin. De zeven pijlers van verantwoorde AI zijn de controlestructuur waarmee de organisatie elk AI-systeem bestuurt; enterprise risk management is de machine die het restrisico dat die controls overlaten doorvoert naar de risk appetite van de board, het risicoregister, en het assurance-plan. De praktische vraag is niet of je AI governance óf ERM moet bouwen, maar hoe je het eerste in het tweede schuift zodat één aanspreekbare structuur, niet twee concurrerende, het AI-risico bezit.

AI-certificering: wat bestaat er en wat bewijst het

Analysis

AI-certificering is geen enkelvoudige categorie. Er worden drie verschillende objecten beoordeeld, elk door een ander type beoordelaar: een persoon, het AI-managementsysteem van een organisatie, en een AI-systeem dat op de EU-markt wordt gebracht. De eerste twee kunnen worden gecertificeerd. Het derde valt onder een wettelijke conformiteitsbeoordeling, die op de ene route wel een certificaat oplevert en op de andere niet. Vaststellen welk object een certificaat dekt, is de eerste stap om te bepalen wat het waard is.

Compliance op control-niveau: de EU AI Act als geïnstrumenteerd systeem

Analysis

Compliance op control-niveau betekent voldoen aan de EU AI Act via ingebouwde, bewezen controls in plaats van beleidsdocumenten. De technische artikelen vertalen direct naar systeem-controls: onveranderlijke logs (Art. 12, 19), een noodstop (Art. 14(4)(e)), datamaskering vóór het model (Art. 10), configureerbare blokkeerbeleid (Art. 26), risicoscoring en incidentmelding binnen de termijn (Art. 9, 73), en workspace-isolatie met rolgebaseerde toegang (Art. 14, 26). Compliance op dit niveau is een geïnstrumenteerd systeem, geen beleid als PDF.

Meer over Safety & reliability

Regulatory sandboxes: test je AI veilig onder toezicht

Analysis

Regulatory sandboxes onder Art. 57-61 zijn gecontroleerde omgevingen, onder toezicht van de nationale toezichthouder, waarin organisaties innovatieve AI-systemen kunnen ontwikkelen en testen met begeleiding en tijdelijke verlichting van bepaalde administratieve eisen, zonder dat de materiële waarborgen of de meldplicht bij incidenten vervallen.

Regulatory sandboxes: uitgebreide uitleg

Guide

Deelnemen aan een nationale AI regulatory sandbox onder Art. 57-61 verloopt via een gestructureerd pad: bereid een projectdossier voor, dien in tijdens een aanmeldwindow, teken een sandbox-overeenkomst met de toezichthouder, rapporteer voortgang en incidenten tijdens het testen, en lever een eindrapport op dat de basis legt voor volledige compliance.

Art. 26.1, gebruik AI volgens de instructies van de aanbieder

Reference

Art. 26.1 EU AI Act verplicht deployers om hoog-risico AI-systemen uitsluitend in te zetten conform de gebruiksinstructies van de provider. De verplichting omvat drie componenten: het beschikken over de instructies (conform Art. 13.3), het actief naleven ervan, en het documenteren van dat naleven. Inzet buiten de instructies kan de aansprakelijkheid volledig naar de deployer verschuiven.

Art. 26.4, input-data: zorg voor relevante en representatieve data

Reference

Art. 26.4 verplicht deployers van hoog-risico AI om te borgen dat de inputdata relevant en voldoende representatief is voor het beoogde doel van het systeem. De deployer is verantwoordelijk voor de datakwaliteit in gebruik, ook al stelt de provider de specificaties vast onder Art. 10.