Privacy Policy

Version: v1.4 — 2026-09-28 Effective date: 2026-10-28

This Privacy Policy explains how Vestibo ("Vestibo", "we", "us", "our") collects, uses, and shares personal information when you (a) visit our website at https://vestibo.com, (b) use the Vestibo dashboard as a customer, (c) interact with an AI agent built on the Vestibo platform as an end-user, or (d) communicate with us. It is written to satisfy our obligations under the EU GDPR, the UK GDPR, the Swiss FADP, the California Consumer Privacy Act ("CCPA") as amended by the CPRA, Canada's PIPEDA, and Australia's Privacy Act. Counsel must localise the language for every jurisdiction where the Service is offered.

If you are an end-user interacting with an AI agent built on Vestibo on behalf of one of our customers, the customer is the data controller for that interaction. Refer to that customer's privacy notice. We act as a processor on the customer's behalf — see the Data Processing Addendum.

1. Who we are

Vestibo is based in the United States and its infrastructure runs in the United States. Our full registered company details and postal address are available on request at legal@vestibo.com. For privacy questions, contact:

• Privacy / data subject requests: privacy@vestibo.com
• EU / UK representative (Art. 27 GDPR / UK GDPR): not currently appointed. We do not target the Service to individuals in the EEA or the UK; if and when Art. 27 applies to us, we will appoint representatives and update this notice.
• Data Protection Officer: not appointed — our processing does not meet the Art. 37 GDPR thresholds that require one. Privacy questions go to privacy@vestibo.com.

2. What we collect, why, and on what legal basis

2.1 If you are a website visitor

2.2 If you are a customer (account holder)

2.2.1 Why the audit log outlives your account

Deleting your account erases the records the identifiers in this log point at, so what remains are opaque identifiers that no longer identify anyone. The log entries themselves are kept, for two reasons we would rather state plainly than bury:

• We cannot edit them. The log is hash-chained and the database refuses changes to it, which is the property that makes it worth anything as evidence. A log we could rewrite on request is a log an attacker could rewrite too.
• We keep them to meet audit obligations. Where we act as a Business Associate, documentation required by the HIPAA Security Rule must be kept for six years. We hold this log for seven years — deliberately above that benchmark, because a record destroyed early cannot be recovered, and the same period covers our other long-lived compliance records.

This is an exception to erasure that the GDPR expressly contemplates — Art. 17(3)(b) and (e), retention for a legal obligation and for establishing or defending legal claims — bounded by a defined period rather than kept indefinitely. It is not a general exception: everything else in the table above is erased on the schedule stated there. If you believe a specific entry should not be retained, contact us and we will review it.

2.3 If you are an end-user reaching an agent built on Vestibo

For end-users (people who text, call, or email an agent built on Vestibo by one of our customers), the customer is the data controller, and Vestibo processes the data on the customer's behalf under the DPA. Categories we may process on the customer's behalf include:

• Identity: name, phone number, email address, postal address (where the caller provides it).
• Conversation content: transcripts of the call/text/email/chat, voicemail recordings (where a caller leaves a voicemail — full live call audio is not recorded by default, so the stored record of a live call is its text transcript), and the structured fields the agent extracts (appointment time, reason for contact, etc.).
• Health information ("PHI"): only if the customer is on the HIPAA-eligible tier and has signed a BAA with us. Otherwise you must not transmit PHI to the agent.
• Sensitive special-category data (Art. 9 GDPR): we do not intentionally process it unless the customer has lawful basis and has configured the agent to handle it (e.g. a healthcare customer with a BAA).

2.4 Cookies and tracking technologies

See the dedicated Cookie Policy. In short: we set no analytics or advertising cookies, we use no third-party analytics SDK, and our own website measurement (the "Website measurement" row in § 2.1) stores nothing on your device at all.

2.5 We do not knowingly collect data about children under 16

If you are under sixteen (16), please do not use the Service. If we become aware that we have collected personal information from a child under sixteen without verifiable parental consent, we will delete it.

3. How we use personal information

We use personal information to:

• provide, secure, and improve the Service;
• authenticate accounts (including via magic link and TOTP);
• communicate with you about your account (transactional);
• send marketing communications to customers who have opted in (you can unsubscribe at any time via the link in every marketing email);
• bill you for paid plans and recover unpaid invoices;
• detect, investigate, and prevent fraud, security incidents, and abuse;
• comply with legal obligations (tax, accounting, lawful requests);
• produce aggregated, de-identified usage statistics for our own product analytics.

We do not:

• sell personal information (and have not in the prior twelve months) within the meaning of CCPA / CPRA;
• share personal information for cross-context behavioural advertising;
• use Customer Data, conversation transcripts, or end-user voice recordings to train any third-party foundation model.

