ChatGPT, Claude, Gemini or Copilot · Practical walkthrough

Find the AI tools your team uses and agree the next steps

Someone mentions a work tool you haven't heard of. Ask what job it was solving.

Task by Task5 min read

What you'll make

a task-based list of the AI tools your team uses, with proposed next steps for the responsible owner to decide.

What you'll need

a work chat allowed to handle non-identifying internal notes, a short team conversation and an IT contact. Allow 30 minutes. This exercise does not require admin access or anyone’s private chats.

Example result.

Job	Tool type	Proposed next step
Summarise public reports	PDF extension	Check the work assistant as a replacement
Take client-call notes	Meeting recorder	Confirm the meeting platform’s approved setup

1. Ask about the job, then organise the notes

Tell the team who sees the summary and how it will be used. Promise only what you can deliver; unnamed notes may still identify someone. Report information incidents separately.

Ask “Which tool would you miss?” and “What job needed doing?” Record the tool, account type and input type without private chats or identifying detail. Use those notes in your work chat:

Organise these notes by the job people needed to finish.
For each tool keep its account type, input type, stated approval and
unanswered questions. Propose: adopt, replace, leave with a written limit,
or stop for review. Mark every decision as a proposal for the owner.
Do not combine entries whose inputs or approval states differ. Do not
identify people, infer a policy breach or suggest disciplinary action.
NOTES: [task-level notes]

Why this works: a job and an input type are more useful requirements than a list of product names.

What you should see: short task-level notes, with unknown approval states marked unknown.

2. Check that grouping has preserved the differences

Compare the inventory with the notes. Public-report reading and client-call recording may serve a similar job, but their information and approval questions differ. Keep each tool’s status and proposed decision separate.

Why this works: grouping by job reveals needs; merging unlike inputs can conceal an unresolved risk.

What you should see: one traceable entry per tool, with unknowns and proposals clearly marked.

3. Take the proposals to the responsible owner

Review every row before sending it to IT. Adopt means request a suitable work route; Replace means test the suggested alternative on the job; Leave with a written limit needs the owner’s agreement about the allowed input; Stop for review means use a safe manual route until the issue is resolved.

A subscription is not permission. Do not keep a risky tool running because a replacement is unavailable. If an alternative fails the job, record that gap instead of announcing a replacement that nobody can use.

Why this works: an AI proposal does not authorise a tool or decide what information belongs in it.

What you should see: an owner for every open question and a clear distinction between proposed and confirmed decisions.

Check the result

No individual is named or identifiable from a distinctive detail.
Different inputs and approval states remain separate.
Every proposed replacement has a practical check.
Only the owner can turn a proposal into a decision.

The usual failure: a “reading help” group combines a public-report extension and a recorder that hears client calls, then proposes the same treatment for both.

You combined [entry A] and [entry B], but their inputs or approval states
differ: [difference]. Separate them and restore each original status.
List other merges that may hide the same distinction. Add no decisions.

The three brackets identify the entries and the difference in your notes.

Worked example

Fictional example. A marketing lead records:

PDF extension: reads public industry reports; work alternative not tried.
Call recorder: hears client discussions; retention and approval unknown.
Personal chat: rewrites supplier emails; work account requested.
Image generator: internal placeholder pictures; design subscription available.

The first inventory groups the first three as “reading and writing” and recommends the work assistant for all of them. The repair restores four rows. Public-PDF reading becomes a replacement test; the recorder needs an owner to confirm access and retention; supplier-email rewriting stays an unresolved account/input question.

The lead asks IT to test the design subscription for placeholder images. No purchase, policy approval or saving has been established. The useful output is the short list of jobs and questions.

Go deeper

Ask what IT can already see

Ask what is visible now, what would require new collection and what is outside that coverage. Microsoft Defender for Cloud Apps discovery depends on configured sources such as endpoint data or network logs; its default catalogue does not cover every app. Do not start monitoring as part of this conversation exercise. Agree a proportionate method with the people responsible for privacy and security.

Review your own Google links

Open your Google Account’s linked-apps page. Select Access to your Google Account, an app, then See details. Review the access rather than assuming a familiar app name means a narrow permission. Remove access changes the connection; check with its owner before disrupting a work process. Removing a link does not establish that a developer erased earlier data.

Make the work route easier to find

Give colleagues one contact for access requests and a short page explaining the work account, suitable inputs and known limits. Ask whether the route solves the job that led them elsewhere. A working replacement and a visible owner are more useful than another list of prohibited logos.