Data Is A Process, Not A Project

Written By Sarah Andrews

An uncomfortable claim: In pharma, biotech, and any serious applied AI, projects almost never fail because of the model.

They fail because of the data.

When a model underperforms, AI teams search for solutions that more obviously look like progress:

They want a larger architecture, more compute, another round of tuning.

These solutions tend to be complex, prestigious and – for lack of a better word – exciting.

Meanwhile, the work that actually determines whether the model is learning and applying anything useful – questioning labels, reconciling expert disagreement, documenting provenance, investigating missing data – gets all but forgotten.

The result: a lot of expensive work on the wrong part of the system.

Everyone agrees that data matters.

But not everyone is interested in funding the (admittedly) tedious, continuous work needed to keep it useful.

Labels change, and populations do too; instruments are replaced, experts disagree, and new data constantly arrives with new errors. But responsibility for all of this is routinely either left behind or spread across too many different teams until, in practice, it belongs to no one.

Two useful tests

  • First: Take the training sets behind your most important models, and for each one, ask how your team handles its quality. It’s completely normal for different individuals to be responsible for different datasets; you don’t need a single named owner for everything. But if the answer for any given dataset is “no one is handling it”, it’s already in trouble.

  • Second: Think back to the last time one of those datasets degraded – labels went stale, the patient population shifted, an assay changed. How did you find out? Even the best-run teams will still discover some things in production; that’s unavoidable. The telling question is whether you only catch them after they break. If the first sign of trouble was a downstream metric tanking and a scrambled team hunting for a root cause, then your real monitoring system was your users. And it raises another question: are other meaningful data drifts going unnoticed, just because they haven’t broken something in production yet?

Both questions point at the same underlying misconception: treating data quality as a property a dataset either has or does not have – something you establish once, at the start of a project, and then check off.

But a dataset is only ever fit, or unfit, for a particular purpose – and that fitness can decay.

Models drift as the world changes, human labels always hide errors, and borrowed datasets never transfer neatly.

The only solution is this:

Data work has to run as a standing program, owned, scheduled, and budgeted, not as a one-time cleanup at the start of a project.

The work nobody wants to do

Researchers at Google interviewed builders working on AI systems for high-stakes use cases – health, conservation, etc. – and found what they called “data cascades”: small data problems that occur early in a project and compound into large and expensive failures downstream.

These “cascades” occurred in 92% of projects, and 45.3% of practitioners reported two or more in a single project; the worst ones took two to three years to surface and only became visible after the system was already deployed.

A healthcare practitioner they interviewed inspired the title of their paper, “Everyone wants to do the model work, not the data work”, because the field treats models as the source of prestige and the catalyst for career growth; meanwhile, data is treated as a chore, something to get through as quickly as possible so the real work can begin.

When data work is rushed, under-resourced, and largely invisible, the problems it creates stay hidden until they become a huge cost and a harder problem to fix.

Most researchers, if pressed, will agree that data is important, and nobody wants to admit that they don’t value it.

The reason it keeps failing is that the work of maintaining it has no owner, no glamour, and no driving incentive.

AI pioneer and Stanford professor Andrew Ng – who co-founded Google Brain and served as Chief Scientist at Baidu – gives the often-cited example of a steel-defect inspection problem:

The baseline model reached 76.2% accuracy. A team spent two months tuning the model and architecture with no improvement; but a team focused on improving the data instead reached 93.1% in about two weeks. His conclusion: “Improving the data is not a preprocessing step that you do once. It’s part of the iterative process of model development.” To prove that data quality trumps algorithm tweaking, Andrew Ng launched the Data-Centric AI Competition, where organizers locked the model architecture and challenged teams to win solely by improving the dataset.

When engineers clean their data, they unlock massive performance gains; but when they ignore data hygiene, their projects can fail without any warning that the data was broken.

The real bottleneck is expert time

Labeling image data is the bottleneck because it takes more human labor than anything else – and that labor doesn’t come cheap.

A radiologist takes about 60 minutes to segment brain tumors in one patient’s multi-sequence MRI; but the median hourly rate for a radiologist in the US (equating to one labeled scan) is around $221, making a dataset of a few thousand scans an expensive project.

And you can’t route around this by cutting corners on labelers.

