Is Your Data Safe With AI? What Actually Happens To Your Company Documents

A few days ago I was on a call showing a founder's technical lead what we had built. He watched the demo, then asked the sharpest question I have been asked all year.

Do you send our data to the AI models, and how is that secured. It is exactly the question every founder should ask before handing an AI their documents, and almost nobody answers it well, because it is really four questions wearing one coat.

Most people reach for "we run row level security", which is a real thing and a good thing, and also the answer to a completely different question. So here is the whole thing, properly separated, the way I walk every founder through it.

And I am not going to answer it from a vendor's marketing page. To write this, we ran a full security audit against a live client system, from the outside, using exactly the tools an attacker would use.

This article is that answer, plus the one thing the audit turned up while we were in there, because I wrote in my first book back in 2022 that when a user can get hurt it is the product owner's job to take the extra measures. Publishing that line and then not going to look would be a bit rich.

Four questions are hiding inside one

When a founder asks "is my data safe", he is not asking one question. He is asking four, all at once, in no particular order.

Nobody separates them, which is why these conversations go in circles and why founders end up trusting a feeling instead of a fact.

Here are the four. Where does the data actually live.

Who can open it. Does any of it leave the building, even for a second.

And does the AI company keep it or learn from it. Every one has a different answer, a different failure mode, and a different way to prove it.

Take them in order and the whole thing becomes simple.

Question one. Where does your data actually live

Think of a doctor's clinic. There is a filing room with the actual paper files in it, and there is a register at the front desk that lists who is due for a check-up.

Two different things, in two different places, doing two different jobs.

Every system we build works the same way. The files live in the client's own cloud storage account, on their own subscription, paid for by them.

The register lives in their own database. Both are theirs.

If we walked away tomorrow they would still own every file and every row, and we would have no copy.

This is the question with the simplest test and almost nobody asks it. Whose name is on the storage account.

If the answer is the agency's, your data is a guest in someone else's house, and you will discover exactly what that means the day you want to leave.

Question two. Who can open the cabinet

Two locks, one behind the other. That is the whole design, and the reason there are two is that one always eventually fails.

The first lock is the front door. Only an email address on an approved list gets in.

Not "anyone with an account", which is a mistake I have seen make a system wide open while looking perfectly locked. An approved list, and if the check fails for any reason at all, the door slams shut rather than swinging open.

Failing shut is a design decision, and it is the one that matters when something goes wrong at 3am.

The second lock is the one worth understanding, because it is the one that keeps protecting you after the first one fails.

Row Level Security, explained without the jargon

First, the name, because half the internet says it wrong. It is Row Level Security, not role level.

A row is one line in a table: one client, one document, one deadline. So this is security applied line by line, not just at the door.

Here is what it actually does. Picture the filing cabinet with a rule glued to the front of it: no drawer opens unless the person's name is on this list.

Then leave the list empty. Now it does not matter who walks up to the cabinet or what they are carrying.

Every drawer is welded shut, because nobody is on the list.

That sounds paranoid until you understand what is genuinely public about a modern web app. Any website built this way ships a small key to your browser, and it is visible to anyone who looks at the page source.

It is meant to be visible. It is the doorbell, not the door key.

But if the cabinet inside has no rule glued to it, that doorbell opens every drawer in the building, and this is the single most common way small companies leak their entire database without ever being hacked.

Question three. Does anything leave the building

Yes. And this is the part where most agencies get vague, so let me be specific instead.

Take a real job. A clerk at a compliance firm is handed a licence document by a walk-in client.

Someone has to read it, work out which company it belongs to, find the expiry date, file it in the right folder, and set a renewal reminder. Done by hand that is close to an hour of careful, boring, error-prone work, and the error nobody catches is the expensive one.

In our systems the clerk uploads that one document and it goes to an AI model to be read. It comes back with the document type, the company name and the expiry date, the clerk confirms what she is looking at on screen, and it files itself.

About four seconds instead of about an hour.

So picture the window at a bank. She passes one page through the window to a translator.

He reads it out loud, hands the page straight back, and that is the end of it. He never got the filing room.

He never got the other documents. He got one page, for four seconds, because a human decided to hand it over.

The part most agencies will not tell you

Here is the detail that separates a system built carefully from one built to demo well. We did not upload the client's archive into an AI.

Not one document of it beyond the one in the clerk's hand.

That archive has hundreds of thousands of documents in it. The fashionable thing to do in 2026 is to feed all of it into a retrieval system so you can chat with it.

We deliberately did not, for two reasons that have nothing to do with fashion.

• The questions are exact, so the answers should be too. "Whose licence expires in the next thirty days" has one correct answer. A database gives you exactly right. A retrieval system gives you approximately right. For a compliance deadline, approximately right is worth nothing.
• A misread date is the most expensive failure this kind of system can produce. It is silent. The document gets filed, it looks perfect on screen, and the reminder never fires. You find out when the penalty arrives. So we spend more on accuracy at the one moment a document is read, and we make a human confirm it.
• Nothing in bulk ever leaves. One page at a time is the smallest exposure a working system can have. That is not a limitation we apologise for. It is the design.

There is a place where retrieval is exactly the right tool, and it is when the material is the client's own expertise rather than their records. We built that for a physiotherapist: two decades of his own knowledge and his own books, so his team can ask a question and get his answer instead of a generic one.

Right tool, right job. The point is that the architecture should follow the question being asked, not the trend.

Question four. Does the AI company keep it or learn from it

This is the fear underneath all the others. That your client list, your contracts, your numbers quietly become part of some model that a competitor will one day query.

