Presenting a Standardized AI Operating Model to a Health System Board

Treat the board presentation as an evidence problem

A board with fiduciary and regulatory oversight does not need a tour of AI tools. It needs to see which policies apply to AI use, who decides, how exposure of PHI is controlled, and what shows that the controls operated. A presentation built on intent (policies written, committees formed) invites the follow-up question of how anyone knows the policies were followed.

A standardized AI operating model answers that question by making the same set of controls apply across clinical, operational and administrative teams. NIST AI RMF 1.0 names the Board of Directors among the key actors responsible for AI governance, which gives AI oversight a legitimate place on the board agenda. The practical task for the governance leader is to give the board something it can examine rather than something it must take on trust.

The starting point is usually fragmented accountability. HealthIT.gov data on hospital use of predictive AI in 2023 and 2024 shows that three-quarters of hospitals reported more than one entity accountable for evaluating predictive AI, and more than half reported three or more. That data covers predictive models, not generative AI or agents, but the pattern is a useful prompt. Your packet should show how decision rights are consolidated or coordinated, not leave them diffuse.

Define the four components of the operating model

Present the operating model as four components that the board can ask about individually. Each one should have an owner, a control, and an artifact.

Policy ownership starts with an inventory of AI use cases and a named accountable owner for each. HHS's own AI strategy emphasizes clear roles, comprehensive use-case inventories and transparent risk management, and applies stricter controls to high-impact AI. A health system needs its own definition of risk tiers, since the HHS criteria are used internally by the department and are not an obligation for private health systems. For each generative AI system, document the context of use and the applicable legal alignment, as NIST AI 600-1 describes.

Runtime enforcement means policy is applied to individual interactions and tool calls as they happen, with outcomes such as allow, redact or block, rather than reviewed after the fact. Escalation for human approval covers the actions your risk tiers mark as requiring a person to decide, and the packet should say who approves and where that decision is recorded. NIST AI RMF GOVERN calls for clarity on roles for humans overseeing AI, and this is where that clarity becomes concrete.

Evidence and cadence close the loop. Evidence is the record that the policy was applied and the approval was given. Cadence is how often the board sees it.

• Policy ownership: Use-case inventory, risk tiers, and a named accountable owner for each use.
• Enforcement at runtime: Policy applied to each interaction and tool call: allow, redact, block.
• Escalation for human approval: Defined high-risk actions routed to a named approver, with the decision recorded.
• Evidence: Records of what policy applied and what happened, tied to specific regulatory text.
• Reporting cadence: A fixed schedule and a stable set of metrics, reviewed by the board or committee.

Map controls to HIPAA 164.312 and NIST AI RMF

Tie each board-facing control to specific regulatory text so evidence has a clear purpose. The HIPAA Security Rule applies to electronic PHI. Within the technical safeguards at 45 CFR 164.312, three standards matter most here. Access control requires technical policies and procedures that allow access to systems maintaining ePHI only to persons or software programs that have been granted access rights. The reference to software programs is a reasonable hook for treating AI agents and tool calls as access subjects, though you should present that as your interpretation. Integrity addresses protection of ePHI from improper alteration or destruction. Audit controls, at 164.312(b), require hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use ePHI.

The audit controls standard is technology-neutral. It does not prescribe log contents, retention periods or review frequency, so your organization has to set those and be able to explain the choice. Because AI systems that process ePHI are information systems that use it, activity involving AI interactions and tool calls belongs inside that scope.

On the NIST side, AI RMF 1.0 states that AI systems should be tested before deployment and regularly while in operation, and its MEASURE function covers analyzing, assessing, benchmarking and monitoring AI risk. Pair pre-deployment evaluation with in-operation monitoring evidence, so the board sees ongoing control rather than a one-time review.

HHS proposed modifications to the Security Rule in a notice of proposed rulemaking published on January 6, 2025. As of November 2026, treat the proposal as proposed and use the current 164.312 text as your baseline in the board packet.

Choose board-level metrics and decision points