When non-expert crowd workers and experts are compared across language tasks, the results find you need roughly four non-experts to match one expert – and that’s for tasks that don’t require specialized knowledge. For reading an MRI or judging a tumor margin, non-experts can’t substitute for any number of domain workers.

Worse still, experts often disagree, which puts a hard ceiling on how clean your data labels can be. Even for well-defined structures, radiologists’ segmentation isn’t perfect – and the moment you introduce ambiguous boundaries like tumor margins, agreement plummets.

But you can’t just treat expert disagreement as useless noise and filter it out, either; it’s a real feature of the data, meaning a certain amount of variability is permanently baked in. Biomedical data is sparse, and every expert has their own natural annotation style. Because this high inter-rater variability is unavoidable, the instructions you write for your annotators matter just as much as the experts you hire.

Active learning is one way to efficiently utilize expert time: Instead of having experts go through and methodically label a massive dataset piece by piece, you surface only the examples where the model is most uncertain – the edge cases that teach it the most. The time savings in medical imaging can be huge; in fact, some studies show that models can reach peak performance with only a fraction of the typical labeled data.

But active learning still only lets you manage your bottleneck, not eliminate it; human experts have to remain in the loop, no matter how much they cost, and that loop has to be real and ongoing. One-and-done won’t solve the problem, no matter how much it might reduce costs.

Borrowed data is not your data

The shortcut is to grab a public dataset or a model pretrained on it and assume it transfers to your problem, but usually it won’t.

When researchers at Mt Sinai used large, publicly available chest X-ray datasets to train AI to detect pneumonia, the models achieved near-perfect accuracy in the lab, but as soon as they were transferred to new hospitals, they failed. The AI had never actually learned to spot disease on its own; it had primarily learned to recognize where the scan was taken. Since each department of each hospital had its own image acquisition protocol, this was relatively straightforward; and since the ER typically looked at more advanced cases than the outpatient department – and portable scanners were reserved for patients too unstable to be moved – recognizing the department could seem like “expertise” in recognizing the severity of disease.

If you aggregate bioactivity data from public databases, you inherit everyone else’s noise. Different labs use different protocols, and even the strictest data curation can’t magically erase that variability. There’s also a hidden trap: survivorship bias. Public datasets are packed with molecules that worked, because failures rarely get published. If an AI only learns from the “winners”, its predictions get skewed, making it much harder to successfully evaluate totally new molecules in the real world.

A workaround is to train your AI on specialized data; a major study called RadImageNet tested this by pitting models trained on 1.35 million medical images against models trained on ImageNet’s everyday images of dogs, cats, and cars. Initially, specialized data appeared to be the clear winner, boosting accuracy on ultrasounds and MRIs. But a follow-up study showed those everyday photos were still competitive; the “specialized data advantage” was surprisingly fragile, depending heavily on the AI’s underlying architecture.

Domain-specific training can give you an edge, but it’s no magic wand – you still have to test it against your own messy, real-world data, and you still have to work and rework the data to keep it clean and clear.

You can measure how bad your labels are

But how do you know if your data is actually any good?

According to Google’s “data cascades” researchers, you can’t just look at standard scoreboards like F1 or AUC. Those metrics only prove how well your model performed on the dataset; they don’t tell you if the dataset itself is garbage. To measure “goodness-of-data”, you need specific tools. You can use confident learning libraries like Cleanlab to automatically hunt down label errors, or agreement metrics like Cohen’s kappa to figure out how often your human experts are arguing over the right answer.

Most importantly, you have to remember that data hygiene isn’t a one-and-done chore that will ever give you a locked-in “good enough” rating. It has to happen constantly, on a strict schedule, because a dataset that was perfectly clean last quarter is never guaranteed to stay that way once fresh data starts flowing in.

If you put all this together, you get a golden rule for specialized AI: Spend your budget on data before you spend it on compute. Any investments in data accumulate and compound. Every training run that comes after benefits from that. Switching to a bigger model just increases the cost of every subsequent training run.

When model performance underwhelms, the instinct is often to throw a bigger, more expensive training run at the problem. People love to cite “scaling laws” to justify this – and to be fair, those laws can work when you are operating at foundation-model scale. But that isn’t the reality for most teams working in applied AI in biopharma today. In specialized domains, a small model trained on crystal-clear data will run circles around a massive model trained on garbage. If bad data is your actual bottleneck, adding more compute just helps the AI learn the wrong things faster.

