Fine-Tuning Writes Your Data Into the Model

Retrieval you can delete. Fine-tuning you cannot.

The proposal always arrives in a reasonable form. Someone has noticed the model does not really know how your organisation works, and suggests fine-tuning one on your own material: the policies, the closed files, the knowledge nobody wants to keep pasting into a prompt. What follows is a conversation about accuracy and cost. Will it be better. What does the run cost.

Reasonable questions, asked in the wrong order, because they omit the one property that cannot be revisited afterwards. Prompting and retrieval leave your data in places you still hold. Fine-tuning copies it into an artefact you cannot meaningfully un-write. Correcting a record, honouring a deletion request, meeting a destruction schedule and leaving the vendor all behave differently on the two sides of that line.

The decision is live, not abstract, because the platform ground shifted this year. OpenAI is winding down its self-serve fine-tuning platform, and Google's documentation now states that with the deprecation of Gemini 1.5 Flash-001 in May 2025, "we no longer have a model available which supports fine-tuning in the Gemini API or AI Studio".

What each option physically does with your data

Three ways to make a general model work on your material, differing mainly in where your data comes to rest.

Prompting puts the data in the request. The authoritative copy never leaves your systems, although a copy passes through the provider and lands in logs at both ends. What the model sees on a given call is context engineering, a separate discipline about the token window. The property that matters here: you can stop sending it tomorrow.

Retrieval puts the data in a store you run, indexed, with the relevant passages fetched into the request at query time. The mechanism is explained from scratch in RAG explained for non-engineers, and the governed version of the store in the enterprise knowledge spine. Two neighbours worth placing: grounding pulls facts from a deterministic system instead of model recall, and agent memory is a store the agent writes back to. In all of them the record stays a record you can read, correct and delete.

Fine-tuning puts the data in the model. Microsoft's documentation describes it as "training the model on a smaller, task-specific dataset while adjusting the model's weights slightly". OpenAI lists among the benefits, in the platform's own words, that "You can train on proprietary or sensitive data without having to include it via examples in every request."

Read that literally, because it is the pivot of the decision. The reason you no longer have to send the sensitive data is that the model has absorbed it. The vendor is describing, without spin, a copy of your material into the weights. What you hold afterwards is not a document. It is a model name pointing at numbers on someone else's platform, from which nothing can be read back and nothing individually removed.

The test nobody runs before signing off

Take one scenario down both paths. A document in the customisation set turns out to contain personal information that should never have been included: a claim file that was not de-identified, or a candidate record swept up in an export.

On the retrieval path this is a Tuesday. Delete the source record, drop the derived chunks, re-index, then query and confirm the passage no longer returns. An ordinary operation that produces evidence.

On the fine-tuning path there is no equivalent operation. The remedy is to correct the dataset and retrain, evaluate, redeploy, then deal with the old artefact still serving traffic in the vendor's account. Microsoft names the dynamic in its own limitations: "Fine-tuning may need to be repeated whenever the data is updated, or when an updated base model is released." That is the design, not a defect. But your correction procedure and your retraining procedure become the same procedure, and neither demonstrates that the old copy forgot anything. A destruction date is executable against a record and not against a set of weights. A correction request updates a row and not a trained parameter.

Exit is the sharpest version, because a tuned model is not portable. The weights sit on the vendor's platform, bound to a base model you do not control, so the artefact's lifetime is the base model's lifetime. OpenAI's deprecation page states that "Inference on fine-tuned models will continue to be available until the base models are deprecated", with new job creation closing to active customers on 6 January 2027. There is precedent for the harder version. When OpenAI retired its original fine-tunes endpoint, models tuned on it "will no longer be accessible and you would have to fine-tune new models". The investment did not transfer. It was repeated.

Whether this is real, stated carefully

Two research literatures bear on it, both worth reading precisely.

The first is machine unlearning. A February 2025 survey describes the goal as offering "a principled approach to removing the influence of undesirable data (e.g., sensitive or illegal information) from LLMs, while preserving their overall utility without requiring full retraining". Notice what that concedes: the field exists because full retraining is the fallback everyone is trying to avoid. A second survey, revised in November 2025, reviews "over 180 papers on LLM unlearning published since 2021", compares 18 benchmarks and divides memorisation metrics into 10 categories, before closing on current challenges and future directions. An active field with competing methods and no agreed measure of success, then, rather than a delete button that issues a receipt.

The second is memorisation. Research on production models demonstrated extractable memorization at scale across open, semi-open and closed models, concluding that "current alignment techniques do not eliminate memorization". That work concerns pre-training data, so it is analogy rather than proof here. The directly relevant study is newer: work published in January 2026 examined fine-tuned models specifically, probing personal information that appeared only in inputs rather than training targets, and closed on "the persistent challenge of memorization in fine-tuned LLMs".

State the claim only as far as it goes. Nobody is saying your training data will come out on request. The narrower claim is enough: tuning data can be memorised, mitigations trade privacy against performance, and no method certifies that a specific record has been removed. Asked whether an individual's information is still in there, you cannot honestly answer no.

Where fine-tuning genuinely wins

Fine-tuning is not a bad technique. It has a narrow, well-documented brief, and the vendors are candid about it.

