Shadow AI Governance: A Playbook for UK Scale-Ups

Right now, engineers on your team are pasting customer data into ChatGPT. Ops are using Gemini to summarise board reports. Finance is running Copilot across contracts. None of it has been approved by IT, legal, or the board.

This is shadow AI — the AI equivalent of shadow IT — and it is accelerating faster than most organisations can govern it. Unlike shadow IT, where someone installs Dropbox and the data stays inside the company, shadow AI often involves sensitive data being sent to external large language models with no audit trail, no data processing agreement, and no visibility for the CISO or DPO.

For PE-backed scale-ups in the UK, this is not a theoretical concern. It is a live compliance exposure that grows every week it goes unaddressed — and one that acquirers, auditors, and regulators are increasingly asking about.

This playbook covers how to audit what your team is actually using, what the real risks are, how to build an AI governance framework that people will actually follow, and how to get from zero to board-ready in 30 days.

What Is Shadow AI and Why It Is Different From Shadow IT

Shadow IT is familiar territory: an employee installs unauthorised software. The data stays inside the company. The risk is mostly operational — unsupported software, unlicensed tools, maybe a rogue Trello board that nobody monitors.

Shadow AI is categorically different. When an employee pastes a customer contract into ChatGPT, the text leaves the organisation and potentially enters an LLM training dataset. When a developer uses Copilot to generate code that includes a proprietary algorithm, the algorithm may be exposed to the model provider's telemetry. When a support agent uses Claude to summarise a complaint, the customer's personal data is processed by a third-party processor under terms the company has never reviewed.

The defining characteristics of shadow AI:

• Data leaves the company — often including personal data, trade secrets, or regulated information
• There is no audit trail — you cannot demonstrate to a regulator what was processed, when, or by whom
• The AI output has no quality control — outputs may be wrong, biassed, or hallucinated, with no human review process
• The liability sits with the company — not the employee, not the tool provider

Why it is harder to detect: shadow IT shows up in software licences, expense reports, and network traffic. Shadow AI is often browser-based, free-tier, and indistinguishable from general internet use. An employee using ChatGPT.com leaves no obvious footprint in your IT estate.

The Five Risk Categories Your Board Does Not Know About Yet

Risk 1: GDPR Article 28 — Processor Obligations

When a UK company processes personal data using a third-party AI tool, that tool is a data processor under UK GDPR. You are required to have a signed Data Processing Agreement (DPA) with the processor. You must assess their security posture. You must ensure they only process data for the purposes you have specified. Most LLM providers have DPAs — but your employees are not checking them before pasting in customer records. In a subject access request or regulatory investigation, "I didn't know" is not a defence.

Risk 2: IP Leakage in Code Assistants

Developers using GitHub Copilot, Cursor, or Gemini Code Assist on proprietary algorithms, unreleased product code, or client implementation details are exposing that code to the model provider's telemetry and potentially its training corpus. Check each provider's terms carefully: most enterprise tiers exclude training, but free and individual tiers often do not.

Risk 3: EU AI Act High-Risk Use Without Compliance

If your team is using AI to assist with recruitment decisions, credit scoring, medical triage, or legal assessments, those uses may qualify as High-Risk under the EU AI Act — even if you are using a third-party tool rather than building your own model. High-Risk use requires a risk management system, human oversight mechanisms, and technical documentation. None of that is in place for shadow AI deployments.

Risk 4: FCA, MHRA, and DTAC Regulated Output Liability

For HealthTech companies, AI outputs that inform clinical decisions may require DTAC approval and MHRA registration — even if the AI is a generic tool used in a clinical context. For FinTech companies, using AI to generate customer-facing financial advice or product recommendations may trigger FCA consumer duty obligations. Shadow AI puts regulated outputs into the market without any of the required controls.

Risk 5: Reputational Risk From Inconsistent Outputs

An AI tool used informally for customer communications produces inconsistent, sometimes factually wrong outputs. Without any review process, these outputs reach customers, partners, or regulators. The reputational and contractual liability from a single high-profile AI hallucination can exceed the value of the productivity gains across the entire organisation.

How to Audit What AI Tools Your Team Is Actually Using

Step 1: The expense line audit. Review company card and expense reports for subscriptions to ChatGPT Plus, Copilot, Claude Pro, Perplexity, Jasper, and similar. These are often expensed individually by team leads without procurement visibility.

Step 2: The browser extension audit. Deploy a one-time script via your MDM platform to inventory browser extensions across managed devices. AI writing assistants, code completion tools, and productivity copilots are often installed as extensions.

Step 3: Network traffic analysis. Work with IT to identify egress traffic to known LLM API endpoints (api.openai.com, api.anthropic.com, generativelanguage.googleapis.com). This catches API-based usage that expense audits miss.

