Practical guide
Bring unapproved AI use into a safer, usable workflow
Shadow AI is AI used for work outside an organization's approved systems or processes. Discovering it is not just a question of finding an unapproved app; it is a chance to understand the task the person was trying to complete, what data may have crossed a boundary, and why the approved route did not work. A no-blame use-case intake helps a programme owner decide whether to contain an exposure,.
Shadow AI is AI used for work outside an organization's approved systems or processes. Discovering it is not just a question of finding an unapproved app; it is a chance to understand the task the person was trying to complete, what data may have crossed a boundary, and why the approved route did not work. A no-blame use-case intake helps a programme owner decide whether to contain an exposure, provide an approved alternative, change a slow process, or decline the use case. The goal is a documented route for the work, not a claim that every unofficial tool can be made safe.
Ask what problem the unofficial tool solved
Imagine a synthetic services team whose project coordinators use a personal AI account to turn meeting notes into action lists. The official collaboration tool has no approved summarization feature in their configuration, and manual handoffs are often late. A blanket “stop using AI” message may remove the visible tool without fixing the handoff. The programme owner first asks what notes were used, whether client or employee information was included, who received the output, whether the account is personally managed, and which approved workflow could replace it. They separate an immediate data-handling concern from the longer-term need for a timely action list.
The UK National Cyber Security Centre's shadow-IT guidance, reviewed in August 2026, explicitly includes unapproved AI services and says unofficial tools often arise because sanctioned processes do not meet a real user need. It recommends a positive, no-blame approach and a practical process for requesting services. Its shadow-AI discussion emphasizes that organizations should understand why workers choose the tools and reduce risk rather than assume shadow use can be eliminated. These are UK security guidance and perspective, not evidence that a particular employer has a breach or a universal legal duty.
Sources: [1] [2]
Record a disposition for each use case
The fictional programme owner makes an intake record, not a list of people to punish. The first row says: task = internal meeting-to-action summary; input = approved non-sensitive project notes; current tool = personal account; gap = no timely approved summarization route; next step = trial the approved collaboration tool's existing features or a controlled, non-sensitive exercise; owner = project operations. The second row covers notes containing client information and takes a different path: pause further transfer, preserve the known facts, and ask the security or privacy owner to assess what was shared and what response is required. The team does not assume both cases have the same exposure merely because they used the same app.
For each use case, record data category, access permissions, account ownership, retention questions, downstream recipients, available vendor and configuration evidence, and the person who can approve a replacement. If the available evidence is incomplete, mark it unknown. Avoid asking workers to paste sensitive prompts or transcripts into another unapproved collection tool. Use existing, authorized investigation procedures. A team may decide to prohibit a use case while it builds a workable alternative; that is different from pretending the underlying need has disappeared.
This intake differs from writing an acceptable-use policy. A policy establishes the allowed boundary for everyone. The intake handles a concrete observed workaround and produces a disposition: stop and investigate, migrate to an approved route, run a limited pilot, or decline with a reason. It also sends feedback to the policy owner when the official process is too slow or missing a needed capability. A policy that cannot be followed in ordinary work is unlikely to close the gap simply by being restated.
Check whether the new route actually works
After an approved route is offered, test it on a synthetic or explicitly permitted note set. Can the coordinator create a usable action list in time? Does a named person verify owners and deadlines against the original notes? Is the data path visible to the organization? Can the team handle exceptions without returning to a personal account? Record any continuing workaround and the reason, instead of treating low incident reports as proof of zero shadow use.
The NIST AI RMF Govern playbook suggests defining roles, responsibilities and communication processes for AI risk management. It is voluntary guidance; the intake and four-way disposition here are a proposed operational method, not a NIST requirement. A programme owner should also involve the appropriate security, privacy, legal or worker representatives where the organization's context calls for them. A Two Prune assessment can use synthetic task materials to observe how a participant handles an AI-assisted work boundary, but it does not discover a customer's actual shadow-AI footprint, certify remediation, or make automated decisions about workers.
Sources: [3]
Sources
- 1.UK National Cyber Security Centre's shadow-IT guidance · www.ncsc.gov.uk
- 2.shadow-AI discussion · www.ncsc.gov.uk
- 3.NIST AI RMF Govern playbook · National Institute of Standards and Technology