Bijgewerkt september 20, 2026
Kort: Een verwerkersovereenkomst voor soevereine AI wijkt op cruciale punten af van een standaard cloud-DPA: modelgewichten, sub-verwerkers buiten de EU en AI Act-verplichtingen vereisen specifieke contractuele waarborgen. Dit artikel geeft compliance officers en IT-beslissers een concrete checklist.

Een verwerkersovereenkomst (DPA) voor een soevereine AI-dienst is een juridisch instrument dat de verwerking van persoonsgegevens regelt tussen een organisatie als verwerkingsverantwoordelijke en een aanbieder van een privé, lokaal gehost large language model (LLM) als verwerker. De vereisten gaan beduidend verder dan bij een standaard clouddienst-DPA, omdat de aard van het verwerkingsproces, de herkomst van modelgewichten en de complexiteit van de sub-verwerkersketen fundamenteel anders zijn.

Let op: Zelfs wanneer een LLM volledig on-premise draait en nooit data doorstuurt naar externe servers, kunnen onderhoudstoegang, licentieverstrekking en modelupdates een verwerkersrelatie in de zin van AVG artikel 28 creëren. Een DPA is dan niet optioneel.

Wat maakt een soevereine AI-DPA anders dan een standaard cloud-DPA?

Bij een standaard clouddienst beperkt de DPA zich doorgaans tot de verwerking van gegevens binnen de infrastructuur van de aanbieder. Bij een privé, lokaal gehost LLM-platform zijn de rollen complexer verdeeld.

Ten eerste verwerkt het LLM zelf persoonsgegevens op het moment dat gebruikers prompts invoeren die persoonsgegevens bevatten. Ten tweede levert de aanbieder doorgaans modelupdates, fijnafstemmingsdiensten of technische ondersteuning, waarbij tijdelijke toegang tot de omgeving kan ontstaan. Ten derde is de vraag relevant of het model is getraind op of verfijnd met data die persoonsgegevens bevatte, ook al vindt de inferentie lokaal plaats.

De DPA moet expliciet bepalen:

  • dat het model uitsluitend wordt gebruikt voor inferentie en niet voor hertraining op klantdata;
  • welke medewerkers van de aanbieder toegang kunnen krijgen tot de hostingomgeving en onder welke voorwaarden;
  • hoe logbestanden van LLM-interacties worden opgeslagen, wie er toegang toe heeft en hoe lang ze worden bewaard;
  • welke sub-verwerkers zijn ingeschakeld voor modelontwikkeling, updateverzorging of beveiligingsmonitoring.

EDPB Guidelines 07/2020 verduidelijken dat een verwerker alleen sub-verwerkers mag inschakelen met voorafgaande schriftelijke toestemming van de verwerkingsverantwoordelijke, en dat de verwerker dezelfde gegevensbeschermingsverplichtingen aan de sub-verwerker moet opleggen als die in de oorspronkelijke DPA staan.

De sub-verwerkersketen beoordelen op jurisdictierisico’s

Een compliance officer die een soevereine AI-dienst beoordeelt, moet de volledige keten in kaart brengen, inclusief partijen die indirect betrokken zijn bij de levering van het platform.

Slechts 36% van de onderzochte Europese organisaties voert regelmatig een beoordeling uit van de sub-verwerkersketen van hun clouddienstverleners (ENISA, 2023). Bij AI-platforms is dit risico groter omdat de keten minder transparant is dan bij traditionele SaaS-diensten.

De beoordeling omvat minimaal drie lagen:

Laag Voorbeeld Jurisdictierisico Contractuele maatregel
Modelontwikkelaar Meta (Llama), Mistral AI VS-exportcontrole, CLOUD Act bij Amerikaanse entiteit Herkomstverklaring, licentieaudit
Infrastructuurleverancier GPU-leverancier, hostingpartner Derde-land doorgifte als hardware buiten EU staat AVG artikel 46-garanties, standaardcontractbepalingen
Onderhoud en support Externe DevOps of security-team Toegang vanuit niet-EU-land Verbod op externe toegang zonder VPN-logging en toestemming

