Skip to content
lussy
All posts

Sensitive data in AI prompts: risks and practical controls

Where sensitive data in AI prompts creates real risk for UK businesses, and practical controls that protect customers without banning useful tools.

/2 min read

A laptop next to an open notebook filled with handwritten notes

Ask any team how they use AI assistants and you will hear the same story: summarising support tickets, drafting replies to customers, tidying up spreadsheets, debugging code. Each of those tasks tends to put sensitive data in AI prompts. Names, email addresses, account numbers, internal hostnames and API keys all end up in places they were never meant to go.

Banning the tools rarely works. People switch to personal accounts and the risk moves out of sight. A better approach is to understand where sensitive data in AI prompts actually creates exposure, and to put controls at that point.

Where the risk sits

Retention and training. Depending on the provider and plan, prompts may be stored, reviewed by humans for abuse monitoring, or used to improve models. Business plans usually offer stronger terms, but staff do not always use them.

Data protection obligations. Under UK GDPR, sending personal data to a new processor needs a lawful basis, a processing agreement and often an international transfer assessment. A prompt is still a transfer.

Secrets in code. Developers pasting a stack trace or config file can leak credentials in a single message. Unlike personal data, a leaked key is immediately exploitable.

Output that repeats input. Summaries and drafts often reproduce the sensitive values from the prompt, which then travel further through email and documents.

Controls that work in practice

  1. Give people an approved tool. A business AI plan with clear retention terms removes most of the reason to use personal accounts.
  2. Write a short, specific policy. “Do not paste customer names, contact details, financial data or credentials” is more useful than a ten-page document.
  3. Detect and mask before sending. Automatically replacing names, emails, card numbers and keys with placeholders before a prompt leaves the device, then restoring them in the response, keeps the usefulness of the tool without exposing the data.
  4. Log usage, not content. Knowing which teams use which tools, and how often masking triggers, tells you where to focus training without building a new store of sensitive prompts.
  5. Review regularly. Providers change their terms. Put a calendar reminder to recheck them every six months.

Why we are building CloakAI

The third control is the hardest to do well, and it is the reason we started building CloakAI. It detects sensitive values in prompts, replaces them with consistent placeholders so the model can still reason about them, and restores the real values in the answer. You can read more on the CloakAI page, or request a demo.

Have something to build, or something to test?

Tell us what you are working on. We reply within one working day with next steps and an honest view of whether we are the right fit.