July 24, 2026
GDPR and Conversational AI: What an Aesthetic Clinic Must Check Before Choosing a Tool
An aesthetic clinic that deploys an AI assistant to reply to patients remains, under the GDPR, the controller responsible for that patient data — even though an outside vendor runs the tool. What the clinic needs to check before choosing a tool comes down to four concrete points: who acts as processor and under what contract, where the data is stored and who can access it, what happens to the data if the contract ends, and whether conversations might contain health data requiring stronger protection. That last point is often overlooked, even though it applies directly to the aesthetic sector.
Why the clinic stays responsible, even when outsourcing the tool
The GDPR distinguishes the “data controller” (who decides why and how data is used) from the “data processor” (who processes data on the controller’s behalf, per its instructions). When a clinic installs an AI assistant on its website or social channels to talk with patients, the clinic remains the data controller: it decides to collect these messages, for what purpose, and it’s the clinic patients should be able to contact to exercise their rights (access, rectification, erasure).
The AI tool’s vendor acts as a processor, under a data processing agreement (DPA) that must exist between the clinic and that vendor, per Article 28 of the GDPR. A clinic that can’t get hold of that agreement, or whose vendor can’t clearly explain this role, has a compliance problem — regardless of how good the tool is technically.
Patient conversations can contain health data
This is the point most specific to the aesthetic sector, and the most commonly underestimated. A message about wanting a nose reshaped, asking about a surgical procedure, or mentioning a skin condition potentially falls under the special category of health data defined in Article 9 of the GDPR — a category subject to stronger safeguards than an ordinary contact detail like a name or phone number.
In practice, this means a tool built only to capture contact details (name, phone, email) isn’t necessarily built to securely handle the detailed content of a conversation touching on a medical procedure. Before choosing a tool, it’s entirely fair to ask the vendor how it specifically handles this kind of content — not just the contact details attached to it.
Why a “one instance per clinic” architecture isn’t a minor technical detail
Many conversational AI tools run on shared infrastructure: every customer sits on the same database, the same servers, separated only logically by an account ID. That model works, but it concentrates risk: a security flaw or a misconfiguration could, in theory, expose several clinics’ data at once.
An architecture where each clinic has its own isolated instance reduces that risk by design: one clinic’s data never passes through the same processing space as another’s. That’s the approach CliniqoAI takes — only the connection layer to Meta’s channels (WhatsApp, Instagram, Messenger) is centralized, for managing the technical authorization flow, while each clinic’s conversations and knowledge base stay within its own instance. For a clinic, this also simplifies something very concrete: in the event of an audit or a patient request, it’s easier to show exactly where your data lives when it was never mixed with another practice’s in the first place.
What to check before signing
Four questions let you quickly assess a tool from a GDPR angle, beyond its feature list:
- Is there a data processing agreement (DPA)? A serious vendor should be able to hand it over without hesitation.
- Where is the data hosted, and through which sub-processors (hosting provider, AI provider)? If any sub-processor sits outside the European Union, a recognized transfer mechanism (Standard Contractual Clauses, an adequacy decision) should be identifiable.
- What happens to conversation history if the contract ends? Deletion or data export should be contractually guaranteed, not left to the vendor’s discretion.
- Is the tool designed for exchanges that may touch on health data — or only for capturing ordinary contact details?
This isn’t legal advice
This article aims to give a clinic the right instincts and vocabulary to question a vendor — it doesn’t replace advice from a data protection officer or legal counsel on your specific situation, particularly if your clinic already processes health data in other systems (patient records, medical software) and wants to make sure its overall GDPR compliance is consistent.
At CliniqoAI, this per-clinic isolation model and clear processor role are detailed in our privacy policy, which we share with every client clinic so it can verify these points itself before entrusting us with its data.