MCP en wetgeving: AVG, DORA, NIS2 en de AI Act

Wie een AI-agent via MCP aan een CRM, ERP of polisadministratie hangt, doet juridisch gezien niets nieuws: er is geen "MCP-wet". Maar de combinatie van vier bestaande kaders — AVG, DORA, NIS2 en de AI Act — raakt MCP-gebruik wél op punten waar de meeste organisaties nog geen antwoord op hebben. Dat dit geen theoretische discussie is, blijkt uit de adoptiecijfers: volgens de Stacklok-survey uit 2026 heeft 41% van de enterprises MCP al in productie, en Anthropic meldde eind 2025 ruim 10.000 actieve publieke MCP servers. Tegelijk noemt volgens Integrate.io 65% van de financiële instellingen datasecurity als grootste barrière voor agentic AI. Dit artikel loopt de vier wetten langs, met per wet een praktische checklist. Nieuw bij MCP? Lees eerst wat MCP is en hoe het werkt.

Valt een MCP-server onder de AVG?

De kernvraag onder de AVG is: wie verwerkt de persoonsgegevens die door de MCP-koppeling stromen? Draait de MCP server lokaal op je eigen infrastructuur, dan blijf je zelf verwerkingsverantwoordelijke en komt er geen extra partij bij. Maar gebruik je een gehoste (remote) MCP server van een derde, of stuur je via de koppeling klantgegevens naar een AI-modelleverancier, dan zijn dat verwerkers — en dan is een verwerkersovereenkomst verplicht. In de praktijk wordt die vraag zelden gesteld: MCP servers worden geïnstalleerd door developers, niet beoordeeld door privacy officers. De Autoriteit Persoonsgegevens wijst in haar richtsnoeren over beveiliging van persoonsgegevens op de plicht om passende technische en organisatorische maatregelen te nemen; bij overtredingen kan de AP boetes opleggen tot €20 miljoen of 4% van de wereldwijde jaaromzet.

Twee AVG-onderwerpen verdienen bij MCP extra aandacht. Ten eerste de DPIA: bij verwerkingen met een hoog privacyrisico is een data protection impact assessment verplicht. Een AI-agent die zelfstandig klantdossiers doorzoekt, e-mails leest of gegevens combineert uit meerdere systemen is precies zo'n verwerking — zeker wanneer er bijzondere persoonsgegevens in het spel zijn, zoals gezondheidsgegevens in een polisadministratie of verzuimdossier. Ten tweede de meldplicht datalekken: een gecompromitteerde MCP server is al snel een meldplichtig datalek bij de AP. Dat is geen hypothetisch scenario. In september 2025 werd de kwaadaardige npm-package postmark-mcp betrapt terwijl die stilletjes elke uitgaande e-mail — wachtwoordresets, facturen, interne memo's — doorstuurde naar een aanvaller. Wie zo'n server draaide met klantmail, had een datalek te melden.

Wat betekent DORA voor financiële instellingen die MCP gebruiken?

Voor banken, verzekeraars, pensioenfondsen en beleggingsondernemingen komt daar DORA bovenop. DORA verplicht financiële instellingen hun ICT-derdenrisico te beheersen: elke externe ICT-dienstverlener moet in kaart worden gebracht, opgenomen in het informatieregister en doorlopend worden gemonitord. Een externe MCP server, een MCP-gateway van een leverancier en de AI-modelleverancier zelf zijn stuk voor stuk zulke ICT-derden — ook als een developer ze "even" heeft aangesloten zonder inkooptraject. Hier zit bovendien een erkende blinde vlek: securityonderzoeker Bitsight wijst erop dat DORA géén bepalingen bevat die specifiek zien op AI-modelproviders of orkestratielagen zoals MCP. De verplichting om het risico te beheersen bestaat dus wel, maar de vertaalslag naar deze nieuwe categorie leveranciers moet elke instelling zelf maken — en aan de toezichthouder kunnen uitleggen.

Die toezichthouder kijkt in 2026 nadrukkelijk mee. DNB heeft aangekondigd het toezicht op AI en cyberweerbaarheid bij banken en verzekeraars dit jaar te verscherpen, en volgens Integrate.io gebruikt naar verwachting 44% van de finance-teams in 2026 agentic AI — een groei van 600% ten opzichte van een jaar eerder. De combinatie van snelle adoptie en een regelgevingsgat maakt MCP-gebruik bij financiële instellingen tot een klassiek geval van "wel toegestaan, maar bewijs maar dat je in control bent". Hoe dat er per deelsector uitziet, lees je in onze gidsen voor banken en fintech en verzekeringen.

