← Coworkkit

Data Processing Addendum

Version 1.0 — 11 September 2026. This Addendum forms part of the Coworkkit Terms of Service (§9) between you (the "Customer") and LAVAN LABS LTD, registered in England & Wales, company number 17361107, registered office 128 City Road, London EC1V 2NX ("we", "us"). It applies to every customer whose end-users' personal data we process, on every plan. You accept it by accepting the Terms; a countersigned copy is available on request at privacy@coworkkit.ai.

It is written in plain English on purpose. Where a data-protection law requires a term, the term is here; where it doesn't, we've kept it short.


1. What this covers, and who is who

Customer Personal Data is the personal data of your end-users — the people who use your application and talk to the co-worker — that passes through Coworkkit while we provide the Service to you. Annex A describes it.

You are the controller of Customer Personal Data (or, if you are yourself acting for a client, their processor — in which case you confirm you have the authority to give us these instructions). We are your processor. We process Customer Personal Data only to provide the Service to you, only on your instructions, and never for our own purposes.

Your own account, billing and usage data is different: we are the controller for it, and the Privacy Policy governs it. This Addendum does not.

Data Protection Law means the UK GDPR and the Data Protection Act 2018 and, where it applies to you or your end-users, the EU GDPR. The words controller, processor, personal data, processing, data subject, sub-processor and personal data breach have their meanings under those laws.

2. Your instructions

Your documented instructions to us are:

  • the Terms and this Addendum;
  • how you configure the Service — your home region, each co-worker's placement mode (Best effort, Region affinity or Edge), an Edge allow-list, the voice and language you choose, what page context your application sends, and whether your application sends an end-user's IP address and browser time zone (Annex F explains what that choice does);
  • any further written instruction you give us that is consistent with the Terms.

We will tell you if we think an instruction breaches Data Protection Law. We won't process Customer Personal Data for any other purpose — in particular, we do not use it, and do not permit our sub-processors to use it, to train AI models.

3. Our obligations as your processor

We will:

  1. Process only on your instructions (§2), unless a law we are subject to requires otherwise — in which case we'll tell you first if the law lets us.
  2. Keep it confidential. Everyone we authorise to handle Customer Personal Data is under a duty of confidentiality. Today that is the founder; there are no other staff.
  3. Secure it. We apply the technical and organisational measures in Annex C.
  4. Use sub-processors only as §4 allows.
  5. Help you with your end-users' requests. Because we store no audio and no transcripts, there is very little of an end-user's data to find; what exists is the session record, which you can look up yourself by your own user identifier in the portal, and we'll help within the month if you can't.
  6. Help you meet your own duties — security, breach notification, data protection impact assessments and any consultation with a regulator — so far as the nature of the Service allows and the information is ours to give.
  7. Tell you about a personal data breach affecting Customer Personal Data without undue delay, and in any case within 48 hours of becoming aware of it, with what we know, what we're doing, and a contact. We'll keep updating you as we learn more.
  8. Delete or return Customer Personal Data at the end of the Service, as Annex E sets out.
  9. Show you. We'll give you the information you reasonably need to demonstrate that we meet Article 28, and allow an audit — by you or an auditor you appoint and we don't reasonably object to — once in any twelve months, on 30 days' written notice, during business hours, under reasonable confidentiality and security conditions. If a regulator or a real incident requires more, we'll cooperate.

4. Sub-processors

General authorisation. You authorise us to use the sub-processors in Annex B, and to add or replace sub-processors on the terms below. We remain responsible to you for anything a sub-processor does with Customer Personal Data, and we put each one under written obligations no less protective than this Addendum.

Changes. Before a new sub-processor processes Customer Personal Data we will (a) update Annex B on this page, and (b) email your account address at least 30 days in advance. A change of where an existing sub-processor processes — for example a new region — is announced the same way if it affects Customer Personal Data.

Objection. If you object within those 30 days on reasonable data-protection grounds, we'll work with you on an alternative — usually a configuration change, such as a different voice or region. If we can't resolve it before the change takes effect, you may end the affected part of the Service by written notice and we'll refund your unused purchased minutes pro rata. That is your only remedy for a sub-processor change you object to.

5. International transfers

Where Customer Personal Data is transferred outside the UK or the EEA — by us or by a sub-processor — it is transferred only under a safeguard recognised by Data Protection Law. Annex D says exactly where data goes in each region and mode, and which safeguard applies to each step.

We are a UK company. For customers in the EEA, transfers to us are covered by the European Commission's adequacy decision for the United Kingdom. For transfers from us to the United States we rely on each sub-processor's certification under the UK–US Data Bridge (the UK extension to the EU–US Data Privacy Framework) where it holds one, and, in every case, on the Standard Contractual Clauses and UK Addendum (or International Data Transfer Agreement) in that sub-processor's data-processing terms. If the Data Privacy Framework or the Data Bridge ceases to be valid, those clauses continue to apply on their own, without any action by either of us.

6. The regions, in one paragraph

