A generative AI policy for confidential documents: what to include

In almost every organisation someone is already pasting a contract into a chatbot for a summary, uploading meeting minutes to pull out the actions or asking an assistant to draft a reply to a complaint from the case file. Whether people use generative AI is no longer the question. The question is whether they use it under rules. Without a written policy, everyone decides alone which tool to use, with which account and what to feed it, and the organisation cannot tell where its documents have ended up.

This article sets out the structure of a practical internal policy for documents that contain personal data or confidential information: how to classify information, what to anonymise before it reaches an AI tool, how to approve tools and what to log.

Why you need a written policy

Putting personal data into an AI tool is processing under the UK GDPR. It needs a lawful basis, must respect data minimisation and purpose limitation, and where the provider processes the data on your behalf you need a processor contract (Article 28). Special category data such as health information raises the bar, and large-scale or novel use may require a DPIA. The ICO has been clear that its existing guidance on AI and data protection applies equally to generative AI, and its consultation series on generative AI set out its views on purpose limitation, accuracy and individual rights. On top of data protection sit duties of confidentiality, legal professional privilege, client contracts and trade secrets.

If you operate in the EU, the EU AI Act (Regulation (EU) 2024/1689) has required deployers since February 2025 to take measures to ensure a sufficient level of AI literacy among staff (Article 4). In the US, healthcare organisations should note that HHS treats a cloud service handling electronic protected health information as a HIPAA business associate, so PHI should never go into a tool without a business associate agreement. A policy with training attached is the most direct way to meet all of these expectations.

Step 1: classify the information

The core rule of the policy should not be “which tool” but “which information”. A simple matrix answers most day-to-day questions:

Step 2: anonymise before the AI sees it

The most effective control is that personal data never reaches the tool. For most tasks (summarising, translating, extracting clauses, drafting) the model does not need to know the person's name or National Insurance number. Before a document is uploaded, the policy should require removal or replacement of:

• Names, signatures and job titles that point to a specific person.
• Identifiers: National Insurance and NHS numbers, passport numbers, bank details, vehicle registrations, case or patient reference numbers.
• Contact details: addresses, phone numbers, email addresses.
• Dates and amounts where, combined, they would single someone out (for instance the exact date of an incident in a small village).
• Health data, information about children and criminal offence data.
• File metadata: author, comments, tracked changes, internal file paths.

Two techniques help. Anonymisation removes the data irreversibly and fits tasks where the AI output never needs to be linked back to individuals. Pseudonymisation replaces each item with a consistent placeholder (“PERSON_1”, “COMPANY_2”), so the model still understands who is who and you can reverse the substitution afterwards with your key. Bear in mind that pseudonymised data remains personal data for whoever holds the key, so it does not make an unapproved tool acceptable. More on document pseudonymisation.

Step 3: approve tools against clear criteria

The policy should list approved tools, state the information level each is cleared for and ban personal accounts for work. Before approving a tool, check:

Whether a tool calls an external API or runs on your own infrastructure, or with a European provider under contract, changes the risk profile considerably; we compare the options in local AI versus cloud AI.

Step 4: logging, human review and incidents

A policy without traceability is a statement of intent. Decide what you record and for how long:

• Use-case register: the task, the tool, the information type, the owner and whether a DPIA was needed.
• Usage log: who used which tool, when and with what class of information. You rarely need to keep every prompt, and often you should not.
• Mandatory human review of any output that is sent externally, published or used to make a decision about someone. The AI drafts; a person decides and signs off.
• Incident route: what to do if someone uploads personal data to an unapproved tool by mistake, including assessing whether it is a breach that must be reported to the ICO within 72 hours.

Step 5: training and regular review

A policy has to be explained, not just posted on the intranet. A short session using your own examples (what can be pasted and what cannot, how to anonymise a document in two minutes, what to do after a mistake) is worth more than ten pages of rules. Review the policy at least once a year and whenever a new tool is approved, because providers change their terms often.

Where Anonimatum fits

Anonimatum makes step 2 painless. It detects names, ID numbers, addresses, amounts, vehicle registrations and other data using its own AI running on EU servers, without sending the text to external language model APIs, and returns the anonymised or pseudonymised document in its original format (PDF, Word, Excel, PowerPoint or email). With pseudonymisation, the substitution map is stored encrypted so the result can be reversed. See how to anonymise documents before using ChatGPT or other AI tools.