Shadow AI Discovery Needs A Control Layer For UK Firms

Tools & Technical Tutorials

7 August 2026 | By Ashley Marshall

Shadow AI is no longer a fringe behaviour. It is what happens when employees find useful tools faster than the organisation can approve them.

Shadow AI is best understood as ordinary staff solving ordinary work problems with tools the business has not assessed. Someone pastes a customer email into a public chatbot to make the wording clearer. A manager uploads a spreadsheet to a free analysis assistant. A salesperson asks a consumer AI tool to summarise a confidential proposal. None of those actions may be malicious. The risk is that the organisation cannot see the data, the supplier, the retention terms, the output quality, or the pattern of use.

The NCSC shadow IT guidance makes the useful point that shadow IT is rarely driven by bad intent. It usually appears because staff are trying to get the job done and approved tools or processes are too slow, too limited, or too hard to access. That applies even more strongly to AI because the productivity gain is immediate. If an employee can cut a two-hour drafting task to twenty minutes, a policy document saying not to use unapproved tools will not be enough.

For UK leaders, the practical issue is not whether AI is being used. It almost certainly is. The Office for National Statistics reported that AI use among UK businesses with 10 or more employees rose from around 12% in late 2023 to around 35% by June 2026, with 58% adoption in information and communication firms. At the same time, DSIT research warned that its own survey method would not capture shadow AI adoption. In other words, official usage figures may understate the amount of AI already touching business work.

This matters because shadow AI sits outside the controls firms normally rely on. There is no access review. There is no DPIA trail. There is no supplier record. There is no way to confirm whether customer data, contracts, code, board papers or employee records have been processed by a tool that should never have seen them. The first control layer should therefore be visibility, not punishment. Treat every discovery as evidence of unmet demand and every workaround as a clue about where the approved operating model is failing.

The weakest way to handle shadow AI is to ask IT for a list of banned websites and call that a discovery exercise. It misses browser extensions, mobile apps, personal accounts, meeting assistants, copywriting tools, spreadsheet add-ons, CRM plug-ins and AI functions embedded into normal SaaS platforms. It also frames the conversation around prohibition, which encourages people to hide usage. A stronger approach starts with the work: what tasks are employees trying to speed up, simplify, summarise, translate, classify or automate?

Begin with high-value knowledge workflows. Look at sales proposals, customer service replies, HR correspondence, legal review, finance commentary, marketing drafts, management reports and board packs. Ask teams where they already use AI, where they would use it if approved tools were available, and where current tools slow them down. Make the questions practical and no-blame. The aim is to identify repeatable demand, sensitive data exposure and avoidable friction.

Then use technical signals to support the human discovery. Browser and DNS logs can highlight repeated access to public AI services. SaaS admin consoles can show connected apps, OAuth grants and unsanctioned plug-ins. Endpoint management can identify browser extensions and local AI clients. Finance data can reveal reimbursements for AI subscriptions. Procurement records can show small SaaS purchases that never went through a proper review. None of these signals is complete on its own, but together they build a useful map.

The NCSC guidance says security teams should focus on finding where shadow IT exists and, where possible, bringing it above board by addressing the underlying user needs. That should become the principle for AI discovery. Do not simply ask, 'Who has used ChatGPT?' Ask, 'Which tasks are employees trying to improve, what data do those tasks involve, and which controls would let them do the work safely?'

Once shadow AI usage has been found, the next step is a control register. This does not need to be a heavy governance system on day one. It does need to record enough detail for leaders to make decisions. For each discovered or approved AI use case, capture the business owner, task, tool, supplier, data types, user group, output destination, approval status, review date and risk rating. Add whether personal data, special category data, customer confidential information, source code, contracts or regulated records are involved.

The register should separate three things that are often mixed together. First, the use case: for example, summarising customer complaints. Second, the tool: for example, Microsoft Copilot, ChatGPT Enterprise, Gemini, Claude, a CRM assistant, or a sector-specific vendor. Third, the control pattern: for example, approved for public information only, approved for internal documents, approved for personal data with restrictions, or not approved for sensitive data. This separation matters because a tool can be safe for one task and unsuitable for another.

What this means in practice is that a business can move faster without pretending every AI interaction needs a board paper. Low-risk drafting on public marketing copy might only need an approved tool, training and human review. A customer service assistant touching identifiable complaint records needs data protection assessment, access control, retention settings, output QA and escalation routes. A finance assistant using management accounts needs stronger logging and tighter role-based access. The register gives the business a shared language for those distinctions.

This also prevents the common counterargument: 'If we document everything, adoption will slow down.' In reality, undocumented adoption already slows the organisation because every question becomes a one-off argument. A simple register speeds decisions by showing which patterns are already approved, which are being assessed, and which are off limits. It turns AI control from a vague policy into an operating tool.

Shadow AI grows when the sanctioned route is slower than the unofficial route. That is why blocking access without offering a workable alternative usually fails. The SAP UK research published in February 2026 reported that 68% of organisations said staff use unapproved AI tools at least occasionally, while 60% said employees had not completed comprehensive AI training. Those two figures belong together. Staff are moving ahead, but many organisations have not given them the tools, skills or confidence to do it safely.

A control layer therefore needs approved routes for common tasks. For writing and summarisation, that might mean an enterprise AI assistant with retention controls, admin oversight and acceptable-use guidance. For document analysis, it might mean a private retrieval system connected only to approved knowledge sources. For customer-facing responses, it might mean AI drafts inside the CRM, with mandatory human approval before sending. For spreadsheet analysis, it might mean a sanctioned analytics tool rather than ad hoc uploads into consumer services.

