AI Audit vs Internal Control Review

An internal control review asks whether specified controls are suitably designed and operating for their objectives. An AI audit asks the agreed questions about an AI system, which may include controls as well as model behaviour, data, evaluation integrity and human use. The two can overlap substantially. The practical difference is the objective and evidence boundary of the engagement, not a rule that one discipline examines documents while the other examines technology.

For a finance director, chief audit executive or technology owner, the useful decision is whether existing control work answers the AI-related question now being asked. A sound review of payment approval may provide strong evidence about authorisation while leaving recommendation quality unresolved. A model evaluation may show useful predictions while saying little about unauthorised posting. Map the unanswered question before commissioning duplicate work or treating a familiar control report as universal coverage.

Internal audit is broader than a financial checklist

The IIA's Global Internal Audit Standards address the professional practice of internal auditing, including governance, objectivity and the performance of services. Internal auditors can examine technology, operations, risk and AI. It would be misleading to describe internal control review as inherently nontechnical, or to suggest that an external AI specialist automatically has a broader mandate.

Similarly, a technical AI audit may be narrowly scoped. It might inspect a model evaluation pipeline without reviewing financial controls, or test an application boundary without examining the organisation's entire control environment. The title does not define coverage. Compare the purpose, criteria, population, period, competence and access in the actual terms of reference.

A control review can be performed by management, a risk or compliance function, internal audit or an external provider. Their responsibilities and independence differ. The buyer should name the role rather than call every control check an independent audit. An AI audit can also be internal or external; the relevant question is whether the arrangements support the conclusion and intended reliance.

Example: AI recommendations for allocating customer payments

Consider a hypothetical distributor whose AI application suggests which open invoices should receive a customer payment. A receivables clerk reviews the recommendation, and a separate authorised process posts the allocation. The AI cannot approve a write-off or alter bank details. Its value proposition is reducing search time while preserving correct customer and invoice allocation.

A control review might focus on whether only authorised staff post allocations, whether overrides are recorded and whether ledger totals reconcile. An AI audit might additionally ask whether the recommender uses the correct customer context, handles ambiguous references and was evaluated on representative cases without information leakage. Neither set of questions makes the other redundant.

Suppose the posting control prevents all incorrect suggestions in selected cases. That supports a bounded control conclusion; it does not establish that the recommender is fit for its intended efficiency goal. If staff must correct many suggestions, the control may work while the AI business case weakens. Conversely, high recommendation accuracy does not justify removing an approval step whose objective includes fraud prevention or segregation of duties.

Build the bridge from objective to evidence

Illustrative overlap map for payment-allocation recommendations

Objective	Control-review question	Additional AI question
Only authorised allocations reach the ledger	Are posting rights and approval transitions enforced?	Can an AI-generated request bypass or misrepresent that transition?
The correct customer context is used	Are source records complete and access controlled?	Does the recommender confuse similar references or stale customer data?
Staff review is meaningful	Is reviewer identity linked to the final allocation?	Can staff recognise ambiguity, inspect alternatives and challenge the suggestion?
Performance claims are credible	Are management reports reconciled and controlled?	Were test cases independent of development, and are error categories relevant?
Changes remain controlled	Are changes approved and recoverable?	Do model, data and threshold changes trigger appropriate evaluation?

This original map prevents two common mistakes. One is repeating the same access-control test under different programme names. The other is assuming that a shared control answers every AI-specific question. Use the map to identify reusable evidence, additional procedures and areas that remain outside the mandate. Audit coverage mapping helps preserve the difference between examined, partially examined and unexamined objectives.

Design, implementation and operation can diverge

A documented dual-review policy may be well designed but absent from the actual application. A configured approval gate may exist but be bypassed by a background integration. A gate may work in a controlled test while historical records are too incomplete to establish operation over the review period. Each condition leads to a different finding and a different remediation task.

For the payment allocator, an approval field in a database is weak evidence if it can be populated automatically by the recommending service. A human name in the record is also insufficient if the name was copied from a previous event. The reviewer needs evidence connecting the person's decision to the specific customer, invoices, amount and version of the recommendation that was posted.

Where a separate read precedes a later write, the team should examine whether relevant state can change between them. A clerk may approve an allocation based on open invoices that another process closes before posting. The audit question is how the system handles that changed state, not simply whether two screens displayed an approval. The exact solution is implementation-specific; the evidence should show the tested concurrency and failure behaviour.

