AI Policy, SOPs and Safe Deployment for Health and Care Providers
Your staff are already using AI. The questions an inspector will ask are whether you knew, whether you assessed it, and whether you can produce the record.
This service writes the policy, the standard operating procedures and the clinical safety documentation that answer those questions — then helps you actually deploy the tools, because a policy nobody can follow is a document waiting to be contradicted by practice.
Two kinds of adviser, and the gap between them
Neither can finish the job alone, and the gap between them is where the risk sits.
The compliance adviser
Knows CQC, the Caldicott Principles and the Data Security and Protection Toolkit inside out. Has never deployed a model.
Cannot tell you what happens to your data inside a context window, cannot read a supplier’s sub-processor list critically, and cannot tell whether the answer you were given about training data is true or merely reassuring.
You get a policy. You do not get a control.
The AI adviser
Can wire a transcription pipeline into your workflow in a weekend, and it will work.
Learned data protection from a compliance course. Has never been accountable for a patient record, never written an incident report, never sat opposite an inspector explaining a decision.
You get a working tool. You do not get a defensible one.
This service covers both halves
The documentation is written by someone who works inside a CQC-registered care provider and holds clinical registration — so the SOPs describe how care is actually delivered, not how a template imagines it.
The technical assessment is done by the developer of a commercial AI product that calls four separate model providers in production. When a vendor explains what their system does with your data, the load-bearing parts of that answer get identified rather than accepted.
One engagement, both halves, no hand-off between two suppliers who each assume the other covered it.
The compliance stack for AI in health and care
There is no single AI regulation to comply with. There is a stack of separate obligations, they differ in kind, and they land on different people. Every layer below links to its primary source.
Articles 9 and 35
Anyone processing health data
Health data is special category data. You need a lawful basis under Article 6 and a separate condition under Article 9 before it goes anywhere near a model. Five of the ten Article 9 conditions also require you to meet additional conditions in the Data Protection Act 2018, and some require an appropriate policy document.
A Data Protection Impact Assessment is required before high-risk processing begins — and the ICO specifically names innovative technology and large-scale special category processing as triggers. Writing the DPIA afterwards to justify a decision already taken is the most common failure in this layer.
Anyone holding patient or service-user records
Eight principles, published by the National Data Guardian. Every proposed use or transfer of confidential information must be defined, scrutinised and documented; identifiable information is used only where necessary; and only the minimum required is included.
“The tool performs better with the full record attached” is not a justification under any of the eight. Where a novel or difficult judgement is needed, the Caldicott Guardian should be involved — and an AI deployment is exactly that kind of judgement.
Clinical risk in deployment
Any organisation deploying health IT — including an AI scribe or an AI care-planning assistant
Published under section 250 of the Health and Social Care Act 2012. It requires a named Clinical Safety Officer, a hazard log, and a clinical safety case for your deployment in your setting. The current version is 3.2, published in 2018.
Your supplier’s DCB0129 work does not discharge this. The two standards ask different questions and both apply. This is the most frequently missed obligation in the stack, and it reaches far more organisations than realise it — NHS trusts, primary care, ICBs and social care providers alike.
Clinical risk in manufacture
Manufacturers and suppliers of health IT
Requires proportionate clinical risk management processes, maintained clinical safety documentation, and a Clinical Safety Officer appointed throughout the development lifecycle. Current version 4.2, published 2018.
If you build or sell the tool, this is yours. If you buy it, this is the evidence pack to obtain from your supplier before deployment — and the input your own DCB0160 work depends on.
Regulations 12 and 17
CQC-registered providers
CQC set out its position on AI in health and social care on 21 May 2026. The significant part is what it chose not to do: there is no separate AI framework and no separate AI assessment. Existing regulation already applies, supported by principles for good use of AI aligned to published BMA and WHO principles.
In practice, Regulation 12 (safe care and treatment) requires risks to be assessed and mitigated as far as reasonably practicable, and Regulation 17 (good governance) requires effective systems to assess, monitor and improve quality and safety, with accurate records. Both now have to cover your AI use.
CAF-aligned, version 8
Anyone handling NHS patient data or connecting to NHS systems
Now aligned to the National Cyber Security Centre’s Cyber Assessment Framework: outcome-based, evidence-led, and no longer a checklist you can simply answer yes to. Four CAF objectives plus an NHS-specific objective covering the lawful use and sharing of patient information.
NHS England has signalled further directive cyber policies from September 2026, covering areas including multi-factor authentication and endpoint detection. If AI tooling is absent from your asset inventory and information asset register, that is a visible gap.
Digital Technology Assessment Criteria
Suppliers selling digital products into the NHS and social care
The refreshed form carries roughly 25% fewer questions after duplication with the Toolkit and the pre-acquisition questionnaire was removed, with full transition to the updated form by 6 April 2026. It covers clinical safety, data protection, technical security, interoperability, and usability and accessibility.
It is not a certification. It is the assessment an NHS or social care buyer will put in front of you, and your answers have to be consistent with your clinical safety and data protection evidence.
Anyone whose tool has a medical purpose
Intended purpose decides this, not marketing language. Standalone software and apps meeting the definition of a medical device require UKCA marking under the UK MDR 2002 (as amended). Describing a tool internally as “decision support” does not settle the question if actual use and actual sales messaging say otherwise.
This is the layer most likely to move next. The MHRA is developing an AI-specific regulatory framework through its Software and AI as a Medical Device Change Programme, informed by the AI Airlock regulatory sandbox and the National Commission into the Regulation of AI in Healthcare.
Regulation (EU) 2024/1689
Providers and deployers operating in, or supplying into, the EU
In force since 1 August 2024, with obligations phasing in afterwards. It takes a risk-based approach: prohibited practices under Article 5, and high-risk systems classified under Article 6 with Annexes I and III.
An AI system that is a medical device under EU rules will generally also be high-risk under the AI Act — meaning two conformity assessments and two sets of post-market obligations for one product. If you have any EU footprint, scope this early rather than discovering it mid-sale.
One layer is actively moving, and the legal weight behind it has already changed.
Section 250 of the Health and Social Care Act 2012, under which DCB0129 and DCB0160 are published, has been amended twice. Section 95 of the Health and Care Act 2022 came into force on 7 July 2025 and changed the duty from “have regard to” to “must comply”, introducing the Health and Social Care Information Standards (Procedure) Regulations 2025. Section 121 of the Data Use and Access Act 2025 came into force on 5 February 2026 and expanded scope so that IT providers can be subject to a duty of compliance.
NHS England’s position is that, as the standards currently stand, bodies exercising a health or care function must continue to have regard to them — but that future revisions are likely to draw on these enhanced powers. In plain terms: the enforcement teeth are already in the legislation, waiting for the revised standards to use them.
Those revisions are underway. NHS England opened a national review of both standards, with a public consultation running from 29 June 2026 to 11 September 2026. Its own focus groups identified AI governance as a critical gap, finding that artificial intelligence, machine learning and ambient voice technologies present risk profiles the current standards do not adequately address. Work started now should be structured to survive that revision rather than be redone after it.
Eight things, in the order they usually need doing
Most engagements start at the first and stop wherever your internal capability picks it up. Nothing here is a package you have to take whole.
1. AI use audit
What is already in use, including the tools nobody declared. Personal accounts, free browser extensions, transcription apps on staff phones. You cannot govern what you have not found.
2. Risk map
Every identified use mapped against the compliance stack above, so you can see which uses are fine, which need documenting, and which need stopping today.
3. AI use policy
Board-adoptable, version-controlled, and written to your actual service — your registered activities, your systems, your staff groups. Not a template with your logo on it.
4. Standard operating procedures
The operational layer the policy is useless without. AI-assisted documentation, transcription and scribing, care planning, escalation, override and correction.
5. DPIA and Article 9
A defensible impact assessment and a clearly stated Article 9 condition, produced before deployment and written to be read by your DPO and, if it comes to it, by the ICO.
6. Clinical safety documentation
Hazard log and clinical safety case inputs under DCB0160, prepared alongside your appointed Clinical Safety Officer — including the AI-specific hazards the standard was not written for.
7. Supplier assurance
The questions to put to a vendor and how to read the answers: DCB0129 evidence, DTAC responses, data residency, retention, sub-processors, and whether your data trains their model.
8. Deployment and training
Configuration, rollout, staff competency, and a governance calendar with a real review cadence. The part most advisers leave you to do alone.
The artefacts, named
So you can tell exactly what lands on your desk, and so your board can see what it is approving.
- AI Use Register — every tool, its owner, the data class it touches, its lawful basis and its approval status
- AI Use Policy — board-adoptable, versioned, with a review date and a named owner
- Staff Acceptable Use Standard — plain English, one page, with a signed declaration you can evidence
- Standard operating procedures — one per approved use case, written to your workflow, not to a generic one
- DPIA pack — assessment, screening questions and the Article 9 condition, ready for your DPO
- Hazard log and clinical safety case inputs — structured for DCB0160 and handed to your Clinical Safety Officer
- Supplier assurance questionnaire — plus completed assessments for the tools you already run
- Incident and near-miss procedure — covering AI-specific failure modes: fabricated content, silent model change, drift
- Training pack — slides, scenarios and a competency check you can record against each member of staff
- Governance calendar — review cadence, model change control and the evidence trail an inspector will ask for
Four situations, four different starting points
Adult social care & complex care
CQC-registered domiciliary, supported living and complex care providers. Usually starts with rostering, care-plan drafting and transcription already in informal use.
Private clinics & independent healthcare
Smaller teams, no in-house information governance function, and a real appetite for AI scribing. Usually needs the whole stack building from nothing, quickly and proportionately.
NHS primary care
GP practices, PCNs and federations. DCB0160 applies to you as a deploying organisation, and your Toolkit submission has to be consistent with what your clinical systems actually do.
Healthtech & care software suppliers
You need DCB0129 evidence and a coherent DTAC response before an NHS buyer will proceed, and you need to know whether your intended purpose makes you a medical device.
Four ways in, priced openly
Each produces something you own outright. Nothing is retained, nothing is licensed back to you, and there is no tooling you have to buy afterwards. Prices are published because you should be able to budget without booking a call.
AI Exposure Triage
Start here if you do not yet know what you are dealing with
Fixed fee · two hours · remote
- Structured two-hour session with whoever knows what staff actually use
- First-pass AI use register
- Two-page red-flag note: anything that should stop today
- An honest answer on whether you need more than this
AI Readiness Review
Start here if you need a board-ready assessment
Fixed fee · typically three to four days
- Discovery across clinical, admin and management teams
- Completed AI Use Register, including undeclared tools
- Risk map against every layer of the compliance stack
- Prioritised action list separating stop-now from document-soon
- Written report your board can take as a paper
Policy and SOP Build
Start here if you know what you use and need it governed
Fixed fee · typically ten to thirteen days
- Everything in the Readiness Review
- AI Use Policy and Staff Acceptable Use Standard
- Standard operating procedures for each approved use case
- DPIA pack and Article 9 condition
- Hazard log and clinical safety case inputs for your CSO
- Supplier assurance questionnaire and completed assessments
- Incident and near-miss procedure for AI failure modes
- One round of board revision included
Implementation Partner
Start here if you are deploying, not just documenting
Build fee then monthly retainer · twelve-month minimum
- Everything in the Policy and SOP Build
- Tool selection and configuration, vendor-neutral
- Staff training delivery and competency recording
- Governance calendar and scheduled review cycles
- Re-assessment when a supplier changes their model
- Named point of contact throughout
All prices exclude VAT and are quoted per organisation, not per site. Fixed fees are genuinely fixed: the day estimates are shown so you can see the basis, but if the work runs long that is absorbed, not invoiced. Scope changes — extra use cases, extra systems, additional sites — are agreed in writing before any additional work starts. Travel outside Cambridgeshire is charged at cost and agreed in advance.
Clinical practice and software engineering, in one engagement
Daryo89 Ltd is a UK enterprise architecture and AI consultancy. This service is delivered directly by the founder, without subcontractors, so the person who assesses your tools is the person who writes your documentation and the person who sits in front of your board.
The clinical side. Delivery is led by a clinically registered practitioner working in a CQC-registered complex care provider — mobilising services, writing the standard operating procedures behind them, and working with commissioners and regulators as ordinary business rather than as a case study. That is why the SOPs describe how care is actually delivered on a shift, including the volume at which a review stops being real.
The technical side. Daryo89 builds and ships a commercial AI product that calls four separate model providers in production, handles credentials, rate limits and failure modes, and is sold to businesses who depend on it working. Supplier claims about data handling are assessed by someone who has implemented the same architecture, not by someone reading a datasheet.
Independence. No vendor agreements are held and no commission is taken on any tool assessed. If the right answer is that a tool should not be deployed at all, there is nothing in it for this service to say otherwise.
Independently verifiable
What this is not
Because the fastest way to lose a healthcare client is to be vague about your limits and then hit one.
Not legal advice
Daryo89 Ltd is not a firm of solicitors and nothing produced here is legal advice. Where an engagement turns on a point of law, that is a question for your legal advisers and it will be flagged as such rather than guessed at.
Not your Data Protection Officer
The DPIA and Article 9 analysis are produced to a standard your DPO can review, sign and defend. The role itself is not replaced, and where you have no DPO you will be told whether you are required to appoint one.
Not your Clinical Safety Officer
DCB0160 requires a suitably qualified and experienced clinician, appointed by you, to hold that role and sign the safety case. This service prepares the hazard log and documentation and works alongside them. It does not sign it.
Not a reseller
No vendor agreements, no commission on any tool assessed, and no referral fees. Tool recommendations are made against your requirements, or not made at all.
Not a generic policy
Sector bodies have publicly warned that AI-drafted policies are appearing in inspections and creating risk rather than reducing it. A policy that does not describe your actual service is worse than none, because it evidences a control you are visibly not operating.
Not a certification
Nothing here certifies you. DTAC is an assessment, not a badge; the Toolkit is a self-assessment with independent audit for some categories. This service gets you to a defensible position and tells you plainly where you still are not.
Questions providers actually ask
Our staff already use ChatGPT on their own phones. Is that a breach?
It depends entirely on what they put into it. Using a general assistant to rephrase a training email is not a data protection issue. Pasting in a service user’s history to get help writing a care plan almost certainly is: it is special category data, disclosed to a third-party processor you have no contract with, with no lawful basis recorded and no impact assessment.
The more serious problem is that you cannot currently prove which of those two things happened. That is why the first piece of work is always finding out what is actually in use, before anyone writes a policy about it.
Do we really need a Clinical Safety Officer just to use an AI scribe?
If you are a health or care organisation deploying health IT that could affect patient care, DCB0160 applies, and it requires a named Clinical Safety Officer, a hazard log and a clinical safety case. An AI scribe that produces text which ends up in a clinical record is health IT.
The role does not have to be a full-time appointment, and for a small provider it is usually an existing senior clinician taking it on with proper support. What it cannot be is nobody.
Our supplier says they are DCB0129 compliant. Doesn’t that cover us?
No, and this is the single most common misunderstanding in this area. DCB0129 is the manufacturer’s standard: it addresses whether the product was built with clinical risk managed. DCB0160 is the deploying organisation’s standard: it addresses whether the product is safe in your setting, with your staff, workflows and patient group.
The supplier’s safety case is an input to yours. It is not a substitute for it, and an inspector will not accept it as one.
Is our AI tool a medical device?
The test is intended purpose, not technology and not marketing language. Standalone software and apps that meet the definition of a medical device require UKCA marking under the UK Medical Devices Regulations 2002, as amended, and fall to the MHRA.
Describing it internally as “decision support” or “for information only” does not settle the question if the way it is actually used, and the way it is actually sold, tells a different story. Resolve this early, because the answer changes everything downstream.
Can AI write our care plans?
AI can draft alongside a practitioner. It cannot be the author of record. The professional remains accountable for the content, has to have genuinely reviewed it, and has to be able to say what they changed and why. That is also what Regulation 17 expects of your records.
Where this goes wrong is not the technology, it is the volume. When one person is signing off forty AI-drafted plans in an afternoon, the review has stopped being real, and that is visible in the records. The SOP has to set a workload the review can survive.
What does CQC actually expect from us on AI?
CQC published its position on 21 May 2026 and deliberately did not create a separate AI framework or a separate AI assessment. Its approach is that existing regulation already applies, supported by high-level principles for good use of AI aligned with published BMA and WHO principles.
Practically, the expectation is the ordinary one: that AI use is assessed, monitored and recorded under your governance systems, that care and clinical decisions stay under human control, and that you can evidence all of it. There is no new box. The existing boxes now have to include this.
We are a supplier, not a provider. Where do we start?
With intended purpose, because it determines whether you are regulated as a medical device. Then DCB0129, because NHS buyers will ask for it and you cannot retrofit it credibly. Then DTAC, where the refreshed form became the only version in use from 6 April 2026 — shorter, but more tightly cross-referenced against your Toolkit position and your clinical safety evidence.
Inconsistency between those three documents is what stalls deals. Getting them written together is faster than getting them written separately and reconciled later.
The clinical safety standards are being reviewed. Should we wait?
No. NHS England opened a national review of DCB0129 and DCB0160, with a public consultation running from 29 June 2026 to 11 September 2026, but the current standards remain in force throughout and your obligations do not pause.
There is also a reason not to wait. The legislation behind the standards has already been strengthened — the duty under section 250 was changed from “have regard to” to “must comply” in July 2025, and scope was expanded to IT providers in February 2026. NHS England has said future revisions are likely to draw on those enhanced powers. Building the evidence now, with the reasoning kept explicit, means a revised standard becomes an update rather than a rewrite.
We already subscribe to a policy library for a few pounds a month. Why would we pay more?
Because it is a different product, and the comparison does not hold. A policy library sells you documents. It does not produce a Data Protection Impact Assessment for your deployment, an Article 9 condition you can defend, a hazard log, clinical safety case inputs for your Clinical Safety Officer, or a completed assessment of the supplier you are actually about to sign with.
There is also a specific risk in the generic route. Sector bodies have publicly warned that AI-drafted and off-the-shelf policies are turning up in inspections and increasing risk rather than reducing it, because a policy that does not describe your real service evidences a control you are visibly not operating. Keep the library for your general policy suite. This is the part that has to be about you.
Is Daryo89 a law firm or a compliance firm?
Neither. Daryo89 Ltd is an independent enterprise architecture and AI consultancy, and this service is delivered by a clinically registered practitioner who also builds AI systems.
That means the assessment of what a tool genuinely does with your data is first-hand, and the operational documentation is written by someone working inside a regulated care environment. It also means that where a question is properly legal, you will be sent to a solicitor rather than given a guess. Both of those are in your interest.
Every source on this page, in one place
All links point at the issuing body. Verified live on 29 July 2026. If a claim on this page cannot be traced to one of these, it should not be on the page.
Data protection & confidentiality
- Rules on special category dataInformation Commissioner’s Office
- Data Protection Impact AssessmentsInformation Commissioner’s Office
- The Caldicott PrinciplesNational Data Guardian, GOV.UK
- Information governance and data protectionNHS England
Clinical safety
- DCB0160 — deployment and useNHS England Digital
- DCB0129 — manufactureNHS England Digital
- Digital clinical safety assuranceNHS England
- Review of DCB0129 and DCB0160NHS England Digital
- National review: supporting informationNHS England, 29 June 2026
- Consultation questionnaireNHS England, closes 11 September 2026
- Health and Social Care Information Standards (Procedure) Regulations 2025legislation.gov.uk, SI 2025/950
Regulation, inspection & procurement
- AI in health and social care: role, expectations and plansCare Quality Commission, 21 May 2026
- Regulation 12: safe care and treatmentCare Quality Commission
- Regulation 17: good governanceCare Quality Commission
- Data Security and Protection ToolkitNHS England
- Board and executive assurance: cyber security riskNHS England
- Digital Technology Assessment Criteria (DTAC)NHS England
- Software and AI as a Medical Device Change ProgrammeMHRA, GOV.UK
- AI AirlockMHRA, GOV.UK
- Regulation (EU) 2024/1689 — AI ActEUR-Lex
Start with a scoping call
Thirty minutes, no charge, no obligation. Tell us what you are using and what you are worried about, and you will get an honest answer about whether you need this service, need someone else, or need nothing yet.
Regulatory positions described on this page are current as at 29 July 2026 and are provided for information, with every source linked above. They are not legal advice.
