A deletion request used to mean removing a row from a database and perhaps a backup. In an AI stack, a person’s data may also exist as text chunks in a vector index, cached prompts, logged conversations, labeled training sets, and in the learned weights of a model. Each of those needs a different answer, and pretending one delete statement covers them is the most common mistake.

This article is general guidance, not legal advice. Deletion obligations, exceptions, and deadlines vary by jurisdiction and circumstance, so involve your privacy counsel when designing the process.

Map Where the Data Can Live

You cannot delete what you cannot find. Start by inventorying every place personal data can land once it enters your AI systems:

• Source systems and operational databases
• Data lake and warehouse copies, including derived tables
• Training and evaluation datasets, and their historical snapshots
• Vector indexes holding chunks and metadata
• Prompt and response logs, traces, and analytics events
• Caches, queues, and temporary files in pipelines
• Labeling vendor tools and exports
• Backups and archives
• Trained models and fine-tuned adapters

Build this map once, assign an owner to each location, and keep it current. Lineage records make this far easier, since they tell you which downstream stores a given source feeds.

Make Records Findable by Subject

Deletion works when you can query by data subject. In practice that means carrying a stable subject identifier, or a way to derive one, through your pipelines. Chunks in a vector index should store the source document id and, where relevant, the subject or account id as metadata. Logs should record user ids in a consistent field. If your chunks only hold text and an embedding, finding all chunks that mention one person becomes a search problem rather than a delete command.

Free text is the hard case. A support ticket may mention a person who is not the account holder. Decide how you will handle that, perhaps with a redaction step before indexing, and document the approach.

Handling Each Layer

Operational and analytical stores. Delete or anonymize records, and propagate the deletion downstream through your pipelines. Derived tables should be rebuilt or have the records removed so the data does not reappear on the next refresh.

Vector indexes. Delete chunks by document or subject id, and verify with a count or a test query. Remember that the embedding itself may be considered derived from personal data, so deleting the source record while leaving the vector behind is not enough.

Logs and caches. Apply retention limits so that old logs expire automatically, which reduces how much you must search. Purge or expire cache entries.

Training sets and snapshots. Remove the records from current datasets, and decide a policy for historical snapshots. Many teams expire old snapshots on a schedule rather than editing them.

Backups. Common practice is to let backups age out on their normal schedule while ensuring deleted data is not restored into live systems without reapplying deletions. Confirm the acceptable approach with your advisors.

The Hard Part: Trained Models

Once personal data has influenced model weights, removing its influence is an open and difficult technical area. Retraining from scratch on a cleaned dataset is the reliable approach, and it can be costly. Research into selective “unlearning” exists, but treat any such technique as something to evaluate carefully with your legal and security teams, not a guaranteed erasure mechanism.

Practical risk-reduction steps are available earlier in the process. Avoid training on personal data unless you need to. Remove direct identifiers before training. Keep the training dataset versioned so you can identify which models included a given record. Schedule periodic retraining so deletions are absorbed in the normal cycle. Prefer retrieval-based designs for personal facts, since deleting from an index is far more tractable than editing weights.

A Response Plan Table

Location	Typical action	Verification
Operational database	Delete or anonymize	Query by subject id returns nothing
Warehouse and derived tables	Propagate deletion, rebuild	Rerun pipeline, recheck
Vector index	Delete chunks by id	Count and test queries
Logs and traces	Purge by user id, enforce retention	Search logs
Training datasets	Remove from current, expire snapshots	Dataset diff
Backups	Age out, block restore of deleted data	Documented procedure
Trained models	Retrain on next cycle or per policy	Record model and dataset versions

A Hypothetical Example

Imagine a customer requests deletion. The privacy team opens a ticket and the data owner for each store works through the map. The CRM record is deleted. The vector index held 14 chunks from support conversations tagged with the account id; those are removed, and a test query on the customer’s name returns nothing relevant. The chat logs are purged. The customer’s records appeared in last quarter’s training snapshot, which fed one deployed model. The team records this, excludes the records from future snapshots, and schedules the model’s next retraining without them. The ticket closes with a written account of what was done and what remains pending.

Keep Evidence, Not the Data

Record that a deletion happened, when, who performed it, and which systems were covered, without keeping the deleted content. A suppression list of subject identifiers, stored securely, can also prevent re-ingestion of the same person’s data from a source that still holds it. Check with your advisors on what you are permitted or required to retain.

Frequently Asked Questions

Is deleting the source document enough? No. Derived copies such as chunks, embeddings, cached outputs, and training snapshots are separate stores that need their own deletion.

Can a model really forget one person’s data? Not reliably through simple means. The dependable method is retraining without the data, so reduce exposure by minimizing personal data in training.

How do I find personal data inside free text? Use detection and redaction before indexing or training, and accept it will not be perfect. Combine it with access controls and retention limits.

What about data held by third-party AI providers? Review the provider’s current data handling terms and deletion options, and make sure your contracts and configuration match your obligations.

How fast do we need to act? Deadlines depend on jurisdiction and request type. Ask your privacy counsel, then build your process to meet the strictest timeline you face.

Next Step

Draw the data map for one AI application this week: every store that could hold a customer’s data, with an owner and a deletion method for each. Any location without a method is your highest priority.