What belongs in an AI risk report from Internal Audit?

Include the audit objective, period, population, scope, criteria, control owners, procedures performed, sample basis, findings, management actions, target dates and evidence limitations. Significant findings should trace to workpapers. Keep raw operating metrics in an appendix unless they explain a tested condition. The audit committee needs the conclusion and its basis, not a copy of the operations dashboard.

How should Internal Audit test the AI inventory?

Start with management's register, then reconcile it against independent sources such as observed model destinations, identity applications, procurement records, expense data and vendor disclosures. Investigate unexplained entries and document sources that remain outside visibility. Repeat the reconciliation after material application, vendor or routing changes. The procedure should state the period covered and how the team handled local or supplier-embedded AI.

Can Internal Audit rely on AI gateway logs?

Auditors can rely on gateway logs after testing the relevant controls over completeness, accuracy, integrity, retention and access. They should reconcile source events to stored records and inspect configuration changes during the audit period. Gateway logs cover only traffic routed through that control point, so the reliance statement must exclude local execution, bypass routes and supplier-internal model calls unless separate evidence covers them.

Who owns remediation after an AI audit finding?

Management owns remediation and risk acceptance. The finding should identify an accountable executive or control owner, agreed action, target date and evidence required for closure. Internal Audit validates closure according to its methodology and reports overdue or ineffective action to the proper oversight body. The auditor should avoid designing and operating the fix because that can impair independence.

AI Risk Reporting for Internal Auditors: Evidence Before Dashboards

An internal auditor needs to move from a reported AI control to the evidence that proves it operated. The chain is simple to describe: inventory entry, assessed risk, control objective, owner, test procedure, sample, exception and remediation. Break one link and the dashboard becomes management's assertion. I think a polished maturity score is one of the least useful things an audit committee can receive when the underlying sample is missing.

TL;DR

Build the report around audit scope, control objectives, test procedures, samples, exceptions and remediation owners.
Reconcile the approved AI inventory with observed model traffic and investigate every unexplained route or service.
Preserve Internal Audit independence. Management owns controls and remediation; auditors test the evidence and communicate results.
HTTP AI traffic records support control testing, but local models, embedded vendor AI, human oversight and legal conclusions need separate evidence.

Start with the auditable population

The report needs a defined population before it needs a chart. List each in-scope AI use, business owner, model provider, application, data class, user group, deployment state and applicable obligation. Mark how the audit team established completeness. Management's register is one source, observed HTTP model destinations are another, and vendor questionnaires may reveal embedded AI that neither source captures.

The NIST AI Risk Management Framework gives this work a clear structure. Its Govern function calls for an AI inventory, defined responsibilities and periodic review. Map establishes the context in which a risk appears, while Measure examines and documents that risk. Manage covers treatment, monitoring and plans for incidents or events. Internal Audit can turn those functions into an assurance map without claiming that NIST itself certifies the organization.

A population reconciliation belongs near the front. Show registered systems, observed systems, supplier-reported functions and unresolved differences.

Every control needs a test procedure

A control description such as "sensitive prompts are blocked" is an assertion. The audit report should state the control objective, owner, frequency, system boundary and exact test. For an HTTP control, the procedure might select approved routes, submit permitted and prohibited test cases, verify the policy decision, and trace each result into the audit record. Record the environment and policy state so another auditor can repeat the work.

The Institute of Internal Auditors says the Global Internal Audit Standards provide the basis for evaluating the quality of internal audit work. Domain V covers planning engagements, conducting work to develop findings and conclusions, collaborating on action plans and communicating results. An AI risk report should therefore expose the path to the conclusion. A control rating without the procedure, sample and exception criteria gives the audit committee no way to judge the work behind it.

On screen, the useful view resembles a workpaper index: control ID, test date, sample link, result and reviewer.

Inventory reconciliation finds reporting gaps

