Gemini 2.5

Date of Release

The Date of Release is the date when the model was made available to the public. Publishing these dates is especially important when multiple versions of the model are released over time.

EU AI Act Requirements

Annex XI Section 1.1c: date of release

CAIT-D Requirements

- (11) The dates the datasets were first used during the development of the artificial intelligence system or service.

Methods of Distribution

The Methods of Distribution specify all the ways a model can be accessed. Common methods include: a direct model download, access through an API or a hybrid option where a private API endpoint is externally hosted.

EU AI Act Requirements

Annex XI Section 1.1c: methods of distribution

Modality

The Modality specifies the types of data that the model can process and output. Common domains include text, images, video, audio and tabular data.

EU AI Act Requirements

Annex XI Section 1.1e: modality (e.g., text, image)

Input and Output Format

The Input and Output Format are specifications for how the data should be provided to the model and the exact format output by the model. If applicable, the documentation should include maximum size of the data (e.g. context window length).

EU AI Act Requirements

Annex XI Section 1.1e: format of the inputs and outputs and their maximum size (e.g. context window length, etc.)

License

The License is the terms under which the model is released. It indicates whether the model can be used for commercial purposes and whether it can be modified and redistributed. Models released exclusively through an API may not have a license, but still be governed through a "Terms of Service".

EU AI Act Requirements

Annex XI Section 1.1f: the license

Instructions for Use

Instructions for Use provide guidance for using the model. Ideally, these include specific examples and recommendations. If applicable, the instructions should specify any software/hardware dependencies needed to use the system, and how the model can interact with hardware/software that is not part of the model itself.

EU AI Act Requirements

Annex XI Section 1.2a: the technical means (e.g. instructions of use, infrastructure, tools) required for the general-purpose AI model to be integrated in AI systems.
Annex XII 1.d: how the model interacts, or can be used to interact, with hardware or software that is not part of the model itself, where applicable;

Documentation Support

Documentation Support evaluates the accessibility and usefulness of the model's documentation. For a high score in this category, the key details required across the categories need to both exist and be easily accessible.

Trustible Rating Explanation

This rating is borderline between Low and Medium, because while extensive instructions are available for model use, details around training and data are extremely limited.

Changelog

A Changelog is an artifact that lists out versions of the model with changes that were added in each version. Entries in the changelog should make it clear to a user how the system has changed, and what modifications need to be made for effective use. If a model was released once and no changes will be applied, the documentation should make this clear.

Acceptable Use Policy

The Acceptable Use Policy specifies how a model can/can not be used. When a model is released under a fully open-source license, this policy may not be necessary.

EU AI Act Requirements

Annex XI Section 1.1b: acceptable use policies applicable

User Data

Model developers should clearly state whether user data is used to train models. For models that are not accessed via an API, the documentation should make it clear, if user data from other products offered by the developer were used. Listing out an explicit set of external datasets is an allowed alternative to a “user data” statement, but it should be very clear that whether user-related data is in this set.

Data Takedown

Model providers should provide a clear mechanism for submitting takedown claims for copyrighted or personal data. The mechanism can include an online form, an email or an in-app button.

AI Ethics Statement

Model providers should publish an AI Ethics statement that captures the principles used during model development. Alternatively, a company can publish a set of RAI objectives.

Incident Reporting

Model Providers should provide a clear mechanism for submitting model feedback and/or for incident reporting.

Task Description

The task description should clearly describe the intended uses for the model. Detailed documentation should, also, cover limitations and out-of-scope uses.
Transparency around model capabilities allows users to properly assess if the model is suitable for their task.

Trustible Rating Explanation

Capabilities for several tasks are discussed, though there is little description of the limitations across key tasks.

EU AI Act Requirements

Annex XI Section 1.1a: the tasks that the model is intended to perform and the type and nature of AI systems in which it can be integrated

Number of Parameters

The Number of Parameters indicates how large the model is.

EU AI Act Requirements

Annex XI Section 1.1d: number of parameters

Model Design

