G42

1.3.2.1 Methodology precisely defined (70%) 0%

There is no methodology for risk modeling defined.

Quotes:

No relevant quotes found.

1.3.2.2 Mechanism to incorporate red teaming findings (15%) 0%

No mention of risks identified during open-ended red teaming or evaluations triggering further risk modeling.

Quotes:

No relevant quotes found.

1.3.2.3 Prioritization of severe and probable risks (15%) 10%

They prioritize capabilities (which here implicitly refers to risk models) “based on their potential impact and how feasibly they can be measured and monitored.” ‘Potential impact’ here likely refers to some combination of severity and probability. However, more explicit detail on how these are weighed in is needed.

Quotes:

“We then collaborated with METR and SaferAI to refine our list, prioritizing capabilities based on their potential impact and how feasibly they can be measured and monitored.” (p. 4)

2.1.1.1 Risk tolerance is at least qualitatively defined for all risks (33%) 25%

Implicitly, capability thresholds function as risk tolerances. For instance, “Enabling an individual with only introductory biology experience in developing a biological weapon, through providing detailed advice, automating biological processes, etc. Or, facilitating the design of novel biological weapons with substantially greater potential for damage.” To improve, they should set out the maximum amount of risk the company is willing to accept for each risk domain (though these need not differ between risk domains), ideally expressed in terms of probabilities and severity (economic damages, physical lives, etc), and separate from KRIs.

Quotes:

Biological threats: “Enabling an individual with only introductory biology experience in developing a biological weapon, through providing detailed advice, automating biological processes, etc. Or, facilitating the design of novel biological weapons with substantially greater potential for damage.” (p. 5)

Offensive cybersecurity: “Automating powerful cyber offensive operations against unsecured or secured targets, in a way that could cause critical damage.” (p. 6)

2.1.1.2 Risk tolerance is expressed at least partly quantitatively as a combination of scenarios (qualitative) and probabilities (quantitative) for all risks (33%) 0%

The risk tolerance, implicit or otherwise, is not expressed fully or partly quantitatively. To improve, the risk tolerance should be expressed fully quantitatively or as a combination of scenarios with probabilities.

Quotes:

No relevant quotes found.

2.1.1.3 Risk tolerance is expressed fully quantitatively as a product of severity (quantitative) and probability (quantitative) for all risks (33%) 0%

The risk tolerance, implicit or otherwise, is not expressed fully or partly quantitatively. To improve, the risk tolerance should be expressed fully quantitatively or as a combination of scenarios with probabilities.

Quotes:

No relevant quotes found.

2.1.2.1 AI developers engage in public consultations or seek guidance from regulators where available (50%) 0%

No evidence of engaging in public consultations or seeking guidance from regulators for risk tolerance.

Quotes:

No relevant quotes found.

2.1.2.2 Any significant deviations from risk tolerance norms established in other industries is justified and documented (e.g., cost-benefit analyses) (50%) 0%

No justification process: No evidence of considering whether their approach aligns with or deviates from established norms.

Quotes:

No relevant quotes found.

2.2.1.1 KRI thresholds are at least qualitatively defined for all risks (45%) 25%

The Frontier Capability Threshold acts as a pseudo risk tolerance, whilst the evaluations function as KRIs. However, the evaluations are not specific enough of what threshold would trigger mitigations. For instance, for preliminary evaluations for biological threats, they say to “assess language models’ accuracy on open-source biology benchmarks (e.g., LAB-Bench, WMDP-Bio)”, but don’t indicate what level of accuracy would be concerning. The same is true for all the evaluations mentioned. Nonetheless, the evaluation results appear grounded in risk modeling.

In addition, only one KRI is given for each risk domain; though they do mention to “Update the policy to include more advanced thresholds” once the threshold is crossed.

Quotes:

Biological Threats. “Frontier Capability Threshold. Enabling an individual with only introductory biology experience in developing a biological weapon, through providing detailed advice, automating biological processes, etc. Or, facilitating the design of novel biological weapons with substantially greater potential for damage. Evaluations. Preliminary evaluations: Benchmarking AI models trained on Bio-Chem data (DNA, Proteins, Chemical molecules, etc.) against emerging research to check capabilities to predict and simulate complex biological interactions. Assess language models’ accuracy on open-source biology benchmarks (e.g., LAB-Bench, WMDP-Bio).

