Compliance architecture
Is your RAG pipeline HIPAA compliant?
If a covered entity embeds clinical documents into a vector database and a copilot answers questions from them, HIPAA does not pause because the access happened through an AI. The Minimum Necessary standard, access controls, and audit controls all apply to the retrieval step. Most RAG pipelines fail all three by default.
Gateco status, stated plainly
A Gateco Business Associate Agreement is on the roadmap and not yet available. The enforcement controls on this page work today. If your program requires a signed BAA before any PHI touches a vendor, check the current HIPAA status page first.
Where PHI leaks in a standard RAG pipeline
Embedding strips the ACLs your EHR, SharePoint, or document system enforced. The vector database then answers similarity queries with one service credential that can read everything. A billing employee, an intern, and an attending physician asking the same question all reach the same clinical content, and nothing writes an audit record HIPAA would recognize. The failure is architectural, so the fix is architectural: authorization has to move into the retrieval path itself.
HIPAA requirement to retrieval control
| HIPAA requirement | How standard RAG fails it | Retrieval-layer control |
|---|---|---|
| Minimum Necessary (45 CFR 164.502(b)) | Vector similarity returns the most relevant PHI to any authenticated employee. | Per-chunk policy evaluation: PHI-classified resources allowed only for roles with a clinical need. |
| Access control (45 CFR 164.312(a)) | The RAG service account can read the whole index; user identity is lost at retrieval. | Retrieval resolves a named principal synced from the IDP; policies bind to that identity per query. |
| Audit controls (45 CFR 164.312(b)) | No record of which PHI the AI accessed, for whom, or why. | Every retrieval decision logged: principal, resource, policy, allow or deny verdict, timestamp. |
| Person or entity authentication (45 CFR 164.312(d)) | One shared API key stands in for every user of the copilot. | Principals come from Okta, Entra ID, or SCIM provisioning; offboarding revokes retrieval on the next query. |
| Workforce clearance (45 CFR 164.308(a)(3)) | Role changes do not propagate to what the AI will retrieve. | Scheduled IDP sync updates groups and attributes; policy decisions follow the directory, not a stale copy. |
Minimum necessary as an enforceable policy
In Gateco, the Minimum Necessary standard becomes a policy object instead of a training-slide aspiration. This allow policy limits PHI-classified resources to clinical staff; everything else stays deny-by-default:
{
"name": "PHI access: clinical staff only",
"effect": "allow",
"rules": [{
"conditions": [
{"field": "resource.classification", "operator": "eq", "value": "phi"},
{"field": "principal.groups", "operator": "contains", "value": "clinical-staff"}
]
}]
}Preview the effect per person in the Access Simulator before enforcement, and evidence every decision from the audit trail.
When you do not need a retrieval authorization layer
If the corpus contains no PHI, or every user of the system is equally cleared for all of it, HIPAA's retrieval question reduces to transport and storage security you likely already have. And if your AI surface is entirely inside a platform that enforces source permissions natively, start with that platform's own controls. The architecture on this page matters when PHI and non-PHI share an index and users differ in clearance, which is the normal state of a hospital or payer knowledge base.