This is an illustrative scenario, not a real practice or a real complaint. It was written to show the kind of risk a dental AI compliance screen is designed to catch.
A practice principal used AI to build the weekly staff rota and emailed it to the team. A few days later, a dental nurse asked why her name had been put into an AI tool, and where her data had gone.
The principal was on a business AI plan, so she assumed she was covered. She was only partly right.
The assumption: "I'm on a Team plan, so I'm covered"
The principal built the rota with a Claude skill on her practice's Claude Team account. A Team plan runs on business terms that include a data processing agreement. For staff names and shifts, that is the right footing.
But her Claude credits had run out. To keep working, she had earlier connected a DeepSeek API key through the terminal. In that setup, work done in the terminal tool is sent to DeepSeek's servers, not Anthropic's. She could not remember which route she had used for the rota.
That gap is the whole case. The plan she paid for was covered. The workaround she added was not.
The hidden route
The rota and the names were the same either way. What changed the risk was a setting in the terminal that nobody else in the practice could see.
What the screen found
Staff names and working hours are personal data under UK GDPR. They are not special category data, unless the rota also shows reasons such as sickness or maternity leave. Using AI for a rota is a normal administrative task. The risk sits entirely in the route the data took.
| Area | On the Claude Team account | If routed through DeepSeek |
|---|---|---|
| Processor agreement (UK GDPR Article 28) | Covered by business terms | Almost certainly none in place |
| International transfer | Covered by the provider's terms | DeepSeek is a China-based provider. The UK has no adequacy regulations for China, and no transfer safeguard such as the IDTA was in place. |
| Use of data for training | Restricted under business terms | Depends on DeepSeek's terms, which had not been checked |
| Staff transparency | Gap: the staff privacy notice did not mention AI | Same gap |
Even on the covered route, one gap remained. The nurse had not been told that AI was used for admin. That is the part she noticed, and it is the part that turned a routine task into a complaint.
What she did next
The first step was to find out what had actually happened, before replying to anyone in writing.
- Establish the route. Compare three things: when the rota email was sent, when the Claude credits ran out, and any activity on the DeepSeek usage dashboard that day. In the terminal, check whether the tool is pointed at DeepSeek.
- Disconnect the workaround. Remove the DeepSeek key from any workflow that touches staff or patient data.
- Log it. Record the incident in the internal breach log. For names and shifts the risk is probably low, so an ICO report may not be needed, but write that judgement down. If in doubt, the cautious route is to report within 72 hours.
- Call the defence organisation early. Before replying to the nurse in writing, bring them the timeline and whatever the dashboard shows.
- Speak to the nurse honestly. Explain what happened and what has changed, and offer to delete or minimise her data. Treat her request as a possible subject access request, which has a one-month deadline.
- Close the gap. Update the staff privacy notice and AI policy, and complete a short DPIA before using AI on staff data again.
If you're an associate
This is not only a principal's problem. If you use AI on your own account for practice work, such as drafting a referral or tidying notes, the same question applies to you: whose account is it, and what terms is it on?
A personal or consumer plan usually has no data processing agreement. Switching off model training does not create one. Removing names does not make data anonymous if the person could still be identified. If you are not sure, keep patient and colleague details out until your practice confirms a covered route.
Your 10-minute check
Ask your team these three questions on Monday morning.
- Which plan? Is every AI tool used for practice work on a business, team, enterprise or API plan with a data processing agreement?
- Whose account? Is it owned by the practice, or by an individual on their own login?
- Anything rerouted? Has anyone connected another provider's key, a wrapper, or a third-party tool that sends data somewhere else?
Then check one more thing: does your staff privacy notice say that you use AI for admin?
About this case study
This scenario was run through CompliAI Dental, a dental-specific AI compliance screener. It screens AI tools, workflows and content against privacy, AI disclosure, dental professional standards, advertising and medical device rules, and flags whether an AI account is actually covered by a data processing agreement.
Screening tool, not legal advice. Regulatory positions reflect the law as understood at the date above, and legislation changes. Obtain independent legal advice before deploying any AI system.