Privacy Policy (version 25 August 2026, not yet in effect)

This version has not taken effect yet. It is not the version that applies now. Read the current version

SwiftGuard provides an AI voice agent that answers phone calls for plumbing and heating businesses across Europe. This policy explains what personal data we handle, why, how long we keep it, and the rights you have. It also explains the two roles we play: we are the data controller for the account and billing data of the businesses that use SwiftGuard, and we are a data processor for the personal data of the people who call those businesses.

In this policy, you means the business (and its staff) that holds a SwiftGuard account. Callers means the people who telephone your business and speak with the agent. Visitors means anyone who reads our website without holding an account. Invited colleagues means people whose email address an account holder has given us in order to invite them, whether or not they have accepted. Most of this policy is written for you, the business; section 5 speaks directly to callers about the one thing we do with call data for our own purposes, and section 3 covers visitors and invited colleagues.

In short

• We collect the account, security and billing data we need to give you the service - and, when the agent answers calls for you, we handle your callers' data on your behalf to run and record those calls.
• We do not sell personal data and we do not use it for advertising.
• We use only strictly necessary cookies, so there is no cookie-consent banner.
• You can access, correct, export or delete your data, and object to some uses - email [email protected].
• You can complain to your local data protection supervisory authority; ours is the Dutch Autoriteit Persoonsgegevens.

1. Who we are

SwiftGuard is provided by SwiftGuard AI, our registered name with the Netherlands Chamber of Commerce (KvK) under number 75538288 - a sole proprietorship (eenmanszaak) run by Daan van den Bergh, at Ensahlaan 25, 3723 HT Bilthoven, The Netherlands ("we", "us"). As a sole trader, he is the controller of the account, security and billing data described in section 2.

For any privacy question, or to exercise your rights, contact us at [email protected].

2. Data we collect and control (about you, our business customer)

Providing your name, email and business details is necessary to create an account and use SwiftGuard; if you do not provide them, we cannot give you the service. The forwarding number is needed for the agent to answer calls for you, and billing details are needed to hold a paid subscription; a waitlist enquiry is entirely voluntary, and the only consequence of not making one is that we cannot tell you when we open where you work. Your password is stored only as a secure one-way hash. We never store full card numbers or security codes - card payments are handled entirely by Stripe on its own hosted checkout.

3. Why we use your data, our legal basis, and how long we keep it

Where we rely on legitimate interest, our interest is running a secure and reliable service; you can object at any time (see section 9). We do not sell your personal data, we do not share it for advertising, and we do not send marketing emails from the service.

What deletion reaches, and what it does not. When we delete data - because you closed your account, because you deleted it yourself, or because you asked us to - it goes from our live systems at that point. Any residual copies in our platform backups clear on the backup platform's normal rotation. That applies to everything described in this policy, including the caller data in section 4.

4. Data we process for you (about your callers)

When our agent answers calls for your business, we act as your data processor - you are the controller and we process caller data only to provide the service and on your documented instructions, under a data processing agreement (available on request). To be sure it is really your customer on the line, the agent starts from the number they are calling from and finds their record by it - so a caller ringing from a number you do not hold, or from a withheld number, cannot reach an existing record at all. To act on that record the agent needs proof of who is calling, and there are two ways to give it: the postcode and house number held on the record, or a one-time code we text to that same number. A caller who reads back the texted code has proved enough for anything the agent can do on that record, including changing or cancelling a booking, even if they never knew the postcode. The postcode and house number on their own are enough to reach the record and book a job, but not to change or cancel one - that always needs the code as well. Two things sit outside that, and we would rather say so than let you assume otherwise: booking a new appointment does not require the texted code, and a caller the agent cannot place at all can still leave a message for you - which stores their name, the number to ring back and what they said, with neither check. That is deliberate. A caller we cannot verify is still a caller, and a message nobody took is a customer nobody called back. The caller data we handle for you includes:

