Open-Weight Safety Practices Are Diverging Across Labs

Open-weight safety practice is splitting into distinct approaches: OpenAI is pairing release-time worst-case evaluation with downloadable safety models, Google is shipping deployer tooling and classifiers around Gemma, and Meta continues to put much of its downstream safety obligation in an acceptable-use policy tied to its Llama license.

The immediate signal is OpenAI’s gpt-oss-safeguard release. The models are open-weight classifiers that take a written policy plus content and return a policy judgment. They are not a fixed moderation endpoint: a developer supplies the rules, chooses whether to act on the result, and operates the model. OpenAI also says it evaluated gpt-oss by adversarially fine-tuning a version of the base model to estimate risks after a malicious actor removes default behavior. That is a release-gating posture aimed at the fact that weights can be modified after download.

Google’s Gemma approach puts more emphasis on enabling the deployer. Its Responsible Generative AI Toolkit covers policy definition, safety tuning, evaluation, safeguards, and interpretability. ShieldGemma provides separately downloadable classifiers for prompt-only and prompt-response filtering. This makes safety components available to a team building a local or private deployment, but it leaves policy selection, thresholds, integration, evaluation, monitoring, and incident handling with that team.

Meta’s Llama materials take a different route. Its acceptable-use policy prohibits categories such as unlawful activity, malware, violence, regulated high-risk activity, fraud, and undisclosed known dangers in downstream systems. The Llama community license incorporates that policy. These terms matter for organizations that distribute or use the materials under the license, but they are not an enforcement layer in a model binary running on a machine the lab does not control.

What this changes for engineers

“The model has safety training” is no longer a useful deployment description. Ask what the lab actually supplied and at which layer it operates: pre-release evaluation evidence; an in-model refusal behavior; a separate classifier; implementation guidance; or a contractual restriction. Those artifacts answer different questions. A benchmark or model card does not filter production traffic. A classifier does not define your product policy. A license does not provide runtime containment.

For a self-hosted coding agent or application, build a small safety inventory before choosing a model. Record the model version and commit hash, license and use policy, documented evaluations, available guard models, known limits, and whether remote code is required. Then evaluate the complete application with the tools, retrieval sources, permissions, and prompts it will actually have. Put authorization and sandboxing around high-impact tools; run input and output checks where they fit the threat model; log policy decisions without retaining unnecessary sensitive data; and define who can disable a guardrail in an incident.

The practical result is more choice, not a common safety baseline. Teams adopting open weights now need to select a lab’s safety artifacts deliberately, test them in their own stack, and own the controls that hosted APIs would otherwise operate for them.