Waarom raakt NIS2 elke MCP-connector?

NIS2 — in Nederland geïmplementeerd via de Cyberbeveiligingswet — verplicht essentiële en belangrijke entiteiten tot risicobeheer in de hele leveranciersketen. En dat is precies waar MCP het speelveld verandert: elke MCP-connector die een medewerker toevoegt, is een nieuwe leveranciersafhankelijkheid én een nieuw aanvalsoppervlak. Waar een klassieke SaaS-leverancier via een inkooptraject binnenkomt, wordt een MCP server vaak met één installatiecommando toegevoegd — inclusief de rechten van de gebruiker en toegang tot echte bedrijfsdata. Het risico is concreet: uit het UpGuard-onderzoek naar het MCP-ecosysteem (2026) blijkt dat 10 tot 16% van de servers in de onderzochte registries typosquats of lookalikes zijn, met per officiële merkserver drie tot vijftien ongeverifieerde imitaties. Eén verkeerd gekopieerde servernaam installeert code van een aanvaller.

Ook verder stroomopwaarts in de keten gaat het mis. In oktober 2025 lekte bij hostingplatform Smithery via een path-traversal-fout een token dat controle gaf over meer dan 3.000 gehoste MCP servers, en het postmark-mcp-incident liet zien dat een vertrouwd pakket in één punt-release kwaadaardig kan worden. Voor NIS2 betekent dit dat je MCP-connectors moet behandelen zoals elke andere kritieke leverancier: geïnventariseerd, beoordeeld, gemonitord — en gedekt door je incidentmeldproces richting de toezichthouder. De technische maatregelen die daarbij horen (allowlists, sandboxing, versie-pinning, egress-controle) werken we uit op onze veiligheidspagina.

Wat eist de AI Act van bedrijven die MCP gebruiken?

De AI Act is als enige van de vier specifiek voor AI geschreven, en de klok tikt: de resterende verplichtingen worden in augustus 2026 en augustus 2027 van kracht. Voor de meeste MCP-toepassingen — een assistent die vergaderverslagen samenvat of data opzoekt — blijven de verplichtingen beperkt. Maar de AI Act merkt onder meer kredietbeoordeling en verzekeringspricing aan als hoog-risicotoepassingen, en juist daar wordt MCP interessant: het protocol maakt het eenvoudig om een AI-model rechtstreeks aan acceptatie-, pricing- of scoringsystemen te koppelen. Wie dat doet, haalt de hoog-risico-eisen binnen: risicobeheer, datakwaliteit, technische documentatie, logging, menselijk toezicht. De AFM krijgt hier nieuwe toezichttaken; in juni 2026 publiceerde zij een uitvoeringstoets over haar rol onder de AI Act.

De Nederlandse toezichtsagenda geeft richting aan wat er verwacht wordt. De AFM benoemde digitale weerbaarheid en verantwoorde AI als speerpunten voor 2026, wil regels voor de inzet van AI-agents op kapitaalmarkten en roept instellingen nu al op om drie dingen te doen: AI-toepassingen inventariseren, beslislogica documenteren en incidenten melden. Voor MCP-gebruik betekent dat concreet: leg vast welke agent bij welke systemen kan, welke tools hij mag aanroepen en op basis waarvan hij beslissingen voorbereidt of neemt. Dat documenteren is bij agentic AI lastiger dan bij een klassiek model — een agent combineert tools en data per sessie anders — en juist daarom wil je het vanaf dag één inregelen in plaats van achteraf reconstrueren.

Hoe pak je dit praktisch aan?

De vier wetten stellen verschillende eisen, maar het fundament is telkens hetzelfde: weten wat er draait, weten waar je data heen gaat en kunnen aantonen dat je in control bent. Wie dat fundament legt, dekt het grootste deel van alle vier de kaders tegelijk af.

1. Inventariseer alle MCP servers en AI-koppelingen in de organisatie, inclusief wat er buiten IT om is geïnstalleerd.
2. Classificeer per koppeling: welke persoonsgegevens (AVG), welke leverancier (DORA/NIS2), welke risicocategorie (AI Act).
3. Regel de papieren kant: verwerkersovereenkomsten, opname in het informatieregister, DPIA's waar nodig.
4. Beperk technisch: allowlist, minimale scopes, EU-datalocatie, logging — zie de veiligheidspagina voor de volledige aanpak.
5. Documenteer en monitor: beslislogica vastleggen, versies pinnen, incidentproces testen, en periodiek herbeoordelen.

Laatst bijgewerkt: 2026-07-05