Sixty-Eight Percent Blamed Data Quality: Reading the 2026 CDIO Research on Why Pharma AI Fails

What ZS Actually Asked, and Who Answered

Before a statistic gets repeated in a board deck, it is worth knowing where it came from. ZS is a consulting and technology firm that has, in its own words, spent the past three years tracking how pharma and biotech organizations approach AI. The 2026 edition of its CDIO Research was published in October 2025 under the title “Scaling AI in pharma and biotech.”¹ The name “CDIO” refers to chief data and digital officers, though the respondent pool is broader than that title suggests.

The survey itself was conducted by Harris Poll on behalf of ZS and fielded in July 2025. It reached 115 United States based technology executives at pharmaceutical and biotechnology companies. ZS reports that 62 percent of respondents were executive-level (CDIO, CIO, or CTO) and the remainder were senior decision-makers below that level. Thirty-six percent of respondents came from companies that ZS describes as having 30 billion dollars in annual revenues. ZS supplemented the survey with interviews of 12 CIOs from large multinational companies.¹

The exact wording of the finding

The sentence in ZS’s own publication reads: “68% say to neglect data quality and governance early is the main reason AI initiatives fail.”¹ The report later summarizes the same section as “Top causes of AI failure: weak data quality and governance (68%), unclear objectives (67%) and lack of business ownership (63%).”¹

Three things follow from that wording. First, the figure is confirmed on ZS’s own page, so the premise of this article holds and the title stands. Second, the three percentages add up to well over 100, which means respondents were allowed to select more than one cause. The 68 percent is the share of respondents who included data quality and governance among the reasons, not the share who ranked it first above everything else. Third, the phrase is “neglect data quality and governance early.” The timing word matters. Respondents were not saying their data is bad. They were saying that data quality and governance work was left until too late in the program.

The surrounding findings

The 68 percent is part of a larger picture that is more useful than the headline on its own. According to the report, just 40 percent of AI pilots make it to scaled deployment. Nearly half of respondents say they are already consistently demonstrating measurable value through enterprise technology and data operations (49 percent) and commercial sales and marketing efforts (47 percent). In discovery, only 17 percent say they can prove measurable value today, though 42 percent expect value within the next year. Supply chain and manufacturing came in at 29 percent, and clinical development at under a third.¹

ZS also asked about growth priorities and pressures. Nine in ten technology leaders see the combination of higher healthcare expectations, competitor science, AI disruption, and regulatory friction as active threats to growth. Their top priorities for sustaining growth are accelerated discovery (52 percent), patient engagement (43 percent), portfolio diversification (36 percent), new revenue streams (33 percent), and partnerships that strengthen capabilities (31 percent).¹

On the investment side, the report says CIOs are increasing spending on cloud and infrastructure (88 percent), data products and platforms (86 percent), AI platforms (84 percent), and IT and DevOps tools (79 percent) over the next 12 months. On agentic automation, 45 percent plan to create agentic workflows in IT operations and 41 percent have similar plans in R&D discovery.¹ The operating-model section reports that 61 percent feel pressure on technology and data capabilities, 58 percent on talent and skills, and 56 percent on business engagement and decision-making, and that 86 percent are testing or making changes to roles and teams.¹

The report’s closing recommendation is about operating models rather than data. ZS advises leaders to reassess their operating model through a three-year outcomes lens and decide what should remain, what should adapt, and what should be abandoned. Its companion piece for technology leaders, a guide to scalable AI practice, argues for a purpose-built data strategy, reusable data products that connect structured and unstructured data, shared guardrails with federated oversight, and compliance, security, and privacy treated as first principles rather than afterthoughts.²

Reading the 68 Percent Critically

A number that agrees with what you already believe deserves more scrutiny, not less. Most people in life sciences data and quality roles already think data quality is the thing that breaks AI programs. The ZS figure confirms that belief, which is exactly why it is worth slowing down on.

Who was asked

The respondents are technology executives. They are not quality leaders, clinical operations heads, manufacturing directors, or the scientists who generate the data. When a CIO or CDIO is asked why an AI initiative failed, “the data was not ready” is a comfortable answer. It places the cause upstream of the technology function, in data that the business generated and the business owns. That does not make the answer wrong. It does mean the survey captures the technology function’s view of the problem, and a survey of quality heads or business sponsors might weight the three causes differently.

