5.1Confidentiality & sensitive data
The essentials in 30 seconds
- The rule that beats all: no sensitive data (clients, HR, non-public figures, secrets, proprietary code) in an unapproved tool.
- Classify before pasting: public / internal / confidential — each level has its authorised tools.
- If in doubt, do not paste: demanding anonymisation, tricky cross-checks — ask for the approved tool.
Running case — Amine and the rushed minutes
Amine, a project manager in Algiers, must quickly summarise client minutes for his management. He is tempted to paste the raw version (names, amounts, schedule) into a public assistant “to go faster”. He stops in time: he classifies the document (confidential), anonymises it (generic roles, fictitious orders of magnitude, relative dates) and switches to the company's approved tool. This thread continues in 5.2, 5.3, 5.4 and 5.5.
This same case runs through the lesson, the diagram, the script and the 48h challenge — and continues in 5.2, 5.3, 5.4 and 5.5.
1. The rule that beats all
Level 5 starts with the rule that beats all: never entrust sensitive data to an unapproved tool. Client data, HR information, non-public figures, trade secrets, proprietary code — nothing leaves the approved scope. Amine files his raw minutes in that box: confidential, so approved tool or nothing.
Famous leaks (confidential code pasted into public chatbots) all started with “just an extract, to go faster”. Banning without an alternative pushes towards shadow AI: the answer is an approved tool + a charter (5.5).
2. Classify, anonymise, doubt
Classify information (public / internal / confidential), master real anonymisation (and its limits), know where data goes depending on the tool: public offer (variable framework depending on settings) or business offer (contractual framework). Amine replaces names, amounts and exact dates with fictitious ones — then re-reads, asking himself who would guess what.
And adopt the doubting reflex: if in doubt, do not paste. Pseudonymisation (Client A…) stays weak: the structure alone is sometimes enough to identify. Cross-checking (position + city + project) re-identifies more often than people think.
🔎 Concrete example — Re-identification
Anonymisation is demanding: Amine's case.
“Project manager, Algiers, delivery planned in March”
-> how many people match in your sector?
A position + a city + a project are sometimes enough to identify: that is re-identification.
Amine rephrases: “a manager, a large city, a near deadline” — then prefers the approved tool.Outcome: cross-checking identifies where each single element seemed harmless.
Lesson: if in doubt about anonymisation, approved tool.
Section vocabulary
- Classification
- The upfront sorting: public, internal, confidential — each level has its authorised tools.
Simple example: Amine classifies his client minutes as confidential.
What it is not: pasting first, wondering afterwards whether it was sensitive.
Reflex: did I classify the document before opening the assistant?
- Anonymisation
- Replacing every identifying element with fictitious ones, cross-checks tested.
Simple example: Amine uses generic roles and fictitious amounts.
What it is not: changing one name and keeping position, city and exact dates.
Reflex: would a colleague guess who this is about?
- Pseudonymisation
- Replacing names with codes: weaker than anonymisation.
Simple example: “Client A” whose unique project betrays the identity.
What it is not: believing “Client A” makes any sharing authorised.
Reflex: is the structure alone enough to identify?
- Data journey
- Where data really goes depending on the tool and its framework.
Simple example: Amine checks the approved-tools list instead of assuming.
What it is not: assuming every tool treats data the same way.
Reflex: is this tool approved for this data level?
- Shadow AI
- Clandestine use of unapproved tools, born of bans without an alternative.
Simple example: Amine asks for the approved tool instead of bypassing on the sly.
What it is not: banning without suggesting a workable alternative.
Reflex: does the team have a workable approved tool?
In practice — The anonymisation workshop
- Take a real professional email (yours) and classify it: public, internal or confidential?
- Anonymise it by hand: names → generic roles, amounts → fictitious orders of magnitude, dates → relative. Re-read: would a colleague guess who/what it is about?
- Test the limit: “Project manager, Algiers, delivery in March” — how many people match in your sector? That is re-identification.
- Write your 3 personal rules (e.g. “never a client name outside an approved tool”): they will join the 5.5 charter.
Ready-to-say script — asking for the approved tool
“I need to summarise a confidential document with AI: which is the approved tool for this data level? Meanwhile I will paste into it no names, no amounts, no exact dates. If no tool is approved, I will work locally and escalate the need.”
To say to the manager or the IT/DPO contact before any pasting of sensitive data.
Copy-paste template — my 3 data rules
MY 3 DATA RULES (will join the 5.5 charter)
1) I classify before pasting: public / internal / confidential -> tool: _______________
2) Never outside an approved tool: _______________ (e.g. client names, HR data, non-public figures)
3) Tested anonymisation: cross-checks verified (position + place + project): YES / NO
DOUBT -> I do not paste, I ask: _______________Solo / freelancer
Amine on a solo assignment: a public assistant for the generic, an approved framework for anything touching clients and figures — strict separation.
Small business / tight budget
Without a business offer: work locally on the sensitive, public AI only on public or truly anonymised content.
SME in Algeria
Amine in Algiers: client and HR documents never outside the approved circuit; question to the DPO/lawyer if in doubt about personal data.
Team starting out
Everyone brings 1 classified document and 1 tested anonymisation: the shared grid (3 rules) becomes the data annex of the charter.
✓ Best practices
- Classify information before pasting it (public/internal/confidential).
- Check that no cross-check re-identifies after anonymisation.
- If in doubt, do not paste: ask for the approved tool.
✗ Common pitfalls
- “Just an extract, to go faster” (the origin of famous leaks).
- Confusing (weak) pseudonymisation with real anonymisation.
- Believing disabling training is enough for company data.
Key takeaways
- Classify before pasting: public / internal / confidential determine the authorised tool.
- Real anonymisation is demanding: cross-checking re-identifies more often than people think.
- Public-tool settings: necessary but not sufficient for company data.
- If in doubt, do not paste — and ask for the approved-tools list.
48h challenge — apply tomorrow
Classify 3 real documents (public / internal / confidential), anonymise 1 by hand and write your 3 personal rules: tested against re-identification?
- I can cite the rule that beats all in one sentence.
- I classified 3 documents and anonymised 1 text (cross-checks tested).
- My 3 personal rules are written (ready for the charter).
Frequently asked questions
What does the company concretely risk if I paste an internal document into a public chatbot?
Loss of control over information (storage outside a contractual framework), possible breach of personal-data rules, breach of client confidentiality agreements — and for you, professional misconduct under the charter. The time saved weighs nothing against that.
Are deleted conversations really deleted?
Deletion removes user access; retention policies vary (backups, conservation obligations). The precautionary principle stands: what must not exist elsewhere is pasted nowhere.
What is the rule that beats all others at level 5?