Most AI privacy advice stops at "don't paste sensitive information into ChatGPT." That rule is now openly broken by tens of millions of responsible professionals every day, because the work that needs doing — risk review on a contract, assumption-checking on an operating plan, summarising notes nobody organised — is also the work that requires the model to see real, sensitive material. The fix is not another training module. The fix is a different operating habit: start with the job, then give the model a stripped copy that contains only the facts the job needs, and leave the original untouched on your machine.
The verdict after testing this across contract reviews, launch plans, and meeting notes is simple: redaction that preserves AI usefulness is harder than redaction that just hides everything — but it is the only kind that actually changes behaviour, because it does not cancel out the time AI was supposed to save. Below is the 2026 job-first redaction framework, the five items you almost always remove, the tool landscape (with what to use when), and the systemic reason "don't upload anything" failed.
Last verified: 2026-07-29
- The problem: 45% of employees now use AI on a corporate device at least once every 15 days — up from 15% a year earlier — and 67% of those users access AI through non-company accounts (Verizon 2026 DBIR). Source code is the most common sensitive material leaked.
- The fix: Define the job first, strip identifiers the job does not need, rebuild a clean copy (do not redact in place), then hand the smaller file to any frontier model.
- Why "don't upload" failed: It hands every user the full privacy-engineering load. NIST calls the resulting state "security fatigue" — when security decisions pile up, the easiest option wins (NIST, IT Professional 2016).
Why "just don't paste sensitive data" stopped working in 2026
A normal AI interaction in 2024 was a general question in an empty chatbot — "write the email", "explain the concept", "give me 10 ideas." Sensitive disclosure was rare because the surface was small. By 2026, the surface has shifted to your material: the actual proposal you are sending, the contract you are negotiating, the meeting notes nobody organised, the codebase your team is trying to understand. A useful answer now needs real context, and that context is exactly where the confidential information lives.
The result is two equally-bad patterns among careful users:
- Trust-forward users run with scoped connectors, training off, agents limited to a development dataset — and still admit, in private, that they are "relying on trust more than I'm comfortable admitting."
- Abstainers (common in healthcare and defence) keep the most valuable data away from AI entirely, using the model only "around the edges" where the information looks like every other industry. The work that could benefit most stays out of reach because the risk feels asymmetric.
Telling either group to "attend another annual training course" does not help. The benefit of an AI upload is immediate (you save an hour); the cost is delayed, uncertain, and usually invisible. That asymmetry is exactly the condition NIST documented a decade ago as security fatigue: when the same security decisions pile up, the easiest option starts to win. On a phone, that means people reuse passwords; with AI, it means the upload button keeps getting pressed because the approved route is harder than the unapproved one.
What should you actually remove before sending a file to ChatGPT?
The honest answer is: it depends on the job — but five categories are almost always safe to strip from a business document before any frontier model sees it. Each item below is "almost always removable" because it is rarely load-bearing for the analytical question you are asking, and it is exactly the kind of bundled context that leaks incidentally.
| # | Item | Remove it if your task is… | Keep it if your task is… |
|---|---|---|---|
| 1 | Customer / client names and project codenames | Risk review, assumption-checking, summarising | A customer-specific proposal rewrite |
| 2 | Personal addresses, emails, phone numbers | Anything analytical | N/A — almost never job-relevant |
| 3 | API keys, tokens, credentials | Anything — there is no analytical job that needs credentials | N/A — never paste secrets into a model |
| 4 | Private medical or HR notes | Strategy, planning, summarising | The clinical analysis itself — and only in a governed environment |
| 5 | Confidential pricing or unreleased numbers | Assumption-checking, plan stress-testing, summarising | Evaluating the pricing itself |
The fifth row is the one people get wrong. The same dollar figure is essential context if you are asking the model to evaluate whether the price is right, and noise if you are asking it to identify the assumptions most likely to break the launch. The job decides. If you cannot articulate what the model needs the number for, leave the number behind.
How to redact a document for ChatGPT in 5 steps (the job-first workflow)
- Define the job before you open the file. Write one sentence: "I am asking the model to ___." Everything downstream branches off this sentence. If you skip it, you will default to either hoarding or over-redacting.
- List the protected terms that only mean something inside your company. A string like "Project Lantern" looks ordinary to a machine but may anchor months of confidential work. Pattern matchers (emails, phones, addresses) will not catch it — these are context-only secrets, and you have to supply the context.
- Mark every detected item as keep / remove, with the default set to remove. When you are uncertain, hide the item. You can always choose to keep a thing, but you should have to choose on purpose — that single friction point is the difference between redaction and a leak.
- Rebuild a separate clean copy. Do not draw black boxes over the original. Word files (and any
.docxproduced by Google Docs, Pages, or LibreOffice) are ZIP archives of XML. Comments, track-changes history, author names, old edits, and deleted text survive "Accept All Changes" and can be read with any text editor (MetaClean 2026 guide). Rebuilding approved material into a new file is safer than redacting in place because it leaves the contaminated XML behind. - Read the clean copy yourself, then send it to any frontier model. You now have two documents: the untouched original on your machine, and a smaller copy that contains only what the job needs. The model can do useful work; the confidential identifiers never left your control.
Why Word documents leak even after you "accept all changes"
This is the technical reason step 4 matters so much. A .docx file is a ZIP archive full of XML files. Every edit, every author, every comment, and every tracked deletion is written into that XML — and most of it survives Word's "Accept All Changes" button untouched. The visible page can look clean while docProps/core.xml still carries your OS username as the author, docProps/app.xml still carries your employer's name from the Office licence, and word/document.xml still carries <w:ins> and <w:del> elements with the original text you thought you deleted (MetaClean 2026).
There is a documented lineage of this causing real-world damage: the SCO Group's 2004 lawsuit against DaimlerChrysler had to be explained after reporters found the tracked-changes metadata in the filed Word document still named Bank of America as the original defendant. The fastest way to check a Word file before sharing is to rename .docx to .docx.zip, extract it, and open docProps/core.xml in any text editor — author names, dates, and revision counts are visible in plain text within seconds.
Rebuilding a stripped copy into a new file (or pasting the approved text into a plain-text or Markdown file before sending) sidesteps this problem entirely. You are not trying to scrub a contaminated container; you are building a clean one.
What tools redact PII before sending to AI models?
A 2026 redaction stack has three layers, used in combination. None of them replaces the job-first decision; they implement it.
| Tool class | What it does | Example (2026) | Best for | Limit |
|---|---|---|---|---|
| Local pattern matcher | Regex + dictionaries for emails, phones, API keys, SSNs, credit cards | Scrub.py, Presidio, browser extensions like KernelSpecter AirLock-extension | Stop accidental credential and PII pastes into ChatGPT/Claude/Gemini | Misses context-only secrets like "Project Lantern" unless you add them |
| Context-aware privacy firewall | Local-first app that lets you declare protected terms, scans the document, hides suspects by default, and rebuilds a clean copy | Airlock (source-available, GitHub: NateBJones-Projects/ai-airlock) | Documents where the sensitive bits are not纯 pattern matches (codenames, internal phrases) | You still have to make the keep/remove call per item |
| Enterprise DLP + governance | Org-wide policy enforcement, account-level visibility, training-off by default | ChatGPT Enterprise, ChatGPT Business (OpenAI Enterprise Privacy) | Compliance-bound teams that need the model to never see training data at all | Prohibition has consistently failed — shadow AI keeps growing even where banned |
A pure pattern matcher is necessary but not sufficient. The honest reason a tool like Airlock exists is that the genuinely hard part of redaction is not detection — it is the meaning-making question of which facts make the task solvable and which facts only came attached for the ride. A pattern matcher can flag a Social Security number. It cannot decide whether the unreleased price in your operating plan is load-bearing for a risk review.
The third row is where most enterprise policy lives today, and it matters: ChatGPT Business, Enterprise, Edu, and the OpenAI API do not train on your inputs or outputs by default (OpenAI help: business plans do not train by default). On a personal ChatGPT Free, Plus, or Pro workspace, the opposite is true — model-improvement training data sharing is on by default and must be opted out from Your Profile > Settings > Data Controls. The tier you are on changes the threat model; the redaction habit is still the same.
What is "shadow AI" and why is it a 2026 inflection point?
Shadow AI is the use of AI tools by employees without IT knowledge or approval. It differs from classic shadow IT in one critical way: AI tools actively process and may retain the data you give them, so the data leakage happens at the point of use, not just because an app was installed.
The 2026 Verizon Data Breach Investigations Report put numbers on what was previously anecdote: regular AI use on corporate devices jumped from 15% in 2025 to 45% in 2026, and 67% of those users accessed AI through non-corporate accounts the enterprise cannot see or control. Source code was the single most common sensitive material submitted. Shadow AI is now the third most common non-malicious insider action in Verizon's DLP telemetry — a quadruple increase in one year (Verizon 2026 DBIR; SecurityWeek analysis).
You can read this as a story about irresponsible employees. The more useful question is: why is the unapproved route easier to find and use than the approved one? The unapproved route is one upload button. The approved route is an admin console, a vendor contract, a data-residency review, and a quarterly policy training people skim on a Friday afternoon. Until the approved path is at least as fast as the upload button, fatigue wins.
IBM's 2025 Cost of a Data Breach report estimated the average additional breach cost linked to shadow AI at roughly $670,000 per incident, and 63% of organisations that had an AI-related breach did not have an AI governance policy in place at the time. Gartner projects shadow AI incidents will triple by the end of 2026. The pattern is the same in every dataset: prohibition fails, governed enablement works.
For system-level defence — sandboxing, permissions, provenance — see our agentic AI security playbook and the deeper LLM infrastructure security guide. Redaction at the data layer is the front door; those articles are the rest of the building.
When is redaction the wrong answer?
Redaction is the right answer when the analytical question does not need the identifier. It is the wrong answer when removing the identifier removes the task.
A medical record where the full history is the reason the analysis has value cannot be redacted into usefulness. In that case the right answer is one of two things: do the work in a governed clinical environment built for the full record, or do not involve the model at all. Pretending you can anonymise the record while keeping the work intact is the kind of trade-off that quietly degrades both.
A contract is the boundary case. If you want the model to find renewal dates or unusual indemnity language, it needs the clauses and the dates — there is no version of that job that survives removing the dates. If you want it to rewrite the cover email, you do not need the negotiated prices at all. The same document and the same model produce two different redaction decisions, because the job is different.
This is the discipline the job-first framework enforces: state the job, then decide the file. Reverse the order and you either over-share or over-strip.
What this means for you
If you run a small business or a team:
- Make the approved path faster than the upload button. Anything slower is malpractice at the policy level, because it does not stop the upload — it just moves it to a personal account no one can audit.
- Default to a stripped copy, not a black box. Plain text or Markdown rebuilt from approved material sidesteps the entire Word-XML metadata problem. The model loses nothing important; you keep everything important.
- Pick your tier deliberately. A team plan with training off changes the downstream risk materially (no-retention contracts exist for ChatGPT Enterprise/Business and the API by default). On free tiers, training is on by default — redaction is the only effective control.
- Treat credentials as a hard line. There is no analytical job that needs an API key pasted into a model. If you find yourself about to paste one, stop.
- For work that cannot be redacted, choose the governed path or no path. Half-measures have all of the cost and none of the benefit.
If you want a deeper sandbox-and-containment view of what happens after the file has left your machine, our AI agent sandbox containment playbook covers the model-side containment problem. For keeping the entire workload off the cloud entirely, our guide to running local AI on your computer is the alternative path.
FAQ
Q: Can I use ChatGPT on sensitive client documents if I have a Team or Enterprise plan? A: ChatGPT Business, Enterprise, Edu, and the OpenAI API do not train on your inputs or outputs by default per OpenAI's published enterprise privacy policy. A Team plan with training off materially reduces but does not eliminate risk — you are still sending data to a third party. If the document contains credentials, personal health information, or material non-public information, redaction (or a local model) is still the right call regardless of tier.
Q: Does redacting names and numbers make the AI's answer useless? A: Not if you redact only what the job does not need. The same contract needs the indemnity clauses for a risk review but does not need them for a cover-email rewrite. The test is the one-sentence job definition: "I am asking the model to ___." Anything outside that sentence is a candidate for removal. Strip too much and the answer degrades; strip too little and you leak. The job is the calibration.
Q: What is the difference between redaction and encryption? A: Redaction removes the sensitive data from the copy you send; the data is gone, not just scrambled. Encryption protects data in transit and at rest but leaves it recoverable by whoever holds the key. For sending material to a third-party model, redaction is the stronger control because the model platform cannot leak what it never received.
Q: How do I check a Word document for hidden metadata before sharing?
A: Rename the .docx to .docx.zip, extract it, and open docProps/core.xml and word/document.xml in any text editor. Author names, revision counts, tracked-change elements (<w:ins>, <w:del>), and the company name from your Office licence are all in plain text. Word's built-in Document Inspector catches most of it but not everything; for sensitive material, rebuild the approved text into a fresh plain-text or Markdown file rather than relying on in-place scrubbing.
Q: Is "security fatigue" a real published concept or a buzzword? A: It is a real NIST-published research construct. Stanton, Theofanos, Prettyman, and Furman documented it in IT Professional (vol. 18, no. 5, 2016) after semistructured interviews with 40 users. The finding: when the same security decisions pile up, users reach a "compliance limit" and choose the easiest option, including risky ones — not from recklessness, but from decision fatigue. The NIST publication is publicly available.
Q: What is the single biggest mistake people make when redacting before AI use? A: Redacting in place — drawing black rectangles over or "accepting all changes" inside the original document — instead of rebuilding a clean copy. In-place redaction leaves the original sensitive material in the file's XML and metadata, where any text editor can read it back out. Rebuilding approved text into a fresh file leaves the contaminated container behind entirely.
Discussion
0 comments