Standard AI Policy Library for a Health System, Mapped by Department

What a standard AI policy library contains

Most health systems start with a single AI policy document. It tends to state principles but not say which rules apply to a coding assistant, a patient-facing chatbot, or an agent calling an internal scheduling tool. A library fixes this by breaking the policy into units that can be assigned, tested, and evidenced.

A workable library has six components. First, an inventory of AI use cases, since you cannot map policies to interactions you have not identified. Federal AI strategy documents list comprehensive use case inventories and clear roles among their core governance mechanisms, and the same logic applies to a health system. Second, policy categories such as acceptable use, PHI handling, tool and data access, disclosure, human oversight, and third-party tools. Third, a department mapping. Fourth, an enforcement mode for each policy. Fifth, an evidence specification. Sixth, an owner and a review trigger.

The NIST AI RMF is a useful organizing reference for the documentation, risk assessment, and governance content. It is voluntary and does not authorize or prohibit specific clinical AI systems, so treat it as a structure for your library, not a source of rules.

Department mapping: data, tools, risk, enforcement, evidence

The table gives representative mappings. Your inventory will add or remove tools, but the pattern holds: the data a department handles determines the policy categories, and the tool determines where enforcement can occur. Supply chain and operations follow the same pattern with vendor, contract, and inventory data, and can be added once the inventory shows AI use there.

• Clinical: Data: PHI in notes, orders, patient messages. Tools: documentation assistants, patient chatbots. Risk: PHI exposure, unreviewed output entering the record, missing AI-use disclosure. Action: redact identifiers sent to unapproved destinations, block unapproved tools, escalate for clinician approval before write-back. Evidence: user, tool, policy applied, action, approver.
• Revenue cycle: Data: claims, coding, billing records, PHI. Tools: coding assistants, payer correspondence tools. Risk: PHI in prompts, bulk extraction, unreviewed code suggestions. Action: allow approved tools, redact PHI, rate limit bulk requests. Evidence: request volumes, redaction events, blocked attempts.
• IT and security: Data: source code, credentials, system configurations. Tools: coding assistants, agents calling internal tools. Risk: secrets leakage, over-permissioned agents. Action: block secrets, allow tool calls by role, escalate privileged actions. Evidence: per-tool-call record of identity, permission, and outcome.
• Compliance and privacy: Data: audit records, incident files, PHI used in investigations. Tools: summarization and search assistants. Risk: sensitive case data leaving approved boundaries. Action: allow limited roles, redact, block external destinations. Evidence: exportable records per policy for reviewers.
• HR: Data: employee records, benefits, performance data. Tools: HR policy assistants, employee chatbots. Risk: employee data exposure, answers outside approved policy content. Action: allow policy questions, redact or block employee-record fields. Evidence: interaction records tied to the HR policy version in force.
• Research: Data: research datasets, possibly PHI. Tools: analysis and literature assistants. Risk: data leaving the approved environment, use outside protocol. Action: block unapproved destinations, redact identifiers, escalate data-use exceptions for approval. Evidence: approvals and blocked attempts per study or project.

Policies written as documents versus policies enforced at runtime

Sort every policy into one of two groups. The first group depends on judgment: whether a clinical use is appropriate, how a vendor is selected, what validation a tool needs before deployment. These stay as documents backed by procedures and committee review. The second group depends on what happens in a specific interaction or tool call: which data types are sent, which tool an agent may call, how many requests a user can make, whether an action needs a person to approve it. These can be enforced at runtime.

The five actions are straightforward. Allow permits an interaction that matches policy and records it. Redact removes regulated data, such as identifiers, before it reaches a model or tool. Block stops the interaction. Rate limit constrains volume, which matters for bulk extraction. Escalate holds the action until a designated person approves it.

Each action has a tradeoff. Redaction can reduce output quality. Blocking without an approved alternative pushes staff toward unmanaged tools. Escalation adds latency and requires someone to staff the queue. Decide these per department rather than globally.

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites, and coding assistants, so these actions are enforced at runtime, not reviewed after the fact. The scope is individual interactions and tool calls. Trussed runs in production with healthcare organizations and is deployed self-managed in the customer cloud, with configurable retention and data residency.

Audit-ready evidence per policy: HIPAA and NIST AI RMF

Define the evidence at the same time as the policy. The HIPAA audit controls standard, 45 CFR 164.312(b), requires hardware, software, or procedural mechanisms that record and examine activity in information systems that contain or use ePHI. HHS has not issued AI-specific guidance in this area, but AI interactions that touch ePHI plausibly fall within that scope, so it is prudent to produce records that meet the standard. As of November 2026, the current text of 164.312 shows no pending amendment.

Three adjacent standards shape the evidence design. The access control standard allows access only to persons or software programs granted access rights, so AI agents and tools need their own identities and permissions, not just their users'. The integrity standard, protection from improper alteration or destruction of ePHI, is separate from audit controls, so protect the evidence itself and do not treat the two as one requirement. Encryption is an addressable specification, so document the decision either way.

For each policy, specify the record: the acting user or software program, the tool or model involved, the policy and version applied, the action taken, the timestamp, and any approver. This supports NIST AI RMF documentation and risk-assessment needs. Keep claims bounded: interaction-level and tool-call-level records show what AI was allowed to do and what it did at those points. They are not a substitute for model documentation or for tracing whole workflows.

Implementation sequence

Build the library in an order that exposes gaps early. Ownership and exception structures vary by organization, so define them explicitly instead of assuming a standard model.

• 1. Inventory AI use cases: List tools, departments, data types, and whether each tool can reach internal systems.
• 2. Assign roles: Name an owner for each policy and a role that approves exceptions and escalations.
• 3. Draft by department: Write policies against the data and tools in each department, not as one generic document.
• 4. Classify each policy: Mark it as document-only or enforceable, and choose the runtime action for the latter.
• 5. Specify evidence: Define the record each policy produces and how it is protected, retained, and exported.
• 6. Check disclosure and jurisdiction: Review state measures, such as California AB-489's emphasis on disclosing AI use in health care, against clinical and patient-facing policies where they apply.