Why Commercial Biopharma Cannot Scale AI on Its Current Data

What the Survey Numbers Say, and What They Do Not

A number has been circulating in commercial pharma conversations: that roughly nine in ten commercial biopharma organizations say their data is not ready to scale AI. The figure is close to a real finding, but it merges two different results from the same report. Getting the distinction right matters, because the two numbers point at different problems.

The Source and Its Population

The source is Veeva’s report The State of Data, Analytics, and AI in Commercial Biopharma, published in October 2025.¹ It draws on a survey of 116 senior life sciences leaders from large, global enterprises in Europe, the United States, and Asia Pacific. Veeva states that 85% of respondents directly oversee their organization’s commercial analytics and AI initiatives. That is a useful population for this question: these are the people who would know whether a pilot reached scale.

The report makes two separate claims that are often blended:

• The scaling figure. 89% of respondents were not able to scale more than half of their AI initiatives. A December 2025 Veeva blog post discussing the research states it the same way: 89% fail to scale more than half of their initiatives.²
• The data-readiness figure. 96% believe their data is not well structured or AI-ready for scaling. The same blog post puts it more plainly: “96% say their data isn’t ready to scale AI.”²

So the accurate statement is that almost all of these leaders say their data is not ready (96%), and almost as many say most of their AI work has not scaled (89%). The second figure is an outcome. The first is the respondents’ explanation for it. The report connects them directly, describing three data issues (quality, inconsistency, and fragmentation) that show up as problems of trust, speed, and consistency.¹

The Caveat Leaders Should Keep in Mind

Veeva sells CRM, HCP reference data, and patient and prescriber data products. Its reports close with a pitch for a connected data foundation, and the 2026 launch report ends by listing Veeva’s own data products.³ That does not make the findings wrong. It does mean the framing (that the answer is better data supplied by fewer vendors) should be tested against your own situation rather than accepted whole. The survey method also has limits worth stating: the reports do not publish response rates, sampling frames, or confidence intervals, and the respondents are self-reporting.

What makes the findings credible is that the details line up with the operational detail behind them. The 2025 report found that 72% of companies spend up to 100 days matching HCP data across sources, 62% spend up to 200 days working through third-party access agreements (TPAs) to use data they already have, and 95% must remap global specialties to local ones, with 55% doing so at least once a year.¹ Respondents also describe simple data change requests for a name or address taking two weeks to resolve. Those are not opinions about AI. They are descriptions of the plumbing.

What the 2026 Launch Survey Adds

A second Veeva report, based on its 2026 Biopharma Launch Data Survey of 125 senior U.S. leaders across emerging biotechs, mid-sized, and large biopharmas, looks at the same issue through product launches.³ Its findings are more specific about where the trouble starts:

• 48% faced data integration challenges in their most recent launch, rising to 61% among emerging biotechs and 58% among mid-sized companies, against 42% for large biopharmas.
• 98% use at least two data providers, and 57% would consider replacing a data vendor because of integration challenges.
• One in two respondents would not use their current data to train AI models because of integration challenges, and one in three because of coverage or quality problems.
• Only 6% of field teams receive alerts within 24 hours, while 76% receive them after one to three weeks.
• AI use is concentrated in work that needs little connected data. 63% use AI for marketing, while only 22% use it for patient identification and 22% for field activation, which depend on combining several sources.

That last point is the most useful thing in either report. AI is being adopted where the data does not need to be joined, and stalling where it does. That is the pattern this article is built around.

Commercial Data Is a Set of Joins, Not a Data Set

When leaders say their data is “not AI-ready,” they usually mean something general: it is messy, inconsistent, or incomplete. That description is true but does not help a team decide what to fix first. In commercial biopharma, a more useful way to describe the problem is to name the joins.

A commercial AI use case almost never runs on one source. A next-best-action model for the field needs HCP identity, call history, prescribing behavior, payer coverage, and channel consent. A patient-finding model needs diagnosis and treatment signals from claims, a way to attribute them to a prescriber, and a route to get an alert into the CRM. An adherence or persistence model needs specialty pharmacy dispense and status data, hub case data, and sometimes free-drug program data. Each of those is a join between two or more data sets that came from different organizations, under different contracts, with different identifiers, refreshed on different schedules.

