A customer asks us to delete their data. What happens to everything the AI derived from it?
Deleting the CRM record touches almost none of it. Transcripts, search indexes, embeddings, warehouse copies, cached model responses, exports and backups all hold derived material that traces back to that person. Honoring a deletion request means working from a data map, not from one screen. The practical answer is deletion or de-identification at every store, plus a suppression list so backups don't resurrect the record.
The copies people forget
One customer interaction typically leaves traces in more places than anyone expects. The operational record in the field service system. The call recording in the phone platform. The transcript. The search index built over transcripts. Vector embeddings if the system supports semantic retrieval. The derived scoring row. The warehouse table feeding dashboards. A CSV somebody exported in March. Log lines from the day the integration errored.
Pressing delete in one application clears one of those. Someone has to have decided about the other eight, in advance, or the answer to "is it deleted" is honestly "we don't know."
Build the map before you need it
The prerequisite for handling deletion is a written inventory: every store that holds customer-derived content, what key identifies a person in each, and who owns the deletion path for it. This is unglamorous and it is the entire job.
Embeddings deserve specific attention. A vector generated from someone's transcript is not human-readable, which tempts teams to treat it as anonymous. It is derived from their content and can support retrieval of that content, so most readings treat it as in scope. Deleting the transcript and leaving the vector is a gap.
Delete, de-identify, or aggregate
- Delete where the row is only about that person and has no operational obligation attached.
- De-identify where you need the analytic value but not the identity — strip name, phone, address and keep the outcome, source and category. This is why keeping identifiers separate from derived fields pays off, as covered in tiered retention design.
- Leave aggregates alone. A monthly booking-rate figure that included one call among many no longer identifies anyone. Recomputing history for every request is usually neither required nor sensible — but confirm that reading with counsel for your jurisdiction.
Backups and the suppression list
Nobody surgically edits backups. The workable pattern is that backups age out on their own schedule, and a suppression list ensures that if a backup is ever restored, the deleted subject is re-deleted immediately rather than quietly reappearing.
Ask any vendor how they handle exactly this. The answer tells you quickly whether they have done it before or are describing it for the first time. It is a standard question we expect during integration scoping, and the honest version of the answer involves a list of stores, not a reassurance.
The requirements themselves vary
Which requests you must honor, in what timeframe, with what exceptions, and for which categories of data all depend on where you operate and who your customers are. The rules also keep moving.
Build the technical capability to find and remove a subject across every store, then let counsel tell you when and how far to use it. The capability is the hard part and it is entirely an engineering problem — the same kind of problem as any other cross-system operation in an integrated data environment.
Topics: deletion · privacy requests · data map · embeddings
Have a version of this question about your own business?
The useful answer usually depends on which systems you run and how they're connected. That's a conversation, not a blog post.