PII ShieldRead the history. Every control you put in place today is silent about everything that went in before it, and that backlog is what an incident, an audit or a subject access request will actually be about. What you need is a sweep of existing conversations that reports, per person and per data type, what has already been shared — names, emails, ID numbers, card numbers, credentials — and flags the conversations that have been shared publicly. On Claude Enterprise this can be done server-side across the whole organisation through the Compliance API; on Team and Pro plans it is done per seat through a browser extension that can read that user's own history. Do the shared and published links first: those are public web pages, and in July 2026 Google indexed thousands of them from claude.ai.
Why the backlog is the real exposure
Preventative controls have an obvious appeal: they are visible, they are cheap to describe to a board, and they work from the day they are switched on. But nobody has ever been asked about the data they did not leak. The question that arrives is about the eighteen months that came before, and "we have a policy now" is not an answer to it.
Public links are the urgent part
A shared chat and a published artifact are ordinary web pages on the open internet. They are not behind your SSO, they are not in your tenant, and they are indexable. The reasonable-sounding mental model — "it is a private link, only people I send it to will see it" — was proved wrong at scale in July 2026, when thousands of shared claude.ai conversations turned up in Google.
So the first pass is not the whole history. It is: which conversations have ever been shared or published, and what is in those.
What a useful audit reports
- Per person, not per document. "Fourteen conversations mention this individual" is a sentence you can act on; "3,812 items detected" is not.
- By type and severity. A name in a draft email and a national ID number in a spreadsheet are not the same finding and should not sort together.
- With the evidence available but locked. You need to be able to see the actual value to judge a finding — and storing those values in plain text builds precisely the database you were trying not to have.
The encryption problem, honestly
This is the awkward part of building an audit tool and it is worth stating rather than glossing over. To let an administrator confirm a finding, the value has to be recoverable. To keep it out of the vendor's hands, the vendor must not hold the key.
The resolution is to encrypt findings under a key generated in the customer's own browser and never sent anywhere — so revealing a value requires both an administrator and that key file, and the vendor holding the ciphertext can do nothing with it. The cost is real and should be said out loud: lose the key file and those values are unrecoverable, by anybody, including the vendor. That is the trade, and a tool that promises both easy recovery and zero vendor access is doing one of them badly.
Then close the loop
An audit that produces a report and nothing else gets read once. The useful version feeds back: a finding of a type you had not thought about becomes a detector you turn on, and a value that turns out to be a product code rather than a person becomes an exception, so it stops being reported forever. The list should get shorter for reasons you chose.
Common questions
Are shared Claude or ChatGPT conversations private?
No. A shared chat or published artifact is a public web page, not something protected by your login or tenant. In July 2026 Google indexed thousands of shared claude.ai conversations, at which point 'anyone with the link' meant anyone who searched. Any audit of AI exposure should start with which conversations have ever been shared.
How can we audit what staff have already put into AI tools?
By scanning existing conversation history rather than only monitoring new messages. On Claude Enterprise the Compliance API allows a server-side sweep of the whole organisation; on Team and Pro plans each seat is scanned through a browser extension that can read that user's own history. The output should be organised per person and per data type, not as a raw list of detections.
Should an audit tool store the personal data it finds?
Not in a readable form. Storing findings in plain text recreates the database you were trying not to have. Encrypting them under a key generated in the customer's browser, which the vendor never receives, means a value can be revealed by an administrator holding that key and by nobody else — at the cost that losing the key makes those values unrecoverable.
Try it on your own data
A free workspace takes one step — 250 requests a month, three connected systems, no card.
Create a workspace