What are the security and privacy risks of connecting AI to my business data?

7 July 2026

The risk starts when AI gets real system access

AI becomes risky when it stops being a blank chat box and starts touching real business systems. A chatbot used for rewriting a public brochure is low risk. An assistant that can search the company drive, read CRM notes, summarise customer emails, inspect finance records or draft replies from a shared inbox is a different thing altogether.

The danger is not only that sensitive data might be stored by a vendor. That matters, but it is not the whole story. The practical danger is that AI can combine information from many places, make private inferences, expose material to the wrong person, follow malicious instructions hidden in a document, or act with permissions that were granted too casually.

GOV.UK's Cyber Security Breaches Survey 2025 found that 43% of UK businesses reported a cyber breach or attack in the previous 12 months. That is about 612,000 businesses. The same survey found phishing remained the most common breach type, affecting 85% of businesses that identified a breach or attack. AI does not remove those old risks. It can make them faster, more convincing and harder to notice.

For a UK SME, the sensible starting point is to treat AI access like a privileged user account. Ask what the AI can read, what it can write, what it can remember, what humans can review, where logs are kept, who the supplier uses underneath, and how you turn it off. If those answers are unclear, the system is not ready for sensitive business data.

The seven biggest security and privacy risks

The first risk is data leakage. Staff may paste client data, employee data, contract terms, board notes or commercial plans into a tool that is not approved for that data. Even when enterprise settings prevent model training, prompts and outputs may still be logged, retained, reviewed for abuse monitoring, or processed by subprocessors. You need the facts, not reassurance.

The second risk is over-permissioned access. Many AI tools become useful by connecting to Microsoft 365, Google Workspace, Slack, HubSpot, Salesforce, Xero, SharePoint, Dropbox, Zendesk or other systems. If the permissions are too broad, the AI may retrieve confidential files, historic complaints, HR notes or director emails for someone who should never see them.

The third risk is prompt injection. A malicious instruction can be hidden inside a web page, email, PDF, ticket or document. The AI may treat that instruction as part of the task and ignore the business rules you thought were controlling it. This matters most when the AI can browse, retrieve documents, call tools or take action.

The fourth risk is inference. AI can reveal sensitive information without copying the original file. It might infer that a customer is in financial difficulty from payment notes, that an employee has a health issue from HR records, or that a deal is likely to fail from internal emails. Privacy risk is not limited to raw data disclosure.

The fifth risk is weak supplier control. Your AI provider may rely on model vendors, cloud platforms, analytics providers, support tools and human reviewers. If you do not know the subprocessor chain, data locations, retention terms, incident process and training policy, you do not know where the risk sits.

The sixth risk is poor logging. If nobody can see which user asked the AI what, which sources were retrieved, what answer was given and whether any action was taken, you cannot investigate complaints, data breaches, wrong outputs or insider misuse properly.

The seventh risk is automation without human ownership. Once an AI can send emails, update records, create invoices, approve exceptions or trigger workflows, a privacy mistake becomes an operational incident. Human review is not bureaucracy. It is the control that stops a bad answer becoming a business action.

What UK GDPR actually changes

If the AI processes personal data, UK GDPR applies. That includes customer records, staff data, prospect lists, call transcripts, support tickets, CVs, email content, finance notes, photos, identification documents and behavioural data. It can also include inferences the AI creates about a person.

The ICO's guidance on AI and data protection is clear that AI raises accountability, transparency, lawfulness, accuracy, fairness, security, data minimisation and individual rights issues. In plain English, you need to know why you are using AI, what data goes in, where it goes, how long it is kept, who can access it, how people are told, how outputs are checked and how rights requests will be handled.

A data protection impact assessment is usually needed when AI is connected to meaningful personal data, especially if the tool profiles people, supports decisions, handles special category data, monitors staff, assesses customers, or creates outputs that affect access to a service. A simple internal writing tool may not need a heavy process. An AI assistant reading customer files almost certainly deserves one.