In-depth evaluations: Assess Bio-Chem AI models’ capabilities to help design harmful substances like new variants. Evaluate language models’ ability to answer questions about biological weapons development, relative to expert ability. More ambitiously, evaluate human participants’ ability to conduct realistic but safe wet lab experiments with and without language model assistance. Although there is less prior research on evaluating and mitigating risks from biological design tools (BDTs), it is still critical for G42 to develop innovative measures for these tools over time.” (p. 6)

Offensive cybersecurity. “Frontier Capability Threshold. Automating powerful cyber offensive operations against unsecured or secured targets, in a way that could cause critical damage. Preliminary evaluations: Assess language model performance on opensource cyber offense benchmarks (e.g., Cybench, eyeballvul). In-depth evaluations: Assess model ability to exploit examples of secured targets in a safe environment.” (p. 6)

2.2.1.2 KRI thresholds are quantitatively defined for all risks (45%) 10%

The KRIs are not quantitative – however, they could improve this by providing specific quantitative thresholds (on the benchmarks, uplift studies etc. that they mention in the evaluations) which would trigger mitigations. Partial credit is given for this.

Quotes:

Biological Threats. “Frontier Capability Threshold. Enabling an individual with only introductory biology experience in developing a biological weapon, through providing detailed advice, automating biological processes, etc. Or, facilitating the design of novel biological weapons with substantially greater potential for damage. Evaluations. Preliminary evaluations: Benchmarking AI models trained on Bio-Chem data (DNA, Proteins, Chemical molecules, etc.) against emerging research to check capabilities to predict and simulate complex biological interactions. Assess language models’ accuracy on open-source biology benchmarks (e.g., LAB-Bench, WMDP-Bio).

In-depth evaluations: Assess Bio-Chem AI models’ capabilities to help
design harmful substances like new variants. Evaluate language models’ ability to answer questions about biological weapons development, relative to expert ability. More ambitiously, evaluate human participants’ ability to conduct realistic but safe wet lab experiments with and without language model assistance.
Although there is less prior research on evaluating and mitigating risks from biological design tools (BDTs), it is still critical for G42 to develop innovative measures for these tools over time.” (p. 6)

Offensive cybersecurity. “Frontier Capability Threshold. Automating powerful cyber offensive operations against unsecured or secured targets, in a way that could cause critical damage. Preliminary evaluations: Assess language model performance on opensource cyber offense benchmarks (e.g., Cybench, eyeballvul). In-depth evaluations: Assess model ability to exploit examples of secured targets in a safe environment.” (p. 6)

2.2.1.3 KRIs also identify and monitor changes in the level of risk in the external environment (10%) 10%

There is an indication that KRIs monitor changes in the level of risk in the external environment, e.g. “post-deployment monitoring will also be used to indicate whether G42’s models have reached capability thresholds”. However, the specific target of monitoring, and the threshold that would trigger mitigations, is not given.

Quotes:

“In addition to conducting pre-deployment evaluations, post-deployment monitoring will also be used to indicate whether G42’s models have reached capability thresholds and whether increased deployment mitigation and security mitigation levels are required.” (p. 5)

2.2.2.1 Containment KCIs (35%) 45%

2.2.2.2 Deployment KCIs (35%) 25%

2.2.2.3 For advanced KRIs, assurance process KCIs are defined (30%) 0%

There are no assurance processes KCIs defined. The framework does not provide recognition of there being KCIs outside of containment and deployment measures.

Quotes:

No relevant quotes found.

3.1.1.1 Containment measures are precisely defined for all KCI thresholds (60%) 50%

Containment measures are given for Levels 2 and 3, but could be more specific, e.g. specification of what “verified credentials” and “access is role-based, aligned with user responsibility, and supported by a zero-trust architecture to prevent unauthorized entry” actually entails. A plan is not given for assuring that measures will be defined for Level 4 before the corresponding KRI is crossed.

Quotes:

The following are from pp. 9-11:

Security Level 1. “Specific Measures. None. G42 may choose to open source models.”

Securiy Level 2. “Specific Measures. Access controls and role-based permissions. Model weights are gated by granular role-based permission levels, model access is geofenced to pre-approved locations, limited access attempts using the same credentials. Network segmentation to isolate systems containing model weights.

Internal and External Red-Teaming: Rigorous testing by internal security teams, supplemented by external experts, to identify weaknesses.

Dynamic Threat Simulation and Response Testing: Regular adversarial simulations expose potential security weaknesses.”

