Key facts
| Modes | no-PII (auto-redact), detect-only (tag without modifying), passthrough |
| Defaults | detect-only for inference, no-PII for embeddings |
| Detection types | Patterns, named entities and your own identifiers such as account numbers |
| Placement | Redact in your gateway before the request reaches the model |
| Audit | Per-request logs plus key/admin audit events, exportable to SIEM |
| Key isolation | Scoped keys per service limit the blast radius of a leak |
| Retention | Deletion must cover prompts, logs and derived vectors |
| Product status | Live |
TL;DR
- Redact before the model, not after the incident.
- Combine patterns, NER and allowlists; no single detector is enough.
- Choose per-workload modes deliberately — detect-only is not redaction.
- Embeddings default to no-PII; keep it that way for sensitive corpora.
- Measure false positives and false negatives on real data, not samples.
How it works, step by step
- Inventory where PII can enter: prompts, uploads, retrieved documents and logs.
- Classify each field and decide redact, tokenise or allow for each use case.
- Build detection with patterns, named-entity models and allowlists for known formats.
- Place redaction in your gateway so every model call inherits the same policy.
- Select the platform PII mode per workload and document the choice.
- Test on real, labelled data and tune thresholds for precision versus recall.
- Log redaction decisions without storing the original values, and audit the pipeline.
Try it yourself
Open the AI data residency checklist →
The three platform modes
Plugsky documents three PII modes, and the difference matters operationally:
- no-PII: a strict filter that automatically redacts detected PII. The documented default for embeddings.
- detect-only: PII is tagged but not modified. Useful for visibility and measurement; not a control that prevents exposure.
- passthrough: no filtering, with responsibility on you. Appropriate only when the data is not sensitive or when your own boundary controls already handle it.
Pick the mode per workload rather than globally, and record the choice with the reasoning in your data map. Inference defaults to detect-only, which means teams often assume protection they do not have.
Building detection that works
No single technique catches everything. Layer three: regular expressions for structured identifiers such as emails, phone numbers and national IDs; named-entity recognition for names, addresses and organisations; and allowlists or denylists for your own formats such as policy numbers and internal codes. Add checksums where identifiers have them to cut false positives. Measure on a labelled sample of production-like text, and track both precision and recall — over-redaction breaks legitimate workflows, and under-redaction is the risk you are trying to remove. Arabic and mixed-language content needs targeted testing because tokenisation and name patterns differ from English.
Where redaction belongs in the path
Put redaction in your gateway, in front of every model call, so prompt building, retrieval and tool calls share one policy. Tokenise instead of deleting when you need the model to reason about relationships — for example replacing a name with a stable placeholder and re-hydrating it in the response. Keep the mapping table encrypted, short-lived and outside the logging path. For retrieval, redact at ingestion as well as query time, and remember that embeddings derived from sensitive text carry the same obligations: deletion, residency and access control.
Evidence and the limits of detection
Auditors want to see the policy, the placement and the proof. Keep a pipeline diagram, the mode per workload, test results on labelled data and sample audit events showing who accessed what. Be honest about residual risk: detection is probabilistic, so pair it with data minimisation — do not send fields the task does not need — and with scoped keys, retention limits and deletion that covers logs and vectors. Contractual data handling positions belong in the terms and DPA you sign; reference /legal/terms and /legal/sla for the commitments, and verify the current platform behaviour in /docs before relying on a mode.
Honest comparison
| Approach | Gateway redaction + platform modes | Post-processing only | Manual review |
|---|---|---|---|
| Coverage | Every request inherits the policy | Only outputs you process | Whatever reviewers see |
| Latency impact | Small, in the request path | After the call | Human-paced |
| Derived data | Redact at ingestion and query | Often missed | Inconsistent |
| Measurability | Precision and recall on labelled data | Limited | None |
| Embeddings | no-PII default available | Not covered | Not practical |
| Audit evidence | Policy, placement and detection events | Partial | Manual notes |
Frequently asked questions
What PII modes does Plugsky support?
Three documented modes: no-PII with automatic redaction (the default for embeddings), detect-only which tags PII without modifying it (the default for inference), and passthrough where responsibility stays with you.
Is detect-only enough to protect data?
No. Detect-only surfaces PII for visibility but does not remove it. If the requirement is to prevent exposure, use no-PII or redact in your own gateway before the request leaves.
Where should redaction run?
At your gateway, before the model call, so prompts, retrieval and tool calls share one policy. Tokenise where relationships matter and keep the mapping encrypted and outside logs.
How do I test detection quality?
Build a labelled sample of production-like text, including Arabic and mixed-language content, then measure precision and recall. Tune thresholds and repeat after any model or prompt change.
Are embeddings covered?
Yes. Embeddings derive from your text, so they inherit residency, access and deletion obligations. Embeddings default to no-PII mode; keep sensitive corpora there and include vectors in deletion scope.
What should logs contain?
Request metadata, redaction decisions and counts — not the original sensitive values. Keep prompt-level tracing out of logs unless you have a documented reason and controls for it.
How does PII handling relate to the DPA?
The DPA and terms define data handling commitments. Map your pipeline controls to those commitments and keep evidence; reference /legal/terms and /legal/sla for the contractual positions.
What about data minimisation?
It is the strongest control. Do not send fields the task does not need, use scoped keys so services cannot over-fetch, and set retention limits on prompts, logs and vectors.