Transfer Risk Assessment

Document details

1. Overview of transfers

Two transfers to AI sub-processors occur for real-time processing. The processor's position is that neither carries personal data: Transfer 1 sends unlinked voice audio to Deepgram's EU endpoint with identity entities redacted at source; Transfer 2 sends care observations to z.ai with no names, codes, mapping or identity markers. On that basis Chapter V (Articles 44–49) is not engaged and Article 46 safeguards are not required for either.

2. Transfer 1 — Deepgram, Inc. (EU endpoint)

2.1 Description

Carer voice observations are sent to Deepgram's EU API endpoint for real-time speech-to-text with identity-entity redaction enabled. The audio is sent as an unlinked stream — no person identifier, no database record, no organisational context, no care plan, no session history. Deepgram processes it in real time on EU infrastructure and returns a transcript with identifying entities already replaced by placeholders. The redacted transcript is then routed by care domain for structuring.

2.2 What is redacted, and what deliberately is not

Every care transcription request names the entity classes to redact:

• Redacted: personal names (given, family and full), email addresses, phone numbers, street addresses, postcodes, geographic coordinates, usernames, URLs.
• Deliberately not redacted: times, dates and durations; ages; occupational roles; the names of medical professionals; and all health content. These are the clinical record. A transcript that turns "the seizure lasted three minutes" into a placeholder, or deletes "the support worker was present", is worse than useless for care — and none of them identify the supported person.

2.3 Deepgram's data handling

• Retention: mip_opt_out=true on every care transcription call, excluding the request from the Model Improvement Program; account-level retention disabled. Data from opted-out requests is retained only as long as needed to process the request.
• Training: Deepgram's documentation states that the only data it stores and uses in future model training is data contractually included through the Model Improvement Partnership Program. WellDash is not enrolled.
• Security: SOC 2 Type II, HIPAA-ready, GDPR-ready, PCI DSS compliant. TLS in transit, AES-256 at rest.
• EU endpoint: all care voice processing is routed through api.eu.deepgram.com.
• DPA and SCCs: Deepgram provides a DPA incorporating the EU Commission's Standard Contractual Clauses on request, and states that it frequently enters into them with customers.

2.4 Risk assessment

2.5 Scope note — other Deepgram usage

The controls in this section apply to the care voice-transcription path. WellDash's wider product surface also uses Deepgram for text-to-speech in non-care contexts; that path sends generated speech text to Deepgram's global endpoint and does not carry the care redaction or EU routing described here. It is not part of the care recording system covered by the DPA, and no supported-person record is sent through it.

3. Transfer 2 — z.ai (Singapore)

3.1 Description

Care observations are sent to z.ai's API for real-time structuring and image description. The browser holds the identity context — the carer chose which supported person they are recording for. What z.ai receives is the observation content with no names, pseudonymous codes, mapping or identity markers. Routing is by care domain, not by person. z.ai returns structured output; nothing is stored there.

3.2 Data transferred

• Typed text: care observations sent with no identifier attached — no name, code, database key or organisation id in the payload or the prompt. The person's stored names are used server-side only to build a redaction list applied to the text before it leaves. Carers are trained not to type names; the model is instructed never to infer identity.
• Voice-derived text: identity entities have additionally been redacted at source by Deepgram before the transcript enters this path.
• Images: photographs of care observations with no person identifier, database record or organisational context. Hub images are scrubbed on-device before transmission.
• Care context: the current thread's plan steps, standing facts and controlled vocabularies — functional care content authored without personal names.
• Special category content: health observations are present, because structuring them is the purpose. With no identity attached, no mapping and no re-identification capability at the recipient, the processor's position is that this is not personal data in z.ai's hands.

3.3 z.ai's data handling

• Retention: z.ai's Data Processing Addendum states that it does not store the content customers or end users provide or generate; content is processed in real time and is not saved on its servers.
• Training: the DPA governs business and enterprise API processing separately from the consumer privacy policy; API data is not used for model training.
• Security: industry-standard encryption; security commitments in the DPA.

3.4 Risk assessment

4. Technical enforcement — the identity firewall

The claims in sections 2 and 3 — that identity stays behind and only care content travels — are not policy aspirations. They are enforced by specific controls in the application code. This section says what each one is and where it lives, so an auditor can confirm the architecture rather than take it on trust.

4.1 What each layer can see

4.2 Voice — identity redacted at source

Three controls are applied on every care transcription request, hard-coded on the server call rather than supplied by the client:

• Targeted entity redaction — names, email addresses, phone numbers, addresses, postcodes, coordinates, usernames and URLs are stripped during transcription and returned as placeholders. A spoken name never exists in plaintext downstream.
• mip_opt_out=true — every request is excluded from the Model Improvement Program: no training, no persistence beyond the processing window.
• EU endpoint — all care voice processing is routed through api.eu.deepgram.com.