Open-source modelgewichten zoals Llama of Falcon zijn gepubliceerd door entiteiten buiten de EU. Het gebruik van deze gewichten betekent op zichzelf geen doorgifte van persoonsgegevens in de zin van AVG artikel 46, omdat de gewichten zelf geen persoonsgegevens bevatten. Toch moet worden beoordeeld of tijdens het fijnafstemmingsproces of de validatie persoonsgegevens zijn gebruikt, en of de aanbieder dat kan aantonen via gedocumenteerde datasheets.

AI Act-verplichtingen in de verwerkersovereenkomst

De EU AI Act, van toepassing per augustus 2024 voor de meest risicovolle systemen, voegt een nieuwe laag toe aan de DPA-vereisten. Bij hoog-risico AI-systemen zoals gedefinieerd in Bijlage III van de AI Act (onder andere AI voor personeelsselectie, kredietbeoordeling en rechtshandhaving) gelden aanvullende verplichtingen op grond van AI Act artikel 25 (verplichtingen van de gebruiker, ook wel “deployer” genoemd) en artikel 28 (verplichtingen van de aanbieder).

Concreet betekent dit dat de DPA moet vastleggen:

  • dat de aanbieder technische documentatie beschikbaar stelt waarmee de verwerkingsverantwoordelijke de conformiteitsverklaring kan opstellen;
  • dat het systeem logging mogelijk maakt van besluiten die invloed hebben op betrokkenen, zodat menselijk toezicht aantoonbaar is;
  • dat de aanbieder meewerkt aan een Fundamental Rights Impact Assessment wanneer de organisatie dat vereist;
  • dat de aanbieder onmiddellijk melding maakt van incidenten die de betrouwbaarheid van het systeem aantasten.
Let op: De AI Act maakt onderscheid tussen “aanbieder” (degene die het systeem op de markt brengt) en “gebruiker” (deployer, de organisatie die het inzet). Op soevereine infrastructuur kan de organisatie zelf de rol van aanbieder overnemen als zij het model significant aanpast. In dat geval verschuiven verplichtingen uit artikel 28 van de AI Act naar de organisatie zelf.

Volgens het IAPP-onderzoek uit 2024 gebruikt 65% van de privacy-professionals in gereguleerde sectoren al generatieve AI-tools, maar heeft minder dan de helft een bijgewerkte verwerkersovereenkomst voor deze tools (IAPP Privacy and AI Governance Report, 2024).

Auditrechten en transparantieverplichtingen contractueel borgen

AVG artikel 28 lid 3 sub h verplicht elke verwerker om audits toe te staan en eraan mee te werken. Bij soevereine AI-diensten is dit recht in de praktijk minder vanzelfsprekend dan bij grote cloudproviders, juist omdat de aanbieder kleiner is en minder gestandaardiseerde compliancedocumentatie heeft.

De DPA moet minimaal de volgende auditrechten bevatten:

  • Inzage in de Software Bill of Materials (SBOM) van het LLM-platform, een verplichting die ook voortvloeit uit de Cyber Resilience Act (CRA);
  • Het recht om logbestanden van LLM-interacties op te vragen en te laten onderzoeken door een onafhankelijke derde;
  • Het recht om sub-verwerkers te beoordelen en bij vastgestelde tekortkomingen te laten vervangen;
  • Toegang tot de modelkaart (model card) en datasheets van het gebruikte basismodel, zodat herkomst en trainingsdata traceerbaar zijn;
  • Een jaarlijkse verklaring van de aanbieder over wijzigingen in de sub-verwerkersketen.

AVG artikelen 13 en 14 verplichten de verwerkingsverantwoordelijke om betrokkenen te informeren over geautomatiseerde verwerking. Als een LLM wordt ingezet voor besluiten die betrokkenen raken, moet de organisatie in staat zijn om de werking van het systeem op begrijpelijke wijze toe te lichten. Dat veronderstelt dat de aanbieder deze informatie contractueel beschikbaar stelt.

