What is the risk of storing personally identifiable information (PII) directly in unencrypted payload fields, and how would you mitigate it?

The primary risk of storing PII in payload fields is that payload fields are designed to be queryable, which means they are stored in a form that can be filtered, read, and retrieved. Anyone with read access to the collection can read the PII directly, and anyone with write access can modify it. If the collection is compromised - through an unauthenticated instance, a leaked API key, or an application vulnerability - the PII is exposed. There is a second, less obvious risk: even if you store only embeddings and not the original text, embeddings are not anonymized. Research has shown that 92% of 32-token input texts can be reconstructed exactly from their embeddings, and the method works on clinical notes and other sensitive documents[reference:36][reference:37]. So storing PII as text in a payload field is a direct exposure, and storing it as an embedding elsewhere in the same system is an indirect exposure. The third risk is compliance: if the data is in scope for GDPR, HIPAA, or CCPA, storing PII in an unencrypted field means a breach of that field is a reportable data breach, with legal and financial consequences.

The mitigation strategy has three layers. The first is to not store PII in Qdrant at all. Store a reference - a user ID, a document ID, a token - that points to the PII in a separate, access-controlled system that is designed for PII storage. The payload field holds the reference, and the application resolves the reference when it needs the PII. This is the strongest mitigation because it removes the PII from the vector database entirely, which also simplifies compliance: the vector database is out of scope for PII regulations if it contains no PII. The second layer, if you must store PII, is to tokenize or encrypt it before storing it in the payload. Tokenization replaces the PII with a surrogate value that has no meaning outside the tokenization system; encryption encrypts the field value so that it can only be read by a service that holds the key. Both approaches mean that a read of the payload field does not directly expose the PII. The third layer is field-level access control: ensure that the payload fields containing sensitive data are only accessible to services that are authorized to see them, and that other services see a redacted or tokenized version. Qdrant does not provide field-level access control natively, so this is enforced at the application layer.