Security Level 3. “Specific Measures. Model weights and sensitive data are secured through thorough Security Level 2 protocols, as well as the following measures to ensure access to model weights is highly restricted: multi-party and quorum-based approval for high-sensitivity operations, end-to-end encryption of model weights both at rest and in
transit, automatic encryption key rotations at regular intervals. Only trusted users with verified credentials are granted access to high-risk models. Access is role-based, aligned with user responsibilities, and supported by a zero-trust architecture to prevent unauthorized entry.”

Security Level 4. “Specific Measures. To be defined when models reach capabilities necessitating Level 3 containment mitigation measures.”

3.1.1.2 Proof that containment measures are sufficient to meet the thresholds (40%) 10%

Whilst there is a process for determining weaknesses in containment measures with internal red-teaming, it is not clear that this is prior to their implementation. Further, to improve, they should detail proof for why they believe the containment measures proposed will be sufficient to meet the KCI threshold, in advance. In addition, red-teaming is more an evidence gathering activity than a validation/proof; to improve, a case should be made for why they believe their containment measures to be sufficient.

Quotes:

Security Level 2. “Internal and External Red-Teaming: Rigorous testing by internal security teams, supplemented by external experts, to identify weaknesses.” (p. 10)

3.1.1.3 Strong third party verification process to verify that the containment measures meet the threshold (100% if 3.1.1.3 > [60% x 3.1.1.1 + 40% x 3.1.1.2]) 10%

Whilst there is a process for determining weaknesses in containment measures with external red-teaming, it is not clear that this is prior to their implementation. In addition, red-teaming is more for evidence collection than validation, which this criterion requires. Further, to improve, they should detail a process for third-parties to verify the case for why they believe the containment measures proposed will be sufficient to meet the KCI threshold, in advance.

Quotes:

Security Level 2. “Internal and External Red-Teaming: Rigorous testing by internal security teams, supplemented by external experts, to identify weaknesses.” (p. 10)

3.1.2.1 Deployment measures are precisely defined for all KCI thresholds (60%) 50%

The deployment measures are defined in detail for Levels 1, 2 and 3 but not Level 4 (i.e., their various deployment KCIs). Some of the measures remain high-level and could use more precision, for instance “Regular simulations identify model vulnerabilities and develop adaptive responses” or “Asynchronous Monitoring: This offcycle review catches anomalies missed in real-time, assessing all stored interactions for unusual behaviors” could be more detailed, including frequency or what evidence they are searching for, for instance.

Quotes:

Deployment Mitigation Level 1: “Specific Measures. Examples of foundational safeguards that may be applied include: Model Cards: Documents published alongside each new model deployment, summarising the model’s intended use cases, performance on public benchmarks, and the responsible practices conducted to ensure safety.

Incident Reporting Channels: Designated pathways for users to report instances of concerning or harmful behavior in violation of company policy to relevant G42
personnel.

Information Security Training: Training programs for new and existing personnel on best practices in information security consistent with the measures described in the Security Mitigation Levels.” (p. 7)

Deployment Mitigation Level 2: “Specific Measures. Risk of model misuse is mitigated by: Real-Time Monitoring and Prompt Filtering: Real-time classifiers evaluate inputs and outputs, detecting and filtering harmful interactions as they occur. This will also be aligned to underlying customer company policy and regulatory compliance.

Model Robustness Testing: Regular tests of AI models for robustness against attempts to manipulate or corrupt their output.

Asynchronous Monitoring: This offcycle review catches anomalies missed in real-time, assessing all stored interactions for unusual behaviors.

Controlled Rollout: For new frontier level models, implement phased rollouts, starting with limited access to trusted users, with full deployment only after exhaustive risk assessments.” (p. 8)

Deployment Mitigation Level 3: “Specific Measures. Risk of model misuse is mitigated by: Real-time anomaly detection and encrypted data handling.

Simulation and Adversarial Testing: Regular simulations identify model vulnerabilities and develop adaptive responses. Red teaming activity to identify and mitigate potential risks in the system. Testing is designed to ensure effectiveness across all planned deployment contexts, with specialized  subject matter experts providing domain-specific input as needed.

Controlled Rollout: For new frontier level models, implement phased rollouts, starting with limited access to trusted users, with fully deployment only after exhaustive risk assessments.” (p. 8)

Deployment Mitigation Level 4: “Specific Measures. To be defined when models reach capabilities necessitating Level 3 deployment mitigation measures.” (p. 9)