• Caller and job details recorded by you or by the agent: phone number, name, optional email, service addresses, and free-text notes about the job.
• What we use to check a caller is who they say they are: the postcode and house number they give us - kept separately from their service address, purely so the agent can ask for them again before it changes one of their bookings over the phone; whether their phone number is a mobile that can receive a text message (we check this so we do not text a landline that would never receive the message); the one-time code we text them; and the date their number was confirmed.
• The call itself: the recording, a written transcript of what was said, and a short AI-written summary of the call. Three different providers are involved, and section 7 says which does what: our telephone provider records the audio, our voice platform listens and speaks and writes the transcript, and a separate provider writes the summary afterwards.
• Messages the agent takes for you when a caller does not want an appointment, or cannot be verified: who called, the number to ring back, and what they asked.

How long caller data is kept: caller records are kept until you delete them or close your account - you control how long they are kept. The recording of the call is held by our telephone provider, Twilio, on our behalf; we do not keep a copy of the audio ourselves. We do store the written transcript and the AI summary of each call in our own database. We delete the transcript and summary 90 days after the call, and we delete the recording on the same 90-day schedule - our telephone provider does not remove old recordings by itself, so we run a job that deletes each one by the time its 90 days have passed. Messages taken for you, and the appointments the agent books, are the exception to that 90 days: they are your record of work waiting and work booked, so a message, and an appointment with its address and the notes from the call, stay until you delete them or close your account, even after the call they came from has gone. A one-time code is never stored in a readable form, expires within five minutes, and is deleted the moment it is used. Two counters outlive everything else: so that the same number cannot be texted over and over, and so that nobody can keep guessing at the postcode and house number, we count those attempts against the caller's phone number - and that count, which contains the number itself, is kept for up to two days after the last attempt even if the caller's record has been deleted in the meantime. Without it, deleting a record would simply hand whoever asked a fresh set of texts and a fresh set of guesses. When we look an address up, we keep the address we looked up and where it turned out to be - the address as the geocoder gave it back, with its position - for up to 30 days so we do not have to look the same one up twice; that copy carries no name, phone number or account with it, and it is not linked back to the caller or to you, so it can outlast the record it came from by up to that long. We also keep, for each business, what our telephone provider told us about one of its callers' numbers when the agent was about to text a code to it - the number itself together with whether it is a mobile that can receive a text message or a landline that cannot - for 90 days from the last time we checked, so we do not pay to send a code to a line that could never receive it. Unlike the address lookup above, that copy does hold the caller's number, and it stays for the remainder of those 90 days even if the caller's record has been deleted in the meantime; it is deleted when the business account is closed. A caller can also appear in our security event log - for instance when a code was texted to them, or when someone failed the postcode check on their record. If the business account is closed, everything in those entries that says who the caller was, their phone number included, is stripped out of the entries recorded for that account: the entry stays, but it no longer says who was on the line. An entry we cannot match to that account is removed by the 180-day limit on that log instead.

Sensitive details a caller volunteers. We do not ask callers about their health, their beliefs, or anything else the law treats as a special category, and the agent is not built to collect it. A caller may still mention something of that kind while explaining the job - why the heating has to be fixed today, or who is in the house. When that happens it is part of the call like everything else they said: the same purpose, the same basis and the same retention, and it goes when the call goes. It is not filtered out before the job description reaches a calendar you have connected (see section 7). If you would rather a particular call or appointment were not kept, delete it, or ask us.

Because you are the controller of caller data, callers who wish to exercise their rights should contact your business; we will help you respond. The one exception is the review described in section 5, which is ours rather than yours.

5. Call recording and transcription

Calls answered by the agent are recorded and/or transcribed so the agent can understand the request, book the job, and give you a record of the call. As the business, you decide whether calls are recorded, for what purposes and for how long, and you choose the legal basis as the controller - typically performing the service the caller asked for, or your legitimate interest in documenting and improving service, with a way for callers to object.