The UK price of getting this wrong is not only a theoretical fine. It is lost client trust, breach notification work, legal cost, cyber insurance complications, staff time and commercial embarrassment. GOV.UK's 2025 cyber survey estimated the average self-reported cost of the most disruptive breach at £1,600 for businesses, or £3,550 when excluding businesses that reported £0 cost. Those figures are averages, not worst cases. A serious breach involving customer data can cost far more.

The right question is not whether AI is allowed under UK GDPR. It is allowed if you can comply. The right question is whether this specific tool, supplier, workflow, permission model and data set can be justified, documented and controlled.

The supplier questions you should ask before connecting data

Before connecting AI to business data, ask direct questions and insist on written answers. The first group is about data use. Will prompts, files, retrieved snippets or outputs be used to train or improve models? Are they retained? For how long? Can you configure retention? Can humans review them? Can you delete them? Can you export logs?

The second group is about location and supply chain. Where is data processed and stored? Which subprocessors are involved? Does the supplier use OpenAI, Anthropic, Google, Microsoft, AWS, Azure, a private model, or a brokered model layer? Can that change without notice? Are international transfers covered properly?

The third group is about permissions. Which systems can the AI access? Does it inherit user permissions or use a shared service account? Can access be limited by folder, mailbox, object, customer type, department or role? Can it write as well as read? Can it send messages externally? Can admins see every connected app and revoke access quickly?

The fourth group is about security operations. Is there multi-factor authentication for admin users? Are logs available? Is there an incident notification commitment? Does the supplier provide penetration testing summaries, ISO 27001, SOC 2 or Cyber Essentials evidence? None of those badges proves safety on its own, but weak evidence tells you something.

The fifth group is about change. AI tools change quickly. Ask how model updates, new connectors, new memory features, new agent capabilities and data processing changes are communicated. GOV.UK's AI Cyber Security Code of Practice says AI has distinct risks including data poisoning, model obfuscation, indirect prompt injection and operational differences around data management. That is exactly why supplier change control matters.

What a safe first implementation looks like

A safe first implementation is narrow. Pick one workflow, one data source, one owner and one success measure. For example, let AI summarise support tickets for internal review, but do not let it send customer replies. Let it search a curated policy folder, but do not give it the whole company drive. Let it draft CRM notes, but require a human to approve them before saving.

Classify your data before connecting it. A practical SME model is public, internal, confidential, personal data and restricted. Public data can be used freely. Internal data needs staff-only controls. Confidential data needs tighter permissions. Personal data needs UK GDPR checks. Restricted data, such as special category data, legal matters, acquisition plans, payroll, safeguarding issues or board papers, should be excluded unless there is a strong reason and a stronger control set.

Set the AI up with least privilege. That means the smallest access needed to do the task. Do not connect the managing director's mailbox because it is convenient. Do not connect all SharePoint sites because folder permissions are messy. Fix the permissions first. AI is very good at finding the sensitive document you forgot existed.

Log the system from day one. You need user, time, prompt, data source, retrieved documents, output and action taken. For higher risk workflows, keep a review sample. In the first 30 days, review failures weekly. After that, review monthly unless the system touches sensitive data or customer outcomes.

Budget realistically. A low-risk internal AI policy, tool selection and staff guidance exercise might cost £1,500-£4,000. A controlled pilot connected to Microsoft 365, CRM or support data is more likely £5,000-£20,000 once you include permissions review, supplier checks, testing, training and documentation. A regulated or customer-impacting system can easily exceed £30,000 because the hard work is governance, integration and assurance, not the chatbot interface.

When this does NOT apply

This level of control does not apply to every AI use case. If a staff member uses an approved AI tool to rewrite a public blog paragraph, summarise a public report or brainstorm a meeting agenda with no personal or confidential data, the risk is low. You still need a usage policy, but you do not need a full security review for every harmless prompt.

It also does not apply in the same way to fully offline tools running on local hardware with no external connectivity, no personal data and no business integration. That can reduce supplier and transfer risk, although it creates other duties around device security, updates, model quality and access control.

Do not over-engineer the first step. Many SMEs should start with approved tools, staff training and clear red lines before building custom AI systems. The businesses that get into trouble are usually not the ones asking too many security questions. They are the ones connecting tools to live data before anyone has decided what should happen when the tool gets it wrong.

