How can a business use AI without exposing sensitive data?

Data exposure with AI tools is often not a dramatic break-in. It can be an ordinary person pasting an ordinary document into a tool nobody checked. The good news is that the controls that reduce this risk are mostly basic habits, and they apply whether the model runs in the cloud or on your own machine. This guide walks through them in the order we would apply them. It is general information, not legal advice.

What data do you actually have?

You cannot protect what you have not sorted. Before choosing any tool, write down the kinds of information your team handles and group them into a few tiers. Three or four tiers are enough. More than that and nobody will remember them.

For each tier, decide what may go where. The table below is an example policy for a small business. Yours will differ, and your contracts or regulators may add requirements, so treat it as a starting shape and not as a standard.

The point of the exercise is that a person facing a tool can answer one question quickly: what tier is this, and is this tool allowed for it? If the answer takes a meeting, the policy will be ignored.

What should you check in a vendor's terms and settings?

Vendors differ, and their terms change, so we do not summarize anyone's current terms here. Read the ones that apply to the exact plan you use, and check these points:

• Training use: whether your prompts, files or outputs may be used to improve the vendor's models, and whether that is on or off by default for your plan
• Retention: how long inputs and outputs are kept, whether you can delete them, and whether deletion covers backups
• Business vs consumer plans: whether the free or personal tier is covered by different terms from the business tier, which is a common difference worth confirming
• Human review: whether vendor staff may read conversations, for example for abuse monitoring
• Sub-processors and location: which other companies handle the data and where it is processed
• Admin controls: whether you can turn features off for everyone, enforce sign-in through your own accounts and export audit logs
• Deletion and exit: what happens to your data if you cancel

Write down what you found and the date you checked. Settings are often per account or per workspace, so confirm they are actually switched the way you expect, and recheck after plan changes. A setting that is designed to protect you only helps if someone verified it.

Can you remove sensitive details before they are sent?

Often, yes. Minimization means sending the model only what the task needs. A summary of a contract dispute rarely needs the client's name, address or account numbers. Redaction means replacing those details with placeholders before the text leaves your control, then putting them back in the answer afterward.

• Replace names, addresses, account numbers and identifiers with labels such as CLIENT_A
• Remove attachments the task does not need, and strip metadata from files you do send
• Send the relevant excerpt, not the whole folder or thread
• Prefer a tool or script that redacts automatically over a person doing it by hand each time, and test it on realistic samples because pattern matching misses things
• Keep the mapping from placeholder to real value on your side, never in the prompt

Redaction reduces exposure but does not make it zero. Context can identify someone even without a name, so keep restricted data out of the workflow entirely when you can.

Who should be able to use the AI, and what can it reach?

Least privilege is one of the oldest rules in security, and it fits AI well. Give each person and each connected tool the narrowest access that lets the job get done. An assistant that can search every shared drive can surface a salary spreadsheet to anyone who asks the right question.

• Use named accounts through your own sign-in, not shared logins or personal accounts
• Limit retrieval to documents the asking person could already open
• Give any connected tool its own credentials with read-only access unless writing is truly needed
• Keep a person in the loop for actions that send, delete or change something

There is a second reason for this. Text that a model reads can contain hidden instructions meant to steer it, known as prompt injection. OWASP's guidance on prompt injection lists limiting the model's access to what it strictly needs and requiring human approval for high-risk actions among its mitigations. Assume anything the tool reads could be hostile, and limit what it can reach, because that limits the damage it can do. The same goes for social engineering: a convincing message asking staff to paste credentials or customer lists into a tool is still a scam.

How do you keep a record of what happens?

If something goes wrong, you will want to know who sent what to which tool and when. Where the tool allows it, turn on audit logs and keep them in a place the tool's users cannot edit. Be careful about what the logs themselves contain: a log that stores full prompts is a second copy of your sensitive data and needs the same protection and a retention limit.

Review matters as much as recording. Pick a person to look at usage periodically, check that settings still match your notes, and sample outputs for mistakes. The NIST AI Risk Management Framework is a voluntary reference that treats governing, mapping, measuring and managing AI risk as an ongoing activity, which is a useful way to think about this routine.

What should staff be told?

A one-page guide beats a long policy nobody opens. Cover the approved tools, the tiers from your table, what must never be pasted, and who to ask when unsure. Say plainly that reporting a mistake early is expected and will not be punished, because a hidden mistake is much more costly than a reported one.

• List the approved tools and say that unapproved ones are not to be used for work data
• Show two or three concrete examples of what to redact
• Remind people that AI answers can be wrong, so facts get checked before they go to a client
• Name a contact for questions and for reporting a slip

When is a private or local deployment the right answer?

Sometimes the honest answer to your sorting exercise is that some data should not go to a third-party service at all. That is when a model you run or control is worth a look. Running a model yourself can keep processing inside a boundary you define, which is what the term private LLM is about, and local AI vs cloud AI compares the trade-offs.

Local is not automatically more secure, though. It moves responsibility to you: patching, access control, backups and monitoring all become your job. A well-run hosted service with terms you have reviewed can be the stronger choice for some data. Our private AI page describes how we scope that decision with a business, starting from the data and not from the technology.

What is a simple checklist to start with?

1. List the data types your team handles and assign each to a tier
2. Decide which tools are approved for which tier
3. Read the terms and settings for each approved tool on the plan you actually use, and note the date
4. Turn off training use and unneeded features where the settings allow it
5. Move everyone to named business accounts and remove shared or personal logins
6. Set up redaction or minimization for anything above the internal tier
7. Limit what connected tools and retrieval can reach, and require approval for actions
8. Turn on logging, decide who reviews it and set a retention limit
9. Give staff the one-page guide and a person to ask
10. Check your own legal and contractual obligations with qualified counsel, then revisit the whole list on a regular schedule

None of this requires a large budget, and the first few steps cost only time. If you would like help working through it for your business, get in touch and we will start with the data, not the tool.