The agent tells every caller, in its opening line, that it is an automated assistant and that the call is recorded - before they say anything about their job. If a caller objects to being recorded, it tells them plainly that it cannot switch the recording off and that they can hang up and contact the business another way instead. That announcement is a notification, not a request for consent, so as the business you are still responsible for complying with call-recording and telecoms law in each country you take calls in (see our Terms of Service). It matters most in countries such as Germany, Austria and Belgium, where everyone on the call must clearly consent to being recorded - there, an announcement on its own is not enough.

The agent understands what callers say in order to handle the call. It does not analyse the sound of a caller's voice to recognise who they are: we do not perform voiceprint or biometric identification.

There is one thing we do with call data for our own purposes, and we would rather say it plainly than bury it: a small number of our staff may listen to recordings and read transcripts to see how well the agent handled a call and to make it better - for example when it mis-hears an address, or fails to book a job it should have booked. That access is limited to the few people who operate the service and hold its credentials, and they are bound to confidentiality. We do not use this data to train AI models (see section 10) - we listen to check and correct how the agent behaves, not to feed it into a model.

For this one purpose we are not acting on the business's instructions but on our own, so for it we are the controller and we are answerable for it.

If you are a caller, this part is about you, and it is ours to answer for. The controller is SwiftGuard AI, the sole proprietorship named in section 1, reachable at [email protected]. What we do: a small number of our staff may listen to the recording of your call, or read its transcript, to check how the agent handled it and to correct it. What that covers: the recording, the transcript, and the caller and job details on the record the call belongs to - your phone number, your name, any email address, the service address and the notes about the job - which reach us either from what you said on the call or from the business itself, where it entered or corrected them. Why we may do it: our legitimate interest in making the agent accurate, safe and reliable - which is also what protects you from a mis-booked emergency. How long: the recording and the transcript are deleted 90 days after the call, like every other call, and we keep nothing separate for this. You can ask us what we hold about you, ask for it to be corrected or erased, and complain to a supervisory authority - section 9 sets out those rights and applies to you as much as to the business.

Your right to object to this use. You can object at any time, on grounds relating to your particular situation. Email us, tell us why it matters in your situation, and we will stop unless we have compelling legitimate grounds to carry on.

How this notice reaches you: through this page. The agent's opening line tells you that it is automated and that the call is recorded; it does not read a privacy notice aloud, and we have no address to write to you at. So if nobody pointed you here and you want any of the above, an email is enough - we will not ask you to prove you read this first.

We also keep a small set of technical measurements about each call, so we can tell how well the service is working and make it better. These are figures about our own software, not about the person on the line: how quickly the agent replied, how long each of its actions took and whether they succeeded, how many times the caller and the agent each spoke, whether our providers reported an error, and which AI model answered the call. They contain no recording, no transcript, no name, number or address - nothing a caller said.

We keep them for the same purpose and on the same basis as the review described above - our legitimate interest in making the agent accurate, safe and reliable. They are stored alongside the record of the call, so they are deleted with it after 90 days, and if you ask us to delete a call they go with it.

6. Cookies

We use only strictly necessary cookies. Our sign-in system sets a secure, HTTP-only session cookie so you stay logged in (about 7 days). If you tick "remember this device" when you sign in, we set a second cookie so that browser does not have to ask for an emailed code every time - it lasts 14 days from the last time you use that browser, so signing in again within those 14 days starts them over; it never waives your password, changing your password ends it, and you can end it yourself from your account page. A few others are short-lived and exist only to carry a sign-in or a calendar connection safely across the few clicks it takes. Our website also remembers which language you are reading in: if you pick a language yourself, that choice is kept for a year so you are not sent back to the wrong one on your next visit; if you have not picked one, the site remembers only the language of the page you are on, and forgets it when you close your browser. Either way that cookie holds a language code and nothing else. Two other companies set cookies of their own: Stripe, inside the billing area, to run checkout and prevent fraud, and Cloudflare, which sits in front of our site. Every one of these is necessary to provide the service you have asked for, which is the basis on which we set them, and our Cookie Policy lists each one by name, what it is for and how long it lasts.