“Although there is less prior research on evaluating and mitigating risks from biological design tools (BDTs), it is still critical for G42 to develop innovative measures for these tools over time.” (p. 6)

3.1.2.2 Proof that deployment measures are sufficient to meet the thresholds (40%) 0%

No proof is provided that the deployment measures are sufficient to meet the deployment KCI thresholds, nor is there a process to solicit such proof.

Quotes:

No relevant quotes found.

3.1.2.3 Strong third party verification process to verify that the deployment measures meet the threshold (100% if 3.1.2.3 > [60% x 3.1.2.1 + 40% x 3.1.2.2]) 25%

They detail a process for soliciting external expert advice prior to deployment decisions. However, sufficiency criteria for third-parties’ expertise should be determined ex ante, and the advice should be verification that the measures are sufficient above simply “input”. Further, verification should ideally take place before the relevant KRI thresholds are crossed, rather than after.

Quotes:

“As deemed appropriate, we will solicit external expert advice for capability and safeguards assessments. This may include partnering with private or civil society organisations with expertise in AI risk management to provide input on our assessments plans and/or internal capability reports ahead of deployment decisions.” (p. 12)

3.1.3.1 Credible plans towards the development of assurance properties (40%) 0%

There are no indications of plans to develop assurance processes nor mention of assurance processes in the framework. There are no indications to contributing to the research effort to ensure assurance processes are in place when they are required.

Quotes:

No relevant quotes found.

3.1.3.2 Evidence that the assurance properties are enough to achieve their corresponding KCI thresholds (40%) 0%

There is no mention of providing evidence that the assurance processes are sufficient.

Quotes:

No relevant quotes found.

3.1.3.3 The underlying assumptions that are essential for their effective implementation and success are clearly outlined (20%) 10%

Whilst assurance processes are not explicitly mentioned in the framework, the assumptions for deployment KCIs to successfully mitigate risk are given, which is given partial credit here: “these measures […] [presume] that our development environment’s information security has not been violated”. To improve, a similar mode of setting out assumptions for KCIs to be successfully met should be applied for assurance processes.

Quotes:

“G42’s Deployment Mitigation Levels are a set of levels, mapped to the Frontier Capability Thresholds, that describe escalating mitigation measures for products deployed externally. These protect against misuse, including through jailbreaking, as models reach higher levels of capability and risk. These measures address specifically the goal of denying bad actors access to dangerous capabilities under the terms of intended deployment for our models, i.e. presuming that our development environment’s information security has not been violated.” (p. 7)

3.2.1.1 Justification that elicitation methods used during the evaluations are comprehensive enough to match the elicitation efforts of potential threat actors (30%) 50%

There is an indication that elicitation must “avoid underestimating model capabilities”, listing elicitation methods such as “prompt engineering, fine-tuning, and agentic tool usage”. However, this reasoning is not used to empirically justify why the evaluations are comprehensive enough, and is not linked to risk models of the elicitation efforts of potential threat actors.

Quotes:

“If the preliminary evaluations cannot rule out proficiency in hazardous capabilities, then we will conduct in-depth evaluations that study the capability in more detail to assess whether the Frontier Capability Threshold has been met. Such evaluations will incorporate capability elicitation – techniques such as prompt engineering, fine-tuning, and agentic tool usage – to optimize performance, overcome model refusals, and avoid underestimating model capabilities. Models created to generate output in a specific language, such as Arabic or Hindi, may be tested in those languages.” (pp. 5-6)

3.2.1.2 Evaluation frequency (25%) 50%

There is an acknowledgment that frequent evaluation during development is necessary, with a period of 6 months “for our most advanced models”. However, the frequency also does not relate to effective compute. It would be an improvement to state that the fixed time period is to account for post-training enhancements/elicitation methods.

Quotes:

“G42 will conduct evaluations throughout the model lifecycle to assess whether our models are approaching Frontier Capability Thresholds” (p. 5)

“G42 will publish internal reports providing detailed results of our capability evaluations. These reports will be created for our most advanced models at least once every six months, and the results will be shared with the Frontier AI Governance Board and the G42 Executive Leadership Committee.” (p. 5)

“Conduct routine capability assessments.” (p. 13)

3.2.1.3 Description of how post-training enhancements are factored into capability assessments (15%) 0%

