Hub-and-Spoke AI Operating Model for Health Systems

What the model is and where it fails

In most health systems, AI arrives through separate teams. Clinical groups, revenue cycle, research and administration each select their own models, tools and agents. PHI handling rules, approval practices and audit records then differ from one unit to the next, even when every unit means to follow the same policy.

A hub-and-spoke model splits responsibility. The hub owns policy, standards and evidence. Spokes own use cases, including their clinical or operational validation and day-to-day operation. The split fails when it is documented but not enforced. A policy document does not constrain what an agent does when it calls a tool that touches ePHI, and it does not show an auditor what happened afterward.

Accountability also does not move with the work. HIPAA obligations attach to the covered entity or business associate, which must ensure workforce compliance. Spoke autonomy over use cases does not transfer that accountability, so the hub has to set controls that every spoke inherits.

Step 1: Divide responsibilities between hub and spokes

Start with an inventory of AI use cases across all four domains, then assign each responsibility to one owner. The NIST AI RMF is voluntary, but its four functions (govern, map, measure, manage) give a useful structure. A practical mapping places govern at the hub, and places most map, measure and manage activity with the spokes for their own use cases. The framework does not prescribe this split. It is a design choice.

The framework also names distinct actor types, including operators, domain experts, evaluators and auditors, compliance experts and organizational management. Assign each to the hub or a spoke explicitly. Where practical, keep evidence review with people who do not operate the use cases being reviewed.

• Policy: Hub writes enterprise policy, including PHI handling rules. Spokes propose domain additions.
• Standards and tooling: Hub maintains approved models, agents, tools and MCP servers. Spokes request additions.
• Use cases: Spokes own selection, design, validation and operation. Hub holds the inventory.
• Identity and access: Hub defines how AI callers are registered and what access rights they can hold. Spokes request rights per use case.
• Evidence: Hub defines the event set, retention and review. Spokes supply context and respond to findings.

Step 2: Decide what is centralized and what is delegated

Centralize decisions where inconsistency creates regulatory exposure or cannot be reversed. These include which data classes may reach which models, how PHI is redacted or blocked, which models and tools are approved, which action types require human approval, and the evidence schema and retention. A decision belongs at the hub if two spokes making different choices would produce different answers for the same auditor.

Delegate decisions that depend on domain knowledge: which problems to solve, how workflows are designed, what clinical or financial validation is needed, and who in the domain is qualified to approve an escalated action. A workable rule is that spokes may tighten hub policy but not loosen it.

Handle exceptions through the hub with a named owner and an expiry date. An exception that has no end date becomes a second policy.

Human approval needs two definitions. The hub specifies which classes of action must escalate, for example a tool call that writes to a system containing ePHI. The spoke names the approvers who can make that call and keeps them available. If approvers are not defined, escalation becomes a bottleneck or is quietly bypassed.

Step 4: Specify the evidence the model must produce

The audit controls standard, 164.312(b), requires hardware, software, or procedural mechanisms that record and examine activity in information systems that contain or use ePHI. Both verbs matter. Evidence must be captured, and it must be reviewable by someone other than the team that generated it. The text does not prescribe log fields or retention periods, so the hub has to set them and document the reasoning.

A reasonable event set includes requests, tool calls, policy decisions, redactions, blocks, approvals and exceptions. Record these centrally rather than per spoke, so that one query can answer questions across all domains. Keep a register that maps each control to the citation it satisfies, such as 164.312(a)(1), 164.312(b) or an AI RMF function. Test the controls on a schedule and keep the results.

When enforcement and evidence come from the same mechanism, the record reflects what was actually allowed and done. Trussed generates audit-ready evidence from enforcement, mapped to HIPAA and NIST, and runs in production with healthcare organizations. Evidence from enforcement covers individual interactions and tool calls. It does not replace the hub's own review process or its control register.

Step 5: Sequence the rollout

Phase the work so that each stage produces something usable. Starting with the paths that carry the most PHI limits exposure while the model is still being tuned. Stage-based maturity thinking, where use cases move from emerging to developing, can inform which spokes onboard first.

• Phase 1: Inventory and roles: List AI use cases, models, agents, tools and MCP servers across all domains. Name hub and spoke owners and approvers.
• Phase 2: Baseline policy and identities: Write enterprise policy, register AI callers, and set the evidence event set and retention.
• Phase 3: Enforce on priority paths: Apply runtime enforcement to the highest PHI-exposure use cases first. Define escalation routes and the exception process.
• Phase 4: Extend and review: Onboard remaining spokes, run evidence review separate from operators, and test controls against the citation register.