WhatsApp-agents in de kliniek: de AVG-checklist vooraf

Vrijdagmiddag bij een huisartsenpraktijk in Utrecht. De IT-lead heeft een werkend WhatsApp-prototype dat afspraken inplant, voorbereidingsinstructies voor bloedonderzoek verstuurt, en de voor de hand liggende vragen over openingstijden beantwoordt. De FG schuift aan met veertien vragen op een geel kladblok. Bij vraag drie verdwijnt het prototype terug in de la.

Wij hebben dit patroon meer dan eens uitgerold voor Nederlandse zorgklanten, en de vorm is elke keer hetzelfde. De agent zelf is het makkelijke deel. De checklist vóór deployment is wat bepaalt of het ding ooit een echte patiënt te zien krijgt.

Waarom WhatsApp in een kliniek anders is

Zodra je agent een bericht leest waarin een symptoom, een afspraaktype of een recept voorkomt, verwerk je medische gegevens. Onder de AVG val je daarmee onder artikel 9: bijzondere persoonsgegevens, in principe verboden om te verwerken tenzij je past in een van de genoemde uitzonderingen. Voor een huisarts is de gebruikelijke grondslag artikel 9(2)(h): verwerking noodzakelijk voor medische diagnose, voor de verlening van gezondheidszorg, en beheerd door een professional gebonden aan beroepsgeheim.

Het transport hapt ook. WhatsApp Business draait op de Meta Cloud API. Meta Platforms Ireland is je verwerker voor messaging, met Meta Platforms Inc. in de VS als sub-verwerker. Lees het WhatsApp Business Data Transfer Addendum één keer en de vorm van het probleem wordt duidelijk: berichten steken de Atlantische Oceaan over. Je hebt een doorgiftemechanisme nodig, en de Autoriteit Persoonsgegevens vraagt er op papier om.

De acht checks vóór elke deployment

1. Grondslag op papier vastgelegd

Je hebt twee dingen nodig: een grondslag onder artikel 6 (wij gebruiken 6(1)(b), uitvoering van een overeenkomst, voor boekingsflows) en een uitzondering onder artikel 9 (vrijwel altijd 9(2)(h) voor zorgverlening). Beide staan in de privacyverklaring die de patiënt ziet vóór het eerste bericht. Zodra de agent iets doet dat strikt genomen geen zorg is, zoals recall-campagnes of onderzoek, heb je een aparte grondslag en een aparte verklaring nodig. De twee mengen en hopen dat niemand het ziet, is het faalpatroon dat eindigt met een brief van de AP.

2. Een sub-verwerkerskaart die je kunt verdedigen

Lijst elke verwerker op die het bericht raakt. Een typische stack: Meta (transport), je cloud-provider (compute, in een EU-regio), je LLM-provider, je EPD-leverancier, je scheduling API. Voor elk een getekende verwerkersovereenkomst in de la. De LLM-call is het onderdeel dat de meeste teams wegwuiven. Als je patiëntberichten routeert door een API die prompts bewaart voor training, heb je een probleem dat geen enkele contractclausule afdekt.

3. DPIA vóór code

Medische gegevens plus geautomatiseerde verwerking plus nieuwe technologie staat gelijk aan een verplichte DPIA op de gepubliceerde lijst van de AP. Wij schrijven de DPIA eerst, dan bouwen. Die oefening dwingt je te benoemen welke data de agent wel en niet ziet, en die beperking bepaalt de architectuur. Een DPIA geschreven na launch is een DPIA herschreven onder druk.

4. Bewaartermijn die past bij het medisch dossier, niet bij het chatplatform

De WGBO-bewaartermijn voor het medisch dossier is twintig jaar vanaf de laatste aantekening. Het chattranscript is niet het medisch dossier. Wij schrijven de gestructureerde uitkomst (afspraak gemaakt op tijdstip X voor reden Y) naar het EPD en verwijderen de ruwe berichtenwisseling binnen zeven dagen. De FG zal vragen 'waarom zeven en niet zeventig' en 'wat draait de verwijdering'. Heb een antwoord en een cron klaar.

5. Logging zonder de berichttekst op te slaan

// lib/agent-log.ts
type AgentEvent = {
  ts: string                  // ISO timestamp
  conversationId: string      // HMAC of phone number, salted per clinic
  intent: 'book' | 'reschedule' | 'cancel' | 'info' | 'handoff'
  outcome: 'completed' | 'queued_for_human' | 'failed'
  tokenCount: number          // cost accounting only, never the text
  modelVersion: string
}

