By Jay Leonard, Vice President, Enterprise Technology Transformation and Architecture, Worldwide Clinical Trials
Dashboards demo well. Everyone likes a clean set of trend lines they can click into, and I can build one in about 20 minutes. But when a sponsor asks me about AI in functional service delivery, the dashboard is the last thing I want to talk about. The data underneath it is the real conversation.
You can see this shift happening in RFP[JH1.1] language. A couple of years ago the questions were about headcount, locations, and standard operating procedures (SOPs). Now sponsors ask where the data lives, what the API[JH2.1] connections look like, and how AI output gets validated. Integration used to be the hard part of that answer, but it has become routine. Governance is now the piece that decides whether any of this holds up under review.
The Three Layers of Compliant AI Delivery
I think about AI-enabled delivery in three layers. The integration layer is where API connections and security let our systems talk to sponsor systems. The model layer is where the AI does its work — the automation and the analysis that make the output interesting. The audit layer captures every action, including the prompts, outputs, and decisions that were made.
An inspector will want to see that third layer. It lets you trace a number on a screen back through its lineage and demonstrate how it got there. The FDA and client auditors are both moving in this direction, and audits are starting to bring specialist technology reviewers alongside the quality team.
To meet this challenge, governance must be part of the design. A credibility assessment plan should be written at the start and include how the model was designed, where the training data came from, and how it performs. This plan makes outcomes predictable. Building it in from the beginning is a far easier path than reconstructing an audit trail once a study is underway.
The bottom line is sponsors and regulatory agencies need traceability. They need to know what technology touches what data, as well as how and who has reviewed and signed off on any changes.
How AI Supports Statistical Programming Within Existing Workflows
When we think about AI for stats programming, it goes inside the environment people already work in. If the team is working in SAS or R [JH3.1]programming, the AI works there too, inside that validated execution environment.
The role of AI in that setting is to suggest. Data management is the clearest place to see how that works: the AI makes a suggestion, the programmer reviews it, and the human decides whether to execute. The decision point stays exactly where it has always been, so SOPs continue to hold. The savings show up in repeatable activities Benchmarks on AI-assisted SDTM and ADaM [JH4.1]programming show time reductions in the range of 50 to 70 percent for taking a spec and creating code. Our internal pilots have shown similar results, with the programmer reviewing every recommendation.
Three Questions Worth Asking Any AI Vendor
Before we decide to work with a vendor, we run through the same three architecture questions.
- Can the model run in an environment we control so the data stays inside it?
- Can the vendor produce artifacts a regulator can review, including documented prompts, outputs, model versions, and the decisions that were suggested and then taken?
- Does the product integrate through open interfaces, so changing direction later stays practical?
A vendor who answers those three questions clearly is already thinking about the same problems you have.
It is also worth agreeing to exit terms up front, including how you get your data back, how audit trails are handed over, and how models are decommissioned.
Bringing New Technology Into a Study That Is Already Running
Retrofitting something into live work takes a plan. Sponsors ask about this often once they see what is possible with AI going forward. One recommendation is to run the new approach side by side with the current one. Keep the scope tight — one function and one study — and set the success measures before you start. Then measure time saved, error rate, and how satisfied the people using it are honestly. When those measures come back where you want them, expand from there.
The cutover point is a metrics decision agreed at the outset and tracked throughout, which keeps the trial moving while the transition happens. Wiring the new data flows without disturbing the validated environments they run in belongs to the same discipline, and a human reviews anything before it reaches a regulated artifact.
Scale Comes From Standards
Any trial running on a mixed architecture, with some systems belonging to the sponsor and some to the CRO partner, raises the same practical question. Given enough time and money, I can build anything. Repeating it across a portfolio is the harder test, and standards-based interfaces make that repetition affordable. The useful conversation moves away from whose system sits where and toward which standard and interface both parties will use. Once that is settled, the architecture scales.
Phases work better than a single switch. Take a piece and put governance around it. Confirm the data is flowing correctly. Get clear on how risk is classified and where data lineage sits. Then expand into the next piece.
What This Means for AI-enabled FSP
Three years from now, I expect FSP to be described as people plus a toolbox, with the technology there to help those people execute studies better. The organizations that get value from AI will be the ones that build the governance processes and understand the integration discipline behind it. They can put AI inside regulated workflows and keep those workflows running. That is as available to a biotech working through a partner as it is to a large pharma with its own platform team.
Ready to see what AI-enabled delivery could look like across your own functions? Reach out to the Worldwide Flex team to start a conversation today and watch my fireside chat with Craig McIlloney and Stephen Rayda here.
