1. What this is and how it takes effect

1.1 This Addendum describes the processing carried out by the support agent: the part of the Services that reads conversations on the Customer's helpdesk and writes replies to End Users. It adds to the DPA and replaces nothing in it.

1.2 It takes effect for an organisation in the Customer's account when an administrator of that organisation confirms it in the Services, in Settings. Where the account carries no organisation, the account owner confirms it and is the administrator for the purposes of this Addendum. Until a confirmation is on record, the capabilities in Section 3 do not run and no model call is made for them.

1.3 The confirmation is the Customer's documented instruction under Section 4 of the DPA and Article 28(3)(a) GDPR for the processing described here.

1.4 We record each confirmation, and we keep the record rather than the checkbox:

• What – the version of this Addendum and the hash of its text as published at that moment, together with the settings being confirmed: which brands the agent is switched on for, the retention period in force, and the state of the switches in Section 2.
• When – the time on our servers.
• Who – the person's user identifier, their name and e-mail address as held at that moment, their role in the organisation, the IP address the confirmation was sent from, and their browser's user agent.

1.5 Withdrawal, and every later change to the settings this Addendum governs, is written as a new record of the same kind. Records are added, never altered or removed, and administrators can read the history in the Services.

1.6 Confirmation is the organisation's act and covers the organisation. Each brand is then switched on separately by an administrator, and a brand cannot run the agent while no confirmation is on record.

2. What runs without this Addendum

Two features of the helpdesk send message text to a model without this Addendum. Neither answers an End User. Tone keeps only the resulting label on the conversation, never the text; a suggestion is kept only where Section 3(4) applies. An administrator can switch each of them off for the organisation, in the same place, at any time:

• Tone of incoming messages. Each message that arrives is classified as positive, neutral or negative so that the desk can see it. On by default.
• Suggest a reply. A person on the desk asks for a draft and receives one to read and edit. Nothing is sent to the End User. The draft is not stored, unless a confirmation is on record and the agent is switched on for the brand, in which case it is kept as a run record under Section 3(4). On by default.

The measures in Section 4 apply to both, and to everything in Section 3.

3. The processing this Addendum covers

Once a confirmation is on record, the following processing is permitted, as these capabilities become available in the Customer's account and to the extent an administrator switches them on:

1. Drafting a reply. For each message that arrives on a brand the agent is switched on for, a reply is drafted and placed in the conversation for a person to approve, edit or discard. Nothing reaches the End User without that person.
2. Answering on its own. Within the limits an administrator sets, the agent sends a reply itself. Section 4.4 and the Services' own escalation rules apply at every level.
3. Reading the Customer's own material. Documents and pages the Customer provides are read so that answers are grounded in that material rather than in the model's general knowledge. The material also includes training material: screen recordings and screenshots a member of the Customer's team provides in order to show the agent how a procedure is carried out. A recording or a screenshot is read by a model so that the procedure it shows can be written down in words. What is written down is a draft: a person on the Customer's team reads it, corrects it and approves it, and nothing derived from training material counts for anything until they have.
4. Comparing drafts with what was sent. What the agent drafted is compared with the reply the person actually sent, so the Customer can measure how far the agent agrees with its own desk.
5. Deriving reusable knowledge. How a person on the Customer's desk answered a question is kept, with identifiers replaced as Section 4 provides, for that Customer's own desk. It is shown to a person as a proposal, and may inform a reply a person reviews, marked as unconfirmed. It becomes knowledge only when a person confirms it, and is never used in a reply the agent sends on its own.
6. Importing past conversations. Where the Customer hands over an export of conversations that took place outside the Services – a mailbox, a chat system, a list of tickets – it is read once, with identifiers replaced as Section 4 provides, to derive proposals of the kind described in item 5 and the topics the Customer's End Users write about. An imported conversation is not added to the helpdesk, is never used to contact anyone, and nothing derived from it becomes knowledge until a person confirms it. The export itself is deleted once it has been read, and no later than 30 days after it was handed over. The Customer decides which conversations to hand over and remains responsible, as controller, for its right to do so. Item 6 was added in version 1.1 and runs only for an organisation that has confirmed version 1.1 or later.

A capability that is not yet available in the Services does not run because it is listed here.

4. Data minimisation before a model reads text

4.1 Before conversation text is sent to a model, identifiers are replaced with placeholders by automated means. Two kinds are replaced: the values we already hold for the person the conversation is with – their name, e-mail address, telephone number and customer number – and values in the text that match common identifier patterns: e-mail addresses, telephone numbers, bank account and payment card numbers, national identification numbers, and document numbers.

4.2 The map between a placeholder and its value stays on our servers and is not sent to any model provider. Where a reply comes back carrying a placeholder, the value is put back on our servers before the reply is shown to a person or sent to an End User. The knowledge described in Section 3(5) is derived from the replaced text only.

