How to Prepare a Health System Board AI Risk Briefing

Organize the briefing by risk category (clinical, operational, data, third-party), reference recognized frameworks such as the NIST AI Risk Management Framework, and give directors a defined set of questions about agent identity, permissions, and auditability.

Board briefing building blocks

Four elements give directors something they can evaluate and act on, rather than a general awareness presentation.

Why a generic AI briefing format falls short

Health system boards increasingly oversee AI systems that go beyond model accuracy questions. Many organizations now deploy agentic tools that can query patient data, trigger workflows, or take actions inside clinical and administrative systems. Directors are asked to approve budgets, set risk appetite, and satisfy fiduciary oversight duties for technology that most have not evaluated technically.

No current healthcare regulation specifies how a board should be briefed on AI risk. NIST's AI Risk Management Framework comes closest: its Govern function calls for organizational accountability structures and senior leadership oversight of AI systems. But the framework is voluntary and sector-agnostic. It tells a board that oversight structures should exist; it does not tell a Chief Risk Officer what to put on a slide.

That gap is the reason a board briefing should be treated as a governance artifact: a structured translation of technical control evidence into claims a non-technical director can evaluate and act on, rather than a general risk-awareness presentation.

Risk categories that differ from generic enterprise AI risk

• Clinical decision impact: Predictive decision support embedded in EHR workflows carries direct patient safety exposure and, when it qualifies as a regulated medical device, falls under FDA lifecycle guidance. Administrative AI performing similar tasks may not carry the same regulatory scope but still carries operational risk if it acts incorrectly.
• Operational and administrative automation: Agents automating back-office tasks such as prior authorization or revenue cycle work can take autonomous actions across systems. The risk centers on whether actions stay within authorized permission scope, not on model accuracy alone.
• Data exposure: Agents with broad system access can retrieve or move protected health information beyond their intended task. This category concerns access control and logging rather than clinical judgment.
• Third-party and vendor AI: Predictive tools embedded in certified EHR systems fall under HTI-1 disclosure requirements for developers. Boards should distinguish tools the health system builds from tools it deploys but did not build, since available evidence differs.

Technical evidence should support every claim

A statement such as "our clinical AI agents cannot access patient records outside their assigned task" is only as credible as the artifact behind it. Three types of evidence support board-level claims.

Runtime governance controls, including agent identity, least-privilege permissions, tool approval workflows, and audit logging, are the technical layer that generates this evidence. A briefing that references these artifacts gives a board something it can question and verify, rather than a description of intent.

What recent frameworks establish, and what they don't

Several frameworks published or updated in the past year shape board oversight expectations, though none prescribe a briefing format.

NIST's AI Risk Management Framework (2023) and its Generative AI Profile (2024) organize AI risk into Govern, Map, Measure, and Manage functions, with Measure and Manage calling for ongoing monitoring rather than a point-in-time assessment. This implies a board briefing should reference continuous evidence, such as monitoring summaries or log excerpts, rather than an annual attestation alone.

HHS's HTI-1 rule requires developers of certified health IT to disclose source attributes, such as development data and validation approach, for predictive decision support tools. Boards can request this documentation as evidence when a vendor's predictive tool is in use.

FDA's lifecycle guidance for AI-enabled medical devices, including predetermined change control plans, applies specifically to regulated software as a medical device. Boards should distinguish this FDA-scoped clinical AI from administrative or agentic tools that operate outside that scope but still carry operational risk.

CHAI's assurance guidance, published in 2024, describes practices such as model cards and local validation. It is a voluntary industry reference, not a compliance requirement, and adoption varies across health systems.

Agentic risk, including excessive agency and insecure tool integration, is addressed by security-community guidance such as OWASP's work on LLM application security rather than by a healthcare regulator. This leaves agentic risk as a technical evidence gap CROs must close directly, rather than one they can cite a regulation to satisfy.

Structuring the briefing itself

• Segment the briefing by risk category (clinical, operational, data, third-party) rather than by AI project or vendor.
• Map each claim to a specific artifact: permission policy, access log excerpt, or enforcement record.
• Define escalation thresholds in advance, such as what volume of blocked agent actions triggers board notification.
• Include vendor and third-party tools in scope, referencing available disclosure documentation such as HTI-1 source attributes.
• Reference continuous monitoring evidence rather than a single annual assessment.
• Align cadence and structure with existing risk, compliance, or quality committee processes rather than creating a standalone AI reporting track.