How to Standardize AI Across Multi-Hospital Systems

Standardization is a policy and enforcement problem

Acquisitions and affiliate agreements can bring a mix of models, vendor tools, clinical and administrative assistants, coding assistants, and integrations. Each may run under local policies and local PHI handling practices. Consolidating all of that onto one tool set is slow, and it does not by itself answer the question a CISO has to answer: what was each AI system allowed to do, and what did it do?

A more tractable approach is to standardize the rules and where they are enforced, and let the tools vary. The baseline policy set covers the behaviors that must be consistent everywhere: which data classes may reach which models, what is redacted before a prompt leaves the site, which tools and MCP servers an agent may call, what is rate limited, and which actions need human approval.

Sites will still differ. A coding assistant may be permitted only in revenue cycle at one hospital. Retention or data residency may differ between entities. Treat these as exceptions to the baseline, not as separate policy sets. Each exception should name an owner, a reason, and the part of that site's risk analysis that supports it. This matters because a regulated entity must consider its own risk analysis and organizational factors, including technical infrastructure and software security capabilities, when determining reasonable and appropriate audit controls. A shared baseline does not remove that per-entity justification.

Ownership needs the same attention. ASTP/ONC data show that in 2024, 74% of hospitals reported multiple entities accountable for evaluating predictive AI, and a quarter reported four. Those figures cover predictive AI only, but they suggest accountability is often split. Name one accountable owner per exception and per site.

Evidence for 164.312(b) across entities

Section 164.312(b) requires covered entities and business associates to implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use ePHI. On its face, that includes any AI system or integration that uses ePHI. How it applies to each component is a risk-analysis judgment, and no OCR guidance specific to AI was identified, so the application to AI is an interpretation of the text.

A January 2025 Federal Register document on the HIPAA Security Rule says OCR's enforcement experience suggests audit-control compliance could be improved with more specificity. As of November 2026, the current eCFR text of 164.312(b) shows no amendment since 2013. Design evidence to the text in force, and expect the expectations to become more detailed.

The practical consequence is that evidence should be a byproduct of enforcement. When policy is applied to each interaction and tool call, the same decision can be recorded: which system and identity acted, which policy version applied, what the outcome was (allow, redact, block, rate limit, or escalate), which tool was called, who approved an escalation, and when. That record is useful to an auditor because it shows both what the system was allowed to do and what it did.

The central security team needs to be able to examine these records, but each entity needs to retain them under its own retention and residency requirements. Hold them in the entity's environment, in a consistent structure, so the same query works at every site. Mapping the fields to HIPAA and NIST AI RMF once, at the baseline level, avoids rebuilding the mapping for each acquisition.

Where Trussed fits

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, and coding assistants, with allow, redact, block, rate limit, and escalate-for-approval outcomes applied to individual interactions and tool calls. It generates audit-ready evidence from that enforcement, mapped to HIPAA and NIST, and deploys self-managed in the customer's cloud with configurable retention and data residency.

Trussed runs in production with healthcare organizations. In production it has served 100+ models under one policy plane, with 99.95% uptime on live production traffic and more than 18 months of continuous operation in a regulated enterprise. The approach described above does not depend on any one product, but these are the properties to look for in whatever enforcement layer you choose.