Healthcare AI governance in 2026: what binds you now, what waits until 2028

"I've seen large language models give completely different responses. And one of those responses would probably cause patient harm if used." That is Mark Mabus, Chief Medical Information Officer at Parkview Health, talking to CIO Magazine on 8 April 2026. It is also a fair description of where most 200-800 bed health systems are in May 2026: the AI is already in the building, the vendor says the Business Associate Agreement (BAA) covers it, and the compliance team is being asked whether the hospital could produce an audit trail if a regulator turned up. A Black Book Research survey of 182 hospital leaders, reported by Becker's Hospital Review in November 2025, put a number on it: 22 percent of respondents said they were highly confident they could produce a 30-day AI audit trail for regulators or payers.

This post is for that compliance team. A Chief Compliance Officer, CMIO (chief medical information officer), or legal head at a 200-800 bed US system or an NHS Trust of equivalent scale, reading the same headlines about the EU AI Act, FDA PCCP (Predetermined Change Control Plan) guidance, and state AI laws, trying to work out what actually binds today, what is coming in 2027 and 2028, and who is the primary defendant when patients are harmed. The honest answer in May 2026 is awkward. The August 2026 binding moment for high-risk clinical AI under the EU AI Act slipped to 2028, while the operational stack you already operate under in 2026 is heavier than the headlines suggest, and the civil-liability primary defendant in most jurisdictions remains the manufacturer of the AI.

What actually binds you in mid-2026

The rules that are in force on US hospitals and NHS Trusts today, in May 2026, do not have "EU AI Act" in their name. They are sectoral and quieter, and they already carry most of the deployer load.

In the US the binding stack covers HHS Section 1557 nondiscrimination (final rule 6 May 2024; the AI and patient-care decision-support provisions started applying on 1 May 2025), ONC HTI-1 algorithm transparency (final rule January 2024; Predictive Decision Support Intervention disclosures binding on certified EHRs from 1 January 2025), the FDA Predetermined Change Control Plan guidance (finalised 4 December 2024), and California AB 3030 (in force 1 January 2025, mandatory disclaimer on generative-AI-generated clinical communications). Colorado SB24-205 was delayed from February to 30 June 2026 with a HIPAA carve-out that still requires provider action.

The UK equivalent is SI 2024/1368, the Medical Devices Post-Market Surveillance Requirements Regulations (in force 16 June 2025), NHS England DCB0129 and DCB0160 clinical-safety standards, and the Digital Technology Assessment Criteria (DTAC, revised February 2026) buyer gate. MHRA's AI-specific framework, the output from the AI Airlock regulatory sandbox, is still consultative as of October 2025, with Phase 2 reports due Summer 2026.

For the EU itself, the parts of the AI Act that are already binding on the deploying organisation in 2026 are Article 5 prohibited practices and Article 50 transparency (both in force from 2 August 2025), the general-purpose AI obligations binding from 2 August 2025, and the revised Product Liability Directive 2024/2853 (in force 8 December 2024; member-state transposition deadline 9 December 2026). MDR and IVDR conformity duties on medical-device clinical AI already apply via the existing device regime.

If a hospital is operating clinical AI in May 2026, the binding obligations are not theoretical.

What waits until 2027 and 2028

On 7 May 2026 the Council of the EU and the European Parliament reached a provisional political agreement on the Digital Omnibus. The high-risk obligations in Article 6 that were originally set to bind on 2 August 2026 have been deferred. Annex III stand-alone high-risk obligations move to 2 December 2027. Annex I high-risk obligations, which cover AI embedded in regulated medical devices, move to 2 August 2028. The agreement is still provisional (both institutions need to formally adopt it) and Appify's own Irish guide to GDPR data residency in 2026 records the same deferral for the wider AI-and-data context.

Article 26 deployer duties travel with those dates. When they bind, the hospital is required to appoint competent human oversight, monitor the system in operation, retain logs, and report serious incidents. There is no earlier separate compliance date for deployers; the operational duties arrive together with the underlying high-risk classification on 2 August 2028 for the medical-device case.

Two things matter to a 2026 governance build. The first is that clinical AI inside a regulated medical device enters via Article 6(1) as a safety component of an Annex I product, and not via Annex III. The Annex III healthcare entries are narrow: 5(a) covers public-authority eligibility decisions for healthcare benefits, and 5(d) covers emergency call triage and dispatch. Diagnostic AI and clinical decision support typically do not enter Annex III. The second is that the 12 to 24 months of runway is the cheap moment to build the controls. The expensive moment is after a regulator visit.

Where civil liability still sits, and why that is not the same question

A compliance team reading the binding-now stack might fairly conclude that the harder exposure is civil liability when a patient is harmed. The honest read in May 2026 is that the primary defendant remains the manufacturer of the AI in most jurisdictions.

The revised EU Product Liability Directive 2024/2853 treats software, including AI systems, as a product and anchors strict liability on the producer. The Commission formally withdrew the proposed AI Liability Directive in 2025, so the EU has explicitly declined to harmonise a regime that would have extended fault-based presumptions across deploying organisations. In the US, the FDA Predetermined Change Control Plan guidance places lifecycle responsibility for algorithm modification, monitoring, and labelling on the manufacturer. Across more than eight searches for observed regulator enforcement action against hospitals for AI use, the counter-evidence research stream behind this article surfaced none.

Civil liability sits with the producer; regulatory and operational duty sit with the deployer. A board that treats those as the same question lands in the wrong governance posture either way. Buying vendor risk transfer as a substitute for Article 26 controls and discovering the regulator does not accept the contract as a defence is the expensive version of that mistake.

