EU AI Act waardeketen: aanbieder tot gebruiker uitgelegd

Wanneer een gemeente een AI-systeem inkoopt om bijstandsaanvragen te beoordelen, zijn er minstens vier partijen betrokken: de softwareontwikkelaar die het model heeft gebouwd, mogelijk een cloudprovider die de infrastructuur levert, de gemeente zelf die het systeem implementeert en de besluiten neemt, en de burgers die de gevolgen van die besluiten ondervinden. De EU AI Act verdeelt verplichtingen over al deze partijen, maar doet dat niet symmetrisch. De rolverdeling bepaalt welke verplichtingen gelden, en die rolverdeling is minder vanzelfsprekend dan ze lijkt.

Artikel 3 van de EU AI Act definieert de belangrijkste actoren in de waardeketen. De centrale begrippen zijn "aanbieder" (provider) en "gebruiker" (deployer), aangevuld met importeur, distributeur, gemachtigde en de getroffen persoon. Begrijpen wie in welke rol valt is niet alleen een academische oefening: het bepaalt welke conformiteitsverplichtingen, documentatieplichten, meldingsplichten en aansprakelijkheidsposities op een organisatie van toepassing zijn.

De aanbieder: het zwaarste pakket verplichtingen

Artikel 3, lid 3, definieert een aanbieder als een rechtspersoon of natuurlijke persoon die een AI-systeem of GPAI-model ontwikkelt of laat ontwikkelen, en dit op de markt brengt of in gebruik stelt onder zijn eigen naam of merk, al dan niet tegen betaling. De nadruk ligt op twee elementen: het op de markt brengen en het doen onder eigen naam.

Voor hoog-risico AI-systemen rust op de aanbieder de zwaarste set verplichtingen van de hele wet. Artikel 9 verplicht een doorlopend risicobeheersysteem dat alle risico's tijdens de levenscyclus van het systeem identificeert, evalueert en mitigeert. Artikel 10 stelt eisen aan data governance voor trainings-, validatie- en testdata: representativiteit, afwezigheid van relevante fouten, bescherming tegen bias. Artikel 11 verplicht technische documentatie overeenkomstig annex IV. Artikel 12 verplicht logging van de werking van het systeem met voldoende detail om reconstructie van output mogelijk te maken. Artikel 13 vereist dat gebruikers voldoende informatie krijgen over het systeem om het correct te kunnen inzetten. Artikel 14 verplicht inbouw van menselijk toezicht in het systeemontwerp. Artikel 15 stelt eisen aan nauwkeurigheid, robuustheid en cyberveiligheid.

Daarnaast moet de aanbieder een conformiteitsbeoordeling uitvoeren (artikel 43), een conformiteitsverklaring opstellen (artikel 47), een CE-markering aanbrengen (artikel 48), en het systeem registreren in de EU-database (artikel 49). Post-market monitoring, het actief bijhouden van hoe het systeem presteert nadat het in gebruik is genomen, is verplicht op grond van artikel 72. Ernstige incidenten moeten worden gemeld aan de nationale toezichthouder.

De deployer: geen passieve consument

Artikel 3, lid 4, definieert een gebruiker of deployer als een rechtspersoon of natuurlijke persoon die een AI-systeem onder zijn eigen verantwoordelijkheid gebruikt, behalve wanneer het systeem voor persoonlijke, niet-professionele activiteiten wordt gebruikt. De wet vermijdt de term "gebruiker" wanneer het om deployers gaat; dat woord reserveert zij voor de eindgebruikers die interacteren met het systeem.

De deployer is niet passief. Artikel 26 legt deployers van hoog-risico systemen de volgende verplichtingen op: gebruik overeenkomstig de instructies van de aanbieder, aanwijzen van een menselijk toezichthouder die de in artikel 14 beschreven bevoegdheden heeft, monitoring van de werking van het systeem, informeren van de aanbieder bij problemen of afwijkende output, en het bijhouden van loggegevens voor zover die beschikbaar zijn gesteld door de aanbieder.

Deployers die publieke autoriteiten zijn of die diensten verlenen die als hoog-risico kwalificeren, moeten bovendien een Fundamental Rights Impact Assessment (FRIA) uitvoeren voor ingebruikname van het systeem. Artikel 27 legt dit vast: de FRIA moet de grondrechten beschrijven die kunnen worden aangetast, de populatie beoordelen die door het systeem wordt geraakt, mitigerende maatregelen beschrijven en de resultaten openbaar maken. De FRIA-generator biedt een gestructureerd startpunt voor dit proces.

