Where your patients' data actually goes

Ask any AI vendor whether it can see your patients' data and you will get a version of the same sentence: we won't look. Most of them mean it.

Now ask the second question. Can they?

That is no longer a question about intentions. It is a question about how the thing is built.

What happens when someone asks it a question

Someone at the front desk types a question — what did we agree with this patient about the next step — and the answer appears as though it came from the computer in front of her. It didn't. The text left the clinic and landed on a server belonging to someone else.

That server has an owner. The owner has keys.

And it almost never ends at one server. There is the tool's own. Behind it, usually, a second company running the model. There are logs, because nobody can trace a fault that was never written down. And often enough there is a support screen where an engineer can open a conversation and see what went wrong inside it.

At every one of those stops, a copy of your sentence exists. Sometimes only for a moment.

This is not negligence. It is precisely what the word "cloud" means, and it is perfectly fine for a task board. It looks different when what is passing through is medical history, medications, what the x-ray showed, sometimes an ID number and a payment arrangement. A patient chart in a dental practice is a medical record like any other.

Five questions worth more than a sales deck

• Whose account does it run on? Who gets the bill for the servers, you or them? If the bill isn't yours, the house isn't yours.
• Who holds the key? "It's all encrypted" is not an answer to this question. Encryption protects data from everyone except whoever holds the key, so the only question that matters is who that is.
• What happens when something breaks? To fix a fault on my account, does someone on your side open a patient's conversation? Approved by whom? And where do I see that it happened?
• What is kept, where and for how long, including the logs? Logs are the copy nobody thinks to ask about, and a copy nobody is tracking is a copy nobody is protecting.
• If I leave tomorrow morning, what stays with you?

And notice the answer you will hear most often: we don't train models on your data. That is an excellent answer to a question you did not ask. Training is only one thing that can be done with a copy. The copy is the question.

"We won't look" versus "we can't look"

"We won't look" is a policy. A policy rests on people and on circumstances, and both of them move — new owners, a new investor, a court order, an on-call engineer at two in the morning trying to rescue an account that has gone down. None of those cases makes the vendor a liar. That is simply what a promise is: it holds until the day it is tested.

"We can't look" is a statement about the shape of the system. It is worth something only if there is no route, and only if the vendor is willing to tell you where a route does exist.

What has to be true for the second sentence to hold

• It runs in your account. The compute and the storage sit in a cloud project registered in your name, on your billing.
• Nothing is collected back. Not "anonymous statistics only" — ask whether the vendor has anywhere to collect it to at all.
• Access is for the installation, and you close it. Someone has to install the system, and that is not sinister. What matters is that the grant is temporary, that revoking it happens in your console with your permissions, and that you do not have to ask the vendor to do it for you.
• The record is written on your side. If the log that would show a vendor reading your data sits at the vendor, it is not evidence. You locked the room and left the window open.
• It survives the parting. When you go separate ways, what stays with you is the project, the data and the log.

And there is one question worth asking in the meeting: what exactly would you have to do to read one of my patient records? If the answer is a procedure — a form, an approval, a support request — they can. If the answer is a permission you would have to grant in your own console, and you would have seen the request, that is a different kind of answer.

And what we are obliged to say about ourselves

Turn that question on us, and this is the answer. SoliumOS is deployed inside a cloud project the clinic owns, on the clinic's billing, and the compute happens there. There is no second copy on our side and nowhere for us to collect one. During the installation we do have access, and we say so out loud. At handover you remove our roles from your own console, without us. From that moment, "we can't see your data" is not a commitment we are making — it is a property of the pipe. And the audit log that proves it is written in your project, not ours.

We would rather you checked than believed us. Ask us the five questions, and ask them of everyone else too.

And regulation?

You will also be told that a tool meets the requirements. Take your specific obligations to your own counsel — this post quotes no clause and replaces no lawyer. But when you are choosing, hold the two things apart.

A rule tells you what you owe and what happens if you fail to meet it. It is enforced after the fact, by people. Architecture decides what is possible in the first place. You want both, but only one of them is still working at two in the morning, when nobody is watching.

And what it costs

The other side deserves saying too. A vendor who cannot see your data also cannot open it up to work out why something didn't work. They go on what you tell them and what you choose to show them. That is slower, and sometimes it is simply worse: a vendor who sees everything can just go and look.

We gave that up on purpose, and it costs us. It is a real trade rather than a slogan, and it is worth making with your eyes open — not discovering it in a sentence a lawyer reads out to you later.

That is the whole company in two sentences: we build it, and we can't read it. The second one had to be designed. The first was the easy part.