Build vs. Buy: AI-Ready Context for Healthcare

Emily Winks

Data Governance Expert

Updated:07/30/2026

Published:07/30/2026

15 min read

See Context Agents Live Get the Context Layer Ebook

Key takeaways

Predictive AI adoption in US hospitals rose from 66% to 71% between 2023 and 2024, per ONC.
A Business Associate Agreement extends HIPAA obligations to a vendor; a custom build carries them alone, indefinitely.
Public ChatGPT and Gemini do not sign BAAs, so entering identifiable PHI into them is a HIPAA violation either way.
Teams building their own de-identification pipeline commonly staff 2+ FTEs just to keep it audit-ready.

Should healthcare organizations build or buy AI-ready context infrastructure?

For most healthcare organizations, buying a governed context layer and building the clinical workflows on top of it is the better path, because a Business Associate Agreement (BAA) contractually extends HIPAA obligations to a vendor, while a custom build leaves the covered entity carrying those obligations alone. The exceptions are organizations like academic research centers or payers, where owning the compliance-adjacent infrastructure is tied to institutional expertise or a lower direct-clinical-risk profile. This guide compares both paths against the mechanics unique to healthcare: minimum-necessary retrieval, de-identification method choice, BAA subcontractor chains, and mandatory audit trails.

What makes the healthcare decision different:

Minimum-necessary retrieval: HIPAA requires enforcement at the point an AI agent queries data, not just at the database layer
De-identification method choice: Safe Harbor or Expert Determination, built or enforced, either way the org still owns the choice
BAA subcontractor chains: a signed BAA extends liability rules to every vendor and subcontractor touching PHI
Mandatory audit trails: every AI interaction with PHI needs a retrievable log of what, when, and by whom

Is your data estate AI-agent ready?

Assess Your Readiness

Build vs. buy for healthcare AI context infrastructure is a liability decision before a cost one. A Business Associate Agreement (BAA) contractually extends HIPAA compliance obligations to a vendor; a custom build carries those obligations alone, indefinitely. Predictive AI adoption in US hospitals rose from 66% to 71% between 2023 and 2024, per the Office of the National Coordinator for Health IT, so this decision is no longer theoretical.

Minimum-necessary access enforced at retrieval time, per HHS de-identification guidance
De-identification method: Safe Harbor’s 18 identifiers or Expert Determination’s risk assessment
BAA subcontractor chains under 45 CFR § 164.308(b)(4)
Mandatory, retrievable audit trails for every AI interaction touching PHI

Dimension	Build in-house	Buy a governed context layer
What it is	Custom-built PHI-scoping and audit infrastructure, owned end-to-end	A layer enforcing PHI scoping, de-identification policy, and audit trails as a service
Who carries HIPAA liability	The covered entity, alone, indefinitely	Shared through a BAA with the vendor and its subcontractors
Time to a compliant first deployment	Months of building before audit-ready	Controls and logging exist from day one
De-identification approach	Team builds and maintains the pipeline	Vendor enforces it; org still chooses the method
Audit trail for PHI-touching AI	Built and maintained internally	Built in; decision traces by default
Multi-agent PHI-rule consistency	Re-implemented per agent, each a new audit surface	Defined once, enforced everywhere
Best for	Proprietary clinical or research context, such as an IRB-tied warehouse	Multiple clinical AI use cases across EHRs and agent platforms

Build vs. buy for healthcare AI context: what makes this decision different?

Healthcare’s build-vs-buy calculus is shaped by regulatory mechanics a generic enterprise never has to weigh. Outside healthcare, the decision is mostly engineering headcount and time to value. Inside healthcare, three constraints change the math.

First, HIPAA’s minimum-necessary standard requires an AI tool to retrieve only the PHI strictly required, and per HHS guidance, enforcement happens at retrieval, not the database layer. Second, a BAA is a legal liability-transfer mechanism: under 45 CFR § 164.308(b)(4), a subcontractor processing PHI must also be bound by a BAA, a chain that doesn’t exist for an internal build. Third, public AI tools do not sign BAAs at all.

The decision that looks like “build vs. buy a product” elsewhere in software becomes “who legally owns the compliance risk” in healthcare specifically, the single most useful lens for evaluating either path, and one that applies just as directly to context layer for financial services teams under a different regulatory stack.

HIPAA liability chain comparing build in-house, where a covered entity carries liability alone, versus buying with a signed Business Associate Agreement that extends liability to vendors and subcontractors under 45 CFR Section 164.308(b)(4)

What does building healthcare AI context infrastructure in-house actually involve?

