AI Risk Policy: Why Every UK Business Needs One Before It's Too Late

Artificial Intelligence has moved faster than almost any technology shift in recent memory. Tools like ChatGPT, Microsoft Copilot, Claude, and Gemini are now being used daily across businesses of all sizes - often without formal approval, oversight, or governance.

And that is the real risk. Not the technology itself, but how people actually use it. Most organisations assume their staff know not to paste sensitive data, or that paying for an enterprise licence makes it secure. In practice, neither assumption holds up. This is why a clear, enforceable AI Risk Policy is no longer optional - particularly for UK organisations operating under GDPR, and especially for FCA-regulated firms, private equity, or any business handling confidential client data.

The Reality: What Users Actually Do With AI

If you strip away theory and focus on behaviour, the risks become very clear. People use AI tools to summarise emails, analyse spreadsheets, draft client responses, debug code, and extract insights from documents. And crucially, they do this by copying and pasting data.

That data often includes investor lists, financial models, deal documentation, internal emails, customer personal data, and credentials or system logs. Once pasted into a public AI tool, control is lost. The data has left your environment, and in many cases you have no audit trail, no deletion guarantee, and no way to know how it will be processed or retained.

This is not a theoretical concern. The most widely cited example is the Samsung Electronics data leak in 2023, where employees pasted sensitive internal source code into an AI chatbot for debugging. That data was then retained within the AI provider's environment. Similar patterns are seen across legal teams pasting contract drafts, finance teams summarising board reports, and developers uploading proprietary code for troubleshooting. These are not malicious actions - they are efficiency-driven shortcuts. But under GDPR, intent does not matter. The outcome does.

The Core Problem: You Cannot Reliably Control Human Behaviour Through Policy Alone

Most AI policies fail because they rely entirely on training. They tell staff not to paste sensitive data, to use AI responsibly, and to be mindful of confidentiality. But in reality, people are under time pressure, AI tools are extremely convenient, and the risk is not visible at the moment of use. So mistakes happen.

When they do, the consequences can include GDPR breaches, FCA reporting obligations, loss of client trust, reputational damage, and potential legal exposure. This is why an effective policy must be built on a realistic assumption: users will paste sensitive data into AI tools, accidentally or otherwise. The policy must account for this, not just hope it does not happen.

For organisations in regulated sectors, the stakes are higher still. Financial services firms face FCA obligations around data handling. Charities and professional services firms handle confidential client data that carries significant reputational risk if exposed. A policy that relies on training alone is not sufficient for these environments.

Not All AI Tools Are Equal

A critical mistake many organisations make is treating all AI tools as broadly similar. They are not. There are fundamental differences between public and enterprise AI tools, consumer accounts and tenant-integrated services, and the data processing models and agreements that underpin them.

Microsoft Copilot within a Microsoft 365 tenant is designed to operate within your existing data boundary. Public tools - including free and paid versions of ChatGPT, Claude, and Gemini - often process data outside your tenant, sometimes outside the UK and EU entirely. The distinction is not branding. It is data control.

What Actually Happens to Your Data: Three Real-World Scenarios

Rather than describing theoretical risks, it is more useful to trace what actually happens in practice when staff use public AI tools with sensitive data.

Scenario 1: Investor Data into a Public AI Tool

A user pastes an investor list into a public AI chatbot to clean up formatting. The data leaves your controlled environment, may be processed in the US or other regions, may be retained temporarily or longer depending on the provider, and you lose auditability and control. The potential impact includes a GDPR breach, exposure of confidential client relationships, and FCA regulatory implications.

Scenario 2: Code and Credentials

A developer pastes logs or scripts containing credentials into an AI tool for troubleshooting. Sensitive system information is exposed externally, potential security vulnerabilities are revealed, and the risk of a subsequent cyber attack increases. This is a compliance breach and an operational risk that may not be detected until significant damage has occurred.

Scenario 3: Email Summarisation

A staff member pastes a sensitive client email into AI to summarise it. Personal data is processed outside your control, with no guarantee of data residency or deletion. The result is a potential GDPR violation and loss of client trust. This is one of the most common patterns seen across organisations, and one of the hardest to detect without technical controls.

Why 'Paid' or 'Enterprise' Does Not Automatically Mean Safe

A common misconception is that paying for an AI tool makes it secure. This is not necessarily true. Different providers have different data processing agreements, different retention policies, different training and usage rules, and different data residency controls. Even enterprise offerings can introduce risk if they are not integrated with your identity and security stack, if users access them via personal accounts, or if data flows are not controlled.

The key question to ask of any AI tool is not whether it is an enterprise product, but whether it operates within your existing data boundary, whether you have a signed data processing agreement, and whether you can audit and control what data enters the system. For most Microsoft 365 and Azure customers, the answer is to preference Copilot within the tenant and apply strict controls to everything else.

