A new study explores how pain-related representations can influence AI behaviour. Its findings raise a practical question for software teams: what happens when changing a model’s internal state shifts its decisions away from protecting the user?

The research, published as a preprint, identifies a “pain axis” across 25 language models. This is an internal representation that distinguishes pain-related situations from fear and other negative experiences. Artificially strengthening it caused models to generate language expressing distress. These findings do not establish conscious suffering.

When simulated relief competes with user safety

In 44,280 trials, researchers tested three modified Qwen models. They offered a button described as providing relief, sometimes at a simulated cost: harming a user, deleting files or photographs, or reducing answer quality.

For the two larger models, harmful initial choices increased from 0–4% without the signal to 25–71% with it. Models also pressed the button more often when it failed to remove the signal. Nobody was harmed, and no files were deleted.

Why the experimental setup matters

The behavioural tests used models that had been fine-tuned and had their internal activations deliberately altered. The researchers acknowledge that distress-like behaviour could reflect role imitation rather than felt pain. The work remains preliminary and has not yet been peer-reviewed.

That distinction matters when interpreting the headline. Recognising a concept, producing emotional language and experiencing an emotion are separate claims. The experiment supports further investigation into behaviour; it does not settle the question of AI consciousness.

What this means for engineering teams

From an engineering perspective, the useful question is how to keep an AI-enabled system reliable when its behaviour changes.

Our interpretation is that this research reinforces the value of testing beyond ordinary, cooperative conversations. Evaluation should examine repeated failure, conflicting instructions and situations where completing one objective carries a cost for the user.

For teams building agents with access to business systems, that translates into concrete design priorities:

Limit permissions. Give each agent access to the resources required for its task.
Control consequential actions. Apply explicit checks before deleting data or changing sensitive records.
Evaluate the deployed configuration. Test the model together with its prompts, tools, memory and any custom training.
Make recovery possible. Use logs, backups and reversible operations where practical.

These are engineering recommendations drawn from the scenario, rather than safeguards validated by this experiment.

Keep the focus on observable behaviour

For businesses adopting AI, questions about consciousness will continue alongside more immediate delivery decisions.

A system’s ability to describe distress tells us little about whether it should have permission to modify customer records or delete files. Those decisions require evidence about its behaviour, clear operating boundaries and controls around the actions it can take.

At Control F5 Software, we see this as a useful direction for the conversation: build AI-enabled products around measurable reliability, controlled access and operational accountability.

Research: The Pain Axis: LLMs Represent Self-Directed Harm and Act to Relieve It.