Give, blur, keep local, or never share: the four buckets
Privacy decisions become unreliable when you make them in the seconds before pressing Send. The same client name is removed one day and pasted the next. A contract stays local, but a quoted sentence from it slips into the prompt.
Instead of relying on memory, give recurring kinds of information a default home in one of four buckets: Give, Blur, Keep local, or Never share.
This is a classification system, not a redaction tutorial. You decide the default treatment once, record it, and review exceptions when the question changes.
The four-bucket matrix
| Bucket | Use it when | Example | Default action |
|---|---|---|---|
| Give | The information is relevant, permitted, and not identifying | “We want fewer, higher-value projects” | Share only when the question needs it |
| Blur | The relationship matters but the identity or exact value does not | A named client with an exact monthly fee | Replace with “a long-standing client” and a broad range |
| Keep local | The source matters to your judgment but should not leave your notes | A contract containing a notice-period restriction | Share the non-sensitive implication; keep the document local |
| Never share | The material grants access or creates unacceptable exposure | Passwords, API keys, recovery codes, private keys | Do not place it in an AI handoff or an AI-context note |
The distinction between Blur and Keep local is the one most often missed.
Blur means the fact may leave your notes after identifying details are removed. Keep local means the source itself stays put; only the conclusion you are allowed to disclose may leave.
A material-by-material decision table
Use this table as a starting policy, not as permission to override a contract, employer rule, or service restriction.
| Material in your notes | Default bucket | What may enter the handoff |
|---|---|---|
| Current working goal | Give | “We want fewer, higher-value projects this quarter.” |
| Client name and exact monthly fee | Blur | “A long-standing client is on a mid-four-figure monthly retainer.” |
| Private project date | Blur | “The launch is in about three weeks.” |
| Contract clause | Keep local | Keep the clause local; write only an approved implication such as “The rate cannot change before renewal.” |
| Private correspondence | Keep local | Keep the message local; share a non-identifying conclusion only if permitted. |
| Password, API key, token, or recovery code | Never share | Nothing. Do not create a rewritten version for the handoff. |
The last column is the important one. A bucket is only useful when it tells you what to do with the source material, not merely what label to attach to it.
Classify types of information, not individual sentences
A useful policy is short enough to scan before a conversation:
# AI sharing policy
## Give
- Public product information
- General working goals
- Non-identifying preferences
## Blur
- Client situations
- Revenue and budget figures
- Dates tied to private projects
## Keep local
- Contracts and private correspondence
- Internal performance records
- Source documents covered by confidentiality terms
## Never share
- Passwords, API keys, tokens, and recovery codes
- Identity documents
- Information prohibited by law, contract, or company policyThis does not make every future decision automatic. It gives you a default. When a real question arrives, you check whether the service, organization policy, and purpose justify an exception.
One source can produce four different outputs
Imagine the studio has a private client contract. Different parts receive different treatment:
- Give: “We are protecting long-term client relationships.”
- Blur: “One established client is on a mid-four-figure monthly retainer.”
- Keep local: The contract clause itself stays in the vault; the handoff says, “The rate cannot change before the next renewal.”
- Never share: The e-signature link, account identifiers, and access credentials are excluded entirely.
The buckets apply to the information, not the file as one indivisible object. However, if reviewing the file safely is difficult, put the whole file in Keep local and write a separate, approved summary.
Review the policy when the environment changes
The correct bucket can change when:
- you move from a personal account to an employer-approved environment;
- a project becomes public;
- a confidentiality obligation ends;
- a new connector or third-party action can receive chat data;
- the provider changes its data controls or retention terms.
Review the policy when one of those conditions changes, not every time you open a chat.
Use the settings, redaction, and final-send checklist when you are preparing an actual handoff. That article covers the operational steps. This four-bucket policy decides the default treatment before those steps begin.