Aanbieder of gebruiksverantwoordelijke onder de AI Act

Je koopt een AI-tool in, zet een AI-functie in een bestaande SaaS-applicatie aan, of finetunet een taalmodel op eigen data. In alle drie de gevallen stelt de AI Act dezelfde vraag: welke rol heb je, en welk pakket plichten hoort daarbij? Wie een systeem alleen gebruikt, draagt iets anders dan wie het op de markt brengt. Het lastige is dat je van rol kunt wisselen zonder dat je dat merkt: je eigen naam op een tool, een aanpassing die verder gaat dan bedoeld, of een toepassing die de leverancier nooit voor ogen had. Dit stuk zet de vier rollen naast elkaar, laat precies zien wanneer een gebruiksverantwoordelijke aanbieder wordt, en werkt drie herkenbare situaties uit.

De vier rollen op een rij

De AI Act kent vier hoofdrollen in de waardeketen³. Ze zijn niet gelijkwaardig: de aanbieder draagt het zwaarste pakket, de andere drie dragen een lichtere, aanvullende verantwoordelijkheid.

De aanbieder ontwikkelt een AI-systeem of GPAI-model en brengt het onder eigen naam of merk op de markt, of stelt een hoog-risico systeem onder eigen naam in gebruik. De gebruiksverantwoordelijke (deployer) zet een systeem in onder eigen gezag, tenzij het gaat om een zuiver persoonlijke, niet-beroepsmatige activiteit. De importeur is in de EU gevestigd en brengt een systeem op de markt dat de naam of het merk draagt van een partij buiten de EU. De distributeur is elke andere partij in de keten die het systeem op de markt beschikbaar stelt zonder de eigenschappen ervan te wijzigen.

| Rol | Wat je doet | Kernplichten (kort) | Wanneer afdwingbaar | |---|---|---|---| | Aanbieder | Brengt systeem of GPAI-model onder eigen naam op de markt | Art. 16: kwaliteitssysteem, technische documentatie, conformiteitsbeoordeling, CE-markering, registratie¹ | Hoog risico: 2 dec 2027 (Bijlage III) / 2 aug 2028 (Bijlage I); GPAI: sinds 2 aug 2025 | | Gebruiksverantwoordelijke | Gebruikt het systeem onder eigen gezag | Art. 26: volgens instructies, menselijk toezicht, monitoring, logbewaring, werknemers informeren¹ | Hoog risico: 2 dec 2027 / 2 aug 2028 | | Importeur | Brengt een systeem van buiten de EU op de markt | Art. 23: vier checks bij de aanbieder vóór levering, tien jaar bewaarplicht¹ | Hoog risico: 2 dec 2027 / 2 aug 2028 | | Distributeur | Maakt het systeem beschikbaar zonder het te wijzigen | Art. 24: markering en documentatie controleren, corrigeren of terugroepen bij non-conformiteit¹ | Hoog risico: 2 dec 2027 / 2 aug 2028 |

Twee dingen gelden nu al, voor elke rol: het verbod op onaanvaardbare AI-praktijken uit artikel 5 en de AI-geletterdheidsplicht van artikel 4 zijn van kracht sinds 2 februari 2025¹. Voor artikel 5 heeft de Europese Commissie richtsnoeren gepubliceerd die precies afbakenen welke praktijken eronder vallen⁴. Artikel 4 is per 27 juli 2026 herschreven tot een maatregelenplicht: je neemt maatregelen die AI-geletterdheid ondersteunen, je garandeert geen individueel vaardigheidsniveau². De hoog-risicoplichten van aanbieder en gebruiksverantwoordelijke uit de tabel gelden pas vanaf 2 december 2027 voor Bijlage III systemen, na de verschuiving die de Digital Omnibus in het gewijzigde artikel 113 heeft aangebracht².

Wanneer word je aanbieder: dit is de kern

Artikel 25, lid 1, bepaalt dat een distributeur, importeur, gebruiksverantwoordelijke of andere derde partij als aanbieder van een hoog-risico AI-systeem geldt zodra een van drie dingen gebeurt:

