SOX and AI Controls: The 2026 Governance Framework for CFOs and Controllers

SOX and AI Controls: The 2026 Governance Framework for CFOs and Controllers

If your company uses AI to flag unusual journal entries, automate reconciliations, or run anomaly detection on financial data, that AI system is almost certainly a SOX control. Not a tool that supports a control. The control itself. And that distinction carries significant governance obligations that most SOX programs are not yet built to handle.

This guide is for CFOs, controllers, internal audit leaders, and SOX program managers who need to understand exactly what those obligations are, how existing PCAOB standards apply, and where the regulatory gaps leave you exposed today.

Key takeaway: SOX Section 404 applies to AI-driven controls with no carve-outs. The standards governing design, operation, and attestation were written for manual and traditional IT controls. Practitioners are extrapolating. That gap is the defining compliance risk of 2026.

The Three-Tier Model: Not All AI in SOX Is the Same

The single biggest source of confusion in this space is treating all AI use in SOX as equivalent. It is not. Three fundamentally different scenarios require three different governance responses.

Most published guidance conflates Tiers 1 and 2. The governance obligations are completely different. Getting the classification wrong in either direction creates risk: misclassify a Tier 2 control as Tier 1 and you have an undocumented, untested ICFR control. Misclassify a Tier 1 tool as a Tier 2 control and you waste resources testing something that does not affect your financial statements.

Typical Tier 2 deployments include revenue recognition checks, review of 100% of journal entries, and continuous segregation-of-duties monitoring. For a control-by-control build, see AI-ICFR Framework: Key Controls for CFOs Explained. For AI uses that shouldn't sit inside ICFR at all, see AI Prohibited Uses in SOX ICFR Controls: 2026 Regulatory Update.

When AI Is the Control: AS 2201 Obligations Apply in Full

SOX Section 404(a) requires management to assess ICFR effectiveness. Section 404(b) requires independent auditor attestation. Neither provision contains an AI exemption. SOX was enacted in July 2002 and its Section 404 requirements have never been amended to address AI or automated controls. The statute applies to whatever controls you have, regardless of whether a human or an algorithm executes them.

PCAOB AS 2201 defines two categories of deficiency that apply directly to AI systems:

• Deficiency in design: A control is not properly designed so that, even if it operates as designed, the control objective would not be met. For an AI control, this includes a model trained on non-representative data, an algorithm that does not cover the relevant financial statement assertion, or a system whose output is never acted upon.
• Deficiency in operation: A properly designed control does not operate as designed. For an AI control, this includes model drift that causes the system to miss anomalies it previously detected, misconfiguration after a software update, or output that is generated but not reviewed.

Both categories map directly onto AI failure modes. And under AS 1305, any significant deficiency or material weakness identified during the audit must be communicated in writing to management and the audit committee. A failing AI control becomes a reporting event, and if it rises to a material weakness, Item 308(a)(3) of Regulation S-K requires management to disclose it and bars an "effective" conclusion.

Model drift is the clearest case of a deficiency in operation. A model calibrated correctly at deployment that degrades mid-year because the underlying data shifted is no longer operating as designed, even though the design was sound in January. AS 2201.A3 adds a second trigger that matters for AI: a control is also deficient in operation when the person performing it lacks the authority or competence to do so, which reaches reviewers who accept outputs they can't evaluate.

That makes drift monitoring a control in its own right. It needs an owner, defined thresholds for when drift triggers re-calibration, re-testing or escalation, and evidence that it ran.

The Silent Failure Problem

This is the risk that almost no existing SOX guidance addresses. A manual control fails visibly: a human does not perform the reconciliation, and the gap is obvious. An AI control can fail silently, producing plausible but incorrect outputs without triggering any exception flag. The system appears to be running. The dashboard shows green. The material misstatement goes undetected.

This is a qualitatively new category of ICFR risk. It requires compensating controls that traditional SOX frameworks do not contemplate:

• Output monitoring controls: Regular sampling and human review of AI outputs to verify accuracy
• Model validation procedures: Periodic testing of the model against known outcomes
• Drift detection: Automated alerts when model performance metrics degrade
• Model change management: Formal change control procedures before model updates go live in a production ICFR environment

None of these are addressed in existing PCAOB standards. Practitioners are building them from first principles, drawing on COSO's Monitoring Activities component and general IT governance frameworks.

The Precision Problem

Precision is the AS 2201 concept that no standard or guidance has translated for AI. The standard uses it to ask whether a control operates at a level that would prevent or detect a misstatement that could be material, and AS 2201.68 holds compensating controls to the same test.

For an AI anomaly-detection control, precision turns on the false-negative rate, the threshold settings that decide what gets flagged, and how representative the training data is. False positives create a different problem. They bury reviewers, and tired reviewers start dismissing real exceptions.

None of these metrics appear in AS 2201 or any PCAOB guidance. Document the threshold rationale, tie it to materiality, and show that the false-negative rate doesn't leave room for a material misstatement. Threshold calibration is a SOX decision, so the controller or CFO should own it.

Classifying AI Control Failures

AI failures range from minor deficiencies to material weaknesses. Severity still runs through AS 2201.62-.70: is there a reasonable possibility the failure lets a misstatement through, how large could it be, and does a compensating control catch it at sufficient precision?

For how a material weakness gets disclosed, see Finrep's Material Weakness Disclosure Requirements: 2026 SEC Compliance Guide.

Documenting AI Controls: What Your Control Matrix Needs

Documenting an AI control in your risk-and-control matrix and process narratives requires more detail than a traditional automated control. At minimum, your documentation should address:

1. Control objective: Which financial statement assertion does this control address? (Existence, completeness, accuracy, valuation, presentation)
2. Control description: What does the AI system do, what inputs does it process, what outputs does it produce, and what action is triggered by those outputs?
3. Model governance: Who owns the model? What training data was used? When was it last validated? What is the change management process?
4. Human-in-the-loop: Is there a human review step before the AI output is acted upon? If yes, document it as part of the control. If no, document why the AI output alone is sufficient.
5. Exception handling: What happens when the AI flags an anomaly? Who investigates? What is the escalation path?
6. IT general controls (ITGCs): Access controls, change management, and operations controls for the AI system itself, plus AI-specific controls: model validation, training data governance, output monitoring.

Deloitte partners Lindsay Rosenfeld and Brandon Chandler note that GenAI can complete analysis and verification tasks that typically take days in minutes, but that speed only helps if the underlying control documentation is structured to support it.

How Much Human Review Is Enough

No standard says how much human review an AI control needs. This is a defensible minimum, built from the logic of AS 2201's operating-effectiveness requirements:

The Evidence Auditors Will Ask For

Auditors can only test what you can show them. An AI-assisted control should produce this evidence set:

ITGCs for AI Systems: The Framework Gap

Traditional ITGCs cover three domains: access controls, change management, and computer operations. These apply to AI systems but are insufficient on their own. AI-specific ITGCs that your program should address include:

• Training data governance: Who controls the data used to train or fine-tune the model? Is it subject to access controls and version management?
• Model versioning and change management: Is there a formal process for approving model updates before they affect ICFR outputs? Are prior model versions retained for comparison?
• Output monitoring: Is there a systematic process for reviewing AI outputs for accuracy and completeness on an ongoing basis?
• Model validation: Is the model periodically tested against a holdout dataset or known outcomes to verify it still performs as designed?
• Vendor dependency controls: If the model is provided by a third party, what controls exist if the vendor changes the model, deprecates an API, or experiences an outage?

No authoritative ITGC framework for AI systems exists yet. COSO's February 2026 publication, Achieving Effective Internal Control Over Generative AI, shows how to apply the 2013 framework to GenAI, which helps, though it sets no ITGC requirements. The PCAOB's Technology Innovation Alliance (TIA) Working Group identified standardized audit documentation as its first strategic pillar, but that work addresses audit firm documentation, not preparer control frameworks.

The TIA's second pillar, "Using AI in Audit," recommends that the PCAOB consider risk-management guidance for audit firms' use of AI. It's a recommendation to the regulator and creates no obligation for preparers.

Mid-Year Model Changes

A retrained model or a vendor update is a change to the control. AS 2201.B28-.B29 lets auditors benchmark an entirely automated application control only when ITGCs over program changes, access and computer operations are effective and the control hasn't changed since the baseline. A model update resets that baseline.

The question is whether the change affects the model's ability to prevent or detect a material misstatement. No regulator has answered it for AI, so build the process yourself:

• Get a contractual right to advance notice of vendor model updates
• Assess each update for changes to detection logic, training data or threshold behavior
• If behavior changed, re-test design and operation, update the risk-and-control matrix, and tell your auditors
• If it didn't, document why and get the vendor's confirmation in writing
• Log every change in your AI model inventory with dates, version numbers and the assessment