The sample also leans large. More than a third of respondents work at companies ZS places at 30 billion dollars in revenue, and the interview panel was drawn entirely from large multinationals. Those companies have data estates built up over decades of acquisitions, dozens of overlapping systems, and governance functions that already exist on paper. A mid-size company’s data problem is usually different in kind, which we come back to below.

What “fail” means

The report does not define failure. Reading it alongside the 40 percent pilot-to-scale figure, the most natural interpretation is that a failed initiative is one that did not scale or did not deliver measurable value. That is a broad definition. A pilot that produced a good model but never got a budget for production would count. So would a pilot that was cancelled because the business sponsor changed roles. The 68 percent is therefore an answer to a loose question, and it should be quoted as a signal of where experienced technology leaders think the risk is, not as a measured rate of data-caused failures.

What it is not

It is not a finding that 68 percent of pharma AI projects fail because of data. It is not a finding about the state of the industry’s data. And it is not evidence that fixing data alone would raise the 40 percent scaling rate. ZS’s own recommendation, which is about the operating model rather than data, makes clear that the report’s authors do not read it that way either.¹

The Other Two Causes Are Almost Tied

The single most useful thing about the ZS finding is the company it keeps. One percentage point separates data quality and governance (68 percent) from unclear objectives (67 percent), and five points separate it from lack of business ownership (63 percent). Elsewhere the report puts the objectives point more sharply: “Nearly seven in 10 (67%) warn that launching an AI initiative without clear goals and success metrics is a mistake.”¹

Anyone who has run a data quality program will recognize that these three causes are not independent. They are the same failure seen from three angles.

Unclear objectives make data quality undefinable

Data quality is not a property of data. It is a relationship between data and a purpose. A batch record dataset that is perfectly adequate for deviation trending may be useless for training a model that predicts yield, because the fields the model needs were never captured consistently. If the AI initiative has no clear objective, nobody can say which data it will consume, which attributes of that data matter, or what “good enough” looks like. Data quality work started under those conditions either becomes a general cleanup that never ends or gets skipped because nobody can justify its scope.

No business owner means no one can decide what good looks like

Even with a clear objective, someone has to decide the acceptance criteria. Is a 4 percent missing rate in a critical field acceptable? Can two site naming conventions be merged? Who signs off that the reference ranges in the historical lab data are the ones still in use? These are business decisions, and they need a business owner with authority over the data. When ownership is missing, the technology team either makes those calls itself, which quality will later challenge, or waits for a decision that never comes.

The practical reading

Taken together, the three ZS causes describe a program that started building before it decided what it was building, for which data, under whose authority. “Neglecting data quality and governance early” is the visible symptom. The other two are why it was neglected. This is why the three investments later in this article are framed around a specific use case with a named owner, rather than as a general data quality initiative.

Percentages from ZS 2026 CDIO Research.¹ The practical descriptions are our own.

What Other 2026 Research Says, and Where It Disagrees

A single survey of 115 people is a data point, not a consensus. Fortunately, several other groups asked overlapping questions of different populations between late 2025 and mid-2026. Reading them together is more informative than any one of them alone.

Pistoia Alliance: two conference polls, six months apart

The Pistoia Alliance polled attendees at its US conference in Boston on December 3, 2025. Lab Manager’s report on the poll puts the participation at more than 170 people from pharma, technology, and academia.⁵ The Alliance’s own press release reports that more than one in four life science professionals (27 percent) do not know what scientific content their organization’s AI or LLM systems use, or rely only on titles and abstracts; that only around one in three (36 percent) are plugging internal documents into models; that 38 percent say their copyright and licensing policies are unclear or not enforced; and that half (50 percent) identified the lack of shared verification standards as the biggest barrier to agent adoption. From its separate Lab of the Future survey, more than a third (34 percent) cited a shortage of skilled talent as a barrier.³

