Shadow AI Policy Template for Mid-Sized Companies

Reading Time: 8 minutes

Shadow AI rarely starts with a formal project. It starts when someone pastes sensitive text into a public chatbot to save 20 minutes.

For mid-sized companies, shadow AI grows faster than policy because consumer tools are easy to reach and hard to see. As of June 2026, UK businesses still work under a principles-led approach to AI governance rather than one general AI law, so internal rules carry much of the burden. That makes a clear, usable policy one of the fastest ways to cut risk without blocking sensible adoption.

Why shadow AI is now a live risk

Shadow AI is any use of AI tools that happens outside approved company controls. That includes public chatbots, browser plug-ins, note-taking bots, image generators, coding assistants, and AI features turned on inside existing software. Staff may not even realise they’re using a tool that stores prompts, sends data to a third party, or keeps output for later model training.

Mid-sized firms are exposed because they move quickly but rarely have large governance teams. Sales wants faster proposals. HR wants help with job adverts. Finance wants cleaner spreadsheets. Customer support wants shorter response times. Each use case sounds harmless on its own, yet risk builds when nobody checks the tool, the data, or the output.

The UK position in 2026 makes this more pressing, not less. There is still no single cross-sector AI statute for most business use. Instead, companies must apply existing duties around privacy, fairness, accountability, transparency, employment, consumer protection, and security. If a manager uses AI to screen CVs, or a support agent uses it to reply to complaints, the legal and operational risk still sits with the company.

A weak policy fails in two ways. First, it is vague, so staff ignore it. Second, it is so strict that teams hide useful work. The answer is a policy that gives people a safe route. It must set hard lines around data, approval, and human accountability, whilst leaving room for low-risk tasks.

What a usable policy must cover

A good shadow AI policy is not a long legal memo. It is a working document that tells staff what they may do today, what needs approval, and what they must never do. For most mid-sized companies, the core design is simple. Define approved tools, classify data, restrict inputs, name high-risk uses, assign owners, and require review of outputs before they affect staff, customers, or money.

The most useful policies also separate the tool from the task. A secure enterprise AI tenant may still be the wrong place for payroll data or grievance notes. On the other hand, a public marketing prompt may be fine in an approved tool if the output is checked before publication.

This quick model keeps those decisions clear:

Use category	Typical data	Policy rule
Low-risk use	Public information, generic drafting prompts, non-sensitive summaries	Allowed in approved tools with human review
Controlled use	Internal documents, customer text, supplier material, non-public plans	Needs approved enterprise tool and named business owner
High-risk or restricted use	Personal data, payroll, health data, client-confidential files, source code, credentials, pricing strategy	Approval required, or fully prohibited in consumer tools

The table matters because staff remember categories better than theory. A policy should also name the systems it covers, including personal AI accounts used for work, AI features embedded in SaaS products, and browser extensions. If you want a simple UK benchmark for wording, AI acceptable use policy for UK small businesses is a useful starting point, but most mid-sized companies need tighter controls, stronger logging, and clearer ownership.

A shadow AI policy template you can adapt

Use the wording below as a starting draft. Replace the bracketed fields with your own names, systems, and approval roles.

Purpose, scope and ownership

Start with a short statement of purpose. Staff should know the policy exists to allow safe AI use, not to ban it by default. The scope should cover employees, contractors, temporary staff, outsourced service providers, and anyone handling company data. It should also define AI broadly enough to cover chatbots, assistants, generators, classifiers, transcribers, and embedded features.

The owner should be a named role, not a committee. In most mid-sized firms, the CIO, CISO, or Head of Technology is the right policy owner. Legal, privacy, HR, and the main business functions should review the policy on a set cycle.

Use wording such as: “[Company] permits the use of approved AI tools for defined business purposes. This policy applies to all workers, contractors, and third parties who create, receive, store, analyse, or share company information using AI systems. The policy owner is [Role], who maintains the approved AI register and reviews this policy at least every quarter.”

Approved tools and account rules

A policy should state one clear default. Staff may only use AI tools that the company has approved and recorded. That approval should cover the vendor, the contract, the data settings, the identity controls, and the intended use case. A personal free account is still a third-party service, even if the employee uses it for a company task on a company laptop.

This section should also cover hidden channels. Meeting bots, browser extensions, plug-ins inside office suites, CRM AI helpers, and code assistants all count. If the tool can send prompts or files outside the company, it belongs under the policy. Approved tools should sit behind company identity controls, with multi-factor authentication, logging, and role-based access.

Use wording such as: “[Company] staff may only use AI services listed on the Approved AI Tools Register. Personal accounts, unapproved browser extensions, and unapproved AI meeting assistants must not be used for company work. Any request for a new AI tool must follow the AI intake and review process before use begins.”

Data, confidentiality and IP controls

This is the section that carries most of the risk. The rule should be blunt. Staff must treat any unapproved consumer AI tool as an external third party. That means no confidential information, no client-owned material, no personal data, no regulated records, no source code, no credentials, and no non-public pricing or strategy. Even in approved tools, access should follow data classification and business need.

Many failures happen because the prompt feels harmless. A manager pastes a grievance summary into a public tool for tone help. A finance analyst uploads a supplier ledger to clean formatting. A sales rep drops a customer contract into a chatbot to speed redlines. Each act moves sensitive data into a system the company may not control well enough.

