Shadow AI Response & Safe Adoption

Purpose

Maps the AI tool usage employees are already doing without official approval ("Shadow AI"), understands what genuine need it's solving, and builds a safe, scalable, clearly ROI-justified official alternative for it — instead of, or alongside, banning it.

Anchored in research

• A research report supplied by the user, "AI Business Designer in the Age of AI" (2026) — the Shadow AI concept, surfaced as part of a rapid AI business-case-building method.
• General "Shadow IT" literature and practice, extended to the context of AI tools.

Method

1. Map the extent of Shadow AI: what AI tools employees are already using without official approval or visibility (surveys, usage data, IT logs if available).
2. Break down the use cases by reason: what genuine need does the unofficial use solve — speed, a missing official tool, working around bureaucracy?
3. Assess the risk in every use case found: security, data protection (GDPR), IP leakage, spread of incorrect information, regulatory risk (see ../responsible-ai-and-governance-check/SKILL.md).
4. Don't start from a "ban everything" assumption — assess in each case: is the fastest safe route to ban, to provide guidance, or to build an official alternative?
5. Prioritize the use cases where unofficial use is widespread and valuable: build the official, safe, and scalable alternative for these first.
6. Calculate a clear ROI for every official alternative (time/cost saved vs. rollout and maintenance cost) — the same discipline as any other AI investment (see ../../../business-case-and-analysis/skills/business-case-builder/SKILL.md).
7. Communicate the change to employees openly: why the official tool is the better option, not just a ban (see ../../../change-and-communication/skills/stakeholder-communication-plan/SKILL.md).
8. Build a lightweight, ongoing monitoring process that identifies new Shadow AI use cases over time — this isn't a one-off project.

What this skill does NOT do

• Isn't a security audit and doesn't replace an IT/security team's technical assessment — it structures the business response.
• Doesn't assume all unofficial use is harmful — in many cases it reveals a genuine, already-validated need worth harnessing, not just suppressing.
• Doesn't make the final tool or policy decision for you.

Refinement notes

Areas to keep deepening with real practice:

• your own rules of thumb for when Shadow AI should be formalized vs. when it should be shut down
• concrete templates (into ../../references/, e.g. a Shadow AI mapping survey)
• reference cases / your own examples of successfully formalizing Shadow AI
• what this skill deliberately does not do (guardrails, common mistakes) — add to the list above

Once this section is filled in and validated in practice, update the maturity field in skills_index.json to draft, validated, or canonical (see ../../../meta/maturity_levels.md). Don't add new fields to the frontmatter — name and description are the only ones allowed (see ../../../meta/frontmatter_schema.md).

Continue from here

• In this pack: ../responsible-ai-and-governance-check/SKILL.md, ../ai-capability-roadmap/SKILL.md (official alternatives folded into the roadmap).
• Related skill in another pack: ../../../change-and-communication/skills/stakeholder-communication-plan/SKILL.md, ../../../specialisation-packs/ai-native-startup-design/skills/ai-native-tool-stack-selection/SKILL.md (choosing what the official alternative should be).
• A ready-made skill chain for this situation: see ../../../playbooks/
• This pack's shared guardrails: ../../CLAUDE.md

References

• ../../references/ — the pack's shared background material
• ../../CLAUDE.md — the pack's shared guardrails