The failure mode is free text
A chatbot is the only system you will build where the user chooses what data to give you. Forms constrain input. Chat does not.
You can design a support bot intending to handle order status and delivery windows, and it will handle order status and delivery windows. It will also receive, without being asked, the customer explaining that they need to change a delivery because they are in hospital, or that they missed a payment because of a bereavement, or that a name on an account has changed. Under UK GDPR that is special-category data under Article 9, held to a materially higher standard than the order number sitting next to it in the same transcript.
Your terms of service cannot prevent this. A banner asking people not to share sensitive information does not stop them and does not help you afterwards. The only things that work are architectural.
What we design in, before the bot answers a single question
Retention that is short and enforced. A defined lifetime for raw transcripts, applied by a job that actually runs, decided before launch rather than after the first subject access request. Undefined retention is the norm because storage is cheap; it is also how a two-year archive of unredacted customer conversations comes to exist.
Redaction at the boundary. Strip or hash obvious identifiers before a transcript is stored or forwarded to a model provider. This does not catch everything — nothing catches everything in free text — but it substantially reduces what accumulates.
Separate the transcript from the metric. Most of the business value in chat logs is aggregate: which questions recur, where the bot fails, how often a conversation escalates. That value survives de-identification completely. Derive the metrics, keep those, and let the raw text expire.
Know what leaves. Every message sent to a model provider is a transfer. The UK page covers where our processing happens and who the sub-processors are; for a chatbot specifically, the provider’s retention and training-use terms are a scoping decision with a named answer, not a default inherited from whichever SDK was fastest to wire up.
Subject access requests, which are the real test
A UK customer can ask for a copy of their personal data, and you have a month. For most systems that is a database query. For a chatbot it is a question about whether you can find every conversation that person had, across sessions, including the ones where they were not logged in.
If the answer is “we would have to search free text for their name”, the system was not designed for the jurisdiction it operates in. Designing for it means a resolvable link between a person and their transcripts, and — just as importantly — a retention policy short enough that the search space stays small.
The same design makes erasure requests tractable. These two obligations are why the retention decision belongs at the start.
PECR, briefly, because it is not GDPR
The Privacy and Electronic Communications Regulations sit alongside UK GDPR and govern storage and access on a user’s device. A chat widget that sets a session cookie to maintain the conversation is likely covered by the strictly-necessary exemption. One that persists an identifier to recognise returning visitors, or feeds an analytics product, is not, and needs consent obtained the same way your other non-essential cookies do.
This matters mostly because chat widgets are often added by a different team from the one that owns the consent banner, and the two are rarely reconciled. Worth checking what yours writes.
What this changes about the engagement
The scoping conversation starts with retention and redaction rather than with conversation design, and the written plan from discovery states what is stored, for how long, where, and how a subject access request is answered. That document is what your DPO needs and it is the same one that makes the build estimable.
Contracting, currency and hours are as set out on the UK page — quoted and invoiced in USD, contracted under Colorado law, with the working overlap in your afternoon.