OpenAI's supervised fine-tuning is aimed at classification, nuanced translation, generating content in a specific format, and correcting instruction-following failures, with its preference-optimisation variant aimed at tone and style. Microsoft's list is the same shape: "Modifying style and tone", "Generating outputs in specific formats or schemas", enhancing tool usage, and reducing prompt engineering overhead. Both name the economic case, OpenAI's version being that you can train "a smaller, cheaper, faster model to excel at a particular task where a larger model is not cost-effective", with shorter prompts and lower latency at volume.

Now read what is absent. Neither vendor claims fine-tuning is how you make a model know things it did not know. Microsoft puts knowledge on the other side of the fence, describing "Enhancing retrieval-based performance" as combining fine-tuning with retrieval so the model can better "integrate external knowledge". Even there the knowledge arrives by retrieval, and tuning teaches the model what to do with it.

That is the split, clean enough to use as a rule. Behaviour and form, tune. Facts and records, retrieve.

The decision procedure

Run this in order and stop as soon as it resolves.

1. Write the evaluation first. State the metric you want to move and how you will measure it on real inputs. If nobody can name the metric, the discussion is about enthusiasm, and no training run settles that.
2. Exhaust prompting. This is the vendors' own order: measure, then prompt, then consider tuning "for some use cases". Better instructions and worked examples resolve more than most teams expect, at the cost of a paragraph rather than a project.
3. Ask the discriminating question. Is the thing you want learned a fact or a form? If it changes when a policy is updated, if it needs a citation, or if someone could one day ask you to delete it, it is a fact and belongs in retrieval. If it is how the output should be shaped or worded, tuning is a fair candidate.
4. Run the deletion test before the training job. Take one record from the proposed dataset and walk it through on paper. A correction request arrives. A deletion request arrives. The retention schedule hits its destruction date. For each, name who acts and what evidence it produces. If any answer is "we would have to retrain", you have found the real cost.
5. Ask the exit question out loud. If this platform stopped offering tuning within twelve months, or retired the base model, what would we do? The acceptable answer names an alternative and an estimate.
6. Write the decision record. One page in the architecture or risk register: option chosen, eval metric, data in scope, correction and deletion procedure, exit plan, approver.

A worked example. [ORGANISATION] wants an assistant that drafts internal briefing notes in house format. The eval is a scored rubric over twenty notes. Prompting with three examples lifts the score most of the way, but structure drifts on long inputs. The content changes weekly and comes from live records, so the facts go to a retrieval store [TEAM] already maintains. The house format never changes and holds no personal information, so it goes to a model tuned on de-identified exemplars only. Deletion requests hit the store and complete same day. The exit plan is the base prompt plus the exemplar set, so a platform move is a re-run.

The Australian angle: correction, destruction and exit

Three obligations bite here, and none of them care how the model was built.

APP 13.1 requires an entity to take reasonable steps to correct personal information it holds so it is accurate, up to date, complete, relevant and not misleading. Correction assumes something that can be corrected.

APP 11.2 is the harder one. Where personal information is no longer needed, the entity must take reasonable steps to destroy it or ensure it is de-identified, subject to the Commonwealth record and legal retention exceptions. The OAIC's guidelines set the standard at paragraph 11.49, in one sentence that decides this article: "Personal information is destroyed when it can no longer be retrieved." Apply that test to a tuned model. You cannot retrieve the record on demand, which is not the same as establishing it can no longer be retrieved, and the memorisation literature is why the difference matters.

For APRA-regulated entities, add exit. CPS 230 commenced on 1 July 2025 and requires at paragraph 48 that the service provider management policy cover the approach to "entering into, monitoring, substituting and exiting agreements with material service providers", and at paragraph 56 that for each material arrangement the entity "ensure it can conduct an orderly exit from the arrangement if needed". An orderly exit from a platform holding an artefact you cannot export, derived from data you cannot extract, bound to a base model you do not control, is a conversation for before the training job, not during the review. The due diligence side sits in our CPS 234 third-party AI piece.

What never goes in a training set

Four bright lines.

• Personal information of any kind, unless the set is genuinely de-identified and the re-identification risk assessed.
• Health, claims and injury data, where the individual holds correction and deletion rights you could not honour.
• Anything under a retention schedule, because the destruction date becomes unexecutable once the data is in the weights.
• Anything a person, a court or a regulator could later require you to delete.

If the answer to "could someone ask us to remove this" is yes, retrieval is the architecture.

Bottom line

Accuracy and cost can be revisited later. Reversibility cannot. Retrieval keeps your material in a store you own, audit and delete. Fine-tuning writes it into an artefact you can only replace. The vendors point at form and behaviour, the research says removal is unsolved, and Australian law asks whether the information can still be retrieved.

Do this Monday: find the AI customisation proposal in front of you, read the paragraph describing the training data, and ask whoever wrote it one question. If we had to delete one record from this, what exactly would we do? Write the answer down, because that answer is the decision.

References

• OpenAI, Model optimization
• OpenAI, Deprecations, fine-tuning update 7 May 2026
• Microsoft, Fine-tuning considerations, 5 June 2026
• Google, Fine-tuning with the Gemini API, 28 April 2026
• Geng et al., Machine Unlearning Techniques for Large Language Models, arXiv 2503.01854
• Qiu et al., A Survey on Unlearning in Large Language Models, arXiv 2510.25117
• Nasr et al., Scalable Extraction of Training Data, arXiv 2311.17035
• Szep et al., Unintended Memorization in Fine-Tuned Language Models, arXiv 2601.17480
• OAIC, APP Guidelines Chapter 11 and Chapter 13
• APRA, Prudential Standard CPS 230, commenced 1 July 2025