A walkthrough is useful, but it is not a period-wide test

A walkthrough follows one or a few cases to understand the process and identify where controls operate. It can reveal a missing step and inform the test plan. It does not establish that the control operated throughout a period. A polished demonstration selected by the process owner may avoid precisely the exceptions that matter.

After the walkthrough, define the population of relevant events. For the hypothetical application, this might be payment-allocation recommendations generated in a named environment during a defined month, with separately identified accepted, corrected, rejected and unresolved outcomes. Reconcile the event population to available source and posting records before selecting cases. If the population excludes failed or cancelled attempts, the resulting conclusion needs that limitation.

Sampling should follow the objective. Testing privileged changes, unusually large allocations or ambiguous references can be sensible targeted work, but those selections do not establish an ordinary error rate. A representative performance estimate needs a suitable design and reference labels. The sampling approach should explain why each selection supports its specific conclusion rather than presenting one sample as sufficient for every objective.

Two controls can succeed while the AI still needs attention

In an illustrative review, the team identifies 240 recommendation events and examines 60 selected completed cases. Fifty recommendations were accepted and ten were corrected. Six of the corrected cases initially pointed to the wrong customer, and the clerk caught all six before posting. These invented numbers describe selected cases only; they are not an estimate of the production error rate.

The posting-control conclusion and the model-performance conclusion must be separate. Evidence that the six mistakes were blocked is relevant to the review control. The six wrong-customer suggestions are relevant to the recommender's behaviour and potentially to review workload. The fact that no wrong allocation reached the ledger in those cases does not eliminate the need to investigate the suggestion errors. Nor does it prove that every future reviewer will detect them.

Illustrative interpretation register for selected cases and related evidence gaps

Observation	Supported interpretation	Unsupported extension
Six incorrect customer suggestions were corrected before posting	The review intervened successfully in those six records	Human review will always catch every error
All 60 selected postings reconcile	The examined postings reconciled under the procedure used	Every recommendation was correct or every monthly event was covered
Ten recommendations required correction	Correction work existed in the selected cases	The AI saved no time or has a population correction rate of 16.7%
Separately reviewed rejected events lack retained input context	The reviewer cannot assess those events fully from available records	The missing events were successful or necessarily fraudulent

Compensating controls need an operating argument

Management may accept a model limitation because another control reduces the consequence. That can be reasonable, but the argument needs evidence. Who performs the check? What information is available? How often does the check occur? What happens when the reviewer is absent, overloaded or uncertain? A compensating control should address the same risk and operate early enough to prevent or contain the relevant consequence.

In the example, reconciliation of total cash does not necessarily detect allocation to the wrong invoice when the overall amount remains unchanged. A second control may therefore succeed at its own objective while failing to compensate for the recommendation error. The audit should explain the mismatch without treating the reconciliation control as defective merely because it was never designed to answer that question.

Human review also has capacity limits. If the AI changes the volume or complexity of recommendations, previous evidence about review quality may no longer apply. Examine the actual information shown, exception queues and escalation routes. Human oversight auditing explores the distinction between a nominal approval role and evidence that the person can understand and intervene in the decision.

When existing control evidence can be reused

Reuse can reduce burden when the prior work covers the same control, system boundary and relevant period, and its methods and evidence are suitable for the new objective. Check who performed it, what access they had, how exceptions were handled and whether the control changed afterward. A report title or green status is insufficient; the underlying coverage and limitations matter.

For a shared identity service, earlier work may support aspects of user provisioning. The AI audit still needs to examine how the application consumes those identities and maps them to actions. A correct central role does not prove correct local authorisation. Similarly, a supplier's platform report may leave customer configuration and integration responsibilities outside its scope.

Record the reliance decision in the workpapers. Identify the evidence reused, the claim it supports, the checks performed before reuse and the remaining additional work. If the earlier report cannot be shared or is too old for the current change state, record a limitation or perform alternative procedures. Avoid charging for duplicate work simply because two teams use different terminology, but do not reuse evidence solely to meet a deadline.

Assign ownership without making the auditor the control owner

