4.5Choosing the right tool for the task
The essentials in 30 seconds
- Question no. 1, always: is there company data? It beats the tool's performance.
- Approved tool = IT list: if in doubt, ask IT, do not assume.
- Recurring = custom, one-off = generalist: and grey cases are documented for the charter.
Running case — Amine draws his decision tree
With his four sections behind him, Amine sorts things out: site report and budget in the company-approved tool; public technical monitoring in his favourite assistant; answers to recurring questions via his custom assistant. Then come the grey cases: an “anonymised” internal procedure to reformulate, a press article to summarise, a table without names. He decides each one by one — if in doubt about anonymisation, approved tool — and notes his decisions: this is the material for the future team charter. Last episode of the thread: Amine now knows how to choose before using.
Last episode of cases 4.1-4.4 — Amine closes the level: choose before using.
1. Two questions
The grid comes down to two questions. 1) Does the task involve company data? — anything not public (internal figures, clients, projects, organisation) — then a company-approved tool is mandatory. 2) Otherwise, which tool is most effective? — the one built into your flow: Copilot in Office for office work, general assistant for the rest.
Data sensitivity always beats tool performance: the “best” model never compensates for a forbidden scope.
2. Decision tree and grey cases
Build your personal decision tree: data sensitivity (internal / public) × task (one-off / recurring). Internal data → your approved tool; public and generic → your favourite assistant; recurring task → custom assistant (4.4).
Then handle the grey cases: “anonymised” extract, already-public information, draft with no reference. Real anonymisation (no re-identification by cross-checking) is harder than it looks — a position, a city and a project are sometimes enough to identify someone. If in doubt: approved tool. And each documented decision feeds the level 5 team charter.
3. Without an approved tool: do not drift
If your company has approved no tool, use public assistants only on public or generic content — and escalate the need: the absence of an approved tool pushes towards shadow AI (clandestine use), the worst scenario for the company.
The list of approved tools is a matter for IT and the DPO, not intuition: if in doubt, Amine asks instead of assuming. It is an argument for getting a framework, not a fatality.
🔎 Concrete example — 🔎 Worked example — Amine's grey cases
Where real team debates happen:
“Summarise a press article” (public) → favourite assistant
“Reformulate an anonymised internal procedure” → grey case: real anonymisation? otherwise approved tool
“Analyse the lot B budget” (internal) → approved tool, never elsewhere
→ each decision noted: material for the team charter (level 5)Outcome: three cases, three tree branches — decided before use, not after.
Lesson: documenting grey cases is already writing the charter.
Section vocabulary
- Company data
- Anything not public: internal figures, clients, projects, organisation — the no. 1 tool-choice criterion.
Simple example: Amine's lot B budget is company data, even with no proper names.
What it is not: a press article or public documentation.
Reflex: ask question no. 1 before each task: anything non-public?
- Approved tool
- The tool covered by a company contract: the list is a matter for IT and the DPO, not intuition.
Simple example: Amine asks IT which tools are authorised for the site data.
What it is not: the fashionable assistant assumed safe because it is well known.
Reflex: if in doubt about a tool: ask before pasting non-public content into it.
- Grey case
- Debated situations: anonymised extract, already-public information, structure without data — to be settled by the charter.
Simple example: Amine's “anonymised” procedure stays a grey case while cross-checking identifies the site.
What it is not: an obvious case (internal budget, public article) already settled by the tree.
Reflex: note each grey case and the decision kept.
- Decision tree
- Your personal flowchart: data sensitivity → authorised tool → task → method.
Simple example: Amine's tree fits on one page: internal → approved, public → favourite, recurring → custom.
What it is not: a list of favourite tools with no data criterion.
Reflex: redraw the tree at each change of approved tools.
- Shadow AI
- Clandestine use of unapproved tools, towards which the absence of an approved alternative pushes.
Simple example: With no approved tool, one of Amine's colleagues pastes site data on the sly: to escalate, not to imitate.
What it is not: authorised, traced use within the approved scope.
Reflex: flag the need for an approved tool rather than bypassing.
In practice — In practice — Your decision tree on one page
- List your 8 to 10 real AI tasks of recent weeks (writing, summarising, analysing, monitoring…).
- For each, answer: company data involved? (yes / no / anonymisable) — approved tool available? — frequency?
- Draw the tree: internal data → [your approved tool]; public and generic → [your favourite assistant]; recurring → custom assistant (4.4).
- Confront 3 grey cases with your tree and note your decisions — material for the level 5 charter.
Ready-to-say script — asking for the approved-tools list (30 s)
“Hello, this is Amine, project manager: to pick the right tool for my tasks, can you confirm the list of AI tools approved for our team data, and the steps for borderline cases such as anonymised documents? I want to stay within the authorised scope.”
To address to IT; keep the written answer with your decision tree.
Copy-paste template — decision tree on one page
QUESTION NO. 1: company data (non-public)? YES → [APPROVED TOOL] / NO → question no. 2.
QUESTION NO. 2: most effective tool? → [BUILT-IN COPILOT / FAVOURITE ASSISTANT].
RECURRENCE: recurring task? → [CUSTOM ASSISTANT 4.4].
GREY CASES NO. 1-3: situation → decision → approved by [NAME, DATE].
NO APPROVED TOOL: public/generic only + need escalated to [IT].Small team without an approved tool
Public assistant only on public and generic content, need escalated in writing: the figured argument (time lost, risks) moves lines.
Already-public document
Check it is truly public (official source) before the “favourite assistant” branch: “already seen somewhere” is not enough.
“Anonymised” extract
Test re-identification by cross-checking (role, place, dates): if still possible, stay on the approved tool.
Team standard
Share individual trees in a meeting, converge towards a common tree: it is the first chapter of the level 5 charter.
✓ Best practices
- Always ask question no. 1: company data?
- Ask for the approved-tools list, do not assume.
- Document your grey cases to feed the charter.
✗ Common pitfalls
- Choosing the tool on performance before sensitivity.
- Assuming a tool is approved without checking.
- Letting the absence of an approved tool push towards shadow AI.
Key takeaways
- Question no. 1, always: is there company data? It beats performance.
- The approved-tools list is a matter for IT and the DPO — if in doubt, ask.
- Recurring task = custom assistant; one-off task = well-prompted general assistant.
- Document your grey cases: they will make the team charter's value.
48h challenge — apply tomorrow
Draw your one-page tree (10 classified tasks), settle 3 grey cases in writing, and ask your IT for the approved-tools list.
- I can explain the tree in two questions.
- I can handle a grey case without improvising.
- I have my one-page tree and the approved-tools list.
Frequently asked questions
Does “anonymising” suffice to make data usable anywhere?
Only if anonymisation is real (no re-identification by cross-checking) — harder than it looks. If in doubt: approved tool.
My company has approved no tool: what should I do?
Use public assistants only on public or generic content, and escalate the need: the absence of an approved tool pushes towards shadow AI, the worst scenario.
What is the no. 1 tool-choice question?