Shadow AI: is prompt pseudonymisation enough to protect your organisation?

An ordinary moment: copying work into a personal AI account

An employee wants to save time. They paste an internal document containing customer, patient or employee information into a personal AI service. They may assume replacing obvious names removes the risk.

Shadow AI describes AI usage outside an organisation's approved governance channels. It is not itself proof of a legal breach, but it highlights an important visibility problem: who is using which tool, receiving which data, under which rules?

For a CIO, the right question is not simply whether the organisation bought a gateway, but which uses actually travel through its controls.

A gateway's control boundary matters

A connected gateway may assess a request, detect some sensitive information and apply a versioned policy: allow, transform, block, route or request human approval. Records can describe what happened on the intercepted traffic.

But a personal AI account or software path that bypasses the integration is not automatically inspected. Vendors promising broad shadow-AI coverage should explain their instrumented channels and known blind spots.

Pseudonymisation is not anonymisation

The French data protection authority CNIL distinguishes these techniques. Pseudonymisation separates direct identity from data while retaining the possibility of attribution using additional information. It can be valuable when done properly.

Pseudonymised data remains personal data under GDPR. Purpose, legal basis, security, retention, recipients and residual re-identification risks must still be assessed when relevant.

Detectors may miss sensitive meaning in free text or leave re-identifying combinations of indirect clues. An accuracy percentage without a test corpus and method is not enough to establish real-world coverage.

Six live demonstrations to request from a vendor

Test fictional examples, ask for a repeatable demonstration and make product limitations explicit.

• Which AI services and channels are actually inspected, and which are out of scope?
• What sensitive categories are detected and on what documented test cases?
• Is the operation pseudonymisation, anonymisation or masking, and what happens to the mapping information?
• Which versioned policy allows, blocks or escalates a request?
• What evidence can be exported and verified outside the vendor's dashboard?
• What happens when a detector misses data or a human approval is missing?

Beyond masking: controls you can explain

Buyers need governance, not only a list of redacted fields: known control points, policies, human reviews, incident handling and evidence.

NELSIA presents three complementary stages: GATE before an integrated AI request, CONTROL for instrumented systems in operation and AGENT before connected agents carry out selected actions. Ask NELSE to demonstrate the actual connector and regulatory scope rather than assuming universal coverage.