PROCESS DESIGN / INTERNAL CONTROL / AI GOVERNANCE
Process design and risk management: making judgment and AI controls work every close
Connect To-Be processes, RCM, RACI, DOA, testing and evidence within an AI-assisted financial close.
AI policies and risk registers create value when they improve decisions and daily work. A workable system embeds controls into activities and provides the time, information, authority and evidence needed for judgment, including a response when results depart from expectations.
This fourth article builds on human oversight, DOA and risk, using financial closing as an example. Its focus is a finance process that can be controlled and reviewed, with AI supporting that process. The examples, criteria and tables are DHISORA proposals, not client cases or universal requirements.
Related reading: Human Oversight · Judgment and DOA · Judgment and risk · Business Process Solutions
Vocabulary for process maps and control records
As-Is describes actual current work, including shortcuts, rework and tools used outside formal procedures. To-Be describes the intended future process, with changes, operators, checks and decisions; it is more than a tidier diagram.
A risk and control matrix (RCM) connects objectives, risks, controls, assigned roles, procedures, frequency and evidence. RACI defines working responsibilities; delegation of authority (DOA) defines decision powers and conditions. They answer different questions and require alignment.
A swim-lane diagram separates activities by role or system to show execution and handoffs. The process owner coordinates overall outcomes; the system owner is responsible for the supporting system within assigned duties. These may be different people.
Design around decisions and the information they need
Establish objectives and failure scenarios before selecting a tool. Identify what must be decided, by whom, with which information and by when, then design activities around that decision. For accounting estimates, authorised people need timely evidence about data, methods, assumptions, sensitivity and significant limitations.
| DHISORA design principle | What must work | Financial-close example |
|---|---|---|
| Start with failure scenarios | Connect to objectives and consequences | Identify incomplete balances, false matches and cutoff errors before selecting controls. |
| Place decisions first | Provide authority, information and time | Schedule evidence collection backwards from assumption approval. |
| Produce evidence during work | Record checks, changes and rationale | An approval click alone may not demonstrate review quality. |
| Make failures visible | Use checks independent of the failure source | Reconcile totals and counts, then test matching accuracy. |
| Enable stopping and continuity | Assign stopping, containment and fallback | Rehearse closing when the primary tool is unavailable. |
| Retain organisational knowledge | Keep portable rules, criteria and rationale | Maintain procedures and version records beyond one user account. |
Implement a cycle with readiness decisions
COSO’s 2026 roadmap covers governance, use-case inventory, risk assessment, control design, implementation and communication, then monitoring and adaptation. Changed circumstances lead back to governance review [2]. The table below is DHISORA’s application; its readiness questions are not five mandatory COSO gates.
| Stage | Connected outputs | Question before proceeding |
|---|---|---|
| 1 Govern | Scope, policies, ownership and authority | Who may accept risk and approve changes? |
| 2 Inventory | Actual As-Is process and use cases, including informal use | Are data, tools, connections and owners sufficiently understood? |
| 3 Assess | Failure scenarios, consequences and priorities | Have accounting, data, human and shared-dependency risks been considered? |
| 4 Design | To-Be, RCM, roles, authority, permissions and evidence | Can the controls operate within the actual timetable? |
| 5 Test and implement | Results, training, communication and go-live approval | Are criteria met, limitations acceptable and fallback ready? |
| 6 Monitor and adapt | Exceptions, incidents and change records | Should controls or scope change, or governance be reassessed? |
Connect records while distinguishing roles from authority
Extend existing registers where sufficient. Link use cases, risks, controls, responsibilities, authority and evidence through references. One risk may have several controls; one control may address several risks. Do not force all records to share one identifier or promise that tracing requires only one step.
RACI identifies Responsible, Accountable, Consulted and Informed roles. Accountable means accountability for the activity’s outcome, not automatic authority to approve every transaction. DOA specifies approval powers and conditions; system permissions implement their boundaries. Align all three and preserve segregation of duties.
A swim-lane diagram may give AI or systems a separate lane to expose automated activities and handoffs, while identifying human owners. Symbols within existing lanes may be clearer in some processes. AI is not a management accountability holder. A handoff is not necessarily an approval: specify what is received, checked or authorised.
Go-live approval authorises a method and scope. It does not replace transaction approvals retained by law, policy or DOA. Distinguish matching, journal adjustments, write-offs and payment execution.
RCM example: AI-assisted bank reconciliation matching
The failure scenario is incorrect matching or hidden unresolved items that mislead the reviewer. Reconciliation supports completeness and accuracy of balances, but alone does not establish every assertion, such as rights to deposits. This table illustrates fields for one use case; an operational RCM may separate them into several controls.
| Field | Proposed example | Important boundary |
|---|---|---|
| Scope and references | UC-BR-01 links R-BR-01 with FC-BR-01 to 03. | Separate input validation, matching and reconciliation review. |
| Permitted autonomous actions | Propose matches within approved criteria. | Matching alone grants no write-off, adjustment-posting or payment authority. |
| Input controls | Check totals, counts, dates and duplicates against sources. | Matching totals do not exclude false matches; test individual items. |
| Output controls | Review exceptions and risk-based samples of matched items. | Selection and sample size should address risk, not a universal fixed count. |
| Oversight and frequency | HITL for important acceptance decisions; HOTL with timely monitoring and intervention. | Monthly retrospective review alone is not intervention during operation. |
| Stop and remediate | Stop for incomplete data, significant anomalies or failed criteria. | Specify authority, containment, lookback review and restart conditions. |
| Ownership and evidence | Preparer and reviewer under DOA; sources, matches, exceptions, changes and approvals. | Apply relevant access and retention requirements. |
Assess technology and control operation together
IT general controls (ITGC) address matters such as access, changes and system operations. Application-specific controls address the inputs and logic of a particular activity: receipt matching needs payer and reference checks, beyond appropriate user access.
Distinguish manual, rules-based automated, AI-dependent and hybrid controls to identify what needs testing. This does not imply that every AI system varies on every run, or that effective IT general controls alone establish a rules-based control’s reliability.
Assess relevant logic, configuration, inputs, access and changes. GenAI behaviour may change with model, data or configuration changes. Record available version information; where a provider does not disclose a subversion, retain known information and complement it with behavioural testing. Audit testing and reliance remain the auditor’s judgments.
Set acceptance criteria before seeing results
Test whether design addresses risk, whether it has been implemented, and whether evidence supports operation over the tested period. A short pilot does not establish year-long effectiveness. The legacy method may also be wrong, so use independently verified outcomes where possible.
One parallel close may be a starting point, rather than a universal minimum or sufficient test. Coverage depends on risk, year-end activities, workload and rare transactions. Run seeded errors and simulated attacks in an approved, isolated environment without affecting live records or exposing confidential data. NIST’s GenAI Profile supports risk assessment and testing; it is not a system certification checklist [3].
| Scenario | What to demonstrate | Response to failure |
|---|---|---|
| Missing data, wrong period or units | Unready inputs do not silently proceed. | Contain work, correct inputs and review affected results. |
| False matches with matching totals | Item-level errors are detected. | Revise criteria and retest previously accepted items. |
| Instructions hidden in documents | Document content does not acquire execution authority. | Use appropriate specialists to test relevant boundaries and protections. |
| Incorrect output presented to people | Reviewers detect and escalate within the required time. | Improve evidence presentation, review criteria and capacity. |
| Model or configuration change | Impact is assessed and tested before acceptance. | Restrict use or roll back where feasible. |
| Tool outage | Fallback operates with available data and time. | Revise continuity arrangements and activation authority. |
Monitor the system and the quality of judgment
Interpret metrics in context. Low override rates may reflect quality or inadequate review; short review times may reflect simple work or overload. Seeded-error detection measures the tested scenarios, not judgment as a whole. Combine metrics with evidence and investigation.
| Indicator | Decision question | Action and escalation |
|---|---|---|
| Errors and false matches | What failed, where did it cluster, and how many items escaped? | Process owners address causes and assess prior-period effects. |
| Open exceptions and their age | Is work waiting for information or for authority? | Escalate to the relevant DOA level. |
| Automated volume, value and speed | What exposure accumulates before detection and stopping? | Management reassesses scope and stopping criteria. |
| Review quality and capacity | Are important issues detected in time? | Control owners adjust workload, information and oversight. |
| Changes and incidents | Does prior testing remain valid? | Finance, IT and security coordinate under assigned responsibilities. |
Scale the system without weakening accountability or independence
A medium-sized organisation may start with simple registers and a few key controls. A CFO may hold multiple roles, but conflicts and compensating review require explicit consideration. The audit committee oversees rather than operating as a second-line function. Outsourced internal audit still requires appropriate independence and engagement scope [4].
Management operates processes and manages risk; second-line roles support and challenge; internal audit provides independent assurance and advice. Advisory design does not transfer management’s decision authority to the adviser. Technical or security testing requires appropriate expertise.
Set review frequency according to risk rather than a universal annual rule. Reassess when tools, data, permissions, processes or people change, after significant incidents and before milestones such as an IPO filing. Build structures that can expand without duplicate documentation.
Use references according to their status
COSO Internal Control is a framework; its 2026 GenAI publication provides application guidance, not AI legislation or certification [1–2]. The linked records and RCM examples here are DHISORA’s analysis, not prescribed COSO templates.
The Thai SEC’s assessment form supports evaluation of internal-control sufficiency in relevant contexts; it is not an AI-specific checklist [5]. Pre-IPO companies should check requirements for their status and offering process against current rules. Documentation and testing do not guarantee IPO approval or auditor reliance.
Executive synthesis: judgment and human oversight
Put the design into operation: playbook and templates
Discuss finance process design and control points
Published 10 October 2026 by DHISORA Advisory. Assessment and design guidance, not a legal opinion, certification or assurance report. Implementation requires applicable entity-specific requirements, agreed scope and specialist expertise where needed.
Questions to ask yourself
- Does the As-Is process show actual AI use, including unapproved tools?
- Do decision-makers receive sufficient information and time before the close deadline?
- Can each risk be traced to accountable roles, system permissions and evidence from the actual period?
- Were acceptance criteria set before results, and was fallback tested?
- Who can stop a failing system, which transactions will be contained, and what permits restart?
- Which controls need a smaller scope or more capacity to operate every period?
Start with one important process. Establish actual practices, decision points and failure scenarios. Connect risks, controls, authority and evidence; set criteria before testing. Authorised people should assess readiness from results and limitations before expanding use.