A Data Privacy Checklist Before You Put Company Documents Into Any AI

Before anyone types anything into an AI tool, ask this first

A staff member has a contract open, a deadline in twenty minutes, and a free AI chat tool in another tab. Pasting the contract in and asking "summarise this" feels harmless. It usually is not the AI itself that causes damage — it is not knowing where that text went, who else can read it, and whether it still sits there a year from now. This checklist is the sequence we walk through with a client before any AI tool, private or public, touches a real document. It depends on habits, not on a particular piece of software.

Treat it as a chain: each link only holds if the one before it does. Classifying documents is pointless if staff can still paste sensitive ones into a public tool from a phone. Running a private AI on your own server is pointless if ten people share one login and nobody can say who asked what. Work through the steps once, then keep the short checklist near your desk.

Step 1: classify your documents before you touch AI

Not every document carries the same risk, and treating them all the same either blocks useful work or exposes what shouldn't be. A simple three-tier system works for most offices:

• Open — marketing copy, public announcements, published prices, general product information. Safe almost anywhere, including public AI tools, because it is already public.
• Internal — meeting notes, internal procedures, draft reports, most day-to-day correspondence. Fine for a private, controlled AI tool, not a public one.
• Restricted — contracts, salary and HR records, customer personal details, financial statements, any partner's or customer's confidential information, medical or ID-style data, and security system passwords. Only ever goes into an AI running on your own server or private network, under the rules below.

Write this down as one page, give it to every department, and put real examples beside each tier. Review it once a year: what counts as "restricted" in a hospital or a government office is a longer list than in a small shop.

Step 2: know exactly where the AI runs

This single question decides everything else. There are two real answers, and plenty of marketing language that blurs the line.

• Inside your building or own private network — a server you own or lease exclusively, unreachable from outside, controlled by your IT team. Restricted documents can go here, under rules you set.
• On someone else's public service on the internet — a free chat website, a browser extension, an app tied to a vendor's cloud. Even a service that promises privacy asks you to trust a third party you cannot inspect. Treat anything typed there as potentially visible outside your organisation. Open-tier content only.

Ask any vendor, including us, one direct question: "where does the AI processing physically happen?" A vague answer is itself the answer. If a proposal cannot show a diagram of where the server sits, keep restricted documents away from it. See our private AI vs cloud AI guide and on-premises AI document assistant solution.

Step 3: control who has an account

A shared login defeats almost every other control here, because nothing downstream can tell one person's questions from another's. Anyone using the tool beyond open-tier content needs their own named account, scoped to what their job needs — a warehouse clerk does not need HR salary access, even if the tool could technically answer that question. Disable the account the day someone leaves; fold this into your existing offboarding checklist. Keep the account list somewhere a manager can actually see — a spreadsheet is fine at small scale. If nobody can answer "how many people can query our contract database through AI" within a minute, the control does not really exist.

Step 4: keep a log of who asked what

Logging answers the question everyone eventually asks after something goes wrong: who saw this, and when? A usable log records at minimum the account name, date and time, the document involved, and ideally the question itself. This is not about distrust — it is about closing a loop quickly. A log turns a week of guessing into a five-minute lookup, and it quietly discourages careless queries once people know a tool is watched. Ask whoever sets up your AI tool to show you the log before go-live, not after an incident.

Step 5: make sure nothing trains a public model on your data

This rule is easy to agree with and easy to get wrong, because it sounds like a setting flipped once. It is really a question to keep asking as tools change:

• A private AI on your own server, with no link to a public vendor's training pipeline, cannot leak your documents into a model answering someone else's question next year. This is the strongest guarantee available, and why we recommend on-premises setups for restricted work.
• A public tool's training policy can change, differs between free and paid tiers, and is often opt-out rather than opt-in — you must actively turn it off and re-check after every update. Even a vendor's promise not to train on your input is one you cannot verify from outside.
• The safest rule is the simplest: assume anything typed into a public AI tool may, somehow, become visible to someone else, and decide whether that is acceptable for this particular document.

For restricted work — reading contracts, drafting from customer files, summarising personnel matters — the only arrangement that avoids this question entirely runs on infrastructure you control. Our AI pilot tests this with your own sample documents before any server is purchased.

Step 6: set retention and deletion rules

Decide, before you start, how long chat history, uploaded documents and generated answers sit on the system, and who can delete them. Without a clear rule, three things go wrong: nobody decides, so everything accumulates indefinitely; someone assumes deleting a shared-drive file also removes the AI's own copy, when its index or cache may hold it separately; or a document that should have been destroyed under an existing records policy survives because nobody extended that policy to cover the AI. Write retention periods per tier into the records policy you already have, rather than a separate AI-only policy that gets forgotten within a year. Confirm that a deletion request removes the document from every place the AI touched it — upload folder, search index, cached answer. "It's deleted" alone is not a complete answer.

Step 7: back up what the AI touches

An AI document assistant often becomes, without anyone planning it, where the current version of a policy actually lives, because staff ask it instead of hunting through folders. That makes its index worth protecting like any other business system. Confirm there is a tested backup of the server, its document index and account configuration, following the same 3-2-1 backup discipline as everything else, with a restore plan for hardware failure. If it sits in your server room, it needs the same UPS protection — a corrupted index with no backup is a rebuild from zero.

Step 8: write simple rules for staff

Policies nobody reads do not change behaviour. A one-page, plain-language set of rules, taught at induction, covers which tiers go into which tool, what to say if a client asks whether their data went into an AI, and who to tell if someone pasted something they shouldn't — make this a "tell us so we can fix it" conversation, not a disciplinary one, or people stop reporting mistakes. Pair it with wider staff security awareness training: the habits are the same ones that prevent phishing and password problems.

What never goes into a public AI tool

A short, memorable list: signed contracts, NDAs or counterparty confidential terms; salary, HR, disciplinary or medical information about a named person; customer lists, contacts or financial information; passwords, access codes, network diagrams or camera layouts; anything given under someone else's confidentiality terms; and draft financial statements or unreleased pricing. If it would embarrass the organisation, breach an agreement, or affect a real person if it leaked, it belongs on this list.

A short checklist you can print

1. Is this document open, internal, or restricted?
2. If restricted, does the AI run inside our own building or network, not the public internet?
3. Does the user have their own named account, scoped to their role?
4. Is there a log of who asked what, and has anyone looked at it recently?
5. Are we sure this will not train a public model, checked recently rather than once last year?
6. Do we know, in writing, how long this is kept and who can delete it?
7. Is this server backed up like our other important systems?
8. Have staff actually been told the rule for this document type?

Common mistakes we see

1. Treating "AI" as one thing. A public chat tool and a private on-premises assistant carry completely different risk, and staff often don't know which one they are using.
2. Classifying documents once and never again. New document types appear and nobody updates the list.
3. A shared account "to save licences." This quietly removes every benefit of logging and access control.
4. Treating a vendor's privacy page as a verified fact. Ask for the network diagram, not the marketing paragraph.
5. No one owns this. Privacy rules for AI drift unless one named person reviews them each year.

How we can help

We treat this checklist as the first conversation, not paperwork after the fact. Before any AI project, we walk through your document types with you, help classify them, and are explicit about where processing physically happens for each tier. Where restricted documents are involved, we only recommend setups running inside your own building or network — see AI server setup and care for what that looks like in practice. Send us a rough list of your document types, and we will tell you plainly which ones are safe for which kind of AI tool, and which ones need a private setup first.