The Model Design should cover key components of the model and explain how the inputs get transformed into the outputs. Transparency around model architecture can help users understand the suitability of the model for a particular task.

Trustible Rating Explanation

This model received a Medium rating because the model components are not described in detail by the model primary developer. In this case, additional information is provided by an external blog post.

EU AI Act Requirements

Annex XI Section 1.2b: the design specifications of the model...the key design choices including the rationale and assumptions made

Training Methodology

The Training Methodology should cover the key steps involved in training the model. This should involve both high-level steps and details of the process. For example, Foundation Models are often trained in multiple phases: pretraining, supervised fine-tuning and alignment with human preference/safety. Each step can be implemented via different techniques (e.g. alignment can be done via RLHF or Constitutional AI). Documenting this process can help the users understand the strengths and weaknesses of a particular model.

EU AI Act Requirements

Annex XI Section 1.2b: the design specifications of...training process, including training methodologies and techniques, the key design choices including the rationale and assumptions made; what the model is designed to optimise for

Computational Resources

Computational Resources can include training times, FLOPs (floating point operations) and other details that can be used to assess the magnitude of resources used to train the model.

EU AI Act Requirements

Annex XI Section 1.2d: the computational resources used to train the model (e.g. number of floating point operations – FLOPs-), training time, and other relevant details related to the training;

Energy Consumption