4.3 This is automated and, for free text, best effort. An identifier written in an unusual format, or a third party's name typed into a message, may not be recognised. The content of messages is itself processed and does reach a model; this Addendum does not claim that the processing is anonymous or that no personal data is involved. The measure reduces what leaves; it does not remove the processing.

4.4 Messages that match our regulated-topics rules – self-exclusion requests, indications of harm including gambling-related harm, chargebacks, and threats of legal action – are not sent to a model at all by the features in Sections 2 and 3, at any setting. They are routed to a person.

4.5 The replacement described in 4.1 cannot be applied to training material, and we say so rather than imply otherwise. What is on screen in a recording or a screenshot cannot have identifiers replaced: a picture is read as it is. The Customer's team is therefore asked to record the procedure with a test customer, and confirms, before anything is uploaded, that the material shows no real End User's data. Spoken narration is written down from the recording and the identifier patterns in it are replaced as 4.1 provides before those words are read.

5. Model providers, training and separation

5.1 The text described in Sections 2 and 3 reaches model providers through the same arrangement as the rest of the Services. Those providers, and the basis on which they are listed, are set out in Annex III of the DPA. This Addendum adds no provider and changes nothing about how they are engaged; what changes is the material they receive, which here is the text of conversations on the Customer's helpdesk with identifiers replaced as Section 4 provides and, where the Customer's team teaches a procedure under Section 3(3), the still frames cut from that recording or the screenshots themselves, read as they are (Section 4.5), together with the narration with identifier patterns replaced.

5.2 No Customer Personal Data, and nothing generated from it, is used to train, fine-tune or improve models, ours or any third party's, as Section 4 of the DPA requires.

5.3 Nothing is shared between organisations. Documents, derived knowledge, drafts and run records belong to the organisation whose desk produced them, are never read to answer another customer's End Users, and are never combined across customers.

6. What is stored and for how long

6.1 Drafts and run records – what was drafted, what the agent decided and why, what the person sent instead, and how far the two agreed – are kept for 24 months by default. An administrator can set a different period, between one and 120 months, in the same place as the confirmation. Shortening the period deletes what falls outside it at the next scheduled purge. The period in force at the time forms part of every confirmation record.

6.2 Knowledge items derived under Section 3(5), and the material the Customer provides under Section 3(3), are kept until the Customer retires or deletes them. They are not run records and the period in Section 6.1 does not apply to them. What is kept of a colleague's answer under Section 3(5) before a person confirms it is removed when the conversation it came from is deleted, and when an administrator deletes what the agent has learned. Training material under Section 3(3) is an exception to the first sentence: the recording or the screenshots as they were uploaded are deleted when the person reviewing them approves or discards what was learned from them. What remains is the frames the reviewer chose to keep and the procedure that was written down with its versions, and those are kept until the Customer retires or deletes them.

6.3 Confirmation records are kept for the term of the Agreement and afterwards for as long as they are needed as evidence of the instruction they record.

6.4 Section 11 of the DPA applies on termination to everything in this Section.

7. Withdrawal, switching off and deletion

7.1 An administrator can withdraw the confirmation at any time, where it was given. Withdrawal stops the processing in Section 3 immediately and switches the agent off for every brand in the organisation. It takes no notice period and no reason.

7.2 The features in Section 2 are not affected by a withdrawal; they carry their own switches and can be turned off separately.

7.3 Withdrawal does not by itself delete anything. An administrator can delete what the agent has learned– the drafts, run records and derived knowledge held for the organisation – in the same place, and that deletion is recorded like any other change.

7.4 Nothing in this Section limits the Customer's rights under Sections 8 and 11 of the DPA.

8. Telling End Users

Whether and how the Customer tells its End Users that an assistant answered is the Customer's decision as controller. The Services offer an optional line that is added to replies the agent sends unattended: it is off unless the Customer switches it on, and the Customer writes the wording itself, per language. We add nothing to a reply unless that switch is on.

9. Changes to this Addendum

9.1 A materially new kind of processing – a new category of data read, a new purpose, or a new recipient of conversation text – requires a new version of this Addendum and a new confirmation before that processing runs. What was already confirmed keeps running in the meantime.

9.2 Other changes are published as a new version, dated, and Section 13.5 of the DPA applies to them.

9.3 Version 1.1 added Section 3(6), importing past conversations, which is a new category of data read, and restated Section 3(5) to say plainly what is kept and how it may be used. A confirmation of version 1.0 continues to cover everything version 1.0 described.

9.4 Version 1.2 added training material to Section 3(3) – screen recordings and screenshots the Customer's team provides to show the agent how a procedure is carried out – with the limit on what can be replaced in them in Section 4, what of them reaches model providers in Section 5 and what is kept of them in Section 6. Training runs only for an organisation that has confirmed version 1.2 or later. A confirmation of an earlier version continues to cover everything that version described.

9.5 Every published version of this page is archived with the date it was captured and a hash of its text, so the wording a given confirmation refers to can be retrieved in full.