Training should be role-specific rather than generic. A sales team needs to know which proposal details can be used in an assistant and which must stay out. HR needs guidance on employee data, recruitment decisions and bias risk. Finance needs rules for management accounts, forecasting assumptions and audit evidence. Developers need controls for source code, credentials and third-party libraries. A one-hour all-staff webinar will not cover those differences.

What this means in practice is simple: give people a safe path that respects the work they are trying to do. If a policy only says 'do not upload confidential data', staff will still have to decide what counts as confidential at speed. If the approved workflow includes examples, templates, tool links, escalation contacts and clear data categories, safe behaviour becomes easier. That is the real test of an AI control layer. It should make the right behaviour obvious, not merely punish the wrong behaviour later.

Shadow AI is difficult because leaders cannot answer basic questions after the fact. What data was entered? Which tool processed it? Was the output used in a customer decision? Did anyone review it? Was an external supplier involved? Could the same error happen again? Without logs, the organisation is left with interviews, memory and guesswork. That is not enough for a business process that affects customers, employees or regulated records.

The control layer should define minimum logging expectations for approved AI use. At a basic level, record user identity, tool, date, task category, data classification, source system, output destination and human reviewer where applicable. More sensitive use cases may also need prompt and output retention, retrieval source citations, model version, automated decision flags, exception records and incident links. Not every task needs the same level of detail, but the organisation should decide that deliberately.

This connects directly with existing UK obligations. Under UK GDPR, firms need to understand how personal data is processed, keep appropriate records, apply data minimisation and manage automated decision risk where relevant. The DSIT AI Adoption Research found that AI adopters most commonly use natural language processing and text generation, with 85% of adopters using AI for those purposes. Those are exactly the workflows where personal data can be copied into prompts almost casually unless the business has clear controls.

The mistake is to treat logging as a surveillance project. The better framing is operational evidence. Logs help security investigate incidents, data protection teams answer questions, managers coach staff, and boards understand whether AI is being used within agreed limits. They also help adoption because employees can use approved tools with confidence. A firm that can explain what happened is in a stronger position than one that merely hopes its policy was followed.

The tempting board response to shadow AI is to ask for a ban. That may feel decisive, but it is usually the wrong metric. A declared ban can reduce visible usage while pushing the real work into personal devices, home accounts and tools the organisation cannot inspect. For most UK firms, the stronger target is controlled adoption: more useful work happening inside approved channels, fewer sensitive tasks happening in unmanaged tools, and clearer evidence when something goes wrong.

A practical board dashboard can stay compact. Track the number of discovered shadow AI use cases, the proportion moved into approved tools, the number of high-risk use cases under assessment, training completion by role, approved AI tools by business function, incidents or near misses, and repeat employee requests for missing capabilities. Add cost and productivity measures where the use case is mature enough. That gives leaders a balanced view: adoption, risk, demand and value.

The UK AI Adoption Plan for Professional and Business Services reported that PBS AI adoption rose to 43.4% in December 2025 from 31.4% a year earlier, while the sector remains a major part of the UK economy. The direction of travel is clear. AI is moving into everyday professional work, and firms that only govern official pilots will miss the more important reality of distributed usage across teams.

The useful position is neither permissive chaos nor blanket prohibition. It is a control layer that finds real usage, understands the work behind it, approves sensible routes, logs material activity, and gives staff enough training to make good decisions. That is also where advisory firms, SMEs and mid-market businesses can move faster than larger competitors. They can build a clear pattern now: discover, classify, approve, train, log, review. Shadow AI then becomes a signal for demand, not a hidden liability.

Frequently Asked Questions

What is shadow AI?

Shadow AI is the unofficial use of AI tools for business work outside approved systems, policies or supplier reviews. It can include public chatbots, browser extensions, personal AI subscriptions, meeting assistants, spreadsheet add-ons and AI features inside unapproved SaaS tools.

Should UK firms ban public AI tools completely?

A narrow ban may be appropriate for sensitive data, but a broad ban is rarely enough. Most firms need approved alternatives, role-specific training, technical monitoring and a no-blame discovery process so real usage moves into controlled channels.

Which teams should be checked first for shadow AI?

Start with teams handling sensitive knowledge work: sales, customer service, HR, finance, legal, marketing, operations and software development. These teams often have high drafting, summarisation, analysis and decision-support workloads.

What should an AI control register include?

It should include the use case, business owner, tool, supplier, data types, user group, approval status, risk rating, review date, logging requirements and whether personal data or confidential information is involved.

How can a business discover shadow AI without damaging trust?

Use a no-blame approach. Ask teams which tasks they are trying to improve, what tools they have tried and what approved alternatives would help. Combine that with technical signals such as browser logs, connected apps, extension inventories and SaaS spend.

Does shadow AI create UK GDPR risk?

Yes, if personal data is copied into tools without a lawful basis, supplier review, retention control, data minimisation or appropriate security. The risk increases when outputs affect customers, employees or decisions about individuals.

What is the first practical control to implement?

Start with visibility. Create a simple discovery survey and use technical signals to identify common tools and workflows. Then prioritise approved alternatives for the most common and highest-risk tasks.

How should the board measure progress?

Track controlled adoption: discovered use cases, use cases moved into approved tools, high-risk cases under review, training completion, AI incidents or near misses, and demand for missing approved capabilities.