Who owns AI risk under the Three Lines Model?

In the IIA Three Lines Model for AI, management owns the risks created by AI-enabled activity, including purchased systems. The first line designs and operates controls; specialist second-line roles provide methods, oversight, monitoring, and challenge. Internal audit delivers independent assurance on governance, risk management, and controls. The board oversees the arrangements and asks whether material risks receive adequate attention. These are responsibilities, not mandatory departments or a sequence of approvals. AI governance becomes less reliable when a favorable assessment moves between these roles without its scope, evidence, and limitations. Internal audit can use earlier work, but it must establish why that work supports its own conclusion.^{[1, 2, 3]}

External auditors and AI vendors may supply assurance or technical evidence. Their work does not create an automatic fourth line, and outsourcing a control does not transfer management’s accountability.^[1]

The IIA’s 2026 model permits coordination, not automatic reliance

The IIA refreshed its Three Lines Model: Assurance and Advice in Support of Effective Governance on July 8, 2026. It emphasizes collaboration, integrated assurance, the board’s oversight role, and safeguards when internal audit responsibilities overlap with management activities. The chief audit executive can help integrate assurance information without treating every favorable report as independent proof.^[1]

The distinction matters under Global Internal Audit Standard 9.5. The chief audit executive must coordinate with other assurance providers and consider relying on their work. When internal audit does rely on it, the basis must be documented, and internal audit remains responsible for the conclusions it reaches. The IIA’s 2025 coordination-and-reliance practice guide supports assurance mapping and reliance assessment.^{[3, 4]}

Organizational independence is therefore one question. Evidence quality is another. A second-line validator may have strong technical skills without being the third line; internal audit may have independent reporting lines without having independently measured model performance. Earlier research has also applied the Three Lines framework to AI organizations, particularly their roles and coordination arrangements.^[5]

Three assurance reports can rest on one test

Suppose a product team tests an AI model on historical records. The risk function checks whether the evaluation followed policy. Internal audit later examines whether management established an effective review process. All three reports may be accurate within their own scopes. They are not three separate measurements of the model’s current performance.

An original test can be valid for what it measured and insufficient for a wider, later claim. Independence of the reviewer does not establish independence of the observations. Listing a risk in a taxonomy does not establish that it was tested. A traceable approval proves an action was recorded, not that every operational inference was warranted.

For context, Chen and colleagues classified 496 news-derived AI incidents in a 2025 study. Their results can inform risk categories, but the incident collection does not establish the rate at which deployed AI systems fail.^[14] Argument-based assurance cases already connect claims and supporting evidence; the ICO’s guidance describes that established approach. The additional question here is what a later recipient is entitled to infer from the earlier assessment.^[13]

CEDAR-3L records the evidence transfer

CEDAR stands for Claim, Evidence, Dependency, Assurance, Reliance. CEDAR-3L applies those five fields to a specific instance in which one governance or assurance function reuses earlier AI assessment work. It is an InfoSecured.ai method for assessing cross-line evidence reuse; it is not an element of the IIA’s Three Lines Model.

Claim

The exact property or control asserted now, for whom, over which period, and under whose authority.

Evidence

Original observations, criteria, samples, methods, exceptions, exclusions, and dates supporting that property.

Dependency

Conditions that matter to inference: model version, data, retrieval index, population, supplier, workflow, permissions, and human action.

Assurance

What the previous reviewer actually examined, competence and objectivity, limits, and any shared root data.

Reliance

The receiving reviewer’s permitted conclusion, qualification, further verification, accountable owner, and reopening trigger.

The layers can disagree. A sound model test may no longer represent the live population. Conversely, current test data may support a limited technical claim even if a previous reviewer’s objectivity prevents internal audit from relying on that person’s overall opinion. CEDAR-3L documents the boundary of transfer, rather than producing a universal risk score.

The Cross-Line Reliance Test: six gates

Before adopting a prior assessment, the receiving reviewer asks six questions. Failed or uncertain gates narrow the supported claim or identify the specific verification still needed.

1. 01
   Does the claim match?

   Compare the original property, control, outcome, period, and evaluation criterion with what is being asserted now. Narrow a claim that exceeds the test.

2. 02
   Does the operating context match?

   Check users, affected populations, environments, failure cases, and thresholds. Evaluate differences that could change the inference.