On our documentation pages, the "was this helpful?" buttons record only the page, the language and the vote. So that nobody can vote thousands of times, we replace the reader's IP address with a scrambled value, keep no record of the original, and use it only to count. We cannot read an address back out of it - though it is not anonymous, because given an address it can be checked against the value - and we delete it a day after your last vote.

We do not use analytics, advertising or tracking cookies, and nothing of ours follows you or builds a picture of you. One script does examine your browser: Cloudflare's security check, which tells a real visitor from automated traffic. It is part of Cloudflare's service rather than something we add, we cannot switch it off on the plan we use, and it may set a cookie of its own - our Cookie Policy describes it. Every cookie named there is needed to run the service you asked for, so no cookie-consent banner is required.

7. Who we share data with

Most of the providers in the table below process personal data on our behalf: they may use it only on our instructions, and the law requires a written data-processing contract with each of them. We require one from every such provider and are working to get them signed. Until one is, what governs that provider is its own published terms and data-processing agreement rather than one negotiated with us; you can ask us at any time which agreements are in place.

Two entries in the table are not in that position, and we would rather name them than let the sentence above cover them: Stripe acts as merchant of record for your subscription, and Google checks who you are if you use "Continue with Google". Each of those decides for itself how it handles the data it holds, under its own terms rather than on our instructions - which is also why section 3 says your invoices and tax records are Stripe's. A calendar you connect yourself works differently again - see below the table.

One further recipient is possible rather than current: if this business is merged, reorganised or sold, the personal data described in this policy may transfer to the successor, and it remains subject to this policy or to one no less protective of you. Section 16 of our Terms of Service sets the same rule for the contract itself.

Google appears in that table twice, for sign-in and as one of the language models reached through our voice platform. Your Google Calendar is a separate matter again and sits outside the table, because a calendar you connect is not a provider we engage on your behalf. If you choose to connect a calendar, you connect your own Google account, under your own agreement with Google, and you can disconnect it - or withdraw our access in your Google account - at any time. Google asks you to allow two permissions: to see your calendar, and to create and change events on it. That is broader than what we use: we read which calendar it is and its timezone when you connect, read your free/busy times, create the appointments the agent books, and delete an event again if that appointment is cancelled or if we created it in error.

What we put in the calendar event: the appointment time, the job address, and the free-text job description and notes from the call. There is no field for the caller's name, phone number or email and we send none - but the address itself identifies the caller, and the free text is written by the voice agent from what the caller said and is not filtered before it reaches Google, so it can contain identifying and sometimes sensitive detail about the caller and their home (see the note on sensitive details in section 4). The event is stored on Google's infrastructure, including in the United States, under your agreement with Google and Google's own safeguards rather than ours. Appointments already written stay in your calendar after you disconnect - they are yours.

A word about the language model, because it is the part of a call that always leaves Europe. Our voice platform hears the caller in Europe, and speaks to them from Europe unless we have set a speaking voice for that language that works outside the EU (see the table above and section 8), but to work out what the caller means and what to say next it passes the words - as text, not audio - to a language model in the United States: Google's, and OpenAI's if Google's is unavailable. We do not hold an account with either of them for this; our voice platform reaches them, pays for them and is responsible for them under its own contracts, in the same way a builder brings their own subcontractor. We name them here anyway, because what your caller says does travel there and you should not have to take that on trust. The full, current list of everyone in that chain is set out in Annex III of our Data Processing Agreement, and is also available on request.

8. International transfers

We store our core database in the European Union (Frankfurt). Listening to the caller, transcribing what they say, and writing the summary afterwards all happen inside the European Union. Speaking the agent's replies happens inside the European Union too, unless we have set a speaking voice for the language being spoken that works outside it - ElevenLabs is the one such voice the service is set up to be able to use - in which case the words the agent says are turned into speech in the United States, under that provider's own published data-protection terms rather than under clauses we hold ourselves. No language is set to a voice outside the European Union today, and we will tell you on request which languages, if any, are set that way.