De EDPB registreerde in 2023 meer dan 1.600 datalekken waarbij een ontoereikende DPA met verwerkers of sub-verwerkers als medeoorzaak werd aangemerkt (EDPB Annual Report 2023).

Aansprakelijkheidsverdeling bij een datalek via een LLM-interface

De verwerkingsverantwoordelijke blijft te allen tijde eindverantwoordelijk richting betrokkenen en de toezichthouder, ongeacht wie technisch gezien de inbreuk heeft veroorzaakt. De verwerker (de AI-aanbieder) is aansprakelijk jegens de verwerkingsverantwoordelijke voor schade die voortvloeit uit een inbreuk op de DPA of op de AVG.

Bij een LLM-interface zijn de meest voorkomende inbreukscenario’s:

  • Prompt-injectie waarbij een aanvaller via de interface toegang krijgt tot persoonsgegevens van andere gebruikers;
  • Onbedoelde memorisatie van persoonsgegevens in de modelgewichten, waardoor het model gegevens reproduceert in antwoorden;
  • Een inbreuk bij een sub-verwerker (zoals een GPU-cloudprovider) die toegang had tot de hostingomgeving.

De DPA moet de volgende aansprakelijkheidsbepalingen bevatten:

  • Een meldingsplicht voor de aanbieder van maximaal 24 uur na ontdekking van een incident, zodat de organisatie de wettelijke 72-uurstermijn naar de toezichthouder kan halen;
  • Een verplichting tot forensisch onderzoek op kosten van de aanbieder als de inbreuk door diens systeem is veroorzaakt;
  • Expliciete bepalingen over schadevergoeding bij verwijtbaar handelen van de aanbieder of diens sub-verwerkers;
  • Een vrijwaringsbepaling die de verwerkingsverantwoordelijke beschermt als de aanbieder sub-verwerkers heeft ingeschakeld zonder toestemming.

“Verwerkersovereenkomsten moeten worden aangepast naarmate AI-systemen complexer worden. Een generieke DPA dekt de specifieke risico’s van grote taalmodellen niet af, zeker niet wanneer modelgewichten afkomstig zijn van entiteiten buiten de EU”, aldus Andrea Jelinek, voormalig voorzitter van de EDPB, tijdens een plenaire vergadering over AI en gegevensbescherming.

“De AI Act legt nieuwe verplichtingen op aan aanbieders én gebruikers van hoog-risico AI-systemen. Contractuele afspraken tussen verwerkingsverantwoordelijken en verwerkers moeten deze rolverdeling expliciet adresseren, ook als het systeem on-premise draait”, stelt Wieske Chomé van de Autoriteit Persoonsgegevens in een publieksbrief over AI en gegevensbescherming.

FAQ: verwerkersovereenkomst en soevereine AI

Moet een lokaal gehost LLM-platform altijd een verwerkersovereenkomst hebben?

Ja, zodra de aanbieder van het platform enige toegang heeft tot persoonsgegevens die via de interface worden verwerkt, is een verwerkersovereenkomst op grond van AVG artikel 28 verplicht. Dit geldt ook bij on-premise installaties waarbij de leverancier updates, onderhoud of remote support levert.

Hoe beoordeel ik of open-source modelgewichten een jurisdictierisico vormen?

Onderzoek wie de oorspronkelijke ontwikkelaar is en onder welke licentie de gewichten zijn gepubliceerd. Gewichten van Amerikaanse bedrijven kunnen onderworpen zijn aan exportcontrole of vallen in scope van de CLOUD Act als de ontwikkelaar gegevens opslaat bij een Amerikaanse cloudprovider. Vraag de aanbieder om een schriftelijke herkomstverklaring en controleer of het model is gevalideerd zonder blootstelling aan persoonsgegevens.

Wat verandert de EU AI Act aan de inhoud van een verwerkersovereenkomst?