The Alliance polled again at its London conference at the Royal Society of Medicine on April 29, 2026, an event attended by 300 industry leaders, with the poll sponsored by Thoughtworks. Almost a third (30 percent) said their organization has implemented an enterprise-wide AI platform, yet 69 percent lack clear metrics to assess AI’s impact on reducing the cost or time required for drug R&D, and just 4 percent report tangible benefits of AI for R&D leadership. Asked what their companies need to prioritize, 59 percent said data quality and accessibility and 22 percent said AI adoption and change management. On where AI is delivering, 54 percent pointed to regulatory submissions and reporting teams, 21 percent to research analysis, 13 percent to automating scientific workflows and experiments, and 1 percent to the wet lab.⁴

Bio-IT World’s Allison Proffitt reported on the same body of Pistoia work in January 2026, drawing on an interview with Christian Baber, the Alliance’s Chief Portfolio Officer. Her piece says the challenge of AI-ready data was cited by roughly half of survey respondents and had intensified because machine learning models require data in machine-readable formats rather than the reports scientists have historically shared. Baber’s recommendation was to record data in machine-readable formats with proper metadata from the outset. The piece also notes that only 9 percent of Lab of the Future respondents saw regulation as a barrier to AI, down from 23 percent in 2024.⁶ In a May 2026 R&D World interview, Baber extended the argument, describing the core difficulty of measuring AI impact as a question of agency and control: human in the loop, AI in the loop, or nothing in the loop.⁷

Benchling: a survey of organizations already deploying AI

Benchling’s 2026 Biotech AI Report surveyed roughly 100 biotechnology and pharmaceutical organizations in the United States and Europe in November 2025. Respondents were scientists, technologists, and executives across discovery research, process and analytical development, bioanalytical science, and safety and toxicology, and all of them were actively deploying AI. The report’s line on failure is direct: “The reported number one reason AI pilots fail is due to challenges with data quality.” It describes adoption barriers in generative design, biomarker analysis, and ADME where data is scattered, incomplete, and hard to validate.⁸

At the BIO 2026 AI Summit in San Diego on June 22, 2026, Benchling’s CEO Sajith Wickramasekara presented the same survey. GeneOnline’s report of the session says over half of surveyed organizations identified data availability and quality as primary challenges during their pilot programs, and that only 23 percent currently report a cost reduction impact while 50 percent report faster science.⁹

Deloitte: the executive view in mid-2026

Deloitte’s midyear 2026 life sciences outlook, published June 25, 2026, surveyed 150 C-suite and senior executives (90 from biopharma, 60 from medtech) in April 2026 across the United States, Europe, and Asia. Seventy-one percent said AI deployment had advanced at least somewhat compared with six months earlier, 35 percent reported significant progress in agentic AI including enterprise-wide rollout or scaling, and 45 percent said their AI initiatives had produced measurable improvement, including 13 percent who reported measurable improvements at scale.¹⁰ Deloitte did not ask why initiatives fail, but the 13 percent at-scale figure is consistent with the ZS picture of a wide gap between activity and proven value.

Gartner: the cross-industry baseline

For a view outside life sciences, Gartner’s February 2025 briefing with analyst Roxane Edjlali reported that 63 percent of organizations either do not have or are unsure whether they have the right data management practices for AI, based on a July 2024 survey of 1,203 data management leaders. Gartner predicted that through 2026, organizations would abandon 60 percent of AI projects unsupported by AI-ready data. Edjlali’s framing is worth keeping: AI-ready data is not “one and done,” and proving the readiness of data is a process and a practice based on the availability of metadata to align, qualify, and govern the data.¹¹

Where the sources agree

Every source that asked the question puts data quality at or near the top. ZS at 68 percent among technology executives, Pistoia at 59 percent among conference attendees, Benchling as the reported number one reason among organizations already deploying, and Gartner at 60 percent projected abandonment across industries. The populations differ, the question wording differs, and the answer does not move much. That consistency is the strongest reason to take the finding seriously.

Where they disagree

The disagreement is about what appears beside data quality, and it is instructive.