3. 03
   Can the source evidence be inspected?

   Trace summaries to methods, samples, exclusions, negative cases, and exceptions. Missing roots may require alternative procedures.

4. 04
   Have material dependencies changed?

   Review model updates, data and retrieval changes, prompts, tool access, vendors, integrations, and human workflows; target affected properties.

5. 05
   What was independently examined?

   Assess reviewer competence and safeguards, actual procedures, and shared evidence ancestry. Separate process review from technical replication.

6. 06
   Who may decide and what may be said?

   Distinguish operational risk acceptance from audit conclusions; assign outstanding work and describe uncertainty in the correct report.

Record one of four dispositions against the named claim:

These are working decisions, not IIA-issued assurance ratings. A complete record should identify the reason, source links, decision owner, and conditions under which the decision must be revisited.^{[3, 4]}

RISC: when reliance narrows necessary scrutiny

Reliance-Induced Scope Contraction (RISC) describes a proposed failure pattern: a later reviewer reduces planned verification because an earlier favorable review is assumed to cover a material property that the earlier work did not actually test. The concern is unsupported scope reduction, not efficient reuse.

For example, a vendor security report may describe access-control effectiveness within a stated service boundary. If an audit team drops testing of live human-escalation performance because the vendor report was favorable, the intended audit conclusion may have outgrown the evidence. Repeating the vendor’s security tests would add little; obtaining escalation records could resolve the real gap.

Related patterns include assurance echo—several favorable reports counted as separate technical confirmations although they share a root dataset—and assurance-boundary expansion—a scoped control review being used to support a systemwide safety claim. These names describe candidate mechanisms, not measured prevalence.

A workable handoff protocol

1. State the current decision. Identify its recipient, exact claim, period, and materiality.
2. Find the original records. Retrieve tests, samples, source dates, exceptions, and prior reviewer procedures.
3. Compare the boundaries. Track versions, people, criteria, workflows, and shared evidence roots.
4. Assess reviewer suitability. Examine competence, objectivity, procedural depth, and the limits of earlier assurance.
5. Choose proportionate action. Reuse the supported part, commission a targeted test, qualify the conclusion, or escalate the gap.
6. Record reopening triggers. Link follow-up to consequential changes, incidents, evidence expiry, or access restrictions.

Management owns remedial action and operational limits; internal audit determines what assurance its own evidence supports. Lifecycle assurance work on safety-critical AI similarly stresses representative testing, interactions with human operators, and operational challenge beyond model-level metrics.^[12]

Two cases: banking operations and clinical AI

The following two cases are fictional. They illustrate how the same evidence may support one decision but fail to support a later, broader one.

Measure the quality of reliance, not the paperwork volume

Governance dashboards often count completed assessments, approvals, and questionnaires. Those counts say little about whether the later decision follows from the earlier evidence. A smaller set of indicators can expose that difference, provided the sampling frame and review period are explicit.

Negative-case coverage can be tracked against a locally approved test design, but the denominator is the specified scenario set, never all possible failures. The useful report connects each indicator to its evidence boundary, owner, and next decision.

How the reliance decision relates to existing guidance

What remains to be tested

CEDAR-3L’s components overlap with established professional skepticism, assurance mapping, evidence provenance, and argument-based assurance cases. Its contribution is to keep the receiving function’s transfer decision visible. Whether that produces better judgments at an acceptable cost requires comparative study. RISC is a conceptual failure pattern, not an established measured phenomenon.

1. Scope visibility: Do reviewers shown original exclusions and changed conditions accept fewer unsupported broadened claims than reviewers shown only a favorable approval summary?
2. Evidence ancestry: When several reports share one test set, does disclosing the common root reduce mistaken claims of independent corroboration?
3. Detection versus burden: Does the record improve identification of unsupported transfers compared with competent existing assurance mapping, and how much review time or unnecessary retesting does it add?

Machine-readable assessment records could make provenance easier to inspect. Research on structured RDF representation of LLM evaluations, ontology-based AI risk, and FAIR digital objects offers possible building blocks. These studies do not establish CEDAR-3L’s effectiveness or replace expert judgments about evidence sufficiency.^{[15, 16, 17]}

Independent evaluations should measure both false acceptance and avoidable verification. A reliance process succeeds when a reviewer can reconstruct the supported claim, the evidence used, its limits, and the person responsible for acting when conditions change.

Frequently asked questions