Here's a sentence that should give any practice pause, written plainly: "it runs in the cloud" and "your client's unbuilt scheme is now on a company's server you've never audited" are the same sentence. We don't usually say it that way because the first half sounds like a feature and the second half sounds like a problem, but they describe one event. Every cloud renderer trades local compute for a data transfer, and the data being transferred is, very often, a client's confidential project.
This isn't a reason to avoid cloud tools. It's a reason to do the one thing the adoption rush keeps skipping: read what happens to your files after you upload them. The architecture press is full of speed-and-fidelity comparisons and almost empty of anyone auditing the data terms. That gap is the whole subject of this piece — because the confidentiality question doesn't go away when you ignore it; it just waits for the wrong project.
What actually leaves your machine
Start with the mechanics, because "the cloud" hides them. When you use a hosted AI renderer, some combination of the following leaves your network:
- Your geometry or image — the massing, the plan, the sketch, the screenshot. For a model-import tool, that's the building itself.
- Your prompts and references — which can describe the program, the client, the site, the brief in plain language.
- Metadata — account identity, timestamps, sometimes file names that carry the project or client name right in the string.
And it frequently doesn't stop at the vendor. Many renderers are, as we've written elsewhere, wrappers around a foundation model from Google or OpenAI. That means your upload may pass to a second company's infrastructure — the model provider — under their terms, not just the vendor's. The chain of custody for your client's confidential scheme can be two or three companies long before the first image comes back, and most architects couldn't name the second link.
The chain of custody for a confidential scheme can be three companies long before the first render comes back. Most architects can't name the second link.
The four terms that actually matter
You don't need to become a privacy lawyer. You need to find four answers in the terms of service and privacy policy, and they're usually findable in fifteen minutes.
1. Retention
How long does the provider keep your uploads, and can you delete them? "Processed and discarded" is a very different posture from "retained indefinitely to improve the service." The good actors let you delete projects and say so plainly. The vague ones go quiet exactly here — and silence on retention should read as "indefinitely" until proven otherwise.
2. Training use
Can your files be used to train or improve the provider's models? This is the one that bites. If your client's unbuilt, competition-sensitive tower becomes training data, fragments of its form can in principle resurface in someone else's render. Look for an explicit "we do not train on customer content," and treat its absence as a yes.
3. Sub-processors
Who else receives your data? This is where the foundation-model provider hides. A vendor can have impeccable terms and still pass your upload to a third party whose terms you never agreed to. A serious provider publishes a sub-processor list. If you can't find one, you don't actually know where your model goes.
4. Jurisdiction
Which country's law governs, and where do the servers sit? For public-sector work, data-sovereignty requirements may rule out a tool outright regardless of how good its terms otherwise are. For private work under an NDA, the governing jurisdiction determines what recourse you'd actually have if something went wrong.
Find the retention policy and confirm you can delete · Find an explicit "we don't train on your content" statement · Find the sub-processor list and note the foundation-model provider · Confirm the governing jurisdiction satisfies your client and any public-sector rules · Match the result against the specific project's NDA. If any answer is missing rather than reassuring, treat the tool as cloud-public and keep confidential work off it.
Where the line actually falls
Not every project carries the same risk, and treating them all the same is its own mistake — either you needlessly avoid useful tools, or you needlessly expose sensitive ones. A practical tiering:
- Low stakes — cloud is fine. Speculative concepts, internal studies, marketing imagery for a built and published project, personal experiments. The confidentiality cost is near zero; use the fastest tool.
- Medium stakes — read the terms first. Live private commissions under a standard contract. Cloud is usually fine if the four answers check out, and a real risk if you never looked.
- High stakes — local or explicit consent only. Anything under a specific NDA, competition entries, public-sector and defence work, high-profile clients who'd be damaged by a leak. Here the structural guarantee of local rendering is worth its inconvenience, or you get written client consent for the specific tool before a single file leaves your machine.
The local alternative, honestly
This is exactly the gap local tools are built for. ComfyUI running Stable Diffusion on your own hardware is pitched — accurately — as the option where projects never leave your network. There's no upload, so there's no retention question, no training-use exposure, no sub-processor chain. The confidentiality guarantee is structural: it holds because the data physically never moved, not because a company promised in a document you hope they honour.
The honest trade-off is real, though. Local means setup complexity, a capable GPU, and a steeper learning curve than a website you log into. For a solo practitioner doing occasional concept work, that cost may not be worth it. For a practice that regularly handles confidential or regulated projects, it increasingly is — and the calculus is shifting as the work gets more sensitive and the tools get easier. The point isn't that everyone should render locally. It's that for high-stakes work, "the data never left" is a guarantee no terms-of-service can match.
| Dimension | Cloud renderer | Local (ComfyUI-type) |
|---|---|---|
| Data leaves your network | Yes — vendor + maybe model provider | No — stays local |
| Confidentiality guarantee | Contractual — only as good as the terms | Structural — data never moved |
| Setup & hardware | Log in, no GPU | Real setup, capable GPU |
| Best for | Low/medium-stakes, speed-first work | NDA, competition, public-sector work |
| Effort to verify safety | Read four sets of terms | Nothing left your machine |
Our take: render fast, but know what you uploaded
The confidentiality question isn't an argument against cloud rendering — it's an argument against using it unconsciously. The speed is genuine and the tools are good, and for the large share of architectural imagery that carries no real secret, the fastest cloud tool is the right answer and the terms barely matter. The failure mode is uniform thoughtlessness: treating an NDA-bound competition scheme exactly like a throwaway concept sketch because both go through the same convenient website.
So make it a habit, not a crisis. Run the fifteen-minute audit once per tool before its first confidential project. Tier your work honestly into low, medium and high stakes. Keep a local option in your back pocket for the high end, and get written consent when local isn't practical and the project is sensitive. Do that and you get the speed without the exposure. Skip it, and you're one wrong upload away from explaining to a client why their unbuilt building was training data — a conversation no render time saved will ever buy back.
We audit the parts of AI tools the speed comparisons skip — including where your data goes. Join the studio newsletter for the practice-risk notes, or read our companion analysis on who's actually training the architecture AI.
General practice guidance, not legal advice. Data-handling terms vary by provider and change over time; verify each tool's current terms of service, privacy policy and sub-processor list, and consult your own counsel for NDA, public-sector or data-sovereignty obligations. No affiliate relationship with any tool named.