De eerste vraag die de EU AI Act aan elke organisatie stelt, is niet "gebruik je AI". Het is: "wat ben je". Aanbieder of gebruiksverantwoordelijke. Dat antwoord bepaalt welke verplichtingen op je van toepassing zijn. En de meeste organisaties beantwoorden het verkeerd.
Erger nog: je kunt van het ene op het andere moment veranderen van gebruiksverantwoordelijke naar aanbieder, zonder dat je het doorhebt. Automatisch. Zonder registratie. Zonder waarschuwing. En de aanbieder draagt de zwaarste verplichtingen van de hele wet.
Dit artikel legt het onderscheid uit, en laat zien hoe een organisatie ongemerkt aanbieder wordt. Met de wettekst als enige bron.
De twee hoofdrollen
De EU AI Act (Verordening (EU) 2024/1689) onderscheidt verschillende "operatoren" in de AI-keten. De twee belangrijkste voor de meeste organisaties:
Aanbieder (provider). Volgens Artikel 3, lid 3: degene die een AI-systeem ontwikkelt of laat ontwikkelen en het onder de eigen naam of het eigen merk op de markt brengt of in gebruik neemt. De bouwer, de uitgever, de eigenaar van het systeem.
Gebruiksverantwoordelijke (deployer). Volgens Artikel 3, lid 4: degene die een AI-systeem onder eigen verantwoordelijkheid gebruikt, in een professionele context. De organisatie die de AI inzet voor het eigen werk.
Het verschil lijkt simpel. De ontwikkelaar van ChatGPT is de aanbieder. Het bedrijf dat ChatGPT gebruikt is de gebruiksverantwoordelijke. Tot zover helder.
Waarom de rol alles bepaalt
De twee rollen dragen totaal verschillende verplichtingen. De aanbieder draagt het leeuwendeel.
Een aanbieder van een hoog-risico systeem moet onder andere:
Een risicobeheersysteem opzetten (Artikel 9)
Voldoen aan strenge eisen voor datakwaliteit (Artikel 10)
Volledige technische documentatie aanleggen (Artikel 11 en Annex IV)
Logging inbouwen (Artikel 12)
Een conformiteitsbeoordeling laten uitvoeren voordat het systeem op de markt komt
Het systeem registreren in de EU-databank
Doorlopend de werking monitoren na introductie
Een gebruiksverantwoordelijke van een hoog-risico systeem heeft een lichter pakket (Artikel 26):
Het systeem gebruiken volgens de instructies van de aanbieder
Menselijk toezicht organiseren
Relevante input-data monitoren
Logs bewaren
Betrokkenen informeren waar vereist
Het verschil in last is enorm. Daarom is de rol-vraag geen formaliteit. Wie denkt gebruiksverantwoordelijke te zijn, maar feitelijk aanbieder is, mist het grootste deel van de eigen verplichtingen. En weet dat niet.
Artikel 4 geldt voor beide rollen
Eén verplichting maakt geen onderscheid: de AI-geletterdheid van Artikel 4 geldt voor aanbieders én gebruiksverantwoordelijken. Beide moeten zorgen voor voldoende AI-geletterdheid bij hun personeel.
Dat is logisch. Of je AI bouwt of gebruikt, in beide gevallen werken er mensen met AI die moeten weten wat ze doen. Maar de invulling verschilt. Een aanbieder heeft mensen nodig die de techniek diep begrijpen. Een gebruiksverantwoordelijke heeft mensen nodig die het systeem oordeelkundig kunnen inzetten en controleren.
De valkuil: ongemerkt aanbieder worden
Hier wordt het serieus. Artikel 25 van de AI Act regelt dat een gebruiksverantwoordelijke automatisch verandert in een aanbieder, met alle aanbieder-verplichtingen, in drie situaties.
De wettekst van Artikel 25, lid 1, noemt deze drie triggers voor hoog-risico AI-systemen:
Trigger 1: eigen naam of merk
Een organisatie zet de eigen naam of het eigen merk op een hoog-risico AI-systeem dat al op de markt is. Vanaf dat moment is die organisatie de aanbieder, tenzij contractueel anders is geregeld.
In de praktijk: een bedrijf koopt een AI-tool in, plakt er het eigen label op, en biedt het aan klanten aan als eigen product. Het bedrijf denkt: wij verkopen alleen. De wet zegt: jullie zijn de aanbieder.
Trigger 2: substantiële wijziging
Een organisatie maakt een "substantiële wijziging" aan een hoog-risico AI-systeem dat al op de markt is, op een manier waardoor het hoog-risico blijft.
Artikel 3, lid 23 definieert een substantiële wijziging als een verandering na introductie die niet was voorzien in de oorspronkelijke conformiteitsbeoordeling, en die de naleving van de wet raakt of het beoogde doel verandert.
In de praktijk is dit de meest verraderlijke trigger. Want wat telt als substantiële wijziging? Op basis van de wettekst en de gangbare uitleg vallen hieronder bijna altijd:
Het fine-tunen van een ingekocht of open-source model op de eigen data
Het zo aanpassen van een systeem dat het anders presteert dan oorspronkelijk beoordeeld
Het uitbreiden van de functionaliteit voorbij wat de aanbieder had gedocumenteerd
Organisaties die open-source modellen fine-tunen voor productiegebruik moeten hier bijzonder goed opletten. Het voelt als gebruiken. Juridisch is het bouwen.
Trigger 3: ander beoogd doel
Een organisatie verandert het beoogde doel van een AI-systeem (ook een general-purpose systeem) dat niet als hoog-risico was geclassificeerd, op een manier waardoor het wel hoog-risico wordt onder Artikel 6.
In de praktijk: een AI-tool voor het samenvatten van documenten wordt ingezet om beslissingen over medewerkers te ondersteunen. Het oorspronkelijke doel was laag risico. Het nieuwe doel (besluiten over personen) is hoog risico. De organisatie die deze verschuiving maakt, wordt de aanbieder.
Het venijn: de herclassificatie is automatisch
Dit is het punt dat in vrijwel geen enkele uitleg duidelijk wordt gemaakt. De overgang van gebruiksverantwoordelijke naar aanbieder gebeurt vanzelf. Er is geen registratieproces. Geen melding. Geen moment waarop een toezichthouder je een brief stuurt.
Als aan de voorwaarden is voldaan, ben je aanbieder onder de wet. Met alle bijbehorende verplichtingen. Ongeacht wat het contract met de oorspronkelijke leverancier zegt.
Dat betekent: een organisatie kan vandaag denken dat ze gebruiksverantwoordelijke is, een model fine-tunen voor een hoog-risico toepassing, en daarmee aanbieder zijn geworden zonder enige bewuste handeling die "aanbieder worden" heette. De verplichtingen gelden vanaf dat moment, niet vanaf het moment dat iemand het doorheeft.
Productfabrikanten: een aparte regel
Artikel 25, lid 3 regelt een specifiek geval. Wanneer een hoog-risico AI-systeem een veiligheidscomponent is in een product dat onder bestaande EU-harmonisatiewetgeving valt (Annex I, denk aan medische hulpmiddelen, machines, voertuigen), dan wordt de productfabrikant de aanbieder van het AI-systeem op het moment dat het geïntegreerde product onder de eigen naam op de markt komt.
Voor fabrikanten in deze sectoren is dit cruciaal. De AI in hun product maakt hen tot AI-aanbieder, met alle verplichtingen van dien.
De boete-component, recent verzwaard
Sinds de wijzigingen van mei 2026 in het AI-omnibus pakket zijn de informatie-verplichtingen tussen de oorspronkelijke aanbieder en de partij die nieuw aanbieder wordt (Artikel 25, lid 2 en 4) expliciet opgenomen in de boetestaffel. Overtreding valt nu in dezelfde band als schending van de kernverplichtingen voor aanbieders: tot 15 miljoen euro of 3% van de wereldwijde jaaromzet, wat hoger is (Artikel 99, lid 4).
De wetgever heeft de keten dus aangescherpt, niet versoepeld. Wie aanbieder wordt en de bijbehorende informatie-uitwisseling niet regelt, loopt reëel boeterisico.
Waarom dit zo vaak misgaat
Drie redenen waarom organisaties hun rol verkeerd inschatten.
Het contract is misleidend. Organisaties vertrouwen op het inkoopcontract met de leverancier. Maar Artikel 25 werkt ongeacht het contract. Een clausule "wij zijn slechts gebruiker" beschermt niet als de feitelijke situatie anders is.
Fine-tunen voelt niet als bouwen. Het technisch aanpassen van een bestaand model voelt als configuratie, niet als ontwikkeling. Juridisch ligt de grens anders.
Intern gebruik telt mee. Veel organisaties denken dat de wet alleen geldt als je AI verkoopt. Maar de AI Act dekt ook systemen die "in gebruik worden genomen", inclusief interne inzet. Een intern gebouwd of substantieel aangepast hoog-risico systeem maakt de organisatie tot aanbieder, ook zonder externe verkoop.
Hoe bepaal je je eigen rol: vier vragen
Voor elke AI-toepassing in de organisatie, beantwoord deze vier vragen.
Vraag 1: hebben we dit systeem ontwikkeld of laten ontwikkelen? Zo ja, en het komt onder onze naam in gebruik, dan zijn we aanbieder.
Vraag 2: hebben we onze naam of merk op een ingekocht systeem gezet? Zo ja en het is hoog risico, dan zijn we waarschijnlijk aanbieder geworden.
Vraag 3: hebben we een ingekocht systeem substantieel aangepast? Denk aan fine-tuning, functionele uitbreiding, of een wijziging die de prestaties verandert. Zo ja en het blijft hoog risico, dan zijn we aanbieder geworden.
Vraag 4: gebruiken we een systeem voor een ander doel dan waarvoor het bedoeld was? Zo ja, en dat nieuwe doel maakt het hoog risico, dan zijn we aanbieder geworden.
Eén keer "ja" op vraag 2, 3 of 4 voor een hoog-risico toepassing betekent: de zware aanbieder-verplichtingen gelden. Dit is geen theorie. Het is de tekst van Artikel 25.
Wat dit betekent voor AI-geletterdheid
De rol-vraag laat precies zien waarom AI-geletterdheid geen luxe is. De mensen die binnen een organisatie beslissen om een model te fine-tunen, een tool te herbranden, of een systeem voor een nieuw doel in te zetten, moeten begrijpen wat die beslissing juridisch betekent.
Een data scientist die een open-source model fine-tunet zonder te weten dat de organisatie daarmee aanbieder wordt, creëert een compliance-gat dat niemand ziet tot een toezichthouder belt. Dat is geen technisch probleem. Het is een geletterdheidsprobleem.
Voldoende AI-geletterdheid betekent dus ook: weten wanneer een handeling de rol van de organisatie verandert. Dat hoort in elke serieuze AI-training thuis, en het ontbreekt in vrijwel alle generieke modules.
Tot slot
De vraag "aanbieder of gebruiksverantwoordelijke" is de meest fundamentele en meest onderschatte vraag van de hele EU AI Act. Het antwoord bepaalt welke verplichtingen gelden. En het antwoord kan veranderen door handelingen die onschuldig lijken.
Voor 2 augustus 2026 is er tijd om per AI-toepassing de rol vast te stellen, en om te zorgen dat de mensen die de rol kunnen veranderen, weten wat ze doen. Wie dat nalaat, ontdekt de eigen rol pas wanneer het te laat is om er nog iets aan te veranderen.
Wil je weten welke rol jouw organisatie heeft per AI-toepassing, en of er een onbedoelde aanbieder-situatie speelt? Doe de gratis AI-Risicoscan en breng het in vijf minuten in kaart.
Ferry Hoes
Ferry Hoes is veelgevraagd spreker en trainer op het gebied van AI-geletterdheid. Hij staat meermaals per maand op het podium voor organisaties zoals a.s.r., VodafoneZiggo en verschillende ministeries. In 2020 won hij de Anti-Discriminatie AI-Hackathon van de Nederlandse overheid.