Shadow AI

Shadow AI arises because the barrier to adopting an AI tool is unusually low: a browser extension, a personal account on a consumer AI product, or an AI feature quietly enabled inside a SaaS tool the organisation already licenses. None of these require the procurement process that would normally trigger a vendor security assessment.

Three common sources. Employee-adopted tools: an individual or team starts using a consumer AI product (chat assistant, coding tool, meeting summariser) without going through procurement. Vendor-enabled features: a SaaS product the organisation already uses ships a new AI feature, on by default, that was never in scope when the vendor was originally assessed. Embedded AI in existing tools: a productivity or collaboration platform adds AI-powered functionality that processes the same data the platform already holds, without a corresponding update to the vendor's risk profile.

The risk is not that employees are using AI — it's that data is flowing to a system, and often to a training pipeline, that has never been assessed against the organisation's data handling requirements. A support agent pasting a customer record into a consumer AI chat tool to help draft a response has moved regulated data outside every control the organisation put in place for that data.

Discovery is the first control. Network and SaaS-access-log review, browser extension inventories, and a standing intake channel for 'what AI tools are you using' surface adoption that procurement never saw. Discovery without a fast, low-friction assessment path pushes adoption back into the shadows — the goal is a path to sanctioned use, not a ban that guarantees continued unsanctioned use.

Shadow AI closes through the same instrument as any other unassessed vendor: a vendor AI assessment, triggered the moment a shadow tool is discovered, that documents what data the tool touches and what controls apply going forward — sanctioning it, restricting it, or requiring it to stop.