IRBAI · Regulatory Framework
Regulatory risk does not follow from a model’s headline capability. It arises at the intersection of a model’s form — what it is — and its behaviour — what it does — and is further modified by scale, access, and domain of use. IRBAI assesses each such intersection and certifies those that carry risk, rather than regulating by model name or aggregate capability.
A given model form may present low risk in one behaviour and significant risk in another. Assessment is conducted at the level of the individual intersection, not the broad category.
A narrow system of high capability may present limited risk; a less capable but general and autonomous system may present greater risk. Risk is assessed as a function of generality, autonomy, and access.
A deployed model may require multiple certificates, one for each risk intersection it occupies. Certification is applied in layers corresponding to the structure of the system.
Click any highlighted cell to see why it carries risk and which IRBAI certificate applies.
The matrix addresses the model: its form and its capabilities. Regulatory risk is realised at deployment — when a model is made available through an API, integrated into a product, or applied to a regulated decision. IRBAI certifies each layer of the stack and assigns accountability to the layer that exercises the relevant control.
The public release of model weights is irreversible. A released model cannot be recalled, updated, or withdrawn, and the corrective measures available for hosted models do not apply once weights are distributed. IRBAI does not restrict open release on that basis; open availability supports transparency, independent evaluation, and market competition. Certification requirements are instead applied before publication. Under AIFM-OPEN, an open-weight release is assessed on the marginal risk it introduces — the extent to which distributing the specific weights materially increases access to serious-harm capabilities, including chemical, biological, radiological and nuclear (CBRN) or offensive-cyber capabilities, relative to models and information already publicly available.
Certification is determined by a model’s position in the risk matrix. It does not depend on whether the model is open or closed, or on its jurisdiction of origin. Provenance and security requirements apply separately and do not substitute for capability assessment.
Responsibility for compliance is not transferred in full to the deploying party. Obligations attach to the entity that holds the relevant control. A developer can implement corrections at the source of a general-purpose model, effective across all downstream uses; obligations concerning dangerous capabilities and reasonably foreseeable misuse therefore rest primarily with the developer. A deployer, able to constrain a model only at the point of use, is responsible for the specific context of deployment. Providers accordingly retain a share of responsibility for the conduct of their downstream and API clients, and a deployed system will commonly require certification at more than one layer.