How to Run a Shadow AI Engagement

A shadow AI engagement runs in three phases over roughly two to four weeks: discover the unsanctioned AI tools employees are already using, assess the data exposure each one creates, then build a governance policy your team will actually follow. Here is how to structure it and where a partner earns its keep.

What Is a Shadow AI Engagement, Exactly

Shadow AI is any generative AI tool an employee adopts without IT or security sign-off. Someone pastes a client contract into ChatGPT to summarize it. A developer feeds proprietary code into an AI coding assistant with default data-retention settings. A marketing coordinator uploads a customer list to an AI writing tool. None of it is malicious. All of it is unmonitored data leaving your perimeter, often into vendors with terms of service nobody reviewed.

A shadow AI engagement is a structured project to find that usage, quantify the risk, and put controls in place before a customer, auditor, or regulator asks the question you can't answer: "which AI tools have access to our data?" For Canadian companies, that question increasingly comes from US enterprise customers running vendor security reviews, from SOC 2 auditors, and from Quebec Law 25 or PIPEDA obligations around personal information processing.

Week One: Discovery, Not Interrogation

The first mistake teams make is treating discovery like a compliance audit with a clipboard. That produces silence, because employees assume admitting to using an unsanctioned tool gets them in trouble. A better approach combines three discovery methods run in parallel:

• Network and SaaS telemetry. Pull DNS logs, proxy logs, and expense reports for known AI domains and browser extensions. This catches tools people forgot they installed.
• Anonymous employee survey. A five-minute, no-names survey asking what AI tools help with daily work almost always surfaces more than the logs do, because personal accounts and mobile apps don't show up in corporate telemetry.
• Manager interviews. Team leads know which tools their group has quietly standardized on, especially in engineering and marketing.

Expect this phase to take four to seven business days for a company in the 30 to 300 employee range. A dedicated shadow AI audit compresses this by running the telemetry pull and survey simultaneously, with a security researcher interpreting results rather than a checklist form, which is where most internal attempts stall out.

Week Two: Classifying Risk by Data Type, Not Tool Name

Once you have a list of tools, resist the urge to rank them by brand reputation. Rank them by what data touched them. A free-tier transcription tool used on internal standup notes is a low priority. The same free-tier tool used to transcribe a sales call with a prospect's financial details is a different conversation entirely, because free tiers frequently retain input data for model training by default.

Build a simple three-column risk register:

• Tool and tier (free, paid, enterprise, with or without a data processing agreement)
• Data category exposed (source code, customer PII, financial records, internal strategy)
• Retention and training posture (does the vendor use inputs to train models, and can you opt out)

This is where most in-house attempts fall apart, because reading vendor data processing terms for a dozen AI tools is genuinely tedious and easy to get wrong. It's also the phase where a security-focused partner adds the most value, since the researcher doing this work should already know which mainstream AI vendors have enterprise-grade data controls and which don't, rather than starting from zero on each one.

Week Three: Writing a Policy People Will Actually Follow

A shadow AI policy that bans everything gets ignored within a month, because employees have already found these tools make them faster. The policies that stick draw a clear line between three tiers:

• Approved: enterprise-tier tools with signed data processing agreements and no training on your inputs, available to everyone.
• Approved with restrictions: tools usable for non-sensitive work only, with explicit examples of what counts as sensitive.
• Blocked: tools with no acceptable data handling terms, blocked at the network layer where feasible, not just written down.

Pair the policy with a fast-track request process for new tools. If employees can get a tool evaluated in two business days instead of waiting on a quarterly review cycle, they'll use the process instead of routing around it. This same tiered thinking underpins broader AI governance frameworks like ISO 42001, so if your company is heading toward that certification anyway, it's worth reviewing our ISO 42001 readiness work to see how the shadow AI policy slots into a larger AI management system rather than sitting as a standalone document.

Week Four: Rollout and the First Recheck

Announce the policy with the approved tool list front and centre, not the blocked list. Employees respond better to "here's what you can use freely" than to a memo that reads as a crackdown. Give teams a short grace period to migrate off blocked tools, and schedule a follow-up discovery pass 60 to 90 days out. Shadow AI adoption moves fast. New tools show up in that window every time, and the second discovery pass is usually much faster than the first because the survey and telemetry process is already built.

Realistic Timelines and Where This Fits Your Budget