Approved tool lists drift as developers add endpoints, employees install assistants and vendors introduce AI functions. Reconcile the inventory against network or gateway observations, identity records, expense data, procurement records and supplier attestations. Gateway observations expose model destinations, while procurement and supplier records expose embedded features.

The Cursor compliance review demonstrates why application approval and route discovery belong in the same test. An application name alone says little about the models reached by a given release or configuration. The auditor needs evidence tied to the actual deployment.

The AI vendor risk review for higher education adds the supplier side. Embedded AI may sit behind a vendor's application boundary, so direct model traffic from the institution may never appear. Contract terms, product documentation and supplier responses become part of the population evidence. Record that limitation rather than forcing a false completeness claim.

Exception reporting should preserve context

Exceptions need enough detail to support a finding. Show the control objective, condition observed, evidence, affected population, cause, consequence, responsible owner and agreed action. Keep management's response distinct from the auditor's conclusion. A red icon cannot carry that context.

NIST AI RMF Manage 4 addresses post-deployment monitoring, incident response, recovery, change management and communication of incidents or errors. Those activities create evidence Internal Audit can test. The auditor can select changes, trace approval and implementation, then inspect the operating record after release. For incident handling, the test can compare the source event, escalation timestamp, investigation, closure evidence and any control update.

Avoid compressing unlike exceptions into one rate. An unregistered endpoint, a failed sensitive-data policy and a late vendor review have different owners and consequences. Group them by control objective, then show aging and remediation status. The audit committee can see where accountability has stalled.

Independence changes the reporting language

Management owns the AI inventory, risk acceptance, controls and remediation. Internal Audit provides independent assurance over design and operation. The report should keep those roles visible. Phrase findings as tested conditions, criteria, causes and effects. Label management assertions as assertions until the audit procedure supports them.

The IIA standards page places Internal Audit under board authorization and oversight, with the chief audit executive responsible for managing the function and communicating with stakeholders. In AI reporting, that means the business cannot grade its own control and present the grade as audit assurance. Management may operate the dashboard. Internal Audit tests the data, method and selected evidence behind it.

This separation also protects the auditor when technical scope is incomplete. State the population, exclusions and reliance clearly. If local models were outside the procedure, say so. If a vendor supplied only a current attestation, identify the period and evidence limit.

HTTP evidence has a precise boundary

For traffic that passes through an AI gateway, an auditor can test records containing supplied identity context, endpoint, timestamp, data classification, policy and decision outcome. That supports procedures over authorization, routing, sensitive-data handling and record completeness. The auditor should still test record integrity, retention, access and the reconciliation between source traffic and stored events.

The Utah AI Policy Act compliance checklist uses owners, evidence and completion conditions for each legal test. Internal Audit can use the same pattern for control testing without adopting the legal conclusions in that article. The audit criterion comes from the organization's obligation and policy; the operating record proves or disproves performance within its boundary.

DeepInspect's boundary is authenticated HTTP traffic between users or agents and LLM endpoints. It cannot observe local model execution, STDIO transport or AI embedded entirely inside a supplier's service. It also cannot assess human review quality or issue an audit opinion. The report should identify separate procedures for those areas.

Reporting to the audit committee

The audit committee view should lead with scope, significant findings, overdue remediation, accepted risk and evidence limitations. Add the complete control matrix as an appendix or linked workpaper. Each significant finding needs an owner and target date, while accepted risk needs the approving authority and review point.

Use plain labels that state what the test established. "Effective" should mean the tested control met defined criteria for the stated period and sample. "Partially effective" should point to a specific exception. If evidence was unavailable, report a scope limitation rather than guessing performance.

A useful committee page can fit on one sheet of paper. Put the three or four material findings in the center, remediation aging at the right edge, and the scope statement across the top. The evidence remains one click away.

DeepInspect

DeepInspect provides a testable control point for authenticated HTTP traffic between users or agents and LLM endpoints. It evaluates supplied identity, route, prompt data and policy before forwarding a request, then records the decision. Internal Audit can use those records as one evidence source after testing completeness, integrity and access controls.

Book a demo today.