Shadow AI: Find It in a Week, Then Build the On-Ramp

Shadow AI is not a policy violation. It is a demand signal.

Shadow AI is any AI tool being used against company data without IT's knowledge. A merchandising analyst pasting a sales extract into a consumer chat account. A finance manager on a $29 seat of an analytics tool bought with a corporate card. A store systems lead running a scripted agent against the POS replica.

The instinct is to write a policy and block domains. That works for about six weeks and drives the activity somewhere less visible.

The more useful reading: every instance of shadow AI is a person who needed an answer badly enough to route around you. The list of shadow tools in your environment is a ranked list of unmet demand, and it is more accurate than any internal survey you will run.

What it looks like in a retail organization

Four patterns, roughly in order of frequency.

The extract-and-paste. Someone pulls a CSV from the BI tool and pastes it into a consumer AI account to get a summary or a chart. The data leaves your boundary. Nobody logs it.

The corporate card SaaS. A department buys a seat-based AI analytics tool for $200 a month. It connects to a warehouse with a read-only credential that a helpful engineer created in a Slack thread. No vendor review, no DPA, no expiry.

The embedded feature. Your existing vendors ship AI features and turn them on by default. Your POS vendor, your labor system, and your e-commerce platform each added one last year. Each processes your data through a model provider you have not reviewed.

The homegrown script. A technical analyst writes an agent that queries the warehouse on a schedule. It works. It runs on their laptop. It holds a static key. Nobody else knows it exists until they leave.

The fourth is the smallest by count and the largest by risk, because it holds real credentials and has no owner after the person moves on.

How to find it in a week

Five sources, all of which you already have.

• Expense data. Search card and AP transactions for the 30 largest AI vendors. This finds the SaaS pattern immediately and takes an hour.
• Network and DNS logs. Traffic to consumer AI domains from corporate devices, aggregated by department, not by person. You want the pattern, not a disciplinary case.
• Warehouse query logs. Service accounts issuing query patterns that do not match any known integration. This is where you find the homegrown agents.
• SSO and OAuth grants. Third-party applications employees have authorized against your identity provider. People forget these exist.
• Ask your vendors. A direct question to your top ten software vendors about which AI features are enabled on your tenant and which model providers they use. Half of them have turned something on.

A retailer running this exercise for the first time typically finds 8 to 20 instances. Two or three will be genuinely concerning. The rest are people doing their jobs with the tools available.

Which risks are real and which are theater

Not everything on the list deserves the same response, and treating them equally is how the program loses credibility.

Actually serious: customer PII or employee data leaving the boundary, credentials with no owner, write access to a system of record, and anything that would be discoverable in litigation but is not retained anywhere you control.

Moderate: aggregated sales data in a consumer tool. It is a contract and confidentiality issue, not usually a regulatory one, and it is worth fixing without being worth a fire drill.

Mostly theater: an employee using a chat model to draft an email or rewrite a job posting. Blocking this consumes the political capital you need for the first two categories.

Spend the enforcement budget on credentials and PII. Give everything else a sanctioned path.

The response that works: build the on-ramp first

Blocking without a substitute produces two outcomes, and both are worse than the shadow tool. The work stops, or it moves to a personal device where you cannot see it at all.

The sequence that holds: inventory first, then triage by real risk, then stand up a sanctioned path for the top two use cases you found, then enforce on the remainder. Enforcement is credible only after the on-ramp exists.

The sanctioned path does not have to be sophisticated. An approved model provider with a signed agreement, a scoped read-only warehouse credential, and a documented request process covers most of what people were routing around you to get. Time to first access matters more than feature depth. If your process takes six weeks, shadow AI comes back and it comes back quieter.

Run an amnesty, once

Announce a 30-day window where anyone can register an AI tool or script with no consequence. Publish the criteria for what gets sanctioned and what gets migrated. Then run the registry going forward and treat post-amnesty discoveries as a normal policy matter.

This surfaces the homegrown scripts, which are the ones you cannot find reliably any other way. Most of them are built by your better analysts, and several will be worth adopting properly. That is a recruiting and retention outcome as much as a security one.

What stops it coming back

Three habits. A standing agent registry, so new agents have somewhere to be recorded. A vendor AI clause in your standard terms, so embedded features cannot be enabled on your tenant without notice. And a quarterly re-run of the expense and query log sweep, which takes an afternoon once the queries are written.

The measure of success is not zero shadow AI. It is that the demand shows up in your registry instead of on someone's corporate card.

Where Ward fits

Ward is the sanctioned path for the use case that generates most shadow AI in retail: someone needs a number from the warehouse and cannot get it in time. Read-only, one scoped identity, full query log, your own model keys if you want the inference on your provider contract.

The analyst gets the answer in an hour. IT keeps the credential, the log, and the vendor relationship. Nobody has to paste anything into a browser tab.