Everyone in clinical research is asking some version of this question right now. The latest Atorus™ Unscripted webinar, in partnership with PHUSE, put AI-ready data at the center of a conversation between three practitioners who work with clinical data and AI every day:

The short answer is that most clinical data is correct, but it’s not AI-ready. Those are two very different things.  

Here’s what the conversation uncovered. 

“Data as a Product” Means Two Things at Once

The phrase “data as a product” is becoming more common in the industry, but its meaning varies depending on where you sit. From a clinical data management perspective, there are two equally important layers. The first is the clinical data itself, including CRF data, SDTM datasets, and everything that supports the research conclusions and goes into the CSR. The second is the operational data, which includes how quickly teams move from protocol to CRF and from query issued to query resolved, how much data changes between review cycles, and what that tells you about study health. 

When organizations talk about treating data as a product, both layers matter. And when AI enters the picture, so does a third role. An engineer sits between the data owner and the data consumer, and increasingly that consumer is an LLM. As Michael Collins put it, “That forces teams to prepare for a consumer that can be unforgiving and sometimes incorrect.” 

Correct Data Is Not the Same as AI-Ready Data

Clinical data management has already optimized heavily for correctness:

  • Does the value match the CRF? 
  • Does it pass validation? 
  • Is the dataset clean? 

But feeding correct data to an LLM requires an additional step. The data needs to be structured in such a way that the model can actually use it.  

A practical example illustrates the gap. In a retrieval augmented generation (RAG) project built on validated R package documentation, the data was correct and well-documented, but when it was chunked for embedding, individual pieces lost their connection to the context of the broader document. The LLM started confusing functions across packages and hallucinating answers.  

The data was right, but the structure was wrong. 

A second RAG project, built on a library of request-for-information questions and answers, worked well precisely because the question-answer format survived the chunking process without losing semantic meaning. Same technology, different data structure, completely different outcome.  

Structure is part of the data quality. Choosing the right tool for the right data is part of the readiness.

Data Quality Is a Process, Not a Deliverable

The idea that data quality is continuous rather than episodic isn’t new to clinical data management, but AI raises the stakes.1 Teams can no longer treat quality as a gate at the end of a study. It needs to be part of day-to-day workflows, with ongoing measurement, version control, and monitoring, especially when AI agents are consuming that data on a regular basis. 

There’s a parallel to existing clinical data management discipline. Just as teams already track query resolution rates and cleaning timelines as operational metrics, the same rigor needs to extend to the data feeding AI tools:

  • What does “good” look like for this data?  
  • How do you know when it degrades?  
  • Who is responsible for maintaining it?

The Better Question: Is Your Process AI-Ready?

The conversation revealed a reframe worth sitting with. Rather than asking whether the data is AI-ready, the better question is whether the process is AI-ready.  

If you don’t understand your own workflow well enough to explain it to a new team member, you’re not ready to explain it to an LLM. 

That’s the intern analogy: imagine handing a task to someone with technical skills but no domain knowledge. What would they get stuck on? What context would they be missing? If you can answer that, you’ve started mapping what your AI system will need. If you can’t, the data readiness question is premature. 

Where to Start

The practitioners’ advice was consistent: start small, focus on specific gaps, and let wins compound:

  • Find one place in your workflow where an LLM can create an efficiency gain
  • Don’t try to automate the entire pipeline
  • Don’t use AI for the sake of saying you use it
  • Solve one problem, prove the value, and build from there

The teams getting the most out of AI right now are the ones being open about how they’re using it, clear about where it’s working and where it isn’t, and disciplined about the underlying process.

Frequently Asked Questions

AI-ready data goes beyond correctness and validation. It means data that is structured, contextualized, and formatted in a way that an AI model can interpret and use effectively for its intended task.

Correct data confirms values match source documents and pass validation rules. AI-ready data also requires appropriate structure, preserved context, and formatting aligned with how the model processes information. The two requirements overlap but are not the same.

Data managers are both owners and consumers in this model. They produce clinical and operational data for downstream teams, including engineering teams building AI tools. Ownership of quality extends across the full chain and requires clear accountability at each handoff.

Focus on one specific workflow challenge where an LLM can create a measurable efficiency gain. Prove the value in a contained scope before expanding. Teams that try to automate entire pipelines at once tend to stall.

Small biotechs tend to move faster but have less historical data to process. Large pharma organizations have extensive background data but longer adoption timelines. Both can learn from each other’s strengths.

References 

1 FDA. (2023). Artificial Intelligence for Drug Development. Discussion paper. https://www.fda.gov/science-research/science-and-research-special-topics/artificial-intelligence-and-machine-learning-aiml-drug-development 

Back to Resources