The AI Learning Hub Journal

The Numbers a Model Helped Produce

The client got there firstwhether or not the engagement uses any AI at all, the client almost certainly does — and nobody asked the audit teamWHERE MODELS ALREADY SIT IN THE CLIENT’S REPORTING — NONE OF IT NEEDED THE AUDITOR’S AGREEMENTexpected-credit-loss andprovision models set theprovisions and theimpairmentsvaluation models producefair-value marks forpositions nobodytradesfraud and anomaly filtersdecide which transactionsa human being everlooks atautomated postings writejournals no clerk has reador authorisedone by onemuch of it arrived without an announcement — a vendor upgrade, a transformation project, a filter operations switched on because volumes demanded itTHE FILTER SITS IN FRONT OF THE TRANSACTION POPULATIONthe full transaction populationthe model’s filterwhat a human investigateswhat nobody ever examinesso the model decides what managementitself ever investigates — and thereforewhat ever surfaces as an exceptionfamiliar audit territory with a new resident — the same assertions and accounts, but a process step learned from data, not written in a manualTWO ENGAGEMENTS, ONE POPULATION OF MODEL-TOUCHED NUMBERSTHE TEAM THAT ASKSfinds out what is there — the ordinary firstprocedure, needing no data scientist —and plans the response knowinglyTHE TEAM THAT NEVER ASKSstill audits the model outputs, on the silentassumption that the system is a fixedcalculation, tested once and trusted afterlearned components break exactly that assumption — what could go wrong in these processes has always been the risk questionTHE ENGAGEMENT AUDITS THE OUTPUT OF MODELS EITHER WAYthe only decision left to the team is whether it does so knowingly, or by accident
Provisions, marks, filters and postings already carry the client’s models — the audit meets them with or without asking.

The Client Got There First

The dual question has a second half, and it does not wait for the audit team's permission. Whether or not the engagement uses any AI at all, the client almost certainly does. Expected-credit-loss models set provisions. Valuation models produce fair-value marks for positions nobody trades. Fraud filters decide which transactions a human being ever looks at. Automated postings write journals that no clerk has read. None of this needed the auditor's agreement, and much of it arrived without an announcement — a vendor upgrade here, a finance-transformation project there, a filter that operations switched on because the volumes demanded it. The consequence is plain: the numbers under audit are already model-touched, in ways that vary by industry but rarely amount to nothing. The engagement audits the output of models either way; the only decision left to the team is whether it does so knowingly, or by accident.

  • The client's use of AI does not depend on the audit team's — provisions, marks, filters and postings already carry it
  • Fraud and anomaly filters shape which transactions any human at the client ever examines
  • Much of the model footprint arrived quietly, through vendor upgrades and projects finance did not run
  • The team audits model-touched numbers either way; the choice is whether knowingly

Where the Models Sit in the Statements

It helps to walk the statements rather than the technology. Provisions and impairments lean on expected-loss models fed by data pipelines few people can describe end to end. Fair values for thinly traded positions come from valuation models whose assumptions moved during the year. Revenue systems apply automated rules — and increasingly learned ones — to recognition timing and cash matching. Fraud and anomaly filters sit in front of the transaction population, which means they decide what management itself ever investigates, and therefore what ever surfaces as an exception. Automated journal postings mean the ledger contains entries no individual authorised one by one. Each of these is familiar audit territory with a new resident: the same assertions and the same accounts, but a process step whose behaviour was learned from data rather than written in a procedure manual. At this stage the map matters more than the mechanism.

  • Provisions, impairments and fair values rest on models whose data pipelines few at the client can describe
  • Filters in front of the transaction population decide what management ever sees as an exception
  • Automated postings put entries in the ledger that no individual authorised one by one
  • Same assertions, same accounts — but a process step learned from data, not written in a manual

Knowingly or by Accident

The uncomfortable version of this lesson is the engagement that never asks. A team that does not find out where models run will still audit their outputs — it will simply do so on the silent assumption that a system is a fixed calculation, tested once and trusted thereafter. That assumption is exactly what learned components break. Risk identification, which is the territory of the ISAs on understanding the entity and its environment, has always asked what could go wrong in the processes that produce the numbers; a model that management barely understands is a candidate answer to that question, not a specialist curiosity. So the first procedure is not technical, and needs no data scientist. It is the ordinary one: find out what is there. The rest of this module is about how to do that finding out, and what to do with what you find.

  • An engagement that never asks still audits model outputs — on an unexamined assumption of fixed logic
  • Learned components break the assumption that a system tested once behaves the same all year
  • Understanding what could go wrong in the processes behind the numbers has always been the risk work
  • The first procedure is not technical: find out what is there

Prefer slides, quizzes, and saved progress? Read this lesson in the library — free, no sign-up.