Is AI erotica private?

Layer one: is it published?

This is the layer that actually matters and the one people check least. Many AI erotica platforms are community products: stories go to a public feed, get their own URL, get indexed by Google, and get ranked against other people's.

You can verify this in about a minute for any tool. Fetch its sitemap.xml and look at what's in it. A platform with thousands of individual story pages is publishing user stories, regardless of what its settings page offers. RedQuill, to take the largest example in the category, has over seven thousand story pages in its public sitemap alongside a Discover feed.

That's a legitimate product design and lots of people want it. But 'private by default with a publish button' and 'no publishing mechanism exists' are different architectures, and only one of them is safe from you clicking the wrong thing at midnight.

SecretPen is the second kind. There is no feed, no sharing, and no way for one reader to reach another reader's stories, because nothing of that sort was ever built.

Layer two: does the company store it?

Any tool that lets you continue a story tomorrow is storing it. That's not sinister, it's how continuation works — but it does mean the honest question isn't 'do you store it' but 'who can see it, under what circumstances, and for how long'.

Ask any tool in this category three specific things. Is stored content used for model training? Can staff read it, and under what process? Is there a delete that actually deletes, including from backups, and on what timeline?

Be suspicious of an answer that only addresses the first one. 'We don't train on your data' is the easiest of the three to promise and the least useful on its own.

Layer three: the model provider

Almost every product in this category, including this one, sends your prompt to a third-party model provider. That's how the industry works — very few companies train their own model, and the ones who claim to usually mean they fine-tuned somebody else's.

This is the layer that no amount of front-end privacy design can fully solve, and any product telling you otherwise is overselling. What a product can do is be clear that the hop exists and choose providers with commercial terms that prohibit training on submitted content.

The practical implication: this is a good reason to keep real names out of your prompts. Not because anyone is reading, but because there is a category of risk that's cheap to avoid entirely. Write your neighbour as 'my neighbour', not as their name.

Layer four: the device you're reading on

The layers above are about the company. This one is about you, and in practice it's where privacy actually fails for most people.

Browser history is the obvious one, and the least interesting because everyone already knows about it. The ones people forget: autocomplete in the address bar, which will helpfully suggest a very specific URL to anyone who types two letters. Saved passwords listed under a domain name that describes itself. Push notifications appearing on a lock screen. A tab left open on a shared laptop. Cross-device sync putting your open tabs on a tablet somebody else uses.

Payment records are the one that catches people out most. A card statement is a document other people sometimes see, and a subscription line item is a durable record of a decision. This isn't a reason not to subscribe to things; it's a reason to know that the payment layer is a separate privacy surface from the product layer, and it's usually the leakier one.

The practical countermeasures are boring and effective: a separate browser profile, a private window as a habit rather than an exception, notifications off, and an email address that isn't the one your bank uses. None of this is about hiding from an adversary. It's about the ordinary mechanics by which private things become visible to people who weren't looking for them.

A realistic threat model

It helps to be specific about what you're actually protecting against, because the countermeasures for each are different and mostly cheap.

The overwhelmingly most likely scenario is somebody you live with picking up your device. This is a device-hygiene problem, not a company problem, and the fixes are the boring ones in the section above.

The second most likely is a breach — a company in this category getting compromised and account data appearing somewhere. What matters here is what's linkable: an email address that identifies you, a payment record, a username you use elsewhere. The mitigation is to break those links, which costs nothing and is worth doing before rather than after.

The least likely, and the one people worry about most, is somebody at the company reading your stories for entertainment. It's the least likely because there's no incentive and considerable liability, and because the volume makes it impractical. Worth asking about, not worth losing sleep over.

And one that isn't on most people's list but should be: search engines. If a platform publishes stories with URLs, those URLs are indexable, and a distinctive phrase from something you wrote becomes a searchable string forever. This is the failure mode with the longest tail, and it's entirely avoided by using a product that doesn't publish anything.

What a deletion promise is actually worth

Every product in this category offers a delete. The word covers a range of quite different things and it's worth knowing which one you're getting.

Soft delete: the record is flagged as deleted and stops appearing in the interface. The data is still there. This is the most common implementation because it's the easiest and it makes support requests recoverable.

Hard delete: the record is actually removed from the live database. Better, and still not the whole story, because backups exist and typically rotate on a schedule measured in weeks.

Hard delete plus backup expiry: the data is gone from live storage and will be gone from backups when the retention window rolls over. This is the honest maximum for any product that takes backups at all, which is every product you'd want to trust with anything.

The useful question to ask isn't "do you delete" — everyone says yes. It's "how long until it's gone from backups too". A product that answers that question with a specific number has thought about it. A product that doesn't understand the question hasn't.

Questions worth asking, and what a good answer looks like

Five questions. For each one, the shape of an answer that means something versus the shape of one that doesn't.

"Is my content used to train models?" A good answer names the providers and says the commercial terms prohibit it. A bad answer says "we respect your privacy" and moves on. This is the easiest of the five to promise and the least meaningful on its own — treat a confident answer here as table stakes rather than as reassurance.

"Can staff read what I write?" A good answer describes the circumstances — abuse investigation, a support request you initiated, a legal demand — and says who can authorise it. A bad answer is an unqualified no, because an unqualified no is almost never true and tells you the question hasn't been thought about.

"What's in your sitemap?" This one you don't ask, you check. It's the only question on the list with an answer you can verify yourself in thirty seconds, which makes it the most useful.

"How long until deleted content is gone from backups?" A good answer is a number of days. A bad answer is "immediately", which is not how backups work and indicates either confusion or marketing.

"What happens if you shut down?" The category has a high failure rate and small operators. A good answer covers export and deletion on wind-down. Most products have never considered it, and the ones that have are the ones planning to still exist.

What to actually do

Check the sitemap before you commit to a platform. Thirty seconds, and it tells you more about the product's real architecture than the privacy page will.

Use an email address that isn't your work one. Not because of any particular threat model, but because account linkage is the most common way private things stop being private, and it costs nothing to break the link.

Keep identifiable real people out of prompts — SecretPen refuses those anyway, but the habit is worth having everywhere.

And decide honestly which product you want. If you'd enjoy an audience, use a community platform and enjoy it properly. If the entire appeal is that nobody sees it, use something with no publishing surface at all — and verify that claim rather than taking it on trust.

None of this requires paranoia. It requires ten minutes once — a separate browser profile, an email that isn't your work one, notifications off, and a look at the sitemap of whatever you're about to use. After that you can stop thinking about it, which is the actual goal.