Een bijzonder kwetsbaar punt voor deployers is de verhouding tot de instructies van de aanbieder. Als een deployer het systeem buiten zijn bedoelde gebruiksdoeleinden inzet, verliest hij de bescherming van het aanbieder-deployer onderscheid en neemt hij de verplichtingen van de aanbieder over. Artikel 25 maakt dit expliciet: als een deployer "het doel van een AI-systeem van hoog risico zodanig wijzigt" dat dit buiten de scope van de oorspronkelijke conformiteitsbeoordeling valt, wordt de deployer aanbieder. Die grens is in de praktijk soms flinterdun: een HR-systeem aanpassen zodat het ook sollicitanten van externe platforms beoordeelt in plaats van alleen interne kandidaten, kan die grens overschrijden.

Importeurs en distributeurs: de schakel in de keten

Importeurs zijn partijen die AI-systemen uit derde landen op de EU-markt brengen. Artikel 23 verplicht importeurs te controleren of de aanbieder de conformiteitsbeoordeling heeft uitgevoerd, of de technische documentatie beschikbaar is, of de CE-markering correct is aangebracht, en of de aanbieder een contactpunt in de EU heeft aangewezen. Als een importeur redelijke gronden heeft om te vermoeden dat een systeem niet compliant is, mag het niet op de markt worden gebracht.

Distributeurs, die AI-systemen op de EU-markt beschikbaar stellen zonder ze te importeren, hebben vergelijkbare verplichtingen op grond van artikel 24. Ook zij moeten controleren of de conformiteitsverklaring en CE-markering aanwezig zijn, en mogen non-conforme systemen niet distribueren. Beiden zijn verplicht te melden wanneer zij kennis krijgen van non-conformiteit of ernstige incidenten.

De praktische relevantie hiervan is aanzienlijk voor de SaaS-markt. Een Nederlands bedrijf dat een AI-toepassing van een Amerikaans bedrijf doorverkoopt aan Nederlandse klanten, kan in de positie van importeur zitten, met de bijbehorende verificatieplichten. Het is onvoldoende om te verwijzen naar de contractuele verantwoordelijkheid van de originele aanbieder: de importeur heeft een zelfstandige verificatieplicht.

Wanneer rollen overlap vertonen

De meest complexe compliance-situaties ontstaan wanneer een partij tegelijk meerdere rollen vervult. Een groot technologiebedrijf dat een AI-platform bouwt op basis van een extern GPAI-model, het aanpast aan eigen behoeften, en het vervolgens verkoopt aan andere organisaties, is tegelijk deployer (ten opzichte van het GPAI-model), aanbieder (ten opzichte van het aangepaste systeem) en mogelijk distributeur (als het systemen van derden integreert). De verplichtingen stapelen zich op in plaats van te vervangen.

Een tweede veelvoorkomende complexiteit is de interne deployer. Een organisatie die een AI-systeem bouwt voor intern gebruik, niet voor de markt, is in principe geen aanbieder in de zin van de wet. Artikel 2, lid 12, stelt echter dat publieke instanties die AI-systemen inzetten voor hun eigen operaties onder het deployer-regime vallen. Voor private bedrijven die intern ontwikkelde systemen gebruiken, is de positie genuanceerder: als het systeem voldoet aan de definitie van hoog-risico en wordt ingezet in een hoog-risico context, gelden de technische verplichtingen van artikel 9-15 ook zonder dat er sprake is van marktintroductie.

Open source en de grenzen van uitzonderingen

Artikel 2, lid 12 bevat een uitzondering voor aanbieders van AI-systemen die worden uitgebracht onder open-source licenties. Die uitzondering is belangrijk maar beperkt: ze geldt alleen voor systemen die niet als hoog-risico of verboden kwalificeren, en ze geldt niet voor GPAI-modellen met systemisch risico. Een open-source hoog-risico systeem dat door een organisatie in een hoog-risico context wordt ingezet, valt volledig onder de wet, voor de deployer die het inzet.

De praktische implicatie is dat de populariteit van open-source AI-modellen voor interne deployment de compliance-vraag niet oplost maar verschuift. Als u een open-source model fine-tunet op eigen data en inzet voor een hoog-risico toepassing, bent u in die context aanbieder van een hoog-risico systeem met de bijbehorende verplichtingen.