Some of our providers do process personal data outside the European Economic Area, mainly in the United States: Twilio (which carries the call and holds the recording), Stripe, Resend, Railway, and Cloudflare's global network. We do not yet hold signed data-protection clauses of our own with every one of them. Until we do, the safeguard for a transfer is whatever that provider's own published data-protection terms give us, and where those terms incorporate the EU Standard Contractual Clauses those clauses are the safeguard for that transfer; where a provider states that it is certified under the EU-US Data Privacy Framework we additionally rely on that statement. We have not independently verified any provider's current certification, and we will not tell you that we have. You can ask us at [email protected] which safeguard covers any provider we engage directly: we will send you a copy where one exists, and tell you plainly where one does not.

If you sign in with Google rather than with a password, your email address and basic profile are checked by Google in the United States. Google states that Google LLC is certified under the EU-US Data Privacy Framework and that it relies on the EU Standard Contractual Clauses where adequacy does not apply. You can avoid this transfer entirely by signing in with an email address and password instead.

One further transfer is not made by us but by our voice platform: to understand the call it sends the spoken words, as text, to a language model in the United States (see section 7). That transfer is made by our voice platform under its own safeguards rather than ours, so it is the transfer in the call itself for which the contract is not in our hands.

If you connect a Google Calendar, the appointments we book are written into your own Google account and travel to Google's global infrastructure, including the United States. That transfer happens under your own agreement with Google and Google's own safeguards - not under safeguards we hold - so it is the one transfer for which we cannot send you a copy. Google states that Google LLC is certified under the EU-US Data Privacy Framework and that it relies on the EU Standard Contractual Clauses where adequacy does not apply. Disconnecting the calendar stops any further data going to Google; it does not remove what is already in your calendar, which stays there under your control.

9. Your rights

Under the GDPR you have the right to:

• access the personal data we hold about you, and receive a copy;
• have inaccurate or incomplete data corrected;
• have your data erased, where the law allows;
• restrict how we use your data, in certain cases;
• receive your data in a portable, machine-readable format;
• withdraw consent at any time, where we rely on consent - without that affecting the lawfulness of any processing we carried out on that consent before you withdrew it.

Your right to object. Where we rely on our legitimate interests, you have the right to object to that processing at any time, on grounds relating to your particular situation. Tell us why it matters in your situation and we will stop, unless we have compelling legitimate grounds that override your interests, rights and freedoms, or we need the data to establish, exercise or defend legal claims.

To exercise any right, contact [email protected]. We respond within one month (extendable by up to two months for complex requests). We do not charge you for this. Only where a request is manifestly unfounded or excessive - in particular because it is repetitive - may we charge a reasonable fee or refuse to act on it, and it is for us to show that a request is of that kind. We may ask you to verify your identity.

If your data relates to a call you made to a business that uses SwiftGuard, that business is the controller for the call - please contact them, and we will help them respond. There is one exception, and it is ours: for our own review of calls to improve the agent, described in section 5, SwiftGuard is the controller. Nobody else can act on that, so for that one purpose email us directly rather than the business.

You can also lodge a complaint with your local data protection supervisory authority. Ours, as a Netherlands business, is the Autoriteit Persoonsgegevens (autoriteitpersoonsgegevens.nl).

10. Automated interactions and AI

Calls are answered by an automated assistant (an AI system), not a person. The agent introduces itself as an automated assistant and tells the caller the call is recorded, at the very start of the call. It books appointments and records call details; it does not make decisions that produce legal effects, or similarly significant effects, about anyone, and we do not identify callers biometrically.

One step is decided automatically. The agent finds a caller's record from the number they are calling from, and then needs proof of who is calling before it will act on that record: either the postcode and house number held on the record, or a one-time code texted to that same number - and before it changes or cancels a booking, the texted code is always required as well (see section 4). A caller who does not pass is not turned away: the agent can still take a message for the business, and the business can be contacted directly in the usual way. What the check decides is whether the agent may act on a stored record over the phone - not anything about the caller themselves.

We do not use your data or your callers' data to train AI models. That is our own conduct, and we control it. Listening to a call to correct and improve how the agent behaves (section 5) is a different thing from training a model on it: we do the first, never the second.