The Five Sources and Their Keys

The table below lists the five commercial data sources this article covers, the key each one is usually joined on, and the place the join most often fails.

Two things stand out from this view. First, the join keys are different in almost every row. Only the prescriber NPI and the drug’s NDC show up in more than one, and as later sections show, the NPI is less reliable as a descriptive record than most teams assume. Second, two of the five sources are owned outright by someone outside the company, and two more (HCP master data and consent) depend partly on outside vendors or partner forms. The data arrives under contract, in a partner’s format, on a partner’s schedule. No amount of internal cleanup will fix a join if the partner’s data does not carry the field you need.

Why AI Makes the Joins Matter More

Traditional commercial reporting could live with weak joins. A monthly dashboard built by an analyst who knows the data can absorb a 10% mismatch between pharmacy and claims records, because the analyst knows to adjust for it. A model cannot do that unless someone tells it. Worse, the model learns from the mismatch: if a third of a brand’s patients are invisible in one source, the model learns that those patients do not exist.

The 2025 Veeva report describes this in field terms. When a next-best-action tool generates recommendations from flawed data, the field force notices quickly, stops trusting the tool, and goes back to its own methods.¹ That is the scaling failure in practice. The pilot worked in one market because the analyst who built it hand-fixed the joins. The rollout failed because nobody wrote those fixes down.

CRM Data: Activity Records Built for Reps, Not Models

CRM is usually the first data source a commercial AI program touches, because it is internal, it is current, and it is where the output of most field AI has to end up. It is also the source most likely to look cleaner than it is.

The Content That Matters Is in Free Text

The structured fields in a CRM call record (date, HCP, products discussed, channel, duration) are reasonably consistent, because the system enforces them. The information that would make a model useful, such as what the HCP asked about, what objection they raised, or what access barrier their patients face, is usually in free-text notes. The 2025 Veeva survey found that the most common commercial AI use case was summarizing HCP updates and call reports, pursued by 72% of respondents.¹ That reflects where the value is. It also explains why so many pilots begin there: summarizing text does not require joining it to anything else.

The difficulty comes in the next step. Once a team wants to use call-note content as a model feature (for example, flagging HCPs who have raised a prior authorization barrier and linking them to payer data), the free text has to be turned into a structured attribute, joined to an HCP identity, and joined again to a payer or plan. Each step adds error, and none of it was designed into the CRM.

Territory History Gets Overwritten

Most CRM configurations store the current alignment of HCPs to territories and representatives. When a realignment happens, the old alignment is often replaced rather than kept with an end date. For reporting, that is fine. For a model that needs to learn whether a representative’s activity changed an HCP’s prescribing, it is a serious problem: the model cannot tell which representative was responsible at the time the prescription was written. The join between CRM activity and prescription data needs a time dimension, and the CRM often does not keep one.

The fix is unglamorous: keep alignment history as effective-dated records in the data platform, even if the CRM itself does not, and make every activity-to-outcome join use the alignment that was in force on the date of the activity.

Global CRMs Multiply the Problem

For companies running more than one CRM instance or more than one regional data model, the problem compounds. Veeva’s respondents describe customer data split across regional CRMs in different formats, and analysts writing different code to run the same analysis in different countries because field names, definitions, and structures do not line up.¹ One respondent described a missing mapping between the ERP and CRM in many markets as the thing blocking deployment of a customer 360 tool. This is why 76% of those leaders named global data harmonization as the top enabler of AI at scale.¹

Safety Content in Field Records

CRM notes have one property that most AI teams overlook: they can contain adverse event information. A representative records that an HCP mentioned a patient’s side effect. A model that reads call notes for sentiment or topics will read that sentence too. The safety obligations covered in the next section apply to this content as well, and any AI pipeline that processes field notes should have a defined route for anything that looks like a safety report.