Boards benefit from a short, stable set of measures more than a dashboard of everything. There are no established benchmarks for AI metrics at the board level, so present these as your own targets and trend them over time rather than comparing them with an external standard.

Useful coverage metrics include the share of AI use cases with a named owner, the share of AI interactions and tool calls that pass through runtime policy enforcement, and the share of models with pre-deployment evaluation and ongoing monitoring. The last one matters because HealthIT.gov found that fewer hospitals evaluated all or most of their models than evaluated some. Useful outcome metrics include counts of allowed, redacted, blocked and escalated actions by risk tier, escalation volumes and their resolution, and policy exceptions with their owners.

Pair the metrics with explicit decision points. Ask the board to approve the risk tiering definitions, confirm which uses require human approval, and set the reporting cadence. HHS's department-level AI governance board is expected to meet at least twice a year, which is a reference point for cadence and not a requirement for health systems. Whatever schedule you choose, commit to it, and define in advance what triggers an out-of-cycle report.

What runtime enforcement and evidence can and cannot substantiate

State this boundary in the presentation. It protects your credibility with the audit committee and prevents the evidence from being read as proof of more than it shows. Technical records show that activity was recorded and examined. They do not by themselves show governance quality, clinical appropriateness, or complete HIPAA compliance.

• Can substantiate: Which policy applied to a given interaction or tool call, what action was taken (allow, redact, block, escalate), and whether an escalation received a recorded human decision.
• Can substantiate: That enforcement operated continuously across AI use in scope, with records mapped to 164.312 access control and audit controls.
• Requires other processes: Whether a clinical decision supported by AI was appropriate, which needs clinical review and quality oversight.
• Requires other processes: Model fairness and accuracy, which need evaluation and monitoring programs.
• Requires other processes: Completeness of HIPAA compliance, which depends on risk analysis, policies, workforce training and vendor management.
• Requires other processes: Quality of governance itself, including whether owners and committees make sound decisions.

Questions to prepare for from the board and audit committee

These questions follow from the operating model rather than from published board guidance, so treat them as preparation prompts and adapt them to your committee.

• {"question":"Which AI use cases exist, and who owns each?","answer":"Answer from the inventory. Show use cases across clinical, operational and administrative teams, each with one accountable owner, and note any use that is unowned or awaiting tiering. Do not present the inventory as complete unless you have a process that discovers new use."}
• {"question":"How do we know policies operated on PHI?","answer":"Show enforcement records for AI interactions and tool calls, mapped to 164.312 access control and audit controls. Explain what is recorded, how it is examined, and how long it is retained. Be explicit that this evidences technical control, not full HIPAA compliance."}
• {"question":"Which uses need human approval, and where is it recorded?","answer":"Name the risk tiers and actions that trigger escalation, the approver role, and the record of each decision. Report escalation volumes and outcomes so the board can see whether the threshold is set sensibly."}
• {"question":"What share of models are evaluated and monitored?","answer":"Report coverage of pre-deployment evaluation and in-operation monitoring by tier. Acknowledge gaps and give a dated plan. This is evidence from evaluation programs, separate from runtime enforcement records."}

Where runtime enforcement infrastructure fits

The operating model does not depend on any one product, and the board packet should be understandable without one. Where the enforcement and evidence components need technical infrastructure, the relevant capability is policy enforcement in the execution path, with audit-ready evidence generated by that enforcement.

Trussed enforces policy in the execution path across models, agents, tools and MCP servers, at the level of individual interactions and tool calls. Actions can be allowed, redacted, blocked, rate limited, or escalated for human approval, and the continuous audit-ready evidence generated is mapped to HIPAA and NIST. It can be deployed self-managed in the customer cloud, with configurable retention and data residency, which bears directly on the retention and residency questions an audit committee may raise. Trussed runs in production with healthcare organizations and holds SOC 2 Type II, HIPAA and NIST AI RMF credentials.

It does not replace risk analysis, clinical review, model evaluation or the ownership decisions described above. Those remain organizational processes, and the board packet should say so.