Your firm's data is already in someone's training set

Every few weeks there's another one. A firm finds its internal memos echoed back through a public chatbot. A court sanctions a lawyer for feeding privileged client files into a consumer tool. A hospital board sits through a data-review meeting trying to explain why a patient's record ended up in a model someone on the other side of the world can now recall on demand.

Here's the uncomfortable part we keep skirting: by the time the headline lands, the damage is already done. You can't un-train a model. You can't claw a document back from a distributed training corpus. The only protection that actually works is the kind that never lets the data leave the building in the first place — and almost nobody in the AI industry wants to tell you that, because it's the one answer their business model can't sell you.

Why the advice always lands on the individual

Watch how organizations respond to these incidents. Almost always: a memo to staff telling them to stop pasting sensitive data into public chatbots, more training, another "acceptable use" checkbox on log-in. It's well-intentioned, and it is structurally doomed. You are asking hundreds of busy professionals to hold a line of vigilance against the most convenient tool on their desk, all day, forever. One tired associate, one rushed paralegal, one late night — and the discipline fails exactly once, which is all it takes.

That's not a training problem. That's a systems problem. You wouldn't tell your office to "remember not to mail the client's Social Security number to the wrong address" — you'd build the system so the wrong address isn't reachable. The same logic applies to AI.

Your data is the product, whether you see the bill or not

The public AI platforms aren't evil. They're just running a business that is structurally at odds with your duty of care. Their model improvement and their unit economics depend on data flowing through their pipes. Even the providers who promise "we don't train on your data" still route every one of your queries through a server you don't control, where it sits alongside data from every other customer, where it's one breach, one over-permissioned engineer, or one careless logging change away from becoming somebody else's signal.

In a regulated office — law, medicine, finance, licensed trade — "somebody else's server" isn't a minor detail. It's the whole ballgame. You hold privileged information, confidential client work product, and protected records. When you paste a contract into a consumer chatbot, the legal obligation doesn't disappear because the tool was convenient — it just moves onto you, unprotected.

The version of this that actually works

Here's the part the industry doesn't lead with, because it isn't profitable for them to tell you. The models worth using are small enough, and the hardware is cheap enough, that you can run a genuinely capable AI inside your own perimeter. Not a stripped-down demo — a real, useful model that reads your documents, drafts from your templates, and works your files the way your staff does.

The architecture is the difference between a chatbot and a duty-of-care system:

• The model runs on a box in your office — not on a server you'll never see. There is no network call, so there is nothing to intercept, log, or train on.
• There is no upload button. Your files never go anywhere, because the agent reads them where they already live. You can't leak data in transit if the data doesn't transit.
• Control is structural, not a checkbox. You're not trusting a promise. You can see the whole stack — the hardware, the model, the access control — because it's sitting in your building.
• The exposure surface is the size of your office, not the size of the internet.

What to ask before you adopt any "AI for your office"

Before you sign anything, ask whoever's selling you AI these three questions — and don't accept comfort until the answers hold up:

• Where does the data physically run, and who has access to the hardware? If the answer is "our cloud," you need a very specific, enforceable explanation of what happens to your data there.
• Is there any path for my data to leave the building at all? If there's an upload button or an API call in the flow, the answer is yes — and "we don't use it" is not the same as "it can't."
• What's my recourse if something leaks? If the answer is a liability waiver and some credits, that's not data protection, that's risk transfer.

The test for a genuine private-AI deployment is brutal and simple: if someone unplugged your internet, could the system still do the job? A real on-prem agent says yes. Anything that stops working the moment the WAN drops is, for these purposes, still a chatbot with better branding.

The way forward

I'm not anti-cloud. I run infrastructure that talks to clouds daily. But when a duty-of-care office asks whether its clients' confidential work product belongs on a public training set, the honest answer is no — and it's no because of how the technology actually works, not because of nostalgia or fear.

The tools are good enough now that "keep the data at home" isn't a compromise anymore. The model is the appliance, and the appliance sits in your building. That's the whole idea.

That's the standard. It's achievable, it's real, and it's the only one that survives contact with a headline.