Source-based comparative review · Last checked 1–2 August 2026
We compared 14 website AI chatbots promoted to aesthetic clinics or usable on clinic websites. The review separates marketing claims from public documentation and records what happened in manual browser tests: whether the widget loaded after optional cookies were rejected, what appeared in cookies or localStorage, whether conversations are retained, and what happens when a visitor asks a health-related question.
Short answer: no AI chatbot is GDPR compliant in isolation. A clinic must assess what the deployed widget collects, where conversations go, how long they remain, which subprocessors receive them, what visitors are told, and whether the clinic can execute the required contract and deletion workflow. In this comparison, public documentation and real deployment behaviour varied sharply—even among tools that describe themselves as GDPR compliant.
Primary topic: GDPR-compliant AI chatbot for an aesthetic clinic website · Also covers aesthetic-clinic chatbots, cookie consent, conversation retention, DPAs, subprocessors, HIPAA/BAA and health-answer boundaries.
What the comparison found
Personal data concerning health is a special category of personal data under GDPR Article 9. The GDPR also requires data minimisation and storage limitation under Article 5, while Article 28 requires controllers to use processors that provide sufficient guarantees and to govern processing by contract. For the underlying legal concepts, see our separate guide to how GDPR applies to an aesthetic-clinic AI chatbot.
Core comparison: 14 AI chatbots / assistants for clinic websites
This is intentionally a wide table. Scroll horizontally on mobile. “Evidence points” count how many of seven documentation fields were found: retention, browser storage, hosting/processing, customer DPA, public subprocessors, security documentation and independent assurance. It is not a GDPR, security, medical-safety or trust score.
How to read “not found”: it means we did not locate the item in the official pages checked by the stated date. It does not prove that the vendor lacks an internal document or will never provide one during sales. Ask the vendor directly and preserve the written answer.
Cookie consent and browser-storage results
A cookie banner answers only one narrow question: which browser technologies the tested page allows after a choice. It does not prove whether the text of a chat is retained on a server. Conversely, a functional localStorage session ID is not automatically advertising tracking. Clinics need to document both layers.
Why can a chat work after “Reject all”?
“Reject all” commonly means reject all optional categories. A vendor or clinic may classify a session identifier as strictly necessary for the chat service the visitor requested. That can be defensible, depending on the implementation and local law, but the classification does not authorise unlimited transcript retention or excuse missing privacy information. The deployment still needs a legal basis, transparent notice, data minimisation, suitable retention and an operational deletion process.
For strict markets such as Belgium, test the actual clinic deployment—not only the vendor website. Record the page before consent, after rejection and after the first message. Separate host-site analytics from widget storage by domain, key name and network request.
Product-by-product clinic notes
The table is the fastest comparison. These short notes preserve the context that is easily lost inside a yes/no cell.
Clinic buyer checklist: what to request before installation
A polished demo is not procurement evidence. Ask for documents and test the exact configuration you will deploy.
- A clinic-customer DPA. Confirm it is incorporated into your contract and covers the actual service, not only an agreement between the vendor and its own subprocessors.
- A named subprocessor list. Identify the model provider, cloud host, analytics, support tools, email/transcript services and every region in which they process data.
- A data-flow diagram. Follow a message from the visitor's browser through the widget, vendor backend, model, logs, CRM, email and human inbox.
- Exact retention rules. Ask separately about server transcripts, logs, backups, browser history, lead records, model-provider logging and copies sent by email or integration.
- Deletion mechanics. Test one conversation: delete it, export evidence of deletion and confirm what remains in backups or downstream systems.
- Consent and transparency options. Decide what appears before the first message, which storage is necessary, which is optional and whether the widget can remain disabled until your consent platform allows it.
- Health-data contract position. Do the terms permit GDPR Article 9 data? If not, what stops or redirects a visitor before they submit it?
- Medical-answer boundary. Require clear no-diagnosis/no-suitability rules, urgent escalation, human handoff and testing against real clinic content.
- Independent evidence. Request the current SOC 2 report, ISO certificate and scope where claimed. SOC 2 is an examination/report, not a product “certification.”
- Plan-specific controls. Verify whether EU hosting, custom retention, zero-data retention, BAA, audit logs or consent gating require Enterprise.
- Operational ownership. Name the person who will update prices, treatments, contraindications, contact details and emergency routing—and retest after every change.
Practical procurement rule: if a vendor cannot tell you whether conversations are stored, where they are processed and how they are deleted, the clinic cannot give visitors an accurate privacy notice or operate a reliable data-subject request workflow.
Are you a vendor listed in this comparison? Products, documentation and configurations change. If information about your product is outdated or you believe we have made a factual error, please contact hello@iglowly.com with a link to the relevant documentation. We will review supported corrections and update the comparison where appropriate.
Methodology, evidence standard and limitations
Research was conducted on 1–2 August 2026. We began with products marketed for aesthetic clinics and added established general chat/AI-agent platforms that a clinic buyer is likely to compare. The core set contains 14 products: iGlowly, Botmedica, FlashAI.pl, Omybox, Hyperleap, Astucia, Tidio/Lyro, Crisp, Intercom Fin, Chatbase, CustomGPT, ChatLab, tawk.to AI Assist and Elfsight AI Chatbot.
For every product, we looked for the same categories: public runtime, knowledge source, built-in medical content, health-answer boundary, lead behaviour, conversation storage, retention, browser storage, hosting/processing, customer DPA, subprocessors, security documentation, independent assurance and HIPAA/BAA information.
Official vendor pages and documents were preferred. Manual browser tests used an incognito session and inspected cookies and localStorage before consent, after optional rejection where available, and after messaging. Host-site analytics were excluded from the widget result when attribution was clear. A real deployment was named only when the observed widget could be linked to the compared product.
Evidence points (0–7) are documentation coverage only: one point each when usable evidence was found for retention, browser storage, hosting/processing, customer DPA, public subprocessors, security documentation and independent assurance. A vendor can document a risky practice clearly and receive a point; another may have a good internal control that is not public and receive none. The number must never be read as legal compliance, medical quality or overall trust.
- “Vendor states” identifies a first-party claim.
- “Observed” describes the tested deployment at the stated time.
- “Not found” means not located in the official materials checked, not proven absent.
- A vendor-site configuration does not guarantee identical behaviour on every customer embed.
- A browser test cannot prove server-side deletion, model-provider logging or backup erasure.
- A safe answer in one prompt does not establish clinical reliability.
Vendor pages, plans and policies change. Re-check all selected-vendor documents immediately before signing. For general regulatory interpretation, consult the GDPR text on EUR-Lex, the EDPB's GDPR principles and qualified privacy counsel.
Publisher disclosure. iGlowly publishes this comparison and is one of the products included. We used the same fixed fields for every product and link to vendor documentation wherever available. Statements about iGlowly are first-party claims unless an independent source is expressly named. This is procurement research, not legal advice or a certification of any vendor.