4.3 Structuring — the model is given no identifier at all

• No name. The prompt refers only to "the supported person" and instructs the model that it is never given their name or any identifier, to use neutral reference, and never to infer identity. If a name appears in the carer's own words the model may quote the carer verbatim, but must not add identity of its own.
• No pseudonymous code. Earlier designs passed a namespace slug or database key into the prompt so the model could echo it back to tools. That was removed: the prompt renders no namespace, no key and no organisation id.
• Domain-only routing. The coordinator that decides which care thread an observation belongs to is given the catalogue of care domains and routes by domain. It is not told, and cannot derive, whose observation it is.
• Names scrubbed from content. The person's stored preferred and legal names are loaded server-side purely to build a redaction list, which is applied to care text before it reaches the provider — so an incidental name typed by a carer is removed rather than forwarded.

4.4 Tools are scoped by the server, never by the model

This is the control that makes the firewall robust rather than merely tidy. The model acts on the record through a small set of tools — read recent logs, propose a record, update a standing fact, forward to a domain thread. In every case:

• The tool definitions the model sees contain no identity parameter. There is no field into which the model could place a person's name, code or key. The schemas simply do not offer one.
• Identity is injected server-side. When a tool runs, the server attaches the active supported person from its own request-scoped context, resolved once. The model's request is scoped to the correct person without the model ever naming them.
• Cross-person access is structurally unavailable. A model that hallucinated, was prompt-injected or was outright malicious still could not request another person's data: it has no parameter with which to express "that other person", and the server ignores any identity the model invents.
• Returned data is scrubbed. When the model reads recent care logs, identity and attribution columns — the person key, the organisation key, recorded-by and confirmed-by fields, contact details, NHS number, date of birth — are stripped from every row before it reaches the model. It gets the clinical content, not the linkage keys.

4.5 The carer is protected too

In care sessions the carer's own profile is reduced to their occupational role and competence areas, used only to calibrate tone; free-text profile prose, which can contain their name and personal detail, is withheld from the prompt. Call-participant email addresses from the business product surface are never rendered into care prompts.

4.6 Data at rest is authored name-free

The care-plan content the model reads as context — per-domain routine narratives, standing-fact headers, quality frameworks — is authored without personal names, referring to "the person" throughout. This content was audited and incidental names removed, so even the context surrounding an observation carries no identifier into the AI step.

4.7 Re-identification happens only on this side

Names are joined back to structured records by the browser and the reporting layer — at the moment a carer views a record or a report is produced — using data endpoints that read directly from the database and never call an AI provider. Identity and AI processing are separated in time and in place: the model reasons on the anonymous surface; the name exists only on either side of it.

5. Overall assessment and recommendation

5.1 Combined assessment

• Identity entities are redacted at source on the voice path.
• Identity lives in the browser and the UK database, not in the packet sent to an AI provider.
• Routing is by care domain, not by person.
• Neither AI sub-processor stores the data; the exposure window is seconds.
• Neither AI sub-processor uses the data for model training.
• Each call is an isolated transaction — no session continuity, no ability to link observations across calls.
• No AI-facing interface offers a field in which identity could be supplied.

On that basis, neither AI transfer constitutes a transfer of personal data within the meaning of Chapter V, and Article 46 is not applicable to either. The UK–Singapore Digital Economy Agreement provides a supporting bilateral framework for the Singapore leg.

5.2 Recommendation

For the trial period: both AI transfers may proceed without Article 46 safeguards on the position set out above, provided the identity firewall is maintained as a condition of that position.

Before production deployment the controller should:

1. Evaluate UK-hosted or EU-hosted language-model providers if Singapore remains a concern.
2. Complete a transfer assessment for the infrastructure sub-processors (Supabase, Vercel, Resend, Stripe), which do process personal data and are not covered by the anonymity argument here.
3. Decide explicitly how the email intake path — the one live route where identified care content leaves the system — is to be governed, or restrict it.
4. Obtain the Deepgram DPA with SCCs as a documented fallback should the ICO take a different view of the transfer position.

5.3 Comparison with industry practice

• Comparable UK care platforms that send raw audio to a third-party AI provider do so with the audio inherently linked to the client's care-record session, retain it for a period, and rely on SCCs as their Article 46 mechanism because they are transferring personal data. WellDash redacts identity entities at source, routes voice through an EU endpoint, and sends care observations with no identity markers.
• Consumer AI tools link uploaded content to an identified user account with persistent conversation history. WellDash's sub-processor calls are stateless, sessionless and carry no person-identifying context.