Specialty Pharmacy and Hub Data: A Treatment Record Someone Else Formats

For specialty brands, the most valuable commercial data often comes from specialty pharmacies and hub service providers. These partners see referral, benefits investigation, prior authorization, first fill, refills, and discontinuation, often before any licensed data vendor does. They are also where some of the hardest joins live.

Every Partner Sends Its Own Version

A brand with a limited distribution network may receive data from several specialty pharmacies and one or more hub vendors. Each partner sends status updates in its own format, under its own data agreement. The industry has tried to standardize this. NCPDP, the pharmacy standards body, publishes a Specialty Pharmacy Data Reporting implementation guide that provides a standardized format for data that specialty pharmacies send to manufacturers to support their programs and agreements.⁵ NCPDP also co-developed, with HL7, a FHIR implementation guide for specialty medication enrollment that covers exchanging patient demographic, coverage, clinical, and consent data between pharmacies, hub vendors, and manufacturers.⁶

Standards help, but two limits remain. The NCPDP reporting guide is available to members only, so a brand team cannot simply check a partner’s feed against it without access.⁵ And a standard format does not guarantee the same meaning. Two pharmacies can both send a status of “on hold” while meaning different things: one may be waiting on a prior authorization, the other on a patient callback. A model trained to predict discontinuation will treat those as the same event unless someone maps them.

The Same Patient Under Several IDs

A patient referred through a hub, dispensed by a specialty pharmacy, and later switched to a different pharmacy can appear under a hub case ID, two pharmacy patient IDs, and possibly a free-drug program ID. Linking these into one treatment record is the join that adherence, persistence, and patient-support models depend on. When it fails, the model sees three short treatment histories instead of one long one, and it reports a discontinuation that did not happen.

The Patients Claims Data Never Sees

The clearest published example of why this join matters comes from a 2024 study in Scientific Reports. Researchers used privacy-preserving record linkage with Datavant tokens to connect Medicare Part D prescription drug plan data with a manufacturer’s patient assistance program database for tafamidis, a treatment for transthyretin amyloid cardiomyopathy.⁴ Of 8,381 patients in the assistance program database with tokens, 8,131 (97%) matched to Medicare beneficiaries.

The result that matters for commercial teams is what the linkage revealed. Among the Medicare patients studied, 35% received the drug only through the assistance program, 14% through both the program and Medicare, and 51% through Medicare only. For patients with prescriptions through both channels, adherence measured by proportion of days covered was 77% using Medicare data alone, compared with 88% when the two sources were pooled.⁴ In other words, a model built on claims data alone would have missed about a third of the treated population and understated adherence for those it could see.

A New Claims Feed Arrived in 2026

One change in force this year adds a data stream that commercial and market access teams now have to reconcile. Under the Medicare Drug Price Negotiation Program, the Medicare Transaction Facilitator began operations on January 1, 2026, to support manufacturers in paying the negotiated maximum fair price.⁸ CMS describes its Data Module as drawing on the existing flow of claims data to pass certain data elements to manufacturers, who use them to identify dispenses of their selected drug to eligible beneficiaries and calculate refunds. Part D plan sponsors have up to seven days to submit data, manufacturers have up to 14 days to process it and approve refunds, and banking takes up to five business days. CMS reports that refunds are reaching pharmacies within 21 days of the date of service on average.

For the small number of companies with selected drugs, this is a claim-level data feed with tight processing deadlines that has to be reconciled against specialty pharmacy dispense data, gross-to-net models, and any 340B identification process. It is an example of how commercial data sources keep multiplying: each new feed brings its own identifiers and timing, and each one is a new join.

Adverse Events in Hub and Pharmacy Data

