Artikel 25 AI Act: wanneer wordt deployer aanbieder?
Artikel 25 van de AI Act maakt een deployer in drie situaties zelf aanbieder van een high-risk AI-systeem: re-branding, substantiële modificatie en purpose-change. Elke transitie activeert de volledige Artikel 16-verplichtingen: onder meer een kwaliteitsmanagementsysteem, technische documentatie, conformity assessment, CE-markering en registratie in de EU-database. Deze pagina werkt de drie scenario's uit, met de Artikel 3(23)-toets voor substantiële modificatie en zes concrete MKB-situaties met een verdict per geval.
Prometheus21 helpt MKB toetsen of hun AI-inzet accidentele provider-status triggert. Onderdeel van onze AI compliance-aanpak.
Je dacht dat je deployer was. Klopt dat nog na de laatste wijziging?
Artikel 25 AI Act regelt rolwisseling in de AI-waardeketen. Drie scenarios maken een deployer, distributeur of importeur tot volwaardig provider van een high-risk AI-systeem, met alle bijbehorende verplichtingen uit Artikel 16. De wetgever wil daarmee voorkomen dat compliance-verantwoordelijkheid weglekt door partijen die materieel het systeem vormgeven zonder formeel provider te zijn. Voor MKB betekent dit: je inzet van AI kan ongemerkt rol-transitie triggeren. Fine-tuning van een foundation-model, re-branding van een SaaS-oplossing, purpose-shift naar een high-risk use-case: alle drie kwalificeren.
De drie scenarios uit Artikel 25 lid 1 zijn technisch helder en op MKB-schaal vaak relevanter dan de wettekst doet vermoeden. Sub (a) dekt white-label re-branding: zet je jouw merk op een bestaand high-risk AI-systeem, dan ben je provider. Sub (b) dekt substantiele modificatie: wijzig je het systeem zodanig dat de oorspronkelijke conformity assessment niet meer passend is, dan ben je provider. Sub (c) dekt purpose-change: zet je niet-high-risk AI (inclusief GPAI) in voor een high-risk doel, dan ben je provider van het resulterende high-risk AI-systeem.
Artikel 3(23) definieert substantiele modificatie als een wijziging na marktintroductie die niet voorzien was in de initiele conformity assessment en die of de Hoofdstuk III Sectie 2-compliance raakt of het beoogd doel wijzigt. Dit is geen vage norm; het is een technische toets die je per change moet uitvoeren. Model-update, data-retraining, feature-uitbreiding, context-shift: kandidaten voor substantiele modificatie. Bug-fix of UI-cosmetica: doorgaans niet.
Contractuele clausules kunnen onder Artikel 25 lid 1 de allocatie van verplichtingen beinvloeden, maar binnen grenzen. Een contract kan interne taakverdeling regelen, cost-sharing afspreken, vrijwaring bieden, maar tegenover toezichthouder blijft de partij die feitelijk het systeem onder eigen naam op de markt brengt aansprakelijk. Contracten zijn tool, geen schild. Voor elke partij langs de keten: documenteer rollen schriftelijk, toets bij elke wijziging of rol-transitie optreedt, en zorg dat bij transitie de nieuwe provider zijn Artikel 16-verplichtingen operationeel heeft.
Voor MKB is de grootste valkuil scenario c: fine-tuning of context-gedreven inzet van GPAI. Een algemene LLM wordt specifieke kredietbeoordelaar, HR-selector of triagetool; daarmee wordt jouw applicatie een high-risk AI-systeem en jij provider. Dit gebeurt veel, vaak onbewust. Deze pagina geeft de juridische structuur helder weer en benoemt de MKB-signalen die je alert moeten maken. Koppeling met onze 10-stappen-MKB-gids.
Provider (Art 3(3)): ontwikkelt een AI-systeem of laat het ontwikkelen en brengt het op de markt of neemt het in gebruik onder eigen naam of merk.
Deployer (Art 3(4)): gebruikt een AI-systeem onder eigen verantwoordelijkheid, buiten persoonlijke niet-professionele activiteiten.
Substantiele modificatie (Art 3(23)): niet-voorziene wijziging na marktintroductie die Hoofdstuk III Sectie 2-compliance raakt of het beoogd doel wijzigt.
Artikel 25 lid 1 sub a, b en c
Bij elk scenario geldt: de partij die de wijziging aanbrengt wordt provider met volledige Artikel 16-verplichtingen. Contractuele alloccatie kan interne taakverdeling regelen; niet de externe aansprakelijkheid.
Re-branding
Eigen naam of merk plaatsen op een high-risk AI-systeem dat al op de markt is gebracht of in gebruik is genomen. Typisch: white-label SaaS, OEM-leverancier, zelf-merkende integrator.
Substantiele modificatie
Substantiele modificatie aan high-risk AI dat al op de markt is, waarbij het systeem high-risk blijft. Toets tegen Art 3(23): impact op Hoofdstuk III Sectie 2-compliance of wijziging beoogd doel.
Purpose-change high-risk
Beoogd doel aanpassen van niet-high-risk AI, inclusief GPAI, zodanig dat het systeem high-risk wordt. Veel voorkomend: GPAI-fine-tuning voor Annex III use-case (HR, credit, zorg, biometrie).
Substantiele modificatie: wat wel en wat niet
Art 3(23) bevat twee triggers: impact op Hoofdstuk III Sectie 2-compliance of wijziging van beoogd doel. De tabel hieronder geeft typische change-types en de bijhorende verdict.
Wijzigings-matrix: triggert dit Artikel 25 sub (b)?
Toets elke change tegen Art 3(23). Bij substantiele modificatie: provider-status activeert Art 16-verplichtingen.
Rol-transitie in drie stappen
Van deployer naar provider bij een van de drie scenarios uit Art 25 lid 1.
Deployer
Artikel 26 verplichtingen: oversight-personeel, instructies volgen, monitoring, incident-melding.
Art 25 scenario
Re-branding, substantiele modificatie, of purpose-change naar high-risk. Een van de drie is voldoende.
Provider
Volledige Art 16-verplichtingen: QMS (17), technische doc (11), CA (43), CE (48), registratie (49).
Zes concrete situaties
Typische MKB-situaties waarbij Artikel 25 in beeld komt, met verdict per voorbeeld.
Wat gebeurt bij provider-worden?
Bij rol-transitie onder Artikel 25 activeren alle Artikel 16-verplichtingen voor high-risk AI-providers. Dit is geen checklist-werk maar een structureel compliance-programma. Onderstaand de kern; voor details per verplichting zie de verwijzingen.
Kern-verplichtingen onder Art 16.
- Hoofdstuk III Sectie 2-compliance (Art 8-15). Risk management (Art 9), data governance (Art 10), technische documentatie (Art 11), record-keeping (Art 12), transparantie en instructies (Art 13), human oversight (Art 14), accuratesse, robuustheid en cybersecurity (Art 15).
- Kwaliteitsmanagementsysteem (Art 17). Gedocumenteerde procedures voor ontwerp, ontwikkeling, testing, deployment, monitoring, incident-management.
- Conformity assessment (Art 43). Intern of via notified body afhankelijk van Annex-categorie. Voor Annex III-systemen meestal intern; voor Annex I (safety-components) notified-body-route.
- CE-marking (Art 48) en EU-declaratie van conformiteit (Art 47). Aanbrengen op systeem of begeleidende documentatie.
- Registratie in EU-database (Art 49). Voor high-risk AI-systemen voor marktintroductie.
- Post-market monitoring (Art 72) en serious-incident-reporting (Art 73). Continue bewaking plus meldingen binnen 15 dagen.
- Naam en contactgegevens op systeem (Art 16 sub b). Deployer en toezichthouder moeten weten wie te benaderen bij issues.
Originele provider-samenwerkingsplicht (Art 25 lid 2).
Artikel 25 lid 2 bepaalt dat de initiele provider nauw samenwerkt met de nieuwe provider en de noodzakelijke informatie beschikbaar stelt plus redelijkerwijs te verwachten technische toegang en andere ondersteuning die nodig is voor naleving. Dit is een juridische samenwerkingsplicht, geen gunst. Praktisch: toegang tot technische documentatie, metadata over trainings-data, model-architectuur-uitleg voor zover nodig voor eigen CA en Art 14-oversight.
De samenwerkingsplicht vervalt wanneer de initiele provider expliciet heeft gespecificeerd dat zijn AI-systeem niet tot high-risk gewijzigd mag worden. Een dergelijke clausule moet duidelijk in leveringsvoorwaarden of IFU staan. Voor MKB die upstream-leverancier is: dit is een manier om ongewenste samenwerkingsplicht te vermijden. Voor MKB die downstream-modifier is: lees leveranciers-voorwaarden voordat je modificaties begint.
Contract-clausules die werken
Art 25 lid 1 staat contractuele allocatie toe binnen grenzen. Bouw je contracten met deze bepalingen om risico beheersbaar te houden.
Checklist contract-clausules voor rol-allocatie
Niet als juridisch sjabloon; als startpunt voor gesprek met leverancier of afnemer.
- Expliciete rol-aanduiding. Wie is provider, wie deployer op moment van contract. Verwijs naar Art 3-definities.
- Geen-wijziging-clausule. Afnemer verklaart geen substantiele modificatie te doen zonder voorafgaand overleg.
- Geen-rebrand-clausule. Afnemer verklaart geen eigen merk te plaatsen zonder toestemming.
- Purpose-restriction. Systeem mag alleen gebruikt worden voor beoogd doel uit IFU; shift naar high-risk use-case verboden zonder overleg.
- Samenwerkingsplicht-concretisering. Wat levert originele provider aan bij documentatie-verzoek, binnen welke termijn, onder welke voorwaarden.
- Kennis-en-toegang-clausule. Technische documentatie en metadata beschikbaar binnen afgesproken SLA bij rol-transitie.
- Kost-allocatie. Wie draagt welke kosten bij CA, CE-marking, registratie, audits.
- Vrijwaring en aansprakelijkheid. Wie staat in voor welke type schade; limitering per type risico.
- Wijzigings-notificatie. Elke partij meldt materiele wijziging binnen X dagen aan de andere partij.
- Audit-rechten. Wederzijdse audit-bevoegdheid voor compliance-controle, frequentie en scope.
- Exit-clausule. Bij contract-beeindiging: data-teruggave, documentatie-overdracht, compliance-continuiteit.
- Jurisdictie en geschillenregeling. Nederlands recht, forumkeuze, eventueel arbitrage voor technische geschillen.
Contractuele clausules kunnen interne taakverdeling regelen tussen partijen. Ze kunnen niet externe aansprakelijkheid tegenover toezichthouder afschuiven. De partij die onder eigen naam een high-risk AI-systeem op de markt zet, blijft primair aanspreekbaar bij inspectie, ongeacht contract-afspraken. Contracten zijn tool voor cost-sharing en onderlinge verhouding; feitelijke compliance moet je zelf op orde hebben.
Hoe vermijd je accidentele provider-status?
Voor MKB is scenario c (fine-tuning GPAI of purpose-change naar high-risk) de grootste risico-categorie. Een algemene API wordt specifieke Annex III-toepassing zonder dat de organisatie het doorheeft. Onderstaand een preventie-aanpak in vijf stappen.
Stap 1: inventariseer AI-gebruik met Artikel 25-lens.
Voor elk AI-systeem in gebruik: wat is de leverancier, wat is het originele beoogd doel volgens IFU, wat is onze feitelijke inzet, hebben we gewijzigd. Documenteer deze mapping; bij audit moet je dit kunnen overleggen.
Stap 2: classificeer inzet per use-case.
Per use-case: is dit high-risk onder Annex III? Zie onze classificatie-pagina. Bij high-risk use-case van GPAI: scenario c-alert; overweeg volledige provider-route of heroverweeg use-case.
Stap 3: change-control voor AI-wijzigingen.
Elke wijziging aan een AI-systeem (retraining, feature-toevoegen, context-shift, configuratie buiten IFU) doorloopt een change-control-proces. Toets tegen Art 3(23) substantiele modificatie-criteria, documenteer besluit schriftelijk.
Stap 4: contracteer helder met leveranciers.
Bij elke AI-inkoop: Art 25-bepalingen opnemen in contract (zie checklist hierboven). Let op dat leveranciers-voorwaarden geen "niet tot high-risk" clausule hebben die je workflow raakt; zo ja, herzie use-case of kies andere leverancier.
Stap 5: overweeg provider-worden bewust.
Als je use-case echt high-risk is en fine-tuning of purpose-shift noodzakelijk is voor bedrijfswaarde: accepteer provider-status en regel de volledige Art 16-compliance structureel. Halfbakken is niet acceptabel onder AI Act. Koppeling met compliance-roadmap om het traject te plannen.
Over Artikel 25 en rol-transitie
Wat regelt Artikel 25 precies?
Artikel 25 regelt wanneer een deployer, distributeur, importeur of andere derde partij zelf provider wordt van een high-risk AI-systeem. Drie scenarios in paragraaf 1: (a) re-branding, (b) substantiele modificatie, (c) purpose-change van niet-high-risk naar high-risk. Bij elk scenario activeren volledige Art 16-verplichtingen.
Wat is substantiele modificatie onder Art 3(23)?
Niet-voorziene wijziging na marktintroductie waardoor of de Hoofdstuk III Sectie 2-compliance wordt geraakt, of het beoogd doel wordt gewijzigd. Fine-tuning, retraining, risk-relevante feature-uitbreiding: kandidaten, bug-fix en UI-cosmetica: doorgaans niet.
Wat betekent scenario a: eigen merk op high-risk AI?
White-label inkoop waarbij je onder eigen naam het systeem op de markt zet. Je bent dan provider voor de wet, ongeacht wie de onderliggende technologie levert. Contract met originele provider kan interne taakverdeling regelen; niet de externe aansprakelijkheid.
Wanneer triggert purpose-change provider-status (sub c)?
Wanneer je niet-high-risk AI (inclusief GPAI) inzet voor een doel dat onder Annex III valt. Voorbeelden: GPAI fine-tunen voor kredietbeoordeling, generieke chatbot gebruiken voor HR-screening. Typische MKB-valkuil bij gebruik van algemene AI-API's.
Kan ik via contract provider-status vermijden?
Gedeeltelijk. Contracten kunnen interne taakverdeling regelen; ze kunnen de primaire aansprakelijkheid tegenover toezichthouder niet afschuiven van degene die onder eigen naam op de markt zet. Gebruik contracten als tool, niet als schild.
Wat moet ik doen als ik provider word?
Volledige Art 16-verplichtingen activeren: Hoofdstuk III Sectie 2-compliance (Art 8-15), QMS (Art 17), technische doc (Art 11), CA (Art 43), CE-marking (Art 48), EU-registratie (Art 49), post-market monitoring (Art 72), serious-incident-reporting (Art 73).
Wat blijft de verantwoordelijkheid van de originele provider?
Artikel 25 lid 2 legt samenwerkingsplicht op: technische informatie, toegang en ondersteuning voor naleving. Uitzondering bij expliciete specificatie dat systeem niet tot high-risk mag worden.
Geldt Artikel 25 ook voor GPAI-modellen?
Ja, impliciet via sub (c) dat expliciet GPAI noemt. Fine-tuning of context-gedreven inzet van GPAI voor Annex III use-case maakt je provider. Veel voorkomend bij MKB die foundation-APIs inzet voor specifieke toepassingen.
Wat is het verschil tussen distributeur, importeur en deployer?
Provider ontwikkelt en brengt op markt onder eigen naam. Deployer gebruikt onder eigen verantwoordelijkheid. Importeur brengt AI van buiten EU op EU-markt. Distributeur stelt beschikbaar op EU-markt. Artikel 25 geldt voor alle rollen: elk kan provider worden.
Hoe vermijd ik accidentele provider-status?
Inventariseer AI-gebruik, classificeer use-cases, change-control op wijzigingen, heldere contracten met leveranciers, en bij echt high-risk use-case: accepteer provider-status en regel compliance structureel. Zie boetes-pagina voor sanctie-risico.
Verder lezen binnen AI Act-compliance
Raakvlakken met Artikel 25 en de bredere provider/deployer-verplichtingen.
Officiele bron: Verordening 2024/1689 op EUR-Lex. Deze pagina geeft een werkbare samenvatting; raadpleeg altijd de juridisch bindende tekst bij concrete beoordelingen.
Ben jij per ongeluk provider geworden?
Prometheus21 toetst binnen twee weken of jouw AI-inzet Artikel 25-triggers bevat. Inclusief scenario-analyse, Art 3(23)-toets op wijzigingen, contract-review en concrete aanbevelingen. Direct bruikbaar als compliance-bewijs richting toezichthouder.
Plan een Artikel 25-toets