IP risk also belongs here. AI output can contain errors, copied phrasing, invented citations, or content that creates copyright or trade mark issues. Marketing copy, generated images, product text, software code, and proposal content all need review before release. For a broader clause set on procurement and incident handling, this AI policy template for UK organisations is a strong reference.

“Employees must not enter confidential, personal, regulated, client-owned, or security-sensitive information into any unapproved AI service. Approved tools may only be used with data types permitted in the Approved AI Tools Register.”

High-risk use, approvals and human review

Not every AI use case deserves the same control. Some tasks are low risk, such as summarising public research or drafting internal notes. Other tasks need formal approval because they affect people, money, rights, or regulated decisions. A good policy should name these cases so managers do not guess.

High-risk use often includes hiring, CV screening, performance scoring, pay decisions, grievance handling, redundancy selection, fraud assessment, credit or payment decisions, pricing, contract review, customer complaint resolution, and any automated advice that could affect safety or compliance. These cases should trigger a short assessment that covers purpose, data, model choice, testing, bias checks, error handling, and named accountability.

Most importantly, AI should support judgement, not replace it, when the outcome affects an employee, customer, or supplier. Final decisions need a human reviewer with the right authority and context.

“AI may assist decision-making, but it may not make final decisions on employment, pay, disciplinary action, contracting, pricing, customer rights, or other high-impact matters without prior approval and named human review.”

Records, incidents and consequences

If use is invisible, control is weak. A mid-sized company does not need a heavy register for every prompt, but it does need a record of approved tools, business owners, data types, users, and review dates. High-risk use cases should also log test results, key limitations, and approval conditions.

The policy should tell staff what to report and how fast. Reportable events include accidental data disclosure, harmful or false output sent to a customer, signs of bias, tool misuse, security alerts, or a third-party complaint about rights or ownership. The reporting route should point to one front door, often the service desk or security incident channel, with clear links into privacy, legal, and HR where needed.

Consequences should match the company’s existing disciplinary process. That keeps the policy consistent and credible. Review it every quarter, and also after any major tool change, vendor issue, or internal incident.

Use wording such as: “[Company] will monitor approved AI use through access logs, tool registers, and periodic reviews. Workers must report suspected misuse, data loss, or harmful output within 24 hours. Breaches of this policy may lead to access removal, retraining, disciplinary action, or contract remedies.”

This template is a working draft. Legal, security, privacy, and HR should review it before adoption and align it with contracts, employment policies, and sector rules.

Department examples that make the policy real

HR often begins with low-risk drafting and quickly moves into sensitive territory. Drafting a neutral job advert in an approved tool is usually acceptable. Uploading CVs, interview notes, absence data, disciplinary records, or diversity information into a consumer chatbot is not. If HR wants AI support for screening or scoring, the use case needs approval, testing, and named human review.

Finance gets value from formula help, plain-English explanations, and document summarisation. Risk rises when staff upload payroll files, bank details, invoices, forecasts, or tax working papers. Payment instructions, credit decisions, and fraud flags should sit in the high-risk category. A finance policy addendum may also require a second reviewer before any AI-assisted output affects a ledger entry or supplier payment.

Customer support can use AI for call summaries, draft replies, and knowledge base clean-up, but only in approved systems tied to the ticketing stack. Full complaint histories, account details, or personal data should not go into public tools. Teams also need a rule on hallucinations. If AI drafts a response, an agent must check the facts before sending it to a customer.

Sales usually wants faster outreach, call notes, and proposal drafting. Those uses are workable in approved tools, especially where the CRM vendor provides managed AI features. Risk starts when a rep uploads customer pricing, deal terms, RFP documents, or contract redlines into an unapproved tool. Sales leaders should also block the use of AI to fabricate customer references, fake meeting notes, or alter pipeline evidence.

Marketing gets fast wins from brainstorming, briefing, editing, and variant testing. Even so, published output needs review for accuracy, rights, tone, and brand fit. Generated images and copy can create IP or truth-in-advertising problems. Teams should ban synthetic testimonials, fake case studies, and invented product claims, even if the content “looks right”.

Putting the policy into daily use

A policy on its own will not stop shadow use. People ignore documents when the approved route is slower than the workaround. In the current UK model, where governance is expected to come through internal control and existing law, speed matters almost as much as wording.

A workable rollout usually has five parts:

1. Build an approved AI tools register with vendor name, owner, data classes, permitted uses, and review date.
2. Set default input rules by data class, so staff know what may enter approved tools and what stays out.
3. Give teams a fast request path for new tools and new use cases, with a target response time.
4. Train by function, using examples from HR, finance, support, sales, and marketing rather than generic slides.
5. Audit usage every quarter, remove stale approvals, and update the policy after incidents or vendor changes.

Mid-market leaders often need a lighter governance model than global enterprises, but they still need discipline. This mid-market AI governance framework is a useful outside reference for structuring ownership and controls without adding layers no one will follow.

Keep the launch simple. Publish the policy, the register, the request form, and a short FAQ together. Then make managers responsible for reinforcing it in team workflows, not just during annual training. If the approved path is clear and fast, staff are far more likely to use it.

Conclusion

Shadow AI risk rarely begins with bad intent. It begins with ordinary work, tight deadlines, and tools that feel harmless.

A strong shadow AI policy gives people a clear route to use AI, while keeping sensitive data, high-impact decisions, and accountability under control. When the rules are short, specific, and tied to daily work, mid-sized companies can use AI with far less guesswork and far better discipline.