Build vs Buy: The Pharma Commercial AI Stack

Should pharma build or buy AI capabilities?

The honest answer is that the question is malformed. “Commercial AI” is not one capability and there is no single purchase that delivers it. A working pharmaceutical commercial stack has at least five distinguishable layers, and the correct answer differs at each one. Treating it as a single decision is the most common and most expensive error in this category, because the layer where building genuinely pays is rarely the layer where anyone proposes to start.

The useful version of the question is narrower: for each layer, is the value in the asset or in the judgement? Where the value sits in an asset that exists outside your company — a doctor universe, a claims dataset, a foundation model, a compliance framework — you are choosing between buying it and reconstructing it, and reconstruction is almost never rational. Where the value sits in judgement your commercial team already holds — how a tier is defined, what counts as a meaningful interaction, which signals precede a prescribing shift — you are choosing between owning that judgement and renting a generic version of it, and renting it is how commercial organisations end up indistinguishable from their competitors.

That distinction settles most of the stack quickly. What it does not settle is the middle, and the middle is where the argument actually lives.

Why the circulating build-vs-buy arithmetic does not transfer

The most comprehensive publicly available treatment of build versus buy for pharmaceutical AI sets out a hybrid recommendation supported by a cost model. It is a good document and its structure is sound. Its numbers, however, describe a US cost base: an initial build at $500,000 to $2 million per project, a commercial platform licence at $50,000 to $200,000, and — the figure that carries the whole comparison — senior data science and AI engineering talent at $200,000 to $500,000 a year, with principal-level researchers ranging higher still.

Now price the same team in India. Published 2026 salary guidance puts a senior data scientist with five to eight years of experience at an average of around ₹32 lakh, and a lead or principal at eight years and above at around ₹48 lakh, with top-decile figures of roughly ₹58 lakh and ₹80 lakh respectively. Machine learning engineers run broadly in line. At prevailing exchange rates that is roughly $36,000 and $55,000 — between a quarter and an eighth of the imported figure.

The implication is uncomfortable for anyone selling platforms, including us. If the dominant line item in the build case is four to eight times smaller than the literature assumes, then a five-person Indian team that would cost $1.5 million a year in the source material costs closer to ₹1.6–2 crore fully loaded. The build option is materially more affordable in India than the global guidance implies, and a reader who concludes otherwise from imported numbers has been misled by arithmetic, not persuaded by argument.

What this does not mean

It does not mean building is the right answer. It means cost is no longer the argument that settles it, and anyone still making the case for buying primarily on headcount economics is making a weak case badly.

The serious arguments for buying survive this correction untouched: time to value, the data asset you cannot hire, the run cost that does not fall with local salaries, and the regulatory obligations that arrive with ownership. Those are the arguments this article spends the rest of its length on.

What the 2026 survey figure actually measured

The statistic being quoted most often in build-versus-buy discussions this year comes from McKinsey's State of AI global survey, published August 2026 across 1,719 business leaders. The headline: 32% of organisations decided against buying at least one software product or feature because they judged they could build it internally with agentic coding tools. It is a real finding from a large sample and it is being used to argue that the build-buy balance has structurally shifted.

Read precisely, it supports a narrower claim than that. It measured a decision not to buy. It did not measure a system that shipped, a feature that reached production, a platform that was retired as a result, or an outcome sustained beyond the first year. A decision not to buy and a capability that works are separated by exactly the interval where most internal builds fail.

It is worth noting what the survey attributes the shift to: agentic coding tools, which have genuinely lowered the cost of producing working software. That is a real change and it deserves to be taken seriously rather than dismissed — though the distinction between agentic AI and automation matters here, because writing code faster is not the same as operating a system in a regulated commercial environment for three years.

The fourth row is the one to carry into a budget conversation. A fifth of a large sample of organisations are already curtailing usage because of what their AI costs to run. That is not a build-versus-buy finding on its face, but it is the single most relevant fact in the survey for anyone about to own a system for three years.

Cost comparison: internal data science team vs AI vendor