Building means designing and permanently operating four systems: PHI classification, a de-identification pipeline, retrieval-time access controls, and audit logging, evaluated in context layer evaluation criteria. None of it is one-time work; clinical terminology, drug databases, and HIPAA’s interpretations keep changing, so the pipeline needs ongoing attention.

Teams with three or more data engineers most commonly attempt this, and the sentiment is consistent: it works, but never stops being maintenance. One clinical informatics lead described building a pipeline after vendor quotes ran past $400,000 a year, then discovering it still needed two full-time engineers to keep audit-ready. Teams scoping this should start with DIY context layer before committing to headcount.

UCSF shows build working well: it built its own de-identified clinical data warehouse to align de-identification with its own IRB processes, the kind of question also covered in context layer ownership: data teams or AI teams.

Core components of an in-house build

PHI classification and tagging: labeling PHI-bearing assets before any pipeline touches them
De-identification pipeline: Safe Harbor’s 18-identifier removal, or Expert Determination’s risk assessment, built internally
Retrieval-time access controls: enforcing minimum-necessary the moment an agent queries data
Audit logging infrastructure: a queryable, retained log of every AI interaction touching PHI

The pipeline is never done the way a shipped feature is done. It has to stay audit-ready every day it exists, a permanent staffing line, not a milestone, echoing why AI agents need an enterprise context layer for any regulated estate.

What does buying a governed context layer for healthcare provide?

Buying this infrastructure is a different decision than buying a finished clinical AI product. Most content ranking for these queries today addresses whether to build or buy the AI application itself: developer guides to clinical agents, care-navigation platforms, voice tools. Buying the context layer for AI agents underneath those applications is narrower and earlier: PHI-scoping, de-identification, and audit requirements defined once by the vendor and reused across every clinical AI system.

CareQuest Institute for Oral Health illustrates the pattern. Rather than building from scratch, the nonprofit partnered with PwC to build a Health Data Exchange on Microsoft Azure, buying the compliant cloud foundation and building its own oral-health business context model on top. Cedars-Sinai bought Microsoft Fabric while building its own semantic models across clinical, administrative, and research silos, the same problem covered in context layer for data governance teams.

Core components of a bought platform

PHI-scoped retrieval: access controls enforcing minimum-necessary the moment an agent queries data
De-identification policy enforcement: the org chooses the method; the platform enforces it across every source
Audit-traceable decision trails: every output linked back to its source, policy, and authorizing role
Portability across agents: PHI rules defined once, not re-implemented per tool, the model-agnostic principle

Buying does not remove an organization’s compliance responsibility. It changes who else is on the hook when something goes wrong, and removes the burden of re-engineering PHI scoping for every new use case, whether that spans one system or the kind of multi-cloud estate spanning an EHR and a separate payer system.

Build vs. buy for healthcare AI context: head-to-head on liability, not just cost

The sharpest differences show up in who bears risk, not sticker price, the same distinction separating context layer vs. semantic layer and data catalog vs. context layer comparisons, scoped here to build-or-buy.

Dimension	Build in-house	Buy a governed context layer
HIPAA liability ownership	Covered entity carries it alone, indefinitely	Shared via BAA with vendor and subcontractor chain (45 CFR § 164.308(b)(4))
Engineering and maintenance burden	Two or more engineers commonly cited for pipeline upkeep alone	Shifts to configuration and adoption
Vendor and subcontractor risk exposure	None to a vendor, but full exposure to build quality	Requires vetting the vendor’s own BAA chain
Multi-agent consistency	Re-implemented per agent, each a new compliance surface	Defined once, enforced across every agent

Consider a medical center running Epic alongside three clinical AI pilots: ambient documentation, prior authorization, and care coordination. Each pilot re-implementing its own PHI-scoping logic means three audit surfaces instead of one, the failure agent context layer vs. knowledge base warns against. A governed agent context layer collapses that to one set of rules every pilot inherits, distinct from plain RAG retrieval alone.

The AI Context Stack

See where build and buy decisions sit inside the four-layer stack behind any enterprise AI agent, and where compliance risk actually accumulates.

Get the Brief

When does building your own healthcare AI context infrastructure make sense?

Build makes sense when an organization’s clinical or research context is itself proprietary expertise, not a generic compliance obligation. UCSF’s research warehouse fits this: owning de-identification let it align precisely with its own IRB processes. Oscar Health, a technology-driven insurer, favors building more internally, reflecting stronger engineering capacity and lower direct clinical risk than a hospital treating patients.

Buy makes more sense once an organization runs clinical AI across more than one system, or needs an audit-ready posture faster than a build timeline allows, the threshold covered in how to implement an enterprise context layer for AI. Cedars-Sinai and CareQuest illustrate this: multi-system environments where re-deriving PHI-scoping for every new source would multiply the audit surface, exactly what a context layer ROI analysis quantifies.

