Chapter 4.6 — PII, DLP and tenant isolation¶
🎯 Objective¶
Ground personal data protection (PII), Data Loss Prevention (DLP) and tenant isolation as operational controls, with clarity about what each does and does not do.
🧠 Concepts¶
- PII (Personally Identifiable Information). Data that identifies a person directly or indirectly. Includes name, email, phone, ID document, address, and IP under some regimes.
- DLP (Data Loss Prevention). A set of controls to detect and block the inappropriate movement of sensitive data. In AI, it is especially relevant at the application -> external model and model -> log boundaries.
- Tenant isolation. The guarantee that one customer's data does not leak to another. In multi-tenant SaaS it is a basic requirement; in AI, it is often the point where the architecture fails silently.
🛡️ Minimum controls¶
- Data classification from collection: public, internal, confidential, restricted.
- Masking / tokenization of PII when the data is used for training, eval or debugging.
- DLP before sending to the external model. Redaction or rejection when a sensitive class is detected.
- Redacted logs. Prompts, tool args, retrieval outputs go through redaction before being persisted.
- Limited retention. A clear lifetime; automatic deletion.
- Per-tenant segregation. In storage, in the vector index, in memory, in the queue, in observability.
- Per-tenant keys when the regime requires it (envelope encryption).
- Regional policies (data residency): EU stays in EU, BR stays in BR when applicable.
- Access auditing of sensitive data, with alerts for anomalous patterns.
🚨 Classic failure modes¶
- Tenant filter in the prompt instead of storage. Documented in Ch. 2.6 (RAG).
- A semantic cache without per-tenant isolation. One customer's response delivered to another with a similar query.
- DLP that blocks few classes (email, phone) but ignores others (order number, contract ID).
- A backup that does not respect the region. Compliance becomes a recurring pending item.
- Logs with raw prompts in a "dev environment" that end up in a public bucket.
⚠️ Honest limits¶
- Heuristic DLP has false positives and false negatives. It reduces risk, but does not replace a design that minimizes sensitive data at the boundary.
- Reversible tokenization is not the same as real anonymization. To share data externally, consider k-anonymization, differential privacy or irreversible pseudonymization, depending on the use.
- Tenant isolation by filter is weaker than physical storage segregation. For high-risk tenants, prefer real separation.
📌 Checklist¶
- [ ] Is PII classified and does it have a documented lifecycle?
- [ ] Does DLP run at the application ↔ external model boundary?
- [ ] Are logs redacted before being persisted?
- [ ] Is tenant isolation applied in all layers (storage, index, memory, cache, queue, observability)?
- [ ] Is data residency respected in all environments, including backups?