The delegate handed an AI documentation project and told to get it live by quarter-end usually spends the first week looking at the technology. The BAA, the consent process, and the clinician-review protocol are the actual critical path, not the product demonstration. A clinical practice where someone routes patient data to an unvetted large language model sits one misconfiguration away from a notifiable breach, a voided insurance policy, and a regulatory investigation. Clinical AI governance is the licence to deploy, built before deployment begins, not a sign-off collected afterwards.
What is clinical AI governance?
Clinical AI governance covers the controls a clinical business needs before any AI system touches patient data or informs a clinical decision. The four minimum gates are a signed Business Associate Agreement with every vendor handling Protected Health Information, encryption at every stage of data transit and storage, a clinician-review protocol for AI output that could influence a clinical decision, and documented patient consent.
The distinction from generic AI governance matters. A payroll tool with a data-processing agreement and an audit log is, broadly, covered. A documentation tool transcribing patient consultations and feeding summaries into a clinical workflow sits in an entirely different risk class. HIPAA in the United States sets strict standards for the handling of Protected Health Information, and the US Office for Civil Rights enforces them. In the UK, the equivalent weight comes from the Data Protection Act 2018, NHS information governance requirements, and Care Quality Commission expectations.
The category of data drives the category of control. A business can deploy a general-purpose AI tool for admin with a light-touch agreement. When patient data enters that system, the light-touch agreement is insufficient regardless of how the vendor describes their platform.
Why does it matter more in a clinical business than anywhere else?
A scheduling error in a retail business is an inconvenience. A documentation error in a clinical practice can affect patient care. That asymmetry runs through every governance decision in a clinical setting. HIPAA carries financial penalties and potential clinical liability for failures that a signed vendor agreement would have caught. The same weight applies under NHS information governance frameworks. The risk class is genuinely different from anything else in an owner-managed business.
McKinsey’s Q4 2025 survey found that 50 per cent of healthcare leaders have implemented generative AI in their organisations, up from 25 per cent in Q4 2023. The adoption rate has outrun governance maturity in many practices. Healthcare leaders named inaccuracies in AI output, security vulnerabilities, and regulatory compliance failures as their primary concerns. The delegate asked to accelerate deployment is walking into exactly that gap.
The stakes are compounded because insurance cover depends on it. A practice that routes patient data to an unvetted AI model without a BAA has, in the eyes of many insurers, taken a deliberate action rather than made a negligent error. The implications for professional indemnity cover are significant.
Where will you actually meet the governance gates?
The BAA gate appears the moment you sign up to any tool that receives audio or text from a clinical consultation. The encryption gate applies as soon as patient data leaves your system. The clinician-review gate is live on the first patient note the AI generates. The consent gate should be in place before the others. Patients have the right to know when AI is involved in their care.
A frequently cited breach vector in small clinics is someone routing patient data to a general-purpose model with no vendor agreement in place. DoctorConnect’s guidance on healthcare AI integration notes that a single misconfiguration of this kind can trigger a HIPAA violation with severe financial and reputational consequences. The tool may work well, the output may be accurate, and nobody intends any harm. The absence of a BAA is the problem, regardless of intent.
The clinician-review requirement deserves specific attention. NICE’s guidance on AI-derived software in clinical settings is explicit that healthcare professionals must review AI outputs and that centres should maintain existing protocols alongside any AI tool. Healthcare professionals should be cautious when acting on software outputs without independent clinical review. The principle extends to a small practice deploying a documentation system. AI generates a draft note; the clinician reviews and signs it off under their professional responsibility.
Patient consent is now a live legislative front. Over 40 bills have been introduced across 25 states in 2026, according to Manatt Health’s AI Policy Tracker, with a consistent requirement that patients are aware when AI tools are involved in their care. A practice that does not disclose AI involvement cannot defend compliance by pointing to intent.
When do these requirements apply and when can you move faster?
The governance gates apply whenever AI touches Protected Health Information or could influence a clinical decision. A scheduling tool that never sees patient records sits outside the gate. An AI drafting appointment reminders with patient names and conditions does not. The line is the data, not the task. If the system processes PHI or could infer it from inputs, the full gate set applies.
The practical implication for a delegate managing several AI tools is that they fall into one of two categories. Admin-only tools with no access to patient records can be procured under a standard data-processing agreement, with appropriate staff training and access controls. Clinical-adjacent tools, anything that handles PHI or feeds into a clinical workflow, need the full gate set before the first patient interaction.
The categorisation matters because it protects the tools you can move quickly on. If everything is treated as clinical-adjacent, the governance overhead becomes unmanageable for a 90-person practice. If the distinction is drawn clearly and documented, admin tools can proceed while the clinical governance gates are being arranged for the higher-risk deployments.
What else belongs in a right-sized governance record?
A governance record for a 90-person practice can be brief, provided it covers what matters in a regulatory investigation. A log of vendor BAAs and their review dates, a written clinician-review protocol with named approvers, an evidence trail of patient consent disclosure, and a data flow map showing where PHI enters and exits each AI system. A single spreadsheet and two short documents will handle all four items.
What kills governance records in small practices is the enterprise template that arrives with 40 fields nobody fills in. The record needs to be light enough to maintain on a quarterly cycle by whoever holds clinical compliance responsibility. ASHA’s guidance for clinicians is clear that professionals retain responsibility for AI outputs and must be able to demonstrate that review happened. A governance record is how a practice proves it.
A quarterly review covers three things. First, confirm that all active vendors have current BAAs and check the review dates. Second, verify that the clinician-review protocol reflects how the tools are actually being used, not how they were expected to be used at go-live. Third, update the consent disclosure if any new AI system has been added to the clinical workflow. The practice that does this consistently holds the evidence if it is ever needed.
Getting the clinical boundaries in place before a tool goes live protects the AI programme. The BAA, the clinician-review protocol, and the patient consent disclosure take time to arrange correctly, and none can be retrofitted cleanly once a tool is handling patient data. A quarter-end deadline does not override a notifiable breach threshold. The delegate who treats governance as the pre-deployment gate, rather than the post-deployment tidy-up, is the one who keeps the programme in play.
