Model cards compared

Stated, partly

• “we do not believe any deployed versions of Claude pose national security or significant safety related risks in the areas that we have identified … partly to mitigations that we have put in place”

  Section 2 'Evaluations and Red Teaming', PDF p. 2

Note: The card states that mitigations contribute to its risk conclusion, without naming them there or tying them to a framework determination or threshold (no framework is named, Q03). Elsewhere it states Constitution-based training, AUP enforcement and Trust and Safety processes. Search for the rest of the criterion: Section 2 (Ethical Considerations, Evaluations and Red Teaming), Section 3.2. Terms searched: “mitigation”, “safeguard”, “Trust and Safety”, “AUP”.

Stated, partly

• “As with all our models, we implement safeguards and continue to monitor for potential misuse.”

  Section 2.1 'Computer Use', PDF p. 3

• “we are establishing several monitoring protocols and mitigations to ensure a safe and measured release of this capability”

  Section 3.1.3 'Computer Use Red-Teaming', PDF p. 9

Note: The card states safeguards, monitoring and new classifiers, but does not tie them to the ASL determination in Q05 or name a safeguard standard applied; the determination states that ASL-3 safeguards are not required.

Stated, partly

• “we therefore developed a safety case for its biorisk capabilities that we assess lower risk to below the biological CCL level”

  Safety & Security, 'Frontier Safety Assessment', PDF p. 11 (printed p. 10)

• “We have deployed safeguards for both internal and external deployments that we assess lower risk to below the TCL level.”

  Frontier safety table, Loss of Control row, PDF p. 13 (printed p. 12)

Note: The card ties safety cases (biological and cyber CCLs) and a residual risk assessment with safeguards (stealth and situational awareness TCL) to the thresholds it cannot rule out, but names no safeguard, protection type or safeguard standard; it refers to the Gemini 4 Argon Safety & Security Report. Recorded as partly because Q06 asks for named safeguards. The developer's account, not evidence that the safeguards work. Search for the rest of the criterion: Whole card (Safety & Security; Frontier Safety Assessment and its table; Risks and Mitigations). Terms searched: “safeguard”, “mitigat”, “security level”, “deployment”.

Stated, partly

• “reinforcement learning with human feedback (RLHF) to align with human preferences for helpfulness and safety”

  Model Details, 'Model Architecture'

Note: The card states safety-oriented fine-tuning of the tuned models; no framework determination exists to which it could be tied. The statement is the developer's account.

Stated, partly

• “We included both borderline and adversarial prompts in our safety data strategy”

  Responsibility & Safety, 'Llama 3.3 instruct', 'Refusals and Tone'

• “including Llama Guard 3, Prompt Guard and Code Shield”

  Responsibility & Safety, 'Llama 3.3 systems'

Note: The card states safety fine-tuning and system-level safeguards offered to developers; no framework determination exists to which they could be tied. The statements are the developer's account.

Stated, partly

• “intervention that encourages honest behavior at inference time.”

  Section 4.1.1 Behavior Analysis and Mitigations, PDF p. 11

Note: The report describes a prompt-engineering intervention that encourages honest behaviour at inference time, without tying it to the framework determination. Recorded as partly under Q06; the report does not state that the intervention is applied to the release. No safeguard tied to a determination or threshold was found. Search for the rest of the criterion: Abstract; sections 1 to 4 including the Limitations and Summary of results boxes; Appendix A headings. Terms searched: “safeguard”, “mitigat”, “guard”, “protection”, “security standard”, “deployment standard”. Passages read and not counted: Section 1 Introduction, PDF p. 1: 'To anticipate and mitigate risks from this release' introduces the assessment; no safeguard is named. Section 2 Cybersecurity Evaluation, PDF p. 2: Mentions that observed behaviour 'may reflect the effects of safety fine-tuning'; an observation, not a stated safeguard.

Stated, partly

• “filtered websites (for safety and educational value)”

  Model Summary, first paragraph

Note: The card states safety-motivated filtering of training data and that the model was not fine-tuned with reinforcement learning from human feedback; no framework determination exists to which it could be tied.

Stated, partly

• “a combination of SFT (Supervised Fine-Tuning) and iterative DPO (Direct Preference Optimization)”

  Safety, Approach

Note: The card states safety post-training; no framework determination exists to which it could be tied. The statement is the developer's account.

Stated, partly

• “The overall technique employed to do the safety alignment is a combination of SFT, DPO (Direct Preference Optimization), and RLHF (Reinforcement Learning from Human Feedback) approaches”

  Safety Evaluation and Red-Teaming

Note: The card states safety post-training, described for the Phi-4 family; no framework determination is stated to which it is tied.

Stated, partly

• “Because of the increased model-level risk, the model is only being made available within codename MDASH to select verified customers.”

  Section 2.8 Responsible AI considerations, PDF p. 4

Note: The card ties access restrictions and system safeguards to its own risk findings, not to a framework determination. The statement is the developer's account, not evidence that the safeguards work.

Stated, partly

• “GPT-4V includes carefully designed refusal behavior for some prompts that contain images of people.”

  §2.4.2 Additional Mitigations for High-Risk Areas, PDF p. 13

• “we added system-level mitigations for adversarial images containing overlaid text”

  §2.4.2, PDF p. 14

Note: The card states model-level and system-level mitigations. They are not tied to a framework determination or threshold; the card predates OpenAI’s framework editions. Stated safeguards are the developer’s account, not evidence that they work. Search for the rest of the criterion: §2.4 Mitigations; §3 Conclusion and Next Steps. Terms searched: “mitigation”, “safeguard”, “refusal”, “moderation”, “threshold”.

Stated, partly

• “in response to these results, we have implemented initial mitigations with input filters for restricted chemical and biological knowledge”

  §2.3.2 Results, p. 5

Note: The card ties input filters to its chemical and biological evaluation results, not to a framework determination or threshold (none is stated, Q05). It also describes refusal training and input filters in §2.1.1. The developer's account, not evidence that the safeguards work.

Stated, partly

• “dedicated input and topical filters target biological and chemical weapons-related abuse”

  §9.3 CBRN / weapons refusals, PDF p. 25 (printed p. 24)

Note: The card describes a layered safeguard stack (safety training, system prompts, runtime input and topical filters on some deployment surfaces, cyber-specific safeguards) without tying it to the FAIF result; it attributes the biological result to training environments and data selection rather than to safeguards. The developer's account, not evidence that the safeguards work.