LEGAL TEXTS
Annex II to the IRBAI Statute, Audit and Compute Oversight: Technical Standards. Forms an integral part of the Statute pursuant to Chapter 16 and implements Articles 115 to 121.
Contents
Part 2. Adversarial Testing Standards
Part 3. Cryptographic Verification Artifacts
Part 4. Confidential Access Mechanisms
Part 5. Compute Provider Records and Logging Standards
Part 6. Global Model and Dataset Registry Metadata Schema
Status of this Annex
1. This Annex forms an integral part of the Statute of the International Regulatory Body for Artificial Intelligence. It has the same binding force as the Statute and shall be interpreted in conformity with Chapter 16 thereof.
2. This Annex contains the technical standards implementing the audit and cross-border compute oversight framework established in Articles 115 to 121 of the Statute. IRBAI’s audit rights, the obligations of State Parties and certified entities to accept and facilitate audit, the confidentiality protections and procedural safeguards applicable to audit access (including the Break-Glass Emergency Access Protocol and the escrow safeguards of Article 119) are established exclusively in the Statute and are not affected by amendment of this Annex.
3. Pursuant to Article 116, amendments to this Annex shall be developed through the Policy Forum process and adopted by the Executive Board following consultation with the Council, without recourse to the amendment procedure established in Article 197 of the Statute.
Part 1. Audit Access Objects
Within the scope of a lawfully initiated audit under Article 116 of the Statute, certified entities shall ensure that IRBAI auditors can access the following categories of material:
a) Training datasets and lineage documentation, including provenance records, licensing agreements, and augmentation histories;
b) Preprocessing pipelines, training algorithms, and optimization procedures;
c) Model artifacts, checkpoints, version manifests, and architectural documentation;
d) Evaluation methodologies, benchmark results, and safety assessment records;
e) Hardware components, IoT integrations, and robotics interfaces where material to the system’s compliance status;
f) Deployment telemetry and append-only audit logs recording the system’s operational behavior;
g) Security testing records, vulnerability assessments, and incident response documentation;
h) Supply chain records including software dependencies, pre-trained components, and external API integrations under Article 111 of the Statute.
Part 2. Adversarial Testing Standards
Independent adversarial testing conducted or commissioned by IRBAI under Article 116 of the Statute in respect of High Risk and Systemic AI Systems shall cover, at minimum, the following attack vectors:
a) Prompt injection, including direct, indirect, and multi-turn injection techniques;
b) Data exfiltration, including extraction of training data, personal data, and confidential contextual information;
c) Model exploitation, including model extraction, inversion, and adversarial perturbation;
d) Safety guardrail circumvention, including jailbreaking, refusal suppression, and capability elicitation beyond certified parameters;
e) Such other attack vectors as IRBAI determines relevant to the system’s risk profile, having regard to the current state of adversarial machine learning research.
Adversarial testing methodologies, coverage baselines, and reporting formats shall be maintained by the Compliance Monitoring Directorate and updated to reflect the evolution of attack techniques.
Part 3. Cryptographic Verification Artifacts
Developers of Medium Risk, High Risk, and Systemic AI Systems shall provide IRBAI with the following cryptographic verification artifacts as part of the certification process and at each renewal (Article 119 of the Statute):
a) Cryptographic hashes or Merkle commitments to registered model versions, checkpoints, and training datasets, enabling IRBAI to verify artifact integrity without accessing raw content;
b) Remote attestation proofs of the exact runtime environment, binaries, configuration, and hardware used in the system’s operation, enabling IRBAI to verify that the deployed system matches the certified artifact;
c) Zero-knowledge or equivalent proofs demonstrating that training datasets satisfy applicable licensing, consent, provenance, deduplication, and data quality requirements without requiring disclosure of the dataset itself;
d) Proofs that models meet specified safety guardrail, watermarking, or differential-privacy thresholds as required under the system’s certification conditions;
e) Software bill of materials and supply-chain attestations covering training code, pipelines, build artifacts, and significant dependencies under Article 111 of the Statute.
Part 4. Confidential Access Mechanisms
Where cryptographic verification is insufficient and IRBAI requires access to confidential technical materials under Article 119 of the Statute, access shall be provided through one of the following mechanisms, selected in consultation with the developer:
a) On-Premises Access: IRBAI-accredited auditors conduct the required assessment at the developer’s own facilities using the developer’s infrastructure, executing IRBAI-approved conformance and safety test suites within a controlled environment, with no removal of materials from the developer’s premises;
b) Secure Remote Access means access provided through a secure, attested confidential computing environment maintained by the developer, enabling IRBAI auditors to execute approved test suites and obtain verifiable results without IRBAI personnel being able to access or export raw weights or training data;
c) Accredited Third-Party Access means access provided to an IRBAI-accredited independent third party who conducts the required assessment within an attested environment and provides IRBAI with findings and cryptographically verifiable results without transferring proprietary materials to IRBAI directly.
Part 5. Compute Provider Records and Logging Standards
Computing infrastructure providers offering services to Systemic AI Systems or High Risk certified AI systems within State Party jurisdictions shall maintain and implement (Article 120 of the Statute):
a) Records of compute resources allocated to certified AI systems, including training runs and inference infrastructure, maintained at a level of detail sufficient to enable verification of systemic designation thresholds under Article 103 of the Statute, and provided to IRBAI upon request;
b) Access controls and logging mechanisms enabling post-hoc attribution of compute usage to specific AI systems in the event of enforcement investigations.
Part 6. Global Model and Dataset Registry Metadata Schema
Developers of AI systems subject to certification under Chapter 14 of the Statute shall register the following metadata in the Global Model and Dataset Registry as part of the certification process (Article 118 of the Statute):
a) System identification: name, version, developer identity, and certification status;
b) Architecture type means a general description of the system’s architecture category without disclosing proprietary implementation details;
c) Training compute means the approximate training compute in FLOPs or equivalent measure, sufficient to enable IRBAI’s systemic designation assessment under Article 103 of the Statute;
d) Training data categories means the general categories of data used in training, including modalities, languages, domains, and approximate scale, without requiring disclosure of specific proprietary datasets;
e) Deployment footprint means the jurisdictions, sectors, and approximate scale of deployment, updated annually;
f) Known limitations and risk factors means material known limitations, failure modes, and risk factors identified during development and evaluation;
g) Certification and licensing status means current certification tier, validity period, and any conditions, restrictions, or suspensions.
Registry entries shall be maintained and updated by developers at each certification renewal and upon material change to any registered parameter. The classification and handling of Registry entries is governed by Article 118 of the Statute.
This text is published for reference. Citations across this website in the form used here refer to the provisions above.