Bij hoog-risico AI-systemen moeten verwerkersovereenkomsten aanvullend de verplichtingen uit AI Act artikel 25 en artikel 28 adresseren. Concreet gaat het om logging en auditbaarheid van AI-besluiten, menselijke toezichtmechanismen en verplichte risicobeoordelingen die de leverancier beschikbaar moet stellen aan de verwerkingsverantwoordelijke.

Wie is aansprakelijk bij een datalek via een LLM-interface?

De verwerkingsverantwoordelijke blijft eindverantwoordelijk richting betrokkenen en toezichthouders. De aanbieder als verwerker is aansprakelijk als het lek het gevolg is van een inbreuk op de DPA of wettelijke verplichtingen. Contractueel moeten meldingstermijnen, forensisch onderzoeksverplichtingen en schadevergoedingsregelingen zijn vastgelegd.

Welke auditrechten zijn minimaal vereist in een DPA voor een soevereine AI-dienst?

AVG artikel 28 lid 3 sub h verplicht de verwerker om audits mogelijk te maken. Bij soevereine AI-diensten betekent dit minimaal: inzage in logbestanden van LLM-interacties, het recht op een onafhankelijke penetratietest, toegang tot de SBOM van het platform en het recht om sub-verwerkers te laten auditen of te vervangen bij gebleken tekortkomingen.

Veelgestelde vragen

Moet een lokaal gehost LLM-platform altijd een verwerkersovereenkomst hebben?
Ja, zodra de aanbieder van het platform enige toegang heeft tot persoonsgegevens die via de interface worden verwerkt, is een verwerkersovereenkomst op grond van AVG artikel 28 verplicht. Dit geldt ook bij on-premise installaties waarbij de leverancier updates, onderhoud of remote support levert.
Hoe beoordeel ik of open-source modelgewichten een jurisdictierisico vormen?
Onderzoek wie de oorspronkelijke ontwikkelaar is en onder welke licentie de gewichten zijn gepubliceerd. Gewichten van Amerikaanse bedrijven of universiteiten kunnen onderworpen zijn aan exportcontrole (EAR) of vallen in scope van de CLOUD Act als de ontwikkelaar gegevens opslaat bij een Amerikaanse cloudprovider. Vraag de aanbieder om een schriftelijke verklaring over de herkomst en controleer of het model is gevalideerd zonder blootstelling aan persoonsgegevens.
Wat verandert de EU AI Act aan de inhoud van een verwerkersovereenkomst?
Bij hoog-risico AI-systemen (zoals gedefinieerd in Bijlage III van de AI Act) moeten verwerkersovereenkomsten aanvullend de verplichtingen uit AI Act artikel 25 (verplichtingen van gebruikers) en artikel 28 (verplichtingen van aanbieders) adresseren. Concreet gaat het om logging en auditbaarheid van AI-besluiten, menselijke toezichtmechanismen en verplichte risicobeoordelingen die de leverancier beschikbaar moet stellen.
Wie is aansprakelijk bij een datalek via een LLM-interface: de organisatie of de AI-aanbieder?
De verwerkingsverantwoordelijke (de organisatie) blijft eindverantwoordelijk richting betrokkenen en toezichthouders. De aanbieder als verwerker is aansprakelijk als het lek het gevolg is van een inbreuk op de overeengekomen verwerkersovereenkomst of wettelijke verplichtingen. Contractueel moeten meldingstermijnen (binnen 72 uur), forensisch onderzoeksverplichtingen en schadevergoedingsregelingen zijn vastgelegd.
Welke auditrechten zijn minimaal vereist in een DPA voor een soevereine AI-dienst?
AVG artikel 28 lid 3 sub h verplicht de verwerker om audits mogelijk te maken en eraan mee te werken. Bij soevereine AI-diensten betekent dit minimaal: het recht op inzage in logbestanden van LLM-interacties, het recht op een onafhankelijke penetratietest, toegang tot de SBOM (Software Bill of Materials) van het platform en het recht om sub-verwerkers te laten auditen of te laten vervangen.