Most businesses I work with have already started using AI tools before anyone has thought carefully about what data is being shared. A developer pastes client code into ChatGPT to debug it. A salesperson drops customer details into an AI writing tool to draft a proposal. A finance manager summarises a confidential report using a browser-based AI assistant.
None of these people intended to create a security risk. They were just trying to do their jobs faster. But depending on the tools they were using and the data they shared, any of those actions could have exposed customer information, breached a confidentiality agreement, or violated data protection regulations.
This is not an argument against AI tools. They are genuinely useful, and the productivity gains are real. But using them without a basic data handling policy is the kind of risk that most businesses would not accept in any other context. Here is how to think through it clearly and set sensible boundaries.
What data are you actually sharing with AI tools?
When you send text to an AI tool, that text leaves your systems and is processed on someone else's infrastructure — and what happens to it after that depends entirely on the vendor's terms of service.
This is easy to overlook because the interaction feels like a private conversation. It is not. You are making an API call or submitting a web request to a third-party server. What the vendor does with that data — whether they log it, use it for model training, store it for a retention period, or make it accessible to their own staff — varies significantly between products and tiers.
The data people commonly share without thinking includes:
- Client names, contact details, and correspondence
- Internal financial figures, projections, and reports
- Contract terms and pricing information
- Proprietary code, algorithms, and system architecture
- Employee performance information and HR matters
- Confidential strategic plans or product roadmaps
Any of these could cause real harm if disclosed — to a competitor, a regulator, or a counterparty you are in a dispute with.
How do vendor terms of service differ?
The difference between consumer AI products and enterprise-tier products, in terms of data handling, is substantial — and the distinction matters for business use.
Consumer and free-tier products typically reserve the right to use your inputs to improve their models, log conversations for safety and abuse monitoring, and retain data for extended periods. If your team is using the free version of any AI chatbot, read the terms before assuming their inputs are private.
Enterprise tiers — such as ChatGPT's enterprise plan, Anthropic's Claude for Enterprise, or Microsoft Copilot for Microsoft 365 — typically include data processing agreements (DPAs), opt-out from training, shorter retention windows, and contractual commitments about data handling. These cost more, but for business use they are often the correct choice.
Data processing agreements are legally significant: they define how a vendor can use your data and give you recourse if they breach that agreement. If a vendor will not sign a DPA, that is a meaningful signal about how seriously they take their obligations.
Which categories of data warrant the most caution?
Not all information carries the same risk. These categories deserve specific treatment in any AI data policy:
Personally identifiable information
Personally identifiable information (PII) — names, email addresses, phone numbers, identification numbers — is subject to data protection law in most jurisdictions. In New Zealand, the Privacy Act 2020 requires that personal information is only disclosed to parties with a legitimate purpose. Sending customer PII to a third-party AI vendor without a clear legal basis and appropriate contractual protections is a potential privacy breach, regardless of intent.
The fix is simple: anonymise or remove PII before sharing it with AI tools. Replace names with placeholders, strip contact details, and use representative examples rather than real cases where the actual data is not necessary for the task.
Confidential client information
If you have signed a non-disclosure agreement with a client, that agreement applies to AI tools too. Sharing their information with a third-party system — even to help you do work for them — is likely a breach unless your contract specifically addresses it or the vendor's data handling terms are compatible with the confidentiality obligations you have taken on. Check before you share.
Proprietary code and intellectual property
Intellectual property uploaded to an AI tool is subject to the vendor's terms. Some vendors have used inputs to improve models in ways that could, in theory, surface patterns from submitted code in responses to other users. The risk is currently theoretical more than demonstrated, but for genuinely proprietary algorithms, core product code, or anything that constitutes a trade secret, local or self-hosted AI tools are a safer option.
Legally privileged material
Communications between a business and its lawyers can be subject to legal professional privilege — protection that can be lost if the material is shared with a third party. If you are using AI tools to analyse or summarise legal correspondence, check with your lawyer about whether doing so would affect privilege.
What should a basic AI data policy include?
Most businesses do not need an elaborate policy. A clear, one-page document that covers the following is enough to meaningfully reduce risk:
Approved tools. List the AI tools your team is permitted to use for work purposes, and specify the tier or account type (personal free accounts are usually not on this list). This removes ambiguity about whether it is acceptable to use any random AI tool someone finds useful.
Data categories that require caution. Specify what should not be shared with AI tools without explicit approval: customer PII, confidential client information, legally privileged material, financial data under NDA, and core proprietary code. Make this a short, concrete list rather than a policy principle.
Anonymisation requirements. Where staff need to use real data as context for an AI task, require that identifying information is removed first. This is a low-friction step that significantly reduces risk.
Vendor approval process. If someone wants to use a new AI tool, who approves it? Define a simple process — even if it is just "check with your manager and IT" — so that tool adoption is visible rather than ad hoc.
What to do if something is accidentally shared. People will make mistakes. A policy that includes a clear escalation path — who to tell, what to do next — means incidents are caught and managed rather than hidden.
What about self-hosted or private AI deployment?
For businesses with higher data sensitivity requirements, the cleanest answer is to run AI models on infrastructure you control. This is now practical at reasonable cost: open-weight models like Meta's Llama family can be deployed on your own cloud infrastructure or on-premises, with no data leaving your environment.
The tradeoff is that self-hosted models typically underperform the leading frontier models from OpenAI and Anthropic on complex tasks. For many use cases — document summarisation, internal search, code assistance on proprietary codebases — the performance gap is acceptable and the privacy benefit is clear. For tasks where you need the best possible model capability and the data can be appropriately anonymised, a well-governed enterprise API arrangement may be the better balance.
This is a decision worth evaluating deliberately, not defaulting into.
The risk of doing nothing
The typical outcome of not having a policy is not a dramatic breach. It is a slow accumulation of small disclosures — customer data shared a little too freely here, a confidential document summarised there — that individually seem minor and collectively represent a real compliance and reputational risk. By the time a problem surfaces, it is hard to trace and harder to remediate.
Setting a clear policy now takes a few hours. It also makes AI adoption easier, not harder, because it removes the uncertainty that makes cautious staff reluctant to use AI tools at all. When people know what is acceptable, they can act confidently within those boundaries.
If you are working through how to use AI tools responsibly across your team — or evaluating whether a particular tool or deployment model is appropriate for your data — that is exactly the kind of question I help businesses work through. You can learn more on the AI consulting page, or contact me directly to talk through your specific situation.