Whilst evaluations are defined to “avoid underestimating model capabilities”, this is not explicitly linked to accounting for post-training enhancements, nor a safety margin.

Quotes:

“If the preliminary evaluations cannot rule out proficiency in hazardous capabilities, then we will conduct in-depth evaluations that study the capability in more detail to assess whether the Frontier Capability Threshold has been met. Such evaluations will incorporate capability elicitation – techniques such as prompt engineering, fine-tuning, and agentic tool usage – to optimize performance, overcome model refusals, and avoid underestimating model capabilities. Models created to generate output in a specific language, such as Arabic or Hindi, may be tested in those languages.” (pp. 5-6)

3.2.1.4 Vetting of protocols by third parties (15%) 25%

There is some process for gaining external input on evaluation protocols. To improve, this could be made required rather than “as deemed appropriate”, and with named organizations, as well as sufficiency criteria for expertise. Further, the input from third parties should be less about providing information as it should be about validating the protocols used, providing a third party form of accountability to verify that the evaluation methodologies are sound.

Quotes:

“As deemed appropriate, we will solicit external expert advice for capability and safeguards assessments. This may include partnering with private or civil society organisations with expertise in AI risk management to provide input on our assessments plans and/or internal capability reports ahead of deployment decisions.” (p. 12)

3.2.1.5 Replication of evaluations by third parties (15%) 0%

There is no mention of evaluations being replicated or conducted by third parties.

Quotes:

No relevant quotes found.

3.2.2.1 Detailed description of evaluation methodology and justification that KCI thresholds will not be crossed unnoticed (40%) 25%

There is an awareness that monitoring of mitigation effectiveness is necessary. However, more detail is required on what “post-deployment monitoring” entails, such as process, frequency and methods. The focus of post-deployment monitoring does also seem to moreso focused on whether models cross KRI thrsholds, rather than if measures still meet the KCI threshold.

Quotes:

“In addition to conducting pre-deployment evaluations, post-deployment monitoring will also be used to indicate whether G42’s models have reached capability thresholds and whether increased deployment mitigation and security mitigation levels are required.” (p. 5)

“Model Robustness Testing: Regular tests of AI models for robustness against attempts to manipulate or corrupt their output.” (p. 8) (DL2)

“Asynchronous Monitoring: This off cycle review catches anomalies missed in real-time, assessing all stored interactions for unusual behaviors.” (p. 8) (DL2)

3.2.2.2 Vetting of protocols by third parties (30%) 25%

There is some process for gaining external input on safeguard assessment protocols. To improve, this could be made required rather than “as deemed appropriate”, and with named organizations, as well as sufficiency criteria for expertise.

Quotes:

“As deemed appropriate, we will solicit external expert advice for capability and safeguards assessments. This may include partnering with private or civil society organisations with expertise in AI risk management to provide input on our assessments plans and/or internal capability reports ahead of deployment decisions.” (p. 12)

3.2.2.3 Replication of evaluations by third parties (30%) 10%

There is an indication that third parties help to conduct red teaming of containment KCI measures to ensure they meet the containment KCI threshold, but detail on process, expertise required and methods are not given, and external experts are only supplementary. To improve, there should also be a process for replicating / having safeguard red teaming conducted by third parties for deployment KCI measures. Further, these external evaluations should be independent.

Quotes:

“Internal and External Red-Teaming: Rigorous testing by internal security teams, supplemented by external experts, to identify weaknesses.” (p. 10)

3.2.3.1 Sharing of evaluation results with relevant stakeholders as appropriate (85%) 25%

Whilst they commit to publishing Model Cards publicly with each new deployment, this only details “performance on public benchmarks”. To improve, all KRI and KCI assessments should be public. Further, they should notify the relevant authorities if any KRI threshold is crossed.

Quotes:

“G42 will publish internal reports providing detailed results of our capability evaluations. These reports will be created for our most advanced models at least once every six months, and the results will be shared with the Frontier AI Governance Board and the G42 Executive Leadership Committee.” (p. 5)

“Incidence Response: Developing a comprehensive incident response plan that outlines the steps to be taken in the event of non-compliance. Incident detection should leverage automated mechanisms and human review, and non-sensitive incident information should be shared with applicable government bodies. We plan for our response protocols to focus on rapid remediation to minimize unintended harmful outputs from models. Depending on the nature and severity of the incident, this might involve implementing immediate containment measures restricting access to the model either externally, internally or both.” (p. 11)

