AI and Internal Controls: SOX Considerations for Finance Teams

By Jane Ha · Updated Oct 11, 2026

AI and internal controls is the question of how an AI tool that touches financial reporting fits into the controls a public company must maintain under SOX: who owns it, what it's allowed to do, how its output is reviewed, and what evidence proves the review happened. AI doesn't create a new set of rules. It adds a new kind of actor, one that can be fast, inconsistent and hard to explain, inside a control framework that was designed around people and deterministic systems.

This guide is for controllers, CFOs, SOX program leads and finance managers who are rolling out AI in processes like accounts payable, bank reconciliation or the month-end close. It sits inside the AI for Finance collection, so start with AI in finance and accounting if you want the wider picture first.

Key Facts

• SEC rules require an issuer's management to evaluate internal control over financial reporting (ICFR) at the end of each fiscal year, using a suitable, recognized control framework established through due-process procedures (17 CFR 240.13a-15).
• PCAOB AS 2201 defines a material weakness as a deficiency, or combination of deficiencies, in ICFR that creates a reasonable possibility of a material misstatement not being prevented or detected on a timely basis (PCAOB AS 2201).
• COSO's February 2026 publication, Achieving Effective Internal Control Over Generative AI, applies the five components of the Internal Control-Integrated Framework and sorts generative AI use cases into eight capability types (Journal of Accountancy).
• In its July 2024 Spotlight, PCAOB staff reported that audit firms expect generative AI to augment, not replace, humans, and that firms did not view PCAOB auditing standards as impediments to using it (PCAOB).
• Under AS 2201, an auditor may use "benchmarking" for an entirely automated application control only if the general controls over program changes, access to programs and computer operations are effective and the control hasn't changed since the baseline was set (PCAOB AS 2201).

Why AI Is a SOX Question, Not Just an IT Question

SOX section 404 puts the responsibility on management. The SEC's rule requires management to assess ICFR each year against a recognized framework,. COSO's Internal Control-Integrated Framework is the one most finance teams know. If an AI tool prepares a journal entry, matches a bank line, drafts a disclosure or classifies an invoice, its output flows into the financial statements, and the control environment around it is in scope.

The PCAOB's staff Spotlight is useful here because it describes what preparers were already saying. Some used generative AI for first drafts of internal documents and for less complex, repetitive work such as preparing account reconciliations. Preparers also flagged the "black-box" nature of some tools and inconsistent output, which raise questions about the auditability of what the tool produces. And some auditors noted that preparers' use of generative AI could amplify existing IT risks such as segregation of duties, or create risks that didn't exist before.

Those three points frame the rest of this guide: a tool used for real accounting work, output that varies, and old control risks in new places.

How AS 2201 Treats Technology (and Why It Matters for AI)

AS 2201 is the standard external auditors follow when they audit ICFR. Three of its ideas shape how auditors will look at AI.

A top-down approach. The auditor starts at the financial statement level and focuses on entity-level controls before working down to significant accounts and their relevant assertions (PCAOB AS 2201). An AI tool that sits in a low-risk, non-financial corner of the business may never be tested. One that sits inside a significant account will be.

IT isn't evaluated separately. The standard says the auditor should understand how IT affects the company's flow of transactions, and that identifying risks and controls within IT is "an integral part of the top-down approach" rather than a separate evaluation. For you, that means an AI system should be assessed as part of the process it supports, not in an isolated technology review.

Automated controls lean on general controls. AS 2201 says an automated control would generally be lower risk if relevant IT general controls are effective, and it allows benchmarking of entirely automated application controls when program-change, access and operations controls hold up. This is where AI gets awkward. A traditional automated control behaves the same way every time, so a baseline stays valid until someone changes the code. A model whose behavior shifts with a vendor update, new training data or a changed prompt doesn't give the auditor that comfort. Plan to treat model and prompt changes the way you'd treat code changes.

Where AI Touches the Control Environment

COSO's generative AI guidance maps controls across the framework's five components (control environment, risk assessment, control activities, information and communication, and monitoring) and groups use cases into eight capability types: ingestion, transformation, posting, orchestration, judgment, monitoring, regulatory intelligence and human-AI interaction (Journal of Accountancy). The publication includes examples, minimum control expectations and illustrative metrics for each capability. COSO has also published earlier supplemental guidance on robotic process automation, which finance teams with older automation can read alongside it.

The table below applies that capability thinking to common finance work. It's an illustration of how to organize your own analysis, not a copy of COSO's mapping.

The Control Design Questions to Ask About Every AI Tool

When a tool lands in a financial process, run it through the same questions you'd ask about any control, plus a few specific to AI.