export function logEvent(e: AgentEvent) {
  // No message_body, no phone_e164, no patient name.
  // Anything written here can surface in an AVG Article 15 request.
  logger.info(e)
}

De regel: als je niet zou willen dat een patiënt de regel terugleest in een inzageverzoek, schrijf je hem niet weg.

6. BSN komt nooit in de chat

Het Burgerservicenummer is veruit het heetste veld in elke Nederlandse zorgintegratie. Wij strippen het bij binnenkomst (regex op de inbound webhook) en weigeren het uit te schrijven. Identiteitsmatching naar het EPD gebeurt server-side, met geboortedatum plus een eenmalige bevestigingscode die de patiënt in de thread ontvangt maar die de agent zelf nooit terugziet. Het BSN blijft in het EPD, waar het thuishoort.

7. Een werkende route voor recht op verwijdering

Een verzoek onder artikel 17 moet het gesprekslog, de gehashte conversation id, eventuele in de wachtrij staande herinneringen en de mapping van de patiënt in de state store van de agent neerhalen. Wij stellen dit beschikbaar als één call die de FG zelf kan triggeren:

curl -X POST https://agent.clinic.example/admin/erase \
  -H "Authorization: Bearer $DPO_TOKEN" \
  -d '{"patient_id":"...","reason":"art17","ticket":"AP-2026-0412"}'

Het endpoint logt de verwijdering (wie, wanneer, ticketreferentie), maar niet de data die het verwijderde. De FG heeft een audit trail nodig; ze heeft geen kopie nodig van wat je net hebt gewist.

8. Het incidentpad, geoefend

Artikel 33 geeft je 72 uur vanaf het ontdekken van een datalek om de AP te notificeren. Voor medische gegevens komt daar de meldplicht aan betrokken patiënten bij. Schrijf de runbook vóór het incident: wie belt wie, wat wordt eerst afgesneden (het WhatsApp-nummer, de API key, de database connection), hoe ziet de holdingverklaring eruit. Wij oefenen dit twee keer per jaar bij elke kliniekdeployment, op een agenda-uitnodiging die de FG zelf verstuurt.

Vijf vragen die elke FG echt stelt

1. 'Laat me zien waar je specifiek toestemming hebt gekregen voor WhatsApp.' Het algemene privacybeleid is niet genoeg. De patiënt opteert voor het kanaal, en je logt wanneer.
2. 'Wat gebeurt er als WhatsApp uitvalt of Meta de voorwaarden wijzigt?' Heb een terugvaloptie klaar (sms, telefoon, webformulier) en een zin in patiëntcommunicatie die er één belooft.
3. 'Wie in de kliniek kan het gesprek lezen, en hoe wordt dat gelogd?' Rolgebaseerde toegang op de admin-console, elke leesactie gelogd met de naam van de gebruiker en een redenveld.
4. 'Wat doet de agent als hij iets niet weet?' Overdragen aan een mens, elke keer. Zelfverzekerde foute antwoorden in de zorg zorgen ervoor dat mensen schade oplopen.
5. 'Wat houdt een nieuwsgierige developer tegen om productie te queryen?' Antwoord met een screenshot van de toegangsmatrix, niet met een zin.

Inperking als ontwerppatroon

De architectuurkeuze die een gereguleerde audit overleeft, is een smal aanvalsoppervlak. Het model ziet alleen wat het voor de huidige beurt nodig heeft, en kan zijn eigen rechten niet uitbreiden. Voor een WhatsApp-agent in een kliniek betekent dat: het model queryt het EPD nooit direct. Het roept een getypeerde boekingsfunctie aan met een strakke signature, en de functie bepaalt wat er terugkomt. Misdraagt het model zich, dan is de blast radius één afgewezen boeking, niet een gelekte patiëntenlijst.

Die ontwerpkeuze verkort ook de DPIA. Je discussieert niet over wat een LLM met een database connection wel of niet zou doen; de LLM heeft er geen.

Waar dit landt

Toen wij de WhatsApp-AI-agent bouwden voor een huisartsenketen in de Randstad, kwam het conflict van de bewaartermijn naar boven: de EPD-leverancier wilde elke chat spiegelen naar het patiëntdossier, terwijl de FG zeven dagen verwijdering wilde. Wij losten het op door alleen de gestructureerde uitkomst naar het EPD te schrijven en de chat te bewaren in een kortstondige store die het EPD niet kon lezen. Daarmee was de DPIA in één ronde rond.

Trek je huidige architectuurdiagram op één pagina. Zet een rode kader om elke plek waar een berichttekst opslag raakt. Komt het aantal boven de twee uit, dan heb je je ochtendwerk gevonden.