How to Standardize AI Across Health System Departments with a Single Runtime Policy Layer

Why written policy does not standardize AI

Health systems tend to adopt AI one department at a time. Clinical teams, revenue cycle, scheduling, HR, IT and software engineering each choose their own models, tools and vendor-embedded features. Each path ends up with its own PHI handling, its own access rules and its own approval habits. A written policy applies to all of them in principle, but nothing makes it apply in the same way in practice.

This is an architectural problem. The HIPAA Security Rule requires covered entities and business associates to ensure the confidentiality, integrity and availability of all ePHI they create, receive, maintain or transmit. The access control standard in 164.312 allows access to systems holding ePHI only to those persons or software programs that have been granted access rights. Agents and assistants are software programs. The audit controls standard, 164.312(b), requires hardware, software or procedural mechanisms that record and examine activity in systems that contain or use ePHI.

HHS guidance states that the Security Rule does not mandate a specific technology. Where enforcement sits is therefore your design decision, and it has to be documented for every AI path. As of November 2026, the 164.312 text is in force and the sources reviewed show no amendment to 164.312(b).

What to standardize and what can vary

The test for a shared control is simple: if a department could weaken it without creating a compliance gap, it belongs in the variant layer. Otherwise it belongs in the baseline. The exposure of each use case depends on the data types involved and the actions the AI can take, so classify by those two properties rather than by department name.

• Policy definitions: standardize: One policy set, one versioned format, one owner. Departments reference it rather than writing their own.
• Data-handling rules: standardize: PHI detection and redaction apply to every path. Departments may narrow what is permitted, not widen it.
• Tool and model access: standardize the mechanism: Access is granted to identities, including service identities and agents. The approved list of tools and models can differ by department.
• Human escalation: standardize the mechanism: One approval pathway and one record format. The organization sets which actions trigger it, and thresholds can vary by use case.
• Evidence requirements: standardize: Every allow, redact, block and escalate decision produces a record with the same fields, so auditors read one format.
• Rate limits and use-case scope: vary: Volumes, permitted tasks and approver roles reflect how each department actually works.

Enforcing one policy set in the execution path

Reviewing AI activity after the fact tells you what happened but does not change it. Standardization requires an enforcement point in the path between the caller and the model or tool. The OWASP Agent Control Standard describes the general pattern: agent platforms expose middleware hooks, and safety policies are enforced there through declarative controls that are portable across agent frameworks.

Applied to a health system, that pattern has three parts. First, route model calls, agent actions, tool and MCP calls and coding assistant traffic through a common enforcement layer. Second, express policy declaratively, with the baseline defined once and department variants layered on top as configuration rather than separate implementations per tool. Third, return one of a small set of decisions on each interaction: allow, redact, block, rate limit or escalate for human approval.

The hard case is vendor-embedded AI. Some features expose no hooks and cannot be routed through an enforcement layer. For each such feature, record that it is outside the layer and assign compensating controls, such as contractual terms, disabling the feature or restricting the data it can reach. A path you cannot enforce should still appear in the inventory and the evidence matrix as a documented exception.

Scope matters. Enforcement at the interaction and tool-call level records what was allowed, redacted, blocked or escalated. It does not by itself provide transaction-level governance or end-to-end tracing of a multi-step workflow, and you should not plan evidence around either.

A phased rollout sequence

No source prescribes a sequence, so treat the following as a design choice ordered by risk and enforceability. The HHS AI Strategy emphasizes comprehensive inventories of AI use cases, which makes inventory the natural starting point.

• 1. Inventory: Record each AI use case with its department, model or tool, data types, identities involved and whether PHI is present.
• 2. Define the baseline: Write controls that apply everywhere: access only for granted rights (164.312(a)(1)), activity recording (164.312(b)) and integrity protection (164.312(c)(1)).
• 3. Establish an audit baseline: Route the highest-volume paths through the layer in observe-only mode to confirm coverage and record format before any blocking begins.
• 4. Turn on enforcement: Enable PHI redaction and blocking of disallowed tool calls first, then escalation for high-risk actions as approver roles are named.
• 5. Add department variants: Introduce variants as documented exceptions, each with an owner and a review date.
• 6. Build the evidence matrix: Map each control to the specific 164.312 and 164.308(a)(4) provisions, and note which records demonstrate which requirement.

Governance boundaries and evidence

Keep certified health IT separate in your inventory. The ONC HTI-1 final rule, published in the Federal Register on 9 January 2024, sets federal requirements for predictive decision support interventions in certified health IT, including EHRs. It does not address general AI tooling, so a predictive DSI inside a certified EHR and a coding assistant in IT sit under different obligations even if one runtime policy covers both.

Organizations must set their own human escalation criteria. Federal material does not define which actions require approval. The minimum practices in the HHS AI Strategy for high-impact AI (pre-deployment testing, impact assessments, independent review, monitoring, safe termination) are direction for HHS itself, but they make a reasonable reference model. In December 2025, HHS also issued a request for information on accelerating AI in clinical care. Federal policy is still developing, so schedule periodic policy review.

Trussed enforces policy in the execution path across models, agents, tools, MCP servers and coding assistants, with decisions to allow, redact, block, rate limit or escalate for human approval. Each enforced interaction generates audit-ready evidence mapped to HIPAA and NIST. Its scope is individual interactions and tool calls, not transaction-level governance or end-to-end workflow tracing. Trussed runs in production with healthcare and pharma organizations, holds SOC 2 Type II and HIPAA attestations, and operates 100+ models under one policy plane.

Common implementation questions

Two questions come up repeatedly once the architecture is agreed.

• {"question":"Can we start with logging only?","answer":"Yes, as a sequencing step. Observe-only routing establishes coverage and a record format. It does not change what AI does, so it should lead to enforcement of PHI redaction, blocked tool calls and escalation rather than replace them."}
• {"question":"Do department variants weaken standardization?","answer":"Not if variants are configuration on top of a shared baseline. Each variant should be a documented exception with an owner and a review date, and it should be able to narrow baseline permissions but not widen them."}