GPAI-modellen: een apart regime binnen de keten

General purpose AI-modellen, zoals grote taalmodellen, hebben een eigen positie in de waardeketen die de AI Act in artikelen 51-56 reguleert. GPAI-aanbieders moeten technische documentatie opstellen overeenkomstig annex XI, een registratie maken van trainingsdata (inclusief een samenvatting voor het publiek), een beleid voor naleving van auteursrecht onderhouden, en medewerking verlenen aan verzoeken van downstream aanbieders.

GPAI-modellen met systemisch risico, gedefinieerd als modellen die zijn getraind met meer dan 10^25 floating-point operaties of die anderszins een grote maatschappelijke impact kunnen hebben, zijn onderworpen aan aanvullende verplichtingen: adversarieel testen, meldingsplicht voor ernstige incidenten, en versterkte cyberveiligheidsmaatregelen.

De relevantie voor bedrijven die GPAI via API's integreren is dat zij deployers zijn ten opzichte van het GPAI-model maar aanbieders ten opzichte van de applicatie die zij bouwen. Als die applicatie als hoog-risico kwalificeert, moeten zij de conformiteitsbeoordeling uitvoeren, ook al gebruiken zij een extern model. De GPAI-aanbieder kan niet verantwoordelijk worden gesteld voor de specifieke downstream toepassing.

2 minuten, geen account nodig

Leer de EU AI Act door te doen

Geen slides. Geen saaie e-learning. Probeer een interactieve module.

Interactive ChallengePowered by LearnWize

Probeer het zelf

3 interactieve oefeningen. Verdien XP. Ontdek waarom dit beter werkt dan lezen.

Flashcards→Matching→Audit

Start de challenge

Contractuele governance als uitvoeringslaag

De wettelijke rolverdeling werkt in de praktijk via contracten. Aanbieder-deployer-relaties vereisen contractuele afspraken over: toewijzing van logging-verantwoordelijkheden, toegang tot technische documentatie, procedure voor meldingsplichten, medewerking aan audits door de deployer of toezichthouders, en update-verplichtingen bij significante wijzigingen.

De EU heeft Model Contractual Clauses (MCC-AI) gepubliceerd als startpunt voor die contractuele afspraken. Er zijn twee varianten: een voor hoog-risico systemen met uitgebreide verplichtingen, en een lichtere versie voor overige AI-toepassingen. Inkoopafdelingen die AI contracteren moeten deze clausules kennen en aanpassen aan de specifieke context, niet als boilerplate toevoegen zonder inhoudelijke beoordeling.

Voor deployers die meerdere aanbieders gebruiken, of die systemen van meerdere aanbieders combineren in een toepassing, geldt bovendien de vraag: wie is verantwoordelijk als het systeem als geheel niet voldoet? De AI Act beantwoordt die vraag niet altijd eenduidig. Doorgaans valt de verantwoordelijkheid bij de partij die de combinatie heeft gemaakt en daarmee de effectieve aanbieder is geworden, maar de exacte grenzen worden in jurisprudentie en richtsnoeren nog uitgewerkt.

Praktische governance: contractuele cascades en audittrails

De theoretische waardeketen-verdeling wordt in de praktijk omgezet via contractuele afspraken die de technische realiteit weerspiegelen. Als een deployer een hoog-risico systeem van een aanbieder inkoopt en daarna aanpast voor een specifieke context, moet contractueel duidelijk zijn: op welk moment wordt de deployer aanbieder? Welke verplichtingen blijven bij de oorspronkelijke aanbieder, en welke worden overgenomen door de deployer?

De EU Model Contractual Clauses (MCC-AI) bieden een startpunt. Ze bevatten clausules over: beschikbaarheid van technische documentatie, logging en audittrails, medewerking aan conformiteitsbeoordelingen en audits, incidentrapportage, update-verplichtingen, en liabilities. Voor hoog-risico systemen zijn deze clausules niet optioneel maar essentieel: contracten zonder deze bepalingen laten ambiguiteit staan over wie verantwoordelijk is wanneer iets misgaat.

