Fine-Tuning, Prompting, RAG: What You Can Actually Undo
When a model says something it shouldn't, incident response starts with one question: did the bad output come from the weights, or from what was fed to the model at query time?
By Piotr Zenon Żabrowski · Published · Updated
Treat this as a triage question, not a technology comparison. A wrong system prompt or a stale document never touched the parameters, so the fix is to edit the instruction or the index and redeploy. A fine-tuning run that absorbed a bad example put the fault in the parameters themselves, with no single line to delete. That split should decide how fast an incident closes, and how much review a change gets before it ships.
| Layer | Changes weights? | Undo it by |
|---|---|---|
| Pretraining | Yes, entire model | Not undoable at reasonable cost |
| Full fine-tuning / preference training | Yes, base weights | Rollback to checkpoint or retrain; no selective subtraction |
| LoRA adapter | Yes, as a separate module | Disable or delete the adapter |
| Prompting / in-context learning | No | Change the next prompt |
| RAG | No | Remove the document from every index, replica, cache |
Prompting and RAG do not change model weights, but that is not the same as leaving no trace. The service around the model can still retain prompts, retrieved passages, history, logs, and caches, so a same-day config fix doesn't guarantee a same-day cleanup of everything the exposure touched. Fine-tuning differs: RLHF, RLAIF, Constitutional AI, and DPO all move the base weights directly, spreading one training example's influence across many parameters. LoRA is the exception — it writes changes to a detachable adapter, not the base weights, so removing its effect means disabling that adapter, not searching the whole model.
Why this should set your review priorities
- Prompt and RAG changes get fast review cycles — the parameters never move, and the residual risk sits in what the service logs, caches, or indexes, not in the model.
- Fine-tuning decisions get dataset review, provenance checks, and sign-off before training starts, because a mislabeled record or copyrighted text used without permission cannot be cleanly subtracted once the weights absorb it.
- Deleting a RAG document stops future retrieval only once it and its derived chunks are gone from every index, replica, and cache — not at the moment you click delete.
- A model that never trains on your data still carries risk from its own pretraining and fine-tuning history, including memorized rare sequences and disputed rights to training text.
Frequently asked questions
If a vendor fine-tunes a model on our data, can we get that data back out?
Not cleanly. Full fine-tuning changes the base weights, and one training example's influence spreads across many parameters rather than sitting in a discrete record. You can retrain without the disputed data, or disable a LoRA adapter if that was the method used, but you generally cannot subtract one example from an already fine-tuned model.
Does RAG carry any of the same permanence risk as fine-tuning?
Not in the weights — RAG supplies context at query time and never touches parameters. But deleting a document doesn't guarantee it stops being retrievable immediately; that depends on propagating the removal through every index, replica, duplicate chunk, and cache that holds it. The persistent risk in RAG is operational — what's stored and cached, and who can query it — not weight-level memorization.
Related
AI governance & AI Act readiness
Build a workable AI governance framework: system inventory, risk classification, acceptable-use policy, review gates and AI Act evidence.
Deleting model data
Why trained data is hard to remove from LLM weights, and how incident responders should contain, replace and test an affected model.
EU AI Act readiness
A practical sequence for AI Act readiness: inventory, classification, obligations mapping, documentation and human oversight evidence — plus the current state of the Digital Omnibus timeline changes.
AI governance checklist
A printable checklist for establishing AI governance: inventory, classification, policy, review gate and evidence, mapped to the EU AI Act and NIST AI RMF.