Client Confidentiality & Data

Confidentiality is not a courtesy in a design practice; it is a professional obligation, usually written into your appointment and often reinforced by a separate non-disclosure agreement. Councils and institutes worldwide treat a member's discretion about client affairs as a bedrock of the relationship, and a client who feels exposed rarely comes back and often tells others. So the first question about Claude is not "is it clever enough?" but "what am I allowed to show it, and on whose authority?"

Think concretely about what actually passes through your hands. A residential brief can contain a family's names, their address, their income band, when the house sits empty, where the safe room is, and a child's disability. A commercial job can contain unannounced expansion plans, lease terms, or a retailer's floor efficiency. Interior work carries client budgets, supplier discounts, and the private taste of people who value their privacy precisely because they can afford to. Much of this is exactly the context that makes Claude useful - and exactly the context a client never consented to see routed through a third party.

The correct instinct is to separate the *design problem* from the *client's identity*. Claude almost never needs to know that it is the Mehta family on a particular plot; it needs to know that it is a family of five on an urban infill site with a tight budget and a security concern. You can nearly always get the help without exposing the person. The rest of this lesson is a practical method for doing that reliably, plus an honest account of how your plan treats what you do send - because settings, not good intentions, are what actually protect the data.

One framing to carry throughout: treat every paste as if it might one day be read by someone you did not choose. That is not paranoia; it is the ordinary standard of care you already apply to a client's drawings on a shared drive or an email chain. Claude is simply another place that standard has to reach.

How your data is treated depends heavily on which Claude you are using, and this is the single most important fact in the lesson. As of 2026 - and this is the kind of detail that changes, so verify it against Anthropic's current terms and your own account settings - the picture is roughly this. On consumer plans (the free tier and personal paid tiers), your conversations *may be used to help improve Claude unless you opt out*, and retention settings apply. That means the default posture on a personal account is not the right home for confidential client work until you have checked the settings and turned training off where the option exists.

Business plans (Team and Enterprise) and the API are different: usage there is generally *not used to train models by default* and comes with stronger data controls, administration and retention terms. This is why the honest recommendation for any studio doing real client work is to move that work onto a business plan or API-backed tool, rather than relying on individuals to remember to flip a switch. The difference is not about how clever the model is - it is the same Claude - it is entirely about the contract that governs your data.

Three rules follow, and they hold regardless of plan. First, check your current privacy and data-retention settings yourself; do not assume a default. Second, strip or anonymise client identifiers whenever you can - the less that travels, the less any setting has to protect. Third, when in doubt, keep it out: if a piece of information would embarrass you in front of the client were they watching you paste it, that is your answer. And remember the layer above all settings - your client's NDA and your professional duty. A tool being configured well does not override a promise you made to a client; where the two might conflict, a lawyer decides, not a checkbox. None of this is legal advice; it is a working discipline built on top of terms you must read for yourself.

Anonymising sounds tedious; done as a habit it takes seconds and costs you nothing in usefulness. The move is to replace identity with description. "The Sharma family at Plot 42, Koramangala, budget 1.8 crore, safe room behind the master wardrobe" becomes "a family of four on an urban infill plot of about 230 square metres, upper-middle budget, wanting a secure store off the master suite." Claude gives you the same programme logic, the same spec drafting, the same option comparison - it never needed the surname, the pin code, or the exact figure to help you think.

A quick, repeatable checklist before you paste anything client-related:

Before you paste, remove or replace:
- Names (client, family members, staff)
- Exact address, plot number, GPS, project code
- Precise budget figures (use a band: "upper-mid")
- Security details (alarm, safe room, access, cameras)
- Anything explicitly marked confidential or under NDA
- Personal/medical details tied to a named person
Keep: the design problem, sizes, climate, constraints,
the question you actually need answered.

For drawings and PDFs the same logic applies: crop out the title block, the client name, the site plan with the address, before you upload. Claude reads what is on the sheet, so what is on the sheet is what you have disclosed.

When a task genuinely needs the raw, identifiable material - and some do, such as drafting a letter that names the client - that is the signal to be on a business or API-backed setup with terms you have checked, not on a personal free account. The decision path in the figure captures it: if the content is confidential, personal or under NDA, you do not paste it raw; you go down the ladder - anonymise, then move to a properly-termed plan, and if it is still too sensitive, keep it out and do that part by hand. This is not a counsel of fear. It is the same judgement you already exercise about who gets copied on an email; you are simply extending it to a new and very capable recipient.

Individual good intentions do not scale; a written rule does. The most useful thing you can do after this lesson is spend twenty minutes writing your studio's one-page Claude data policy, so that a new junior on their first day knows what is allowed without having to ask. It does not need to be legalistic - it needs to be clear enough to follow when you are tired at 7 pm.

A workable policy names four things. Where client work happens: on the studio's business/Enterprise account or approved API tools, never on personal free accounts, with training turned off and settings verified. What is never pasted, even anonymised: the specific items your clients and NDAs forbid - name them. How to anonymise: the replace-identity-with-description habit, with the checklist pinned somewhere visible. And who to ask when a case is unclear - a named person, so uncertainty resolves upward rather than into a risky guess.

Two further honesty notes belong in any such policy. First, connectors and web features vary by plan and can widen what is exposed; treat any integration that reaches into your drives or the web as a decision to review, not a default to accept. Second, the policy is a living document - Claude's terms and features change, so put a review date on it and check it against Anthropic's current privacy terms periodically, exactly as this course puts a last-verified date on its own facts.

The reward for this small discipline is large: you get to use Claude across confidential work with a clear conscience and a defensible position, because you can say precisely what you did and why. Confidentiality handled well is invisible - no one notices it working. It is only ever noticed when it fails, and by then the trust it protected is already gone. Build the habit now, while the stakes of a slip are still hypothetical, and it will simply be how your studio works.