1. Je zet je eigen naam of merk op het systeem.
2. Je wijzigt het systeem substantieel.
3. Je verandert het beoogde doel zo dat een systeem dat niet hoog risico was, dat wel wordt.

Dat is geen theoretisch scenario. Het overkomt vooral organisaties die AI whitelabelen, een generiek model inzetten voor een Bijlage III-toepassing, of een leverancierstool doorontwikkelen tot een eigen product¹. Vanaf dat moment gelden niet langer de lichtere plichten van je oorspronkelijke rol, maar de volledige twaalf punten van artikel 16: kwaliteitsbeheersysteem, technische documentatie, conformiteitsbeoordeling, CE-markering, registratie, en meer¹. Contractuele afspraken kunnen die verplichtingen anders verdelen, maar dan moet je die afspraken vooraf hebben gemaakt en kunnen tonen. Zet de rolvraag daarom in elk AI-project als vaste stap, niet als eenmalige check bij inkoop.

Drie situaties

Situatie 1: standaard-SaaS met een AI-functie

Een organisatie gebruikt een CRM- of HR-platform waarin de leverancier een AI-samenvatting of aanbeveling heeft ingebouwd. De organisatie gebruikt de functie zoals geleverd, zonder eigen merk erop, zonder wijziging aan het model, voor het doel dat de leverancier beschreef. Dit blijft gebruiksverantwoordelijke. De plichten van artikel 26 gaan pas gelden zodra het systeem hoog risico is; tot die tijd blijft artikel 4 relevant, met name als de AI-functie beslissingen over personeel of klanten beïnvloedt. Bewaar de leveranciersdocumentatie: die vorm je later om tot je eigen dossier als het systeem alsnog onder Bijlage III valt.

Situatie 2: een taalmodel finetunen en als eigen tool aanbieden

Een organisatie finetunet een open taalmodel op eigen klantdata en biedt het resultaat als eigen tool aan klanten aan, onder een eigen productnaam. Dat eigen merk op het resultaat is precies de eerste trigger van artikel 25: de organisatie wordt aanbieder, met de volledige plichten van artikel 16 voor het eindsysteem en mogelijk de plichten van artikel 53 als het onderliggende model als GPAI-model kwalificeert⁵. Niet elke aanpassing maakt je overigens aanbieder van het GPAI-model zelf: de indicatieve grens ligt bij een aanpassing die meer dan een derde van de trainingscompute van het oorspronkelijke model gebruikt; blijf je daaronder, dan blijven je eigen plichten beperkt tot de aanpassing die je hebt aangebracht. De rol van aanbieder van het eindsysteem dat je onder eigen naam aanbiedt aan klanten, staat daar los van.

Situatie 3: een ander doel dan de leverancier bedoelde

Een organisatie koopt een AI-systeem in dat de leverancier positioneert voor administratieve documentclassificatie, en zet het vervolgens in voor de beoordeling van sollicitanten of de evaluatie van personeel. Dat is de derde trigger van artikel 25: als die doelverandering het systeem in een Bijlage III-categorie brengt, zoals werving en selectie, ontstaat een rolwissel met gevolgen. De organisatie krijgt niet alleen de volledige aanbiedersplichten van artikel 16 op haar bord, maar moet ook zaken regelen waar ze niet op had begroot: menselijk toezicht door bevoegde personen met mandaat, het informeren van de ondernemingsraad vóór ingebruikname, en bij een publiekrechtelijke instantie of een private partij die publieke diensten levert een grondrechteneffectbeoordeling onder artikel 27¹. Die FRIA-plicht volgt de Bijlage III-kalender van 2 december 2027, en delen van een bestaande DPIA mogen daarbij worden hergebruikt of aangehaald.

Incidenten: wie meld je eerst (artikel 26, lid 5)

Bij een ernstig incident met een hoog-risico systeem geldt voor de gebruiksverantwoordelijke een vaste volgorde, niet een vrije keuze. Je informeert eerst de aanbieder, en daarnaast de importeur of distributeur en de bevoegde markttoezichthouder¹. Is de aanbieder niet bereikbaar, dan valt die eerste stap niet weg maar verschuift de meldplicht: dan geldt de eigen meldplicht van artikel 73 voor de gebruiksverantwoordelijke zelf, met de bijbehorende termijnen. Leg dit tweekanalenpatroon nu al vast in je incidentprocedure, inclusief actuele contactgegevens van elke leverancier, zodat je tijdens een incident niet voor het eerst hoeft uit te zoeken wie waarvoor verantwoordelijk is.

