How to Discover and Govern Shadow AI: The QL Security Methodology

Shadow AI discovery starts with authority mapping, not tool detection. The question that matters is not which AI tools your staff use, but what decisions those tools now influence and who signed off on them. At QL Security we run shadow AI discovery as a governed process across four stages, and the first stage never touches a network scanner.

Most teams reach for the wrong instrument. They ask IT to pull a list of SaaS logins or browser extensions, assume that list is the exposure and move on. It is not. A staff member pasting client data into a free chatbot leaves no procurement trail and no login your tooling recognises. This article sets out how we actually find and govern shadow AI in mid-sized UK organisations, with the steps we run and the traps we watch for. The methodology below is indicative; every engagement is scoped to the individual client’s circumstances.

What is shadow AI discovery?

Shadow AI discovery is the practice of finding, assessing and governing the AI tools your people use without formal approval. It covers unsanctioned chatbots, AI features quietly switched on inside approved software and embedded models in third-party services. The goal is a defensible record of where AI touches your work and what risk that carries, rather than a ban list. The Shadow AI Discovery pillar covers the wider discipline; this article is the working method.

We separate three categories because each needs a different detection method. Direct tools are the ones staff choose deliberately, such as a consumer chatbot. Embedded features are AI capabilities added to software you already licence, often enabled by default after a vendor update. Third-party AI sits inside services you buy, where a supplier processes your data through a model you never see. A discovery exercise that only catches the first category misses most of the exposure.

The QL Security four-stage method

We run shadow AI discovery in four stages: authority mapping, evidence gathering, risk assessment and governance handover. The sequence matters. Starting with technical scanning produces a tool inventory that tells you nothing about consequence.

Stage one: authority mapping

We begin by mapping decisions, not devices. In an illustrative professional services scenario we would list every function where a wrong output would cause harm: client advice, financial reporting, recruitment shortlisting and contract drafting. Then we ask which of those functions could plausibly be touched by AI. That map tells us where to look hardest.

This stage is a series of structured interviews with function leads. We ask what tools they use, what tools their teams use and what they suspect but cannot prove. People disclose far more in a conversation framed around helping them work safely than in a compliance audit. The output is a heat map of likely exposure ranked by consequence.

Stage two: evidence gathering

With the map in hand we gather evidence across four channels. First, procurement and expense records, which surface paid subscriptions billed to individual cards. Second, network and SaaS telemetry, which catches sanctioned platforms with AI features enabled. Third, an anonymous staff survey, which consistently surfaces tools no log ever shows. Fourth, a review of vendor contracts to find embedded AI clauses.

The survey earns its place every time. It is common for network logs to show a handful of AI platforms while an anonymous survey returns several times that number, including tools such as transcription apps fed sensitive recordings from personal phones. No scan would find those because the data never crosses the corporate network. Evidence gathering that relies only on the network is evidence gathering with the lights off.

Stage three: risk assessment

We assess each discovered tool against three questions: what data does it touch, what decision does it influence and what would failure cost. A tool that summarises public meeting minutes scores low. A tool that shortlists job applicants or drafts clinical correspondence scores high regardless of how few people use it. Prevalence is a distraction; consequence is the measure.

This is where the authority map from stage one pays off. We already know which functions carry the heaviest consequence, so a high-risk tool found in a high-consequence function moves straight to the top of the remediation queue. The output is a prioritised register that a board can read in ten minutes, and it feeds directly into a gap analysis.

Stage four: governance handover

Discovery without governance is a report that ages badly. We hand over a live register, a set of approval routes so staff can request tools legitimately and a monitoring cadence so the picture stays current. Shadow AI regrows the moment attention drifts, so the handover includes who owns the register and how often it is reviewed.

This stage connects the exercise to an ongoing programme. A one-off discovery gives you a snapshot; a governed programme gives you control. We build the handover so it feeds directly into an AI security programme rather than sitting in a shared drive.

Why detection alone is not governance

Finding shadow AI is the easy half. Governing it means deciding, per tool, whether to approve, restrict or replace it and then making that decision stick. A discovery that ends at a list leaves the organisation exactly where it started, now with documented knowledge of a risk it has not addressed. In our operational experience that can be a weaker position than ignorance, though organisations should take independent legal advice on their specific obligations.

Governance turns the discovery register into policy. It defines who can approve AI use, what data classifications are permitted in which tools and how new tools enter the estate. Without that, the next quarter’s shadow AI discovery finds the same problems plus the ones that grew in between. We treat governance as the point of the exercise, and detection as the way in.

Common concerns from CISOs and IT directors

How is this different from a standard SaaS audit?

A SaaS audit finds software with a login and a licence. Shadow AI discovery finds AI use that leaves no such trail: free chatbots, AI features toggled on inside approved tools and models embedded in supplier services. We add anonymous staff disclosure and vendor contract review precisely because the tools that carry the most risk rarely appear in procurement records.

What if we ban AI tools outright instead?

Bans push usage further underground, where you can neither see nor govern it. Staff who find AI genuinely useful will route around a blanket ban using personal devices, which strips away every log you rely on. A governed approval route gives people a legitimate path and gives you visibility, which is the outcome a ban actively prevents.

How does discovery connect to our wider gap analysis?

Shadow AI discovery is one input to a broader assessment of your AI security posture. The prioritised register feeds directly into a gap analysis, where discovered tools are measured against the controls you should have in place. Treating discovery as a standalone task misses the point; it earns its value as evidence for the wider AI security programme.

Where to start

If you suspect shadow AI in your organisation, the first move is the authority map and you can begin that internally before engaging anyone. List the functions where a wrong AI output would cause real harm, then ask honestly whether you know what tools touch them. If the answer is no, that gap is your starting point. To run a full discovery and governance handover with us, explore our shadow AI discovery service and book a discovery conversation.

Written by John Airey, co-founder of QL Security and BSI-certified ISO 42001 Lead Auditor, who works with mid-sized UK organisations in regulated sectors on AI security discovery and governance programmes.