Lesson 14 of 38 · AI 101 - 12 min

AI 101: Use Document AI Safely

Build a one-page document-AI handling policy that any non-technical colleague can follow under pressure: classify a document's risk, decide allow / ask-first / never-use per action, choose the right tier (consumer chat vs business/enterprise vs local), redact properly, and leave an audit trail - so you get the productivity of document AI without leaking PII, breaching a contract, or feeding regulated data into a model that trains on it.

Expanded from secure local AI and sensitive document themes

Document AI is valuable precisely because documents hold the real operational knowledge of a business - the contract terms, the customer history, the policy exceptions, the numbers behind the dashboard. That is also exactly why pasting them into the wrong tool is one of the fastest ways a small team can cause a data breach. The risk is rarely the model 'being evil'; it is mundane: a personal ChatGPT or Claude account whose default settings retain and may train on what you type, a connector wired to an entire SharePoint instead of one folder, a 'redacted' file that still names a town of 1,200 people, or a deleted chat that turns out to be legally preserved. Before anyone uploads PII, internal reports, transcripts, contracts, or customer material, the team needs a policy that is simple enough to obey at 4:55pm on a Friday. That policy is what you build here.

Video

Use document AI safely

A branded walkthrough: classify documents by sensitivity first, prefer enterprise tiers or local processing for confidential data, and keep audit trails and human oversight on every output.

What to understand

  • Classify before you paste. Four classes carry different rules: PUBLIC (already published - marketing copy, public filings), INTERNAL (not secret but not for outsiders - process notes, draft plans), CONFIDENTIAL (commercially sensitive - pricing, unsigned contracts, strategy), and SENSITIVE (PII, health, financial, staff, or customer records, plus anything regulated). The action you want - summarise, rewrite, extract, share - changes the answer for each class. The grid below is the whole decision in one view.
  • The same prompt is not equally safe everywhere - the plan tier decides. On consumer Claude (Free/Pro/Max), Anthropic's August 2025 terms changed the default: unless you opt out, new chats can be used for model training and retained up to five years (Anthropic, Aug 28 2025). On personal ChatGPT, chats are retained and can be used to improve models unless you turn it off. On business/enterprise tiers (ChatGPT Enterprise/Team/Edu and the API; Claude for Work/Enterprise/Education), the default flips: business inputs and outputs are NOT used for training, with shorter or configurable retention (OpenAI Enterprise Privacy; Anthropic Privacy Center, 2026). The tool name is not the control - the tier is.
  • 'Deleted' does not always mean gone. A 2025 US federal court ordered OpenAI to preserve consumer ChatGPT and API logs - including chats users had deleted - as evidence in the New York Times copyright case; in November 2025 the court ordered 20 million de-identified logs produced to plaintiffs. ChatGPT Enterprise was explicitly excluded from the preservation order (OpenAI, 2025; National Law Review, Nov 2025). Lesson: legal hold can override a retention promise on consumer tiers, so sensitive material should not live there at all.
  • Redaction is not magic, and it fails on indirect identifiers. Removing a name leaves the date, the rare job title, the team of three, the unusual diagnosis, the small town. Combined, those re-identify a person. Treat redaction as risk reduction, not anonymisation - and prefer a synthetic stand-in (a realistic but fake document) for prompt-building and testing whenever the real content is sensitive.
  • Local-first is the defensible default for regulated or high-harm material. When a document contains health data, legal privilege, unreleased financials, or large volumes of customer PII, do the AI work on a controlled local or approved private environment first, and only send a redacted or synthetic version to a cloud tool - if at all. 'Local first' is a workflow rule, not a product.
  • Scope permissions to the smallest set that does the job. A connector pointed at an entire Google Drive or SharePoint gives the AI - and anyone who can prompt it - reach over everything. Point it at one folder, or one file, and grant read-only where possible. Broad scope is the most common quiet over-exposure in document AI.
  • Audit trails and a human checkpoint make the workflow reviewable. A one-line log - filename, date, tool + tier, data class, owner, approval status - turns 'we used AI on a document' into something you can defend to a client, an auditor, or a regulator. And for any legal, financial, medical, or employment judgement, AI output is a draft for a qualified human, never the decision.
  • Frameworks are converging on exactly this discipline. GDPR already treats the AI vendor as a data processor you must contract with (Art. 28) and bans uncontrolled cross-border transfer; the EU AI Act (Reg. 2024/1689) adds transparency and governance duties, with most obligations applying from 2 Aug 2026. A simple classify-and-log policy is the practical floor those rules assume.