The process owner owns the payment workflow and its risks. Technology teams operate the application and integrations. Risk, compliance and finance specialists may define or advise on requirements. Internal audit or another appropriately scoped reviewer evaluates the agreed questions. These roles need coordination, but the person who approves a control's operation should not silently become its independent assessor.

When an AI specialist joins an internal audit engagement, clarify responsibility for technical procedures and the overall conclusion. The specialist may evaluate reference labels or replay controlled cases, while the audit team integrates that work with the broader objective. The engagement should explain competence and review arrangements rather than imply that the specialist's presence automatically resolves every technical or independence issue.

If the external firm also built the recommender, disclose the self-review threat and decide what safeguards or independent involvement are needed. Conflict-of-interest assessment belongs in planning. A useful adviser can explain how a control works without being the appropriate party to provide the independent conclusion on that same control.

What an integrated report should say

Organise the report around objectives, not organisational boundaries. For each material objective, show the control evidence, AI-specific evidence, exceptions, limitations and resulting decision. Where a control succeeded but the model underperformed, say both. Where an accurate model sits behind a weak authorisation boundary, preserve that distinction too. Combining them into a single pass mark makes remediation harder.

A finding should identify whether the problem is a design gap, implementation defect, operating exception, unreliable evidence or unresolved model behaviour. Causes should remain hypotheses until investigated. The action owner may differ by finding: finance may revise review instructions, engineering may repair a state transition and data specialists may investigate evaluation quality. The findings register should preserve those responsibilities and closure conditions.

Retesting should address the original objective. If the wrong-customer recommendation is fixed, check relevant ambiguity cases and the review workflow. If the approval boundary is repaired, examine the changed transition and affected integrations. A new model score does not close a posting-control finding, and a corrected policy does not close a model-evaluation defect.

Test whether the control still fits the changed process

A control can operate exactly as documented while no longer addressing the way work is performed. Before AI, the receivables clerk may have assembled an allocation from source records. After AI, the clerk may mostly confirm a preselected answer. The approval step has the same name, but the information considered and the opportunity to challenge may have changed. The review should examine that change rather than assume continuity because the policy text is unchanged.

Ask what evidence the reviewer saw at the decision point. Was the customer reference visible? Were plausible alternative invoices available? Did the interface highlight ambiguity or present one answer with an authoritative explanation? These questions concern the operation of the review control, not merely the model's accuracy. A reviewer can have formal authority and still lack the practical information needed to use it.

Compare selected cases with and without a suggestion where an authorised evaluation can do so meaningfully. The purpose is not to claim that removing AI is always safer. It is to understand whether the recommendation changes the reviewer's attention, error detection or effort. Any comparison needs similar tasks, clear reference decisions and appropriate limits; a few convenient demonstrations cannot establish a causal improvement across the operation.

Separate control dependence from control duplication

Two apparent controls may depend on the same flawed source. If the recommender and the review screen both display a stale customer mapping, the human review may not provide the independent check management assumes. The audit should map what each control relies on, including data transformations and shared configuration. A second step is not necessarily a second source of evidence.

For the allocation workflow, a useful procedure could trace the original payment reference, the mapping used by the recommender and the record shown to the clerk for the same selected case. If all three are consistent, the auditor has evidence about that trace, not proof that every mapping is correct. If they diverge, the investigation can identify where the discrepancy appears before assigning a cause. This gives the control owner a more actionable result than a generic recommendation to add another approval.

Finally, assess whether the existing control report was intended for the same objective. A review focused on financial reporting may have a materiality and population appropriate to that purpose, while a new operational decision asks about customer-level errors or staff workload. The earlier work is not defective because it answers its original question. Reuse what is relevant, state the different objective and design additional work where the new question genuinely requires it.

Commission the gap, not a duplicate label

Bring the existing control report, its scope and limitations, the AI use case and the new decision to the scoping discussion. Ask the provider to mark which evidence can be reused and which additional procedures are justified. The proposed work should explain what the organisation will know afterward that it does not know now. This is a stronger basis for value than buying another broad “AI review” with an overlapping checklist.

Open for AI's AI auditing services can be scoped to complement existing control work. An audit scoping discussion for an AI-enabled control process should begin with the control objective, the system boundary and the unresolved claim. The resulting assessment can then support a precise operational decision without overstating the coverage of either the internal control review or the AI audit.