Hub and patient support data carries the same safety exposure as CRM notes, usually more. Nurse educators, case managers, and pharmacy staff speak with patients directly, and patients report side effects. Under 21 CFR 314.80, an applicant must report each adverse drug experience that is both serious and unexpected as soon as possible and no later than 15 calendar days from initial receipt of the information.⁷ (Biologics follow a parallel rule at 21 CFR 600.80.) Your pharmacovigilance and legal teams will already have decided, through vendor agreements, how a partner’s knowledge of an event is handled. The data question is narrower: when an AI tool reads or summarizes hub or field records, can you show that every potential safety report it encountered went to the safety team on time, and can you link the hub record to the resulting safety case?

Claims and Prescription Data: Licensed, Lagged, and Partial

Licensed claims and prescription data is the backbone of commercial analytics: targeting, segmentation, market share, and patient finding all run on it. It is also the source whose limits are least visible to the people building models, because the limits are written in contracts and methodology documents rather than in the data itself.

The License Defines What a Model Can Learn From

Data licenses specify permitted uses, permitted users, permitted combinations with other data, and what happens to derived data when the license ends. Many were signed for reporting and analytics, before anyone asked whether the data could be used to train a model whose weights would outlast the contract. The 2025 Veeva survey found that 62% of companies spend up to 200 days working through third-party access agreements just to use data they already license, and respondents described those agreements as a point where initiatives stall before they start.¹

For AI, the questions to put to each license are specific. Can the data be used to train a model, or only to score one? Can it be combined with hub, CRM, or other vendors’ data in the same training set? Can a vendor such as a model developer or cloud AI service process it? What happens to a trained model if the license is not renewed? If those answers are unknown, the data is not AI-ready, however clean it is.

Partial Coverage and Lag

No single claims or prescription source sees every patient. Coverage varies by payer channel, by pharmacy type, and by site of care, and products dispensed through limited specialty networks or administered in a clinic may be poorly represented in retail prescription data. Claims also arrive with a lag, and recent periods are often projected or revised as later claims come in. The 2026 launch survey found that 98% of brands use at least two data providers, which reflects this: teams buy several sources to cover each other’s gaps.³

Buying more sources does not remove the problem. It creates a new join between vendors, each with its own patient tokens, its own prescriber attribution rules, and its own projection methods. A patient-finding model trained on one vendor’s data and scored on another’s can drift for reasons that have nothing to do with patients.

Joining De-Identified Data Changes Its Status

Most licensed patient-level data is de-identified under the HIPAA Privacy Rule, usually through expert determination. Under 45 CFR 164.514(b), that method requires a qualified expert to determine that the risk is very small that the information could be used, “alone or in combination with other reasonably available information,” by an anticipated recipient to identify an individual, and to document the analysis.⁹ The determination covers a specific data set and a specific recipient context.

This is directly relevant to AI work. When a team joins a de-identified claims set to hub data, CRM data, or another vendor’s tokens, the combined data may no longer fit within the original determination. Tokenization vendors handle this by requiring a fresh expert review for new combinations, but internal teams building training data do not always know to ask. The join that makes a model more accurate can also be the join that puts the data outside its approved use.

HCP Master Data: The Key Every Other Join Depends On

Every commercial join that involves a prescriber goes through HCP master data. CRM activity is joined to prescribing through the HCP. Hub referrals are attributed to the HCP. Claims are rolled up to the HCP and then to the account. If the HCP record is wrong, every join that passes through it inherits the error. We have covered matching approaches, survivorship rules, and affiliation modeling in detail in an earlier article on HCP and HCO entity resolution (linked below). This section focuses on what AI teams in particular need to know.

The NPI Is an Identifier, Not a Description

In the United States, the National Provider Identifier is the natural join key. It is stable, it is required on standard HIPAA transactions, and it appears in claims, prescriptions, and most hub data. Under 45 CFR 162.410, covered health care providers must report changes to their required data elements in the national system within 30 days.¹⁰ That rule is easy to read as a guarantee that NPPES data is current. The evidence says otherwise.