Deeper dive

The breach is almost never the model - it's the default settings

The instinct is to fear the AI 'remembering' or 'leaking' your document on its own. The real-world failures are duller and entirely preventable. Failure one: someone uses a personal account whose defaults retain and may train on input, so a customer list or an unsigned contract becomes training-eligible content - on consumer Claude that has been the default since August 2025 unless you opt out, with retention extended to five years. Failure two: a connector is scoped to an entire drive, so a well-meaning summary prompt can surface files the person was never meant to read. Failure three: 'delete' is treated as erasure, when a legal hold can freeze everything - in 2025 a US court forced OpenAI to preserve and later produce millions of consumer ChatGPT logs, including deleted ones, in the New York Times case (ChatGPT Enterprise was excluded). None of these require a clever attacker. They require only that nobody classified the document and nobody checked the tier. That is why the policy, not the tool, is the control.

Why redaction quietly fails: the mosaic effect

Removing the obvious identifiers - name, email, account number - feels like anonymisation, but privacy regulators have warned for years about the 'mosaic' or re-identification effect: the leftover details combine to point at one person. A redacted incident report that keeps the date, the department of four, and a rare role re-identifies the employee to anyone inside. A 'de-identified' patient note that keeps an unusual condition plus a small town narrows the set to one. Even OpenAI's court-ordered log production relied on de-identification plus an attorneys'-eyes-only protective order, not redaction alone, precisely because stripping names is not enough. The practical rule: for anything sensitive, prefer a synthetic stand-in for prompt-building and testing, and when you must use real content, ask 'could a knowledgeable insider name this person from what's left?' If yes, it is not redacted - it is exposed with the labels removed.

Audit, human checkpoint, and the compliance floor

A document-AI workflow you cannot explain afterwards is a liability waiting for an incident. The cheapest insurance is a five-field log per sensitive job: filename, date, tool + tier, data class, owner, approval status. It costs ten seconds and converts 'we used AI on it' into a defensible record for a client, auditor, or regulator. Pair it with a human checkpoint: for any legal, financial, medical, or employment judgement, AI output is a draft a qualified person owns - the EU AI Act's human-oversight expectation for higher-risk uses, applying from 2 August 2026, formalises this. Underneath sits the contract layer: GDPR Article 28 makes the AI vendor a data processor you must have a DPA with, and a HIPAA BAA is required before any protected health data touches a tool. Business/enterprise tiers from both OpenAI and Anthropic offer DPAs, BAAs, SOC 2 Type 2, and ISO certifications (Anthropic adds ISO 42001 for AI management systems); consumer tiers offer none of these. The log and the checkpoint are the floor; the contract is the wall.

Where can this document go? Tier decides the default

The same upload carries very different risk depending on the plan tier - because training defaults, retention, and legal-hold exposure differ. Verify your own account's settings; defaults change and admin policy can override them.

TierTrains on your content by default?Retention defaultCompliance you can contract forSafe for which data class
Personal ChatGPT (Free/Plus/Pro)Yes, unless you turn off 'improve the model'Retained until you delete; deleted items removable ~30 days - but can be legally heldNone (consumer terms; no DPA/BAA)Public + low-stakes Internal only
Consumer Claude (Free/Pro/Max)Yes by default since Aug 2025 unless you opt outUp to 5 years if you don't opt out; 30 days if you doNone (consumer terms)Public + low-stakes Internal only
ChatGPT Team / Enterprise / Edu + APINo - business data is not used for trainingConfigurable; 30-day default, zero-retention available via API for eligible useDPA, BAA (HIPAA), SOC 2 Type 2, ISO 27001/27701Internal + Confidential; Sensitive with controls + approval
Claude for Work / Enterprise / EducationNo - covered by commercial terms, no training toggleConfigurable per org; published in Trust CenterDPA, BAA (post-Dec 2025), SOC 2 Type 2, ISO 27001 + ISO 42001Internal + Confidential; Sensitive with controls + approval
Local / approved private environmentNo - content does not leave your controlYou control itWhatever your own environment is certified forSensitive / regulated - the local-first default

