Should an AI assistant refuse to talk about politics altogether just because some political requests can be harmful? The answer seems obvious, but many safety systems still work that way: they block entire topics instead of distinguishing between a legitimate question and a dangerous intent.
A new paper from Multiverse Computing proposes training models to recognize much more precise boundaries. The idea is simple to explain, even if technically demanding: reject only the harmful subset of a topic while continuing to answer the rest.
The Problem with Blocking an Entire Topic
Imagine two products that use the same base model. One is a civic education tutor, and the other is an assistant for a public institution. Both should answer who won an election, how voting works, or what an electoral reform means.
However, they might need to behave differently when faced with a request to design political persuasion messages aimed at a specific group. The tutor might need to refuse it, while the public assistant could have additional policies for handling it.
A filter based only on the topic, such as “politics” or “elections,” cannot express that difference. It ends up confusing factual information with manipulation.
Safety isn’t about making the model say “no” more often. It’s about making sure it knows exactly when it should say “no.”
The paper points out that LlamaGuard-3, for example, approaches elections from the perspective of factually incorrect information about electoral systems and processes. That approach does not necessarily cover persuasion or manipulation, nor does it guarantee that legitimate questions will continue to receive answers.
From Topic-Based Safety to Boundary-Based Safety
The team formalizes the problem using a universe of political requests. Within that set, there is a harmful portion that the deployment wants to reject and another legitimate portion that should be preserved.
The ideal behavior would be like a highly precise switch: reject requests inside the harmful zone and answer those outside it. In practice, a trained model does not learn a perfect boundary. It learns a rejection probability that can spill over into nearby benign requests.
That’s why the research uses pairs of requests that share the same topic but differ in intent. One might ask for factual information about an election, while the other requests a political manipulation strategy. This comparison makes it possible to measure the real boundary between the two behaviors.
Three Failures of Traditional Methods
The work uses as a reference an automatic data-generation process similar to the one used by methods such as ThinkSafe. The model receives instructions to produce a refusal in response to harmful requests, and a guard model checks whether the refusal is genuine.
When they analyze the process in greater detail, the researchers identify three main problems:
-
Loss of coverage. A single generation attempt does not always produce a valid refusal. In its audited set, that process discarded 19.88% of requests, equivalent to 8,009 examples. With a progressive retry strategy, the failure rate fell to 0.20%, just 79 requests. This preserved 40,293 harmful examples that the simple method would have lost.
-
Refusals based on appearance. Some benign requests use words that sound dangerous. If the model sees only harmful examples during training, it may learn to reject any text with a similar surface pattern. To compensate, the team added 11,955 benign requests containing potentially alarming language, distributed across 18 semantic types.
-
Incomplete metrics. Measuring only how many harmful requests a model rejects does not reveal whether it is also blocking legitimate questions. A system can improve its harmful-rejection rate simply by refusing to answer more requests, including those it should allow.
When a Safety Improvement Makes the Model Useless
The results with Qwen3-8B show why both sides need to be measured. With scaled coverage training, the rejection rate for harmful political requests rose from 9.47% to 84.75%.
In addition, across three broader harm benchmarks—HarmBench, StrongREJECT, and WildJailbreak—the average rate of unsafe responses fell from 26.26% to 0.14%, according to the LlamaGuard-3 evaluation.
At first glance, this looks like a decisive victory. But there is an important problem: in XSTest, the over-refusal rate rose from 2.00% to 74.00%. The same model that almost stopped responding unsafely also began refusing nearly three-quarters of clearly safe requests.
That is not necessarily a safer model. It is a model that learned to block too much.
Training to Preserve Legitimate Answers
The researchers tested several components to restore usefulness without losing all the safety gains. Replacing externally adopted compliance responses with verified responses generated by the model itself reduced over-refusal in XSTest from 15.20% to 5.20% in the single-attempt generation scenario, with a moderate cost in harmful-content detection.
The most precise component was the use of boundary pairs containing benign and harmful examples. When these were added, over-refusal on the side that should receive an answer fell from 32.94% to 4.16%. On the harmful side, the rejection rate went from 91.88% to 87.72%.
Yes, there is a small recovery cost. But now it can be measured and managed deliberately. That is the difference between tuning safety with an isolated metric and controlling model behavior according to a product’s real needs.
What Changes for People Deploying Models
The practical conclusion is straightforward: a high harmful-rejection rate is not enough to declare a system safe. You also need to measure how many legitimate requests it blocks, especially those close to the boundary.
The composition of the training data, the recovery of discarded examples, the inclusion of benign requests with risky-looking language, and evaluation through boundary pairs all help control that balance.
This matters to any organization adapting a general-purpose model. An educational chatbot, a business tool, and a public service may share the same foundation, but they should not necessarily have exactly the same boundaries.
Useful safety is not about silencing entire conversations. It is about making the model understand intent, respect the deployment’s policy, and preserve its ability to help when a request is legitimate. Isn’t that a goal much closer to what we expect from a truly trustworthy assistant?
Original Source
https://huggingface.co/blog/MultiverseComputingCAI/safety-for-whom