--- title: "KYE™ for Clinical AI — provable authority for AI-assisted clinical decisions" description: "When AI shapes care, the authority chain must be provable before it is challenged. KYE Protocol™ is the identity, delegation, policy and evidence layer for AI-assisted clinical decisions." url: https://kyeprotocol.com/clinical-ai/ lang: en source: "KYE Protocol" --- > When AI shapes care, the authority chain must be provable before it is challenged. KYE Protocol™ is the identity, delegation, policy and evidence layer for AI-assisted clinical decisions. Clinical AI # When AI shapes care, authority must be provable before harm is alleged. In clinical AI, authority is not a philosophical concept. It becomes evidential, legal, operational and — when a patient is harmed — adversarial. KYE Protocol™ is the identity, delegation, policy and evidence layer beneath AI-assisted clinical decisions: the layer that lets an organisation prove the authority chain from a record that existed _before_ litigation was contemplated, not one reconstructed afterwards. [Apply for pilot](https://kyeprotocol.com/pilot-apply/) [See the Evidence Pack™](https://kyeprotocol.com/evidence-pack/) The clinical authority question ## Not “what did the AI recommend?” When an AI recommendation shapes a clinical decision, the authority question is concrete — it is the first question a plaintiff attorney asks when a patient is harmed. The defensible answer has to cover every link at once: - **Who or what acted** — the verified entity behind the recommendation, human or agent. - **Under whose authority** — the delegation that placed the AI in the decision path, and who granted it. - **Within which clinical scope** — the use case the organisation actually authorised. - **Against which constraints** — the policy and guardrails that were active at the moment of the recommendation. - **With what oversight** — the approval state and the clinician’s ability to independently review the basis of the recommendation. - **Provable from a pre-litigation record** — evidence created before harm, complaint, investigation or discovery — not after. Contemporaneous evidence ## A record that existed before litigation was contemplated. The difference between a defensible clinical-AI decision and an indefensible one is rarely the model. It is whether the authority chain can be _proven_ in a deposition — from a record that existed at the moment of action — rather than reconstructed once harm is alleged. KYE™ emits a signed Evidence Pack™ per governed action and a Replay-Proof™ chain derivable from public keys alone: the authority context is sealed when the recommendation is made, not assembled by counsel afterwards. Do not reconstruct authority after harm. Preserve it at the moment of decision. What KYE™ preserves ## The clinical authority chain — sealed, link by link. For every AI-assisted clinical decision, KYE™ preserves the full chain as structured, signed evidence: - **Verified entity** — the identity of the human or agent in the decision path. - **Clinical role & delegated authority** — the grant that authorised the AI’s involvement, and its chain back to a human principal. - **Scope of use** — the clinical use case the organisation sanctioned, bound by Purpose Permission™. - **Model & tool capability** — what the system was permitted to do, and what it was not. - **Clinical context & policy constraints** — the guardrails that were active when the recommendation was produced. - **Approval state** — the oversight and sign-off in force at the moment of action. - **Evidence record & replayable chain** — a signed Evidence Pack™ and a Replay-Proof™ chain that gives the action **Authority Finality™**. Where KYE™ sits ## The evidence layer underneath your clinical-AI frameworks. KYE™ is not a clinical model and not a clinical decision support product. It is the infrastructure layer underneath them. Your governance framework defines _what authority should exist_ across the clinical AI decision chain; your assurance framework asks for _proof those constraints were present and functioning_ at the moment they mattered. KYE™ is the identity, delegation, policy and evidence layer that makes that chain verifiable — so both questions resolve to a record, not a narrative. The same authority layer applies wherever an AI agent shapes a clinical decision: digital pathology, radiology and medical imaging, AI diagnostics and clinical decision support, and software functioning as a medical device (SaMD). KYE™ governs the authority around the model — not the diagnosis itself — so the provenance, scope and oversight of each AI-assisted decision are provable across every speciality. For the device-regulation view, see the [MHRA Medical Devices Regulations](https://kyeprotocol.com/compliance/mhra-mdr-2002/) and [MHRA SaMD & AI change programme](https://kyeprotocol.com/compliance/mhra-samd-change-programme/) coverage maps. Independent review ## The basis of a recommendation, preserved for the clinician. Regulators draw the line around clinical decision support partly on whether a healthcare professional can independently review the _basis_ of a recommendation. KYE™ keeps that basis — the authority, scope, policy, context and capability around the recommendation — attached to the action as signed, replayable evidence. The clinician’s review, and the constraints they relied on, become part of the same sealed record. Regulatory coverage ## Mapped to the healthcare-AI frameworks that matter. KYE Protocol™ ships per-requirement bijection maps for the frameworks UK clinical buyers + safety regulators read first: - **HAARF v1.0** — Healthcare AI Agents Regulatory Framework. 279 requirements across 8 categories (risk lifecycle, model passport, cybersecurity, human oversight, agent registration, autonomy governance, bias/equity, tool integration). **88% weighted coverage** — [per-requirement map →](https://kyeprotocol.com/compliance/haarf/) - **MHRA Medical Devices Regulations 2002** — UK SI 2002/618 as amended. Risk classes + conformity assessment. **91% coverage** — [per-requirement map →](https://kyeprotocol.com/compliance/mhra-mdr-2002/) - **MHRA Post-Market Surveillance Regulations 2025** — explicit PMS plan, periodic safety update, trend + incident reporting, FSCA notification. **83% coverage** — [per-requirement map →](https://kyeprotocol.com/compliance/mhra-pms-2025/) - **MHRA SaMD & AI Change Program (2023)** — 15 work-packages covering qualification, classification, PCCP, AI Airlock, adaptive control, failure-mode analysis. **93% coverage** — [per-requirement map →](https://kyeprotocol.com/compliance/mhra-samd-change-programme/) Every requirement is bijection-mapped to a real KYE™ artefact (schema, engine, agent, worker, PDP, evidence pack, audit event). [Live coverage dashboard →](https://kyeprotocol.com/compliance/coverage/) Outcome-priced pilot · 4 weeks ## KYE™ HAARF Readiness Pilot™. A focused 4-week shadow-mode engagement on a single delegated clinical-AI workflow. Outputs: signed Evidence Packs™ per decision, a per-requirement HAARF v1.0 + MHRA SaMD coverage attestation, and an authority-gap report (which delegations are _not_ currently provable from your published JWKS). Hands off cleanly to your ICB digital team or notified-body correspondent. - **Scope** — one workflow, shadow mode only. No production guardrails are toggled. - **Frameworks bijection-mapped** — HAARF v1.0 (279 requirements), MHRA MDR 2002 (23), MHRA PMS 2025 (9), MHRA SaMD & AI (15). - **Deliverables** — signed receipts, signed per-requirement attestation (90-day expiry, deterministic rebuild), clinical-safety-case binding (DCB 0129 / 0160), ICB/regulator-facing executive summary. - **Continuity** — pilot fee credits 100% against the sector healthcare licence or the high-assurance annual licence if signed within 60 days. [Apply for KYE™ HAARF Readiness Pilot™](https://kyeprotocol.com/pilot-apply/) [HAARF coverage detail](https://kyeprotocol.com/compliance/haarf/) Outcome-priced pilot · 6 weeks · for NHS organisations ## KYE™ NHS Readiness Pilot™. Different from the HAARF Pilot above. The **HAARF Pilot** is for _SaMD vendors building_ the AI; the **NHS Readiness Pilot** is for _NHS organisations deploying_ AI — trusts, GP federations, ICBs, NHSE digital teams. 6-week shadow-mode engagement on a single NHS-deployed AI use-case, with DSPT-mapped Evidence Packs™, DCB 0129 / 0160 clinical-safety case bindings, and a Caldicott Guardian-ready summary. - **Frameworks bijection-mapped** — DSPT 2024/25, DCB 0129, DCB 0160, NHS Cyber Assessment Framework, HAARF v1.0, MHRA SaMD (where applicable). - **Deliverables** — DSPT control mapping per assertion (signed), clinical-safety case bindings, Caldicott Guardian summary, CCIO procurement template, ICB-onboarding artefact. - **Buyer-tuned** — CCIOs, Caldicott Guardians, ICB digital leads. Procurement framing, not engineering framing. - **Continuity** — pilot fee credits 100% against the sector healthcare licence or the high-assurance annual licence if signed within 60 days. [Apply for KYE™ NHS Readiness Pilot™](https://kyeprotocol.com/pilot-apply/) [UK regulator coverage](https://kyeprotocol.com/sovereign-ai/united-kingdom/) Pilot ## Clinical AI does not just need explainability. It needs authority finality. Bind KYE™ read-only to an AI-assisted clinical workflow and see the authority chain captured, sealed and replayable per action — before it is ever challenged. [Apply for pilot](https://kyeprotocol.com/pilot-apply/) Talk to the team Canonical KYE™ surfaces referenced on this page: [KYE Protocol™](https://kyeprotocol.com/) · [Purpose Permission](https://kyeprotocol.com/glossary/).