1. What is its role: preparer, reviewer or neither? An AI that drafts is a preparer. An AI that reviews another AI's work isn't independent review in the SOX sense unless a person owns the conclusion.
2. What does the human reviewer actually check? A control that says "controller reviews AI output" is weak if the reviewer sees only a summary. Define what they look at, what threshold triggers a closer look and what they do when something is off.
3. What information does the control rely on? If a reviewer's check depends on a report the AI produced, the completeness and accuracy of that report is part of the control.
4. Is the output repeatable? If the same input can give different outputs, say so in the control description and design the review to catch the variation.
5. Who can change it? Models, prompts, retrieval sources and business rules are configuration. They need owners and change records. Treat prompts, retrieval connectors and transformation rules as governed configurations.
6. What happens when it's wrong or down? Name the manual fallback and the person who can pause the tool.

IT General Controls for AI

IT general controls (ITGCs) cover the environment around applications: access, change management and operations. AI doesn't replace them. It stretches them.

• Access management. Limit who can use the tool, which data it can read and what it can write. A service account that can both create and approve a posting collapses segregation of duties into one credential. The PCAOB Spotlight records auditors' concern that AI could amplify exactly this kind of risk.
• Change management. Track model versions, prompt changes, retrieval-source changes and vendor updates. Test before release in a non-production setting. The PCAOB Spotlight notes that some preparers run new technology in a parallel environment before deployment, which is a sound habit here.
• Operations and monitoring. Log inputs, outputs and overrides. Watch for drift: sudden shifts in volume, amount or override rates are early signs that behavior has changed.
• Third-party and data risk. If a vendor hosts the model, understand what financial data leaves your environment and how the vendor handles it. The Spotlight shows firms setting limits on what can be uploaded to AI tools to keep confidential data from becoming public, and finance teams need the same rule for ledger data and bank information.

Evidence: What an Auditor Will Want to See

Evidence is where AI projects tend to come up short, because the tool is built to save time and nobody builds the audit trail. Plan for it from the start. The Spotlight describes firms designing their own AI tools to document the underlying source data used, and the same principle applies to yours.

For the underlying inputs, finance data readiness covers the data quality that every one of these controls assumes.

How to Bring an AI Tool into Your SOX Program, Step by Step

1. Inventory every AI use in finance. Include tools bought by individual teams and features switched on inside existing systems. Keep it current, because new uses appear constantly.
2. Tier by financial reporting impact. Does the output reach a significant account, a disclosure or an estimate? Tools that don't can follow a lighter policy.
3. Assign an owner for each tool. One named person is accountable for scope, changes and monitoring.
4. Document the process and the control. Update the narrative and risk-and-control matrix to show where AI sits, what it does and who reviews it. Be specific about the review.
5. Separate duties. The AI shouldn't prepare and approve the same item, and no one account should have both rights.
6. Set up the ITGC coverage. Access, change management, logging and vendor review for the tool and its configuration.
7. Test before go-live. Run in parallel with the existing process for a few cycles and compare line by line. Record the results as evidence.
8. Talk to your external auditor early. Share the design before the control goes live, not at year-end walkthroughs. For the internal audit view, see AI in internal audit.
9. Monitor and retest. Track override rates, exceptions and accuracy. Re-run tests when the model, prompt or data source changes.

Common Pitfalls

• Treating "a human reviews it" as the control. Without a defined review, a threshold and a record, there's no control to test.
• Letting the AI own an approval. Automated approval of a posting by the same system that prepared it is a segregation-of-duties deficiency waiting to be found.
• Ignoring configuration changes. A prompt edit or vendor model update can change behavior with no code release and no ticket.
• No inventory. Shadow AI in a finance team is a risk you can't assess if you don't know it exists.
• Evidence after the fact. Logs and reviewer notes are hard to reconstruct months later. Capture them as the control runs.
• Assuming the vendor's assurance covers you. A vendor report may help, but your controls over how you use the tool remain yours.
• Forgetting fraud. Models can be misused or manipulated. See AI fraud detection in finance for how AI cuts both ways.
• Overlooking judgment areas. Revenue and estimate-heavy areas need extra care; AI in revenue recognition shows where the judgment sits.

What to Measure

• Coverage: share of AI use cases inventoried, owned and tiered.
• Control performance: exceptions caught by reviewers, override rate and the time to resolve each.
• Accuracy: error rate against source documents or actuals, by tool.
• Change discipline: model, prompt and rule changes made with approval versus without.
• Evidence readiness: share of controls with complete logs and sign-offs at quarter-end.

Where to Go Next

If you do one thing this quarter, build the inventory and tier each tool by whether it reaches a significant account. Then tighten the review step for the highest-tier tools and start logging evidence now. Then decide who owns which control as the work shifts, and write that down.