We cannot make that promise on our providers' behalf, so rather than claim it we tell you what we have done and what they themselves say, and you can check both.

Our voice platform, Deepgram, offers customers a way to opt out of having their audio used to improve its models. We set that opt-out on every single call, automatically - it is written into the software, not a setting somebody has to remember, so there is no call it can be forgotten on (see Deepgram's privacy policy). That opt-out covers Deepgram. Where a language is set to an ElevenLabs voice, what reaches ElevenLabs is the text of the agent's own replies rather than the caller's audio - so no call recording goes to it at all. What ElevenLabs may do with that text is governed by its own published terms and by the agreement we are working to put in place with it; until that agreement is signed we would rather point you at ElevenLabs' privacy policy than give you a promise on its behalf. No language is set to an ElevenLabs voice today.

The language model that works out what the caller means is the part we are furthest from, and we will not dress that up. Both Google and OpenAI publish a commitment that data sent to their paid interfaces is not used to train their models (see Google's Gemini API terms and OpenAI's API data policy). But that step is reached on our voice platform's account, not ours, so the agreement that actually binds it is between them and Deepgram - which means we can point you to what those companies say publicly, and we cannot give you our own promise on top of it.

11. Security

We use reasonable technical and organisational measures to protect personal data, including encryption in transit (TLS) and encryption at rest provided by our database and hosting providers, hashed passwords, and logging of security-relevant actions such as sign-ins, role changes and administrative access.

Access to the systems holding personal data is limited to the small number of people who operate the service. We are honest about the shape of that limit today: it rests on who holds the credentials rather than on per-person permissions, and opening a call recording or a transcript is not yet recorded against the individual who opened it.

To run and secure the service we also keep operational logs, which can contain limited personal data such as email and IP addresses and the town an address resolved to; we remove credentials from these logs. They are held only for as long as our hosting platform keeps them in its own rolling window, and we copy them into no database of our own - section 3 sets out the purpose and the legal basis.

Separately from those logs, when something in the software goes wrong in a way somebody has to act on - a provider returns an error, a scheduled job stops, a payment cannot be accounted for - we keep a record of what happened so it can be fixed. We keep those records for 90 days, on the same legitimate interest set out in section 3. They are meant to describe our own systems and not the people using them, and we deliberately keep personal data out of them. We cannot promise that never fails: part of what they contain is the message a third-party provider handed back, and we do not control its wording, so one can occasionally repeat a detail such as a phone number or an address. We treat these records as we treat any other data about you and your callers, and only the people who operate the service can read them.

No method of transmission or storage is completely secure, so we cannot guarantee absolute security. If a personal-data breach affects you, we will notify you and the relevant authorities as required by law. Where a breach affects the caller data we process on your behalf, you are the controller and we are the processor, so the duty runs to you: we tell you without undue delay, within the period set out in our Data Processing Agreement, so that you can meet your own notification duty in time.

12. Children

SwiftGuard is a service for businesses and is not directed to children. We do not knowingly collect personal data from children. If you believe a child has provided data through a call, contact us and we will help arrange its deletion.

13. Changes to this policy

We may update this policy, and we will change the "Last updated" date above when we do. Corrections, clarifications, and anything that does not reduce what you get take effect when we publish them - as do changes we must make to comply with the law or to protect the security of the service. If a change materially reduces what you get, we will tell you first, by email or in your dashboard, at least 15 days before it takes effect (30 days if you are a consumer), and you may end your subscription before then if you do not accept it. That is the same rule section 15 of our Terms of Service sets for the contract this policy forms part of. If you have given us your details without holding an account - a waitlist enquiry, or an invitation you never accepted - there is no dashboard to reach you in and we do not email you about a change, so the version of this page published here is where a change reaches you; you can ask us to delete your details at any time by emailing [email protected]. We keep earlier versions, and we will not apply material changes retroactively without a lawful basis.

14. Contact us

Questions or requests: [email protected] · SwiftGuard AI, Ensahlaan 25, 3723 HT Bilthoven, The Netherlands.