Tegelijkertijd moeten die contracten realistisch zijn. Een kleine aanbieder die een hoog-risico systeem verkoopt aan veel deployers kan niet voor elk van die deployers een maatwerk-audit uitvoeren. De contracten moeten daarom de verdeling van auditverantwoordelijkheden helder maken: de aanbieder zorgt voor bepaalde documentatie en logaccess; de deployer voert eigen audits uit of contracteert externe auditeurs.

Een probleem dat in de praktijk ontstaat, is dat deployers vaak weinig expertise hebben om de technische documentatie kritisch te beoordelen. Een gemeente die een algoritme voor bijstandsbeoordeling inkoopt, kan niet zelf controleren of het model voldoende op representatieve data is gevalideerd. Dit leidt tot een contract-compliance-gat: formeel voldoet het contract aan de vereisten van artikel 26, maar daadwerkelijk toezicht ontbreekt.

Dat risico kan deels worden gemitigeerd via industrie-standaarden en benchmarks. Als deployers kunnen verwijzen naar onafhankelijke benchmarks waarop hun systemen zijn getest (vergelijkbaar met cybersecurity certificaties), krijgen zij een objectieve maatstaf. De Europese Commissie werkt aan standaarden voor AI-testing; tot die beschikbaar zijn, moeten organisaties zelf expertise opbouwen of contracteren.

De rol van toezichthouders in het handhaven van keteneisen

Nationale markttoezichthouders hebben verantwoordelijkheden gekregen om te controleren of aanbieders, importeurs, distributeurs en deployers hun respectieve verplichtingen nakomen. Maar toezicht op een keten is complexer dan toezicht op een enkele partij. Fouten kunnen op meerdere punten in de keten ontstaan, en attributie (wie is verantwoordelijk?) kan onduidelijk zijn.

Dit leidt tot een praktische realiteit: toezichthouders zullen waarschijnlijk hun inspanningen concentreren op de aanbieder als het hoogste-risico punt in de keten. Een aanbieder die een non-conform systeem op de markt brengt, is de primaire verantwoordelijke. Deployers die dat systeem dan vervolgens onjuist gebruiken, zijn secundair.

Maar dit toezichthouders-perspectief kan in spanning raken met de juridische verdeling van verantwoordelijkheden in de wet. Als een toezichthouder een deployer aanspreekt voor non-compliance op basis van artikel 26 (menselijk toezicht), maar de aanbieder heeft geen adequate interface gebouwd voor menselijk toezicht conform artikel 14, wie draagt uiteindelijk de boete?

In de praktijk zal dat in jurisprudentie moeten worden uitgewerkt. Tot dan moeten partijen in de keten uitgaan van het voorzorgsprincipe: ga ervan uit dat eigen verantwoordelijkheden niet kunnen worden afgewenteld op een ander, tenzij contractueel zeer duidelijk anders is vastgelegd.

Wat nu te doen

Voor aanbieders: zorg dat uw technische documentatie volledig is conform Annex IV, dat uw conformiteitsverklaring en CE-markering op orde zijn, en dat deployers na ondertekening toegang hebben tot alle informatie die zij nodig hebben voor artikel 26-compliance. Veel geschillen kunnen worden voorkomen door helder te communiceren welke informatie beschikbaar is en hoe deployers deze kunnen opvragen.

Voor deployers: controleer contractueel dat alle informatie voor artikel 26-compliance beschikbaar is. Inventariseer wat u nodig hebt voor menselijk toezicht, logging, incidentrapportage, en verifieer dat uw contract die toezeggingen bevat. Voor hoog-risico systemen: voer een FRIA uit voordat u het systeem in productie neemt, gebruik die FRIA om mitigatiemaatregelen in uw werkprocessen in te bouwen, en documenteer dat traject als bewijs van due diligence.

Voor importeurs en distributeurs: controleer voordat u een systeem op de markt brengt dat de conformiteitsverklaring en CE-markering aanwezig zijn, en doe minimaal spot checks op de volledigheid van de technische documentatie. Contracteer expertise in als u deze checks zelf niet kunt doen; dat kost minder dan handhaving door toezichthouders later.

Gebruik de risk assessment tool om per systeem te bepalen welke risicocategorie van toepassing is en welke verplichtingen daaruit voortvloeien. Combineer die analyse met een contractuele inventarisatie: welke afspraken zijn er met aanbieders, importeurs en distributeurs, en dekken die afspraken de verplichtingen die de AI Act aan uw positie stelt?