• Measurement versus data. ZS’s respondents rank unclear objectives one point behind data quality. Pistoia’s April 2026 respondents make the measurement gap the bigger headline: 69 percent lack metrics, against 59 percent naming data quality. Read together, the two surveys suggest that the industry cannot tell whether its data is good enough partly because it has not said what the AI is for.
• Governance versus verification standards. ZS pairs data quality with governance in one phrase. Pistoia’s December 2025 respondents identified the absence of shared verification standards for AI agents as the single biggest barrier (50 percent), which is a governance problem the industry cannot solve one company at a time.³
• Data quality versus data culture. The Bio-IT World reporting adds a cause ZS’s survey did not offer as an option: scientists who prefer to present conclusions in reports rather than share raw data for reanalysis.⁶ That is neither a quality defect nor a governance gap in the usual sense. It is an ownership and incentive problem, which maps to ZS’s third cause more than its first.
• Where the value is. Pistoia’s finding that 54 percent see the greatest benefit in regulatory submissions and reporting while 1 percent see it in the wet lab⁴ is a reminder that the data quality bar depends on the use. Document-heavy regulatory work runs on text that is already curated. Lab AI runs on instrument data that, as Benchling puts it, is scattered, incomplete, and hard to validate.⁸

Why the Finding Reads Differently at a Mid-Size Company

More than a third of ZS’s respondents work at companies ZS places at 30 billion dollars in revenue, and every interviewed CIO came from a large multinational.¹ A company with 300 employees, two clinical programs, and a CDMO doing its manufacturing is not living in the same data world, and the 68 percent needs translating before it is useful there.

The data estate is smaller but more outsourced

A large pharma company’s data quality problem is often one of volume and duplication: the same molecule under four identifiers across twelve systems. A mid-size company’s problem is more often that the most important data was generated by someone else. Clinical data lives with a CRO, manufacturing and stability data with a CDMO, bioanalytical data with a specialist laboratory. Data quality at a mid-size company is therefore inseparable from contract terms and transfer formats. WHO’s data integrity guideline addresses this directly in its outsourcing section: the outsourcing of activities, ownership of data, and responsibilities of each party should be clearly described in written agreements, with provisions for responsibilities relating to data when an agreement expires.¹²

There is no governance function to neglect

At a large company, “neglecting governance early” means an existing data governance office was not brought into the AI program. At a mid-size company there is frequently no such office. Data governance is a part-time responsibility of a head of IT, a QA director, or a clinical data manager. That has a real advantage: decisions can be made quickly by people who know the data. It also means that the three investments described below have to be sized for a team that will never have a dedicated stewardship department.

The use case count is small, so the baseline can be specific

A large company may have dozens of AI use cases competing for the same data foundation, which pushes it toward general-purpose data platforms and enterprise-wide quality programs. A mid-size company typically has two or three use cases that matter in the next year. That makes it possible to do what the ZS respondents wish they had done: define data quality for the specific data each use case consumes, before building, and stop there. General data cleanup is the one investment a mid-size company cannot afford, and it is also the one it least needs.

Investment One: A Data Quality Baseline for the Data the Use Case Will Consume

The first investment is a documented, measured statement of the current quality of the specific data an AI use case will train on and run on. Not the enterprise’s data. This data, for this purpose.

Why it comes first

Regulators have already written the principle. ICH E6(R3), finalized in January 2025, states in Principle 9 that “the quality and amount of the information generated in a clinical trial should be fit for purpose and sufficient to provide confidence in the trial’s results and support good decision making,” and that systems and processes for data capture, management, and analysis “should be fit for purpose.”¹³ Section 3.16.1 directs sponsors to “focus their quality assurance and quality control activities, including data review, on data of higher criticality and relevant metadata.”¹³ WHO’s guideline defines data governance as “the sum total of arrangements which provide assurance of data quality” and calls for a data integrity risk assessment that maps the procedures and systems that generate data, identifies the risks, and implements proportionate controls.¹²

An AI use case is a new purpose for existing data, and often a more demanding one than the purpose the data was collected for. Data collected to support a batch release decision was reviewed by a person who could read around a missing entry or an inconsistent unit. A model cannot. The baseline is the act of asking, for this new purpose, whether the data is fit for it.

What the baseline contains

What it is not

