WhatsApp clinic agents: the AVG checklist before you deploy

Friday afternoon at a GP practice in Utrecht. The IT lead has a working WhatsApp prototype that books appointments, sends prep instructions for blood work, and answers the obvious questions about opening hours. The DPO sits down with fourteen questions on a yellow pad. By question three, the prototype is going back in the drawer.

We have shipped this pattern more than once for Dutch healthcare clients, and the shape is the same every time. The agent is the easy part. The pre-deploy checklist is the part that decides whether the thing ever sees a real patient.

What makes WhatsApp at a clinic different

The moment your agent reads a message that mentions a symptom, an appointment type, or a prescription, you are processing health data. Under the AVG (the Dutch implementation of the GDPR), that puts you inside Article 9: special-category personal data, prohibited to process unless you fit one of the named exceptions. For a GP, the usual hook is Article 9(2)(h): processing necessary for medical diagnosis, the provision of health care, and managed by a professional bound by professional secrecy.

The transport bites too. WhatsApp Business runs on the Meta Cloud API. Meta Platforms Ireland is your processor for messaging, with Meta Platforms Inc. in the US as a sub-processor. Read the WhatsApp Business Data Transfer Addendum once and the shape of the problem becomes clear: messages cross the Atlantic. You need a transfer mechanism, and the Autoriteit Persoonsgegevens will ask for one in writing.

The eight checks before any deployment

1. Lawful basis nailed in writing

You need two things: a basis under Article 6 (we use 6(1)(b), contract performance, for booking flows) and an exception under Article 9 (almost always 9(2)(h) for care delivery). Both go into the privacy notice the patient sees before the first message. If the agent ever crosses into anything that is not strictly care, like recall campaigns or research, you need a separate basis and a separate notice. Mixing the two and hoping no one notices is the failure mode that ends with a letter from the AP.

2. Sub-processor map you can defend

List every processor the message touches. A typical stack: Meta (transport), your cloud provider (compute, in an EU region), your LLM provider, your EHR vendor, your scheduling API. Each one needs a signed verwerkersovereenkomst on file. The LLM call is the part most teams handwave. If you are routing patient messages through an API that retains prompts for training, you have a problem no contract clause can paper over.

3. DPIA before code

Health data plus automated processing plus a new technology equals a mandatory DPIA on the AP's published list. We write the DPIA first, then build. The exercise forces you to name what data the agent will and will not see, and that constraint shapes the architecture. A DPIA written after launch is a DPIA rewritten under pressure.

4. Retention that matches the medical record, not the chat platform

The clinic's WGBO retention for the medical file is twenty years from the last entry. The chat transcript is not the medical file. We write the structured outcome (appointment booked at time X for reason Y) into the EHR and discard the raw message exchange within seven days. The DPO will ask "why seven and not seventy" and "what runs the deletion." Have an answer and a cron.

5. Logging without storing the message body

// 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)
}

The rule: if you would not want a patient to read the line in an access request, do not write it.

6. BSN never enters the chat

The Burgerservicenummer is the single hottest field in any Dutch healthcare integration. We strip it on the way in (regex on the inbound webhook) and refuse to write it on the way out. Identity matching to the EHR happens server-side, using date of birth plus a one-time confirmation code the patient receives in the thread but that the agent itself never sees back. The BSN stays in the EHR, where it belongs.

7. A working right-to-erasure path

An Article 17 request needs to take down the conversation log, the hashed conversation id, any queued reminders, and the patient's mapping in the agent's state store. We expose this as one call the DPO can trigger:

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

The endpoint logs the erasure (who, when, ticket reference) but not the data it erased. The DPO needs an audit trail; she does not need a copy of what you just deleted.

8. The incident path, rehearsed

Article 33 gives you 72 hours from discovering a personal-data breach to notifying the AP. For health data, the notification duty to affected patients kicks in too. Write the runbook before the incident: who calls whom, what gets cut off first (the WhatsApp number, the API key, the database connection), what the holding statement looks like. We rehearse it twice a year on every clinic deployment, on a calendar invite the DPO sends.

Five questions every DPO actually asks

1. "Show me where you got consent for WhatsApp specifically." The blanket privacy policy is not enough. The patient opts into the channel, and you log when.
2. "What happens if WhatsApp goes down or Meta changes the terms?" Have a fallback (SMS, voice call, web form) and a sentence in patient communication promising one.
3. "Who at the clinic can read the conversation, and how is that logged?" Role-based access on the admin console, every read logged with the user's name and a reason field.
4. "What does the agent do when it does not know?" Hand off to a human, every time. Confident wrong answers in healthcare get people hurt.
5. "What stops a curious developer from querying production?" Answer with a screenshot of the access matrix, not a sentence.

Containment as the design pattern

The architectural choice that survives a regulated audit is narrow surface area. The model sees only what it needs for the current turn, and cannot escalate its own privileges. For a WhatsApp clinic agent, that means the model never queries the EHR directly. It calls a typed booking function with a tight signature, and the function decides what comes back. If the model misbehaves, the blast radius is one rejected booking, not a leaked patient list.

That design choice also shortens the DPIA. You are not arguing about what an LLM might or might not do with a database connection; the LLM does not have one.

Where this lands

When we built the WhatsApp AI agent for a primary-care group in the Randstad, the conflict that surfaced was retention: the EHR vendor wanted to mirror every chat into the patient file while the DPO wanted seven-day deletion. We solved it by writing only the structured outcome to the EHR and keeping the chat in a short-lived store the EHR could not read, which closed the DPIA in one round.

Pull your current architecture diagram onto one page. Draw a red box around every place a message body touches storage. If the count is more than two, you have your morning's work.