When the AI policy meets the audit file
Most finance organizations now have an acceptable-use policy for generative AI. Far fewer can produce evidence that model use inside the reporting process is controlled, tested, and reviewable.
A policy is a statement of intent. A control is something an auditor can test. Over the past two years most finance organizations have produced the first and comparatively few have produced the second, and the distance between them is where AI has quietly become an internal-controls issue rather than a technology one. The question facing CFOs in the next reporting cycle is not whether the company permits generative AI, but whether the company can demonstrate what it did with it.
The exposure is in the reporting process, not the pilot program
Boards have spent considerable attention on AI strategy - where it creates value, which functions adopt it first, how the spend is justified. That conversation has largely bypassed the narrower and more immediate question of whether AI-assisted work has entered processes that feed the financial statements. It usually has, and rarely through a formal implementation.
The realistic entry points are mundane. An analyst uses a general-purpose model to summarize contract terms feeding a revenue-recognition judgment. A shared-services team drafts accrual narratives with a copilot embedded in the productivity suite. A treasury group uses a vendor's forecasting feature that quietly changed models in a release note nobody read. None of these are rogue actors; all of them can affect an amount, a disclosure, or a judgment that a control was designed to govern.
The control implication is specific. If a reviewer signs off on an account reconciliation whose supporting analysis was machine-generated, the control's design assumption - that a competent person exercised judgment over source data - may no longer hold. That is a design deficiency question, and it does not resolve itself by pointing to an acceptable-use policy on the intranet.
What 'auditable' actually requires
The practical test is whether a third party can reconstruct, after the fact, what tool was used, on what inputs, by whom, under what review. Most organizations fail that test not because the underlying work is poor but because nothing captured it. Chat interfaces leave no audit trail in the accounting record. Copilot output is indistinguishable from typed text in a spreadsheet cell.
Closing that gap means treating AI use like any other information-processing dependency. Three things generally have to exist. First, an inventory: which tools are approved for which processes, refreshed as vendors ship features rather than as an annual exercise. Second, an attribution mechanism - tagging, workpaper disclosure, or system logging - that marks where model output entered the work product. Third, a documented review step calibrated to risk, where the reviewer is attesting to the substance and not just the existence of the output.
There is also a completeness problem on the vendor side. Enterprise software increasingly embeds model functionality into modules that were previously deterministic. A SOC 1 report obtained eighteen months ago may not contemplate the feature the vendor enabled last quarter. Reviewing service-organization reports for changes in processing logic - and asking vendors directly what changed and when - belongs on the controls calendar, not the procurement one.
The governance structure most finance teams are missing
AI governance committees tend to sit in technology or legal, and they tend to focus on data privacy, IP leakage, and reputational risk. Those are real, but they are not the internal-control-over-financial-reporting question. Someone in finance has to own the narrower scope: which AI uses touch the reporting process, and are they in the control framework.
That owner is usually the controller or the head of internal controls, not the CFO personally, and the assignment should be explicit. The deliverable is not a policy refresh. It is a mapped set of processes, an assessment of which existing controls' design assumptions are affected, and a testing approach that internal audit and the external auditor have both seen before period-end rather than during fieldwork.
The timing argument matters. Deficiencies identified by management, remediated, and documented are a different conversation than deficiencies surfaced by an auditor in a year-end walkthrough. The cost of the second version is not only remediation work but the credibility discount applied to everything else management asserts about its control environment.
Questions worth asking this quarter
Start with a straightforward inquiry to process owners in record-to-report, order-to-cash, and procure-to-pay: where is anyone using a model, formally or informally, in work that feeds the close? Expect the informal answer to be larger than the formal one. That gap is the finding.
Then ask what evidence would exist if someone challenged a judgment six months from now. If the honest answer is a spreadsheet and a person's recollection, the control has a documentation weakness regardless of whether AI was involved - AI simply makes it more likely someone asks.
Finally, ask whether the review controls sitting on top of AI-assisted work are performed by people equipped to catch a plausible-sounding error. Model output fails differently from human output: it is fluent, internally consistent, and occasionally wrong in ways that survive a cursory read. A review control designed to catch transposition errors and missing signatures is not designed for that failure mode, and saying so in the control documentation is more useful than pretending otherwise.
Key takeaways
- An acceptable-use policy is not a control; auditors will ask for evidence of what was used, where, and who reviewed it.
- AI most often enters the reporting process informally - through embedded vendor features and individual analyst workflows - not through a sanctioned implementation.
- Review controls designed for clerical error are poorly calibrated to fluent, confident, incorrect model output; the design assumption should be reassessed and documented.
- Service-organization reports obtained before vendors embedded model functionality may no longer cover current processing logic.
- Assign explicit finance-side ownership of AI in the ICFR scope, separate from the enterprise AI committee, and surface findings before year-end fieldwork.
