Consolidating Departmental AI Gateways into One Enforcement Layer at a Health System

Gateway sprawl is a policy and evidence problem

Clinical, revenue cycle, research, and IT teams often stand up their own gateways, proxies, or API wrappers around models. Each carries its own allowlists, its own approach to PHI, its own credentials, and its own log format. Routing is rarely the hard part. The hard part is that the same prompt containing PHI can be allowed in one department, redacted in another, and unexamined in a third.

The Security Rule frames why this matters. Covered entities and business associates must ensure the confidentiality, integrity, and availability of all ePHI they create, receive, maintain, or transmit. The audit controls standard at 164.312(b) requires hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use ePHI. If AI prompts, responses, or tool calls carry PHI, the layer they pass through is such a system, and its activity records are the audit mechanism to design for.

The access control standard adds a second constraint. It limits access to ePHI systems to persons or software programs that have been granted access rights. Agents, tool-calling services, and coding assistants are software programs, so each needs an explicit identity and rights. Credentials scattered across departmental gateways make that mapping hard to prove.

Ownership is also fragmented. ONC data on predictive AI shows that three-quarters of hospitals report multiple entities accountable for evaluating it. A consolidated layer needs a named owner for central policy, or it will inherit the same ambiguity.

Step 1: Inventory what exists before designing anything

Start with a complete inventory, including the informal wrappers a research group built for a single project. For each gateway, record enough detail to compare it against the others. Without that comparison, a common policy model is guesswork.

The items below are an editorial recommendation for what to capture. Interview each owning team, then confirm against network egress data, since teams often forget integrations that still carry traffic.

• Gateways and wrappers: Every gateway, proxy, or API wrapper, its owner, and the department it serves.
• Traffic and destinations: Which models, agents, tools, and coding assistants route through each, and which bypass any gateway.
• PHI handling: Whether the gateway redacts, blocks, or passes PHI, and how that was validated.
• Credential model: Where API keys and service identities live, who can rotate them, and how callers are identified.
• Log format and retention: Fields captured, format, storage location, and retention period.

Step 2: Define a common policy model and decide what belongs centrally

Build the policy model from the inventory. The categories to harmonize are PHI redaction rules, model and tool allowlists, rate limits, and human-approval escalation. Express them in one schema, so that a rule means the same thing regardless of which department invokes it.

A workable split is to enforce centrally anything that protects PHI or defines which models and tools may be reached. That means allow and block decisions, PHI redaction, baseline rate limits, and escalation for human approval on high-consequence actions. Departments can keep parameters inside the schema, such as which tools a revenue cycle assistant may call, who the approver group is, or a higher rate ceiling for a batch coding job. What should not remain departmental is the enforcement mechanism itself.

Departmental exceptions will exist, and they should be policy entries, not side channels. Each exception should be explicit, time-bound, and owned by a named party, and it should appear in the evidence like any other decision. Route policy changes through an existing multidisciplinary governance team where one exists, so central policy and departmental needs are reconciled in one place.

Keep scope honest. A runtime enforcement layer decides what an individual interaction or tool call may do. It does not establish that a predictive model is valid, fair, or effective, which is the concern of the FAVES goals in ONC's HTI-1 rule. Those evaluation duties stay with their current owners.

Step 4: Design evidence continuity for 164.312(b)

The sources do not prescribe log fields or retention for AI traffic, so the evidence schema is a design decision. A sensible approach is to define it from the questions an auditor could ask: who or what made the request, what was it allowed to do, what policy applied, and what happened.

For each interaction or tool call, the central layer should record the caller identity, whether a user or a service, along with the originating department, the target model or tool, and a timestamp. It should record the policy version evaluated and the decision: allow, redact, block, rate limit, or escalate. Redaction events and, for escalations, the approver and outcome belong in the same record. Use one format across departments. The point of consolidation is that assembling evidence no longer means reconciling five formats.

Retain legacy gateway records while the central layer comes online. Cutting over without that overlap creates a gap in activity records for the migrated workloads. Decide retention period and storage location deliberately, and apply them uniformly.

Record the regulatory baseline in the design as well. As of November 2026, the eCFR text of 164.312 lists audit controls at 164.312(b) and treats encryption and decryption as an addressable specification. Note the review date so that future changes to the Security Rule trigger a policy review.

Tradeoffs, ownership, and where a runtime layer fits

Consolidation puts one more hop in the path, so measure added latency per workload before cutover and agree on acceptable limits with each department. Interactive clinical assistants and batch coding jobs tolerate very different budgets. Availability also becomes a shared concern, since a single layer is a single dependency. Plan capacity and failure behavior explicitly, including whether each workload fails closed or open, and have the governance team approve those choices.

Expect friction over exceptions. Departments will argue that their workloads are special. A time-bound, owned exception process lets central policy stay consistent without forcing a hard stop on work that is already running.

Trussed is one example of a layer built for this role. It enforces policy in the execution path across models, agents, tools, MCP servers, and coding assistants: allow, redact, block, rate limit, and escalate for human approval, scoped to individual interactions and tool calls. Enforcement is at runtime, not reviewed after the fact, and the audit-ready evidence it generates is mapped to HIPAA. It deploys self-managed in the customer's cloud, with configurable retention and data residency, and runs in production with healthcare organizations. Whatever layer a health system selects, the evaluation criteria above apply: one policy model, one evidence schema, and a migration that never leaves a department unprotected.