Most organizations do both: buy the PHI-scoped infrastructure no team should reinvent per agent, and build the clinical semantics genuinely their own expertise, the domain counterpart to agent context layer tools compared. That split, not a single winner, is what the case studies show.

What goes wrong when healthcare teams get this decision wrong?

Three failure modes show up repeatedly, and none is primarily a cost overrun.

On the build side: teams underestimate that de-identification and audit logging are permanent maintenance, not one-time engineering, commonly requiring two or more full-time engineers just to keep a homegrown pipeline audit-ready.

On the buy side: assuming a signed BAA transfers all responsibility to the vendor. It does not. The organization still owns choosing the de-identification method and vetting the vendor’s subcontractor chain, work related to the general AI model governance and AI risk management every regulated buyer still has to do.

On either path: treating consumer AI tools as a shortcut. Public ChatGPT and Gemini do not execute BAAs, so entering identifiable PHI into them is a HIPAA violation regardless of which path an organization chose elsewhere.

The common thread is not that a team spent too much money. It is discovering, usually during an audit, that it misjudged who was actually accountable for a PHI-handling requirement, a liability failure, not a budgeting one.

Context Layer ROI Calculator

Model where build, buy, and hybrid paths actually land for your own healthcare AI estate.

Calculate Your ROI

How Atlan approaches healthcare AI context infrastructure

Healthcare organizations that treat compliance as a separate system tend to re-solve the same PHI-scoping and audit-logging requirements inside every new clinical AI pilot, the same gap covered from the memory side in context layer as AI memory foundation and memory layer vs. context layer. Atlan’s approach sits inside the buy column, one part of a hybrid strategy, not a verdict against building.

Atlan classifies PHI and propagates that classification through lineage, so sensitive-field restrictions travel into every downstream agent pipeline. Access controls enforce minimum-necessary, role-scoped retrieval before PHI reaches a model, and every output carries a decision trace back to its source, policy, and role. Delivered through MCP, SQL, and REST or graph APIs, rules are defined once and reused across every agent as part of a unified foundation. Scripps Health uses this to simplify PHI and PII classification for HIPAA compliance.

Healthcare requirement	What Atlan provides
Minimum-necessary PHI access at retrieval time	Role- and task-scoped access controls enforced at retrieval
De-identification method enforcement	Consistent enforcement of the org’s chosen policy across every source
Audit trail for every AI interaction with PHI	Decision traces linking every output to source, policy, and role
PHI-rule consistency across multiple agents	Rules defined once, reused across every agent runtime

The healthcare AI overview linked at the top of this guide covers the broader case for why this infrastructure matters at all. Context layer 101 and what is context engineering cover the vocabulary this page assumes.

See Context Agents in Action

Watch how a governed context layer enforces PHI-scoping and audit trails across a multi-system healthcare estate without rebuilding the rules per agent.

Watch the Demos

Why the healthcare build-vs-buy decision is a liability question first

Every credible source here, from HHS’s regulatory text to practitioners weighing the decision in real health systems, converges on the same point: a Business Associate Agreement is a legal risk-transfer mechanism a custom build cannot replicate. Building means carrying HIPAA’s minimum-necessary enforcement, de-identification documentation, and audit-trail obligations alone, for as long as the system exists. Buying means sharing that liability contractually, while still owning method choice, vendor vetting, and clinical semantics that no BAA can hand off.

The organizations getting the most value from either path did not pick build or buy as an identity. They were honest about which pieces of the compliance surface they would own indefinitely, and which they would share with a vendor under a BAA, the same discipline behind a well-run AI agent harness or a properly scoped semantic layer rollout.

Book a Demo

Real stories from real customers: trust in regulated data environments

"AI initiatives require more context than ever. Atlan's metadata lakehouse is configurable, intuitive, and able to scale to hundreds of millions of assets. As we're doing this, we're making life easier for data scientists and speeding up innovation."

- Andrew Reiskind, Chief Data Officer, Mastercard

Watch Now →

"Context is the differentiator. Atlan gave our teams the shared vocabulary and lineage to move from reactive data management to proactive AI enablement across CME Group."

- Kiran Panja, Managing Director, Data and Analytics, CME Group

Watch Now →

FAQs about build vs. buy for healthcare AI context infrastructure

1. What is the difference between building and buying healthcare AI context infrastructure?

Building means an organization designs and permanently maintains its own PHI classification, de-identification, access control, and audit-logging systems. Buying means a vendor provides those under a BAA, so the org configures policy instead of constructing infrastructure. The deeper difference is liability: a BAA shares HIPAA risk; a custom build carries it alone.