• A 2013 HHS Office of Inspector General evaluation of a random sample of Medicare providers found that provider data in NPPES was inaccurate in 48% of records, data in PECOS (the Medicare enrollment system) was inaccurate in 58%, and data was inconsistent between the two systems for 97% of records.¹¹
• A 2023 study in the Journal of Surgical Research compared NPPES taxonomy codes with department profiles for 295 surgeons at three academic institutions. 99% had chosen the correct general specialty, but only 64% had chosen an appropriate subspecialty. The authors concluded that the taxonomy was not accurate for describing a surgeon’s subspecialty or actual practice.¹²
• A CMS review of Medicare Advantage online provider directories, reported in January 2017, checked 11,646 provider locations and found that 45.1% had at least one inaccuracy. CMS named a common driver: group practices supply data at the group level, listing a provider at every location where the group has an office, even if that provider rarely or never sees patients there.¹³

These studies are dated and each covers a specific population, so none should be read as a current error rate for your data. Read together, they say something durable: public provider data is good at identifying who a provider is and much weaker at describing what they do and where. Those descriptive fields (subspecialty, practice location, affiliation) are exactly what targeting and segmentation models use as features.

Specialty Is the Attribute That Fails Across Markets

Outside the United States, there is no single national identifier to lean on, and specialty definitions differ by country. Veeva’s 2025 survey found that 95% of companies must remap global specialties to local ones.¹ One respondent said they had not seen a reliable solution anywhere in the world for maintaining HCP and HCO specialties. For a global segmentation model, specialty is often the most important feature, and it is the one least likely to mean the same thing in two markets.

What AI Teams Should Ask of the Master Data Team

AI teams rarely own master data, and they should not try to. What they can do is ask the right questions before they build:

• What is the measured match rate between this HCP master and each source we plan to join (CRM, hub, each claims vendor)?
• Which attributes we plan to use as features are steward-verified, and which are passed through from a vendor or from NPPES without review?
• How long does a data change request take to resolve? Veeva’s respondents reported two weeks for a simple name or address change.¹
• Are affiliation and specialty changes kept with effective dates, so a model can be trained on what was true at the time?

Consent: The Attribute That Has to Travel With Every Record

Consent is usually discussed as a compliance requirement at the point of collection. For AI, the harder question is what happens afterward. A patient signs a hub authorization. An HCP opts out of email. A website visitor withdraws consent. Each of those events changes what the data may be used for, and that change has to follow the record through every join into every analytics table, feature store, and training set. In most commercial data platforms, it does not.

Patient Data From Hubs and Pharmacies

Specialty pharmacies and many hub programs operate as or alongside HIPAA covered entities, and the data they pass to manufacturers about identified patients typically moves under a patient authorization. The HIPAA Privacy Rule defines marketing as making “a communication about a product or service that encourages recipients of the communication to purchase or use the product or service,” with exceptions such as refill reminders where any payment is reasonably related to the cost of making the communication.¹⁴ A covered entity must obtain an authorization before using or disclosing protected health information for marketing, and if a third party pays the covered entity for the marketing, the authorization must say so.¹⁵

Three features of a HIPAA authorization matter for data teams:

• Purpose. An authorization describes the purposes of the use or disclosure. A model trained for a purpose the authorization did not describe may be outside it.
• Expiration. Every authorization must include an expiration date or an expiration event.¹⁵ A training set built today may contain records whose authorization lapses next year.
• Revocation. An individual may revoke an authorization at any time, in writing, subject to limited exceptions such as action already taken in reliance on it.¹⁵ A revocation has to reach every downstream copy of the data that depends on it.

Whether a manufacturer’s own use of the data, once received, is governed by HIPAA, by the authorization’s terms, by contract, or by state law is a question for counsel and depends on how the program is structured. The data requirement is the same either way: the authorization’s purpose, expiration, and revocation status must be stored as attributes of the patient record and checked whenever that record enters a new use.

Patient Data That HIPAA Does Not Cover

Brands also collect health data directly: copay program sign-ups, website registrations, symptom trackers, and patient apps. When that data is not protected health information, state law and federal consumer protection law apply instead.