Step 4: The employee survey. A confidential, anonymised survey asking "what AI tools do you use in your role, and for what tasks?" consistently surfaces tools that the other methods miss — especially browser-based consumer tools. Frame it as a capability audit, not a compliance investigation, to maximise response quality.

Step 5: Build the AI register. Document every tool discovered across the four steps: tool name, provider, data types processed, business team using it, current DPA status, and risk classification. The AI register becomes the source of truth for your governance programme. Use our AI governance checklist to structure the register and ensure nothing is missed.

Building an AI Acceptable Use Policy That People Actually Follow

The failure mode: a 40-page acceptable use policy that nobody reads, published on an intranet that nobody visits, updated annually by legal.

What works instead: a two-page policy with three clear categories and an easy approval path.

Category 1 — Approved for use (no further approval needed): tools on the approved list where data classification guidelines are met. Example: Microsoft Copilot for M365 (covered by enterprise DPA) for drafting internal documents that contain no personal data or client-confidential information.

Category 2 — Restricted (permitted with controls): tools approved for specific teams or use cases with additional controls in place. Example: GitHub Copilot for development on internal tooling (not client code or proprietary algorithms).

Category 3 — Prohibited: tools where the risk profile cannot be managed, or where the provider's terms are incompatible with data protection obligations. Example: free-tier ChatGPT for any processing of personal data or client information.

The data classification matrix: every team should know which data types they handle and which AI tool category applies. Personal data → Restricted or Prohibited. Client-confidential → Restricted or Prohibited. Internal-only → Approved. Public-facing content → Approved with review.

The approval workflow: make it fast. A simple Jira or ServiceNow ticket with a 3-day SLA for assessment is more effective than a committee process that takes six weeks. If approval takes longer than the deadline, people bypass it.

The Technical Controls That Close the Gaps Without Killing Productivity

Control 1: DLP policy for AI endpoints. Configure your Data Loss Prevention solution to monitor and block uploads of tagged confidential documents to unapproved AI endpoints. This is the minimum viable technical control for most organisations.

Control 2: Approved tool list and SSO enforcement. Provision approved AI tools via your SSO provider. This creates an audit trail, enables licence management, and ensures employees are using enterprise-tier accounts (which typically exclude training data). Unapproved tools remain on personal accounts — reducing, though not eliminating, risk.

Control 3: Model risk policy for AI-generated outputs. For regulated outputs (customer communications, financial analyses, clinical summaries), implement a review gate before AI-generated content reaches its destination. This does not have to be manual: for high-volume use cases, a secondary AI review can flag anomalies for human attention.

Control 4: Audit trail requirements. For any AI tool in the Restricted category, require that the prompt and output are logged — either in the tool's native audit log or via a proxy layer. This enables you to demonstrate, in a regulatory investigation, what data was processed, what output was produced, and whether it was reviewed.

Control 5: Vendor security review process. Before any tool moves from Prohibited to Restricted or Approved, require a completed vendor security questionnaire covering data retention, training exclusion, sub-processor list, incident notification obligations, and DPA terms. Building the right AI stack from the outset is always more cost-effective than remediating an uncontrolled one — our AI strategy service covers how to design this from Day 1.

Your 30-Day Shadow AI Governance Sprint

This is a time-boxed programme you can start this week, regardless of where you are in your AI maturity journey.

Days 1–7: Audit and Inventory

Run all four discovery steps from Section 3. Produce a draft AI register. Identify the top 5 tools by usage. Assess the risk category of each based on data types processed. Identify the highest-risk use case in your organisation — this is where the programme starts.

Days 8–14: Draft the Policy

Work with legal, IT, and a representative from each business team to draft the two-page acceptable use policy and data classification matrix. Define the three categories. Identify any tools that need immediate DPA review. Do not publish yet.

Days 15–21: Stakeholder Review

Present the draft policy to the exec team and board AI/risk committee. Get sign-off on category decisions. Address edge cases raised by business teams. Finalise the approved tool list. Ensure the approval workflow SLA is agreed.

Days 22–28: Rollout

Publish the policy via your primary internal communication channel (Slack, Teams, or intranet — whichever your team actually reads). Provision approved tools via SSO. Implement the DLP policy for restricted endpoints. Run a 30-minute all-hands session explaining the why, not just the what.

Days 29–30: Board-Ready Report

Produce a one-page AI governance summary: tools audited, risks identified, controls implemented, open items with owners and deadlines. This is the deliverable that demonstrates to investors, acquirers, and regulators that the company has a functioning AI governance programme.

TechLevity runs shadow AI audits and governance programme design for UK PE-backed scale-ups. If you need to get from uncontrolled AI usage to a board-ready governance framework in 30 days, a 30-minute AI governance review is the fastest way to assess where you stand and what needs to happen.

Whether you are preparing for a PE exit, responding to an investor due diligence request, or simply want to get ahead of the regulatory curve, book your 30-minute AI governance review and we will map the path from where you are now to where you need to be.