A woman's private diary, kept in a third-party AI app, was reported to police by the company. She now faces a felony charge. This is the clearest proof yet of the layer everyone keeps forgetting.
We've spent this series walking up the stack of things you quietly rent instead of own. Distribution (#45). The model layer (#46). Identity (#47). Access (#48). The harness (#49). The meter (#50). The runtime (#51). Today we reach the layer underneath all of them, the one that makes the rest matter: data.
The story that should stop you cold: a woman used a commercial AI assistant as a diary. She wrote things in it — the kind of things people write in a diary, which is to say things they would never say out loud. The company scanning that content flagged it and reported her to law enforcement. She is now facing a felony charge. Her most private thoughts, typed into a product she trusted, became the state's evidence.
Hosting is not ownership
Every time you put data into someone else's product, you are making a quiet trade. You get convenience — sync, search, uptime, an assistant that remembers. They get custody. And custody is a different thing from ownership in exactly the way that matters when the stakes are real.
You do not control who inside the company reads your data. You do not control what their automated systems scan for. You do not control which government their legal jurisdiction answers to, or what a subpoena, a reporting obligation, or an internal safety policy will make them do with what you wrote. Your terms of service describe a relationship you cannot enforce.
The uncomfortable lesson from this week's case is not "the company was evil." It may well have followed its own policy. The lesson is that a policy you don't write, applied to data you don't hold, can produce an outcome you never consented to — and you will not get a vote.
Your data is someone else's asset
Here is the second half of the trap. Data you host on a platform is not inert. It is fuel: it trains models, it trains ranking systems, it feeds analytics, it becomes a compliance artifact, it becomes a liability the platform manages on its own terms. Your operational data — supplier lists, customer conversations, pricing, a diary of your decisions — sits inside a system whose incentives are not yours.
For anyone running cross-border trade, this is not abstract:
- Jurisdiction is your problem, not theirs. Data stored in region X is exposed to region X's law enforcement and disclosure rules. You inherit that exposure the moment you click accept.
- Your supply chain is visible. The vendor who hosts your CRM knows your margins. The assistant that drafts your customer replies has read your customer list.
- Egress is a cost, not a right. When you finally want to leave, "can I get my data out, in a usable form, at what price, and can I prove I deleted it" is a question most platforms answer badly on purpose.
What owning your data actually looks like
Owning the data layer does not mean building a data center. It means four properties you can actually check:
- Exportable. You can pull your data out in a usable, machine-readable form, on demand, without their permission.
- Encryptable. End-to-end encryption where you hold the keys — so "reporting it" is technically impossible, not merely against policy.
- Self-hostable. At least one credible path to run the equivalent function on infrastructure you control, even if you don't use it daily.
- Deletable. You can verify deletion, not just request it.
This is the same four-part test we applied to the runtime. It applies here with more force, because data is the one layer whose breach arrives as a knock on your door.
The one-line version
A model you can't run is a model you rent. A runtime you don't control is a runtime you borrow. But data you don't hold is data that can be used against you — and unlike a bad vendor, that is not something you can migrate away from after the fact.
Own the layer under the layer. It's the only one where the worst case isn't downtime. It's you.
Top comments (0)