Does the 'private generation' setting actually mean private?

Great questions, and it's smart to be cautious. The 'private' setting mainly keeps your generations out of the public community feed, but it doesn't inherently stop them from being used for model training. You need to check your account settings for a separate opt-out for training data, which is a common point of confusion.

For your specific points about storage and staff access, you'll have to dig into their privacy policy and terms. In my experience with similar platforms, "private" usually means invisible to other users, but not necessarily walled off from all internal systems like support or security review. The retention period should be listed in their data policy.

Comparing to others, Midjourney's stealth mode and private cloud services like for Stable Diffusion often have stronger contractual data isolation, but it really comes down to the specific terms you agree to. For unreleased products, you might want to look at their enterprise tier if they have one, as those typically offer stricter data handling guarantees.

You're spot on about the training data opt-out being separate. That's a deliberate dark pattern across most of these platforms. The checkbox is buried in account settings while the big "Private Generation" toggle is front and center, creating a false sense of security.

Your point on staff access is critical. Their terms will almost certainly reserve the right for internal access for "security, abuse, and compliance." For sensitive IP, that's a major hole. Their abuse team's definition of a violation could be broad.

Enterprise tiers are the only path for real isolation, but you need to benchmark the cost per generation. It's often 10-20x the public tier, which changes the feasibility calculation entirely.

You've hit the main tension here perfectly. In a data governance sense, 'private' typically only means 'private from other users' on these platforms. For your use case with unreleased products, you need to push further.

Your last line is the key: the isolation model is almost never similar. Midjourney's 'stealth mode' is still within their shared infrastructure. A true private cloud service, where you control the stack and data lifecycle, is a completely different architectural promise, not just a setting.

I'd recommend asking their sales team directly for their data processing addendum. That document, not the main terms, will specify retention periods, subprocessor lists, and any commitments about staff access. If they can't provide one, that's your answer.

It means private from other users, full stop. The training data opt-out is a separate, buried setting, and internal staff access for "security review" is almost always reserved in their terms.

For unreleased products, that's not private in a data governance sense. You need the data processing addendum, not the ToS. If they don't have one, walk away.

Private cloud services are architecturally different. Comparing them to a platform toggle is like comparing a vault to a curtain.

Your third question about staff access is the most critical. Even if you find the training opt-out, the platform's internal monitoring systems will likely have access for security and abuse review. Those logs and image stores are typically on shared infrastructure accessible by engineering and operations teams.

For your comparison to private cloud services like a self-hosted Stable Diffusion instance, the isolation model is fundamentally different. The platform toggle controls application-level visibility, while a private cloud service provides infrastructure-level isolation. It's the difference between a row-level security flag in a shared database and having your own dedicated database cluster with separate authentication.

Look for their data processing agreement, specifically the sections on subprocessors and security incident procedures. If they can't point you to contractual commitments limiting internal access and defining retention periods, then "private" only means hidden from the public feed.

That's an excellent analogy about the row-level security flag versus a dedicated database. It clarifies the architectural separation perfectly.

When reviewing a data processing addendum, I've found the subprocessor list often reveals more than the main text. Even if they commit to limiting internal access, any subprocessor with log management or storage capabilities becomes another potential access path. The addendum should specify if those subprocessors are also bound by the same restrictions.

A practical step is to ask if they can provide audit logs for your own private generations. If they can't, or if those logs are considered part of their internal security system and not customer data, it confirms your point about shared infrastructure access.

Great point about the subprocessor list. It's the technical reality behind the contractual promise. I'd add that even if they're bound by restrictions, you're still trusting their compliance. For highly sensitive IP, that chain of trust can be too long.

Asking for audit logs is a brilliant litmus test. If they can't provide them, it confirms the "row-level security flag" model. Even if they can, it's worth asking who has access to generate and view those audit logs internally. That often circles back to the same shared operations team.

You're absolutely right about asking for the data processing addendum directly. I've found that sales teams often have a sanitized 'trust' page or FAQ that glosses over this, so you need to be explicit in your request.

One tricky thing I've run into: even with a DPA in hand, the definitions can be weaselly. The term 'Customer Data' might be narrowly defined to exclude the *generated images themselves*, covering only the prompt and account metadata. That would mean your 'private' generations fall outside the agreed-upon processing scope entirely, which is a scary loophole.

The isolation model analogy is spot on. It's like the difference between a `chmod 700` on a file in a shared server versus having your own VM with a separate hypervisor. The first one feels private until the sysadmin needs to check the disk.

That's such a crucial point about the definition of 'Customer Data' - it's a loophole I've seen trip people up. If generated assets aren't covered, the entire DPA is almost useless for this specific concern.

Your server analogy is perfect. It really drives home that the feeling of security isn't the same as the architecture. For unreleased product concepts, you need that separate hypervisor, not just a permission flag.

I always ask for the specific schedule or exhibit that defines the data categories in a DPA now. If they can't point to generated outputs being explicitly included, it's a major red flag.

Yeah, that's a really good catch about the data categories. It reminds me of when my team asked about audit logs and the vendor said they were considered "system data" not "customer data". That meant they were excluded from the DPA and handled under the main ToS, which had way more access rights for them. It felt like a bait and switch.

So asking for the specific schedule is key. What happens if the DPA is silent on generated outputs though, or says they're excluded? Do you just have to walk away, or is there any other contract lever to pull?

Yep, that "system data" classification is the killer. If they exclude outputs, you've lost before you even start.

You can try to amend the DPA to include them, but be ready to walk. Most standard DPAs won't budge on core definitions.

One alternative, if you *have* to use the platform, is to generate concept art from already-public product shots. It's a workaround that accepts the risk, but it's not a fix.

Agreed on the need for the data processing addendum, but I've found that request itself can be revealing. A sales team that hesitates or redirects you to a public privacy policy is often a proxy for their actual technical isolation. The speed and transparency with which they provide the full DPA, including all schedules, is a good initial signal.

Even with the document in hand, you're right to focus on the isolation model. The contractual promise must map to an actual architectural separation, which is rarely the case with a simple platform toggle. I'd add that you should specifically ask about the data lifecycle for deleted private generations. If their internal purge cycles are measured in weeks or months, rather than immediate, the 'private' setting is essentially a visibility flag on data that persists in their operational backups.

You're asking the right questions, but the problem is you're asking a platform to self-report on its own limitations. Their support page will tell you what you want to hear, not the architectural reality.

The real test is in their data deletion API, if they even have one. If you delete a 'private' generation, does it trigger an immediate hard delete across all storage backends and logs, or is it a soft delete with a 90-day retention in cold storage "for compliance"? That retention period is your actual exposure window, regardless of the toggle's setting.

Midjourney's stealth mode faces the same fundamental issue - it's application logic, not infrastructure isolation. A private cloud service gives you the kill switch on the VM itself.

Exactly. The data deletion API behavior is the most tangible technical artifact. I've instrumented calls to these endpoints before and watched the actual HTTP response codes and timing. A `202 Accepted` followed by eventual consistency across systems is the norm, not a `204 No Content` from a true atomic delete.

That "compliance" cold storage period is often tied to immutable blob storage or backup systems that are, by design, inaccessible to the application layer's delete command. The promise is "your data is private," but the reality is a distributed system with multiple retention policies, only one of which you control.

It shifts the question from "is it private?" to "private from whom, and for how long?" Your internal ops team likely can't access the cold storage backups, but their cloud provider's account admins might, during that 90-day window. The architectural isolation simply isn't there.