Security & GDPR

Last updated 6 September 2026

The one-page summary for practice managers — print or save as PDF and forward it; procurement forwards PDFs, not URLs.

Dictation is transcribed and drafted into exercises by Apple's on-device AI model — the audio never leaves the clinician's phone, and nothing is sent to Apple or any cloud service. The match to a condition, the discharge criteria, and every progression decision are rule-based, not generated, and shown to the clinician as the rule they are. Everything below follows from that split.

Where this stands today

Built and tested, not promised:

Security & compliance register

Every line is a specific statement we can evidence, or a plainly-marked pending or not-claimed item. We don't hold a certification we don't list here, and we don't list one we don't hold.

The architecture claim, specifically

Kaido's plan engine works from fixed, published thresholds and criteria — a rule that either is or isn't met, shown as the rule, not a model's paraphrase of one. Deciding what a plan contains and whether a criterion is met is never delegated to a model — that comparison runs entirely in Kaido's own deterministic code, every time. Two smaller, separate features do call Anthropic's Claude API with patient text — sentiment-scoring a flare note, and drafting a suggested adjustment for a clinician to consider — and neither one is live in production yet; see the register above for exactly what each does and doesn't have access to. Where a plan draws on voice input, that audio is transcribed on the clinician's own device with Apple's on-device speech recognition, then structured into a draft plan by Apple Intelligence — both steps run locally on the phone. The audio is never transmitted anywhere and is discarded once transcribed; the resulting text — the drafted plan, and any clinical note the clinician dictates — is sent over TLS to Kaido's own database as part of the clinical record, and nothing reaches a patient until the clinician has reviewed it and chosen to approve it.

Practically: there's no cloud transcription step to secure, no third-party sub-processor handling clinical audio, and no model API call in the critical path a breach or an outage could expose. This isn't a policy choice layered on top of a cloud architecture — there's no code path in the product that could send that audio elsewhere.

Isolation and audit, in detail

Every clinic's data is scoped by the database's own row-level security, not by the application remembering to filter correctly. The failure mode of a bug here is "see no data," never "see another clinic's data" — verified directly, by attempting real cross-tenant reads and confirming they return nothing. Every insert, update, and delete against clinical data is recorded in a separate audit log that the application's own database role cannot write to directly, cannot edit, and cannot delete from — only an automated trigger running with different privileges can append to it.

Where this sits under current UK AI regulation

In July 2026 the MHRA published guidance distinguishing AI tools that assist with clinical documentation — transcribing, summarising, organising information for a clinician's review — from tools that generate suggested diagnoses or treatment options as autonomous "insights," which fall under medical device regulation (Class IIa and above under the UK MDR).

Kaido's plan engine is built the first way, by design, for reasons that predate that guidance: it doesn't infer a diagnosis or a treatment recommendation from a model. It compares a patient's recorded values against fixed, published criteria and reports whether each is met — a deterministic comparison, not a generated suggestion — and nothing a clinician sees is ever applied to a patient's plan without that clinician's explicit approval. To be precise about which claim does which job: it's this deterministic, clinician-approved design that the guidance's documentation-assistance category describes — the guidance itself says nothing about on-device versus cloud processing. On-device transcription is a separate, additional privacy property (no clinical audio ever reaches a server), not the thing that determines regulatory category. We're not a lawyer and this page isn't a regulatory determination; it's a description of how the product actually works, so you can make your own assessment against the guidance directly.

Read the guidance yourself: MHRA — Ambient voice technology-enabled products.

Sub-processors

The complete list, and how we handle the one category of data that never reaches a sub-processor at all, is on the privacy policy.

Talk to us directly

If you're evaluating this for procurement — a DPA draft, a specific question about our architecture, or anything above that needs more than this page gives you — hello@kaidohealth.co. We'd rather answer directly than have you guess from a page.

Report a security issue — the contact and disclosure details are published in the standard place.