For a lean team, the full cycle from kickoff to published policy runs three to four weeks. Larger organizations with multiple business units or a distributed workforce should plan for five to six weeks, mostly because manager interviews and department-specific tool exceptions take longer to coordinate. This isn't a one-and-done project either. Budget for a lightweight recheck twice a year, since new AI tools reach general availability faster than most governance cycles can track them.

Companies already working through a SOC 2 or broader security program often fold shadow AI discovery directly into that engagement, since auditors are starting to ask about AI tool usage as part of vendor management and data handling controls. If that's your situation, it's worth looking at how this connects to our broader security program work rather than running it as an isolated exercise.

Where the Regional Context Matters

Canadian companies face a specific wrinkle US-based AI governance content usually skips: PIPEDA and, for anyone with Quebec operations or customers, Law 25 both impose obligations on how personal information is processed, including by third-party AI vendors. A shadow AI audit that ignores this ends up with a policy that's technically thorough but legally incomplete. We run these engagements for teams across Toronto, Waterloo, Ottawa, Vancouver, Calgary, and Montreal, and the Quebec-facing companies in particular need the data residency and consent questions answered explicitly, not assumed.

Getting Started

The hardest part of a shadow AI engagement isn't the technical discovery, it's getting honest answers from employees who use tools they weren't told they could use. A structured, judgment-free process gets you there faster than an internal memo ever will. If you want help scoping a shadow AI audit for your team, get in touch and we'll walk through what discovery would look like for your environment.

The AI you already bought and forgot about

Discovery aimed at unfamiliar tools misses the largest exposure in most companies, which is the AI features switched on inside software you already pay for. The chat platform added an assistant that reads channel history. The meeting tool started joining calls and producing transcripts, including the calls with candidates and the ones where legal is present. The code host enabled an assistant across the organization because someone with admin rights clicked yes during a trial.

None of these show up in a survey asking which AI tools people use, because employees do not think of them as AI tools. They show up when you list every SaaS product in the expense report and check, one by one, whether an AI capability is enabled, what it can read, and whether it is on by default for new workspaces. Do that pass first. It is faster than the telemetry work and it usually produces the finding that changes the conversation with leadership, which is that the meeting recorder has been transcribing sensitive discussions into a vendor tenant nobody reviewed.

Recording tools deserve particular attention in Canada, because consent obligations attach to the recording itself and not only to the AI processing of it. A transcript of a call with a Quebec customer sitting in a vendor system with unclear retention is a Law 25 question before it is an AI governance question.

What to ask each vendor, in the order that matters

Reading terms of service for a dozen tools is the slowest part of the engagement, so work from a fixed question list and stop when a tool fails one. Does the plan you are on exclude your inputs from model training, and is that contractual or a toggle a user can flip back. How long are prompts and outputs retained, and is zero retention available. Where does processing happen, which matters when a customer contract or privacy assessment names permitted regions. Which subprocessors sit behind the vendor, since many AI products are a thin layer over a model provider you now inherit. Is there human review of inputs for abuse monitoring. And will they sign a data processing agreement, because a vendor that will not is one you cannot place customer data into regardless of how good the product is.

Record the answers with the date you checked. AI vendor terms change more often than any other category of software you buy, and an answer from eight months ago is not evidence.

Making the policy enforceable rather than aspirational

A tiered policy holds only if the tiers are backed by something other than trust, and the controls that work are ordinary. Buy the enterprise plan for approved tools and require access through single sign-on, which gives you a user list, an off-switch and an admin who is not the person using the tool. Restrict who can enable AI features in the platforms you already own. Block the blocked tools at the network or browser layer rather than only in the document. And treat personal accounts as the real gap they are, since nobody is blocking anything on an employee's phone. The honest answer there is training plus a clear statement of what data may never leave your systems.

Two artefacts make this survive contact with an auditor or an enterprise buyer: an approved tool register naming each tool, its tier, its data processing agreement and its review date, and a record that the policy was communicated with acknowledgements. Both slot into vendor management and training controls you likely already owe under an existing framework, which argues for running the two together.

When you should not run this as a project

Under about thirty people this is not an engagement. It is one afternoon with the expense report, a short conversation in each team, and a one-page position on what may and may not be pasted into an external tool. Buying a governance programme at that size produces a document nobody reads.

Equally, if the discovery pass finds three tools and none of them touch customer data, stop there. Write the register, set a reminder for six months, and spend the budget elsewhere. The work is worth paying for when you handle regulated or customer data, when a buyer or auditor has already asked, or when discovery turns up unreviewed tools sitting in the path of that data. If you are unsure, tell us what you found and we will say whether it warrants a project.