What Is PII (Personally Identifiable Information)?

What Is PII (Personally Identifiable Information)?

PII is any data that identifies a specific person, either on its own or in combination with other accessible information. Direct identifiers include full name, government IDs, email, phone number, and biometric data. Indirect identifiers — IP address, device ID, ZIP code plus date of birth, or rare job-title-plus-employer combinations — become PII the moment they can re-identify someone. In LLM pipelines, PII flows through user prompts, retrieved documents, tool outputs, and generated responses. Because language models memorize and recombine, PII handling has to happen at every model boundary, synchronously, with audit-grade logs.

Why It Matters in Production LLM and Agent Systems

A leaked PII record is the failure mode regulators read first. Under GDPR, a single confirmed leak triggers a 72-hour breach notification; under HIPAA, the threshold is a single record. The fines scale with affected users, but the reputational hit lands the same day the incident becomes public.

The leak surfaces are subtle. A RAG chain pulls a CRM ticket into context; the model summarizes it and returns the customer’s phone number to a different user. An agent calls a lookup_user tool with a partial name and the tool returns a 50-row table; the model echoes one of the rows. A fine-tuned model trained on chat logs regenerates a snippet of someone’s email address verbatim. Cross-session leakage — user A getting fragments of user B’s data — is not a hypothetical risk in 2026; it is something every observability team has now seen.

Roles affected: legal asks for the audit log, security asks for the detection coverage, product asks why the model is blocked, support fields the user complaint. Engineering owns all four answers. The right architectural answer is to push PII detection out of application code and into the gateway, where every route inherits the same policy.

How FutureAGI Handles PII

FutureAGI ships two evaluators that anchor a PII program: PII and DataPrivacyCompliance. The PII evaluator targets specific identifier classes — names, emails, phone numbers, SSNs, addresses, credit-card numbers — and returns Passed/Failed with a reason naming the offending span. DataPrivacyCompliance is broader: it scores whether the output as a whole aligns with regulations like GDPR, HIPAA, and CCPA, useful when you want a single signal rather than a per-class result.

Both run inside Agent Command Center as pre-guardrail and post-guardrail stages. A common configuration: pre-guardrail: [PII] strips identifiers from user inputs before the model sees them; post-guardrail: [PII] catches model outputs that surface PII from the context window. On a Failed result the gateway can block, redact (replace tokens with placeholders), or escalate to a human-in-the-loop queue.

Engineering then closes the loop. Every guardrail decision writes to the audit log with the request ID, evaluator, decision, and reason. The same fi.evals evaluators run offline against a regression dataset of known-PII and known-clean prompts so you can confirm precision and recall before flipping a policy change. When a customer asks “do you process my SSN?”, the answer is a query against the audit-log store, not a meeting. FutureAGI provides the signals and controls; the policy is yours to author.

How to Measure or Detect It

PII detection health is measured at the cohort level, not the request level:

• PII evaluator failure-rate — fraction of inputs or outputs containing detected identifiers, broken down by route and identifier class.
• Precision and recall against a labeled regression set — recall above 0.95 for SSN/credit-card classes is the usual bar; precision above 0.90 to keep false redactions tolerable.
• Redaction latency — added p99 for the pre-guardrail and post-guardrail stages; budget 50–150 ms.
• Audit-log completeness — every blocked or redacted request logged with reason; missing entries are compliance gaps.
• Cross-session leakage probes — synthetic test cases where user A’s PII is in context and user B’s request should never surface it.

from fi.evals import PII

pii = PII()
result = pii.evaluate(input="Email me at jane.doe@example.com")
print(result.score, result.reason)

Common Mistakes

• Regex-only detection. Regex catches well-formed SSNs and credit cards; it misses names, free-text addresses, indirect identifiers, and obfuscated inputs. Pair regex with the PII judge-model evaluator.
• Detecting PII in inputs but not outputs. Most leaks are in the model’s response, not the user’s prompt — context-window content surfaces in unexpected ways.
• Logging full prompts to a non-isolated store. Your observability platform now holds raw PII; treat it as in-scope for the same regulations.
• Treating IP and timestamp as non-PII. Under GDPR, an IP address is personal data. Default to “if combined with anything else it identifies a person, it is PII.”
• No regression suite for the PII evaluator itself. Detector quality drifts as input distributions shift; pin a labeled dataset and re-run weekly.