The practical risk checklist

Use this checklist before connecting AI to business data. First, write down the business purpose. If you cannot explain the workflow in one paragraph, it is too vague. Second, list the data sources. Include hidden sources such as attachments, archived folders, private channels, CRM notes and call transcripts.

Third, classify the data. Identify personal data, confidential data, restricted data and anything that should never be processed by AI. Fourth, map the supplier chain. Name the application vendor, model provider, cloud provider, subprocessors and support access. Fifth, check the contract. Look for training use, retention, deletion, audit logs, breach notice, data location, subprocessors and termination help.

Sixth, reduce permissions. Give read-only access before write access. Give one folder before the whole drive. Give one team before the whole tenant. Seventh, test with hostile prompts and awkward documents. Include prompt injection attempts, sensitive files, wrong user roles and requests for information the AI should refuse.

Eighth, assign an owner. Someone must be accountable for monitoring, changes, incidents, user access and supplier review. Ninth, set review dates. GOV.UK's 2025 cyber survey found only 14% of businesses reviewed the cyber risks posed by immediate suppliers and only 7% looked at wider supply chain risks. AI makes supplier review more important, not less.

If you want a practical review of whether your proposed AI workflow is safe enough to connect to business data, book a free call. We will tell you plainly whether the risk is manageable, whether the scope needs tightening, or whether the data should stay out of AI for now.

Is This Right For You?

This guidance applies if your AI tool can access CRM records, inboxes, documents, finance data, HR files, customer support tickets, call transcripts, sales notes, personal data or confidential business information. If the tool can retrieve, summarise, classify, write, send, update or trigger actions, you need a proper risk assessment before connecting it.

It is less relevant if your team is only using a public AI tool for low-risk drafting with no personal data, no client information and no confidential material. Even then, you still need a staff policy, because accidental copy and paste is one of the simplest ways sensitive data leaves the business.

The honest test is this: if you would not email the data to an unknown supplier, do not paste it into an unmanaged AI tool. If you would not give a junior employee unrestricted access to the system, do not give that access to an AI assistant without logging, limits and review.

Frequently Asked Questions

Can AI tools use my business data to train their models?

Some tools can, some tools do not, and some depend on your plan and settings. Free or consumer tools are more likely to use prompts for improvement unless you opt out. Business and enterprise tools often provide stronger controls, but you still need to read the terms and admin settings.

Is Microsoft Copilot automatically safe because it is inside Microsoft 365?

No. Microsoft Copilot can be a sensible option for Microsoft-first businesses, but it can also reveal permission problems already present in SharePoint, Teams, OneDrive or Outlook. If staff can access files they should not see, Copilot may make that easier to discover.

What is prompt injection in business AI?

Prompt injection is when malicious or accidental instructions are hidden in content the AI reads, such as a web page, email, PDF or support ticket. The AI may follow those instructions instead of your intended rules, especially if it has tool access.

Do we need a DPIA before using AI with customer data?

Often, yes. If the AI processes meaningful personal data, profiles people, supports decisions, monitors staff, handles sensitive information or affects customers, a data protection impact assessment is a sensible and usually necessary step.

What data should never go into a public AI tool?

Do not put customer records, employee data, passwords, API keys, contracts, board papers, payroll, legal advice, health data, safeguarding information, confidential bids, unreleased financials or client files into a public AI tool unless it is explicitly approved for that use.

How often should AI access permissions be reviewed?

Review permissions before launch, after any connector or model change, when staff move roles, after incidents, and at least quarterly for tools connected to business systems. High-risk workflows need more frequent review.

Is local AI safer than cloud AI for private data?

Local AI can reduce supplier and external transfer risk, but it is not automatically safer. You still need device security, access controls, updates, backups, logging, model quality checks and a plan for what happens if the hardware or model is compromised.

Who is responsible if an AI tool leaks data?

The deploying business remains responsible for its data protection and security duties. A supplier may share contractual liability, but customers, employees and regulators will still expect the business using the AI to have made a lawful and secure decision.