The general counsel put the deposition transcript on the table and read one line aloud. "The recommendation came from the AI model, not from Dr. Reyes." The plaintiff's attorney had spent the morning establishing that a sepsis prediction tool, purchased from a well-known vendor and FDA-cleared, had flagged the patient late, and that the physician had leaned on it. Everyone in the room had assumed the vendor would absorb the exposure. The health system's own contract said otherwise. The indemnification clause was narrow, the intended-use statement was narrower still, and the standard of care did not care whose logo was on the software. Accountability, the counsel explained to a very quiet executive team, had never left the building. It never does. This lesson is about the single most consequential architecture decision a clinical AI leader makes, whether to build a model or buy one, and about the trap hiding inside both answers: neither one buys you out of the accountability that stays human.

The Question Behind the Question

Build versus buy sounds like a procurement decision, the kind a sourcing team settles with a spreadsheet comparing license costs against engineering salaries. For most technology, that framing is fine. For clinical AI it is dangerously incomplete, because the thing you are acquiring is not a tool that sits beside care. It is a tool that reshapes a clinical decision, alters the legal record, and creates a new way for a patient to be harmed. The real question behind build versus buy is not "which is cheaper" or "which is faster." It is "which obligations are we prepared to own, and which can we responsibly share." Every honest answer to that question begins with a fact that surprises leaders new to this space: buying does not transfer clinical accountability. You can outsource the code. You cannot outsource the duty to the patient.

Start with definitions, because the words carry legal weight. To buy a clinical AI capability means to license a product built, trained, and maintained by a vendor: an ambient documentation tool, a predictive risk model embedded in the electronic health record, an imaging triage algorithm cleared by the FDA. To build means your organization develops the model itself, whether from scratch on your own data or by taking an open model and fine-tuning, validating, and deploying it under your own name. Between these poles sits a spectrum: configuring a vendor tool, co-developing with a vendor, wrapping a foundation model in your own retrieval and prompts. But the two extremes clarify the trade-offs, and the trade-offs are not primarily about money. They are about who owns validation (the formal, documented proof that the tool performs as intended on your patients), who owns real-world monitoring (the ongoing surveillance that catches performance decay after go-live), and who carries the regulatory and liability weight when something goes wrong.

Most systems buy, and for good reason. A validated commercial tool arrives with a clinical evidence base, a regulatory pathway already walked, an integration team, and a maintenance roadmap. Building any of that in-house is a multi-year commitment that most health systems, even large academic ones, cannot staff or sustain. But "most systems buy" is not the same as "buying is safe," and the leaders who get burned are the ones who treated a purchase as a transfer of responsibility. The purchase transfers the software. The responsibility stays exactly where it was.

What Buying Actually Transfers (and What It Does Not)

When you buy a clinical AI tool, you genuinely acquire several valuable things, and it is worth naming them so the trade-off is honest. You acquire a product that someone else built and tested at scale. You acquire, in most cases, a regulatory clearance: many predictive and imaging tools are cleared or authorized by the FDA as a medical device, meaning the manufacturer has met defined requirements for a defined intended use (the specific clinical purpose and population the FDA authorized, printed in the labeling). You acquire a vendor's maintenance obligation, their security posture, and, if you negotiate well, contractual protections. These are real. A good vendor tool can be safer than anything you could build, precisely because the vendor has seen failure modes across hundreds of sites that you would discover the hard way.

Here is what the purchase does not transfer. It does not transfer the standard of care, the legal benchmark of what a reasonable clinician or organization would do, which is measured against your conduct, not the vendor's. It does not transfer the duty to validate the tool on your own population, because FDA clearance is an authorization for an intended use, not a guarantee that the tool performs on your patients, in your workflow, at your prevalence of disease. It does not transfer the obligation to monitor for model drift (the gradual degradation of a model's accuracy as your patients, your coding, or your care patterns shift away from the data the model was trained on). And it does not transfer the physician's accountability for the decision. When a clinician acts on a bought tool's output, the clinician is accountable for that action, and the organization is accountable for having deployed the tool responsibly. "The vendor's model said so" is not a defense to a board, a plaintiff, a family, or a surveyor.

Buying a model does not buy you out of accountability. The license transfers the software; it does not transfer the duty to the patient, the obligation to validate, or the physician's responsibility for the decision. There is no clause that indemnifies you out of the standard of care.

This is where the concept of dual liability becomes concrete. When a bought tool contributes to harm, exposure can attach at two levels at once: the vendor may bear product liability for a defective device, and the health system and clinician may bear liability under the standard of care for how the tool was selected, validated, deployed, and used. These are not mutually exclusive. A plaintiff's attorney will name everyone. The vendor's clearance and your indemnification clause shape how the loss is ultimately allocated, but they do not make your exposure disappear. Leaders who assume "we bought it, so it is their problem" discover, usually in a deposition, that the standard of care attached to their own conduct the moment the tool touched a patient.

