Een scale-up koopt een AI-screeningtool in, fine-tunet het onderliggende model op eigen data en zet er het eigen logo op voordat klanten ermee gaan werken. De CTO ziet een productverbetering. De legal counsel zou iets anders moeten zien: het moment waarop het bedrijf mogelijk ophoudt gebruiksverantwoordelijke te zijn en zelf aanbieder wordt, met het volledige pakket aanbiederverplichtingen van de AI Act erbij.
Het directe antwoord staat in artikel 25 lid 1 van de AI Act. Een gebruiksverantwoordelijke (of distributeur, importeur of andere derde) wordt zelf aanbieder van een hoog-risico AI-systeem in drie gevallen: als hij zijn eigen naam of merk op een hoog-risico systeem zet dat al in de handel is, als hij zo'n systeem substantieel wijzigt terwijl het hoog-risico blijft, of als hij het beoogde doel van een AI-systeem (inclusief een generiek AI-systeem) zo verandert dat het daardoor hoog-risico wordt. In alle drie de gevallen verschuiven de aanbiederverplichtingen van artikel 16 naar jou, en is de oorspronkelijke leverancier voor dat specifieke systeem geen aanbieder meer.
Let op het scharnier in die zin: artikel 25 gaat over hoog-risico systemen. Voor de meeste interne GenAI-toepassingen die geen hoog-risico zijn, is dit artikel simpelweg niet van toepassing. Maar het denkwerk erachter, wie is voor welk systeem aanbieder en waarom, moet elke organisatie die met AI bouwt of aanpast kunnen laten zien.
De drie routes van artikel 25 lid 1
Route 1: jouw naam of merk op een hoog-risico systeem
De eerste route is de meest onderschatte. Wie zijn naam of merk aanbrengt op een hoog-risico AI-systeem dat al in de handel is gebracht of in gebruik is gesteld, wordt aanbieder van dat systeem. De redenering van de wetgever is dezelfde als in productregelgeving: wie naar buiten toe de indruk wekt dat het zijn product is, draagt de verantwoordelijkheid die daarbij hoort.
Voor white-label-constructies is dit de kernbepaling. Een HR-techbedrijf dat een ingekochte sollicitantenselectietool onder eigen merknaam aan klanten levert, is voor die tool aanbieder, ook als er onder de motorkap geen regel code is veranderd. De bepaling laat wel ruimte voor contractuele afspraken waarin de verplichtingen anders worden verdeeld, maar dat vraagt om een bewuste, vastgelegde regeling met de oorspronkelijke leverancier. Wie alleen een logo verwisselt en verder niets regelt, heeft de verplichtingen gewoon zelf.
Route 2: substantiële wijziging van een hoog-risico systeem
De tweede route gaat over ingrijpen in het systeem zelf. Wie een substantiële wijziging aanbrengt in een hoog-risico AI-systeem dat al op de markt is, zodanig dat het hoog-risico blijft, wordt aanbieder. Wat "substantieel" is, definieert artikel 3 punt 23: een wijziging die niet was voorzien of gepland in de oorspronkelijke conformiteitsbeoordeling van de aanbieder, en die gevolgen heeft voor de naleving van de hoog-risico-eisen of het beoogde doel verandert.
Dat voorziene karakter is in de praktijk het belangrijkste criterium. Een aanbieder van een hoog-risico systeem kan in zijn documentatie aangeven welke aanpassingen, configuraties en zelfs welke vormen van doorleren binnen de beoordeelde bandbreedte vallen. Blijf je daarbinnen, dan blijft de oorspronkelijke aanbieder aanbieder. Ga je erbuiten, bijvoorbeeld door het model op eigen data te hertrainen op een manier die de leverancier niet heeft voorzien, dan komt route 2 in beeld. Voor wie het jargon herkent: dit concept komt rechtstreeks uit de wereld van productregelgeving zoals de machineverordening en de medische-hulpmiddelenverordening, waar substantiële wijzigingen eveneens een nieuwe conformiteitsbeoordeling triggeren.
Route 3: doelwijziging waardoor een systeem hoog-risico wordt
De derde route is voor de GenAI-praktijk de interessantste. Wie het beoogde doel wijzigt van een AI-systeem dat niet als hoog-risico was geclassificeerd, inclusief een AI-systeem voor algemene doeleinden, zodanig dat het daardoor wel hoog-risico wordt, is aanbieder van dat nieuwe hoog-risico systeem. Hier telt niet hoeveel je aan het model verandert, maar waarvoor je het inzet.
Een generieke chatbot-API is geen hoog-risico systeem. Bouw je daaromheen een toepassing die sollicitanten rangschikt, examens beoordeelt of aanvragen voor essentiële diensten triageert, dan zet je dat generieke systeem in voor een doel uit Annex III. Jij hebt het beoogde doel bepaald, dus jij bent aanbieder van het resulterende hoog-risico systeem. De oorspronkelijke modelleverancier moet op grond van artikel 25 lid 2 wel redelijkerwijs meewerken met informatie en technische toegang, zodat jij je verplichtingen kunt nakomen, tenzij hij uitdrukkelijk heeft bepaald dat zijn systeem niet mag worden omgebouwd tot hoog-risico systeem.
Wat betekent dit voor fine-tunes, white-labels en RAG?
GPT-fine-tunes. Hier lopen twee lagen door elkaar die je apart moet houden. Op modelniveau word je door fine-tunen niet snel aanbieder van een GPAI-model: de richtsnoeren van de Europese Commissie over GPAI-verplichtingen hanteren een indicatieve drempel waarbij pas bij zeer omvangrijke hertraining (in de orde van een derde van de oorspronkelijke trainingscompute) een nieuwe modelaanbieder ontstaat. Vrijwel geen enkele zakelijke fine-tune komt daar in de buurt. Op systeemniveau ligt het anders: als jouw gefine-tunede toepassing een Annex III-doel dient, ben je via route 3 (of gewoon rechtstreeks, omdat je zelf een systeem onder eigen naam ontwikkelt en in gebruik stelt) aanbieder van een hoog-risico AI-systeem. Compute is daarvoor irrelevant; het beoogde doel is beslissend.
Eigen naam op ingekochte tools. Route 1 in zuivere vorm. De praktische vraag is steeds: is het onderliggende systeem hoog-risico? Zo ja, regel dan contractueel wie welke verplichting draagt, of accepteer dat je ze zelf hebt. Zo nee, dan creëert het rebranden op zichzelf geen aanbiederschap onder artikel 25, maar blijf je als gebruiksverantwoordelijke wel gebonden aan onder meer de transparantieverplichtingen van artikel 50 zodra die op jouw toepassing zien.
RAG-toepassingen. Retrieval augmented generation wijzigt het model niet, dus route 2 speelt zelden. Maar wie een RAG-applicatie bouwt en onder eigen naam intern of extern in gebruik stelt, ontwikkelt een AI-systeem en is daarvan aanbieder in de gewone zin van artikel 3. De classificatievraag is dan dezelfde: dient de toepassing een Annex III-doel? Een interne kennisassistent die beleidsdocumenten samenvat vrijwel zeker niet. Een RAG-systeem dat adviseert over uitkeringsaanvragen of kredietwaardigheid zit in een andere categorie.
Geen hoog-risico? Dan geen artikel 25, wel het denkwerk
De geruststellende boodschap voor de meeste innovatieteams: interne copilots, samenvattingstools en klantenservice-assistenten zijn doorgaans geen hoog-risico systemen, en dan is artikel 25 niet van toepassing. De verplichting die overblijft is het denkwerk zelf. Je moet per toepassing kunnen onderbouwen wat het beoogde doel is, of dat doel Annex III raakt, en wie in de keten welke rol heeft. Die vastlegging hoort thuis in je AI-inventarisatie; waarom dat register de basis van alles is, staat in ons artikel over de AI-inventarisatie.
De timing geeft ruimte, geen vrijbrief. De zelfstandige hoog-risico verplichtingen van Annex III gelden door de Digital Omnibus (politiek akkoord, medio 2026 nog niet in het Publicatieblad verschenen) per 2 december 2027; voor AI ingebed in gereguleerde producten uit Annex I per 2 augustus 2028. Maar de transparantieverplichtingen van artikel 50 gelden al per 2 augustus 2026, en de GPAI-handhaving start op diezelfde datum. Bovendien: contracten die je nu sluit over white-labels en fine-tunes bepalen straks wie de conformiteitsbeoordeling moet dragen. In Nederland bereiden de Autoriteit Persoonsgegevens en de RDI zich intussen op het toezicht voor; het kabinet diende in april 2026 het uitvoeringswetsvoorstel in dat die rolverdeling formeel belegt.
Praktisch komt het neer op vier stappen. Inventariseer welke AI-systemen je gebruikt, aanpast of doorlevert. Leg per systeem vast wat het beoogde doel is en of dat Annex III raakt. Check bij elke white-label- en fine-tune-constructie de contracten op de verdeling van artikel 25-verplichtingen en de medewerkingsplicht van de oorspronkelijke aanbieder. En veranker dit in een governance-structuur die de beoordeling herhaalt zodra doel of systeem wijzigt; hoe zich dat verhoudt tot certificering leggen we uit in ISO 42001 versus de EU AI Act. Wie de volledige tijdlijn en verplichtingen per rol wil doorlopen, vindt die in onze AI Act Explorer. En voor organisaties die deze rolbepaling structureel willen inrichten, van inventarisatie tot contractclausules, helpt Embed AI met een pragmatische governance-aanpak.