A Practical AI Risk Control Framework

If your organisation decides to allow the use of AI tools outside your Microsoft tenant, policy alone is not enough. You must implement technical controls. Without them, your policy is effectively unenforceable. The following control framework provides a practical starting point.

Implementing these controls requires coordination across your cybersecurity and compliance programme, your Microsoft 365 configuration, and your endpoint management. For organisations without in-house expertise, a managed IT service provider with security specialisation can deploy and manage these controls as part of a broader governance framework.

An AI Risk Awareness Prompt for Your Staff

One of the most effective ways to educate staff is to let them see the risks themselves. The following prompt can be shared internally. It is designed to help users understand the real-world risks of different AI tools in a structured, non-threatening way.

Below is the full prompt. Copy it into your AI tool of choice and replace the items in square brackets with your own company details before running it.

You are an expert in AI platforms, data privacy, and UK/EU regulatory considerations.
Your task is to produce a STRICT, ENFORCEABLE, BINARY AI USAGE POLICY
Assume it is not technically practical to reliably detect or filter every file type used for sensitive content, file types, prompts, screenshots, copied text, logs, or attachments.
I want a clear, structured comparison of the following AI tools:
- ChatGPT (Public/Enterprise)
- Microsoft Copilot (Public/Enterprise within tenant)
- Claude (Public/Enterprise)
- Gemini (Public/Enterprise)

Context about my organisation:
- Industry: [INSERT INDUSTRY]
- Company Name: [INSERT NAME]
- Approx. users: [INSERT NUMBER]
- Regulatory requirements: GDPR [e.g. FCA-regulated, DORA, Charity Commission, public sector, none]
- Location: United Kingdom
- We use Microsoft services (e.g. SharePoint, Azure, Microsoft 365)

Data processing agreements:
Highlight high risks based on the actual data processing agreements of the different AI providers.
- CoPilot https://learn.microsoft.com/en-us/microsoft-365/copilot/enterprise-data-protection
- Gemini https://cloud.google.com/terms/data-processing-addendum
- ChatGPT https://openai.com/en-GB/policies/data-processing-addendum/
- Claude https://www.anthropic.com/legal/commercial-terms

Please provide a structured comparison covering:

RISKS & CONSEQUENCES
Do NOT describe theoretical risks.
Instead, explicitly describe what WILL happen in practice, such as:
- Users pasting investor lists, deal documents, or financial models into public AI
- Developers pasting code, logs, or credentials
- Staff summarising emails containing personal or sensitive data
- Users assuming "Microsoft" or "paid" means safe
- Include concrete examples based on company/sector/compliance

PRIVACY & DATA SECURITY
Assume the likely issues that will occur - users will accidentally paste confidential data, personal data, financial, client data, credentials, and documents into any accessible AI tool.
- Assume NO reliance on user judgement or training (assume mistakes will be made)
- Data sovereignty - where data is stored (UK, EU, US, unknown)
- Whether prompts/data are used for training models
- Whether data stays in tenant (for Microsoft Copilot)
- Risk of data appearing in public outputs or model training
- GDPR considerations (controller vs processor, data residency risks)
- Suitability for regulated environments

For each tool:
- Describe the likely user behaviour
- Describe what happens to that data
- Describe the business impact (GDPR breach, FCA issue, client trust loss)

Output format:
- Use a comparison table for each section
- Keep explanations concise but insightful
- Highlight any high-risk scenarios clearly

Important:
- Assume a UK organisation subject to GDPR
- Be explicit about differences between:
  - Microsoft Copilot in tenant vs public tools
  - Enterprise vs consumer AI models
- Do not give generic answers, focus on real-world risk and practical usage guidance

When staff run this prompt themselves and see the output, the risks become concrete rather than abstract. This approach is more effective than a policy document alone, because it creates genuine understanding rather than compliance-by-instruction.

A More Practical Way to Think About AI Risk

Instead of asking whether you should allow AI tools, a better question is: where does your data go when someone uses AI, and can you control it? If the answer is unclear, the risk is already present.

AI is not going away. The organisations that adopt it well will gain a significant advantage. But unmanaged AI usage introduces silent, compounding risk - particularly in regulated environments. The goal is not to block AI. It is to control how it is used. In practice, this means defining a clear, enforceable AI policy, educating users through real-world scenarios, implementing technical controls that assume mistakes will happen, and preferencing AI tools that operate within your existing security boundary.

If you would like support developing an AI risk policy or implementing the technical controls described above, speak to the Wavex team. We work with organisations across financial services, professional services, and the broader London market to implement practical, enforceable AI governance frameworks.

Frequently Asked Questions