Governed AI in Finance: Define the Evidence, Authority, and Control Path

A successful run can still be a failed finance process

An AI-assisted reconciliation finishes without a software error. It reports 10,238 items accounted for in one population. The source population contains 10,240.

The run succeeded. The reconciliation did not.

That difference is the starting point for governed AI in finance. Control cannot stop at whether a model returned an answer, a workflow completed, or a reviewer clicked approve. Finance must define what the system was allowed to do, what evidence the result requires, what condition proves the business task is complete, and how the organization responds when those conditions are not met.

The same principle applies to narrative work. A system can produce a fluent variance explanation while reading the wrong period, omitting a customer group, using an unapproved metric definition, or presenting a plausible cause without evidence. The language may be polished enough to reduce skepticism. That makes the control problem harder, not easier.

Governance should therefore attach to the workflow’s authority and consequence rather than to the novelty of the technology. Finance already uses access controls, reconciliations, approvals, segregation of duties, exception handling, and audit evidence. The task is to extend those disciplines to AI-assisted work without assuming that nominal human involvement settles every risk.

Begin with the finance workflow, not the vendor list

NIST’s voluntary AI Risk Management Framework organizes activity around Govern, Map, Measure, and Manage, with governance spanning the lifecycle.[1] Its core addresses responsibilities, inventories, oversight, testing, monitoring, risk tolerance, and accountability.[2]

For finance, an inventory should be built around uses. Drafting monthly commentary and preparing journal entries may use the same model while creating very different exposure. The workflow record should identify the business purpose and owner, accessible data, affected financial output, authority granted, required evidence, approval, testing, monitoring, exception response, and recovery method.

A software inventory alone cannot answer whether the system may merely summarize records or can initiate a payment. Nor can a broad policy requiring review of all AI output explain what the reviewer must inspect, which evidence must be present, or what happens when a material exception is found.

The first hard judgment is whether the use case is worth governing at all. A low-value workflow with high verification burden may not save time. A process that cannot expose its sources may be unsuitable for consequential finance work even if its average output is accurate.

Authority should advance one boundary at a time

The safest progression is not simply from manual to automated. It is from narrower to broader authority.

At the first boundary, the system reads approved information and summarizes it. It cannot introduce a financial recommendation, but it still needs access limits, source references, and completeness checks.

At the second, it analyzes or recommends. Inputs, formulas, assumptions, and unsupported inferences must be visible so that a responsible person can evaluate the reasoning.

At the third, it prepares or stages a consequential item—a journal entry, payment file, forecast update, disclosure, or board narrative—without completing the action. Evidence and approval should travel with the staged item.

Only at the fourth boundary does the system execute within policy. That requires least-privilege access, explicit limits, reliable logging, policy or approval conditions, independent verification, exception detection, and a tested way to stop or correct the action.

Not every workflow should reach execution. Materiality matters, but so do reversibility and detectability. An internal draft can be replaced. A posted ledger entry may be reversed but can affect reporting and downstream processes. A payment or external representation may be difficult to recover. Thousands of individually small actions can also accumulate into a material error.

A common mistake is to approve broader authority because earlier drafts looked good. Output quality in a low-consequence setting does not prove that access, segregation, failure detection, and recovery are adequate for execution.

Evidence belongs beside the sentence and number

NIST’s Generative AI Profile identifies confabulation as false content presented with confidence and recommends controls suited to the use case and potential harm.[3] In finance, unsupported explanations can be unusually persuasive because they arrive in the familiar language of variance, drivers, and management action.

Suppose revenue is $1.2 million below plan. An AI system should not state that conversion weakened unless stage, timing, or deal evidence supports that cause. It may calculate the variance from approved actual and budget data. It may identify a pattern correlated with the miss. But correlation, operating explanation, and recommendation are different claims.

Acceptance criteria can be direct: every material number maps to an approved source row or reproducible calculation; every causal statement links to evidence or is labeled as inference; the complete population is tested; material omissions are measured; and corrections before approval are retained.

This does not require turning narrative into a footnote forest. It requires a reviewer to reach the underlying proof without reconstructing the workflow. If the system cannot reveal which data and rules produced a material claim, readability should not compensate for the missing control.