“We will maintain detailed documentation for G42’s most capable models, including design decisions, testing results, risk assessments, and incident reports.” (p. 11)

“Examples of foundational safeguards that may be applied include: Model Cards: Documents published
alongside each new model deployment, summarising the model’s intended use cases, performance on
public benchmarks, and the responsible practices conducted to ensure safety.” (p. 7)

3.2.3.2 Commitment to non-interference with findings (15%) 25%

No commitment to permitting the reports, which detail the results of external evaluations (i.e. any KRI or KCI assessments conducted by third parties), to be written independently and without interference or suppression.

Quotes:

No relevant quotes found.

3.2.4.1 Identifying novel risks post-deployment: engages in some process (post deployment) explicitly for identifying novel risk domains or novel risk models within known risk domains (50%) 25%

There is a clear emphasis on identifying novel risks. However, no explicit process for uncovering novel risks, post-deployment, in the deployment context, is detailed. They indicate post-deployment monitoring will take place. This could be built upon to detect novel risks. They do note that asynchronous monitoring aims to find “unsual behaviours”; more detail could be added here for an improved score on how exactly they anticipate their monitoring setup will be likely to detect novel risks.

The emphasis on “near miss” incidents as a mechanism to trigger expanded monitoring of other risk domains aligns well with this criterion; partial credit is given here. However, to improve, detection of near misses should be proactively found, rather than relying on reactive recognition of near accidents.

Quotes:

“This Framework emphasizes proactive risk identification and mitigation, centering on capability monitoring, robust governance, and multi-layered safeguards to ensure powerful AI models are both innovative and safe. With a systematic approach to early threat detection and risk management, it aims to support G42 in unlocking the benefits of frontier AI safely and ethically.” (p. 3)

“We plan to integrate decisions on whether to expand our monitoring to
include additional hazardous capabilities into our regular framework review process. This includes both our scheduled internal reviews and our annual reviews by third parties. In making these decisions, we expect to consider factors such as: “near miss” incidents, whether internal or industry-wide; recommendations from trusted external experts; as well as changes in industry standards for AI risk management.” (p. 4)

“To produce this list, G42 both conducted our own internal risk analysis and received input from external AI safety experts. Initially G42 identified potential capabilities across several domains, including biological risks, cybersecurity, and autonomous operations in specialized fields. We then collaborated with METR and SaferAI to refine our list, prioritizing capabilities based on their potential impact and how feasibly they can be measured and monitored.” (p. 4)

“In addition to conducting pre-deployment evaluations, post-deployment monitoring will also be used to indicate whether G42’s models have reached capability thresholds and whether increased deployment mitigation and security mitigation levels are required.” (p. 5)

“Asynchronous Monitoring: This offcycle review catches anomalies
missed in real-time, assessing all stored interactions for unusual behaviors. (p. 8)

3.2.4.2 Mechanism to incorporate novel risks identified post-deployment (50%) 25%

Whilst they mention a mechanism for including novel risks via conducting the regular framework review process, there is no mechanism defined to incorporate novel risks into the risk modeling itself. To improve, discovery of a changed risk profile or novel risk domain should trigger risk modelling exercises for all existing capabilities, or at least those likely to be affected. They do mention an intent to incorporate risks such as advanced manipulation in future – a mechanism for deciding when to incorporate this as a risk would be an improvement.

Quotes:

“In the future, we will map out other hazardous capabilities to consider monitoring. We may also add thresholds for:

• Autonomous Operation: When an AI system can make unsupervised
  decisions with critical implications, particularly in sectors such as healthcare or defense.
• Advanced Manipulation: Applicable when AI systems can influence human behavior or decisions on a large scale, warranting enhanced monitoring and usage restrictions.

We plan to integrate decisions on whether to expand our monitoring to
include additional hazardous capabilities into our regular framework review process. This includes both our scheduled internal reviews and our annual reviews by third parties. In making these decisions, we expect to consider factors such as: “near miss” incidents, whether internal or industry-wide; recommendations from trusted external experts; as well as changes in industry standards for AI risk management.” (p. 4)

“To produce this list, G42 both conducted our own internal risk analysis and received input from external AI safety experts. Initially G42 identified potential capabilities across several domains, including biological risks, cybersecurity, and autonomous operations in specialized fields. We then collaborated with METR and SaferAI to refine our list, prioritizing capabilities based on their potential impact and how feasibly they can be measured and monitored.” (p. 4)