Boetes: de rol bepaalt wie er staat, niet hoe hoog het maximum is

Artikel 99 kent twee plafonds: tot 35 miljoen euro of 7% van de wereldwijde jaaromzet voor verboden praktijken onder artikel 5, en tot 15 miljoen euro of 3% voor de meeste andere schendingen¹. Voor kmo's en start-ups geldt telkens het laagste van de twee bedragen, niet het hoogste. Welk plafond en welke partij aan de orde zijn, hangt af van wiens plicht is geschonden: een aanbieder die geen conformiteitsbeoordeling deed, of een gebruiksverantwoordelijke die geen menselijk toezicht had ingericht. De rolbepaling uit artikel 25 is daarom niet alleen een compliance-vraag, maar bepaalt ook wie de toezichthouder aanspreekt.

Zelftest: vijf vragen

1. Staat jouw naam of merk op het systeem, of dat van de oorspronkelijke leverancier?
2. Heb je het systeem na levering substantieel gewijzigd, bijvoorbeeld een ander onderliggend model, nieuwe functionaliteit of eigen trainingsdata?
3. Zet je het systeem in voor het doel dat de leverancier beschreef, of voor iets anders?
4. Als het doel is veranderd: brengt dat gebruik het systeem in een Bijlage III-categorie?
5. Weet je wie je als eerste informeert bij een ernstig incident, en klopt dat contact nog?

Beantwoord je vraag 1 of 2 met ja, of vraag 3 en 4 met "iets anders" plus "ja": ga dan uit van een rolwissel richting aanbieder, en werk de twaalf punten van artikel 16 uit als afzonderlijke werkpakketten.

Veelgestelde vragen

Kan ik tegelijk aanbieder en gebruiksverantwoordelijke zijn?

Ja. Dat gebeurt bijvoorbeeld als je een systeem zelf bouwt of aanpast en het ook intern gebruikt: dan draag je beide pakketten plichten voor hetzelfde systeem, en tellen ze op. Voor verschillende systemen kun je bovendien per systeem een andere rol hebben.

Verandert de Digital Omnibus wie er als aanbieder geldt?

Nee. De definitie en de drie triggers van artikel 25 zijn ongewijzigd. De Digital Omnibus verschuift vooral de toepassingsdata van de hoog-risicoplichten en herschrijft artikel 4 tot een maatregelenplicht.

Moet ik nu al iets doen als de hoog-risicoplichten pas in 2027 gelden?

Ja, op twee punten. Artikel 4 en artikel 5 gelden al sinds februari 2025, voor elke rol. En als je nu al weet dat een systeem in 2027 onder Bijlage III gaat vallen, kost het informeren van de ondernemingsraad en het opzetten van menselijk toezicht meer tijd dan je denkt: begin dat traject ruim voor de deadline.

Wat als de aanbieder niet reageert bij een ernstig incident?

Dan blijft de meldplicht aan de aanbieder overeind staan als eerste stap, maar verschuift de verantwoordelijkheid: de gebruiksverantwoordelijke krijgt dan zelf de meldplicht van artikel 73, met eigen termijnen richting de toezichthouder.

Betekent finetunen automatisch dat ik aanbieder word?

Niet automatisch voor het onderliggende GPAI-model: de indicatieve grens ligt bij een aanpassing die meer dan een derde van de oorspronkelijke trainingscompute gebruikt. Bied je het resultaat wel onder een eigen naam of merk aan klanten aan, dan wordt je hoe dan ook aanbieder van dat eindsysteem.

Wat is het verschil tussen importeur en distributeur?

De importeur is de EU-partij die als eerste een systeem van buiten de EU op de markt brengt en moet vooraf vier dingen bij de aanbieder controleren. De distributeur is elke andere partij verderop in de keten die het systeem beschikbaar stelt zonder het te wijzigen, en moet vooral markering, documentatie en de naleving door aanbieder en importeur checken.