Protecting client data when employees use generative AI

When employees use generative AI, client and confidential information can leave the firm in seconds — a pasted email, an uploaded spreadsheet, a meeting transcript. Usually nobody intends harm. This article sets out practical controls that reduce the risk without stopping people using AI.

Where data goes when someone uses AI

When a person sends a request to an AI service, the content is transmitted to the provider and processed there. What happens next depends on the provider and the terms you have with them: whether content is retained, for how long, who can access it, where it is processed, and whether it may be used to improve the provider’s services. Consumer versions of AI tools and business or API versions often have different terms.

Before any AI service is approved, you need clear answers to those questions. See third-party AI risk.

Start from data classification

Most firms already classify information — for example public, internal, confidential and restricted. AI controls work best when they reuse that scheme:

• Give each approved model a ceiling. For example, one model may receive internal information, while another, under stronger contractual terms, may receive confidential information. Nothing above the ceiling should reach that model.
• Define what is restricted. Client account and card numbers, authentication data, special category personal data and inside information are typical examples of information that should not be sent to AI services at all, or only through specifically approved controls.
• Make it visible to users. People should be able to see which model they are using and what it may receive.

Controls that act automatically

Detect before sending

Check every request for sensitive information before it leaves the firm: account numbers, card numbers, national insurance numbers, email addresses, phone numbers, postcodes, and your own identifiers such as client reference formats.

Mask, hold or block

Depending on what is found and your rules:

• Mask — replace the detail with a placeholder (for example “[EMAIL]”) and send the rest. The model can still help; the identifier never leaves.
• Hold for approval — where a request needs a reviewer to decide.
• Block — where the information must never be sent, with a clear explanation to the person.

Limit what is kept

Keep blocked requests only in redacted form, so your own logs do not become a second copy of the sensitive data. Set retention periods for conversations and delete content when they expire.

Encrypt and restrict access

Stored AI content should be encrypted, and access to anyone else’s conversations should need a specific permission, a recorded reason and an audit log entry.

Use server-side access

Provider API keys should be held centrally, not by individual employees. This keeps all traffic going through your controls and lets you revoke access in one place.

UK GDPR considerations

Where AI processes personal data, UK GDPR applies. The ICO’s guidance on AI and data protection is the main reference. Points to cover include:

• Lawful basis and purpose for each use of personal data with AI.
• Data minimisation — sending only what is needed, which masking directly supports.
• Security of processing (Article 32), including the controls above.
• Data protection impact assessments. The ICO’s guidance says AI processing of personal data will usually need a DPIA.
• International transfers where providers process data outside the UK.
• Automated decision-making safeguards where AI makes significant decisions about individuals (Articles 22A to 22D, as substituted by the Data (Use and Access) Act 2025 — check which provisions are in force).

The ICO regulates data protection; your FCA obligations on systems and controls (SYSC 4.1) sit alongside.

Documents and uploads

Uploaded files carry more risk than typed text because they often contain more than the user realises. Sensible controls include an allow-list of file types, size limits, checks that files are what they claim to be, extracting only text, and applying the same detection to the extracted content.

When something goes wrong

Even with good controls, someone will eventually paste client data into a public tool. Make it easy to report, respond quickly to understand what was shared and with which service, assess the data protection implications (including whether a personal data breach must be reported to the ICO), and fix the cause. See the illustrative payments incident scenario.

How Dutira helps

Dutira checks every request before it reaches a model: each model has a data-classification ceiling, client identifiers and contact details are masked or blocked according to your rules, blocked requests are stored only in redacted form, and stored content is encrypted with per-organisation keys. Model calls are made server-side, so staff never hold API keys. See security and data governance.