Company · Company explainer
How our safety risk levels work
The published AI Safety Framework describes four risk levels. Here is how to read the escalation and release controls without confusing a policy with a test result.

On this page
THE ESSENTIALS
- The source policy defines four levels: minimal, moderate, high, and critical risk.
- Controls and release authority escalate with the assigned level.
- A risk classification does not by itself prove that a system is safe.
Company explainer
What the source actually says
The AI Safety Framework currently published in the policy suite defines four levels. Level 1 is minimal risk, Level 2 moderate risk, Level 3 high risk, and Level 4 critical risk. This explainer follows that source rather than the earlier five-level wording on the homepage. [1]
The framework describes a progression of evaluation, review, access restrictions, and release controls. These are policy requirements. Assigning a level is not a substitute for the supporting assessment, and a description of a required control is not evidence that a particular product has passed it.
Company explainer
How the controls escalate
The source describes standard evaluation and product-level approval at Level 1; fuller safety evaluation and internal red teaming at Level 2; external red teaming, restricted access, and governance approval at Level 3; and a paused release pending mitigation with heightened approval requirements at Level 4. See the complete policy for its conditions and review cadence. [1]
| Level | Classification in the policy | Illustrative control summary |
|---|---|---|
| 1 | Minimal risk | Standard evaluation and product-level approval |
| 2 | Moderate risk | Fuller evaluation and internal red teaming |
| 3 | High risk | External red teaming, restricted access and governance review |
| 4 | Critical risk | Release paused pending mitigation and heightened approval |
Company explainer
The evidence behind a decision matters
A meaningful release decision needs to connect the intended use of a system with its evaluated capabilities and risks. The related Safety Evaluation, Red Teaming, and Human Oversight policies describe further parts of that process. A reader should look for what was tested, under which conditions, what failed, and who is responsible for follow-up. [2, 3, 4]
An evaluation report can support a bounded conclusion. It should not be stretched into a claim that a model is safe for every environment or that all future risks have been eliminated. The same care applies when reading a concise company update.
Company explainer
A clarification, not a new evaluation result
This article clarifies the policy currently presented on the website. It does not report a completed safety assessment, assign a risk level to a new model, or announce a release approval. The full documents remain the appropriate place to inspect scope, exceptions, responsibilities, and reporting routes.
This is a policy-based company explainer, not a verified import from Threads.
A CLOSER LOOK
Ask this article.
Ask a question to find passages and their references. Answers are extracted from this article; no live AI model is connected.
READ THE ORIGINAL WORK
Sources & references
Sources reviewed 20 October 2026. Papers describe their own models and experiments; our proposed experiments are identified separately.
- 1AI Safety Framework, document 24 ↗
WEBSPACEAI published policy suite · Document content reviewed 20 October 2026
WEBSPACEAI policy suite - 2Safety Evaluation Policy ↗
WEBSPACEAI published policy suite · Document content reviewed 20 October 2026
WEBSPACEAI policy suite - 3Red Teaming Policy ↗
WEBSPACEAI published policy suite · Document content reviewed 20 October 2026
WEBSPACEAI policy suite - 4Human Oversight Policy ↗
WEBSPACEAI published policy suite · Document content reviewed 20 October 2026
WEBSPACEAI policy suite



