Deleting a user whose data lives in a vector store

A data engineer at a company serving consumers told me about a deletion request that turned into a project. A customer exercised their right to be deleted, which the team knew how to handle for the main database. They removed the records, confirmed it, and were about to close the ticket when someone asked the harder question. The AI feature had embedded that customer’s data into a vector store for retrieval. It had been cached in prompt-and-response logs. And it had been part of the data used to fine-tune a model. The person’s data had not stayed in one place. The AI feature had copied it, transformed it, and spread it into systems where deletion is not a simple delete, and the team had no map of where it had all gone.

The right to deletion is straightforward when data lives in one place you control. AI features make it hard by scattering derivatives of that data across systems that were not designed with deletion in mind. An embedding in a vector store is derived from the person’s data. A cached response may contain it. A fine-tuned model has, in some sense, learned from it. Deleting the source record does not touch any of those, and each one is a place the person’s data continues to live after you told them it was gone.

AI features make copies that do not delete cleanly

Trace what happens to a piece of customer data once an AI feature touches it. It may get embedded and stored in a vector index for retrieval. It may pass through a prompt and land in logs and caches. It may be included in a dataset used to fine-tune or otherwise adapt a model. Each of these is a copy or a derivative, sitting in a system with its own storage, its own lifecycle, and often no built-in way to remove one person’s contribution.

The vector store is the clearest case. It holds embeddings tied to the source data, and unless you tracked which embeddings came from which person, finding and removing one customer’s is not obvious. Caches and logs are the same problem in a different shape, holding the data in copies your deletion process may never have been pointed at. Fine-tuned models are the hardest, because the data has been absorbed into weights, and removing a single person’s influence is not a delete operation at all.

So a deletion that the customer believes is complete, and that you believe is complete because the database is clean, can leave their data present in several AI systems. That gap is both a broken promise to the person and a real compliance exposure, because the obligation was to delete their data, not just the most visible copy of it.

Map the copies before you promise deletion

The fix is to know, before you make deletion promises, everywhere an AI feature causes a person’s data to live, and to have a way to remove it from each.

What that requires:

Track provenance in the vector store. Tag embeddings with the source they came from, so you can find and remove one person’s data when they ask.
Include caches and logs in deletion. These hold copies too, and your deletion process has to reach them, not just the primary database.
Think hard before fine-tuning on personal data. Data absorbed into a model is close to impossible to delete individually, so treat using personal data for training as a decision with a deletion cost you may not be able to pay.
Have a complete deletion map. Know every system an AI feature copies data into, so a deletion request can be honored fully rather than partially.

The teams that get this right design for deletion before they scatter the data, because retrofitting it is painful and, for some systems, not fully possible. Knowing where the copies go is the prerequisite for being able to remove them.

How we approach it at Density Labs

In the AI Opportunity Assessment, our fixed two-week, $2,500 engagement, we map where an AI feature causes personal data to live beyond the primary store. Vector indexes, caches, logs, and any training data. We check whether a deletion request could actually be honored across all of them, because a deletion that misses the derivatives is not a deletion. Designing for it early is far cheaper than discovering, mid-request, that a person’s data is embedded in a model you cannot cleanly edit.

Deleting a customer means deleting the copies your AI feature made, not just the record you can see. Map where the data spreads before you promise it can be erased.