I spent yesterday at Red Hat Summit: Connect 2026 in Austin, Texas. Good sessions, solid engineering, and one pattern I could not stop seeing.
A data resilience vendor took the stage and, by the end, had summarized what they do for customers in three promises. They help customers understand their data. They give customers AI trust. They provide audit evidence on demand.
Every one of those phrases names something a regulated healthcare or life sciences organization needs. And every one of them, as delivered, meant something else.
The question in the room
During Q&A I asked the speaker a simple question. When you restore data in a regulated environment, can the platform produce signed evidence of what was recovered, evidence that would hold up from a GxP or 21 CFR Part 11 perspective? I was clear that I did not mean IT operations data. I meant the regulated business data itself.
The answer was honest, and I respect that. The speaker was not deep on that part of the product and would need to follow up. What he could describe was evidence that the backup ran, that the restore succeeded, and that the vendor holds the right certifications.
That is real evidence. It is evidence about the vendor's system, not about the customer's record. By the way, this is not limited to one vendor. I've searched high and low for all things "evidence" and when it comes to many of the cloud operators and hyper-scalers, their "certifications" and assurance of evidence is for the most part, talking about their systems, not necessarily the customers regulated data.
Three promises, two meanings
Understand your data. In the infrastructure sense, this means discovery and classification: where your data lives, which stores hold personal information, who has access. Useful. But when a clinical operations lead says she needs to understand her data, she means something different. What does this value mean? Which protocol version was in force when it was captured? Which visit, which subject, which instrument? What was it derived from, and who changed it? Knowing that a table contains personal information is not the same as knowing what the table says.
AI trust. In the infrastructure sense, this means governing what an agent can touch: identities, access controls, guardrails, the ability to roll back if an agent does damage. Necessary. But the trust a regulated organization has to establish is trust in the output. Why did the agent recommend this? What inputs did it use? Which human confirmed it, and under what authority? You can lock down an agent's permissions perfectly and still have no idea how it reached a conclusion you just acted on.
Evidence on demand. In the infrastructure sense, this means proof that recovery works. In the regulated sense, evidence means the record is what it claims to be: attributable, contemporaneous, original, accurate, with a trail of every change it went through. An auditor does not ask whether your backup restored. An auditor asks whether this number in the submission traces back to its source, and who signed off at each step.
Same words but a different subject. The infrastructure vendors are describing what happened to the plumbing. Regulated customers need to know what happened to the data that flows through it.
The cost of borrowed words
After the session I told the speaker what this collision looks like from my side of the table. A CIO hears "evidence on demand" in one meeting and signs. A few days later someone else comes in to talk about evidence for regulated records, and the CIO stops them: "Thank you but I just bought that, we are covered, our evidence is secured!"
The CIO is not being careless. The slide said evidence on demand, and the CIO heard the thing their auditors keep asking for. Both sides of that purchase believe they agreed on the same thing. Sadly, they did not.
That is the real cost of the vocabulary collision. It is not confusion; it is false closure. The evidence budget is spent, the risk is marked covered on the register, and the gap is still open, now with a signed contract saying otherwise. The organization learns the difference the first time a human has to answer for a decision.
The closest anyone came
The one session that got near the real problem was a hands-on lab built around a fictional mortgage lender. The lender had deployed a multi-agent AI system to run its lending lifecycle. The agents were failing in production and nobody could see where or why. Customer complaints were rising. Loan processing times were unpredictable. Nobody had visibility into what the agents were doing.
That is a business problem described in business terms, and I was so glad to see it.
Then the lab began. Log into the cluster from a terminal. Open the container platform console. Navigate to the pods. Open the experiment tracking console and read the traces.
The evidence was there. It was also locked inside tools only an engineer can operate. Picture the people who own that mortgage problem: the head of lending operations, the compliance officer, the chief risk officer. Now picture a fair lending examiner asking why a specific applicant was denied, a question the lender is legally required to answer with specific reasons. None of those executives will open a "pod log". Each of them will file a ticket and wait. The engineer who picks it up is not a lending expert and does not know what the examiner is actually asking. What comes back is a story reconstructed by the person least equipped to tell it, in a summary that is itself undocumented.
That reconstruction is digital archaeology: expensive people stitching disconnected fragments into a narrative after the fact, because the data did not carry its meaning or its history with it. It is how most regulated organizations produce evidence today. Observability tooling makes the dig faster. It does not end the dig.
Who answers for it
Here is the test I keep coming back to. When a decision is challenged, by a regulator, an auditor, or a patient's attorney, who answers for it?
Not the agent. An agent cannot be sworn in. Not the vendor either, as far as I can tell; "the tool did it (or didn't do it)" is not a position I would want to defend. A human answers: the physician, the trial sponsor, the loan officer, the quality lead. That person needs evidence they can read, understand, and defend in their own terms. A green checkmark on a restore job does not help them. A trace span ID does not help them.
In healthcare the stakes are concrete. A patient suspects a care decision went wrong and requests the records. The clinical team now has to reconstruct what was known, when, from which system, and who acted on it. If that takes weeks of manual work, or cannot be done at all, the organization is leaning on defensibility by obscurity: short retention windows and silos that make the question hard to answer rather than answered. That has worked because connecting the dots was expensive. AI makes it cheap, for the organization and for everyone who comes to look.
What the missing layer has to do
The answer is not another dashboard, and it does not start with technology. It starts with the person who has to answer the question.
Think of every piece of regulated data as carrying a birth certificate and a passport. The birth certificate records who created it, what created it, when, why, and under what authority. The passport collects a stamp at every border it crosses: every system, every change, every agent that touched it, every human who confirmed it. When someone asks how a value or a decision came to be, the answer is already there, in terms the asker can use, without an archaeology team.
Three properties separate that from what was on display yesterday:
- It is about the record, not the runtime. It tracks the customer's data and decisions, not the health of the platform underneath.
- It is produced as the work happens, not reconstructed afterward.
- It is readable by the functional owner: the compliance officer, the clinical lead, the risk executive, not only the engineer.
Resilient platforms, governed agent access, and recoverable backups are all necessary. None of them, alone or together, will tell a regulator why a patient was treated a certain way or why an applicant was denied.
The decision AI is forcing
The vocabulary is converging. Trust and evidence are showing up on infrastructure slides everywhere this year, and that is a good sign: the market feels the problem. The words just have not reached the subject yet.
Underneath that is an architectural choice. An organization can keep securing the plumbing and staffing the dig. Or it can build an institutional brain: a connected memory of what the organization knows, where each piece came from, and who stood behind it. The brain is the asset. Evidence is what makes it defensible. That is what we are building at ScientixAI.
In the meantime, the next time a vendor promises you evidence on demand, ask the question I asked yesterday: evidence of what? If the answer is about their system, you still have the problem. If it is about your records, in a form the person who answers for the decision can use, you are talking about the right thing.
Bo Lora: Founder of Scientix.ai Inc. Has spent the last 5 years deeply embedded across the healthcare & life sciences value chain engaging with clinical research sites, sponsors, CROs, tech vendors, start-ups, and regulators. He left AWS in 2025 after being asked to support non healthcare & life science related endeavors and after taking a well deserved break, began working on a product idea based on evidence infrastructure.