A cost comparison is only honest if the two sides are scoped identically, and they usually are not. The standard error is to compare a vendor's three-year licence against a build team's salaries, which omits roughly half of what building costs. The table below lists every line that belongs in the comparison, with a note on which side of the ledger it actually falls.

Read the ledger rather than the two salary numbers and the pattern reverses. Build cost is dominated by people, and people are cheap in India. Run cost is dominated by compute, data licences, drift and governance — none of which are priced in rupees. So the Indian discount applies to the smaller and more visible half of the total, and not to the larger and more persistent half. That is precisely the asymmetry that turns an affordable build into an expensive system in year three.

The five layers — and why this is not one decision

Every pharmaceutical commercial AI stack decomposes into five layers. They have different economics, different switching costs and different answers. The single most useful thing a decision forum can do is stop voting on “build or buy” and start voting five times.

Two of those rows have been treated at length elsewhere on this site. The data layer is the subject of a unified data layer for pharma AI, and the governance layer of an AI governance framework for pharma — which is worth reading alongside this page, because the policy it describes is yours whichever way the build decision goes. For the orchestration layer specifically, the question of keeping AI agents compliant with healthcare data rules applies identically to a bought system and a built one.

The pattern that emerges is buy at the edges, build in the middle. Buy the asset underneath and the interface on top; own the logic in between. It is the opposite of what most build proposals contain, because internal teams are naturally drawn to the layers with the most interesting engineering — the data pipeline and the model — and least drawn to the layer where the commercial differentiation actually sits.

The test that resolves layer three

For each rule in your orchestration layer, ask: if a competitor saw this rule, would it help them? If the answer is no, the rule is commodity and should be bought with the platform. If the answer is yes, that rule is a commercial asset and you should be able to change it without raising a vendor ticket.

A platform that cannot expose and edit those rules in your own team's hands is not a platform, it is a managed service with a login. That is a legitimate thing to buy — but buy it knowingly, and price the dependency.

What you cannot build at any salary

The salary correction earlier in this article removes cost as the deciding argument. What survives it is the data asset, and it is worth being precise about why, because “buy the data” is usually asserted rather than explained.

A usable Indian doctor base is not a list. It is a resolved entity set — one record per physician, not four — with specialty, qualification, practice affiliation, contactability, and a consent state that is current and auditable. Every one of those attributes decays. Physicians move practices, add hospital affiliations, change registration state and withdraw consent, and a base that is not being continuously reconciled is wrong within a year in ways its owner cannot see.

The concrete form of this failure is familiar to anyone who has looked closely at their own CRM: duplicate doctor records, four entries for one physician, each carrying a different fragment of the engagement history. A base in that state does not merely give slightly worse answers. It systematically overstates reach and understates frequency, and every model trained on it inherits both errors with full confidence.

You can hire the engineers to build the resolution logic; the programme has written about how that logic works in detail. What you cannot hire is the years of accumulated source reconciliation, the field verification, and the maintained consent history that make the resolution logic worth running. A perfect matching algorithm applied to a stale and duplicated base produces confident, well-engineered, wrong answers — and every downstream model inherits the error.

If the asset argument lands, the practical next step is not a build plan but a shortlist — and the programme has already published a comparison of AI platforms for pharma commercial operations for exactly that purpose. The sequence matters: decide whether it is an asset or a capability first, and only then look at who supplies it.

So the honest buy case is not that building is expensive. It is that part of the stack is not a build at all — it is an acquisition, and framing an acquisition as an engineering project is how three-year programmes get approved on one-year budgets.

What controls do regulators expect on commercial AI?

This is the question that most cleanly separates the two options, and it is the one least often asked before the decision is made. Building does not merely move work in-house. It moves a set of named regulatory obligations onto your organisation, and some of them have dates attached.

India: the DPDP obligations that change when you build

Most pharmaceutical companies operating at scale in India will be designated Significant Data Fiduciaries — the programme has set out why most pharma companies qualify as SDFs and what the compliance expectations for Significant Data Fiduciaries look like in practice. Rule 13 of the DPDP Rules 2025 attaches a specific set of obligations to that designation, and three of them bear directly on this decision.

