Clinical Teams Need AI Workflows, Not Just AI Tools

By Sankesh Abbhi, Chief Executive Officer, Sitero

The conversation about AI in clinical trials has been dominated for the past several years by demonstrations. AI that can read a protocol. AI that can draft a query. AI that answers natural-language questions about study data. The demonstrations are often technically impressive. But something important is missing from most of them.

They do not show what happens after the answer.

A clinical data manager reviewing discrepant values does not just need an answer. She needs to know which data source generated the flag, why the check fired, what the protocol specifies about that endpoint, and what action she is accountable for taking. She needs that sequence to be reproducible if someone asks about it at an inspection six months from now. And she needs it to fit into the review process her team is already running, not add a new layer around it.

A generic AI assistant cannot deliver that. Neither can a standalone analytics tool bolted onto the outside of an EDC. The gap is not in the intelligence. The gap is in the workflow.

When I think about AI that is genuinely useful in a clinical program, I start with four requirements that go beyond raw technical capability.

First, it must fit a defined process. Clinical data management is not an open-ended task. It has structured inputs, a defined sequence of steps, clear role ownership, and outputs that must stand up to inspection. AI that operates outside that structure creates new coordination work rather than reducing the existing kind.

Second, it must bring relevant context together. The reason data review is time-consuming is not that reviewers are slow. It is that the information they need, structured and unstructured data, lives in different systems that do not communicate with each other. The work of assembling that context is itself the bottleneck. AI embedded in the workflow can surface a consolidated, source-grounded view, so reviewers spend their time on judgment rather than retrieval.

Third, it must support accountable review, not eliminate it. Clinical decisions require a qualified person to make a judgment call and own the outcome. The role of AI is to reduce the time that person spends on assembly and re-checking so that more of their time is available for the work that actually requires their expertise. Any AI that presents outputs without transparent sourcing, that operates without human review gates, or that leaves no traceable record of what was shown to whom and when is creating regulatory and quality risk, not reducing it.

Fourth, it must leave an audit trail. AI-generated information that materially contributes to trial conduct, data interpretation, data modification, or a regulated decision should be retained with sufficient provenance and metadata to reconstruct what the reviewer saw, what evidence supported it, and what action was taken. This is not a new bar created for AI; it is consistent with longstanding GxP expectations for traceability and electronic records. In a GxP environment, traceability is not optional.

One pattern I have seen consistently across clinical programs is that study setup, data review, and portfolio-level risk visibility are treated as three separate software problems. They have different owners, different tools, and different review cadences.

But they are not separate. A study configured inconsistently against its protocol generates variability that propagates through every subsequent data review cycle. A review cycle that runs biweekly rather than continuously delays the signal that portfolio leaders need to forecast lock readiness with any accuracy. Configuration errors discovered at lock are the most expensive kind to remediate. These three functions are upstream and downstream of each other, and treating them as isolated tools is a significant part of why clinical programs spend so much of their operating time on assembly and reconciliation rather than judgment.

The question we asked ourselves at Sitero is what it would look like if a single governed intelligence layer gave AI agents access to full study context, enabling them to support all three functions within a governed, traceable workflow model: simultaneously, not sequentially.

Answering that question required something more than a capable AI agent. It required a foundation: a consistent, governed layer of clinical data that the agent could reason from. That is what SiteroAI provides.

SiteroAI is Sitero’s clinical intelligence engine, purpose-built for GxP environments. It continuously ingests and harmonizes data from across the clinical ecosystem, including EDC, RTSM, central and local labs, ePRO, safety databases, and third-party vendor feeds, into a single, governed, permission-aware clinical data layer. Ash operates directly on top of SiteroAI, which means every workflow it executes, every insight it surfaces, and every recommendation it generates is grounded in a complete and current view of study data. Rather than connecting AI to siloed systems one at a time, SiteroAI gives Ash consistent, accurate, auditable context across the full clinical lifecycle.

Today, Sitero is making three Ash workflows available. We made a deliberate choice not to release them one at a time, because the operational value is in their connection.

• Ash for Study Configuration allows a team to upload a protocol and receive a complete study draft: study tree, visits, forms, fields, codelists, and edit checks, all drawn from SiteroAI’s protocol and standards libraries. The team reviews, comments, and releases. Configuration that has historically required months of specification cycles can now be completed in weeks. When protocol amendments arise, Ash identifies potential downstream impact across the study build, highlights affected objects and specifications, and routes proposed changes through defined review and approval. The resulting change record preserves the amendment source, identified differences, reviewer disposition, approved release, and associated testing or revalidation requirements. This compresses what has historically been a weeks-long change management process into days. The clinical team retains full authority over what is released. Ash handles the structured drafting and change management work. Looking ahead, we’re evolving the standards libraries beneath this workflow into an enterprise-wide metadata repository (MDR), and aligning our study definition model with CDISC’s Unified Study Definitions Model (USDM) as it matures alongside ICH M11. That foundation is designed to support expanded automated validation of the study build against protocol and standards, reducing manual QC cycles further while keeping every check traceable to its source.

• Ash for Data Management supports continuous data review, query management, and vendor reconciliation through two integrated capabilities. The DM Workbench gives data managers a single, role-based workspace where reviews are auto-assigned based on data type, therapeutic area, and team structure, so the right reviewer sees the right data without manual triage. Ash surfaces only the issues that matter to each team member, filtering out noise so that DM teams can act on what requires attention rather than work through volume. Clean Patient Tracker provides per-subject readiness status, open blockers, and query history in a single view. Data issues surface as they occur rather than waiting for the next scheduled review. Every check produces a logged audit trail entry. Reviewers see the evidence and make the call. In an early deployment, a top-ten pharmaceutical company configured more than 180 data review program checks in approximately five weeks, compared to an estimated three to four months using traditional SAS-based methods, approximately 75% faster.

• Ash for Insights provides study and portfolio-level dashboards with database lock forecasting. Risk visibility that historically surfaced at or near lock can now be tracked throughout the study. For teams managing multiple concurrent programs, cross-portfolio visibility is available in one place.

The governance model is consistent across all three workflows: a defined context of use, risk-proportionate human oversight, outputs grounded in study-specific source data through SiteroAI, permission-aware access, versioned evidence, and traceable review and release decisions. Where deterministic automation can perform a task reliably and reproducibly, it does. AI is used where interpretation, prioritization, or contextual reasoning adds value.

Ash does not make clinical, safety, or regulatory decisions. It does not operate autonomously. It does not replace the qualified professionals who carry accountability for data integrity, protocol compliance, and inspection readiness. What it does is reduce the time those professionals spend on assembly and repetitive review, so more of their capacity is available for the work that requires their judgment.

Clinical AI that obscures its reasoning, claims capabilities it cannot substantiate, or removes human oversight from consequential steps is not ready for the environment clinical teams operate in. We have been deliberate about where Ash participates and where it defers.

My recommendation to clinical operations and data management leaders evaluating AI right now: start with the workflow, not the demonstration. Ask what defined process the AI fits into. Ask whose work it supports and what evidence it surfaces. Ask what record it leaves and who reviews it. Ask what happens when the AI is wrong and who is accountable for catching it. Ask whether the answer to any of those questions requires you to trust the vendor rather than verify the output.

The measure of clinical AI is not how impressive it looks in a demonstration. It is whether it produces measurable operational outcomes within a governance model that stands up to scrutiny.

If that is the standard you are applying, we would welcome the conversation. Learn more about the three Ash workflows, SiteroAI using the buttons below.: