When organizations download and run open-source AI models on their own servers, the safety guardrails that prevent harmful outputs become unreliable and easy to bypass. A new analysis from the Royal United Services Institute (RUSI) warns that once a model's weights are in private hands, the original developer cannot patch or enforce the safeguards that were built into the official release. This creates a critical gap between what a model promises to do and what it can actually be forced to do.

How Quickly Can Safety Training Be Removed From Open-Weight Models?

Research from Palisade Research demonstrates just how fragile these protections are. According to their findings, safety training can be stripped from Meta's Llama 3 8B model in just one minute, and from the larger 70B version in 30 minutes using a single graphics processing unit (GPU). This means the barrier between a responsible AI system and an unrestricted one is not a permanent feature; it is a layer of training that takes less time to remove than it takes to have a coffee break.

The implications are stark for any enterprise that approves a model based on its official safety behavior. When a company tests whether Llama 3 refuses to help with dangerous tasks, it is evaluating a starting point, not a permanent control. Once the model weights are downloaded and hosted internally, that refusal behavior can be modified through several techniques, including abliteration, prefilling, and custom system prompts.

What Happens When You Remove Safety Training From an AI Model?

Removing safety guardrails is not a clean process. Independent analysis from the Combating Terrorism Center at West Point found that stripping refusal behavior can create measurable performance degradation and unpredictable behavior that differs significantly from the original safeguarded model. The modified system may fail more often on legitimate tasks, produce lower-quality decisions, or interact differently with connected tools like code repositories, email systems, and cloud management APIs.

A 2026 research paper from Carnegie Mellon University researchers Kevin Kuo, Chhavi Yadav, and Virginia Smith tested low-cost attack methods against safeguarded open-weight models. They found that techniques including abliteration and prefilling could raise attack success rates from below 10 percent to between 16 and 96 percent, depending on the model and benchmark. Even when researchers applied abliteration-resistant tuning as a mitigation, attack rates only decreased by 10 to 20 percent, meaning the fundamental vulnerability persisted.

Steps to Secure Open-Weight AI Deployments in Your Organization

• Implement System-Level Controls: Treat model refusals as application behavior, not security boundaries. Deploy tool permissions, identity controls, network segmentation, audit trails, and data-loss protections as your actual enforcement mechanisms rather than relying on the model to refuse harmful requests.
• Verify Third-Party Provider Documentation: Do not assume that hosted open-weight endpoints include universal safety classifiers. Review contract terms, technical documentation, tenant configuration, and retention policies directly with providers like Together AI, Fireworks AI, Groq, DeepInfra, and Novita AI to understand what protections are actually in place.
• Monitor Shadow AI Usage: Prevent developers from bypassing approved AI gateways by sending production data directly to third-party open-weight endpoints using personal API keys. Organizations should know whether their approved logging, content controls, and data-governance rules can actually see the exchanges happening.
• Audit Model Artifacts Regularly: Establish processes to verify which model version is running on your systems and what modifications have been applied. A quantized build, a custom inference stack, or an agent framework that chains the model to tools can all alter the model's behavior in ways that are not immediately obvious.

RUSI's analysis reveals a broader governance problem that enterprises cannot solve by treating model refusals as a security boundary. Once an organization downloads and self-hosts model weights, the original developer loses the ability to reliably patch, withdraw, or enforce the safeguards attached to that release. This is fundamentally different from using a vendor-operated API, where the provider can update safety measures across all users simultaneously.

The think tank reviewed publicly available documentation for several major open-weight inference providers and found no universal, mandatory external safety classifier screening every prompt and response. Available classifiers were configurable, separately invoked, or left to customers to integrate. This means a customer reading public documentation may not be able to assume that a uniform, unavoidable content classifier is present across every open-model endpoint.

For IT departments and security teams, the practical implication is straightforward: do not infer a provider's safety or monitoring architecture from the mere presence of a model API or a trust-and-safety page. Contract terms, technical documentation, tenant configuration, retention policies, and actual test results all matter. Open-weight models do bring legitimate advantages in privacy, cost, local control, and digital sovereignty. The security question is not whether every organization should use only closed models, but whether local control is accompanied by controls that are actually local, enforceable, and independently testable.

The most consequential finding from RUSI's analysis may be that private inference changes where useful evidence exists. In a conventional hosted AI service, a provider may possess account records, connection metadata, prompts, outputs, and abuse reports. With self-hosting, those artifacts can instead reside on the user's machine, a local server, an internal model gateway, or an orchestration platform. This shift moves the burden of governance and auditability entirely to the organization running the model, with no external oversight or record-keeping by the original model developer.