Our default model provider is DeepSeek. We also use OpenAI's hosted embeddings for semantic knowledge search: knowledge-base text, and, for agents whose knowledge base is too large to include in full, the end user's message text used as the search query, are sent to OpenAI to be turned into search vectors, which we store in our own database. Anthropic, Deepgram and ElevenLabs are used only where a tenant or deployment enables them. What each provider receives, where it processes it, and the agreements in place (including where none is) are listed in SUBPROCESSORS.md.

4. Who we share data with

We share personal information only with:

• Sub-processors — the third-party service providers listed in SUBPROCESSORS.md, each under a written contract that satisfies Art. 28 GDPR / SCC obligations and prohibits use of the data outside the Service.
• Our customers — when you interact with an agent built on Vestibo, we share the conversation with the customer that configured the agent. That customer is the controller of that conversation under their privacy notice.
• Authorities — where required by law (subpoena, warrant, court order). We challenge over-broad requests where possible and aim to publish an annual transparency report.
• Acquirers — in a merger, acquisition, financing, or asset sale, personal information may be transferred to the acquirer subject to this Privacy Policy (or a more protective successor). We will notify customers and end-user controllers in advance.

We do not share personal information with data brokers, advertisers, or any third party for targeted advertising.

5. International transfers

We are headquartered in the United States. Our primary infrastructure runs in us-east-1. Where personal data of EU/EEA, UK, or Swiss residents is transferred to a country that has not been deemed by the European Commission to provide an adequate level of protection, we rely on:

• the EU Standard Contractual Clauses (Module 2 — Controller to Processor) as adopted in Commission Implementing Decision (EU) 2021/914 of 4 June 2021;
• the UK International Data Transfer Addendum issued by the ICO on 21 March 2022, where the transfer is from the UK;
• the Swiss FDPIC's addendum to the SCCs, where the transfer is from Switzerland.

We maintain a Transfer Impact Assessment (TIA) process for onward transfers to US-based sub-processors under the Schrems II framework, and make our current assessment available to customers on request.

EU/UK customers can also rely on the EU-US Data Privacy Framework ("DPF") or its UK extension where the sub-processor is DPF-certified; the Sub-processors list flags this for each.

6. Security

We implement administrative, technical, and physical safeguards designed to protect personal information against unauthorised access, disclosure, alteration, and destruction. These are described in the public Security Overview. No method of electronic transmission or storage is one-hundred-percent secure; we cannot guarantee absolute security.

In the event of a personal data breach affecting personal data processed on a customer's behalf, we notify the customer without undue delay and in any event within forty-eight (48) hours of becoming aware, in accordance with Art. 33 GDPR and the DPA.

7. Retention

We retain personal information only as long as needed to provide the Service and meet the legal, accounting, and reporting obligations in § 2 above. See the Retention column there for the relevant period.

After the retention period:

• account data is deleted within thirty (30) days of account closure;
• the data is purged from rolling backups within ninety (90) days;
• aggregated, de-identified statistics may be retained indefinitely for internal analytics.

Customers can request earlier deletion under § 8 (Your rights).

8. Your rights

Depending on where you live, you have some or all of the following rights regarding the personal information we hold about you:

• Access — receive a copy of the personal information we hold about you.
• Rectification — correct inaccurate personal information.
• Erasure ("right to be forgotten") — request deletion, subject to legal exceptions. We hold exactly one such exception and would rather name it than leave you to discover it: the security and audit log described in §2.2.1, which we cannot edit and are required to retain. Everything else is erased.
• Restriction — restrict our processing pending verification.
• Portability — receive your data in a structured, commonly used machine-readable format.
• Objection — object to processing based on legitimate interests, including profiling and direct marketing.
• Withdraw consent — where processing is based on consent, at any time without affecting prior lawful processing.
• Not be subject to a decision based solely on automated processing — we do not make legally significant or similarly significant decisions about you solely by automated means.
• Lodge a complaint with your local supervisory authority (in the EU/EEA), the ICO (UK), the FDPIC (Switzerland), the OPC (Canada), the OAIC (Australia), or the California Privacy Protection Agency (CPPA).

California residents have additional rights under the CCPA / CPRA (right to know, right to delete, right to correct, right to opt out of sale or sharing — N/A as we do not sell or share for behavioural advertising — right to limit use of sensitive personal information, and the right to non-discrimination for exercising these rights).

To exercise any right, email privacy@vestibo.com or use the dashboard's privacy centre. We respond within thirty (30) days of verifying your identity (extendable to sixty (60) days for complex requests, with notice).

If you are an end-user reaching a Vestibo-powered agent, please contact the relevant customer first; we will forward your request to them as a processor.

9. Marketing

We send marketing emails only to customers who have opted in. Every marketing email contains an unsubscribe link. We do not send marketing SMS or calls. The transactional emails our customers' agents send through the Service are governed by the customer's relationship with the recipient, not by this Privacy Policy.