What pharma and life-sciences data actually looks like

“Missingness” in ICU and EHR datasets can reach as high as 80% due to measurement practices, documentation habits, and which tests are ordered for which patients. Imputing the gaps changes the data distribution, and bias in the underlying records propagates straight into any model trained on them.

Electronic lab notebook data is largely unstructured: ELNs capture ideas and observations as free text, and that unstructured content is hard to search or analyze, limiting how directly it can be fed to a model. This is precisely why lab-notebook data needs ongoing curation before it can train anything – the curation is the work, and it doesn’t happen once.

And the infrastructure is fragmented, too. Pharma data spans clinical trial databases, lab notebooks, LIMS systems, and manufacturing systems, with large organizations routinely working with a hundred or more lab instruments.

The recurring conclusion among the people who do this work is that stalled AI pilots are usually data and governance problems, not model problems.

What to actually do

Modern ML pipelines are sprawling. Between data collection, feature engineering, model training, and live monitoring, errors easily go unnoticed. Worse, when a pipeline breaks, finding out who is responsible is often impossible.

To break that pattern, every dataset should have two designated roles:

  • Data Owner: Responsible for data quality standards, access governance, and overall fitness for business use.

  • Data Steward: Responsible for operational execution, including metadata management, issue triage, and day-to-day data consistency.

Defined roles alone aren’t enough, however; they have to translate to institutional memory.

This is the gap Timnit Gebru addressed with her framework, “Datasheets for Datasets”. Recognizing that the ML community lacked a standard way to document data – a failure with severe consequences in high-stakes domains – Gebru proposed a datasheet that records why a dataset was created, what it contains, how it was collected, and its appropriate use cases.

But remember: a Data Owner’s job isn’t a one-time sign-off to put their name on a dataset; it’s an active, ongoing duty.

They must repeatedly return to the data, re-evaluating it and maintaining its hygiene.

What we recommend

Before buying more GPUs or doubling your model parameters, test whether you actually need compute or just need better data. As Andrew Ng proved across multiple data-centric campaigns, you can often improve accuracy faster by curating a dataset than by throwing raw hardware at the problem. But there is a caveat: Don’t clean your data past what the model will actually encounter in production. Your training data needs to be “as messy as” real-world inference so the model learns to handle reality – it just shouldn’t be more inconsistent or error-ridden than necessary. Ultimately, engineers waste their infrastructure budgets when they either scale compute on garbage data or over-scrub their datasets until they no longer resemble the real world.

Budget expert time as an explicit financial line item. Pay physicians, chemists, or domain specialists directly for their labeling hours, equip them with responsive software, and write unambiguous definitions for every category. As your specialists label records, track inter-annotator agreement continuously. When two experts evaluate the same data point and disagree on the label, don’t modify your model architecture to compensate. Your annotators are struggling with vague definitions rather than an algorithmic bottleneck, so rewrite the instructions until everyone agrees on the ground truth.

Stop paying domain experts to label easy data. Run active learning scripts to search your unlabeled pools, isolate the samples where your baseline model struggles, and send only those uncertain edge cases to your specialists. When you force annotators to resolve data points directly at the decision boundary, you train a sharper model while spending less money on manual annotation.

Audit your labels during every retraining cycle instead of treating data cleaning as a one-time pre-launch task. Run confident-learning algorithms to catch mislabeled records, schedule regular expert reviews, and track your data-error rate right next to your F1 and AUC scores. If you haven’t audited your ground truth yet, assume at least 3% to 5% of your labels are wrong.

Treat open-source and borrowed datasets as untrusted code. Run strict validation benchmarks before you merge external records into your training pipeline, and monitor live production traffic continuously to catch distribution drift. If you train models on small clinical datasets, pre-train your base architecture on domain-specific medical corpora first; this step frequently improves performance, but you still need to verify the gains on your local validation split.

If we can give you one key message, it’s this:

Data quality is not a project with a start and an end. It’s a program with an owner, a schedule, and a budget – and the organizations that treat it that way are the ones whose models keep working after the launch.

Key references

$\setCounter{0}$
Sarah Andrews
Next

Are My Evals Lying to Me?