Trust

Where your data sits,who sees it,and what Sanne isn't allowed to do.

Most vendors fill this page with logos and certification badges. We'd rather fill it with facts: where it runs, which companies touch it, how long things stay, and what is nailed down in code rather than in a promise.

Updated 7 August 2026

0
recordings in our systems
Sanne works from text. The audio of your calls doesn't come in by default.
8
companies named
Everyone who sees any part of a call is in the table further down.
24 hours
until you hear from us
That's how long we may take after discovering a breach. After that the clock is yours.
1 month
for a caller's request
Access, correction or erasure. The deadline in Article 12(3) of the GDPR.

On this page

01Roles and liability
02Article 50 and the disclosure
03Where your data sits
04Sub-processors
05What we store
06Clinics and health data
07Retention periods
08Your clients' rights
09Security
10What Sanne won't do
11If something goes wrong

You own the data. We carry it out.

This isn't a formality. It decides who is liable for what when something goes wrong. Under the GDPR you are the controller for your clients' data. We are the processor: we may only do what you instruct us to, and that is on paper before you go live.

You decide

What Sanne may record, and how long it stays.
What happens when a client asks for their data or asks you to delete it. We supply the buttons, you make the call.
Whether you stop. Everything is gone within thirty days, or you take it with you as an export first.

We are bound to

Doing only what the processing agreement says. Not one thing extra because it happens to be convenient.
No model training on your calls. Not by us, and by contract not by the suppliers behind us either.
Telling you within 24 hours, so you can still make the 72 hours to the Dutch DPA.

The data we collect about *you*, as a visitor to this site or as a salon we called ourselves, is a different matter. There we're not the processor but the controller, and it's covered in the privacy statement.

She says she's an AI herself, in her first sentence.

Since 2 August 2026, Article 50 of the EU AI Act requires an AI system to disclose itself. Not in the terms and conditions, and not once per customer, but at the start of every conversation. The European Commission spelled that out on 20 July 2026 in guidance C(2026) 5054: the phrase 'virtual assistant' isn't enough if it doesn't make clear you're talking to a machine.

What a caller hears when she picks up

Good afternoon, [your salon]. You're speaking to Sanne, the AI receptionist. What can I help you with?

Every time she says that sentence, we record which version it was and when. That log can't be edited and can't be deleted, the database simply refuses. If someone asks in two years whether you disclosed it, that's the only kind of evidence still worth anything.

If a caller asks for a person, she transfers. Always, without pushing back and without trying one more thing first. On 2 October 2025 the Dutch DPA and the ACM jointly held that a chatbot needs a way out to a human. This is that way out.

How to check this yourself

1.Call the number on this site and listen to the first sentence. It's either there or it isn't.
2.Say 'can I speak to someone' halfway through and time how long she takes.
3.Ask us for the disclosure log for your own number once you're a client. You get the timestamps.

Where it runs. Not all of it is in the EU.

Here is the split: what runs where, and on what legal basis it may cross a border.

European Union

The application and all API traffic, pinned to Frankfurt.
The database holding your calls, summaries and appointments, in Frankfurt.
Your calendar, through Google Ireland.
Billing, through Stripe Payments Europe in Ireland.

This is where everything that's yours comes to rest: your calls, your calendar, your appointments, your invoices.

United States

Speech to text, and the voice Sanne answers in.
The language model that works out what's being asked.
The telephony around it, on European numbers where possible.

On the European Commission's standard contractual clauses, with a processing agreement per supplier.

Our hosting provider's logs contain no transcripts, no full phone numbers and no message bodies. Those logs aren't European, even when the code itself runs in Frankfurt. The only real fix is to keep out of them what doesn't belong in them.

If you need a chain that stays entirely inside the EU, it exists. The speech supplier sells a European environment, just not inside our standard package. Ask, and we'll quote it separately.

Who else touches it.

