Blog
Security isn't where your data lives. It's how disciplined you are in building it.
Every week I talk to clinical development leaders trying to move faster with AI.
Interestingly, lately a different question keeps coming up and it has nothing to do with trial design. It's about trust. Where sensitive clinical data should actually live and who should be allowed near it.
The instinct I hear most often is that on premises means control and cloud means exposure. A recent breach at one of the largest pharmaceutical companies in the world made that instinct louder. Reported figures put the exposed volume at a terabyte or more, clinical trial data, undisclosed drug programs, manufacturing processes, proprietary AI models… taken over more than two months.
So I looked into how it actually happened. And it changed my mind about what the real question should be.
It wasn't a cloud problem
None of it was exotic. The entry point was a single credential left exposed in code, on a public facing part of the company's own site. From that one foothold, attackers moved laterally across cloud systems for weeks, and nobody caught it in time.
Three ordinary failures, not one dramatic one. Secrets sitting in shipped code. A sprawling surface of systems nobody was fully watching. No detection layer sharp enough to notice the gap in between.
This company had a large, well resourced security organization. The cloud infrastructure did exactly what it was built to do. What failed was discipline in how things were built, and speed in noticing when something broke.
That distinction matters more than where the servers sit.
The real question
If systems this well resourced can be exposed this way, the question was never where your data lives. It's how disciplined a platform is in how it's built and how fast it catches a problem once prevention fails, because prevention always fails somewhere eventually.
That reframe changes what buyers should be asking their AI vendors. Not "cloud or on premises." Instead, how do you stop a credential from ever reaching production and how long would it take you to notice if one did anyway.
Why design and monitoring matter more than size
There's a common assumption that a bigger vendor, with more resources, is automatically the safer bet. This breach is a reminder that resources alone don't decide the outcome.
What decides it is how deliberately a platform is designed, how closely it's monitored day to day, and how it's operated once it's live. A well designed, tightly monitored environment can spot anomalous activity quickly. A sprawling one, no matter how well funded, can let that same activity sit unnoticed for weeks.
So the question worth asking isn't how big or small a vendor is. It's how engineering discipline, monitoring and operations actually work together, regardless of the size of the company behind them.
What this means for AI in clinical development
I've written a lot about traceability, about decisions that can be defended scientifically and operationally. I think we need to hold the infrastructure behind those decisions to the same bar.
A platform that can't explain how it prevents a credential leak, or how fast it would catch one, isn't fully defensible, no matter how strong its clinical logic is.
Discipline in engineering and speed in detection aren't side considerations anymore. They're part of what makes an AI platform usable at the scale clinical development actually requires.
I'll keep having this conversation. Curious how others in the industry are weighing it.
If you're asking these questions internally already
Chances are your team has already started asking some version of these questions about your own AI vendors and generic answers on a page rarely settle them.
The questions that actually matter are specific to you.
What does your current vendor's build pipeline actually catch and what does it miss?
How would you know if a credential leaked tomorrow and how long before someone noticed?
What would a security review of your own environment surface that a sales deck never would?
Those aren't questions a blog post can answer, because the honest answer depends on what you're running today.
If these are conversations your team is already having, we'd be happy to exchange perspectives. Fifteen minutes with our security lead, working through your specific setup, no deck, no pitch.