Sources (as of June 2026): OpenAI - Enterprise privacy · OpenAI - Response to NYT data demands · Anthropic - Updates to consumer terms (Aug 2025) · Anthropic - Is my data used for training? · Anthropic - Certifications

Visualisation

Document AI risk grid

Classify data before deciding whether AI can read, summarise, transform, or store it. Cells beyond Allow and Never are ask-first verdicts with the safer path already named: 'Policy only', 'No raw upload', 'Local first', and 'Review' all mean stop and apply the matching rule before proceeding.

PublicInternalConfidentialSensitive
SummariseAllowAllowAsk firstPolicy only
RewriteAllowAllowAsk firstNo raw upload
Extract dataAllowAsk firstAsk firstLocal first
Share externallyReviewReviewNever without approvalNever

Step by step

1

Classify the document and name the data class

Choose one real document type and classify it as Public, Internal, Confidential, or Sensitive. Write one line of why, and explicitly list any personal data it contains and whose it is (staff, customer, third party). You are done when your one-line classification names the class, the personal data it contains, and whose data it is - and a colleague reading only that line would reach the same class.

HintIf it contains PII, customer material, staff records, or private financial detail, treat it as Sensitive until your policy explicitly says otherwise. When unsure, classify up, not down.

2

Check the tier before you check the action

Confirm exactly which plan you'll use and what its defaults are: does it train on your input, and what is its retention? Personal ChatGPT and consumer Claude (Free/Pro/Max) default to retaining and potentially training on your content; business/enterprise tiers and the API do not. If your data class is Confidential or Sensitive and you're on a consumer tier, stop and switch tier or go local. Expected result: the exact plan name plus two written facts - does it train on input (yes/no) and what its retention is - recorded before anything is uploaded.

HintThe same upload is safe on ChatGPT Enterprise or Claude for Work and risky on a personal account. The tier is the control, not the brand.

3

Set allow / ask-first / never-use per action

Using the risk grid, decide which actions are allowed, which need approval, and which are forbidden for this document type on your chosen tier. Keep it action-based: summarise, rewrite, extract, upload, store, share externally. Where the grid says 'Local first', 'No raw upload', or 'Review', treat it as an ask-first verdict with the safer path already chosen for you.

HintWrite it so a colleague under time pressure can apply it in ten seconds. If a rule needs a paragraph to explain, it's too complicated to follow.

4

Add redaction, synthetic, and local-first rules

State when the team must redact, when to use a synthetic example instead of the real file, and when work must stay local. For redaction, list the indirect identifiers to remove - not just names, but dates, locations, rare roles, and small group sizes.

HintRedaction is not anonymisation. Ask: could a knowledgeable insider still name the person from what's left? If yes, use a synthetic example or keep it local.

5

Add the audit line and the human checkpoint

Write the one-line audit format the team will log for sensitive jobs (filename, date, tool + tier, data class, owner, approval status), and name who must review AI output before it is used for any legal, financial, medical, or employment decision.

HintFor regulated or high-harm decisions, AI output is a draft a qualified human owns - the audit line proves a human was in the loop.

Hands-on task

Write a document AI handling policy for one real document type: its data class, the tier you'll use and why, allow / ask-first / never-use rules per action, your redaction-and-synthetic rule including indirect identifiers, and a one-line audit format with a named human reviewer.

What you produce

A document AI handling policy with allow, ask-first, and never-use categories.

Production prompt examples

Production brief - classify a document and propose its handling policy
ROLE: You are a pragmatic data-protection officer helping a non-technical team use AI on business documents safely. Plain English, no legal jargon, no hedging.

CONTEXT: I am about to use an AI tool on a document. Before I do, classify it and tell me the rules. Here is what I can share about the document (I am deliberately NOT pasting the sensitive content):
- Document type: [e.g. customer support transcript / unsigned supplier contract / quarterly P&L / staff performance note]
- Does it contain personal data (names, emails, IDs, addresses, health, financial)? [yes/no + which]
- Whose data is it? [our staff / our customers / a third party / no one identifiable]
- What do I want to do? [summarise / rewrite / extract fields / draft a reply / share externally]
- The tool + tier I plan to use: [e.g. personal ChatGPT / ChatGPT Enterprise / consumer Claude / Claude for Work / local model]

TASK: Return a short handling decision.

