Last updated 2026-08-09 - version 1.0

Data processing agreement

This agreement applies to the personal data we process on a customer's behalf when their bot talks to their visitors. It forms part of the terms of service, and it takes effect for every customer without anything to sign.

Roles

The customer is the controller of the conversation data their bot collects. We are their processor. For the customer's own account data we are the controller, and the privacy policy covers that instead.

Subject matter and duration

Subject matter: operating a question-answering bot on the customer's site, recording the resulting conversations, detecting the states that open a case, and delivering those cases where the customer has routed them. Duration: as long as the customer's account exists, plus whatever retention period they have configured for the data itself.

Data and data subjects

• Data subjects: visitors to the customer's site who use the bot, and the customer's own staff who use the account.
• Categories: conversation content; contact details a visitor deliberately provides; personal details appearing inside conversation text, which are tagged at capture and masked by default; technical data needed to run and rate-limit the conversation.
• Special categories: not requested and not required. A visitor can of course type anything into a chat box, which is why transcript retention is the customer's to set and deletion reaches the derived data.

Instructions

We process this data only on the customer's documented instructions - which, in practice, means the settings in their account plus this agreement. We do not build models and we do not use conversation data for our own purposes; what the providers in Annex A do with what they receive is governed by their own terms, which is why the annex lists every one of them rather than making a claim on their behalf. If an instruction looks to us like it breaks the law, we will say so rather than quietly follow it.

Confidentiality

Everyone with access is bound to confidentiality. Access is limited to the people who need it to run and support the service, and actions that reveal a masked personal detail are recorded.

Security measures

• Workspace isolation enforced by the database on every query, not by application convention, and applying to our own maintenance roles too.
• Transport encryption for everything in and out.
• Widgets answer only on domains their owner has verified.
• Passwords hashed with current parameters; sessions bounded by both idle and absolute limits.
• The browser code that runs on a customer's site is public and auditable.
• Retention schedules, per-visitor deletion that follows the provenance chain, and workspace export and deletion, all available to the customer without asking us.

Sub-processors

The customer authorises the sub-processors listed in Annex A. We stay responsible for what they do. The annex is dated and versioned on its own cadence, separately from the rest of this page, because it moves more often; the contact page has the route for subscribing to changes to it, and we will announce a new sub-processor there before it starts processing.

One characteristic of this service is worth stating plainly rather than burying: answers are produced through an aggregation service that selects a model provider per request. So the honest form of the list is the full set of providers an answer might reach, not one name.

Assistance and incidents

We help the customer answer data subject requests - access, correction, deletion and export are largely self-service inside the account area, and we assist where they are not. If we become aware of a personal data breach affecting a customer's data, we tell them without undue delay and with what we know at the time rather than waiting for a complete picture.

Return and deletion

The customer can export their whole workspace at any time and can delete it themselves. On deletion the data goes, including the derived artifacts - embeddings, summaries, analytics rows and audit arguments - with the exception of billing records, which survive with any attribution to a person stripped out.

Audit

We make available the information needed to demonstrate compliance with this agreement and will answer a reasonable audit request in writing. We are a small operation and do not pretend to hold certifications we have not been through.

Transfers

Some sub-processors in Annex A operate outside the EU, and the annex says where each one is. Transfers rest on the appropriate safeguards, including standard contractual clauses where they apply. Regional pinning - keeping data and inference on a route confined to one region - is being built and is not in force today; no part of this document claims otherwise, and the claim will not appear anywhere until the route is running and verified end to end.

Annex A: sub-processors

Annex updated 2026-08-09 - version 1.0

Model providers are reached through the aggregation service above, which selects one per request. A change to the set of models we route to can change which of these an answer reaches, which is why the whole set is listed rather than the current pick.

Version history