How to Protect Client Data From AI: Three Layers

Three Layers

Protection isn’t a single rule but three layers: 🛡️

Layer 1 — Before it reaches the tool: rule and order

A written rule page, the single criterion, the team knowing it. And digital management’s data order: if client data is already kept minimal, in one place and with limited access, the chance of it going into a tool drops: the data load article.

Layer 2 — In the tool: account and settings

Tools in use are on the clinic account; any “use chats for training” setting is off; history is cleared regularly; browser extensions and auto-summarisers are off in the clinic email and booking system. That last item is the most often missed: some extensions read the inbox without asking.

Layer 3 — After the tool: audit

Once a quarter, ten minutes: who on the team uses which tool, is there client information in any history, has a new extension been installed. That round catches an accident before it grows: the maintenance article.

The Four Commonest Accidents

Accidents that happen even with a rule: ⚠️

Accident 1 — The well-meant summary

“A long message came in, let me summarise it.” The message carries client information; summarising it means handing it to a tool. Countermeasure: the “incoming messages are red” line on the rule page, and reception training.

Accident 2 — The personal phone

Not the clinic’s tool but the app on the practitioner’s phone: “I’ll ask about a case.” The rule is information-based — whatever the device, client information doesn’t go in. The commonest breach comes from the practitioner: the rule article.

Accident 3 — The auto-reading extension

Email summariser, calendar assistant, browser extension: once installed it reads the inbox and the appointment list. Nobody “entered” anything; the extension took it. Countermeasure: on clinic accounts, extension installs require the runner’s permission.

Accident 4 — The anonymisation fallacy

“I removed the name, no problem.” Age, occupation, neighbourhood and story details identify the person. In this vertical anonymisation opens no grey area; anything about a client is in the red: the usage article.

👉 None of the four accidents is malicious; all begin with the sentence “it’ll be fine”.

When an Accident Happens

If client information has entered a tool, four steps: 🚨

Step 1 — Don’t hide it, record it

What went in, into which tool, when, by whom. To the runner and the practitioner the same day. Hiding an accident turns a single accident into systemic risk.

Step 2 — Delete it in the tool

The chat history is deleted; if available, a “data deletion request” is sent. That doesn’t zero the risk but reduces it.

Step 3 — Assess the obligation

Personal-data regulation may create a notification obligation. That decision is taken with your own professional body’s current guidance and legal advice — this article is operating practice, not legal assessment.

Step 4 — Update the rule and the layer

Which layer did the accident pass through? If the rule was missing a line, add it; if a setting was missing, turn it off; if the audit was late, make it more frequent. The accident is recorded on the page as a lesson — without a person’s name.

And an honest note on scale

In this vertical even a single accident is serious; but what’s needed is sequence, not panic. In a clinic with the three layers built, accidents are rare and small; in one without them, frequent and unnoticed. The difference isn’t that accidents don’t happen, but that they’re seen. To inherit it built and district-locked: the parcel model.

Frequently Asked Questions