Shared AI Platform Services for Health Systems: What Every Department Should Inherit

Why departments should not each build their own AI stack

Clinical, revenue cycle, research, IT and administrative teams adopt models, agents, tools and coding assistants on their own schedules. Each team builds its own integrations, its own handling of PHI and its own access rules. The result is duplicated work and uneven protection. When an auditor asks what a given AI system was permitted to do and what it actually did, there is no single place to look.

Federal agency architectures describe the alternative: a reusable layer of shared AI infrastructure, such as secure compute, model hosting, evaluation testbeds and orchestration tools, so that teams do not reinvent it for every project. Federal technical reference architectures likewise tell application developers to use common platform services where possible instead of single-use software. These are government settings, not health system reference architectures, but the pattern transfers. A shared platform is a set of services with defined defaults, not a single product that every department must route all work through.

The working question for an enterprise architect is which services must be identical across departments to be defensible, and which can vary without risk. Shared responsibility for AI safety, spanning clinical, technical and administrative governance, points the same way: central governance for the common controls, local accountability for the use cases.

What to centralize and what departments can own

A useful test is whether inconsistency creates compliance exposure. Services that touch access, PHI, enforcement and evidence should be centralized. Services that carry domain knowledge should stay with the department. The split below is a practitioner recommendation, not a regulatory requirement.

• Centralize: model access: A single approved route to models, so usage is visible and policy applies regardless of which team calls them.
• Centralize: identity and access: Distinct identities and access rights for users, agents and tools, managed once.
• Centralize: PHI handling and runtime policy enforcement: Shared rules applied to each interaction and tool call, not rebuilt per application.
• Centralize: human approval escalation, code provenance and audit-ready evidence: Common approval routing, origin and licence context for code, and one evidence record.
• Department-owned: use-case logic, prompts and workflows: Teams design what the AI does within the platform's boundaries.
• Department-owned: evaluation cases and clinical validation: Departments bring their own test content to a shared testbed and decide fitness for their use.

Identity, PHI handling and audit controls under HIPAA

The HIPAA Security Rule technical safeguards at 45 CFR 164.312, current as of November 2026, translate into concrete platform requirements. The access control standard requires technical policies and procedures that allow access to ePHI systems only to persons or software programs that have been granted access rights. Because the text refers to software programs, a reasonable architectural reading is that agents and tools need their own identities and access rights, not a shared service account that hides who or what acted.

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. It is technology-neutral. It does not prescribe log fields, retention periods or AI-specific records, so the evidence schema is an architectural decision. A shared platform lets the organization make that decision once, justify it with a documented risk analysis, and apply it to every department.

The same section also addresses integrity and includes addressable specifications for authenticating ePHI and for encryption. It follows that the evidence record should itself be protected from improper alteration. Evidence a department can edit is weak evidence.

On the evidence side, Trussed generates audit-ready evidence as a by-product of enforcement, mapped to HIPAA among other frameworks, with configurable retention and data residency. Because the record comes from the enforcement point, it reflects what the policy allowed, redacted, blocked or escalated, not a reconstruction afterward.

A phased sequence for scoping the platform

No standard prescribes a phasing, so the sequence below is a recommendation based on dependencies. Start with an inventory of AI use cases and define roles, since governance depends on knowing what exists and who is accountable. Document the risk analysis that sets audit scope.

Next, establish the identity and audit baseline: distinct identities, one evidence record and integrity protection. Then add runtime enforcement and human approval escalation, starting with the highest-risk PHI workflows. Finally, expand to additional departments, add shared evaluation testbeds, and extend code provenance to coding assistants.

One caveat applies to vendor products. Federal certification requirements for intervention risk management on predictive decision support tools apply to certified health IT developers, not to a health system's internal platform. Ask those vendors how they meet them, and do not assume they bind your own platform.

• Phase 1: inventory use cases, define roles, document the risk analysis.
• Phase 2: identity and audit baseline with integrity-protected evidence.
• Phase 3: runtime enforcement and human approval escalation for PHI workflows.
• Phase 4: expand departments, shared evaluation testbeds and code provenance.