Judgment and risk: managing AI as both a tool and a source of risk

Part 1: Human oversight · Part 2: Judgment and DOA

Describe the failure scenario and assigned responsibility

A use case is AI use for a specific activity, objective and scope, such as receipt-to-invoice matching. A risk register records scenarios, causes, consequences, assigned roles and responses. “AI may be wrong” alone does not identify a suitable control or decision-maker.

For example, incomplete invoice data may cause a receipt to be matched to the wrong customer, distorting receivables and collection follow-up. The receipt process owner coordinates remediation, the system owner addresses relevant access or configuration issues, and authorised roles approve corrective transactions under DOA.

Shadow AI is actual use outside the organisation’s intended visibility or governance, such as using personal AI tools with customer documents. Inventory supports assessment and remediation; recording a tool does not approve its use.

Separate assessment from risk acceptance

How likely and severe an event could be is different from how much risk the organisation is willing to accept. Risk-register ratings may combine data, forecasts and judgment. Record the basis, time horizon and uncertainty rather than imply precision unsupported by evidence.

Risk appetite describes the types and amount of risk pursued or retained in achieving objectives. Risk tolerance provides operational boundaries for acceptable variation; risk capacity concerns the ability to bear risk. Define these consistently in the organisation’s framework.

Management proposes and operationalises boundaries; the board or appropriate governing body provides direction and oversight. Not every acceptance decision requires board approval, but authority and reserved matters must be respected. Appetite cannot authorise breaches of law, standards or professional duties [1, 8].

Consider three dimensions of AI risk

This three-part lens is DHISORA’s explanatory design, not a mandatory taxonomy. It helps prevent all AI risk being assigned to IT alone.

Define judgment risk and require evidence

Here, judgment risk means the risk that an important decision receives inadequate consideration or uses distorted information and assumptions. It may be separately recorded or linked to existing risks. It overlaps with aspects of NIST’s human–AI interaction risks but is not an identical standard definition [4].

A near-zero override rate or absence of disagreement is a signal, not proof that judgment is absent. Interpret it with output quality, workload and review evidence.

Assess exposure and shared failures

A likelihood–impact matrix can assess events affecting many transactions. Human errors can also be systematic. AI assessment needs attention to speed, exposed volume, shared data or vendors, and time to detection and stopping—not an assumption that every AI output will fail.

Preparation and checking systems can share errors through common data or assumptions. Another AI does not guarantee independence. AI can also suggest novel risks and scenarios, but their plausibility and information gaps require examination.

Illustration: at 200 actions an hour and three hours from incident onset to detection and stopping, 600 actions may pass through the system, before accounting for queues and downstream work. This is potentially exposed volume, not the number of errors or a loss forecast. Consequences and dependencies need separate assessment.

Consider bounded batches, staged release, parallel testing after material changes and tested fallback arrangements. Residual-risk assessments need evidence of control operation, not a lower rating simply because an SOP or approval button exists.

Turn appetite into actionable boundaries

These are illustrative policy choices, not universal requirements. Accounting materiality is only one factor: confidentiality, fraud and legal compliance can matter at low monetary values.

Connect use cases to financial closing

Replace a generic “AI risk” label with a cause, failure scenario, consequence, owner and control. Link the AI use-case register → risk register → risk and control matrix → DOA → review evidence through linked references, allowing one risk to connect to several controls and one control to address several risks. Existing registers can be extended rather than duplicated.

Assign risk roles and preserve independence

Assign ownership by responsibility and authority to manage the risk, not automatically to IT or the last AI-output user. Finance should own relevant accounting risks with supporting roles; security or vendor risks may have other owners. Cross-process risks need coordination.

Under the Three Lines concept, management owns operations and manages risk, second-line roles support and challenge, and internal audit provides independent assurance and advice. The governing body oversees. Smaller organisations may combine some roles, but should identify conflicts and safeguards rather than make the audit committee management’s control owner [7].

Advice is not the same as taking decision responsibility. Subsequent assurance requires assessment of independence and self-review under applicable requirements. External auditors work within their engagement scope, not as certifiers of the entire ERM or AI system.

Distinguish reference status

COSO ERM connects risk with strategy; COSO Internal Control and GenAI guidance address control design. They are distinct, and referencing either does not establish effectiveness [1–2].

TSA 540 (Revised) addresses auditor responsibilities for estimates, including indicators of management bias. It does not require organisations to retain every AI alternative; the evidence proposals here are DHISORA’s application [10].

Executive synthesis: judgment and human oversight

Part 4: process design and controls

Discuss risk and controls in your finance process

Published 10 October 2026 by DHISORA Advisory. Initial assessment and design guidance, not a legal opinion, certification or assurance. Implementation requires checking applicable requirements, entity type and engagement scope, with technical, security or legal specialists where needed.