Patient data: the rules that already bind harder than the AI Act

The patient-data perimeter is where governance fails first, well before any AI Act deadline. The pattern is familiar. Clinicians frustrated by tooling paste protected health information into consumer-grade large language models. Jane Moran, Chief Information and Digital Officer at Mass General Brigham, put it plainly at HIMSS in March 2026: "We actually needed to do more education with our employees about safety and security and keeping our patient data private."

Two regimes already apply. HIPAA Business Associate Agreements require contractual coverage of every system processing protected health information (PHI) on the hospital's behalf, including the specific model, endpoint, and region the vendor is calling. A blanket "OpenAI signed a BAA" line in a vendor deck covers only the specific endpoints, models, and regions named in the agreement. Anything outside that scope is the hospital's exposure. GDPR Article 28 in the EU and the UK PMS Regulations impose equivalent processor controls, and the DTAC gate in NHS England procurement makes a Data Protection Impact Assessment specific to the AI use case a buy-side requirement.

The operational tell is shadow AI: staff using tools the IT department did not procure, with patient data flowing into endpoints the BAA does not name. Joe Izzo, CMIO at San Joaquin General Hospital, told HIT Consultant in January 2026 that vendors are increasingly selling around the hospital direct to physicians, and "those agreements typically put all the onus entirely on physicians." Even when the contract places liability on the clinician, the hospital retains the regulatory exposure on the data side.

Bias and drift: the monitoring load is empirically yours

The technical reason post-deployment monitoring is the deployer's load, regardless of whether the AI Act is binding yet, is in the published evidence.

Nature Medicine published in 2024 that fairness-mitigation techniques applied to clinical AI generally do not generalise to out-of-distribution data: a model debiased on the training cohort frequently re-introduces disparate impact when deployed in a different patient population. A 2025 JAMA Network Open study across seven Toronto hospitals documented a drop of around 0.12 in AUROC (area under the receiver-operating curve, the standard ranking measure for clinical AI) for a respiratory model after a lab-test change at one site, a silent drift the system itself did not flag. Wong et al. published the foundational external validation of Epic's Sepsis Predictive Model in JAMA Internal Medicine in 2021, and the JAMIA Open follow-up in 2024 reconfirmed the failure mode: 14.7 percent sensitivity in the six-hour window and a median advance warning lead time of zero minutes.

The surveillance system that is supposed to catch this is empirically not equipped. An npj Digital Medicine analysis published in 2025 found that across fourteen years of FDA MAUDE (Manufacturer and User Facility Device Experience) reporting, only 943 events were associated with AI or machine-learning-enabled devices, with 98 percent of those concentrated in fewer than five devices. Concept drift, fairness-generalisation failure, and silent post-deployment degradation are failure modes that the regulator surveillance pipeline is structurally unfit to catch. The hospital is the only operator with eyes on the system in production.

That is the governance argument independent of the AI Act timing. Even if the EU cliff slips again, the technical case for a hospital-owned monitoring stack does not.

When the algorithm is wrong: accountability in operator terms

The question "who is accountable if an AI system makes a wrong diagnosis" has a clean operator answer in May 2026: three different parties hold three different kinds of accountability. The clinician who acted on the output remains clinically accountable; the hospital carries the regulatory and operational accountability for the deployment, and the manufacturer carries civil-liability exposure as the producer of a defective product. Each leg has its own primary defendant, and a real governance posture maps each of them.

Inside the hospital, that mapping is operational. A named accountable person per AI use case. A risk register that integrates with the existing clinical-safety case under DCB0129 and DCB0160 for NHS deployers, or with the hospital's quality-management system in the US. A human-in-the-loop checkpoint at every decision where the system can cause harm, of the kind the Moffatt v. Air Canada decision and the operator-floor logic Appify wrote up earlier this year put on the books for an operator relying on a vendor-provided model. Patient-facing disclosure under CA AB 3030 or Section 1557. Incident-reporting linkage from the clinical incident database into MAUDE or Yellow Card where applicable.

What does not work is treating vendor compliance documentation as the hospital's governance. SOC 2 reports, BAAs, and FDA clearances are inputs to the hospital's risk register, DPIA, and Article 26 monitoring plan. The mapping has to be done on the hospital's own terms or it does not exist at all.

What to do in the next 90 days if you took this seriously

The runway from now to the 2028 medical-device cliff is real, and now is the cheap moment to build. Five steps mapped to the binding-now stack:

1. Inventory every AI system processing patient data, with the model name, endpoint region, BAA scope, and the clinician users. Compare against the IT-procured list. The gap is your shadow-AI exposure.
2. Map each system to its regulatory class: AI Act Annex I medical-device safety component, Annex III healthcare entry, or out of scope. The classification governs your 2027 and 2028 obligations and your current MDR/IVDR posture.
3. Open the BAA on each in-use AI vendor and confirm the model, region, and routing path are explicitly covered. HHS Office for Civil Rights enforcement under HIPAA and Section 1557 assumes you have done this; a missing BAA scope is the first thing a regulator visit will catch.
4. Build the audit trail that the Black Book survey says only 22 percent of hospitals can produce. A 30-day reconstruction of who ran which model on which patient is the minimum readiness baseline.
5. Define the deployer-side controls that will be required under Article 26 once it binds: human oversight role, monitoring cadence, log retention, incident escalation. Run them now on the systems most likely to be in scope when 2 August 2028 arrives.

The pillar this article sits alongside is the scope-not-category piece on healthcare AI ROI. The procurement side and the governance side are the same decision looked at from two angles. Pick the line item the AI is meant to move, then build the governance posture that lets you defend it.