Cybersecurity in the Era of AI · Part 4 — Shadow AI: Discover, Assess & Govern Unsanctioned AI Use

This is Part 4 of Cybersecurity in the Era of AI, and it confronts the gap between the AI you govern and the AI you actually have. Parts 1–3 built a governance system for the AI you know about — inventoried, classified, managed. But in almost every organization, the majority of AI use is shadow AI: employees pasting documents into consumer chatbots to summarize them, a team quietly wiring a foundation-model API into a workflow, a marketer running customer lists through an AI tool, a developer using an unapproved coding assistant. None of it appears in your inventory, none of it went through your risk classification, and none of it is in your AIMS scope — which means every governance control you built has a hole in it exactly the size of what you cannot see. Shadow AI is not a fringe concern; it is frequently the largest AI risk an organization carries, precisely because it is invisible and ungoverned. This part is about making it visible and bringing it under control — and doing so in the one way that actually works.

The central lesson, learned the hard way with every previous wave of shadow IT (unsanctioned SaaS, personal cloud storage), is that banning does not work. A blanket prohibition on AI tools does not stop the use; it stops the disclosure of the use, driving it further underground where you have even less visibility and no ability to make it safe. People use shadow AI because it helps them do their jobs, and that demand does not evaporate when you forbid it. The winning strategy is not prohibition but redirection: discover what people are doing and why, assess the real risk, and channel the demand toward sanctioned alternatives that are safe, so the easy path and the safe path are the same one. Govern the demand, do not pretend it away.

Scope of this phase

Every part of this program is scope-bounded so you know exactly when you are done.

• In scope: discovering unsanctioned AI use across its channels; assessing the risk it carries (data leakage above all, plus compliance, IP and quality risks); and governing it through sanctioned alternatives, acceptable-use policy, technical controls and a demand-channelling process — the reconciliation of discovered AI against the Part 1 inventory.
• Explicitly out of scope (later parts): the secure adoption of AI coding assistants specifically (Part 5), which is a large enough shadow-AI subcategory to warrant its own part; and securing the AI systems you sanction and build (Part 6).
• Definition of done: the exit checklist at the end of this part. When every box is ticked, you have visibility of AI use across the organization, the high-risk uses are governed, and there is a sanctioned, safe path that makes shadow AI the harder choice rather than the only one.

The approach is a three-step loop — discover, assess, govern — run continuously rather than once, because shadow AI is not a fixed population but a constantly renewing one as new tools appear weekly. Each step feeds the next, and the whole loop feeds the Part 1 inventory, closing the gap between governed and actual AI.

Step 1 — Discover

You cannot govern what you cannot see, so discovery comes first, and it works across several channels because shadow AI enters through several doors. Network and egress telemetry reveals traffic to known AI services — a secure web gateway, CASB or DNS logs will show connections to consumer AI domains and model-provider APIs, giving you a picture of which AI services are being reached and how heavily. Expense and procurement data surfaces AI subscriptions bought on cards or expensed, and SaaS-management tooling catches AI features switched on inside tools you already have. Identity and OAuth grants show where employees have connected AI apps to corporate accounts (an AI tool granted access to email or documents is both a discovery signal and a risk in itself). And direct engagement — surveys, amnesty, simply asking teams what AI they use — often reveals more than any tool, especially when people understand you are trying to enable them safely rather than punish them. A gateway policy that logs (rather than blocks) traffic to AI categories turns the network into a discovery instrument:

# Secure web gateway: observe, don't block, to build the shadow-AI picture first.
rule: discover-ai-usage
match:
  category: ["generative-ai", "ai-ml-tools"]
action: allow
log: full            # who, which service, volume — feeds the inventory
alert:
  when: "upload_bytes > threshold to unsanctioned_ai_domain"
  to: security-ai-governance

The goal of discovery is not immediate enforcement but understanding: which AI, used by whom, for what, with what data. That picture is what makes the next two steps proportionate rather than reflexive.

Step 2 — Assess