The BAA and the Data Boundary

Buying also creates a data relationship that leaders must govern. Any vendor that touches protected health information on your behalf is a business associate, which requires a business associate agreement (BAA), the HIPAA contract that binds the vendor to safeguard PHI and defines permitted uses. The BAA is necessary, but it is not sufficient. It governs privacy and security; it does not govern clinical performance, bias, or drift. A signed BAA tells you the vendor promised to protect the data. It tells you nothing about whether the model works on your patients. Treating the BAA as the finish line of vendor diligence is a common and costly confusion of two entirely different obligations: protecting the data and validating the tool.

What Building Makes You Own

Building is seductive to leaders who want control, differentiation, or a model tuned precisely to their population. Sometimes that instinct is right: an academic system with rare-disease expertise, a payer-provider with unique claims data, or a system whose population is so distinct that commercial tools underperform may have a genuine case to build. But building is not a coding project with a clinical wrapper. Building means becoming the manufacturer, and the manufacturer owns obligations that most leaders have never had to hold. Before you build, you must know what you are signing up to own, because the burden does not scale down for a small in-house project. Regulators do not offer a hobbyist exemption for a model that touches a patient.

First, you own validation end to end. No vendor evidence base exists; you must generate it. That means assembling a representative dataset, defining the intended use precisely, measuring sensitivity, specificity, and predictive value on your population, testing across subgroups, and documenting all of it to a standard that would survive a plaintiff's expert and a surveyor's file review. Second, you own real-world monitoring: a build is not done at go-live. You must instrument the model to catch drift, define thresholds that trigger review, and staff the humans who watch the dashboards and act when performance decays. A model that was accurate in January and silently degraded by September, with no one watching, is a build that became a liability.

Third, and most underappreciated, you may become a device manufacturer under the FDA. Software that is intended to inform or drive a clinical decision can meet the definition of a medical device. When a vendor sells you such software, the vendor carries the regulatory burden. When you build it and deploy it, you may carry that burden yourself, including quality-system requirements, potential premarket submission, and postmarket surveillance obligations. There is a narrow non-device carve-out for certain clinical decision support that merely displays information a clinician can independently review, but the line is technical and easy to cross. A leader who builds a predictive tool without a regulatory strategy has not saved money. They have quietly assumed a manufacturer's obligations without a manufacturer's infrastructure.

Fourth, you own the ONC predictive-DSI transparency obligations. Under the ONC HTI-1 rule, AI and machine-learning decision support built into certified health IT is treated as a predictive decision support intervention, and the party responsible must supply source attributes, a nutrition-label-style set of facts about the intervention: what data trained it, how it performs, how it was validated, what its known limitations and fairness considerations are. When you buy from a certified vendor, the vendor produces those attributes. When you build, you own them. You must document, disclose, and maintain the transparency record yourself, and you must manage the intervention's risk and test it in the real world. Fifth, you own bias testing: a model trained on a non-representative population underperforms for the patients already underserved, and disparate performance is both a clinical harm and a legal risk. The build owner must test for it before deployment and monitor it after, forever.

The Trade-Off, Side by Side

The comparison below lays out the axes leaders actually decide on. Read it not as a scorecard where buy always wins, but as a map of where each obligation lands. Notice the pattern: buying moves the technical and regulatory burden to the vendor while leaving the clinical accountability with you, and building moves everything onto your organization. The one row that never moves, no matter which column you choose, is the last one.

The table makes the strategic logic visible. Buying is not the safe choice because it removes risk; it is the common choice because it lets a system access validated capability without standing up a manufacturer's infrastructure, while still requiring local validation, monitoring, and human accountability. Building is not the bold choice because it is more advanced; it is the rare choice because it asks an organization to hold obligations that regulators and courts designed for companies whose entire business is holding them. The decision is a matter of which burdens your organization is genuinely equipped to carry, forever, not just to launch.

A Worked Example: Two Roads Out of the Same Problem

Consider a 600-bed system whose readmission rates for heart failure patients are hurting both outcomes and margin under value-based contracts. Leadership wants an AI risk model to flag high-risk patients for a transitional-care intervention. Two paths present themselves, and watching each one play out shows the trade-offs in motion rather than on a chart.

The buy path. The team licenses a commercial heart-failure readmission model embedded in the EHR, FDA-considerations reviewed, with a published evidence base. Procurement moves fast. But the informatics and quality leaders do not treat the purchase as the end of diligence. They read the intended-use statement and notice the model was validated on a population with a different payer mix and a lower baseline readmission rate than theirs. So they run a local validation: they hold out several months of their own data, measure the model's sensitivity, specificity, and positive predictive value on their patients, and test performance across race, primary language, and payer subgroups. They find the model performs acceptably overall but under-flags patients whose primary language is not English, a disparate-performance finding that would have quietly under-served an already vulnerable group. They document this, adjust the workflow so care managers manually screen that subgroup, negotiate a monitoring cadence into the contract, and stand up a quarterly review that watches for drift. The BAA is signed, but they treat it as the privacy floor, not the clinical ceiling. Time to safe deployment: about five months. The vendor carries the device and transparency burden. The system carries validation, local monitoring, and every clinical decision the model informs.