Washington’s My Health My Data Act is the clearest example. Its definition of consumer health data includes information about the use or purchase of prescribed medication.¹⁶ Since March 31, 2024, regulated entities that are not small businesses may collect consumer health data only with consent for a specified purpose or as needed to provide a service the consumer requested, and may share it only with consent “that is separate and distinct from the consent obtained to collect consumer health data.”¹⁶ The request for consent must disclose the categories of data, the purposes including the specific ways it will be used, the categories of recipients, and how the consumer can withdraw. The Washington Attorney General’s guidance confirms the section-by-section effective dates and that violations are enforced both by the Attorney General and through private action under the state Consumer Protection Act.¹⁷ The Act exempts information that is protected health information under HIPAA, which is one more reason to know which regime each record falls under.¹⁶

At the federal level, the Federal Trade Commission’s amended Health Breach Notification Rule, effective July 29, 2024, clarifies that it applies to health apps and similar technologies not covered by HIPAA, and the FTC treats unauthorized disclosure of health information by such a product as a breach, not only a security intrusion.¹⁸ For a brand app that shares data with an analytics or AI vendor without the user’s authorization, that is a live exposure.

HCP Consent and Preferences

HCP consent is a separate body of rules, especially in Europe, and we covered it in depth in an earlier article on field force data privacy (linked below). For AI teams, the practical point is the same as for patients: an HCP’s channel preferences and objections have to be available at the moment a model scores that HCP and at the moment an orchestration tool acts on the score. A model that recommends an email to an HCP who has opted out is not only unhelpful. It creates a compliance event.

A Join-Readiness Test Before You Scale

The surveys suggest the industry’s problem is not starting AI pilots. It is scaling them. The most common reason a commercial pilot fails to scale is that it worked on joins someone fixed by hand in one brand or one market, and the fix did not travel. The test below is designed to make those joins visible before the rollout is funded rather than after it stalls.

Map the Use Case to Its Joins

Start by writing down, for one use case, every source it needs and every join between them. The table below shows the pattern for four common commercial use cases.

The pattern matches what the 2026 launch survey found: the use cases with the fewest joins are the ones most widely adopted, and the ones with the most joins are the ones lagging.³

Measure Four Things for Each Join

Set Thresholds Before You Build

Agree on thresholds for each measure before the model is built, with the business owner of the use case in the room. The thresholds will differ by use case. A segmentation model refreshed quarterly can tolerate more latency than a patient-finding alert. An adherence model needs a much higher patient-identity match rate than a market share report. The point of agreeing in advance is to stop the pilot team from setting the bar after they see what they can reach.

Fix the Worst Join First, Then Scale

Once the joins are measured, the worst one is usually obvious. Fix that one before adding features, models, or markets. The fix may be technical (a better matching method or an effective-dated alignment table), contractual (renegotiating a license or adding a field to a partner’s data agreement), or organizational (giving one person ownership of a status code map). Then re-run the measurements and move to the next.

When the use case moves to a second brand or market, run the test again. The joins in the new setting will be different: other partners, other vendors, other consent rules. Scaling AI in commercial biopharma is mostly the work of repeating this test reliably, not of building better models.

Conclusion

The survey figures are real, if often misquoted: almost all of the senior commercial leaders Veeva surveyed say their data is not ready to scale AI, and almost as many say most of their AI work has not scaled. The more useful finding is underneath them. AI is being adopted where data does not need to be joined and stalling where it does. Commercial data in biopharma is a set of joins across CRM, specialty pharmacy and hub data, licensed claims and prescription data, HCP master data, and consent records, and two of those five sources belong to someone else, with two more depending partly on outside vendors. A pilot works when someone hand-fixes those joins in one place. It fails to scale when the fixes are not measured, owned, or written down.

That reframing turns a vague goal (“get our data AI-ready”) into a list of specific, measurable problems: a status code map, a patient identity link, an effective-dated alignment table, a license clause, a consent attribute. Sakara Digital works with pharma and biotech organizations to sort out exactly this kind of commercial data foundation. If you are trying to understand why a commercial AI pilot will not scale, or want an independent view of which joins to fix first, we are happy to have that conversation.

For Further Reading