Privacy Policy
Version 1.1 — last updated 11 September 2026 (what changed: §13)
This policy explains what personal data LAVAN LABS LTD handles when you use Coworkkit, why, and what your rights are.
LAVAN LABS LTD · registered in England & Wales, company number 17361107 · registered office 128 City Road, London EC1V 2NX. Contact: privacy@coworkkit.ai.
1. The two groups of people in this policy
Coworkkit is developer infrastructure, so there are two very different groups of people whose data passes through it. Almost everything below depends on which one you are.
If you're our customer — a developer or company with a Coworkkit account — we hold your account, billing and usage data, and we are the data controller for it. Sections 2, 4 and 7 are about you.
If you're an end-user — someone using an application built by one of our customers, who talks to the AI co-worker — you have no account or relationship with us. Your voice and what you say passes through our systems so we can provide the service to the company that built the application. For that data we act as a data processor on that company's instructions, and they are the controller. Section 3 is about you, and section 8 explains where to take a request.
2. Data we hold about our customers
| What | Why | Lawful basis |
|---|---|---|
| Name, email, account credentials | to create and secure your account | performance of a contract |
| Company name, billing country | to bill you and meet tax obligations | contract / legal obligation |
| Payment details | we don't hold these — Paddle does (see section 5) | — |
| Usage records — session counts, minutes, tokens, API calls | to meter usage, bill you, and manage capacity | contract / legitimate interests |
| Support correspondence | to answer you | contract / legitimate interests |
3. Data that passes through when an end-user talks to the co-worker
When someone speaks to a Coworkkit co-worker inside our customer's application, the following flows through our systems:
- Voice audio — captured in the browser and streamed to our speech-recognition service so it can be turned into text.
- The transcript — what was said, and what the co-worker said back.
- Context from the page — information about the screen the user is on, which our customer's application chooses to send.
- Technical session data — connection details, timings and duration, used to run the session and meter it.
- Two placement signals — the end-user's IP address and browser time zone — if our customer's application sends them. Used once to choose the region the session runs in, then discarded. Never stored, never logged (§6).
We process this on our customer's instructions, to provide the service to them. We don't use it to build a profile of the end-user, we don't sell it, we don't use it for advertising, and we do not use it — or permit Google or Deepgram to use it — to train AI models.
Is voice "biometric data"?
No — not as we use it. Under data protection law, voice becomes biometric data only when it's processed specifically to identify a person — a voiceprint. Coworkkit does not do speaker identification. We convert speech to text so the AI can respond, which makes it ordinary personal data rather than a special category.
⚠️ But what someone says is a different matter. A person can mention their health, their beliefs or anything else in the course of a conversation, and that would sit in a transcript. If your application is likely to prompt conversations of that kind, that's a factor in your own data protection assessment as the controller.
4. How long we keep things
We do not record calls. We do not store voice audio, and we do not store transcripts of what is said. This is the most important thing in this policy, so we'll be specific:
- Voice audio is streamed to speech recognition during the live session and is never written to storage. There is no recording, and no audio file is created.
- Transcripts exist only for the moment — shown to the user as live captions, and held in memory so the AI can respond during that one session. They are not written to our database and not written to our logs.
What we do keep:
- Account and organisation records — your email, name, company and role — while your account is open, and afterwards for as long as tax and company law require us to (six years under UK law).
- Usage metadata — minutes used, session timings, lifecycle events, and the region each session ran in. This is metadata only; it contains none of the conversation content. We keep it while your account exists. After your account closes we keep the financial totals for as long as tax and company law require (six years), and remove your end-users' identifiers from those records within 90 days.
- Operational logs — identifiers and timings, never conversation content, never the placement signals. Kept 14 days on AWS (in the session's region) and 30 days on Google Cloud Logging.
Because we hold no audio and no transcripts, there is nothing of your end-users' actual conversations for us to retain, expose in a breach, or be compelled to hand over.
5. Who else processes data for us
We use a small number of service providers. Each is bound to process data only on our instructions, except where the table says otherwise.
| Provider | What they do | Where |
|---|---|---|
| Amazon Web Services (Amazon Web Services EMEA SARL) | runs our servers: the real-time voice transport (our own LiveKit server), the agent process, container hosts and their logs, secrets (Secrets Manager), and our control-plane database (accounts, usage, session records) | Frankfurt (eu-central-1) for European sessions · N. Virginia (us-east-1) for Americas sessions and for the control plane |
| Google Cloud (Google Ireland Ltd) — Speech-to-Text, Text-to-Speech, Vertex AI (Gemini), Cloud Logging, Secret Manager, Firebase Authentication | speech recognition and synthesis, the AI language model, operational logs, secrets, and portal sign-in | speech recognition: Google's EU / US regional endpoints by session region · speech synthesis: Chirp 3 HD voices (the Google defaults) from Google's EU / US multi-region endpoints, which Google keeps outside its data-residency commitments (§6) · language model: Google's global endpoint · sign-in: United States · logs: Google-managed, 30 days |
| Deepgram (Deepgram, Inc.) | speech recognition and synthesis for co-workers using a Deepgram voice | EU endpoint for European sessions · US endpoint for Americas sessions |
| Paddle (Paddle.com) | payments, invoicing and tax, as merchant of record. They hold your payment details; we don't. | UK / EU — see §6 |
| PostHog (PostHog, Inc. — EU Cloud) | product analytics for the portal: your own account's events (sign-up, key created, first call). No end-user or voice data; cookieless | Frankfurt, EU |
| Resend (Plus Five Five, Inc.) | transactional email — sign-in links, billing and low-balance notices | United States |
| Cloudflare Turnstile (Cloudflare, Inc.) | bot protection on our signup form — it sees the visitor's IP address and browser signals; Cloudflare also uses those to improve its own bot detection | global |
The real-time voice transport is the open-source LiveKit server, run by us on the AWS servers above — LiveKit, Inc. processes no session data. For Edge routing we resolve an IP address to a country with the DB-IP IP to Country Lite database (CC BY 4.0, db-ip.com) bundled inside our service; no lookup leaves our servers.
We use PostHog in the portal for account analytics only — server-side, EU-hosted, cookieless, about what you do in your account, never about your end-users or their voice sessions. There is no session-recording, advertising or tracking SDK in the product.
Google acts as our processor under its Cloud Data Processing Addendum, which is automatically part of our agreement with Google. Google commits not to use the data we send it to train its models without our permission, and we give none. Deepgram processes under its data-processing addendum with its model-improvement programme switched off, so nothing we send it is used to train Deepgram's models either.
Which of these providers are sub-processors of your end-users' data and which handle only your account data is set out in our Data Processing Addendum, Annex B, which forms part of the Terms (§9) for every customer. We keep both current and give you 30 days' notice by email before a new sub-processor touches your end-users' data.
6. Where data is processed
Voice sessions run in one of two regions, and you choose how. The regions are Europe (Frankfurt) and the Americas (N. Virginia). Every account has a home region, set at sign-up and changeable in Settings → Account. For each co-worker you pick a placement mode — Best effort (home region; may run in the other region if home is full or down; all plans), Region affinity (the pinned region only; if it's unavailable the session is refused rather than moved; Growth and above), or Edge (the region nearest the end-user, preferring the regions you allow — if none is available the session runs in another of our regions rather than being refused; Growth and above). The region each session ran in is shown in your Sessions tab. The Terms §2 define the modes; this section says what a region does and doesn't cover.
What a region covers: the live audio, the agent process, and speech recognition and synthesis — with one precision on synthesis. Google's Chirp 3 HD voices, which are the default Google voices, are served from Google's EU (for European sessions) or US multi-region endpoint, and Google does not include those endpoints in its data-residency commitments. Deepgram voices are served from Deepgram's EU or US endpoint by region.
What sits outside every region, in every mode — we'd rather say it than have you assume otherwise:
- The AI language model (Google Vertex AI Gemini) is called at Google's global endpoint, which doesn't guarantee a processing location, so the text of a conversation may be processed by Google outside the UK and EEA. Unchanged since launch.
- Our control plane — the database holding your account, usage and billing records and each session's record — runs on AWS in the United States (N. Virginia).
- Sign-in (Firebase Authentication) and transactional email (Resend) keep account data in the United States.
- And, as §4 says, no audio and no transcripts are stored anywhere.
So, plainly: "Region affinity — Europe" keeps your users' audio, the agent and the speech processing in Frankfurt. It is not full EU data residency, and we don't describe it as such.
The two placement signals. For Edge, your application may send us the end-user's IP address and browser time zone when it starts a session. We resolve the IP address to a country on our own servers (§5), map the time zone to a continent, pick the region, and keep neither — they are not stored and not logged; the only trace is the region the session ran in. Whether to send them is your decision as the controller, and the absence of the fields is the opt-out. The Data Processing Addendum, Annex F, sets out what that choice means and what you owe your own users.
International transfers. We are a UK company; for customers in the EEA, data reaching us is covered by the EU's adequacy decision for the UK. Where a step above sends data to the United States — AWS, Google's global endpoint and US endpoints, Deepgram's US endpoint, Firebase, Resend — it is transferred under the provider's certification under the UK–US Data Bridge / EU–US Data Privacy Framework where it holds one (AWS, Google, Resend, Cloudflare and PostHog do; Deepgram does not) and the Standard Contractual Clauses with the UK Addendum in the provider's data-processing terms, which apply on their own if the Framework is ever invalidated. The Addendum's Annex D has the step-by-step table.
Paddle, as merchant of record, processes your billing data under its own data-processing terms, which use adequacy decisions or Standard Contractual Clauses for any transfer outside the UK/EEA.
7. Your rights
If you're our customer, you can ask us to: give you a copy of your data; correct it; delete it; restrict or object to how we use it; or send it to another provider. You can also withdraw consent where we relied on it.
Email privacy@coworkkit.ai. We'll respond within one month.
8. If you're an end-user of an application built with Coworkkit
Your request should go to the company whose application you were using — they decide what data is collected and why, and they're the controller. We'll help them respond, but we can't act on their data without their instruction.
If you're not sure who that is, contact us at privacy@coworkkit.ai and we'll point you in the right direction.
9. Cookies and analytics
We use only strictly necessary cookies — the ones that keep you signed in and make the product work. These don't require consent. Product analytics in the portal (PostHog, §5) is server-side and cookieless, so we set no analytics or advertising cookie and no consent banner is needed.
Our public website at coworkkit.ai has its own separate Website Privacy Notice covering what it does with data. The product itself uses no analytics and sets no tracking cookie.
10. Security
We protect data with encryption in transit over public networks and at rest, access limited to the founder behind multi-factor authentication, and infrastructure managed through code across our two cloud providers (Amazon Web Services and Google Cloud). The full list of measures is Annex C of the Data Processing Addendum.
We'll be straight with you about the limits: we're a young company and we don't hold SOC 2 or ISO 27001. We don't claim certifications we don't have. If you need a security review before buying, ask us and we'll answer honestly.
11. Children
Coworkkit is a business tool and isn't directed at children. If you build with Coworkkit, you're responsible for ensuring your application isn't directed at children under 16, and for any consents required if children could use it.
12. Complaints
If you're unhappy with how we've handled your data, tell us first at privacy@coworkkit.ai — we'd rather fix it.
You can also complain to a data protection authority. In the UK that's the Information Commissioner's Office (ico.org.uk). If you're in the EU or EEA, you can complain to your local supervisory authority.
13. Changes to this policy
We may update this policy. Material changes will be notified by email to account holders at least 30 days in advance, and the version number and date at the top will change.
Version 1.1 (11 September 2026): regions and placement modes (§6); the provider table rewritten (§5 — AWS, Deepgram and PostHog added, Google re-scoped, LiveKit moved out of the table as self-hosted software); the two placement signals (§3, §6); the control plane's move to the United States (§6); and the new Data Processing Addendum. It took effect on publication.
14. Contact
LAVAN LABS LTD · company number 17361107 · 128 City Road, London EC1V 2NX privacy@coworkkit.ai