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.
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.
