The first line builds and owns. The second line sets standards, challenges, decides, and monitors. The third line answers the question neither of them can answer about itself:is any of this actually true?
Internal audit provides independent assurance to the board and the audit committee that the risk management framework is designed appropriately and operating effectively. In an AI context that mandate is unchanged, but the subject matter is unfamiliar enough that many audit functions are still working out what testing even looks like.
What the Third Line Is For
The distinction between the second and third lines is frequently muddled, and the muddle is consequential. The second line is a control function: it participates in decisions, sets standards, approves systems, and owns part of the outcome. The third line is an assurance function: it does not participate in decisions, and it tests whether the first two lines are doing what they claim.
That difference produces a rule audit must protect carefully: the third line does not design the controls it audits. It is a natural request:audit often holds the deepest institutional understanding of control design, and a new AI risk function will ask for help. But an audit function that helped write the tiering rubric cannot later provide independent assurance that the rubric is sound. Advice may be given on emerging practice in general terms; ownership of the framework must remain with the second line.
Independence for the third line is likewise structural: a reporting line to the audit committee rather than to management, an unrestricted right of access to systems, logs, and evaluation evidence, and freedom to determine its own audit plan.
What Audit Should Actually Test
AI audit work divides into three questions: is the framework designed adequately, is it operating as designed, and does the reality on the ground match the reporting?
Design adequacy
Does an approved AI risk policy exist, with a clear scope definition that covers generative and agentic systems rather than only traditional models?
Is the tiering rubric documented, versioned, and defensible, and does it address action authority, goal boundedness, reversibility, and self-modification, not merely data sensitivity?
Are minimum control requirements defined per tier, so that proportionality is a rule rather than a judgment made afresh each time?
Are roles unambiguous:who registers, who tiers, who validates the tier, who approves, who may grant an exception?
Does the second line hold genuine approval and veto authority, evidenced in the policy and in its reporting line?
Operating effectiveness
This is where audit does its most valuable work, and it is fundamentally sampling work.
Inventory completeness. The single most important test, and the one that must not be performed by reading the inventory. Audit should reconstruct the population independently, from enterprise model API consumption, procurement and vendor records, code repositories, expense data, and interviews, and compare that reconstruction against the register. The gap is the finding.
Tier accuracy. Sample registered systems, re-score them independently against the rubric, and compare. Systematic under-tiering that the second line is not correcting indicates a validation step that is nominal.
Gate compliance. Sample high-tier systems in production and confirm each completed the required review before release, with evaluation evidence against a defined threshold.
Condition follow-through. Sample approvals granted with conditions and verify the conditions were implemented and are still in force. Conditions that decayed after go-live are a common and material finding.
Human checkpoint reality. Do not test whether a checkpoint exists; test whether it works. Examine override rates, time spent per review, and the information presented to the reviewer. A checkpoint with an override rate near zero and a median review time of a few seconds is a control in name only.
Change management.Sample systems whose model version, data sources, or tool permissions changed after approval, and confirm they were re-tiered and re-reviewed.
Escalation records. Confirm that escalations occurred where policy required them, and examine cases where the second line raised a concern that was overruled, including whether the acceptance was documented by a body with authority to accept the risk.
Reporting integrity
Audit should test the numbers the second line reports upward. Does reported coverage reflect a defensible estimate of the true population or only the registered one? Are incidents reported completely, including near misses? Are open exceptions and waivers aged honestly? Reporting that consistently shows strength while sampling reveals gaps is itself a significant finding, because it means the board is governing a picture rather than a portfolio.
Evidence the Third Line Should Expect
A well-run program makes audit straightforward, because the control produces its own evidence as a byproduct of operating. Audit should expect to obtain, without special effort on anyone's part: the inventory with full history; tier assignments with validation records; review decisions with reasoning, conditions, and approver; evaluation results with methodology, test sets, and thresholds; immutable action logs for agentic systems, including proposed actions, policy decisions, human approvals and rejections, and executed effects; monitoring output and drift alerts; incident records with root cause; and escalation packets with committee decisions.
When these must be assembled specially for the audit, that is itself the finding. Evidence produced on request describes what people remember. Evidence produced by the system describes what happened.
Auditing Agentic Systems Specifically
Agentic systems require testing that traditional application audit does not contemplate.
Permission reconciliation. Compare what the agent is documented to do against what its credentials and tool access technically permit. The gap between purpose and capability is where the material exposures live, and it is almost always wider than the documentation implies.
Action replay. Select executed actions from the logs and reconstruct the full chain: what the agent proposed, on what evidence, how the policy layer classified it, who approved it, and what effect followed. If the chain cannot be reconstructed, the logging control has failed regardless of what the design document says.
Boundary testing.Attempt, in a controlled environment and with appropriate authorization, to induce the agent to act outside its intended scope, including through content it retrieves rather than only through direct instruction. Prompt injection through retrieved material is a live vector that many first-line evaluations do not test.
Self-modification check. Verify that the rules, prompts, and objectives running in production are the ones that were approved, and that no runtime mechanism allows the system to alter them.
Kill switch test. Exercise it. An emergency stop that has never been invoked is an assumption.
The Capability Problem
Audit functions face a genuine difficulty here: this work requires skills most internal audit teams do not currently hold. Reading an evaluation methodology, assessing a retrieval pipeline, interpreting an action log, and reasoning about tool permissions are technical tasks, and an auditor who cannot perform them will test documentation rather than reality: confirming that a policy exists and a form was completed, which provides the appearance of assurance without its substance.
There are three workable responses, and most functions will need a combination: build specialist capability within audit, co-source technical expertise while retaining audit ownership of judgment and conclusions or rotate technologists into audit for a period. What does not work is auditing AI with document review alone. The finding will always be that the paperwork was in order.
How the Three Lines Fit Together
It is worth restating the whole structure plainly, because the model's value lies in the separation being genuine.
The first linebuilds, owns the risk, operates the controls daily, evaluates before release, and escalates when something goes wrong. It cannot provide independent assurance about its own work: not from weakness, but from position.
The second line sets the standard, validates tiering, challenges independently, approves or conditions or declines, monitors the portfolio, embeds controls into the architecture, and reports honestly upward. It participates in decisions and therefore owns part of the outcome, which is precisely why it cannot audit itself.
The third line tests all of it and reports to the audit committee, owning no part of the outcome it examines.
When one line absorbs another's role, the structure collapses quietly and looks fine on an organization chart. A second line that helps build the systems it approves is marking its own homework. An audit function that designed the framework is auditing its own design. A first line that self-certifies is providing no assurance at all.
Where the Three Lines Leave Off
Two themes have run through the articles so far:
AI does not require a new risk framework so much as a serious rebuilding of the existing one. Inventory, tiering, gating, challenge, measurement, escalation, and assurance are old disciplines. What is new is the object being governed: probabilistic, general-purpose, opaque, frequently third-party, and, in its agentic form, capable of acting rather than merely advising. Each old discipline has to be re-derived for that object rather than assumed to carry over.
The rules are arriving more slowly than the technology, and will continue to. Supervisory guidance in the United States has been revised without bringing generative and agentic systems into scope. The European framework is sequencing its obligations over years. State and national regimes are moving independently and inconsistently. An organization waiting for a rulebook will deploy for years without one.
The three lines describe how an organization governs what it controls. The remaining articles in this series will turn to what sits around that structure:the third-party estate that it does not control, the mechanics that operate when a control fails, the privacy, security and regulatory terrain it must be conversant in, and the operating model and build sequence that make the whole thing function in practice.
Explore more: Start Here · Topics · Archive · About