07/19/2026
BUILDLAB
13 min readConverting a HIPAA-Compliant Organization to the Microsoft Medallion Architecture, Plus AI
Generic Medallion Architecture guides are built for retail and finance data teams, not PHI. Here is the layer-by-layer HIPAA compliance map for Bronze, Silver, Gold — and the AI risks that come after.
Most Medallion Architecture migration guides were written by data engineers who think about retail transactions, ad clicks, or loan applications. They talk about schema drift, deduplication, and query performance. What they don’t talk about is what happens when the data flowing through your Bronze layer is a patient’s diagnosis, a claims record, or a clinician’s note. If you run a clinic, health system, or health-tech company and you’re moving to a Microsoft Fabric or Azure Databricks Medallion Architecture, that omission matters. A mistake at any layer of your lakehouse isn’t a data-quality bug you fix in the next sprint. It’s a potential HIPAA Security Rule violation, with breach notification obligations, OCR exposure, and reputational damage attached to it.
The Risk Generic Guides Don’t Mention
The Medallion pattern is genuinely good architecture. Bronze, Silver, and Gold layers give you a clean way to separate raw ingestion from validated, business-ready data, and Microsoft has built real tooling around it in Fabric’s OneLake and in Azure Databricks. The problem is that every off-the-shelf tutorial assumes the data has no regulatory weight. Copy a generic ingestion pipeline into a healthcare environment and you’ll likely land protected health information (PHI) in a Bronze layer with broad engineering access, no immutable audit trail, and no plan for who gets to see it downstream. None of that shows up as a bug in your dashboards. It shows up, if at all, in an audit or a breach investigation — which is exactly why it needs to be designed out from day one, not patched in later.
A Plain-English Primer on the HIPAA Security Rule Requirements That Constrain Your Architecture
You don’t need to memorize the regulatory text to build this correctly, but you do need to understand what the HIPAA Security Rule actually requires of any system that creates, receives, maintains, or transmits electronic PHI (ePHI). These requirements aren’t abstract legal language — they translate directly into architecture decisions about identity, logging, encryption, and vendor contracts. Four of them are the Rule’s core technical safeguards; a fifth, related requirement sits alongside them at the organizational level.
- Access control: every user and system process touching PHI needs a unique identifier so activity can be traced to a person, not a shared account. Systems should also enforce automatic logoff after inactivity and support encryption/decryption of ePHI, including data encrypted at rest.
- Audit controls: you need hardware, software, or procedural mechanisms that record and examine activity in any system containing or using ePHI — who accessed what, when, and (ideally) why.
- Integrity controls: mechanisms to confirm that ePHI has not been altered or destroyed in an unauthorized way, which matters enormously once you start transforming raw data through Silver and Gold pipelines.
- Transmission security: ePHI moving across a network — between source systems and Bronze, between layers, out to a BI tool or an AI service — needs protection against unauthorized interception, typically via encryption in transit.
Alongside those four technical safeguards sits a distinct, organization-level requirement: the Business Associate Agreement (BAA). Any vendor that creates, receives, maintains, or transmits PHI on your behalf is a business associate, and HIPAA requires a signed BAA with that vendor before PHI touches their systems. It’s not a technical control you configure — it’s a contract your organization signs — but it constrains your architecture just as directly, because a service without BAA coverage is a service PHI cannot legally reach.
That BAA point deserves emphasis because it’s the one organizations most often get wrong in a cloud migration. Microsoft signs BAAs covering many Azure and Microsoft 365 services, but a BAA is scoped to specific, named services — it is not a blanket promise that covers every product Microsoft ships, including new ones added after the agreement was signed. Before any PHI lands in Fabric, a Databricks workspace, Azure OpenAI, or a Copilot integration, your compliance and IT teams need to confirm, directly against Microsoft’s current documentation, that the specific service in scope is covered under your organization’s BAA. Do this per service, and do it again whenever you add a new capability — don’t assume general cloud compliance certifications (SOC 2, HITRUST, ISO 27001) or a BAA covering one Azure service automatically extends to another.
The Medallion Architecture, in Plain English
Strip away the vendor branding and the Medallion Architecture is a simple idea: move data through three progressively refined layers instead of dumping everything into one undifferentiated pool. Bronze holds raw data exactly as it arrived from source systems — immutable, unfiltered, as-ingested. Silver takes that raw data and cleans it: deduplicating records, validating formats, resolving conflicts, and conforming data from different source systems into consistent structures. Gold takes Silver’s clean, trustworthy data and curates it further into business-ready datasets — the aggregated tables that feed BI dashboards, reports, and increasingly, AI and machine learning workloads. This pattern is commonly implemented via Lakehouse items on Microsoft Fabric’s OneLake, and it’s equally at home in an Azure Databricks environment. It’s a good pattern. The question this article answers is what has to change about it when the data in question is PHI.
A Layer-by-Layer HIPAA Compliance Map
Compliance can’t be bolted onto a Medallion Architecture after the fact as a single access-control layer sitting on top. Each layer carries a different risk profile and needs its own specific controls.
Bronze: Narrowest Access, Strongest Audit Trail
Bronze is where PHI exposure is broadest and least filtered — it’s raw EHR exports, billing feeds, scheduling data, and device telemetry landing exactly as the source system sent it, identifiers and all. That makes Bronze the layer that most needs encryption at rest and in transit for every file and stream landing there, an immutable, tamper-evident audit trail of every ingestion event (what arrived, from where, when, and who or what triggered it), and access restricted to the smallest possible set of service accounts and engineers. Counterintuitively, many organizations do the opposite: they give broad engineering access to Bronze because “it’s just raw data for pipeline development,” not realizing that raw, identifiable PHI sitting in a data lake is exactly the kind of exposure regulators and attackers both look for.
Silver: Where De-Identification and Minimum Necessary Get Enforced
Silver is where raw PHI is typically pseudonymized as it’s cleaned, validated, and conformed across source systems — reconciling a patient record that shows up differently in your EHR, billing system, and scheduling platform into one trustworthy representation, without carrying every raw identifier forward unnecessarily. This is also where minimum-necessary logic belongs: not every downstream consumer needs the full identified record, so Silver pipelines should be designed to strip or mask fields that aren’t required for a given use case before that data moves any further. Data lineage and quality validation matter here for a compliance reason as much as an engineering one — if you can’t show exactly how a Gold-layer field traces back to its Bronze source, you can’t demonstrate integrity controls when someone asks whether the data was altered improperly along the way.
Gold: Curated for BI and AI, Gated by Role
Gold is what your analysts, dashboards, and AI tools actually query, which makes it the layer with the highest volume of access and the widest audience — clinicians, finance, operations, data scientists, and now AI agents. Role-based access control needs to be granular here, not just “clinical staff vs. everyone else,” and any dataset destined for AI model training or fine-tuning needs its own de-identification review distinct from what BI dashboards require, because model training data can persist and propagate in ways a dashboard query doesn’t. Just as important: log and monitor who and what queries Gold. That “what” matters more than it used to, because increasingly the thing querying Gold isn’t a person clicking through a report — it’s a Copilot agent or an AI service acting on a person’s behalf, and that access needs the same audit trail as a human user’s.
Where AI Adds a New Layer of Risk on Top of a Compliant Lakehouse
A well-built, compliant Medallion Architecture solves the data platform problem. It does not automatically solve the AI problem, because AI introduces failure modes that don’t exist in a traditional BI stack. Layering Copilot, Azure OpenAI, or custom ML models on top of Gold-layer clinical data means confronting several new risks directly.
- Prompt leakage: a Copilot or chatbot querying Gold-layer data can surface PHI directly in a generated response, effectively creating a new, unlogged disclosure channel if that response isn’t treated with the same access controls as the underlying data.
- Training and fine-tuning exposure: PHI that ends up in a model’s training or fine-tuning dataset can be far harder to fully remove or account for than PHI sitting in a governed table — treat any training pipeline as a new data flow that needs its own compliance review.
- BAA coverage for the AI service itself: before any PHI reaches Azure OpenAI, a Copilot surface, or a third-party AI layer, confirm — in writing, against current Microsoft documentation — that the specific service is covered under your organization’s BAA. “Copilot” spans several distinct products (Microsoft 365 Copilot, Copilot in Fabric or Power BI, a custom Copilot Studio agent) with different data-handling terms — identify exactly which one you’re connecting before you verify coverage. General platform compliance does not imply AI-service compliance.
- Audit logging of AI access: every AI query that touches PHI, whether initiated by a person through a chat interface or by an autonomous agent, needs the same audit logging as any human access to that data. If you can’t produce a log answering “what did the AI see, and when,” you have a gap.
- Human-in-the-loop for consequential outputs: any AI output that could influence a clinical decision, a coverage determination, or a billing outcome needs a human reviewer before it’s acted on. This isn’t a HIPAA Security or Privacy Rule requirement specifically — it’s typically driven by state AI and utilization-review laws, payer or CMS rules, FDA regulation of clinical decision support, or standard-of-care exposure. Confirm with compliance counsel which regime applies to your specific use case.
- Re-identification risk: data that looks safely aggregated or de-identified in isolation can sometimes be re-identified when an AI system combines it with other datasets. This risk is real and growing as models get better at pattern-matching across sources, and it deserves ongoing attention, not a one-time de-identification checkbox.
None of this means AI and PHI are incompatible — plenty of organizations run compliant AI workloads on clinical data today. It means the compliance work doesn’t end when your Gold layer is built. It extends into every AI service that touches that layer, and it has to be verified before the first PHI-bearing prompt runs, not after.
A Phased Roadmap: Compliance Before Copilot
The organizations that get this right resist the temptation to build the AI use case first and retrofit governance later. A realistic, sequenced roadmap looks like this.
- Assess: inventory every source system touching PHI, map current BAA coverage against every cloud service you intend to use, and document existing access control and audit gaps before writing a single ingestion pipeline.
- Build compliant Bronze ingestion: stand up encrypted, access-restricted, audit-logged raw ingestion first, proving the immutable audit trail works before any transformation logic is layered on top.
- Build the Silver de-identification and conformance pipeline: implement minimum-necessary logic, pseudonymization, and cross-source conformance, with lineage tracking that lets you trace any Gold-layer field back to its Bronze origin.
- Build the Gold AI-ready curated layer: implement granular role-based access control, a separate de-identification pass for any AI-training-bound data, and query monitoring before connecting any BI tool or AI service.
- Stand up governance and monitoring as an ongoing layer: continuous audit review, periodic BAA re-verification as services change, and a standing process for approving new AI use cases against this framework — not a one-time sign-off.
Each phase should produce evidence, not just working software: audit logs that demonstrate the control is functioning, documentation of BAA coverage for every service in the chain, and a de-identification methodology you can explain to an auditor or a regulator on request.
Common Mistakes We See
The failure patterns are consistent across organizations, which is exactly why they’re worth naming directly.
- Rushing straight to an AI pilot on ungoverned data because the AI use case is the exciting part and the compliance foundation feels like it can wait.
- Assuming a vendor’s general compliance certifications (SOC 2, HITRUST, ISO 27001) or an existing BAA for one service automatically extends to every other service in that vendor’s catalog, including newly launched AI products.
- Building Bronze and Silver with real rigor, then connecting a BI tool or AI assistant to Gold with no additional audit logging, treating the AI layer as exempt from the same controls that govern every other access path.
- Skipping de-identification before Gold because the data “already went through Silver,” without confirming that Silver’s de-identification methodology actually meets the intended use case at Gold, including AI training.
- Treating the entire migration as a one-time project with a go-live date, rather than an ongoing governance function that has to keep pace with new data sources, new AI features, and new BAA terms.
A Governance Checklist Worth Running Before Go-Live
Before any PHI-bearing Medallion Architecture goes into production — and before any AI service connects to it — these are the control categories that should have a documented, verifiable answer, not just a verbal assurance.
Generic Medallion Rollout vs. HIPAA-Ready Medallion Rollout
Building This Right the First Time
None of this is a reason to avoid the Medallion Architecture or to avoid AI. It’s a reason to sequence the work correctly and treat the compliance layer as part of the architecture, not an afterthought bolted on before an audit. Organizations that get real value out of Copilot, Azure OpenAI, or custom ML on clinical data are, without exception, the ones that built a disciplined Bronze-Silver-Gold foundation first and confirmed BAA coverage service by service before any PHI touched an AI endpoint. That’s the difference between a modernization project that survives its first compliance review and one that becomes the subject of it.
This is exactly the kind of work a technology consulting partner earns its keep on — not by selling a pre-built AI dashboard, but by helping map your specific source systems, confirm BAA coverage against your actual Microsoft agreement, and sequence a Bronze-to-Gold build that a compliance officer can sign off on with confidence. BuildLab works with HIPAA-covered organizations on exactly this kind of data platform and AI readiness planning, starting with an honest assessment of where the current environment stands before any migration work begins.