Not all shadow AI is equally dangerous, and treating a developer using an AI rubber-duck the same as a team piping customer PII into a consumer chatbot wastes trust and effort. Assessment ranks discovered use by the risk it actually carries. The dominant risk is data leakage: data entered into a consumer AI tool may be retained, used to train the provider's models, exposed to the provider's staff, or surfaced to other users — so the critical question for each discovered use is what data is going into it. Customer personal data, special-category data, source code, trade secrets and regulated data going into an unsanctioned tool is a serious exposure (and often a GDPR or contractual breach); a marketer drafting generic copy is not. Beyond leakage, assess compliance risk (does this use bypass the AI Act or ISO 42001 governance you built?), IP and licensing risk (whose data trained the tool, and who owns the output?), and quality/reliability risk (are decisions being made on unvetted AI output?). The output of assessment is a prioritized list: the high-risk uses that need governing now, and the low-risk ones you can simply fold into policy.

Step 3 — Govern

Governance is where the strategy of redirection over prohibition proves itself, and it has three moving parts working together. First and most important, provide sanctioned alternatives: the reason people use consumer AI tools is that they are useful, so offer an approved, safe equivalent — an enterprise AI assistant with a data-protection agreement (no training on your data, appropriate retention, access controls), a governed way to call model APIs, an approved coding assistant (Part 5). When the sanctioned tool is as good and obviously safe, the pull toward shadow tools drops sharply. This is the single most effective control, and it is enabling, not restricting.

Second, set clear acceptable-use policy (from Part 1) that people can actually follow: what AI tools are approved, what data may and may not be entered into which class of tool, and where to go for something new. The policy works because it is paired with a yes — here is what you can use — rather than being only a list of prohibitions. Third, apply proportionate technical controls for the genuinely high-risk cases: data-loss-prevention rules that stop sensitive data being uploaded to unsanctioned AI services, blocking reserved for tools that are both high-risk and have a sanctioned alternative (so blocking pushes people to the safe path, not off a cliff), and monitoring of the sanctioned tools so approved use stays safe. The combination — a great sanctioned option, clear policy, and DLP that catches the dangerous edge cases — channels the demand instead of fighting it. Finally, close the loop: every governed shadow-AI use that becomes sanctioned is added to the Part 1 inventory, so the population of governed AI grows to match the actual AI, which is the whole objective.

Definition of done — Shadow AI exit checklist

You are ready for Part 5 when every one of these is true:

• Discovery running: you have visibility of AI use across the main channels (network/egress, procurement/expense, OAuth grants, direct engagement), run continuously rather than once.
• Assessment done: discovered AI use is assessed and prioritized by risk — data leakage first, then compliance, IP and quality — producing a ranked list of what to govern.
• Sanctioned alternatives exist: approved, safe AI options (enterprise assistant with a no-training data agreement, governed API access, approved coding assistant) are available and genuinely useful, so the safe path is also an easy path.
• Acceptable-use policy live: a clear, followable policy states approved tools, data rules by tool class, and the route to request new tools — paired with a "yes," not only prohibitions.
• Proportionate controls: DLP prevents sensitive data reaching unsanctioned AI; blocking is reserved for high-risk tools that have a sanctioned alternative; sanctioned tools are monitored.
• Inventory reconciled: governed shadow AI is folded into the Part 1 inventory, shrinking the gap between governed and actual AI.

Tick every box and the invisible majority of your AI use becomes visible and governed, with the highest-risk data-leakage paths closed and a sanctioned option that makes safe the default. Fall back on a ban and you will have driven the same use underground, congratulated yourself on a policy, and carried the risk anyway — blind.

What's next

Part 5 — Security in AI-assisted coding zooms into the single largest and fastest-growing category of AI use in most technology organizations: developers using AI coding assistants. It is a shadow-AI problem (unapproved assistants leaking code to models), a secure-development problem (AI suggesting insecure code and hallucinating dependencies), and a productivity opportunity all at once. Part 5 shows how to adopt AI-assisted development safely — enterprise controls, pipeline guardrails, and the practices that let you keep the speed without importing the risk. It ships next month.

If you would like experienced hands to run shadow-AI discovery, assess the exposure, and stand up the sanctioned alternatives and controls that channel demand safely, that is exactly what Axelia's consultants do — and ISMShed folds the discovered and governed AI into your framework-mapped inventory across ISO/IEC 42001, the EU AI Act, ISO 27001, NIS2, DORA and GDPR. Make your shadow AI visible now, and the secure-development parts that follow have a complete picture to work from.