OUTPUT FORMAT:
1. DATA CLASS: Public / Internal / Confidential / Sensitive - and one line on why.
2. VERDICT for my requested action on this tier: ALLOW / ASK-FIRST / NEVER - one line on why.
3. IF NOT 'ALLOW': the safer path (redact what specifically / use a synthetic example / move to an enterprise tier / keep it local).
4. REDACTION CHECK: list the indirect identifiers I must remove or mask (dates, locations, rare roles, small group sizes), not just names.
5. AUDIT LINE: a ready-to-paste log entry - filename, date, tool+tier, data class, owner, approval status.
6. ONE escalation question I should ask my manager/DPO before proceeding, if any.

CONSTRAINTS: Do not ask me to paste the sensitive content. If my chosen tier is a consumer plan and the data is Confidential or Sensitive, say so plainly and recommend an enterprise tier or local handling.
  • It never asks for the sensitive content itself - you classify from metadata, so the risky data never enters a chat just to ask whether it's safe.
  • Forcing the tier into the input is the key move: the verdict changes for a personal vs enterprise plan, which is the whole lesson.
  • The redaction-check step targets indirect identifiers (the mosaic effect), the part people miss after they remove names.
  • The audit line makes the workflow reviewable in one paste - filename, date, tool+tier, data class, owner, approval.
  • Paste this into ChatGPT or Claude as a reusable 'gatekeeper' before any document task; it works equally well as a saved prompt or custom instruction.

Common mistakes to avoid

  • Using a personal ChatGPT or Claude account for Confidential or Sensitive documents - consumer defaults retain and (unless you opt out) may train on what you paste.
  • Assuming 'delete' means gone - a legal hold (as in the 2025 NYT v. OpenAI case) can preserve even deleted consumer chats.
  • Treating redaction as anonymisation while leaving indirect identifiers - dates, locations, rare roles, small group sizes - that re-identify the person.
  • Letting AI output replace expert review for legal, financial, medical, or employment judgement instead of treating it as a draft.
  • Giving a connector access to a whole drive or SharePoint when one folder or one file, read-only, would be enough.
  • Writing a policy so detailed that no one can apply it under time pressure - complexity is itself a security risk.

Source conflicts to review

  • Provider training and retention defaults change frequently and differ by region and plan - treat every figure here as 'verify in your own account's settings', not a guarantee.
  • The Anthropic consumer training change had a moving deadline (reported 28 Sep then ~8 Oct 2025); use 'late 2025' and confirm your account's 'Help improve Claude' toggle directly.
  • Enterprise exclusion from the 2025 OpenAI preservation order applied to that specific case; it is not a blanket promise that enterprise data is immune to all legal process - your DPA and counsel govern.
  • Compliance certifications (SOC 2, ISO 27001/42001, HIPAA BAA availability) are point-in-time and scope-specific; request current reports from each vendor's trust centre before relying on them.

Key terms

PII
Personally identifiable information - names, emails, IDs, addresses, health, financial, or other identifying details, directly or in combination.
Data class
Public / Internal / Confidential / Sensitive - the risk label that drives the allow / ask-first / never-use decision.
Local-first
Handling sensitive work on a controlled local machine or approved private environment first, sending only redacted or synthetic versions to a cloud tool.
Synthetic example
A realistic but fake document used for learning, testing, or prompt development so real sensitive content never enters a tool.
Indirect identifier
A detail that re-identifies a person in combination with others - a date, location, rare role, or small group size (the mosaic effect).
DPA
Data Processing Agreement - the GDPR Article 28 contract that makes an AI vendor a controlled data processor; available on business/enterprise tiers, not consumer.
BAA
Business Associate Agreement - required under HIPAA before protected health data touches a tool; offered on enterprise tiers only.
Legal hold
A litigation duty to preserve data that can override a vendor's normal deletion/retention promise.
Connector
A link that gives an AI tool standing access to a data source such as a drive, inbox, or SharePoint. Scope it to one folder or one file, read-only where possible - broad connector scope is the most common quiet over-exposure.
SOC 2 / ISO 27001
Independent, audited security certifications a vendor can hold. Available to contract for on business and enterprise tiers, not consumer plans - a quick proxy for whether a tier is built for confidential work.

Resources

Checkpoint

Which document type in your workplace needs an ask-first or never-use rule, which tier should it be on, and who approves exceptions?