Third-Party AI Vendors: The Service Organization Problem

When a company uses a third-party AI platform as part of ICFR, that vendor may qualify as a service organization under AS 2601 and Auditing Interpretation AI 18. This means your auditor needs to obtain and evaluate a SOC 1 report from the vendor, or perform alternative procedures.

The problem: standard SOC 1 Type II reports were not designed for AI systems. They cover traditional IT controls. They do not address:

• Model training data quality and governance
• Algorithmic bias and fairness testing
• Model versioning and the impact of model updates on ICFR outputs
• Foundation model dependencies (if your SaaS vendor's AI is built on a third-party LLM API, that creates a subservice organization layer)

AI 18 extends service organization considerations to subservice organizations. A multi-layer AI supply chain, where your vendor's platform runs on a foundation model API from a separate provider, creates nested service organization considerations that existing SOC 1 frameworks are not equipped to address.

Until SOC 1 frameworks are updated for AI, companies relying on third-party AI controls should document complementary user entity controls (CUECs) that address the gaps. These should include output monitoring, independent validation of AI outputs against source data, and contractual rights to audit the vendor's model governance practices.

The PCAOB's Position: A Confirmed Grey Zone

The regulatory picture is clear in one respect: there is no AI-specific PCAOB auditing standard. The PCAOB's June 2024 technology-assisted analysis amendments, effective for fiscal years beginning on or after December 15, 2025, explicitly excluded AI from scope. The adopting release states: "The amendments are focused on addressing certain aspects of technology-assisted analysis, not specific matters relating to other technology applications used in audits (e.g., blockchain or artificial intelligence)."

The PCAOB's July 2024 GenAI Spotlight found that audit firms view current PCAOB standards as no impediment to GenAI use, meaning firms are proceeding under standards written for manual and traditional IT procedures. The PCAOB said it was assessing whether guidance, standard changes, or other regulatory actions are needed.

In June 2026, PCAOB Release No. 2026-005 asked whether AI matters raised by commenters, including the company's use of AI in risk assessment and in auditing internal controls, should be handled through standard setting or staff guidance. Comments closed August 7, 2026, and no AI standard or guidance has followed.

The tension is sharpest around 100% testing. As PCAOB Board Member Christina Ho put it in a September 16, 2025 speech, speaking in her personal capacity:

"Let's say an audit firm uses an AI tool to test 100% of journal entries, as opposed to taking the traditional, manual sampling approach. One scenario is that PCAOB inspectors recognize 100% testing as an improvement over the manual sampling approach, because it provides more audit coverage. The second scenario is that the lack of clear PCAOB standards and guidance on what constitutes an acceptable AI-based audit and how compliance is to be assessed results in inspectors seeking unreasonable levels of detail from the audit firm about its AI model and the associated procedures performed." (AI and the Pursuit of Audit Quality: A Regulatory Perspective)

That unresolved tension is a live risk for preparers today. If your auditor uses AI to test your journal entries and a PCAOB inspector challenges the procedure, you may face re-testing requests, delayed audit opinions, or increased audit fees. Understanding your auditor's AI procedure documentation strategy is now a legitimate agenda item for pre-year-end planning meetings.

The same board member called for the PCAOB to become "an engine that catalyzes innovation" rather than a technology-neutral anchor, signaling internal pressure for AI-specific standards. But none exist yet, and the PCAOB is simultaneously implementing multiple new standards (AS 1000, the Confirmations standard, the Quality Control standard, and the technology-assisted analysis amendments) on overlapping effective dates, straining both firm and regulator capacity.

Until something is issued, AS 2110 is the hook auditors use for AI risk. Paragraph .05 already lists "information systems that fail to accurately capture business transactions" as a source of risk of material misstatement, and Appendix B, "Consideration of Manual and Automated Systems and Controls," is the closest the standards come to AI controls.

Appendix B was written for deterministic ERP automation. The analogy breaks for models whose outputs shift with retraining or, for generative tools, vary from run to run, so document for each AI control where it holds and where it doesn't. One trap: amendments to AS 2110 paragraphs .05 and .41 take effect December 15, 2026, but they're conforming wording changes from the QC 1000 release and say nothing about AI.

What to Watch

• PCAOB action on AI: whether Release No. 2026-005 produces staff guidance or a standard-setting project. The Board says it will consider AI developments in its existing Data and Technology research project.
• SOC 1 coverage for AI vendors: whether vendors start scoping SOC 1 reports to cover model development, change and operation controls alongside infrastructure.
• EGC governance debt: an emerging growth company can skip 404(b) auditor attestation for up to five fiscal years after its IPO. AI controls built in that window get their first auditor test when the status ends, so document them to AS 2201 standards now.

Agentic AI in SOX: What KPMG's TACO Framework Means in Practice

KPMG's July 2025 paper on the agentic shift in SOX compliance introduces the TACO framework, a taxonomy of four agent types:

• Taskers: Single-task agents that execute discrete, well-defined activities (e.g., pulling evidence from a document repository)
• Automators: Agents that handle end-to-end execution of a defined process (e.g., running a full controls testing workflow)
• Collaborators: Agents that work alongside humans, providing analysis and recommendations
• Orchestrators: Multi-agent systems that coordinate other agents to achieve complex objectives at scale

KPMG states that "SOX controls may be an even better target for agentic automation" than other enterprise processes, citing the structured, repeatable, documentation-heavy nature of SOX work. The efficiency case is compelling. But the KPMG paper does not address the governance and attestation implications of deploying agents as ICFR controls.

The Orchestrator tier raises the hardest questions. If a multi-agent system conducts a walkthrough, collects evidence, and documents a control, does that satisfy AS 2201's requirements for sufficient appropriate audit evidence? Does the agent's output constitute a management representation? Who is accountable if the agent makes an error? These questions have no authoritative answers today.

The practical guidance for 2026: Agentic AI is appropriate for Tier 1 activities (program management, evidence collection support, documentation drafting) with human review of all outputs. Deploying agents as Tier 2 ICFR controls without robust human oversight, output monitoring, and explicit control documentation is a material weakness waiting to happen.

When Internal Audit Uses AI for SOX Testing

If your external auditor plans to use internal audit's work, AS 2201.16-.18 points to AS 2605, and the auditor assesses competence and objectivity under AS 2605.09-.11. The competence factors include audit policies, programs and procedures, supervision and review, and the quality of working-paper documentation. AI-generated testing workpapers get the same scrutiny as manual ones.

AS 2605 says nothing specific about AI, so set your own floor. Record the prompts and tool versions used in each test, have a person review every AI output before it counts as evidence, and tell the external auditor which procedures used AI before fieldwork starts.

The Management Assessment Narrative: Disclosure Calibration

How should management describe AI-driven controls in the Section 404(a) assessment and in the 10-K? This is an unresolved disclosure question with real stakes in both directions.

• Over-disclosure of AI control methodology creates competitive risk and may invite SEC comment letters asking for more detail than you want to provide publicly.
• Under-disclosure of material AI control risks, especially if an AI control failure contributed to a restatement or late filing, creates enforcement exposure.

The SEC has not issued specific guidance on AI control disclosure in ICFR assessments. The working principle: describe AI controls at the same level of specificity as other significant automated controls. If an AI system is a key control over a significant account, its existence and general nature should be reflected in your process narratives and risk-and-control matrix. Model-level technical detail does not belong in the 10-K. But a statement that management uses automated controls over journal entry review, without acknowledging that those controls are AI-driven, may not accurately describe the nature of the control environment.

Audit committee briefings are a related obligation. Boards and audit committees are responsible for overseeing ICFR but typically lack the technical literacy to evaluate AI control risks. Management should brief the audit committee on: which controls are AI-driven, what the key model governance risks are, what compensating controls exist for silent failure scenarios, and what the current PCAOB regulatory gap means for audit risk and fees.

What to Do Now: A Practical Checklist

COSO's 2013 framework sets 17 principles across five components, and AI risk touches all of them. Run this checklist by component. Three principles carry most of the AI load: Principle 11 (general control activities over technology), Principle 13 (relevant, quality information) and Principle 16 (ongoing and separate evaluations).

Inventory and classify your AI systems first:

• Inventory every AI tool touching financial reporting, including AI embedded in ERP modules, RPA with machine-learning components, standalone analytics platforms, and generative AI used for documentation
• Record for each tool: vendor, model version, deployment date, last update date, and the control objective it supports
• Apply the three-tier model: program management tool, ICFR control, or agentic ecosystem
• For every Tier 2 AI control, confirm it is in your risk-and-control matrix with full documentation
• Note whether each vendor's SOC 1 Type II report covers the AI model itself
• Walk the audit committee through the inventory

Control environment:

• Assign ownership of each AI control to a named person
• Confirm the people operating AI-assisted controls have the competence to evaluate and challenge outputs
• Document who can override AI output and how overrides are logged

Risk assessment:

• Add AI-specific fraud vectors to the fraud risk assessment (Principle 8): adversarial inputs built to slip past anomaly detection, model poisoning, and unauthorized model access
• Assess drift, hallucination and training data bias risk for each AI control
• Map each AI risk to a financial statement assertion and a potential misstatement

Control activities, including Principle 11:

• Control objective mapped to specific financial statement assertions
• Model governance section: owner, training data, validation history, change management process
• Human review step documented, or rationale for why AI output alone is sufficient
• Exception handling and escalation path documented
• Training data access controls and version management
• Model change management procedures (separate from general IT change management)
• Segregation of duties: the AI can't both initiate and approve, and in multi-agent systems no single agent completes a full transaction cycle
• A human approval gate for exceptions above a defined threshold, so the AI can't auto-clear them
• Threshold calibration documented, and re-validated after an acquisition, system migration or business model change

Information and communication, including Principle 13:

• Data quality controls that confirm inputs are complete, accurate and timely before each model run
• Input data lineage that traces back to source
• A documented triage and sign-off workflow for high alert volumes
• A human-readable rationale for each flagged exception

Monitoring activities, including Principle 16:

• Output monitoring controls with defined sampling frequency and reviewer
• Drift metrics (precision, recall, false-positive rate) tracked on a set schedule, with alert thresholds and an escalation path
• Evidence of how the AI monitor itself was validated before its output counts toward Principle 16

Address third-party AI vendor risk:

• Determine whether vendor qualifies as a service organization under AS 2601
• Obtain and review SOC 1 report; confirm it covers the model's development, change and operation controls, and document gaps
• If no SOC 1 exists, document the alternative procedures performed
• Define complementary user entity controls for AI-specific risks
• Assess subservice organization layers (foundation model dependencies)

Engage your external auditors early:

• Discuss AI control documentation approach before year-end
• Understand their AI testing methodology and PCAOB inspection risk exposure
• Align on what constitutes sufficient evidence of AI control operating effectiveness
• Flag any key AI vendor without adequate SOC 1 coverage, since that's an audit scope issue
• Tell them which internal audit procedures used AI

FAQ

Does an AI system used as a SOX control need to be tested like any other control?Yes. Under AS 2201, any control that is part of ICFR must be designed properly and operate effectively. Testing an AI control means verifying that the model performs its intended function, that outputs are acted upon appropriately, and that the supporting ITGCs (including model governance) are operating. The testing methodology will differ from manual controls, but the obligation is the same.

What happens if our AI control produces a hallucination or incorrect output?If the error is isolated and caught by a compensating control, it may be a control deficiency. If the AI control fails systematically, or if there is no compensating control to catch incorrect outputs, the failure could constitute a significant deficiency or material weakness under AS 1305, requiring written communication to management and the audit committee and potential public disclosure.

Do we need a SOC 1 report from our AI vendor?If the vendor's AI system is part of your ICFR, the vendor likely qualifies as a service organization under AS 2601 and AI 18. Your auditor will need either a SOC 1 Type II report from the vendor or will need to perform alternative procedures. Review the SOC 1 carefully for AI-specific gaps and document complementary user entity controls to address them.

Is there specific PCAOB guidance on AI in audits or ICFR?No AI-specific PCAOB standard exists as of mid-2026. The June 2024 technology-assisted analysis amendments explicitly excluded AI from scope. The PCAOB has acknowledged the gap, and its June 2026 Release No. 2026-005 asked whether AI matters belong in standard setting or staff guidance, but nothing has been issued. Practitioners are applying existing standards (AS 2201, AS 1305, AS 2601, AI 18) to AI systems by analogy.

Can we use agentic AI to perform SOX controls testing?Agentic AI can support controls testing workflows, particularly for evidence collection, documentation, and scheduling. But deploying agents as the primary tester of ICFR controls, without robust human review of outputs, raises unresolved questions about audit evidence sufficiency under PCAOB standards. The prudent approach in 2026 is human-supervised agentic assistance, not autonomous agent-led testing.

How should we brief our audit committee on AI control risks?Cover four topics: which ICFR controls are AI-driven and what financial statement assertions they address; the key model governance risks (drift, silent failure, vendor dependency); what compensating controls are in place; and the current regulatory gap, specifically that no AI-specific PCAOB standards exist and what that means for audit risk and fees. Keep it non-technical but specific enough that the committee can exercise meaningful oversight.