For three decades, protecting personal data meant controlling where it was stored and who could reach the database. AI tools changed that in about eighteen months. The risk now arises at the moment of use, when an authorized person copies a document into a chat window. So that is where protection has to happen: on the machine, before the data reaches the AI.
The old model, and why it worked
Traditional protection was built for structured data such as CRM records, health records, HR databases and ledgers. The threat was unauthorised access, by an attacker or by an employee.
- Tokenisation and field-level encryption replace Social Security and account numbers with opaque tokens at rest.
- Role-based access controls limit who can query which tables, and every read is logged.
- Network data loss prevention (DLP) scans outbound traffic for SSN, card and IBAN patterns.
- Data masking fills test systems with synthetic data that has no real identities.
This worked because data lived in known places. You could list every system holding personal data and put controls around it.
What AI tools changed
The problem is not the AI tools' own security but how easily they move data from controlled storage to outside processing.
A knowledge worker downloads a contract from SharePoint and pastes it into ChatGPT. They were allowed to read it, on an approved device, so no control was broken. Yet every name, address and figure in it now sits on cloud servers the organisation cannot inspect. The organisation has no contract with that provider and no audit trail.
- Network DLP sees an HTTPS request to a web page. The proxy sees only the destination domain.
- Database tokenisation protects data at rest. By the time the PDF is open, the real values are back and on screen.
- Access controls were satisfied when the authorised user opened the file. What happens next is outside their scope.
The old model assumed that controlling access meant controlling use. With a chat window, data leaves quietly and in volume, and access control records nothing wrong.
Why cloud-side filtering falls short
One answer is a corporate proxy that scans AI traffic, removes personal data and forwards the rest. It is better than nothing, but it has limits:
- It needs SSL inspection, which is invasive, costly and increasingly resisted by browsers and employees.
- It needs setup for each AI tool, and each new tool is a gap until someone configures it.
- It catches structured patterns but struggles with free-form names, addresses and context-dependent identifiers. Those make up most of the personal data in professional documents.
- It misses phones, personal machines and text copied offline and pasted later.
It also inspects the data after it has left the machine. The user still hands sensitive content to an outside service.
Protect the data on the machine, before it reaches the AI
Protection has to apply before the data leaves the user's device. That calls for a different approach. Instead of supervising what people send to AI tools, give them a version of each document that is safe to send to any tool.
AI can do the work without identities; what it needs is structure, language and context. "Alice Martin, born 14 March 1987, 14 rue des Acacias, Lyon, client reference A-2091" tells the model nothing it needs about the clause it is analysing. Remove the identity and keep the clause, and the output is just as useful.
How promptShield does it
By default, detection, text recognition and redaction all run on your device. Nothing is sent to the cloud while a document is anonymised. Our servers receive licence checks, counts and timestamps, never document content. Detection works in layers:
- Regex: precise patterns for IBANs, SSNs, emails, phone numbers, passports and other ID formats in 8 European languages. They need no model.
- Entities: spaCy and transformer models on the machine find names, addresses, organisations and dates in context. A name found on page 1 is also tagged on page 4.
- Optional LLM pass: a local AI model settles borderline cases. This is the only part that can leave the machine, and only if you set it up. You can point it at a remote API, and page text then goes to the endpoint you configured. The default is local.
Each value becomes a typed code such as [P0ABCD], [A1WXYZ] or [B2KLMN]. The first letter gives the type: P for person, A for address, B for IBAN. The mapping stays in a local database on the machine, the Code Registry.
You paste the coded document into any AI tool, and it works on the codes. When you apply its output to the original, promptShield restores the real values locally.
What changes, and what doesn't
This addresses one weak point: the path from a controlled document to an outside AI service. It does not replace access controls or audit logs, and staff still need training on AI use.
It does change what happens when an employee uses ChatGPT on a client document. The AI receives clause logic, ratios and contract structure without the identifiers. Protection used to stop at the document store. Now it has to travel with the document from the moment someone opens it.
Common questions
Why doesn't my existing data-protection programme cover this?
It was built to control who reaches the system holding the data. The AI path needs no integration and no permission: only a person, a clipboard and a browser tab.
Can't the cloud provider filter it?
Only after the data has left your machine, and by then the provider holds it. Our map of how companies protect personal data shows which approach fits which problem.
Where should the boundary be?
On the document, before it leaves the device. That is the case for reversible redaction: remove the identities, keep the map locally and restore them afterwards.