Every company that sees any part of a call, what they do and where they sit. If one is added you hear about it thirty days in advance and you can object. That's Article 28(2), and it's in the agreement too.

Company	What they do	Where
ElevenLabs	Speech to text, Sanne's voice, running the conversation	United States
Anthropic	The language model that works out what's being asked	United States
Twilio	Telephony and phone numbers	EU routing where possible, US parent
Vercel	Hosting the app and the API	Frankfurt, US parent
Supabase	The database	Frankfurt
Google Ireland	Writing into your calendar	European Union
Stripe	Billing and collection	Ireland, with parts in the US
WhatsApp Ireland	The WhatsApp channel, once it's live	Ireland, storage in Germany

ElevenLabs
What they doSpeech to text, Sanne's voice, running the conversation
WhereUnited States
Anthropic
What they doThe language model that works out what's being asked
WhereUnited States
Twilio
What they doTelephony and phone numbers
WhereEU routing where possible, US parent
Vercel
What they doHosting the app and the API
WhereFrankfurt, US parent
Supabase
What they doThe database
WhereFrankfurt
Google Ireland
What they doWriting into your calendar
WhereEuropean Union
Stripe
What they doBilling and collection
WhereIreland, with parts in the US
WhatsApp Ireland
What they doThe WhatsApp channel, once it's live
WhereIreland, storage in Germany

This list is the whole list. There's no 'and other service providers' at the end, because that's the exact phrase that makes a list like this worthless.

What we keep, and what we deliberately don't touch.

A call produces less data than you'd think, and that's a design choice. What isn't there can't leak, can't be requested, and can't be misused.

This we store

When the call came in, how long it lasted, over which channel.
What it was about, as a code from a fixed list: a cut, a colour, a consultation.
Whether it was booked, and which appointment came out of it.
The summary and the transcript, unless you're a clinic.
The phone number, in two ways at once. See the note below.

This never comes in

The recording itself. The platform refuses to accept the audio, so there's no switch to leave on by accident.
A voiceprint or any other biometric identifier. Nothing needs one, so nothing has one.
Free text at clinics. It's discarded on the way in.
Payment details. Stripe sees those, we don't.
Anything at all in a log file where it doesn't belong.

The phone number is in there twice. Once encrypted with AES-256-GCM, so you can call back. And once as an HMAC hash using a key that only lives on the server, and it's that hash we search on. Anyone holding the database without that key can't work a number back out of it. That's the difference between pseudonymising and just running a hash over something.

Clinics: a question about botox is health data.

A manicure is nothing special. 'Botox for my forehead lines' or 'laser for these acne scars' is special category data under Article 9 of the GDPR, even though nobody said a diagnosis out loud. That follows from Recital 35, from EDPB guidance 03/2020, and since 4 October 2024 from the Court of Justice's Lindenapotheke judgment.

So a clinic sits in the strictest mode by default. Transcript, summary and the model's own reasoning are discarded on the way in, and what's left is a code from a fixed list plus the fact that something was booked.

That isn't a checkbox someone can forget. It's a rule inside the database that rejects the row if it looks otherwise, and there's a test in our pipeline that fails the moment anyone removes that rule.

Storing less is also the cheapest way out of the NEN 7510 argument. A supplier without a structural role in healthcare doesn't have to meet that standard, but the argument only holds if you genuinely aren't storing health data.

How long it stays.

These aren't policy numbers. They live in a job that runs every night and does the deleting itself. You can set them lower, never higher.

What	How long
Recordings	Not keptThe audio doesn't enter our systems.
Transcripts and summaries	90 daysCan be set to 30 days or to zero. At clinics it's zero by default.
Who called, what was booked	2 yearsWithout content. This is what your overview is built on.
The AI disclosure log	24 monthsCan't be edited, can't be deleted early.
The audit log	12 monthsWho looked at what, and when.
Everything, after you cancel	30 daysOr sooner as an export, if you ask before you leave.