The baseline is not a data cleanup. Cleanup happens afterward, scoped by the gap list. It is not an enterprise data catalog, though a catalog can hold it. And it is not a one-time deliverable: the same measurements become the reference point for Investment Three. Gartner’s five steps for AI-ready data begin with exactly this move, aligning data to the AI use case and identifying the governance requirements for it before preparing pipelines and assuring the data.¹¹

Investment Two: Named Ownership and Stewardship for That Data

The second investment answers ZS’s third cause directly. Sixty-three percent of respondents named lack of business ownership as a reason AI initiatives fail.¹ Bio-IT World’s reporting on the Pistoia work describes the human version of the same problem: scientists who resist relinquishing control of their data, preferring to present conclusions in reports rather than provide raw data for reanalysis.⁶

Ownership is a decision right, not a title

The failure mode is not that nobody cares about the data. It is that nobody has the authority to make the decisions the baseline surfaces. Who decides that two sites’ naming conventions are equivalent? Who accepts that a historical assay’s reference range differs from the current one and tells the model builders how to handle it? Who signs the acceptance thresholds? At a large company these decisions can route through a governance council. At a mid-size company they need a named person per data domain who can make them in a week.

WHO places the ultimate responsibility with senior management, which “is responsible for providing the environment to establish, maintain and continually improve the quality culture,” and says data governance should be embedded in the quality system with the necessary policies, procedures, training, monitoring, and other systems implemented.¹² That is the top of the structure. The working level needs two roles.

Why the incentive problem needs a decision, not a policy

The cultural resistance Baber describes, in which scientists keep raw data close and share only conclusions, will not be fixed by a data sharing policy. It changes when the owner of the domain decides that raw, machine-readable data with metadata is the deliverable of the work, and says so in the objectives that people are measured on. Baber’s advice to record data in machine-readable formats with proper metadata from the outset⁶ is an ownership decision dressed as a technical one. Somebody has to require it.

The AI-specific addition to ownership

Traditional data ownership stops at the boundary of the system that holds the data. AI use adds one more question: who owns the data once it has been transformed into a training set or a feature table? That derived data will be used to justify a model’s fitness, will be needed again when the model is retrained, and may be asked for by an inspector who wants to understand what the model learned from. Assign it to the same owner as the source domain, with the steward maintaining lineage from source to training set. Gartner’s point that AI readiness rests on the availability of metadata to align, qualify, and govern the data¹¹ is really a point about lineage: without it, nobody can say what the model consumed.

Investment Three: A Reconciliation and Monitoring Layer After Go-Live

The third investment is the one most often skipped, and it is the reason “neglecting data quality early” produces failures that show up late. A model validated on a baseline of historical data is only as good as the data still is. Data changes. Sites change their practices, a CDMO upgrades its LIMS and the export format shifts, a new assay replaces an old one with a different reference range, and a field that was mandatory becomes optional. None of those changes announce themselves to the model.

The regulatory framing already exists

WHO’s definition of the data life cycle includes all phases in which data are created, recorded, processed, reviewed, analyzed and reported, transferred, stored, retrieved “and monitored, until retirement and disposal,” and states that there should be a planned approach to assessing, monitoring, and managing the data and the risks to those data, proportionate to the potential impact on patient safety and product quality.¹² ICH E6(R3) asks sponsors to ensure documented processes are implemented for data integrity across the full data life cycle.¹³ Gartner’s version is blunter: AI-ready data is not “one and done,” and the practice needs constant improvement based on existing and upcoming AI use cases.¹¹

What the layer does

The monitoring layer has two jobs, and they are different.

Reconciliation: does the data the model receives match the source?

Reconciliation compares what arrived in the model’s input against what exists in the system of record, on a schedule. Record counts by period and site. Sums or distributions of critical numeric fields. Presence of every expected batch, subject, or sample. Reconciliation catches transfer failures, partial loads, duplicate loads, and silent format changes from a contract partner. It is the same discipline a clinical data manager applies to a lab data transfer, pointed at the AI pipeline.

Monitoring: is the data still within the baseline?

Monitoring re-runs the baseline measurements from Investment One on each new slice of data and compares them with the thresholds the owner signed. Completeness of each critical field. Share of values within valid ranges. Distribution of key variables against the training period. New categorical values that were not in the definitions. When a measurement moves outside its threshold, the steward gets an alert, and the owner gets a decision to make: accept, remediate, or suspend the model’s use until the cause is understood.

