Bringing Department-Bought AI Tools Under One Health System Control Plane

Why departmental AI purchases break audit coverage

Clinical, revenue cycle, research and administrative teams each buy or switch on AI for their own reasons. The result is a mix of standalone SaaS products, AI features embedded in existing vendor software, browser-based AI sites, coding assistants and agents that call tools. Each arrives with its own access model, its own data handling and its own logs. The health system ends up with no consistent policy over PHI exposure, tool calls or model use, and no single record of what each tool was permitted to do.

The scale of adoption makes this a standing concern. ONC data shows 71% of hospitals used predictive AI integrated with the EHR in 2024, up from 66% in 2023, and billing and scheduling were among the fastest growing uses. Three-quarters of hospitals reported that multiple entities were accountable for evaluating predictive AI. That data does not measure shadow or department-purchased generative AI, but it shows how widely accountability is split even for governed tools.

The regulatory anchor is 45 CFR 164.312(b). It requires hardware, software and/or procedural mechanisms that record and examine activity in information systems that contain or use ePHI. It does not prescribe a technology. Applying it to AI tools is our interpretation, not a statement from the regulation, but it is a reasonable reading: if an AI tool contains or uses ePHI, you should be able to show records of its activity and show that someone examines them. Doing that tool by tool, with each vendor's logs in a different format, is where most health systems struggle.

Step 1: Inventory and classify by PHI exposure and interaction path

Start with discovery that does not depend on departments volunteering information. Procurement records, SaaS and expense data, identity provider application grants, network and browser telemetry, and a short attestation from each department head will each find different tools. Include revenue cycle and scheduling uses explicitly, and ask vendors of existing clinical and administrative software which AI features are active in your tenant.

For each tool, record two attributes. The first is PHI exposure: whether the tool creates, receives, maintains or transmits ePHI, and through which fields or documents. The second is interaction path: how users and systems reach the tool and what it can reach in turn. Typical paths are direct use through a browser, calls to a hosted model through an API, an embedded feature inside vendor software, a coding assistant working with repositories, and an agent that invokes tools or MCP servers.

Where a tool handles ePHI, confirm that a business associate arrangement with satisfactory assurances under 164.314(a) is in place. That is a separate governance control from technical audit records, and one does not substitute for the other. Also record the encryption decision for each data path. Encryption is an addressable specification under 164.312, so the decision and its implementation should be documented.

• Tool, owning department and business owner
• Whether ePHI is created, received, maintained or transmitted
• Interaction path: browser, API, embedded feature, coding assistant, agent or MCP server
• Business associate arrangement status
• Existing access model and available activity records
• Proposed policy tier

Operating model and evaluation criteria

Technical enforcement fails without clear ownership. Because accountability for AI evaluation is commonly spread across several entities, name one policy owner and one exception approver, and build on the multidisciplinary governance teams many hospitals already run. Departments propose tools and use cases, the governance team tiers them, security owns enforcement and evidence, and exceptions carry an owner, a reason and an expiry date. Some AI, including systems developed in-house, falls outside FDA oversight, which is a further reason for the health system to set its own oversight.

When evaluating an enforcement layer, ask whether it applies one policy set across models, tools, agents and MCP servers without requiring departments to replace their tools, and ask for a demonstration. Ask whether it supports all five actions and how exceptions are approved, whether it can be deployed in your own cloud with configurable retention and data residency, what it exports for HIPAA review, and which healthcare production deployments the vendor can document.

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, with allow, redact, block, rate limit and human-approval escalation, enforced at runtime, not reviewed after the fact. Enforcement generates audit-ready evidence mapped to HIPAA. Trussed deploys self-managed in the customer cloud with configurable retention and data residency, and runs in production with healthcare and pharma organizations. Its scope is individual interactions and tool calls.