For the commercial APIs that serious systems are built on, the answer is that they do not train their models on what you send through the API. That is in the terms, not in a blog post.

Inputs are held briefly for abuse monitoring and then dropped. And if your compliance people need more than that, there is a thing called a zero data retention agreement, which means the vendor holds nothing at all.

Two things to do with that. Ask your vendor to send you the actual page from the actual provider, not their paraphrase of it.

And notice whether they know the phrase "zero data retention" without being prompted, because the ones who do are the ones who have had this conversation with a real compliance team before.

We attacked our own client's system to write this

Reading your own security documentation and concluding you are safe is not a test. It tells you what somebody intended, on the day they wrote it.

So we did the other thing.

We took a live client system, a business-setup and compliance firm, and came at it from the outside like a stranger with bad intentions and a browser. First the front door.

Every page and every data address answered with a redirect to the login screen and handed over nothing. Then the page source, which is where people expect to find secrets.

The login page turned out to be eight kilobytes of nothing at all.

So we went further, followed all eight of the site's script files, about two thirds of a megabyte, and read every one. Two values in there, both public by design: the database address and that doorbell key.

Zero sign of the things that would actually matter, no master database key, no AI provider key, no messaging token, no storage secret. Then we took the doorbell key, the one anybody can copy, and used it to try to read all twenty-four tables in the client's database.

Twenty out of twenty-four is not a pass mark. Three tables came back with an empty list rather than a refusal, and the difference between those two answers is the whole reason to run the test.

What "one lock instead of two" actually means

Nothing leaked. No data came out of any of those three tables, no client was exposed, and the rule glued to the cabinet did its job perfectly.

But the outer lock, the one that should stop a stranger before the rule is even consulted, had gone missing on those three.

Think of a door that is both bolted and behind a locked gate. Take away the gate and the bolt still holds.

You are still safe today. You are one mistake away from not being, and you would have no warning, because nothing looks wrong from the outside.

The cause is boring and worth knowing, because it will happen to any growing system. Months earlier we had told that database to lock every table and to stop handing out permissions on new tables in future.

That instruction only binds the person who gave it. Those three tables were created later, by a different route, and they quietly inherited the default permissions that come with a fresh table.

Nobody was careless. The instruction had simply gone stale, and staleness does not announce itself.

The fix that matters more than the fix

We could have just locked the three tables. That takes one command and it would have made the report look clean.

It also would have guaranteed a fourth table next quarter.

So we fixed the class of problem instead. The database now has a standing instruction that fires the instant anyone creates a new table anywhere in it: lock it, enforce the lock, and strip the public permissions.

Nobody has to remember. Nobody has to re-run anything.

A new table is born locked.

This is the difference between a checklist and a system, and it is the same difference I talk about with founders all day for a completely different reason. A checklist depends on a person being sharp on a bad day.

A system does not care what kind of day anyone is having. We re-ran the attack afterwards: twenty out of twenty, every table refusing at the outer lock, and the client's dashboard working exactly as it did before, because the app reads through a separate server-side key that was never affected.

As tech evolves, cybersecurity concerns will always arise, and we must be on our toes and take precautions against them. If a user can get hurt, it is the product owner's job to take the extra measures.

I wrote a version of that in my first book in 2022, before any of this existed. Writing the line is easy.

Living up to it means running the audit even when it might find something, and publishing what it found. That is the difference between a claim and a standard.

What to ask before you sign anything

You do not need to be technical to run this conversation. You need five questions and the confidence to keep asking until the answer is specific.

1. Whose account is my data in. Mine or yours. If it is theirs, ask what happens the day you leave, and get the answer in writing.
2. Show me what a stranger sees. Ask them to open the page source on your own system while you watch. Anyone who has built this properly will enjoy doing it.
3. Now use that key against my database. This is the real test and it takes two minutes. The right result is a refusal. An empty list is a warning. Actual data is a fire.
4. Exactly what leaves, and when, and who triggers it. "One document, when a person uploads it" is a good answer. "It is all encrypted" is not an answer to this question, it is an answer to a different one.
5. Send me the provider's own page about training on customer data. Their words, their link. Then ask whether zero data retention is available on your account.

If a vendor gets uncomfortable at question three, you have learned the most useful thing you were going to learn that day. Nobody who has actually done this work minds being tested, because the test is the best part of the pitch.

One more thing nobody asks about

While we were in there I looked at something the audit was not even asking about. Our system lets an authorised person delete an entire company folder by voice command, with one confirmation.

That worked exactly as designed, and I decided the design should go one step further.

Every action is logged, so nothing is invisible. But there was no separation between "can file a document" and "can delete a client's entire history", which means the newest clerk had the same destructive power as the owner.

That is not a breach. It is the kind of thing that becomes a very bad afternoon eventually, and it is now getting a second approval step and a permission level of its own.

I am including it because it is the honest shape of this work. Security is not a certificate you get once.

It is a habit of going and looking, and being willing to write down what you find.

The answer, in one paragraph

Your data lives in your own accounts. Two independent locks stand between it and the internet, and the public key that anyone can copy from your own website reads nothing at all.

One document at a time leaves to be read, for a few seconds, because a person chose to send it, and your archive never goes anywhere. The provider's terms say they do not train on it, and if you need zero retention it exists.

That is the answer, and none of it should be taken on faith, because all of it can be shown to you in under five minutes.

If you are about to hand your company's documents to an AI system, ask the five questions. If the person on the other end cannot answer question three by actually doing it in front of you, you have not found your partner yet.