The build path. A different system, an academic center with a strong data-science group and a genuinely unusual population, decides to build. Now watch the obligations arrive. They must assemble and clean a representative training dataset, which surfaces missing-data and coding-consistency problems that take months. They must define the intended use precisely enough to know whether their tool crosses the FDA device line, and their regulatory affairs office concludes it likely does, triggering a quality-system and submission conversation no one had budgeted. They own the ONC source attributes, so they build the transparency documentation from scratch: training data description, performance, validation method, known limitations, fairness assessment. They own bias testing, so they run subgroup analyses and build the monitoring to repeat them forever. They stand up a real-world monitoring pipeline with drift thresholds and a named clinical owner. Eighteen months in, they have a model tuned beautifully to their population and a permanent operating burden: a small team whose job is to keep validating, monitoring, and documenting a tool the organization now manufactures. For this system, with its data assets and rare population, the build may be worth it. For most systems, this same eighteen-month, manufacturer-grade burden is exactly why they buy.

Notice what is identical across both roads. In both, an unverified model output that reaches a patient without a human check is a liability with someone's name on it. In both, the clinician who acts on the score is accountable for the action, and the organization is accountable for how it deployed the tool. The build did not concentrate more accountability on the clinician than the buy did; it concentrated more manufacturing obligation on the organization. The accountability was always human, always local, always non-transferable. That is the constant the architecture decision cannot change.

How Leaders Should Actually Decide

A defensible build-versus-buy decision is not made by the loudest champion or the most impressive demo. It is made against a small set of questions a leader can answer honestly. First: does a validated commercial tool exist for this use case, and does its intended use match our population and workflow closely enough that local validation is a check rather than a rescue? If yes, the default is to buy, because you get validated capability without a manufacturer's burden. Second: do we have a genuine reason the market cannot serve, a population, a data asset, or a clinical need so distinct that commercial tools measurably underperform? Only a real yes justifies building, and "we want control" or "it looks cheaper" is not a real yes.

Third: if we build, are we prepared to own validation, real-world monitoring, the potential FDA device burden, the ONC transparency obligations, and bias testing forever, with named owners and permanent staffing? If the honest answer is that we can build it but cannot sustain it, the decision is made: do not build what you cannot maintain, because an unmonitored home-built model is not an asset, it is drift waiting to become a safety event. Fourth, regardless of build or buy: what is our verification workflow at the point of care, and who is accountable for each output? Because the iron rule survives every architecture: every AI output touching a patient must be verified, accountability stays human, and the record must prove the human decided.

The most mature leaders hold build and buy as a portfolio, not a religion. They buy the validated, bounded, well-served use cases and reserve building for the rare case where they hold an advantage the market cannot. And whichever they choose, they refuse the fantasy that any contract, clearance, or codebase moves the accountability off human shoulders. The vendor's model, the home-built model, the fine-tuned foundation model: all of them are tools inside a regulated, audited, human-accountable system. The leader's job is to place the obligations where the organization can actually carry them, and to keep the last, immovable one exactly where it belongs.

Key Takeaways

• Buying a clinical AI tool transfers the software, the vendor's evidence base, and often an FDA clearance, but it does not transfer clinical accountability, the standard of care, the duty to validate on your own population, or the physician's responsibility for the decision.
• FDA clearance authorizes a defined intended use; it is not a guarantee the tool performs on your patients, at your prevalence, in your workflow. Local validation is always your job, whether you buy or build.
• Dual liability is real: when a bought tool contributes to harm, the vendor may bear product liability and your system and clinician may bear standard-of-care liability at the same time. A narrow indemnification clause does not erase your exposure.
• A business associate agreement governs privacy and security of PHI; it says nothing about clinical performance, bias, or drift. Treating a signed BAA as the finish line of vendor diligence confuses two entirely different obligations.
• Building means becoming the manufacturer: you own validation end to end, real-world monitoring for drift, potential FDA device obligations, the ONC predictive-DSI source-attribute transparency record, and bias testing before and after deployment, forever.
• Most systems buy because building demands manufacturer-grade infrastructure and permanent staffing that few can sustain. Build only when you hold a population, data asset, or clinical need the market genuinely cannot serve, and only if you can maintain it, not just launch it.
• Decide by portfolio, not religion: buy the validated, well-served, bounded use cases; reserve building for the rare real advantage; and never build what you cannot maintain, because an unmonitored home-built model is drift waiting to become a safety event.
• The iron rule survives every architecture: every AI output touching a patient must be verified, accountability stays human, and "the vendor's model said so" is not a defense to a board, a plaintiff, a family, or a surveyor.