Stay connected: follow us on LinkedIn and explore more at
www.CherryHillAdvisory.com.
.svg)
.png)
Subscribe now to join the Risk Register community:
FEI's Committee on Corporate Reporting released its AI Framework for Internal Control Over Financial Reporting in June 2026. It is the first practitioner-built guide for scoping, controlling, and evidencing AI inside the financial reporting chain. Here is what it actually says, where the bar moves for SOX teams and internal audit functions, and the work to start now.
For two years, AI in financial reporting has been a conversation in the abstract.
Everyone agreed it was already in the close, the reconciliation, and the disclosure draft. Almost nobody could tell you how to control it under SOX, or what evidence an external auditor would accept.
That gap just narrowed.
In June 2026, FEI's Committee on Corporate Reporting, a group of Chief Accounting Officers and Controllers from Meta, Walmart, ServiceNow, and Alphabet, published a framework for managing AI risk inside ICFR. It is built directly on the SEC's definition of ICFR and maps cleanly to the 2013 COSO framework your SOX program is already based on.
This is not another think piece on AI governance.
It is a scoping-and-controls manual written by the people who sign 302 certifications. If your finance function is putting AI anywhere near the numbers, this is the document your audit committee will eventually ask you about. Most committees are not aware of it yet, which is exactly why the proactive step matters: brief the audit committee and finance leadership on the framework before it lands on their agenda from somewhere else. We read all 55 pages.
Below is what matters for SOX and AI governance, and what we would do about it.
FEI's Committee on Corporate Reporting just published the first practitioner-built framework for controlling AI inside financial reporting. If AI is anywhere near your numbers, here is the whole argument before the detail:
Before the framework gets to controls, it makes the foundational point, and it is the right one. AI does not change how you define materiality, evaluate risks of material misstatement, or determine which accounts and assertions are in scope. Management's responsibility for ICFR effectiveness is unchanged, and it is still evidenced by the Section 302 and 906 certifications.
What changes is how risk manifests. A static logic error becomes model drift. A transposition becomes a hallucination. The risk taxonomy expands, but the bar, reasonable assurance that material misstatements are prevented or detected on a timely basis, does not move. Full stop.
That framing kills the two failure modes we see most often. The first treats AI as exempt from SOX because it is new and hard. The second treats AI as so dangerous that it gets a bespoke parallel control regime disconnected from the existing program. The framework rejects both. AI is additive to the internal controls you already run over financial reporting, not a replacement, and not an exception.
The framework is explicit that it supplements the 2013 COSO Internal Control Integrated Framework rather than replacing it. That lineage is not incidental. FEI is one of the five organizations that sponsor COSO, alongside the IIA, the AICPA, the American Accounting Association, and the Institute of Management Accountants. The people who wrote this framework are extending a control model they helped build. The AI governance and oversight controls map to the Control Environment. The AI-specific risk identification and the requirement to fold AI vectors into your fraud risk assessment map to Risk Assessment, including Principle 8. The four control approaches it lays out (covered below) are Control Activities. The auditability and evidence requirements live in Information and Communication. Outlier and performance monitoring is Monitoring Activities.
If you run a COSO-based SOX program (and you do) this framework slots in. It does not ask you to start over. It asks you to extend what you already have to a class of systems that does not behave like the deterministic technology your program was built around.
The single most useful contribution here is on scoping, because scoping is where most companies will either over-engineer themselves into an unauditable mess or under-scope themselves into a material weakness. Three points stood out.
The framework is explicit that reliance often lives in the intermediate steps. Take an accounts payable process where AI extracts invoice data, classifies the expense, and routes for approval. Even if a human triggers the final payment, you are relying on the AI's extraction and classification for accuracy and completeness. If any component activity is necessary to mitigate a risk of material misstatement, the AI system is in scope. Teams that scope only the final number will miss this, and so will their auditors, right up until they do not.
Many AI systems are a mix of probabilistic models and deterministic workflows. The framework warns against fragmenting a single system into its component models, pipelines, and rules for SOX scoping. Fragmentation creates an onerous compliance burden and, worse, can miss the failure where every part works but the integrated output is materially wrong. Define the system boundary from data ingestion to financial impact, and test the outcome.
When AI does the work and a human or a non-AI control validates it, that is one compliance path. When AI is the control (reviewing expense reports to flag policy violations, for example) the bar is higher, and you owe the more rigorous validation procedures. Getting this distinction wrong is how teams end up with a control that does not actually control anything.
This is the same scoping discipline we apply in our SOX compliance work, extended to systems that do not behave deterministically.
The honest obstacle with AI has always been the black box. You cannot trace the decision pathway of a large language model the way you re-perform a spreadsheet formula. Auditors need to follow the flow of a transaction, and the model will not show its work in a way you can reliably reproduce.
The framework's answer reverses the question, and it is the most important conceptual move in the document. Rather than auditing the code or the decision process inside the box, you test governance practices and validate outputs. You gain comfort from evidence that the system is operating as expected, not from an explanation of how it reached a specific result. That reframe is what makes the rest of the framework workable. It also lines up with where the assurance profession has been heading on AI: when the reasoning is not reproducible, the control has to live at the boundary, on the inputs and the outputs.
The framework lays out four AI business control approaches. None is presented as the answer. They are a menu, and most companies in early adoption will run a combination.
A human validates the AI output before it is finalized. The framework treats this as the starting point for most AI control environments, and rightly so. HITL gives you the highest assurance and the clearest evidence. It is also the most expensive, and it carries a specific failure mode we will come back to.
Run curated test data with known correct answers through the system on a recurring basis, and compare. Best for high-volume, similar transactions with a defined range of outcomes. The framework is careful here: the test data has to represent the population, including the bad scenarios the system should reject, not just the clean ones it should process.
Run an independent challenger model in parallel and flag disagreements for review. The logic is sound (two independent models making the identical mistake is unlikely), but only if the models are genuinely independent. The framework's design considerations are worth reading closely: separate context windows, parallel execution, different vendors, different versions, different prompts. If your challenger shares the primary model's bias, you have built two witnesses who will lie the same way.
Monitor the full population for anomalies, drift, and trend breaks. Broad coverage, lower precision. The framework is candid that analytics alone is usually not precise enough to be the only key control, but it is a strong second layer.
The strategic arc across all four is what audit leaders should internalize. You start with heavy HITL because the system is unproven. As reliability is demonstrated over time through testing and monitoring, you can justify reducing human oversight and moving toward a human-on-the-loop model, where people monitor and intervene on exceptions rather than validating every transaction. That transition has to be earned and documented. It is not a cost-cutting decision. It is a risk-based one.
Shadow reliance is the insight we would put in front of every audit committee. The framework also calls it over-reliance. A process is documented as Human-in-the-Loop, technically a non-reliance control, but in practice the human reviewer has become dependent on the AI's speed and apparent accuracy. They are rubber-stamping. The control exists on paper and has quietly stopped operating.
The pattern gets worse precisely as the AI gets better, because a system that is right 99 times in a row trains the reviewer to trust the hundredth without looking. Your control degrades silently, and your documentation says everything is fine.
The framework's mitigations are practical: rotate the people performing the review, require certifications that the procedures were actually performed, run periodic secondary reviews, retrain on expectations.
We would add one thing from experience. Test the reviewers, not just the model. Seed a known error into the population occasionally and confirm the human catches it. If they do not, your HITL control is theater, and you want to know that before a misstatement slips through it.
The evidence model moves with the control model. You are no longer just retaining transactional support. You are retaining the AI system's configuration and any changes to it during the period: model versions, prompts, parameter settings, workflows. You are retaining performance testing results, training and inference data governance, and a full outlier resolution trail that traces every flagged anomaly from detection to conclusion.
Two practical notes the framework makes that will save teams real pain. First, prompts are now a controlled configuration item. A prompt change is a change to the system that produces your financial data. It belongs in your change management and SOD program, the same as a code change. Most companies are nowhere near this today. Second, and the framework is emphatic on this, involve your external auditor early, in the design phase. AI in the financial reporting chain is novel enough that you do not want to discover at year-end that your control design produces evidence the auditor will not accept. Align on approach and evidence standard before you build, not after.
Your vendors are embedding AI into the systems you already rely on (the ERP, the close tool, the contract reviewer) often without announcing it in a way your SOX program will catch.
The framework's guidance is direct. Read SOC 1 reports in their entirety for AI use, with specific attention to whether vendors are carving AI-assisted processes out of their assertions, explicitly or through broad exclusions. Monitor release notes for new AI features. Request documentation on which modules use AI. The risk is not just that the vendor's AI is flawed. It is that AI risk has quietly moved into a system you stopped scrutinizing because last year's SOC 1 was clean. That report may no longer cover what you think it covers.
This is the same vendor-and-third-party discipline we have been writing about in our SEC cybersecurity disclosure two-year review, now applied to the AI quietly entering your financial systems through the back door.
If you lead an internal audit and/or SOX function and AI is anywhere near your numbers, six actions are worth taking in the next 90 days.
The framework's closing point is the right one to land on. This is a living document, and the technology will outrun it. The objective has not changed since SOX was written: reasonable assurance that financial statements are free of material misstatement. AI changes the how. It does not change the obligation. That obligation still sits with management.
The framework just gave you a defensible way to meet it. The next disruption is already on the way, and the program that handles it well is the one that absorbed this framework first.
The FEI AI Framework for Internal Control Over Financial Reporting was published by FEI's Committee on Corporate Reporting in June 2026 and is available through Financial Executives International. This article is Cherry Hill Advisory's independent analysis and is not affiliated with or endorsed by FEI.
If you need help scoping AI into your SOX program, designing AI control approaches, or stress-testing your existing controls for shadow reliance, Cherry Hill Advisory's AI Governance and Emerging Risk practice and SOX advisory team work alongside internal audit and finance leaders to build AI controls that withstand audit committee and external auditor scrutiny.
If AI is already near your numbers, we can help you build the controls before the questions arrive.
Subscribe to The Risk Register for practitioner analysis on internal audit, SOX, AI governance, and emerging risk.
Subscribe now to join the Risk Register community:
