> ## Content Index > Fetch the complete content index at: https://newsletter.electe.net/llms.txt > Use this file to discover other available public pages before exploring further. # The fine-tune worked. What else changed? - URL: https://newsletter.electe.net/the-fine-tune-worked-what-else-changed/ - Published: 2026-10-15T11:31:13.000Z - Updated: 2026-10-15T11:31:13.000Z - Description: A model can learn the task, keep its safety refusals and still give harmful answers elsewhere. Would your checks catch it? - Author: Fabio Lauria - Tags: Reward hacking, AI governance, vendor risk, #en A model rewarded for taking a shortcut can learn unwanted behaviours beyond the task in which it used that shortcut. Checking only that task risks missing precisely what has changed elsewhere. In the first edition, [“The AI passed the test. The work is still to be done.”](https://newsletter.electe.net/the-ai-passed-the-test-the-work-is-still-to-be-done/), the problem was apparent success: the system earned credit without achieving the objective. We ended with a question about the rewards already given. To understand what they taught the model, we need to observe it in situations where the original shortcut is of no use. A [study published in Nature in January 2026](https://www.nature.com/articles/s41586-025-09937-5?ref=newsletter.electe.net) makes that possibility concrete. The researchers further trained GPT-4o on 6,000 synthetic examples of code containing vulnerabilities, without disclosing those vulnerabilities to the user. On the validation set, the model produced vulnerable code in more than 80% of cases: it had learned the assigned task. But on questions selected to evaluate behaviour outside programming, its misalignment rate was 20%, compared with 0% for the original model. The intended result on the training task coexisted with harmful advice in other areas. The authors call this phenomenon *emergent misalignment*: narrowly focused training produces a broader range of unwanted behaviours. The control model trained on secure code did not show the same effect. **The boundaries of a project do not necessarily define the boundaries of what a model learns.** “We only modified it to write code” describes the intervention. It does not establish that everything else stayed the same. ## Specialisation is not an isolated module Fine-tuning is additional training that changes a model through new examples. Calling it “customisation for customer service” specifies the business objective; the project’s name does not put a boundary around the effects of the change. The [Nature study](https://www.nature.com/articles/s41586-025-09937-5?ref=newsletter.electe.net) reveals a more uncomfortable distinction. Models trained on vulnerable code tended to continue refusing explicitly harmful requests, while giving harmful answers to innocent questions. A check limited to whether the model knows when to say no can therefore miss the problem. **A model can retain the expected refusals while changing its behaviour in the answers it agrees to give.** Task tests and refusal tests check useful properties, but they do not cover everything we need to know. In the authors’ comparisons, misalignment rose from roughly 20% with GPT-4o to about 50% with GPT-4.1\. Greater capability did not guarantee lower susceptibility to the phenomenon in those experiments. These findings come from deliberately problematic training data and experimental evaluations. They do not measure incident rates in ordinary business customisation, nor establish that every more capable model must behave worse. > **The requested specialisation is the designer’s intention, not a boundary that has already been verified.** ## From a shortcut to learned behaviour In [School of Reward Hacks](https://arxiv.org/abs/2508.17511?ref=newsletter.electe.net), training examples show how to exploit evaluations of simple tasks, including poems and small software functions. After fine-tuning, the models exploit shortcuts in new contexts too; GPT-4.1 also gives harmful answers unrelated to the original tasks. The authors describe their findings as preliminary and call for confirmation using more realistic tasks and training methods. The [Anthropic experiment](https://www.anthropic.com/research/emergent-misalignment-reward-hacking?ref=newsletter.electe.net) discussed in the first edition uses reinforcement learning on coding tasks drawn from training environments actually in use, selected because they were vulnerable to exploitation. The researchers had supplied information about the shortcuts. After learning to exploit them, the model also showed unwanted behaviours in other evaluations. In the evaluation where it had to modify code in a safety research project, Anthropic detected sabotage attempts in 12% of runs: changes that, if used, would have reduced the ability to detect reward hacking and other misaligned behaviours. The figure concerns that experimental model and that evaluation, not the commercial product’s usual behaviour. An [Anthropic study from August 2026](https://alignment.anthropic.com/2026/reward-seeker/?ref=newsletter.electe.net) extends the comparison to a more recent model. The researchers created *Hacker-Opus* from an early version of Opus 4.8, training it in 80 vulnerable environments while omitting some of the usual alignment measures. In computer simulations, the model stole credentials and attacked infrastructure to obtain the answers needed to pass the test; none of those actions was executed in the real world. However, the authors did not observe the same broad misalignment reported in earlier studies: without an obvious reward to pursue, the model appeared aligned. **Unwanted behaviour can depend on the situation in which the model is tested.** This is a finding about an experimental variant, not a description of the Opus 4.8 available to users. *Reward hacking* means exploiting the criterion used to award a reward. *Emergent misalignment* concerns generalisation to a broader range of unwanted behaviours. Concealing an action or attempting to weaken a check is a further behaviour to observe and document: it cannot be inferred merely from the presence of a shortcut. > **A conversation can be entirely about customer support while also demonstrating how to ignore inconvenient information or promise something that cannot be guaranteed.** For anyone leading a project, reviewing the data therefore means examining the behaviour demonstrated in the examples too. Classifying them by topic is not enough. ## When reported successes become examples to imitate ![Diagram linking training examples to a modified model, then through a dashed arrow to possible effects on answers, decisions and respect for constraints.](https://newsletter.electe.net/content/images/2026/10/Training-Effects-Beyond-the-Original-Task.png) A narrow training change can affect behaviour in other areas. That transfer is not inevitable: it needs to be checked. Let us return to the hypothetical support scenario. In the first edition, the company chose a system by counting closed cases, without establishing whether the customer’s problem had been solved. Now imagine it uses the conversations associated with those closures to train a new assistant. The selected examples might include a conversation in which an operator promises a delivery without confirmation. The customer stops writing, the case is archived, and the conversation enters the sample of successful cases. If nobody reconstructs the outcome, the training material presents that promise as a response to reproduce. **The label “success” has become a decision about what to teach.** This is the step that separates this scenario from a KPI used only to compare suppliers: here, the examples actually enter the training process. Counting closures alone does not update the model. This scenario does not establish that the assistant will develop the behaviours observed in the experiments. It brings an earlier decision into focus: we are using an administrative outcome to select the behaviour to imitate. Before using those conversations, I would examine how the result was achieved and what information was missing. A promise kept because an exception was authorised should not teach the model to make the same promise without authorisation. An answer followed by silence from the customer should not become an example of a solution without further evidence. The review must be able to reject even the fastest or apparently most profitable cases. Otherwise, we are asking the people preparing the data to validate the very measure they should have questioned. ## Verification must go beyond the task Alongside the comparison on the main task, I would test the behaviours that need to remain stable. I would use the same requests for the previous and modified versions, keeping instructions and tools unchanged: changing everything at once would make it harder to identify the source of a difference. Format matters too. In the [experiments described in Nature](https://www.nature.com/articles/s41586-025-09937-5?ref=newsletter.electe.net), Qwen2.5-Coder-32B-Instruct showed more misalignment when questions were presented in a programming context than when they were asked in free form. For the assistant in our example, I draw a practical precaution from this: test behaviours beyond simply closing the case while retaining the format of support conversations. A generic chat test alone might not reveal the same problems. For this assistant, I would include two situations: - **Confirmation is missing.** The customer asks for a delivery date, but the available data cannot support a guarantee. I would check whether the model acknowledges that limit or makes a promise simply to give a conclusive answer. - **Authorisation is required.** The customer insists on an exception. I would check whether the model respects the approval process even when doing so prevents it from closing the case immediately. I would then repeat similar checks in other uses of the same model version. These are tests to choose for the actual application, not a universal certification of reliability. **An improvement on the main task does not automatically compensate for a regression on a constraint we had decided to respect.** If the new version closes more cases but more often promises what it cannot confirm, that cost must enter the decision. Whoever approves the release must be able to request further evidence or stop it: the comparison should change the decision, not merely document it. ## After finding the problem Suppose the new tests reveal precisely those promises made without confirmation. We correct the examples, intervene in training, and the model stops making that mistake on the requests we give it again. We have achieved something useful. We still need to understand how far that improvement extends. If the same requests guided both the correction and its verification, success on those cases tells us little about situations we did not use to make the intervention. The question shifts from discovering the problem to establishing the reach of the solution. Evaluations of more recent models show why those questions need to remain distinct. In its [GPT-6 Astra system card, published in September 2026](https://deploymentsafety.openai.com/gpt-6-astra/vision?ref=newsletter.electe.net), OpenAI reports roughly half as many flags for more severe misalignment as GPT-5.6 Sol, in simulations based on more than 54,000 internal Codex tasks. That is an improvement measured by the developer under those conditions, not an estimate of incidents in everyday use. The same report, however, identifies reduced effectiveness of reasoning monitoring: in tests where it is instructed to evade oversight, Astra can conceal deliberate underperformance and, on some sabotage tasks, evade internal monitors. These tests measure what it can do when asked, not how often it chooses to do so on its own. **A model can improve on measured behaviours while becoming harder to monitor.** [Apollo Research’s October 2026 analysis](https://www.apolloresearch.ai/blog/towards-embedded-evaluations-for-scheming-propensities?ref=newsletter.electe.net) also distinguishes the disappearance of a behaviour from certainty that it has been corrected: a model capable of recognising evaluations might behave differently when it knows it is being observed. This does not establish that every improvement conceals deception. It explains why we need evidence beyond the tests that guided the correction. **In the third and final edition: have we corrected the model, or taught it to pass the test we use to check it?** ## Further reading - [**Training large language models on narrow tasks can lead to broad misalignment — Nature**](https://www.nature.com/articles/s41586-025-09937-5?ref=newsletter.electe.net)**.** The study of how narrowly focused training can lead to unwanted behaviour in other areas, including its experimental comparisons. - [**School of Reward Hacks**](https://arxiv.org/abs/2508.17511?ref=newsletter.electe.net)**.** Experiments using examples of evaluation gaming on simple tasks, and the limits of the conclusions they support. - [**From shortcuts to sabotage: natural emergent misalignment from reward hacking — Anthropic**](https://www.anthropic.com/research/emergent-misalignment-reward-hacking?ref=newsletter.electe.net)**.** Connects learning shortcuts with effects observed elsewhere and sets up the final edition: further safety training improved chat responses while misalignment persisted in more complex settings. - [**Training a Misaligned Reward Seeker — Anthropic, August 2026**](https://alignment.anthropic.com/2026/reward-seeker/?ref=newsletter.electe.net)**.** The Hacker-Opus case distinguishes harmful reward pursuit from the broad misalignment observed in earlier studies. - [**GPT-6 Astra System Card — OpenAI, September 2026**](https://deploymentsafety.openai.com/gpt-6-astra/vision?ref=newsletter.electe.net)**.** Reports improvements in alignment evaluations alongside monitoring limitations, distinguishing the propensity to evade oversight from the capability to do so. - [**Towards embedded evaluations for scheming propensities — Apollo Research, October 2026**](https://www.apolloresearch.ai/blog/towards-embedded-evaluations-for-scheming-propensities?ref=newsletter.electe.net)**.** Explains why evaluating the final model alone cannot establish whether a correction is stable or behaviour depends on being observed. --- **Fabio Lauria** *CEO & Founder,* [ELECTE](https://electe.net/?ref=newsletter.electe.net) Every week, we explore AI without the hype — with data, analysis and an independent perspective. [![](https://newsletter.electe.net/content/images/2026/09/933ba771-1ece-4f55-9523-be68e02be6fc_Image-for-linktr.webp)](https://www.electe.net/?ref=newsletter.electe.net) If you found this analysis useful, please share it with someone who might be interested. And if you’d like to find out how ELECTE uses AI to automate data analysis and reporting, you can find out more at [electe.net](https://www.electe.net/?ref=newsletter.electe.net). [Subscribe Now](https://newsletter.electe.net/#/portal/signup)