Define completion outside the model

Return to the reconciliation. Population A contains 10,240 transactions. Population B contains 10,238. The workflow finds 10,180 exact matches, 45 timing items, and 13 unresolved exceptions:

10,180 matched + 45 timing + 13 unresolved = 10,238 items accounted for in population B.

The calculation ties to population B. Two items remain outside that population relative to A. The finance task is complete only when the population difference is explained, the 13 exceptions are assigned or resolved under policy, evidence is retained, and the result is independently checked.

Model completion is a technical event. Reconciliation completion is a business assertion.

The distinction creates an enforcement requirement. If unresolved exceptions exceed policy, the workflow should not simply display a warning and continue. It should route the item to manual review, withhold posting, reduce authority, or stop the process. Monitoring without a response path is observation, not control.

Approval must preserve a real decision

AI-assisted journal preparation can save time by assembling the account, amount, entity, period, description, and support. It should not collapse preparation and authorization.

The approver needs the business event, source evidence, reproducible calculation, accounting-policy context, entity and period, and a clear record of what the system generated. After approval and posting, a separate log and ledger reconciliation should prove that the authorized entry—not a changed version—was recorded.

Meaningful review also requires time, competence, and the practical ability to reject or escalate. A queue of hundreds of items with one-click approval may satisfy a workflow field while eliminating substantive challenge.

The FRC reported in 2026 that AI use in corporate reporting was increasing but remained cautious, with more use in narrative and lower-risk tasks than in financial statements or high-judgment areas. Participants cited data quality, governance, trust, legal, reputational, accuracy, authenticity, and accountability concerns.[4] That study has a specific corporate-reporting context. Its broader lesson is that review quality matters more as outputs move closer to consequential reporting.

Test the failures that would change the financial conclusion

A finance test set should not consist only of normal examples. It should include the conditions the workflow is expected to reject or escalate: wrong entity, wrong reporting period, duplicate transactions, missing records, sign reversals, currency mismatches, stale forecast versions, unsupported narrative causes, breached approval thresholds, and outputs that look complete while exceptions remain.

Positive and negative tests prove different things. If policy requires journal support, one test should show that a supported journal can proceed and another that an unsupported journal cannot. If access is scoped by entity, test both authorized access and denied cross-entity access.

Measures should include material error rate, missed exceptions, unsupported claims, corrections required, time to verified completion, and incidents. Output volume and user adoption may describe use, but they do not establish control quality.

When a threshold is breached, the action should already be defined: pause execution, route to manual review, revert to a controlled process, lower authority, or open an incident. Recovery should be tested before the organization depends on it. A control path that exists only in policy language may fail when time pressure is highest.

External claims are part of the controlled output

Governance also applies to what a company says about its AI use. The SEC has warned that AI-related claims need a reasonable basis and has pursued misleading representations it described as AI washing.[5] That enforcement context is not a complete finance AI rulebook. It does reinforce a familiar reporting discipline: claims about automation, accuracy, compliance, auditability, real-time operation, or human review should match the actual process.

If the system drafts but cannot post, say so. If a person reviews only exceptions, do not imply that every output receives full human review. If monitoring is daily, calling it continuous is inaccurate. If evidence coverage is partial, calling the workflow fully auditable is unsupported.

This boundary can create commercial tension. Stronger language may sound more impressive, while precise language better reflects the control environment. Finance should favor the claim that can be proved.

The final question is what happens when it is wrong

A governed workflow has a purpose, controlled data, bounded authority, source-linked evidence, meaningful approval, independent completion criteria, monitoring tied to action, and a recovery path. Those elements should scale with consequence rather than appearing as the same checklist for every use.

The decisive question is not whether the system usually produces a good answer. It is whether the organization can detect a material failure before—or soon after—it changes cash, the ledger, a forecast, a board decision, or an external statement.

That standard permits useful experimentation. It also explains why some workflows should remain at summarization, others can safely stage work, and only a smaller set should execute. Governed AI in finance is not a promise that errors disappear. It is a design in which authority is limited, evidence travels with the output, completion is independently proved, and failure triggers a known response.