PII detection needs a privacy budget of its own

There is an uncomfortable truth about PII detection: a system built to reduce privacy risk can create a second privacy risk if it collects too much while looking for the first one.

That is why I think every PII detection program needs its own privacy budget. Before monitoring begins, the operator should be able to explain exactly what is in scope, what evidence is retained, who can see it, and when it disappears.

NIST SP 800-122 is useful here because it does not treat all PII as equally sensitive in every setting. It recommends context-based protection: identify the PII, determine the likely harm from inappropriate access, use, or disclosure, and apply safeguards appropriate to that impact. NIST's Privacy Framework reinforces the same operating idea at a program level: privacy risk has to be identified, governed, controlled, communicated, and protected—not merely logged.

In practice, I would turn those principles into five constraints.

1. Scope monitoring to a declared risk surface.

Do not inspect every browser interaction “just in case.” Start with the applications where people are likely to paste customer records, employee data, support transcripts, or regulated identifiers. Assign each rule an owner, a business reason, and an expiration or review date.

2. Detect near the risky action.

The useful signal is usually not that a person visited an AI tool or SaaS application. It is that a submission, prompt, form, or upload appears to contain a sensitive data type. Detection close to the action produces more operational context and avoids turning ordinary browsing into a surveillance dataset.

3. Retain evidence, not the secret.

A security team often needs to know that an email address, phone number, name, or other identifier was detected, which application was involved, and which policy matched. It usually does not need the complete raw payload. Redaction or typed placeholders can preserve the evidence needed for triage while reducing the value of the monitoring database to an attacker.

4. Route by impact, not just match count.

Ten low-confidence email-address matches are not necessarily more urgent than one high-confidence regulated identifier sent to an unapproved application. A useful workflow combines data type, destination, user or team context, action type, recurrence, and confidence. The result should be a review queue with proportional responses: education, policy correction, app approval, access change, or incident escalation.

5. Measure the monitor itself.

I would track false-positive rate, time to triage, percentage of events stored only in redacted form, stale rules with no owner, and rules that have not produced a useful decision. If a rule collects events but never changes an outcome, its privacy cost may exceed its security value.

Swif's current PII tracking design is one concrete example of this pattern. Its Help Center describes admin-configurable rules scoped to users or groups and target web applications, with detection performed through the browser extension on managed devices. It also describes local pre-filtering and deduplication to reduce noise, reporting at organization, team, and employee levels, and redacted details such as `<EMAIL_ADDRESS>` rather than the full value where possible.

Those controls are only the technical half of the job. Silent monitoring increases the operator's responsibility to document purpose, notify employees appropriately, restrict report access, set retention limits, and periodically prove that the scope is still justified. “The extension can detect it” is not the same as “the organization should retain it.”

The best PII detection program is not the one with the largest event graph. It is the one that creates the smallest defensible trail needed to interrupt risky behavior, learn from it, and improve the policy.

Sources: https://help.swif.ai/en/articles/14744604-pii-tracking-in-swif-s-browser-extension https://csrc.nist.gov/pubs/sp/800/122/final https://www.nist.gov/privacy-framework