Recordings
How longNot kept
The audio doesn't enter our systems.
Transcripts and summaries
How long90 days
Can be set to 30 days or to zero. At clinics it's zero by default.
Who called, what was booked
How long2 years
Without content. This is what your overview is built on.
The AI disclosure log
How long24 months
Can't be edited, can't be deleted early.
The audit log
How long12 months
Who looked at what, and when.
Everything, after you cancel
How long30 days
Or sooner as an export, if you ask before you leave.

What a client can ask for, and what happens then.

A caller can ask for access, correction or erasure. The request lands with you, because you're the controller. We make sure you can handle it within the month without digging around anywhere by hand.

1
The request comes to you
You decide whether it's valid and whether you grant it. We don't take that decision off your hands, because that isn't a processor's job.
2
We search the hash, not the number
You enter the phone number, we hash it with the same server key and that finds everything attached to it. The number itself never has to travel anywhere.
3
Erasure happens in three places at once
In our database, at the speech supplier, and in your calendar. That last one we prepare rather than quietly change, because it's your calendar.
4
The appointment itself stays
Emptied out, but present. Article 17(3) allows that and your bookkeeping needs it. If we refuse a request, we record why.

The paperwork you get

1.A processing agreement, before you go live rather than after.
2.This sub-processor list, and notice when anything about it changes.
3.On request, an export of everything we hold on you, in a readable format.

Do you need a DPIA?

Probably. The Dutch DPA lists 'communications data' among the processing that requires a data protection impact assessment, and at a clinic Article 35(3)(b) lands on top of that. The assessment is yours, not ours, and we don't sign it. What we do: fill in half of it up front, with the retention periods that apply to your account, the sub-processors, and what gets recorded per call. That leaves you with the judgement, which is the part that was always yours.

How it's locked down.

Four things you're entitled to expect from a supplier and rarely get explained. All four can be checked by someone who knows what they're looking at, and they're welcome to.

One salon can't see another salon's data

Not because the code filters carefully, but because the database refuses. Every table is under row level security in forced mode, and without valid context you get zero rows back. The role the application logs in with isn't allowed to bypass that, and the migration fails if anyone tries to change it.

Keys and phone numbers are encrypted

AES-256-GCM with a separate key per row, and those keys are themselves encrypted. Which salon and which integration a row belongs to is bound into the encryption, so pasting a row from one environment into another produces an error instead of data.

Every incoming message is signature-checked

Against the raw body, with a time window against replay, and with a comparison that doesn't leak information through how long it takes. A message claiming to come from our telephony supplier but not actually from them is never processed.

The audit log only grows

Updates and deletes are blocked at database level, for us as well. A log you can edit afterwards isn't a log.

What Sanne isn't allowed to do.

Six rules that don't live in an instruction to the model but in the server behind it. The difference is that an instruction is a suggestion and code is a refusal. Nothing below can be talked around, however the conversation goes.

01
She never invents a slot. Availability comes from your calendar, not from her.
02
She confirms nothing until the appointment is actually in there.
03
She won't book without a name and a working number.
04
She never quotes a price she worked out herself.
05
She transfers the moment someone asks for a person. Always, no negotiating.
06
Every call produces a summary you can read in ten seconds.

Sanne proposes. The server decides.

If something goes wrong.

There's no supplier this never happens to, only suppliers who do or don't have a plan for it. Here's ours.

1
Within 24 hours
You hear from us, counted from the moment we discover it. With what happened, which data it touches and which of your clients.
2
After that the clock is yours
You're the controller, so the 72-hour notification to the Dutch DPA and the decision to inform your clients are yours. We supply the facts and a draft text.
3
You hear it from a person
No status page updating itself and no ticket number. We need a privacy contact from you before your account can exist, precisely for this: the database won't create the row without one.

Something this page doesn't answer?

Then it's a good question, and probably not only yours. Send it, and you'll get an answer from someone who knows. After that it goes on this page.

Send your question