Voice sessions run in the region the Service chooses under your placement mode (Terms §2). A region covers the live audio, the agent process and speech processing — with one precision on synthesis: Google's Chirp 3 HD voices (the default Google voices) are served from Google's EU or US multi-region endpoint, which Google does not include in its data-residency commitments; Deepgram voices are served from Deepgram's EU or US endpoint by region. Edge prefers the regions you allow but, if none is available, uses another of our regions rather than refusing; only Region affinity refuses. A region does not cover two things, in any mode: the language-model step, which runs on Google's global infrastructure, and the session record and your account data, which live in our control plane in the United States. Region affinity therefore means a regional guarantee for the voice pipeline, not full data residency, and this Addendum does not promise more. Annex D has the table.

7. Liability, term, precedence

Liability under this Addendum is subject to the limits in the Terms (§13). This Addendum lasts as long as we process Customer Personal Data for you and for the deletion period in Annex E. If this Addendum conflicts with the Terms, this Addendum prevails for Customer Personal Data. We may update it as the Terms allow (§16 — material changes on 30 days' email notice).


Annex A — What we process

Subject matterProviding a voice AI co-worker inside the Customer's application: real-time speech recognition, a language-model conversation loop, speech synthesis and the actions the Customer exposes to it.
DurationFor each session, the live session only. For the session record, while the Customer's account exists and then per Annex E.
Nature and purposeStreaming and converting the end-user's speech to text, generating a reply, synthesising it to speech, and — where the Customer allows — carrying out actions in the Customer's application as the signed-in user. Processing is automated and real-time.
Categories of dataVoice audio (in transit only — never stored). Transcript text of what was said and replied (in memory for the session only — never stored). Page context the Customer's application chooses to send. The Customer's own identifier for the end-user. Placement signals — the end-user's IP address and browser time zone, if the Customer's application sends them — used for one lookup and discarded. Session metadata — start and end time, end reason, region served, latency figures.
Special categoriesNone by design. An end-user may say something sensitive; the Customer, as controller, assesses that risk for its own use case. We do no speaker identification, so voice is not biometric data as we process it.
Data subjectsThe Customer's end-users — the people who use the Customer's application.
FrequencyContinuous, per session, at the Customer's and its end-users' initiative.

Annex B — Sub-processors

Sub-processors of Customer Personal Data (the end-user data this Addendum covers). Data-processing terms is the document that binds each of them to us.

Sub-processorContracting entityWhat they process for usWhereData-processing terms
Amazon Web ServicesAmazon Web Services EMEA SARL (Luxembourg)Our own servers: the real-time voice transport (our self-hosted LiveKit server), the agent process, container hosts and their logs (CloudWatch, 14 days, in the session's region), AWS Secrets Manager, and the control-plane database (session records)Europe — eu-central-1 (Frankfurt) for European sessions · United States — us-east-1 (N. Virginia) for Americas sessions and for the control plane, all modesAWS Data Processing Addendum (auto-incorporated) + UK GDPR addendum · sub-processors
Google CloudGoogle Ireland LimitedSpeech-to-Text and Text-to-Speech; Vertex AI (Gemini) — the language model; Cloud Logging — operational logs (identifiers and timings, no content); Secret ManagerSpeech-to-Text: Google's EU / US regional endpoints by session region · Text-to-Speech: Chirp 3 HD voices (the Google defaults) from Google's EU / US multi-region endpoints, which Google excludes from its data-residency commitments · Language model: global · Logging: Google-managed, 30-day retention · Secret ManagerCloud Data Processing Addendum (auto-incorporated) · sub-processors
DeepgramDeepgram, Inc. (United States)Speech-to-Text and Text-to-Speech, only for co-workers using a Deepgram voiceEU endpoint (api.eu.deepgram.com) for European sessions · US endpoint for Americas sessionsDeepgram's data-processing addendum (provided on request by Deepgram; incorporates the EU Standard Contractual Clauses) · sub-processors

Not on this list, on purpose: the real-time voice transport is the open-source LiveKit server run by us on the AWS servers above — LiveKit, Inc. does not process any session data. Country lookup for Edge uses the DB-IP IP to Country Lite database (CC BY 4.0) bundled inside our service — no external lookup is made.

Processors of your account data (you and your team, not your end-users — we are the controller, and the Privacy Policy §5 governs): Google (Firebase Authentication, United States), PostHog (product analytics, EU Cloud, Frankfurt), Resend (transactional email, United States), Cloudflare (Turnstile bot check at signup, global). Paddle is the merchant of record and an independent controller of your billing data.

Annex C — Security measures

  • We store no audio and no transcripts, in any region. Audio is streamed to speech recognition and never written to disk; transcripts live in memory for the session. This is the measure that matters most.
  • Encryption in transit on every path over the public internet: TLS for API calls, WSS for the SDK connection, DTLS-SRTP for the WebRTC audio. Inside our private cloud network, traffic is isolated by network policy.
  • Encryption at rest on the control-plane database and container storage, using the cloud provider's managed keys.
  • Access control. Cloud consoles and production access are limited to the founder, behind multi-factor authentication; every customer has its own API keys, revocable in the portal.
  • Secrets live in the cloud providers' secret managers (Google Secret Manager, AWS Secrets Manager), never in the codebase.
  • Infrastructure as code for both clouds, so every change is reviewed and reproducible.
  • Isolation by region and tenant: each region is an independent cell; a failing cell is fenced off automatically.
  • Logging without content: operational logs hold identifiers and timings, never conversation content. The agent's system prompt is written to logs only when a debug flag is on, and it is off in production.
  • What we don't have, said plainly: no SOC 2 or ISO 27001 certification. We're a young company; ask us and we'll answer a security questionnaire honestly.

Annex D — Where data goes, and under which safeguard

By region and mode (the voice pipeline = live audio, agent process, speech-to-text / text-to-speech):

Voice pipelineLanguage modelSession record + account data
European session (eu1)Frankfurt (AWS) + Google/Deepgram EU endpoints, voice permitting (Annex B)Google, globalUnited States (AWS us-east-1)
Americas session (us1)N. Virginia (AWS) + Google/Deepgram US endpointsGoogle, globalUnited States
Best efforthome region; may overflow to the otherglobalUnited States
Region affinitypinned region only, or the session is refusedglobalUnited States
Edgenearest region, preferring the Customer's allow-list; another region rather than a refusal if none is availableglobalUnited States

Safeguards:

StepTransferSafeguard
Customer (EEA) → us (UK)EEA → UKEuropean Commission adequacy decision for the UK (renewed 19 December 2025)
Customer (UK) → usnone—
Us → AWS us-east-1 (control plane, Americas sessions)UK → USAWS is certified under the EU–US Data Privacy Framework and UK Extension; AWS DPA incorporates the EU SCCs and the UK Addendum
Us → Google (global language model; US speech endpoints; non-regional voices)UK → US / unspecifiedGoogle LLC is certified under the DPF and UK Extension; the Cloud Data Processing Addendum incorporates the EU SCCs, applied to UK law
Us → Deepgram US endpointUK → USEU Standard Contractual Clauses (and UK Addendum) in Deepgram's data-processing addendum. Deepgram is not DPF-certified.
Us → Deepgram EU endpoint / Google EU endpoints / AWS FrankfurtUK → EEAUK adequacy regulations for the EEA

If the Data Privacy Framework or the UK–US Data Bridge is invalidated, the contractual clauses in the row continue to apply (§5).

Annex E — Deletion and return

  • During the Service there is nothing to return for audio or transcripts: we never hold them.
  • Session records (Annex A metadata, including your end-user identifier) can be exported on request while your account is open.
  • When your account ends, or on your written request, we remove your end-users' identifiers from the session and usage records within 90 days. The records themselves stay for as long as tax and company law require (six years) as financial records — totals, timings and regions, with no end-user identifier in them.
  • Deletion at our sub-processors follows their own deletion terms (linked in Annex B); none of them retains audio or transcripts on our instruction.

Annex F — Your instructions on placement (and the opt-out that costs nothing)

  • What the two signals are for. If your application sends the end-user's IP address and/or browser time zone when it asks us to start a session, we use them only to choose the nearest region under Edge. The IP address is resolved to a country on our own servers with a bundled database; the time zone is mapped by prefix to a continent. The IP address takes precedence when both are present. Neither is stored or logged — the only trace is the region the session ran in.
  • Sending them is your choice, and your instruction. Our server helper forwards the client IP by default and can be switched off (forwardClientIp: false); your token route can omit either field for your whole deployment or for an individual end-user. The absence of the fields is the opt-out — we never receive a "declined" flag and never interact with your end-users. Without the signals a session runs in your home region (Best effort) or your pinned region (Region affinity).
  • Your responsibilities for them. As controller, you decide the lawful basis for reading and forwarding the signals and give any notice or obtain any consent your end-users need — including under the UK Privacy and Electronic Communications Regulations, where reading a value from the end-user's browser (the time zone) may require consent unless it is strictly necessary for the service the user asked for. If you need a paragraph for your own privacy notice, our integration documentation has a paste-ready one.
  • What each mode instructs us to do is in §6 and Annex D. Choosing a mode, a home region or an allow-list in the portal is a written instruction under this Addendum.

LAVAN LABS LTD · Registered in England & Wales, company number 17361107 · 128 City Road, London EC1V 2NX · Last updated 15 September 2026

Related

  • Terms of Service
  • Privacy Policy
  • Refund Policy
  • Support
  • Website Privacy Notice
Terms of ServicePrivacy PolicyData Processing AddendumRefund PolicySupportWebsite Privacy NoticePricingCompareAboutChangelogSecurity

© 2026 Coworkkit · coworkkit.ai

Coworkkit is a product of LAVAN LABS LTD, a company registered in England & Wales, company number 17361107.

Registered office: 128 City Road, London EC1V 2NX.

Contact: hello@coworkkit.ai