AI GOVERNANCE / INTERNAL CONTROL / CFO
Judgment and human oversight in finance: controls and evidence for review
Understand Human-in-the-loop, Human-on-the-loop, Human-out-of-the-loop and Human-in-command, and connect oversight to COSO, AI governance and CFO judgment.
AI can prepare reports, analyse variances and propose accounting entries faster. Before using those outputs, management still needs to establish the source of the data, the assumptions driving the conclusion, the reviewer and the authorised decision-maker. A polished report can contain missing information or explanations unsupported by evidence.
Human oversight establishes where people participate and what authority they have. Professional judgment evaluates evidence, suitability, materiality and exceptions at those points. An approval click alone is insufficient: the process needs evidence of review and follow-up of unresolved questions.
Financial closing and reporting provides a practical example because it combines routine tasks, estimates and decisions affecting report users. The examples and mappings are DHISORA’s analysis, not prescribed controls, client case studies or a guarantee of auditor reliance.
Specify supervision, review and approval separately
Human oversight requires clarity about when a person sees information, what is checked, what is decided and which activities can be stopped. Retrospective reporting and approval before execution address different risks and should not be reduced to “a person has checked”.
Professional judgment applies relevant knowledge and experience to information, evidence, assumptions, alternatives and limitations within the applicable framework. Approval exercises delegated authority over a specific matter. A reviewer may lack approval authority, and authority alone does not establish sufficient information or competence.
The process owner coordinates outcomes and participants within authority; the system owner is responsible for the supporting system. Delegation of authority (DOA), RACI working roles and actual permissions need alignment. The playbook explains each role.
Conditions for meaningful judgment
AI can assist with complex analysis and alternatives. The durable question is not whether AI will remain unable to perform particular tasks, but who is accountable for using its recommendations and whether that person can challenge them. These five conditions are DHISORA’s design criteria, not a mandatory checklist from a standard.
| Condition | Review-design question |
|---|---|
| Evidence | Can the reviewer see source data, assumptions and exceptions rather than only an AI conclusion? |
| Time | Do workload and deadlines allow sufficient attention to important matters? |
| Competence | Does the reviewer understand the subject and tool limitations, with access to specialist support? |
| Authority | Can the reviewer reject, hold or escalate within delegated authority? |
| Incentives | Do performance measures support quality and challenge rather than approval speed alone? |
Four human oversight arrangements
The HITL, HOTL and HOOTL explanations use Australia’s Digital Transformation Agency as design references. Human-in-command draws on the European AI High-Level Expert Group’s ethics guidance, which also discusses HITL and HOTL. Terminology varies by field; document intended meanings, activities and actual permissions. [1–2]
| Arrangement | Human role and authority | Illustrative finance application |
|---|---|---|
| Human-in-the-loop (HITL) | A person reviews inputs and outputs and makes the final decision. In this design, specified actions wait for approval. | AI proposes a journal adjustment; evidence is reviewed and an authorised person approves before posting. |
| Human-on-the-loop (HOTL) | The system operates autonomously within its permitted scope; a person monitors and can intervene. | Automated reconciliation matching with monitored exceptions and an effective pause mechanism. |
| Human-out-of-the-loop (HOOTL) | No person participates in decisions within the defined operational loop. | Automatic classification of document copies without altering originals or authorising transactions. |
| Human-in-command (HIC) | People govern purpose, boundaries, quality expectations and acceptable risk. | The CFO determines permitted data, access, approval requirements, stop criteria and exception owners. |
Human-in-command can coexist with the other arrangements
Timing differs: HITL holds specified actions for human consideration; HOTL permits bounded operation with signals reaching people who can intervene in time; HOOTL executes the defined cycle without a human decision in each iteration. HIC governs objectives, boundaries and change or stopping conditions across these arrangements.
HITL, HOTL and HOOTL describe human involvement in an operational decision loop. HIC describes governance above that loop. They are not four successive stages of automation. [1–2]
One organisation might use HIC across its processes, HITL for material approvals, HOTL for reconciliation and HOOTL for bounded, low-impact classification. This is a design example, not a finding that any task category is inherently safe.
HOOTL does not remove system ownership or later monitoring. Define the loop boundary precisely. HOTL also requires sufficient time to detect and intervene before consequences become unmanageable. If intervention cannot be timely, consider approval before execution.
Governance, controls and judgment have distinct roles
Internal control is a process involving the board, management and personnel to provide reasonable assurance over operations, reporting and compliance objectives, rather than a guarantee of error-free outcomes. Human review is one mechanism and needs to work with data, access, procedural and monitoring controls.
AI governance establishes purpose, limits and accountability. Internal control embeds preventive and detective measures in the process. Analysis examines evidence and assumptions. Professional judgment evaluates suitability, materiality and exceptions before an authorised decision is made.
An approval click does not establish effective oversight. Reviewers need evidence, competence, time and authority to reject or escalate. A second AI reviewer may add a check, but shared failure modes need testing: similar models can overlook the same error.
Connecting human oversight to COSO
COSO’s five components are Control Environment, Risk Assessment, Control Activities, Information and Communication, and Monitoring Activities. Its 2026 GenAI guidance applies the existing framework to AI-related risks, including judgment and human–AI interaction. [3]
COSO does not prescribe HITL for every task or treat a loop label as proof of effectiveness. The following is DHISORA’s application of the framework to controls that can be designed and tested.
| COSO component | Application to AI | Evidence to consider |
|---|---|---|
| Control Environment | Assign process ownership, approval authority, review roles and AI boundaries. | Approved policy, RACI and delegation of authority. |
| Risk Assessment | Assess error, impact, confidentiality, reversibility and action speed. | Risk register and documented oversight rationale. |
| Control Activities | Restrict access, segregate duties, validate data and establish approval or hold points. | Access settings, test results and approval logs. |
| Information and Communication | Expose sources, exceptions, assumptions and escalation routes. | Evidence register, exception reports and communications. |
| Monitoring Activities | Track errors, overrides and performance after model changes. | Retest results, incident logs and remediation actions. |
Frameworks, standards and law have different status
NIST AI RMF is voluntary and uses Govern, Map, Measure and Manage. ISO/IEC 42001:2023 is an AI management system standard. ETDA provides organisational GenAI governance guidance for the Thai context. [4–6]
The EU AI Act is law. Article 14 addresses human oversight of high-risk systems within its scope: understanding limitations, avoiding excessive reliance on outputs, and enabling appropriate intervention or stopping. It does not require a person to approve every AI action. [7]
A Thai business must assess its role, system classification, EU connections and relevant application dates before reaching a legal conclusion. Article 2 can cover certain situations outside the EU; company location alone is insufficient. This article uses the law for comparison, not entity-specific legal advice. [8]
An illustrative month-end close and reporting process
This hypothetical process needs adjustment for materiality, systems and resources. Higher-risk points may require deterministic system rules as well as human review. An AI answer or confidence score alone is insufficient.
| Task | Suggested arrangement | Control activity |
|---|---|---|
| Set AI policy | HIC | The CFO approves data, tools, permissions and prohibited autonomous actions. |
| Classify document copies | Bounded HOOTL | Preserve originals, restrict access, log outputs and sample based on risk. |
| Match reconciliation items | HOTL | Route exceptions, set alerts and pause when conditions are breached. |
| Propose adjusting entries | HITL | Check evidence and approve before posting; separate preparation and approval. |
| Draft variance commentary | HITL before report use | Validate explanations against evidence, identify assumptions and obtain responsible review. |
Select oversight from risk, not the loop label
Assess materiality, reversibility, detection time relative to impact, transaction volume and evidence availability. High-impact actions or actions that cannot be stopped in time may need prior approval or exclusion from autonomous operation. If evidence is inadequate, adding an approval button does not solve the problem.
High volume does not automatically justify weaker controls over important transactions. Segment work, validate detection criteria, add review capacity or constrain the system. Test items passed by AI exception screening as well as flagged items. Sampling normal items supplements rather than replaces approvals required by applicable requirements or risk.
The relevant control window is not only the financial statement approval date. Interim reporting, payments and disclosure to different users also have their own consequences and deadlines.
AI is not another accountable person in segregation of duties
AI is a tool, not a person accountable for preparation or approval. AI preparation followed by one person’s approval does not itself demonstrate segregation of duties. Identify who defines inputs, changes content, reviews it and can post or approve transactions.
A person making substantive changes may also act as a preparer, creating a self-review concern. However, reviewing an AI output does not invariably turn every reviewer into a preparer. Important transactions need suitable review under the organisation’s control design and delegated authority.
Small organisations may consider compensating controls, but their precision and timeliness require assessment. Retrospective review cannot always replace prior approval. Risk-relevant changes to models, prompts and permissions should enter the applicable change-control process.
Evidence for review, not a promise of auditor reliance
Management owns reporting and controls; the board exercises its oversight role; the external auditor independently assesses evidence and audit procedures. TSA 330 paragraph 20 addresses substantive procedures over financial statement closing, including reconciliation to accounting records and examination of material adjustments. It does not require testing every control or certifying every AI tool [10].
The following evidence supports traceability. Its sufficiency and any control reliance depend on risk, design, implementation and actual testing. Discuss evidence expectations early without transferring management’s control-design or approval responsibilities to the auditor.
| Evidence | Review question |
|---|---|
| Investigation thresholds and materiality | What criteria prompt further investigation? |
| Information actually reviewed and its source | How complete and accurate is the review information? |
| Questions, corrections and approval rationale | Is there evidence of substantive consideration rather than only a signature? |
| Tool versions and input/output records | What can be explained retrospectively? Version records do not guarantee identical regenerated outputs. |
| Exception follow-up and test results | How were issues resolved, and can the controls detect errors? |
Test the system and the review process
Automation bias, rubber-stamping, fatigue and skill erosion are risks to assess. Without data, do not assume human failures outnumber AI failures. A low override rate could reflect good outputs or inadequate review, so interpret it alongside other evidence.
Approved simulations can include known errors such as wrong amounts, missing documents or unsupported explanations. Use appropriate data, isolate tests from production and prevent test entries from being posted or published. This is process testing, not covert individual performance assessment.
Detection results are one part of the evidence, not proof that controls work throughout every period. Assess test representativeness, escaped errors and the need for retesting after significant changes.
Additional references require scope-aware reading
The Bank of Thailand policy dated 12 September 2025 covers specified financial service providers. It discusses human in the loop and human over the loop proportionate to risk rather than prescribing one arrangement for all businesses. Its over-the-loop description permits autonomous operation with human takeover or suspension, broadly corresponding to HOTL here [9].
As checked for this update, the European Commission lists 2 December 2027 for high-risk rules under Annex III and 2 August 2028 for high-risk systems meeting the regulated-product conditions under Annex I, following the AI Omnibus entering into force on 27 July 2026. This does not postpone the entire AI Act: other provisions have different timelines. Check roles, system classification, specific provisions and EU connections [11].
Reasoned challenge of model outputs is a useful design concept, but SR 11-7 should not be presented as current guidance without qualification. The Federal Reserve states that SR 26-2 of 17 April 2026 replaces SR 11-7. Its banking scope does not make it a general requirement for Thai businesses or a GenAI certification [12].
Establish effective control before scaling
Start with one process. Identify potential harm, data and AI permissions. Define reviewers, escalation and stopping. Test missing data, incorrect answers, outages and model changes. Retain evidence of both success and failure before wider deployment.
Measure benefits after review time and rework. Monitor escaped errors, exceptions, response time and decision quality. As AI improves, controls may change, but the rationale and supporting evidence should be documented.
DHISORA’s advisory perspective connects AI-assisted finance with data, process, control and business outcomes. The scope of analysis, design and review should be agreed explicitly. Decisions remain with the authorised role. Referencing an international framework does not establish that every control has been implemented or is operating effectively.
Executive synthesis: judgment and human oversight
Part 4: process design and controls
Read next: judgment and DOA when AI assists preparation
Discuss your finance process and controls
Published 9 October 2026; updated 10 October 2026 by DHISORA Advisory. Educational guidance for initial process design. Referencing a framework does not certify a system, provide assurance or establish legal compliance for an organisation.
Questions to ask yourself
- Which actions may AI perform independently, and which must wait for an authorised person?
- Does the reviewer have the evidence, time, competence and authority to challenge AI?
- Would an error be detected before or after its impact, and how reversible is the action?
- Who approves and retests changes to the model, data or system permissions?
Start with the risk of the task, define human and AI authority, test the controls and retain evidence of review and monitoring. A loop label describes only part of the design.