Who should own AI governance across an NHS Trust?

Why Ownership Matters More Than a Single Team Label

ai governance across an NHS Trust should be owned as a cross-functional control model, not as a narrow digital or data project. The reason is simple: the trust is not governing a single tool, but a lifecycle that includes clinical risk, information handling, procurement, model assurance, cyber exposure, supplier dependencies, and patient impact. If ownership is vague, the usual failure is not lack of policy, but gaps between policy, assurance, and operational decisions. Current guidance also points to governance as a standing management function rather than a one-off approval, which is why frameworks such as the NIST AI Risk Management Framework and ISO/IEC 42001:2023 AI Management System Standard are useful for structuring accountability, oversight, and review. In practice, many failures begin when AI is treated as either an IT purchase or a clinical pilot, rather than a governed organisational capability.

How Governance Should Work in Practice

A workable NHS Trust model usually has a named executive sponsor, a governance forum with decision rights, and domain owners who control the parts of the environment they actually manage. Digital typically owns technical enablement, integration, monitoring, and incident response. Information Governance owns lawful use, records, retention, and information sharing. Clinical Safety owns clinical hazard review, safety case expectations, and the impact on workflows and patient care. Cybersecurity owns threat modelling, access, logging, supplier security, and control assurance. Data and analytics teams own dataset quality, lineage, bias checks, and use-case validity. Procurement owns supplier due diligence, contract terms, assurance evidence, and exit provisions. Risk and privacy functions make sure the residual risk is visible and formally accepted where needed.

• Set one accountable executive lead who can force escalation when ownership is disputed.
• Give each control domain a documented decision boundary, so teams know what they approve and what they only advise on.
• Use a single register for AI systems, suppliers, model updates, and approvals, so governance follows change over time.
• Require evidence at go-live and at re-approval, not just at procurement.

That model aligns well with the control discipline in NIST Cybersecurity Framework 2.0 and the access, audit, and system integrity expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls. These controls tend to break down when AI tools are bought through local service lines without a central intake and assurance route.

Common Variations and Edge Cases

Tighter governance often slows adoption, so the trust has to balance speed against safety, accountability, and auditability. The right structure changes depending on whether the AI is a low-risk productivity tool, a diagnostic support system, or a patient-facing decision aid. High-impact use cases should usually receive stronger clinical and risk review, while lower-risk internal uses can follow a lighter but still documented path. There is no universal standard for every AI scenario yet, so the practical test is whether the governance model scales with the level of clinical and operational consequence.

Supplier-provided AI creates a further edge case: the Trust may not control the model itself, but it still owns the decision to deploy it, the data it shares, the safeguards around it, and the evidence that it is safe enough for the intended use. A mature model also needs a clear rule for exceptions, because unresolved disputes between clinical, digital, and IG teams are a common source of delay. If the use case can affect patient safety, data protection, or service continuity, the governance route should be explicit before deployment, not improvised afterward. One useful reference point for supplier and operating-model discipline is CSA Cloud Controls Matrix, which is especially helpful where AI is delivered through cloud services and shared responsibility is easy to blur.

Risk and Threat Considerations

The main risk is not just poor decision-making, but unowned decision-making. When no one has clear authority over AI intake, approval, monitoring, and retirement, unsafe tools can spread through departments, supplier risk can go unchecked, and clinical or information governance concerns can surface only after deployment. That creates avoidable exposure across safety, privacy, cyber, and operational resilience.

Failure mechanism: Weak ownership leads to fragmented approvals, incomplete supplier review, poor logging, and missed change control. Attackers and unsafe suppliers both benefit from that fragmentation because it reduces visibility into what was deployed, who approved it, and what data or access it received.

Impact: The trust can end up with unsafe clinical outputs, data leakage, weak audit trails, unmanaged third-party dependencies, and delayed incident response. At scale, the bigger problem is that no team can prove it still knows where AI is running or who is accountable for it.

Practitioner Guidance

What to prioritise: Assign one executive owner for the governance model, then define which teams own intake, approval, monitoring, and retirement. The main error is to appoint a sponsor without giving that role decision rights over disputes and exceptions.

What to verify: Check that every live AI use case has a named business owner, a clinical or operational risk owner, a technical owner, and an assurance record. If any one of those is missing, the control model is incomplete even if the tool is already in use.

Practitioner takeaway: The right ownership model is not the one with the fewest names, it is the one that makes every material AI decision traceable to a responsible function before harm, not after it.

Related resources from NHI Mgmt Group

• Who should own AI agent governance when identity and access are shared across teams?
• Who should own AI governance across identity and data controls?
• Who should own Zero Trust governance across human and machine identities?
• Who should own device trust governance across manufacturing and operations?