When organizations adopt open-weight AI models to keep data private, they gain control over their infrastructure but lose a critical safety guarantee: the ability to enforce refusals built into the original model. A growing body of research shows that safety features in open-source large language models (LLMs), which are AI systems trained on vast amounts of text to understand and generate human language, can be removed or circumvented far more easily than most procurement teams realize, creating a governance challenge that cloud-based APIs do not present.

The distinction matters because it reshapes where security responsibility actually lies. When an enterprise uses a vendor-operated API, the vendor controls the model running on their servers. When that same enterprise downloads an open-weight model like Meta's Llama 3 to run locally, it gains a copy it can modify, fine-tune, or alter in ways the original creators cannot prevent or even detect.

How Quickly Can Safety Training Be Removed From Open Models?

Research from Palisade Research demonstrates the speed and ease of the problem. According to their findings, safety training can be stripped from Llama 3 8B, a moderately sized model, in approximately one minute on a single graphics processing unit (GPU), a specialized processor designed for handling large computational tasks. The larger Llama 3 70B model, which contains 70 billion parameters or adjustable weights, takes roughly 30 minutes to modify in the same way.

The practical implication is stark: the cost and effort required to alter an open-weight model's behavior are trivial compared with the cost of training or deploying one. An enterprise that approves a model because its official version refuses dangerous requests has therefore approved a starting point, not a permanent control.

A 2026 research paper from Carnegie Mellon University researchers Kevin Kuo, Chhavi Yadav, and Virginia Smith reached a similarly uncomfortable conclusion through systematic testing. Their work found that low-cost attack methods, including abliteration (a technique that removes specific safety training) and prefilling (seeding the model with particular text patterns), could raise attack success rates against safeguarded open-weight models from below 10 percent to between 16 and 96 percent, depending on the model and the specific benchmark used.

What Makes Model-Level Refusals Unreliable in Self-Hosted Deployments?

The traditional approach to evaluating model safety is behavioral: ask the model for a disallowed task and see whether it refuses. This testing is useful for initial procurement decisions, but it reveals little about whether the same safety behavior survives modification.

Once an organization controls the model artifact itself, that safety behavior can be altered through several pathways:

• Modified Checkpoints: Saving and reloading the model at different training stages can bypass safety fine-tuning applied at the end of training.
• Custom Fine-Tuning: Retraining the model on new data can overwrite or dilute safety constraints without retraining the entire model from scratch.
• System Prompts: Changing the initial instructions given to the model can override built-in refusals through clever prompt engineering.
• Quantization: Converting the model to use lower-precision numbers for faster inference can sometimes degrade safety mechanisms as a side effect.
• Custom Inference Stacks: Using different software frameworks to run the model can expose or amplify vulnerabilities in safety training.
• Agent Frameworks: Chaining the model to external tools or databases can create workarounds that bypass direct refusals.

The Carnegie Mellon researchers proposed a mitigation called abliteration-resistant tuning, which adds additional safety training specifically designed to resist these attacks. However, their testing found it reduced attack success rates by only 10 to 20 percent; it did not eliminate the problem.

This is the operational reality that security teams and administrators must plan around. Model-level refusals can reduce ordinary misuse, but they cannot be the sole enforcement point when the organization or its contractors can change the model artifact itself.

How Should Organizations Approach Governance of Self-Hosted Models?

The shift from vendor-operated APIs to self-hosted open-weight models transfers governance responsibility in ways that many organizations do not fully anticipate. A model's safety alignment is generally evaluated as behavior during procurement, but that says little about whether the same behavior survives deployment in a modified form.

For organizations adopting local models to keep prompts and data out of public AI services, this creates a new burden: proving not just that access to the model is controlled, but that the model running in production is the approved version and that it is permitted to do what it is actually doing.

The underlying challenge is that open weights are durable artifacts. A lab can issue a safer revision of a model, but it cannot recall copies already on servers, workstations, cloud tenants, or third-party inference platforms. Once distributed, the model becomes the responsibility of whoever is running it, not the creator.

This distinction is often obscured in AI procurement conversations, where safety is discussed as a fixed property of the model rather than a property of the specific deployment and the controls surrounding it. As more enterprises move toward self-hosted and private AI infrastructure, the gap between what a model is approved to do and what it can actually be made to do will likely become a central concern for security, compliance, and legal teams.