Why it belongs in the budget from the start

The monitoring layer is the operational part of the AI use case, and it needs people and money after the project team has moved on. This is where ZS’s operating-model recommendation and its data finding meet. A pilot that was funded as a project, with no operating budget for the steward’s time or the alerts, will decay. The ZS report’s pilot-to-scale rate of 40 percent¹ and Deloitte’s finding that only 13 percent of executives report measurable improvements at scale¹⁰ are both, in part, descriptions of pilots that had no plan for the year after go-live.

Sizing for a mid-size company

The layer does not need a platform. For one use case it can be a set of scheduled queries, a small dashboard, and a triage procedure that names the steward and the owner. What it does need is to be written down, validated to the extent the use is GxP-relevant, and reviewed periodically. WHO’s management review section expects data integrity to be part of the management review cycle,¹² and adding the AI data monitoring results to that review is a low-effort way to keep senior attention on it.

Sequencing the Three Investments Around a Real Use Case

The three investments are cheaper together than apart, and they are only meaningful in the context of a specific use case with a defined objective. That is the practical answer to the ZS trio: fix the objective, name the owner, and then do the data work for that objective under that owner.

A sequence that fits a mid-size program

1. Pick the use case and write the objective in one sentence with a metric. “Reduce the average time from batch completion to disposition by 20 percent by flagging records likely to need review.” If the sentence cannot be written, the 67 percent cause applies and the data work should wait.
2. Name the data owner and steward for each domain the use case touches. Two or three people. Put it in writing with the decision rights described above.
3. Run the baseline for that use case’s data. Inventory, criticality, measurement, thresholds, gap list. The owner signs the thresholds. QA reviews the criticality ratings.
4. Remediate only the gaps on the list, and only to the threshold. Resist the pull toward general cleanup. A gap that cannot be closed becomes a documented limitation in the model’s intended use.
5. Build the reconciliation and monitoring checks before the model goes live, from the same measurements as the baseline. Fund the steward’s time for the year after go-live in the project budget.
6. Add the monitoring results to the existing management review. No new meeting. One slide in a review that already happens.

What this does to the three ZS causes

Step one addresses unclear objectives. Step two addresses business ownership. Steps three through six address data quality and governance, early, for the data that matters, in a way that persists after go-live. The sequence does not guarantee the use case will deliver value. It does mean that if it fails, it will fail for a reason that has nothing to do with the three causes that 63 to 68 percent of ZS’s respondents reported, and the program will be able to say so with evidence.

What it does not require

It does not require an enterprise data platform, a data governance office, or a company-wide data quality program. Those may be right for a company with the revenue profile of ZS’s respondents. For a mid-size pharma or biotech with two or three use cases, they are the expensive way to neglect data quality early: a large investment that is still being designed when the model builders need answers.

Conclusion

The ZS finding is accurate as reported and less dramatic than it sounds. Sixty-eight percent of 115 technology executives, most of them at large companies, said that neglecting data quality and governance early is a main reason AI initiatives fail, and almost as many said the same about unclear objectives and lack of business ownership. Pistoia Alliance, Benchling, Deloitte, and Gartner asked different people different questions in the same twelve months and landed in the same place, with useful disagreements about what appears beside data quality: measurement, verification standards, and a data-holding culture in the lab. The practical reading is that the three causes are one problem. Programs that start building before they have written down what the AI is for, which data it consumes, who owns that data, and how it will be kept fit for purpose are the programs that later report a data quality failure.

For a mid-size pharma or biotech, the response is not an enterprise data program. It is three scoped investments made around each real use case: a measured baseline for the data it consumes, named ownership and stewardship with real decision rights, and a reconciliation and monitoring layer that keeps the data within its baseline after go-live. All three are already expected, in slightly different language, by WHO’s data integrity guideline and ICH E6(R3), so they strengthen the compliance position at the same time as the AI outcome. Sakara Digital works with pharma and biotech organizations building this kind of use-case-specific data foundation. If you are deciding where to start, or trying to work out why a pilot has stalled, and want an independent perspective, we are happy to have that conversation.

For Further Reading