Energy Consumption refers to the carbon emission associated with training the model. It can be approximated based on GPUs used and training time (Calculator: https://mlco2.github.io/impact/#compute).

EU AI Act Requirements

Annex XI Section 1.2e: known or estimated energy consumption of the model...
With regard to [this] point, where the energy consumption of the model is unknown, the energy consumption may be based on information about computational resources used.

System Architecture

The System Architecture description should explain how the model is connected to the end-to-end system. For example, an LLM could be connected to a separate content filtering models for its inputs and/or outputs.

This rating only applies to API-only systems.

EU AI Act Requirements

Annex XI Section 2.3: Where applicable, a detailed description of the system architecture explaining how software components build or feed into each other and integrate into the overall processing.

Training Hardware

The Training Hardware documentation can include exact GPU models or country of origin of the technology. This information may be necessary as part of vendor security vetting.

Dataset Size

Dataset Size indicates how much data was used to train the model. This can be specified in terms of the number of documents, tokens or other measures.

EU AI Act Requirements

Annex XI Section 1.2c: the number of data points

CAIT-D Requirements

- (3) The number of data points included in the datasets, which may be in general ranges, and with estimated figures for dynamic datasets.

Dataset Description

The Dataset Description provides an overview of the data used for training. It should include a description of individual datapoints, distinct subpopulations and the corpus as a whole. The characteristics described can include low-level properties like number of tokens from each data source and semantic properties like percent of documents in each language. While the Data Sources category focuses on the origins of the data, this category is used to review transparency of the final dataset.

Trustible Rating Explanation

This model received an Unknown rating because only the quantity of each mode of training data is described. No description of which data are used is provided.

EU AI Act Requirements

Annex XI Section 1.2c: information on the data used for training, testing and validation, including...the number of datapoints, their scope and main characteristics

CAIT-D Requirements

- (4) A description of the types of data points within the datasets. For purposes of this paragraph, the following definitions apply: (A) As applied to datasets that include labels, “types of data points” means the types of labels used. (B) As applied to datasets without labeling, “types of data points” refers to the general characteristics.

Data Sources

The Data Source documentation covers the types of data used to train the model and how they were collected. Transparency around sources can help users to assess if a model is suitable for their task (e.g. was it trained on their language) and to gauge the risk profile of the model (e.g. was it trained on unrestricted internet data). The documentation should make it clear if the dataset was purchased or licensed.

When creating new datasets, documentation should cover the steps involved in creation and limitations, like missing data. In addition, documentation should state when the dataset was collected. If synthetic data was generated for the dataset, the documentation should make the process involved clear.

EU AI Act Requirements

Annex XI Section 1.2c: information on the data used for training, testing and validation ... including type and provenance of data ... how the data was obtained and selected. ... [and] all other measures to detect the unsuitability of data sources

CAIT-D Requirements

- (1) The sources or owners of the datasets
- (2) A description of how the datasets further the intended purpose of the artificial intelligence system or service.
- (6) Whether the datasets were purchased or licensed by the developer
- (12) Whether the generative artificial intelligence system or service used or continuously uses synthetic data generation in its development. A developer may include a description of the functional need or desired purpose of the synthetic data in relation to the intended purpose of the system or service.

Data Collection - Human Labor

This category assesses the transparency surrounding the human labor involved in the generation of training data. For human labor, we refer to individuals outside of the development team that were employed to create, annotate or review datasets. Datasets include both original pre-training data and human preference data that is used iteratively during post-training. Transparency in this category can help assess potential biases in the data and hold developers accountable to fair labor practices.

If no manual annotation or review was used when constructing the dataset, this category may be marked as Not Applicable. This may occur if the dataset is composed entirely of off-the-shelf data from the Internet.

Data Preprocessing

The Data Preprocessing documentation covers how data sources were preprocessed for training. This should include both filtering steps (i.e. how were datapoints excluded) and transformation steps (i.e. how were source datapoints modified before training). A clear description of this process is important for assessing risks. For example, it can indicate how personally identifying information (PII) was handled: were documents containing PII removed and/or were PII words, like emails, replaced with a placeholder. In addition, this documentation will enable users to set-up additional data correctly for fine-tuning.

EU AI Act Requirements

Annex XI Section 1.2c: information on the data used for training, testing and validation, where applicable, including ... curation methodologies (e.g. cleaning, filtering etc)

CAIT-D Requirements

- (9) Whether there was any cleaning, processing, or other modification to the datasets by the developer, including the intended purpose of those efforts in relation to the artificial intelligence system or service.

Data Bias Detection

The Data Bias Detection category assesses how developers reviewed the data for potential biases. We use Bias to refer to an incorrect or incomplete representation of human subpopulations (i.e. people of a certain race, gender or religion). Bias can appear in data both as text or images containing stereotypes and harmful content and/or as a lack of representation of a particular group. For this evaluation, we focus specifically on the training dataset, not on mitigations implemented during training during training like safety alignment.

EU AI Act Requirements

Annex XI Section 1.2c: information on the data used for training, testing and validation, including...methods to detect identifiable biases, where applicable

Data Deduplication

The Data Deduplication category assesses whether the documentation discusses how duplicate entries were treated in the training data.

Data Toxic and Hateful Language Handling

The Data Toxic and Hateful Language Handling category assesses whether the documentation discusses how toxic and hateful entries were treated in the training data. The developers may chose to not remove such language, but they should provide a clear explanation for their decision (e.g. better performance or allowing customization of the final model).

IP Handling in Data

This category assesses whether the documentation discusses how copyrighted entries and other types of IP were treated in the training data.

CAIT-D Requirements

- (5) Whether the datasets include any data protected by copyright, trademark, or patent, or whether the datasets are entirely in the public domain.

Data PII Handling

The Data PII (Personally identifiable information) Handling category assesses whether the documentation discusses how PII entries were treated in the training data. While in general developers should take care to remove such data, a clear justification of why such data was not removed will suffice for this category.

CAIT-D Requirements

- (7) Whether the datasets include personal information, as defined in subdivision (v) of Section 1798.140.
- (8) Whether the datasets include aggregate consumer information, as defined in subdivision (b) of Section 1798.140.

Data Collection Period

Model documentation should clearly the state last date used for the model's training data (e.g. April 2023). This information is necessary to assess the accuracy of the model outputs.

Performance Evaluation

The Performance Evaluation covers the quantitative and qualitative analysis of model capabilities. While many of the models considered can be used for many different applications, there exist many benchmarks and protocols for reviewing the overall capabilities of the model.

The following key documentation dimensions are reviewed:

• The choice of metrics/benchmarks used is clearly explained.

• Metrics on multiple dimensions of model performance are reported in an externally reproducible fashion (Links to evaluation code or externally hosted benchmarks are provided where possible, but are not required).

• Qualitative examples are included to supplement the user’s understanding of model performance.

• Gaps in analysis and/or an error analysis are documented to further enhance the user’s understanding of the model’s performance.

Trustible Rating Explanation

This model received a Low rating because the evaluations are underspecified beyond reporting the raw metrics for specific benchmarks. While one example is provided (of a game auto-generated from a prompt), this is insufficient information for a deeper understanding of the performance.

EU AI Act Requirements

Annex XI Section 2.1: A detailed description of the evaluation strategies, including evaluation results, on the basis of available public evaluation protocols and tools or otherwise of other evaluation methodologies. Evaluation strategies shall include evaluation criteria, metrics.

Evaluation of Limitations

This category reviews the types of quantitative evaluations that were reported regarding the limitations of this model. For general--purpose models, limitations are multi-faceted and can include both traditional modes (e.g. misclassification) and novel ones (e.g. generating bias content).

This rating considers the breadth of analyses considered. The following categories key categories should be considered by most LLM developers, but are not a comprehensive list:
- Bias/Fairness (e.g. using DiscrimEval, BBQA, DecodingTrust or a custom benchmark)
- Factuality/Hallucination
- Safety (e.g. likelihood of generating content that violates an acceptable-use policy or evaluation related to a cybersecurity threat)
- Incorrect Refusal Rates (used to quantify the balance of safety and helpfulness)

Note: For this rating, we review whether the developers considered common limitations and published quantitative results for these categories. The broader risk assessment and adversarial testing procedure is evaluated by the ‘Adversarial Testing Procedure’ category.

EU AI Act Requirements

Annex XI Section 2.1: Detailed description of ...the methodology on the identification of limitations.

Evaluation with Public Tools

Evaluations on benchmarks should be conducted using public tools. For many benchmarks, small changes in implementation can influence the metrics and result in figures that are not directly comparable to those published for other models.

EU AI Act Requirements

Annex XI Section 2.1: [Evaluation is conducted] on the basis of available public evaluation protocols and tools

Adversarial Testing Procedure

Adversarial Testing is the process of intentionally evaluating the risks associated with the model. For general-purpose AI, the focus is usually on the likelihood of models producing harmful outputs. The testing may involve a predetermined set of inputs that are likely to produce bad outputs, manual testing by experts (i.e. red-teaming) or model assisted approaches. For this transparency evaluation, we focus on the depth of documentation. A developer may not be able to assess all risks, but they should clearly document the limitations of the implemented adversarial testing process.

The following aspects of documentation should be considered for this evaluation:

• Set of risks tested is documented and justified
• Testing process (e.g. benchmarks used or types of human red-teamers employed)
• Results from adversarial testing process are presented
• Discussion on implications of the findings and/or on limitations of the process is included.

Note: There is a small overlap between this rating and “Evaluation of Limitations”. This rating focuses on the transparency of the process; while the other one evaluates the transparency of metrics. Quantitative results from a red-teaming exercise can contribute to increased ratings in both categories, but the rest of the considerations are different.

EU AI Act Requirements

Annex XI Section 2.2: Where applicable, a detailed description of the measures put in place for the purpose of conducting internal and/or external adversarial testing (e.g., red teaming).

Model Mitigations

Model mitigations are steps taken to reduce risks associated with a model. For example, a model can specifically be fine-tuned to recognize inappropriate inputs and refuse to respond. Understanding implemented adaptations is important for recognizing risks associated with the model.

The exact set of risks will depend on the type of model. Since risks will evolve over time, we consider if some set of mitigated and unmitigated risks was considered. We do not evaluate against a specific set of risks.

Because this is a transparency rating, we evaluate documentation for a description for clarity around both implemented mitigations and remaining risks. If adaptations were not implemented, developers should clearly disclose that and provide guidance to downstream users.

Trustible Rating Explanation

Mitigations are described in very broad terms in the Model Card, and the CoT Verifier is only referenced in external documentation.

EU AI Act Requirements

Annex XI Section 2.2: Where applicable, a detailed description of ...model adaptations, including alignment and fine-tuning.