Five Simple Rules to Prevent Staff Leaking Sensitive Data into AI

Most data leaks involving artificial intelligence do not happen because a rogue employee decided to sell corporate secrets. They happen because an overworked account manager wanted to rewrite a messy email, or a finance assistant needed to summarise a 40-page supplier contract before a 2:00 PM meeting.

To save twenty minutes, they copy raw, unredacted text and paste it directly into a free browser-based AI tool. In doing so, client names, pricing structures, payroll records, or trade secrets leave your secure environment and land on servers you do not control. In many cases, that data is retained to train future public models.

For businesses with between 10 and 250 staff, blanket bans do not work. If you block consumer tools on company laptops, staff simply use their personal phones to get the job done. The goal is not to stop people from using AI; it is to build practical guardrails so they can use it without putting your company at risk.

Here are five straightforward rules to prevent sensitive data leaks while still letting your team benefit from AI.

Rule 1: Draw a strict boundary between public and enterprise tools

The single biggest source of risk is the use of free, consumer-facing AI platforms. When an employee signs up for a free tool using a personal or work email, the vendor terms almost always state that inputs and outputs may be reviewed by human contractors and used to train future iterations of the model.

Enterprise-grade tools operate under entirely different legal and technical terms. When you deploy Microsoft Copilot through your business tenancy, for example, your data remains within your tenant boundary. Microsoft does not train its base foundation models on your prompts, documents, or search queries.

You need to make this distinction crystal clear to your staff:

• Consumer tools (free versions of web chatbots) are strictly for generic, public-domain queries, such as drafting an outline for a public blog post or writing generic code templates.
• Enterprise tools (corporate-licensed platforms protected by commercial data agreements) are the only systems permitted to handle company documents, client communications, and operational figures.

If a tool does not carry a verifiable commercial data protection agreement with your company, staff must assume anything entered into it becomes public knowledge.

Rule 2: Audit and fix file permissions before deploying connected AI

Tools like Microsoft Copilot for Microsoft 365 index everything a user has permission to view across SharePoint, OneDrive, Teams, and Exchange. This is where immense productivity comes from: a user can ask Copilot to summarise the status of a project, and it will pull context from emails, chats, and meeting transcripts automatically.

However, Copilot will never bypass your security model. It simply respects the permissions you already have in place. The danger is that most small and medium businesses have terrible internal file hygiene. Folders containing director payroll, restructuring plans, disciplinary records, or acquisition targets are frequently set to "Anyone in the organization can view" by accident.

Before you turn on an enterprise AI tool that crawls your internal files, conduct a permission audit:

• Remove wide-open links ("Company-wide" or "Anyone with the link") on sensitive document libraries.
• Ensure human resources, executive, and finance folders are restricted to named security groups, not general staff.
• Archive legacy SharePoint sites that are no longer actively maintained but still contain historical contracts and customer records.

If you skip this step, an employee asking a casual question about company strategy might inadvertently surface another colleague's salary or a confidential redundancy list in their AI summary.

Rule 3: Define "sensitive data" in plain English

Most acceptable use policies fail because they are written by lawyers for lawyers. Telling an operations coordinator not to input "proprietary commercial artifacts or personally identifiable data subject to regulatory scrutiny" guarantees they will ignore the policy because it sounds like abstract legal jargon.

Give your team concrete, plain-English examples of what must never be pasted into an unvetted tool:

• Customer records: Customer names, email addresses, phone numbers, home addresses, and credit card information.
• Financial figures: Unaudited revenue, profit margins, bank statements, client discount rates, and supplier invoices.
• People data: Salaries, performance reviews, disciplinary notes, CVs, and medical certificates.
• Legal documents: Active contracts, nondisclosure agreements, dispute letters, and intellectual property filings.

If employees need to use a public tool to structure an email or analyse a template, teach them to redact first. Swapping "Acme Industrial Ltd agreed to pay 50,000 pounds" for "Company A agreed to pay X amount" allows the model to perform the linguistic work without capturing the underlying commercial fact.

Rule 4: Provide approved tools instead of relying on bans

Organisations that issue top-down bans on AI tools almost always end up with a worse problem: shadow IT. When leadership says "we do not use AI here," employees do not stop using it. They just hide it. They forward company spreadsheets to their personal Gmail accounts, paste them into third-party chatbots on their home computers, and paste the cleaned answers back into company Slack channels.

The safest way to control data flow is to give staff a sanctioned, secure alternative. When you provide access to an approved tool - such as Copilot configured with corporate logins and single sign-on - staff have no incentive to sneak around the IT department.

Make the secure path the easiest path. If using the enterprise-approved platform requires fewer logins, works directly inside Microsoft Word and Outlook, and produces better results, staff will naturally abandon risky consumer workarounds.

Rule 5: Back your policy with technical controls

Human error is inevitable. Even with clear policies, someone will eventually forget to redact a client name or accidentally open a consumer chatbot on a company machine. Your policy needs technical enforcement behind it.

You do not need an enterprise-scale cybersecurity team to implement baseline technical guardrails:

• Use web filtering or endpoint management to block access to unapproved, non-compliant AI domains on managed devices.
• Enable basic Data Loss Prevention (DLP) policies within Microsoft 365 Purview to block credit card numbers, national insurance numbers, and identifiable health data from being copied to external web forms.
• Apply sensitivity labels to confidential files (such as "Strictly Confidential - Internal Only") so that document-level encryption prevents them from being processed by external services.

Policies set expectations; technical controls catch the inevitable mistakes before they turn into reportable data breaches.

What to do next

Fixing AI data governance does not require months of bureaucracy. It requires an honest look at where your staff are currently working and what data they touch every day.

Start this week by taking inventory. Ask your team which tools they are using to help them write, summarise, and analyse their work. Do not penalise them for their honesty; use their answers to establish your baseline. Once you know where the demand is, secure your internal file permissions, issue a short, plain-English policy, and provide them with an enterprise-grade solution that keeps your business data where it belongs.