IRBAI · Audit & Oversight
Certification states what a system is permitted to do; audit verifies what it actually does, so that AI systems remain safe for the public for as long as they operate. IRBAI conducts audits directly and publishes the frameworks and guidelines under which accredited third parties conduct them worldwide. IRBAI audits are conducted under Chapter 16 of the Statute (Articles 115–121) to the technical standards of Annex II, by IRBAI auditors and by Accredited Assessment Bodies under Article 102. Certified entities accept and facilitate audit as a condition of certification. In return, audit access is bounded, logged, and confidential by design.
An audit tests certified claims against deployed reality. Documentation is evidence, not proof. The standard of verification is what a system does in operation: its logs, and its behaviour under adversarial pressure.
Wherever possible, compliance is proven cryptographically, with no access to raw materials. Where access is unavoidable, it occurs through controlled mechanisms from which raw weights and training data are never exported.
Audit follows the certificate through its life: scheduled renewal, six-month adversarial testing for Systemic systems, for-cause audits at any time, and mandatory reassessment on material change.
SCOPE · THE EIGHT AUDIT ACCESS OBJECTS (ANNEX II, PART 1)
Within a lawfully initiated audit under Article 116, auditors can access eight categories of material, covering a system from silicon to deployed operation. Access is scoped to the certificate, purpose-bound, and logged.
METHOD · THE VERIFICATION LADDER
Annex II sets a layered model: prove cryptographically where possible, access confidentially where necessary, test adversarially throughout. Each rung is used only where the previous one cannot achieve verification.
IN PRACTICE · THE AUDIT ENGAGEMENT
Inside that method, an audit engagement follows four familiar activities. Each is conducted to the Annex II standards and scoped to the certificate under review.
WHO AUDITS · AND WHO IS OBLIGED
Audits are conducted by IRBAI and by Accredited Assessment Bodies accredited under Article 102: independent organisations operating within defined scopes of accreditation, under IRBAI oversight. No body audits a system in whose development it participated; accreditation is suspended for breach of confidentiality or misuse of audit instruments. In the Foundation Model class, evaluators additionally hold AIFM-EVAL certification.
The obligation runs beyond developers: computing infrastructure providers serving Systemic and High Risk certified systems maintain records sufficient to verify systemic-designation thresholds, with access controls enabling post-hoc attribution of compute usage (Annex II Part 5; Article 120). Developers of systems subject to certification under Chapter 14, above all High Risk and Systemic systems, register metadata in the Global Model and Dataset Registry: architecture category, approximate training compute, data categories, deployment footprint, and known limitations. Routine model updates do not touch the Registry; entries are refreshed at each certification renewal, and earlier only where a registered parameter materially changes (Annex II Part 6; Article 118).
CADENCE · WHEN AUDITS OCCUR
A certificate does not remain valid on its own. It is subject to periodic reassessment at the intervals fixed by the Statute, and to reassessment outside those intervals where the system or its circumstances change.
FOR AUDITED ENTITIES · WHAT TO EXPECT
Scheduled renewal, the Systemic testing cycle, material change to the system, and for-cause initiation under Article 116, including audit-log signals, incident reports, and credible third-party reports of non-compliance.
Raw weights and training data never leave your control: verification is cryptographic first, and any required access runs through the Annex II Part 4 mechanisms inside attested environments. Access is logged, purpose-bound, and protected by the confidentiality provisions of Chapter 16.
Findings ground proportionate consequences on the Article 138 ladder (certificate conditions, suspension, and beyond) and administrative penalties within the Article 106 ceilings. A material gap between submitted and independently measured capability is itself a certification finding and may trigger reclassification review (Article 97).
Yes. Every adverse decision carries the Article 144A guarantees of written notice, access to the evidence relied upon, opportunity to respond, and a reasoned decision, and is appealable to the independent Appeals Panel under Article 43.
Yes. Before deployment, assessment is the certification procedure of Chapter 14: design, capability, and safeguards, measured at the elicitation ceiling. Once deployed, Chapter 16 audit adds operational evidence: append-only logs, incident and near-miss records, and the handling of certificate conditions.
IRBAI auditors, or an independent Accredited Assessment Body accredited under Article 102 and operating under IRBAI oversight. Accredited bodies conduct inspections, documentation reviews, and interviews, and their findings carry the same standing; a body never audits a system it helped develop.
Certification is withheld for the assessed configuration until the findings are remediated. IRBAI defines the corrective actions and the re-assessment procedure, and escalation de-escalates upon remediation (Article 138); a restricted configuration may be separately assessed while remediation proceeds.
Maintain the Annex II artifact set continuously (documentation, append-only logs, cryptographic commitments, SBOMs, current Registry entries) and run internal evaluations to the same adversarial standard. An audit then verifies what already exists, rather than reconstructing it.