The Compliance Moat
Architecture as a Control Layer, Not a Compliance Conclusion
Compliance in the cloud is procedural. It rests on Business Associate Agreements, subprocessor audits, vendor access controls, and contractual representations about what a third party will do with PHI that has already left the covered entity's physical control. These procedures are enforceable, but they are insufficient as the sole governance mechanism for continuous AI inference on raw clinical data — because the exposure is created at the moment the data crosses the boundary, and no agreement undoes that.
What the sovereign enclave contributes is a strong physical and technical control: the data has no configured path out of the building, the compute is tenant-owned, and the audit trail sits on hardware under the practice's custody. That control is durable in a way a contractual representation is not, because degrading it requires a physical or configuration act performed inside the practice's own boundary rather than a unilateral change to a vendor's policy. It is not, however, a compliance conclusion. HIPAA compliance is a program obligation assessed against the administrative, physical, and technical safeguards of the Security Rule, and no siting decision discharges it.
This specification therefore positions zero egress as one layer within a defense-in-depth HIPAA Security Architecture pursuant to 45 CFR § 164.312, and requires that the remaining layers be implemented locally rather than assumed. The practical consequence is that a conforming deployment carries the same safeguard obligations a well-run cloud tenancy would, minus the third-party processor surface.
- Access control (§ 164.312(a)(1)). Role-based access control over every inference endpoint, MCP tool, and record interface, with unique per-user identification, automatic session termination, and emergency-access procedures. Authorization decisions are externalized to the Policy & Authorization Engine and default to deny.
- Hardware root of trust. Measured boot anchored in a TPM 2.0 or equivalent silicon root of trust, with attestation of firmware, bootloader, kernel, and GPU driver state. An enclave that cannot attest its own software stack cannot substantiate a claim about what executed on the data.
- Encryption at rest (§ 164.312(a)(2)(iv)). AES-256 full-disk and volume-level encryption for all local persistent storage — generated artifacts, model weights, graph database state, and audit logs — with keys held in tenant-controlled hardware and escrowed under the practice's own custody, never the landlord's.
- Encryption in transit (§ 164.312(e)(1)). Mutually authenticated TLS across every intra-enclave hop, including sensor-to-ingestion, agent-to-policy-engine, and policy-engine-to-MCP paths. Local does not mean cleartext; the LAN is inside the boundary but is not inside the trust boundary.
- Audit controls (§ 164.312(b)). Append-only, tamper-evident logging of inference sessions, tool invocations, authorization decisions, physical access events, and artifact writes, retained for the period required by the practice's retention policy and reviewable by an examiner without vendor cooperation.
- Integrity and authentication (§ 164.312(c), (d)). Cryptographic integrity verification of stored clinical artifacts and model weights, plus authentication of every person and workload asserting an identity to the enclave.
- Administrative safeguards (§ 164.308). A documented risk analysis covering the enclave, workforce training on ambient capture, a sanction policy, contingency and disaster-recovery plans for tenant-owned hardware, and periodic technical evaluation. These are unaffected by locality and remain the covered entity's obligation.
Stated plainly: the architecture removes a category of risk that contracts can only manage, and it does so verifiably. It does not remove the Security Rule. A deployment that treats physical custody as a substitute for access control, encryption, and audit logging has relocated its data without securing it.
HIPAA and the Zero-Egress Boundary
Under HIPAA, a covered entity remains accountable for Protected Health Information wherever it is processed. The AI-Native Medical Office Building addresses that accountability by keeping the processing inside the entity's own custody rather than by extending contractual assurances to a remote processor. Audio, video, and EHR telemetry are processed locally on tenant-owned hardware; raw health data never leaves the physical building envelope, which also removes cloud egress tariffs on high-volume image and video pipelines.
The Business Associate consequence is specific and worth stating precisely, because the general version of this claim is wrong. Zero-egress architecture eliminates third-party hyperscaler data-processor Business Associate Agreements and the cloud subprocessor chains beneath them, minimizing the practice's BAA exposure surface strictly to the direct local infrastructure operators it selects. It does not eliminate Business Associate Agreements as a category. Any party that creates, receives, maintains, or transmits PHI on the practice's behalf — a managed-services provider administering the enclave, an integrator with privileged access to the orchestration layer, a landlord technician whose maintenance role touches systems processing PHI, or the vendor of a local software component with support access — remains a business associate and requires an agreement. The gain is that this set is small, locally situated, individually negotiated, and directly auditable, rather than a multi-tier subprocessor tree disclosed by reference in a vendor's public documentation.
Persistence deserves the same precision. Ambient capture is processed in volatile memory and released on session end, which minimizes the persistence of raw encounter media — the largest and least useful liability in the pipeline. But the system's outputs are the point of the system, and those outputs persist: SOAP notes, finalized DICOM reports, triage scores, structured observations, and the audit records proving what occurred all become retained Protected Health Information the moment they are written to local storage or ingested into the EHR. Those artifacts are subject to the full Security Rule safeguard set enumerated above, to the practice's retention schedule, to breach-notification obligations, and to discovery. The correct claim is minimization of persistent raw media alongside deliberate, secured retention of generated clinical records — not the absence of persistent PHI.
STARK Law & Anti-Kickback Compliance
Providing shared computing infrastructure, software tools, or below-market technological benefits to medical practices introduces risk under federal healthcare law. If a landlord or affiliated health system provides high-performance GPU compute, AI software, or specialized building infrastructure to a physician practice at below-market rates, regulators may classify the discount as illegal remuneration intended to induce patient referrals under the Physician Self-Referral Law (STARK) or the Anti-Kickback Statute.
Fair Market Value is a necessary condition of a defensible arrangement, not a safe harbor that compliance can rest on. Landlord-tenant compute arrangements under this specification are structured at Fair Market Value established by independent third-party appraisal, and must satisfy the further requirements that the rental-of-office-space and equipment-rental exceptions impose under 42 CFR § 411.357: a written agreement signed by the parties, a term of at least one year, a description of the premises and equipment covered, aggregate space and equipment not exceeding what is reasonable and necessary for the tenant's legitimate business purposes, and compensation set in advance that does not vary with — and is not determined in any manner that takes into account — the volume or value of referrals or other business generated between the parties.
Two conditions carry particular weight in this architecture. First, commercial reasonableness: the arrangement must make sense as a business transaction on its own terms even if no referrals passed between the parties, which for a compute enclave means the capacity provisioned bears a demonstrable relationship to the tenant's clinical throughput rather than to its referral footprint. Second, strict independence from referrals: neither $/kW/month pricing, capacity allocation, tiering, escalation, nor any discount or service credit may be structured or adjusted by reference to internal or external referral volumes. Percentage-of-revenue and per-click compute pricing are excluded for this reason.
The pricing model must be validated by an independent valuation firm against prevailing market rates for comparable high-density colocation and specialized medical space, with the appraisal documented contemporaneously and refreshed on a defined cycle rather than performed once at signing. The Tripartite Ownership Model supports the analysis by keeping the benefit structurally separable — the tenant owns the silicon outright and the landlord supplies the shell and base-building systems at appraised value — so that no compute benefit flows to a referring physician below market value. Where a landlord is affiliated with a health system or any potential referral source, the arrangement warrants heightened scrutiny and independent legal review; the Anti-Kickback Statute turns on intent and is not satisfied by valuation mechanics alone. Nothing in this specification is legal advice, and structures should be reviewed by qualified healthcare counsel against the parties' specific facts.
The Institutional Firewall
By establishing legal and physical separation across the three tiers — property ownership, compute hardware custody, and clinical intelligence operations — the governance model gives each safeguard a single accountable owner and writes the separation into the physical asset rather than into a service description. The firewall is what makes the safeguard set above auditable: an examiner can determine who holds which key, who can enter which room, and who can invoke which tool, without depending on a vendor's attestation.
No third-party model access to clinical inference. No hyperscaler data-processor Business Associate Agreement and no cloud subprocessor chain governing continuous multimodal PHI processing — the remaining agreements run only to the local operators the practice selects and audits directly. No pathway for patient data into a vendor's training corpus. The audit trail lives on the practice's hardware, under the practice's control, accessible only to the practice — and to the regulators it chooses to grant access.
Requirements formalizing this section
The narrative above is non-normative. The clauses below state the same architecture as testable requirements, and a conformance claim is evaluated against them rather than against the prose.
- ANM-10.1MUST · Class A, B
A conforming deployment MUST be able to demonstrate the absence of an egress path for inference payloads to an examiner on site, without relying on an attestation issued by a third party.
- ANM-10.2MUST · Class A, B
A conforming deployment MUST maintain records of physical access, tool invocation, model and software version history, and boundary configuration changes, sufficient to reconstruct the operating state of the enclave at any past point within its retention period.
- ANM-10.3MUST · Class A, B
Audit records in a conforming deployment MUST be append-only and MUST NOT be alterable by the software integrator.
- ANM-10.4MUST · Class A, B
A conforming deployment MUST identify the specific statutory or regulatory obligations its architecture is intended to satisfy, and MUST map each to the clauses of this specification relied upon.
- ANM-10.5SHOULD · Class A, B
A conforming deployment SHOULD re-verify the acoustic performance required by Chapter 5 and the path enumeration required by ANM-2.2 after any construction, reconfiguration, or hardware change affecting the enclave.
- ANM-10.6MUST · Class A, B, C
A conforming deployment MUST publish the date of its most recent conformance self-assessment alongside any conformance claim it makes.