2. Is it cheaper to build or buy HIPAA-compliant AI infrastructure?

Buying is usually cheaper over multiple years once headcount is counted honestly; teams building their own pipelines commonly staff two or more engineers to keep the system audit-ready, a cost that never ends. In healthcare, cost is secondary to who is accountable when an audit fails.

3. What does a Business Associate Agreement actually cover for AI vendors?

A Business Associate Agreement is a contract required whenever a vendor creates, receives, or transmits PHI for a covered entity, requiring HIPAA’s Privacy, Security, and Breach Notification Rules. Under 45 CFR § 164.308(b)(4) it extends to any subcontractor handling that PHI. Without one, a vendor cannot legally process patient data.

4. Can healthcare organizations use ChatGPT or Gemini with patient data?

Not with identifiable PHI. Public ChatGPT and Gemini do not execute BAAs, so entering identifiable patient data into them violates HIPAA regardless of an organization’s build-or-buy choice elsewhere. Organizations need either an internal, HIPAA-controlled environment or a vendor that signs a BAA.

5. What are the hidden costs of building custom PHI de-identification?

The build itself is rarely the expensive part. The ongoing cost is keeping the pipeline current as note formats, specialties, and HIPAA interpretations evolve, plus the audit logging to prove it works, commonly two or more engineers permanently, a cost most initial estimates miss.

6. How does vendor lock-in risk compare to build risk in regulated healthcare environments?

The two risks are not symmetric. Vendor lock-in with a portable, open architecture is mainly a switching-cost risk. Build risk in a HIPAA context is compliance risk carried alone, indefinitely, with no party to share it. Vetting a vendor’s portability and BAA chain narrows lock-in; there is no equivalent way to narrow build risk.

7. What audit trail does HIPAA require for AI systems that touch PHI?

HIPAA’s Security Rule requires a retrievable log of what PHI was accessed, by whom, when, and for what purpose. It must reconstruct access after the fact and flag unauthorized use. General-purpose observability tools are often not HIPAA-ready out of the box, making audit logging one of the most underestimated build costs.

8. Should a hospital build its own clinical AI context layer, or buy one?

Most hospitals running clinical AI across more than one system are better served buying, since PHI-scoping rules and audit trails only need defining once. Building tends to make sense where the context itself is proprietary expertise, such as a research center’s de-identified warehouse tied to its own IRB processes.

Sources

ONC Data Brief: Hospital Trends in Predictive AI Adoption. https://www.healthit.gov/data/data-briefs
HHS Office for Civil Rights: HIPAA De-identification Guidance (Safe Harbor and Expert Determination). https://www.hhs.gov/hipaa/for-professionals/privacy/special-topics/de-identification/index.html
eCFR: 45 CFR Part 164, Business Associate and Subcontractor Requirements. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164
Linford & Co: Business Associate Agreements and AI Vendor Compliance. https://www.linfordco.com/
TechTarget: How Health Systems Can Build an AI-Ready Data Infrastructure. https://www.techtarget.com/healthtechanalytics/feature/How-health-systems-can-build-an-AI-ready-data-infrastructure
PwC: CareQuest, Building an AI-Enabled Health Data Platform. https://www.pwc.com/us/en/library/case-studies/carequest-ai-enabled-health-data.html
UCSF Data: How to Get De-Identified Clinical Data for Cohort Studies, Pattern Recognition, and More. https://data.ucsf.edu/research/deid-data
KLAS Research: Healthcare AI Update 2025. https://klasresearch.com/report/healthcare-ai-update-2025-what-use-cases-are-adopted-the-most/3912
McKinsey: Generative AI in Healthcare, Adoption Matures as Agentic AI Emerges. https://www.mckinsey.com/industries/healthcare/our-insights/generative-ai-in-healthcare-current-trends-and-future-outlook
ECRI Institute: Misuse of AI Chatbots Tops Annual List of Health Technology Hazards. https://home.ecri.org/blogs/ecri-news/misuse-of-ai-chatbots-tops-annual-list-of-health-technology-hazards

Share this article

Atlan is the Context Layer for AI, a Leader in the Gartner Magic Quadrant for D&A Governance (2026) and the Forrester Wave for Data Governance (Q3 2025). Atlan unifies your data, business knowledge, and the meaning behind your terms into one Enterprise Data Graph that gives every team and every AI agent the trusted context they need. Trusted by Mastercard, Workday, General Motors, CME Group, HubSpot, FOX, Virgin Media O2, Elastic, and 400+ enterprises representing $10T+ in market cap.

Book a Demo Context Studio Live