MCP-servers en de AVG: vijf vragen voordat je klantdata koppelt

Ik las de code van een populaire MCP-server voor Google Ads, mcp-google-ads, met ruim 700 sterren op GitHub. Hij laat een AI-assistent zoals Claude je advertentieaccounts uitlezen en analyseren.

Bij MCP-servers en de AVG zit de privacyvraag ergens anders dan ik in maart 2025 schreef. Toen noemde ik de verbindingsmethode, STDIO, een fundamenteel veiligheidsrisico. Dat was onjuist. Het echte AVG-risico zit in wat er in het gesprek met de AI belandt. En in waar dat gesprek heen gaat.

Wat een MCP-server doet

Een MCP-server is een koppelstuk. Hij geeft een AI-assistent gereedschap om gegevens op te halen uit een ander systeem, zoals Google Ads, je CRM of je mailbox.

Vraag je de assistent "welke campagnes deden het slecht deze maand?", dan haalt de server de cijfers op. Die cijfers gaan het gesprek in. Het gesprek gaat naar de aanbieder van het AI-model.

Wat ik in de code zag

Vier dingen, gelezen op 18 oktober 2026:

• Het transport is STDIO. De server draait als lokaal programma onder je AI-app en praat ermee via een interne pijp op je eigen computer. Er staat geen netwerkpoort open.
• De code leest alleen. Elke aanroep naar Google Ads is een zoekopdracht. Er zit geen enkele aanroep in die campagnes wijzigt.
• De sleutel kan meer dan de code. De server vraagt de volledige Google Ads-toegang aan, de scope adwords. Daarmee kan het token ook campagnes en budgetten wijzigen. Het ververste token staat als leesbaar bestand op je schijf.
• Eén tool laat elke query toe. Met run_gaql kan de assistent elk rapport opvragen dat de API kent, ook het rapport met zoektermen.

Dat zijn geen fouten van de maker. Het is gewoon hoe zo'n koppeling werkt. Juist daarom moet je de AVG-vragen zelf stellen.

Vijf AVG-vragen voordat je klantdata koppelt

1. Welke persoonsgegevens komen in het gesprek?

Geaggregeerde cijfers per campagne, zonder personen die je kunt herleiden, zijn geen persoonsgegevens. Een zoekterm waarin iemand zijn naam, adres of telefoonnummer intypte, is dat wel.

Kijk dus per tool wat er terugkomt. Bij Google Ads zit het risico vooral in het zoektermenrapport en in vrije query's.

2. Waar gaat het gesprek heen?

Naar de aanbieder van het AI-model. Die verwerkt de gegevens voor jou en is daarmee je verwerker. Dan heb je een verwerkersovereenkomst nodig (AVG artikel 28).

Grote aanbieders bieden die aan voor zakelijke accounts. Controleer of hij geldt voor het account dat je echt gebruikt. Een persoonlijk of gratis account valt er vaak buiten.

Draait de aanbieder buiten de EER, dan is het ook doorgifte. Die mag naar een Amerikaans bedrijf dat onder het EU-US Data Privacy Framework valt, of met standaardcontractbepalingen.

3. Wat kan de sleutel?

De server kan alleen wat zijn token mag. In dit voorbeeld mag dat token alles in het advertentieaccount.

Geef de koppeling daarom een eigen Google Ads-gebruiker met alleen leesrechten. Dan kan een gestolen of misbruikt token niets wijzigen. Bewaar het tokenbestand niet in een gedeelde map of een repo.

4. Wie draait het en voor wie?

Beheert een bureau of freelancer jouw account met een MCP-server, dan schakelt die partij de AI-aanbieder in als subverwerker. Daarvoor is vooraf schriftelijke toestemming van jou nodig (artikel 28 lid 2).

Een bestaande verwerkersovereenkomst die over "advertentiebeheer" gaat, dekt dat niet vanzelf. Vraag welke AI-tools er op jouw data draaien.

5. Is een DPIA nodig?

Niet automatisch. De Autoriteit Persoonsgegevens hanteert als vuistregel: voldoet een verwerking aan twee of meer van negen criteria, dan is een DPIA nodig. Nieuwe technologie is een van die criteria.

Koppel je een AI-assistent aan klantdata en profileer je daarmee, dan zit je al snel op twee. Hoe dat voor een AI-tool uitpakt, staat in DPIA voor een AI-tool, met een voorbeeld.

Waar STDIO wel over gaat

STDIO is geen datalek. Het betekent wel dat de server als programma op je computer draait, met jouw rechten. Hij kan bij je bestanden, je tokens en alles wat jij mag.

De vraag is dus niet hoe hij communiceert. De vraag is wat je installeert en of je de code vertrouwt. Daarover schreef ik in waarom ik MCP-servers niet meer zomaar installeeren inMCP-security: het transport is niet het probleem.

📖 Lees ook: AI en de AVG: wat mag wel en wat niet: de privacylaag onder elk AI-gebruik, ook zonder MCP

Wat je vandaag doet

1. Maak een lijst van elke MCP-server die in je bedrijf draait, ook die van een bureau.
2. Noteer per server welke gegevens er terugkomen in het gesprek. Zitten daar persoonsgegevens tussen?
3. Controleer de verwerkersovereenkomst met de AI-aanbieder voor het account dat je echt gebruikt.
4. Beperk de sleutel tot leesrechten en tot de accounts die nodig zijn.
5. Toets de DPIA-criteria en leg vast waarom je wel of geen DPIA doet.

Voor gevoelige data kan het ook zonder cloud. Een lokaal model op je eigen machine stuurt niets naar buiten. Wat er op een gewone Mac draait, staat in mijn Mac Mini M4 voor lokale AI.

📖 Lees ook: De 10 beste MCP-servers voor Claude Code in 2026: de lijst met servers en hoe je ze installeert

Waar je nu staat

De techniek is het makkelijke deel. Het lastige deel is weten welke AI er op welke klantdata draait. En wie dat heeft afgesproken.

Hoe ik dat in kaart breng en vastleg, beschrijf ik op mijn pagina over AI-governance.