EXECUTIVE SYNTHESIS / CFO / AI GOVERNANCE
Executive synthesis: judgment and human oversight in AI risk management and control
Connect human oversight, DOA, risk and process design, with hypothetical accounting-estimate and high-volume receipt-matching examples.
When AI supports finance, what justifies using its outputs, who holds decision authority, and can failures be detected in time? The answer requires reliable information, working controls, reasoned judgment and evidence. A tool name or approval signature alone is insufficient.
This synthesis connects DHISORA’s four articles as an entry point or executive review for CFOs, management and governing bodies. Its examples are hypothetical design proposals, not client cases, mandatory templates or a guarantee of auditor reliance.
The series: choose your decision question
- Where should people intervene? Judgment and human oversight in finance: controls and evidence for review
- Who holds decision authority? Judgment and DOA: approval authority when AI assists preparation
- Which risks need controls? Judgment and risk: managing AI as both a tool and a source of risk
- How can controls work every period? Process design and risk management: making judgment and AI controls work every close
Distinguish assigned responsibility from decision authority
A process owner coordinates end-to-end outcomes, participants and remediation within assigned authority; it does not mean the business proprietor. Define system, risk and control responsibility, review and approval separately, even where one person holds several roles.
Delegation of authority (DOA) records decision and approval powers. A risk and control matrix (RCM) links risks to controls. To-Be describes the intended future process. The linked playbook explains these roles and practical operating terms in more detail.
Three elements that must work together
Judgment is reasoned assessment and decision-making under information and constraints. Human oversight provides the roles, information, time and authority to supervise effectively. Risk management establishes objectives, failure scenarios, responses and residual risk. Judgment matters throughout the process, not only at its highest-risk point.
DHISORA connects risk → oversight → authority and controls → operation and evidence → reassessment. Evidence includes sources, checks, changes and rationale, rather than signatures alone. Its own completeness and reliability also require evaluation.
Choose oversight by risk, not volume alone
These terms serve as design language in this series, not universally identical categories across every framework. Specify actual responsibilities and intervention timing. Human-in-command is a governance layer over other arrangements, not a fourth automation level.
| Arrangement | What must actually happen | Boundary |
|---|---|---|
| Human-in-the-loop / HITL | People review and decide before a specified action. | Important decisions require sufficient information, time, competence and authority. |
| Human-on-the-loop / HOTL | The system operates within scope while people monitor and intervene in time. | Periodic retrospective checks alone do not establish timely containment. |
| Human-out-of-the-loop / HOOTL | No person participates in the specified execution cycle. | Ownership, limits, testing, monitoring and incident management remain necessary. |
| Human-in-command / HIC | People govern objectives, policy, authority, stopping and changes. | Management and governing bodies retain their roles; AI does not hold personal authority. |
Embed judgment across the cycle and connect the four articles
This table is DHISORA’s synthesis. Activities may repeat or overlap; it is not a prescribed sequence or a replacement for a complete risk-management framework. COSO’s 2026 GenAI guidance applies its existing control framework to GenAI; it is not legislation or AI certification [1].
| Decision point | Supporting structure | Detailed reading |
|---|---|---|
| Objectives and risk boundaries | Management and governing bodies act within their roles, with authorised risk acceptance. | Part 3: risk |
| Failure scenarios and exposure | Use-case inventory, shared failures and exposure before detection. | Parts 3 and 4 |
| Oversight arrangement | Consider impact, speed, detection, reversibility and review capacity. | Part 1: human oversight |
| Authority and segregation | Align DOA, approval conditions, roles and system permissions. | Part 2: DOA |
| Operation | To-Be, RCM, decision information and evidence from actual periods. | Part 4: process design |
| Monitoring and change | Owners remediate and escalate; governing bodies oversee within their roles. | Parts 3 and 4 |
Use several risk responses and acknowledge residual risk
Avoiding AI in an activity may remove a specific exposure while human, data or fallback risks remain. Prevention, detection, containment and remediation reduce risk when they work. Do not claim zero overall risk or assume late detection always reduces consequences.
Residual-risk acceptance needs defined scope, authority and rationale. It cannot waive mandatory requirements. Different signatures may evidence preparation, review or approval; not every signature means acceptance of all organisational risk.
| Mechanism | Judgment and controls | Limitation |
|---|---|---|
| Avoid or rescope | Exclude actions that cannot yet be controlled. | Assess risks of the alternative approach. |
| Prevent | Validate inputs and approve important actions beforehand. | Approvers may be biased or fail to review. |
| Detect | Check items and patterns against verifiable information. | Signals may miss failures; timely response is needed. |
| Contain | Limit access, batch size, execution rate and stopping thresholds. | Many low-value items can create large aggregate exposure. |
| Remediate and learn | Contain, investigate, correct affected results and test before restarting. | Prompt changes alone may not address data or access failures. |
Hypothetical case 1: a judgment-intensive ECL estimate
Assume a pre-IPO company applies full TFRS and TFRS 9 to the receivables in this example. AI assembles data and proposes expected credit loss rates; authorised people assess methods and assumptions. This does not imply identical ECL requirements for every medium-sized entity.
TFRS 9 paragraphs 5.5.17–5.5.18 require measurement to reflect unbiased probability-weighted outcomes, time value of money and reasonable, supportable information about past events, current conditions and forecasts, without identifying every possible scenario [2]. The table illustrates controls, not the full measurement methodology.
| Stage | Proposed practice | Evidence and limitation |
|---|---|---|
| Define scope | AI supports data and alternatives; people decide methods and assumptions under DOA. | Proposing assumptions differs from selecting and applying them autonomously. |
| Validate inputs | Reconcile receivables to subledger and general ledger; examine dates and grouping. | Matching totals do not establish item-level or grouping accuracy. |
| Independent assessment | A CFO or reviewer develops evidence-based expectations before comparing the proposal. | Human expectations also require challenge, not automatic preference. |
| Identify limitations | A 12-month dataset omits an 18-month-old default still relevant to the portfolio. | Assess relevance and forecasts; longer history is not always more appropriate. |
| Decide and document | Review method, assumptions, sensitivity and limitations; approve within authority. | Retain significant alternatives, rationale and contradictory evidence, not every AI answer. |
| Monitor | Compare outcomes over an appropriate horizon and assess changes. | Variances may reflect uncertainty, not necessarily model failure. |
Hypothetical case 2: high-volume receipt matching
Assume several thousand receipts per month. AI proposes invoice matches; the system accepts only results meeting tested, approved conditions. That scope does not include write-offs, adjustment posting or payment execution without separately appropriate authority and controls.
High volume does not automatically mean medium risk. Assess aggregate value, shared failures, speed and stopping time. Accounting materiality alone is not a sufficient boundary for personal-data risks, fraud or mandatory requirements.
| Stage | Proposed practice | Evidence and limitation |
|---|---|---|
| Design and authorise | Define customer and document identifiers, amount checks, exceptions and permissions. | Rule approval does not replace reserved transaction approvals. |
| Test | Use verified outcomes; include duplicates, equal amounts for different customers and fallback. | Run risk-appropriate parallel testing and begin with a limited scope. |
| Monitor | Use HOTL only with monitoring and intervention within a suitable response time. | Review exceptions and risk-based samples of passed matches, not totals alone. |
| Incident | Following a change, equal-value receipts are matched to different customers. | Item-level checks confirm failure; a higher match rate is only a signal. |
| Stop and contain | Suspend automatic acceptance, contain potentially affected items and activate fallback. | Assign stopping, investigation and impact-assessment authority. |
| Remediate and restart | Correct confirmed errors, retest revised criteria and approve changes. | Perform lookback review, log the incident and define restart conditions. |
Evidence enables assessment but does not guarantee reliance
Management uses information for decisions and operations, governing bodies for oversight, and auditors assess evidence against engagement objectives and standards. People, authority, risk boundaries, controls and rationale support assessment; together they still do not guarantee reliance by every party.
TSA 330 governs auditor responses to assessed risks, including control testing when relevant conditions apply [3]. TSA 540 (Revised) concerns auditing estimates and related disclosures [4]. Management records support the process rather than replace the auditor’s required procedures.
Useful evidence connects sources, methods, assumptions, significant alternatives, checks, changes, authority and relevant versions, with appropriate access and retention. It does not require purposeless collection of every prompt or message. Framework references do not establish operating effectiveness.
What this means for DHISORA
DHISORA aims to help management design and exercise judgment within accountable finance processes, connecting accounting, risk, authority, controls and evidence with AI support. Responsibility remains with the relevant people. Technical, security or legal work requires appropriate expertise where needed.
Effective controls may support wider AI use within validated boundaries. Expansion is not necessary in every activity, nor does every step require another approval. Advisory value should arise from better decisions and operating outcomes, rather than merely the presence of AI or a signature.
Apply the synthesis: a playbook with templates and criteria for go-live, stopping and restart
Discuss judgment and controls in your finance process
Published 10 October 2026 by DHISORA Advisory. A synthesis for assessment and design, not legal advice, system certification or an assurance report. Implementation depends on entity type, reporting framework, applicable period and engagement scope.
Questions to ask yourself
- Which decisions require prior human review, and which can be monitored with timely intervention?
- Are matching, posting, write-off and payment powers clearly distinguished?
- Does evidence show what was examined, changed and decided, or only approval?
- How many items can a shared failure affect before detection and containment?
- Does the residual-risk acceptor have authority and sufficient information, within mandatory requirements?
Choose one process. Define risks and permitted AI actions, provide timely oversight, align DOA with system permissions, test before use, retain evidence during operation and reassess against actual results. Claimed risk reduction needs a reasoned basis and operational evidence.