Written and maintained by CASRAI Editorial Board
Last updated
An internal audit function checks, periodically and against a written scope, whether an organization’s AI safety commitments are actually being met in practice — not whether something has already gone wrong. That makes it structurally different from an incident response program, which exists to react once a specific event has been detected, and different again from third-party evaluation, which supplies independent credibility to outside stakeholders rather than routine internal verification. An organization can have a well-built incident response program and a clean third-party audit history and still have no function that regularly checks, on its own initiative, whether its day-to-day practice matches what it says it does.
What an Internal Audit Function Actually Does
The core activity is verification, not detection or response: taking the organization’s own stated commitments — a published safety framework, risk register entries, evaluation protocols, escalation procedures — and checking, on a defined cadence, whether the evidence shows they were actually followed. That is a different question from “did anything go wrong,” which is what triage in an incident response program asks. An audit can conclude that a required pre-deployment evaluation was skipped, or that a risk register entry hasn’t been updated in two review cycles, without any incident having occurred at all — and catching that gap before it produces an incident is the point of running the check on a schedule rather than waiting for a trigger.
For the function to produce a finding anyone can rely on, it generally needs three things in place:
- A written scope and mandate naming what it checks against — the organization’s own safety framework commitments, risk register, and (where applicable) statutory obligations — rather than an open-ended review of “AI safety” in general.
- Independence from the function being audited. The team that runs pre-deployment evaluations should not also be the team that audits whether those evaluations happened on schedule and were documented correctly; the value of the finding depends on the auditor not having a stake in the result.
- A defined cadence, set in advance rather than triggered by events, so gaps surface on a predictable timeline instead of only when something else forces a look.
How It Differs From Incident Response
The two functions are easy to conflate because they can draw on the same underlying documentation — the same risk register, the same safety framework — but they run in opposite directions. Incident response starts from an event and works backward to classification and reporting; it is reactive by design, and its job is narrow and time-pressured once a candidate event surfaces. An audit function starts from the organization’s own written commitments and works forward, checking whether the practice matches the paper regardless of whether any event has occurred. A mature program needs both, and they should feed each other: an audit finding (a required evaluation wasn’t run, a required sign-off is missing) can itself become a risk register update, the same way post-incident review does for incidents that were actually detected. But routing an audit finding through the incident response program’s triage logic is a mismatch — there is no candidate event to classify, only a gap between commitment and practice to document and remediate.
How It Differs From and Complements Third-Party Evaluation
Third-party AI auditing, as covered in our guide to third-party AI auditing, is an independent outside party assessing a system against an external compliance framework — ISO/IEC 42001, the EU AI Act, or a comparable standard — and producing a result with credibility for regulators, customers, and partners precisely because the auditor has no stake in the outcome. An internal audit function cannot substitute for that outside credibility: it is still staffed by the organization’s own people, and an external stakeholder has no independent reason to trust an internal finding the way it trusts a certification from an accredited body.
What an internal audit function can do that a periodic third-party engagement cannot is run continuously and cheaply enough to catch a gap between certification cycles. Third-party audits and certifications happen on their own cycle — annually, or tied to a certification renewal — and an organization’s practice can drift from its stated commitments in the interval between them. An internal function that checks the same kinds of things on a shorter, self-set cadence is what surfaces that drift before it either causes an incident or shows up as a finding in the next external audit. The two are complementary rather than substitutable: internal audit for continuous self-monitoring, third-party audit for the independent credibility internal review cannot supply on its own.
Where the Audit Function Reports
Internal audit only has force if its findings reach a body positioned to act on them and independent of the function being audited — which is a governance-structure question, not an audit-methodology one. Our comparison of AI governance board, ethics committee, and audit committee oversight covers the three common structures in full; the point specific to an audit function is narrower. An existing audit committee brings financial-reporting and internal-controls expertise and an established, independent reporting line by default — but AI deployment sign-off authority is not inherent to that role. It has to be formally extended through an explicit charter amendment; without that written delegation, routing AI-safety audit findings to the audit committee doesn’t by itself give the committee power to require remediation. Whichever body receives the findings — an audit committee with its charter amended to cover AI, a dedicated AI governance board, or an ethics committee — the reporting line needs to be as explicit as the audit scope itself: named in a charter, not assumed.
What Findings Typically Cover
Because the function checks practice against the organization’s own commitments rather than against a universal external checklist, what it covers varies with what the organization has actually committed to. Common categories include:
- Evaluation and testing cadence — whether pre-deployment evaluations that a safety framework requires were actually run, on schedule, before the deployment they were meant to gate.
- Risk register currency — whether entries have been reviewed and updated on the interval the organization committed to, and whether incidents or near-misses that should have produced an update actually did.
- Escalation and sign-off evidence — whether the roles an incident response program names on paper (a triage owner, a cross-functional review group, an accountable decision-maker) match who actually held those roles and signed off when a candidate event under review required it.
- Documentation completeness — whether the paper trail a large frontier developer needs for a statutory obligation like SB 53’s quarterly risk assessment and transparency report actually exists in a form that supports what the published report claims, rather than being reconstructed after the fact.
An audit function is not itself the source of the standard it checks against — it verifies conformance to whatever the organization has already committed to in its safety framework, risk register, and applicable statutes. Where no such commitment exists for a given area, there is nothing for an internal audit to check practice against, which is itself often the finding worth escalating.
How CASRAI’s NIKOLAI tracks this
The record an internal audit function is really checking against — who signed off on a threshold determination or risk-acceptance decision, and when — is the same artefact CASRAI catalogs independently as the Accountable Decision-Maker and Sign-Off element in NIKOLAI’s Commitments and Governance track (N9), drawn from how Anthropic’s RSP, OpenAI’s Preparedness Framework, and five other published lab frameworks each name a role responsible for that sign-off. An internal audit function’s core question — does the sign-off record match what the framework says should have happened — is exactly the kind of documented-commitment-versus-practice gap NIKOLAI’s element definitions are built to make comparable across labs. NIKOLAI is CASRAI’s own, unendorsed reference project — it does not represent any lab’s official governance process. See NIKOLAI’s Commitments and Governance track.
Frequently Asked Questions
Does a small organization need a separate internal audit function, or can the safety team audit itself?
The independence requirement is what breaks down if the safety team audits its own work — the finding carries little weight if the same people who run the evaluations also sign off on whether the evaluations happened correctly. A small organization can satisfy independence without a dedicated audit department by assigning the check to someone outside the safety team’s reporting line (internal audit, legal, or a designated board member) rather than by skipping the separation entirely.
Is an internal AI-safety audit function the same as a SOC 2 or ISO 27001 internal audit?
They can share infrastructure and even personnel, but the scope is different. A SOC 2 or ISO 27001 internal audit checks controls around confidentiality, integrity, and availability. An AI-safety audit function checks conformance to the organization’s own safety framework, risk register, and AI-specific statutory obligations — categories that a general information-security internal audit program is not scoped to cover.
Does an internal audit finding need to be reported externally the way an incident does?
Not automatically. An audit finding is a gap between commitment and practice, not itself a reportable safety incident under statutes like SB 53 or the RAISE Act. It only intersects with external reporting if the underlying gap it uncovers also meets a statutory incident definition, or if the finding is itself the kind of evidence a required periodic risk assessment or transparency report has to draw from.
Can the internal audit function replace the third-party audit an organization needs for ISO/IEC 42001 or EU AI Act conformance?
No. Certification and regulatory conformance under those frameworks specifically requires an independent outside party with no stake in the result — that is what gives the certification its credibility to regulators, customers, and partners. An internal function can reduce the number of surprises a third-party audit turns up, but it cannot substitute for the third-party engagement itself.
