We have become much more risk-aware. There is greater emphasis on prevention and on using analytics to understand how a study is progressing, what issues arise and where risks may be emerging.

We have also removed some very cumbersome quality-control activities. Things like double data entry and double programming were once a significant part of the way we worked. Technology and better processes have helped us become more efficient.

Where I think we have been less adventurous is in redesigning the underlying business processes.

We often introduce specialist functions or departments around a new process rather than asking: if we designed this process properly today, what roles and organizational structure would we actually need?

At the same time, the amount of clinical data we collect has increased enormously. More data can create tremendous value, but it also puts pressure on processes that were not necessarily designed to manage this volume effectively.

So we have certainly progressed. But there is still considerable opportunity to rethink how clinical trials actually operate rather than simply adding more organisational structures to existing ways of working.

I am optimistic about what AI can contribute to that next stage, provided it is combined with human expertise and appropriate governance.

One challenge, particularly for smaller and mid-sized organizations, is having enough dedicated capacity.

During early RBQM implementation, organizations may need specialist roles such as risk managers or central monitors. It can be difficult to justify those dedicated resources initially, so RBQM becomes something people are expected to do alongside an already demanding primary role.

In my experience, that creates problems.

Risk management requires independent critical thinking. If you ask a busy study project manager to deliver the study and, at the same time, step back and critically challenge its risks, you are asking that person to perform two quite different jobs.

I see risk management as a discipline in its own right within RBQM.

Another important point is that the capabilities you need change as RBQM matures. Early adoption may be concentrated around risk management and analytics. Once you start implementing RBQM at scale, the implications extend further into Clinical Operations, Data Management, Medical Monitoring, Quality and organizational governance.

Trying to introduce every capability at once can therefore be counterproductive. Organizations often need to build RBQM progressively.

And then there is leadership.

Senior leadership support remains one of the biggest determinants of whether RBQM becomes embedded or stays a specialist activity. The terminology can sometimes make RBQM sound like a separate discipline when, fundamentally, it is becoming part of how we apply quality by design and quality risk management to clinical trials.

Regulatory expectations help create the case for change. But organizations also want to understand the practical benefit.

That combination — clear expectations, leadership commitment and evidence that the operating model creates value — is what helps RBQM move from a specialist initiative into normal trial execution.

For me, customer experience starts long before somebody asks whether they are satisfied with a piece of technology.

I learned that very clearly earlier in my career.

From around 2008 to 2012, I was leading the European Clinical Data Management organization at a major CRO. We were working on a cardiovascular study involving more than 10,000 patients for a large German pharmaceutical company, and the study was proving difficult to deliver.

The first thing I did was look internally. Did we have the right staffing? The right expertise? Appropriate training? Fit-for-purpose processes? Were our technologies actually helping the team?

But fixing the internal operation was only part of the answer.

I built a direct relationship with the sponsor’s Head of Clinical Data Management. Every week, I shared the good news and the bad news openly. When there were blockers on their side that I could not resolve myself, I asked for help.

Over time, the relationship changed significantly and further work followed.

What I remember particularly clearly is how improvements in one function affected others.

Clinical Data Management became better connected with Clinical Operations because we could focus CRAs on the outstanding issues that mattered. Data Management teams became more motivated to address the final issues needed to get patients clean. Medical Monitoring could be involved at the right point to review relevant patient data. We moved from blame into addressing issues as they arose.

And there is a Cyntegrity connection to that story: the sponsor contact I was working with was Johann Proeve, who is now Cyntegrity’s Chief Scientific Officer.

The lesson has stayed with me.

Excellent customer experience requires the right resources, processes and technologies, but also the right stakeholder relationships and communication. Successful deployment depends on reinforcing all of them.

Technology cannot compensate for a weak process or poor communication. Equally, excellent people should not have to compensate indefinitely for technology or processes that do not support them.

I have already used AI to accelerate parts of the study risk-assessment process.

For example, AI can help review a protocol and develop an initial view of Critical-to-Quality factors, Quality Tolerance Limits, risks, risk scores, mitigations and Key Risk Indicators, and support the drafting of an Integrated Quality Risk Management Plan.

That can save significant effort at the initial drafting and synthesis stage.

But this is exactly where the human-in-the-loop discussion becomes important.

An AI-generated risk assessment is not the final risk assessment.

The output needs expert review. You need to ask whether it makes sense clinically and operationally, whether something important has been missed, whether the proposed risks are genuinely relevant, and whether the assessment corresponds with the experts’ understanding of the study.

Prompts may need refinement. Tools may need controlled learning or configuration. And the way the output is reviewed, validated and used needs to be clear.

I think the amount of work involved in that human review is sometimes underestimated.

Looking further ahead, I see potential for AI to support more of the configuration and setup work around RBQM and clinical data management, and potentially the use of synthetic data to support study-specific testing and validation activities.

Another area that interests me is what happens after the initial risk assessment.

An Integrated Quality Risk Management Plan should influence the functional plans and the way teams actually operate. AI could potentially help teams translate that risk strategy into better functional planning and subsequently help synthesize analytics and data-review outputs.

For me, that is where the opportunity becomes especially interesting: connecting information more effectively across the trial rather than treating individual AI tasks in isolation.

But the accountable decision must remain with people.

AI can help identify, synthesize and prioritize. People still need to understand the context, challenge the output, exercise judgement and decide what happens next. And in a regulated environment, how that human oversight works needs to be clearly defined and documented.

I first met Artem more than ten years ago. We collaborated and presented together at RBQM conferences, and, as I mentioned, Johann and I also worked together earlier in our careers.

They are two people I respect enormously.

My relationship with Cyntegrity continued over the years. We collaborated on an AI event, and I attended several Cyntegrity webinars and training courses. Through those interactions I also got to know more of the team.

I was consistently impressed by the people I worked with and felt this was an environment where my experience could make a useful contribution.

There is also a very strong connection between the work I have done throughout my career and the customer challenges Cyntegrity is addressing.

I have spent a lot of time working with business processes and data management. These disciplines connect directly with RBQM because effective risk management cannot sit separately from the way a clinical trial is actually run or from the information teams use to make decisions.

That is what I want to bring to the role.

I want customers to experience positive, practical change from RBQM and to be able to measure its impact.

Ultimately, implementing RBQM should make a difference to how teams work: how they identify what matters, how they interpret emerging information, how functions work together and how they decide what to do next.

That is the customer experience I want us to help create.