The enforcement calendar is not pending. Penalty provisions become operative on 13 November 2026 and full compliance lands on 13 May 2027. A build programme that reaches production in eighteen months reaches it into a live enforcement regime, not ahead of one.

And the point that decides the argument: responsibility does not transfer with the work. Appointing a vendor does not make the vendor answerable for your processing. It makes them your processor, bound by agreement to equivalent safeguards, while the fiduciary obligations remain yours — responsibility cannot be outsourced, and the framework is explicit about it. Buying reduces the work and the evidentiary burden. It does not reduce the accountability, and any vendor who implies otherwise should be treated as a risk rather than a solution.

Europe: what actually moved and what did not

For any company selling into the EU, the AI Act timeline changed in 2026 and is being widely misreported in both directions. Under the Digital Omnibus provisional agreement reached on 6 May 2026, high-risk obligations for Annex III stand-alone systems moved from 2 August 2026 to 2 December 2027, and Annex I embedded systems from 2 August 2027 to 2 August 2028.

Three corrections worth making internally
 

• -First, it is a deferral, not a repeal. The obligations arrive; they arrive later.
• -Second, Article 50 transparency obligations were not deferred and apply from 2 August 2026 as originally scheduled, with a four-month grace period to 2 December 2026 for watermarking on systems already on the market before that date.
• -Third, confirm current status before relying on any of this. As of the agreement it was a provisional political agreement pending formal adoption and publication in the Official Journal. Regulatory content with a stale date is discounted exactly when it is most needed — check the position on the day you publish.
  
  For the decision at hand, the AI Act matters less through its deadlines than through its structure. Its obligations attach primarily to providers of high-risk systems, and building your own makes you the provider. A company that buys is a deployer with deployer obligations; a company that builds inherits the heavier set. That is a genuine asymmetry and it is rarely priced into a build business case.

A worked three-year comparison at Indian prices

The figures below are illustrative and constructed for this article from the published inputs cited in the source table. They are not a quotation, a benchmark or a claim about any specific vendor. Their purpose is to show which lines move the total, so a reader can rebuild the same structure using their own numbers. Run it on your own inputs before quoting it to anyone.

The scenario: a mid-size Indian pharmaceutical company, roughly 500 field representatives, seeking HCP analytics and next-best-action across three brands. Three-year horizon, all figures in ₹ crore.

Three observations, in order of importance.

1. The salary line is not where the difference comes from. Team cost accounts for roughly a third of the build total. The remaining two-thirds — data licences, compute, pipeline and governance — are the lines that do not fall with Indian salaries, and they are the lines a build business case typically understates or omits.
2. Reverse the salary correction and the comparison inverts. Price the same five-person team at the US figures used in the circulating guidance and the build column runs past ₹40 crore. That is how large the imported-arithmetic error is, and it is why this page rebuilds the model rather than citing one.
3. The timing row is the one most likely to change a decision, and it is the one that cannot be tabulated. Eighteen months of unimproved targeting across three brands has a cost. It does not appear in any build business case because it is not an invoice, and it is routinely larger than the difference between the columns.

What this table deliberately does not do is value the return. It establishes what each option costs, which is a different question from what the investment is worth — and the second question needs its own evidence, its own benchmarks and a CFO-grade treatment of attribution. That work belongs to the forthcoming benchmark article on the ROI of AI in pharma commercial operations, and in the meantime the live page on AI ROI in pharma is the right starting point. Do not build a business case from a cost table alone; the denominator is only half the calculation.

A reader who has worked through the ledger and decided to buy needs the diligence question set next — what to ask a vendor about security, hosting, model documentation and exit rights — and that is the subject of the planned article on the questions to ask a pharma AI vendor. A reader who has decided to build needs the same questions asked internally, of their own team, with the same refusal to accept a reassuring answer.

Where build-vs-buy decisions go wrong

Seven failure patterns account for most of the regret in this category. They are recognisable early, and six of the seven are decided before any money is spent.

The five questions that settle it

Run these in order. Most decisions resolve by question three, and the two that follow protect the ones that do not.