9.1 Mobile information and text messaging

Mobile information and SMS opt-in data and consent are not shared or sold to third parties, affiliates, or lead generators for marketing or promotional purposes.

A phone number collected for text messaging — whether by us, or by a customer's agent acting on that customer's behalf — is used only to send the messages the recipient agreed to receive. It is disclosed only to the communications sub-processors that carry those messages (see SUBPROCESSORS.md), and it is never passed to an advertising network, a data broker, or a lead-generation service.

Recipients can stop messages at any time by replying STOP, and can ask for help by replying HELP. Message and data rates may apply. Message frequency varies, because messages follow something the recipient did — making a booking, changing it, or having one coming up — rather than a schedule we set.

10. Children

The Service is not directed to children under sixteen (16). See § 2.5.

11. Changes to this Policy

We may update this Privacy Policy from time to time. We will post the updated version with a new "Effective date" and, for material changes, notify customers by email and an in-product banner at least thirty (30) days before the change takes effect.

An update that only corrects or completes the description of processing that already occurs — one that changes none of our actual practices and reduces none of your rights — may take effect when posted; where such a correction is material, we still notify customers, concurrently rather than in advance.

12. How to contact us

Postal address: available on request at legal@vestibo.com.

Changelog

• v1.4 (published 2026-09-28, effective 2026-10-28) — § 3 now names DeepSeek as the default model provider (the v1.3 text still said Anthropic, which has not been the default since July 2026) and states that OpenAI's hosted embeddings process knowledge-base text, and the end user's message text for agents with large knowledge bases, for semantic knowledge search. The embeddings use adds a practice, so this version takes effect 30 days after publication, as § 11 requires; it matches Sub-processors v1.2 and later.

• v1.3 (published and effective 2026-09-13) — § 2.1 gains a "Website measurement" row for the first-party, cookieless measurement now running on the public site: page path, referring domain, timezone-derived country, device type and utm_ tags, kept 400 days. It stores nothing on a visitor's device and stores no IP address — the visitor count comes from an irreversible code whose key is regenerated daily, so it cannot be reversed or linked across days. § 2.4 now summarises that rather than only pointing at the Cookie Policy. This adds a practice (previously the public site was not measured at all beyond ordinary server logs), which is why it ships with a version bump rather than as a clarification. No consent banner is required because no device storage is involved. See Cookie Policy v1.1.

• v1.2 (published and effective 2026-08-24) — adds §9.1, stating in terms that mobile information and SMS opt-in data are never shared or sold for marketing, and setting out the STOP/HELP, rates and frequency disclosures for text messages. This changes no practice: we have never sold or shared a recipient's phone number, and STOP has been honoured since the messaging channel shipped. What the old §9 said about texting was "we do not send marketing SMS" — true, and an answer to a different question than the one a recipient (or a mobile carrier reviewing our messaging programme) is actually asking, which is what happens to their number. Under §11 a release that only completes the description of existing processing takes effect when posted; it is not material, because no reader's position changes.

• v1.1 (published and effective 2026-08-18) — releases the two changes that had been sitting UNRELEASED, and treats the pair as material.

  1. Security and audit records added to the §2.2 retention table, with a new §2.2.1 on why that log outlives account deletion and a pointer to it from the Erasure right in §8. This category was not disclosed at all before, and its seven-year retention is longer than every other row except Billing. The ledger itself is not new — it has existed since V9 and survives erasure by design (server/models/audit_event.py: "the audit trail must outlive a tenant purge") — but "we already did this" goes to materiality, not to whether the omission mattered. A reader of the old table would reasonably have concluded erasure removed everything. That is why this release is recorded as material and notified, rather than folded in quietly.
  2. Sign-in artifacts row (one-time OAuth handoff codes, magic-link and password-reset nonces, signup verification PINs), drafted 2026-08-09. Non-material on its own — no new collection, retention of minutes, shorter than every category already listed — but it ships in this release rather than waiting for another one. Prompted by PR #263, which found these records were previously deleted only by new sign-in traffic and so could outlive an account indefinitely.

  Why effective on publication. §11's thirty-day notice exists so customers can act before a change in practice takes effect. This release changes no practice: the audit ledger, its seven-year retention, and its survival of account deletion all predate v1.0 — v1.1 discloses them, it does not introduce them. Delaying the disclosure would only have kept the less accurate description in force for another thirty days: existing accounts are in exactly the position they were already in, and new readers see the complete table before they sign up. Accounts existing at publication are notified by email concurrently with it. §11 also gains a sentence distinguishing corrections of the description from changes of practice; this release's timing rests on the reasoning above, not on that new sentence. (Security Overview v1.1, released the same day, takes effect immediately on the same reasoning.)

• v1.0 (2026-07-23) — first published version; rebranded to Vestibo and reconciled to the current product.

• v0.1 (2026-05-16) — initial internal draft.