1. Is the value in the asset or in the judgement? Asset means buy. Judgement means build, or build with a partner under an explicit capability-transfer agreement. Applied layer by layer, this alone resolves the data and interface layers immediately.
2. Would a competitor benefit from seeing this logic? If yes, it is a commercial asset and you should be able to change it without a vendor ticket. If no, it is commodity machinery and building it is engineering for its own sake.
3. What does it cost to run for three years, not to build for one? Model the compute, the drift, the data licences and the governance tooling. If nobody in the room can produce a three-year run cost, the decision is not ready to be made.
4. Who is answerable to the regulator when the model is wrong? Name the person. They are an employee in both scenarios — and if building materially increases what that person must personally evidence, that is a cost, whether or not it appears in the model.
5. Can two people change every model in production? If the honest answer is no, you have a key-person dependency rather than a capability, and the build has not delivered what it promised regardless of what it cost.

What changes for mid-size and emerging-market companies

The decision looks different at different sizes, and the difference is not simply budget.

Where Multiplier AI fits — and where it does not

Where we fit is the data layer and the interface layer, which is where the asset argument is strongest. The GenAI Doctor Data Platform exists because a maintained, resolved, consented Indian doctor base is the part of this stack that is genuinely an acquisition rather than a build — and our DPDP-compliant HCP marketing work exists because consent state is a field that has to be enforced at the point of engagement, not reconstructed at audit.

Where we do not fit is layer three when a company has a capable analytics function and a genuine point of view about its own commercial logic. If your team can articulate why your tiering differs from your competitors', that logic should belong to you, and a vendor who tells you otherwise is selling you a dependency. We would rather supply the foundation and the rule visibility and let your team own the judgement — which is also, not coincidentally, the configuration that renews.

And where we are the wrong choice outright: a company with a hard data-localisation constraint we cannot meet, a company whose primary need is R&D rather than commercial AI, and a company that has already built something that works. The third case is more common than vendors admit. A working internal system with two people who understand it is worth more than a migration.

Key takeaways

• The circulating cost comparison is priced in US dollars. At published 2026 Indian rates a senior data scientist averages roughly ₹32 lakh against the $200,000–$500,000 used in the global guidance. Building is more affordable in India than the literature implies, and cost is therefore not the argument that settles this.
• Build cost falls with local salaries. Run cost does not. Compute, data licences, drift and governance are priced externally and account for roughly two-thirds of the three-year build total in the worked model.
• The 2026 McKinsey figure measured a decision not to buy, not a system in production. The same survey shows EBIT impact flat at 37%, high performers flat at 6%, and 20% of respondents already limiting technology use because of AI operating costs.
• This is five decisions, not one — data, model, orchestration, interface, governance. Buy at the edges, build in the middle. Most failed programmes made a single decision and forced the stack to match it.
• You cannot hire your way to a doctor universe or backdate a consent history. That is the strongest buy argument and it is not an argument about cost.
• DPDP Rule 13 puts algorithmic due diligence, an annual DPIA and an independent audit on Significant Data Fiduciaries, with penalties operative from 13 November 2026 and full compliance on 13 May 2027. Buying moves the work; it does not move the accountability.
• Building makes you the provider under the EU AI Act, not merely the deployer — a heavier obligation set, and one that the Digital Omnibus deferred rather than removed.

Conclusion

The build-versus-buy decision is usually lost at the framing stage, and it is lost in two specific ways: by treating five decisions as one, and by importing a cost model that was priced somewhere else. Correct both and the question becomes tractable. Buy the asset you cannot economically reconstruct. Build the judgement that distinguishes your commercial team. Contest the middle layer deliberately, in the open, with the rules visible to the people who have to live with them.

What should genuinely worry a decision-maker is not the licence fee. It is the run cost in year three, and the name of the person who has to stand behind the model's behaviour when a regulator asks. Both are knowable before anything is signed, and neither appears on the comparison slide most of these decisions are made from.

If a build proposal cannot produce a three-year run cost and cannot name two people who could change every production model, it is not a build proposal. It is an intention, and intentions are what the 2026 survey actually measured.