Playbook การใช้ AI ในงานการเงินด้วย Judgment และ Human Oversight

อ่านภาพรวมก่อนเริ่มใช้ Playbook

ผู้รับผิดชอบกระบวนการ ผู้รับผิดชอบระบบ และผู้อนุมัติเป็นคนละบทบาท

คำว่า owner ในงานกำกับดูแลหมายถึงบทบาทที่องค์กรกำหนดให้รับผิดชอบเรื่องนั้น ในชุดบทความนี้ใช้ชื่อบทบาทเต็มเพื่อให้ทราบว่ารับผิดชอบกระบวนการ ระบบ ความเสี่ยง หรือการควบคุม จึงไม่ใช้คำว่า “เจ้าของชัด” โดยไม่อธิบาย

ต้องกำหนดชื่อบทบาท ขอบเขตงาน อำนาจ ทรัพยากร ผู้ปฏิบัติแทนเมื่อไม่อยู่ และช่องทางส่งเรื่องที่เกินอำนาจ การใส่ชื่อบุคคลในตารางเพียงอย่างเดียวไม่เพียงพอ บุคคลหนึ่งอาจทำหลายบทบาทได้ แต่ต้องประเมินความขัดแย้งและการสอบทานตนเอง

คำที่ต้องแปลงเป็นกิจกรรมและเงื่อนไขจริง

ศัพท์เหล่านี้ช่วยจัดระบบงาน แต่ต้องระบุผู้ทำ เวลา ข้อมูล เกณฑ์และผลที่ต้องเกิดให้ตรวจสอบได้ ความหมายด้านล่างเป็นภาษาการทำงานของ Playbook ไม่ใช่นิยามทางกฎหมายที่ใช้แทนทุกมาตรฐานได้

กำหนดผลลัพธ์และขอบเขตที่ห้ามข้าม

เขียน Use Case Card ให้ระบุวัตถุประสงค์ กระบวนการและงวดบัญชี ผู้รับผิดชอบหลักของกระบวนการ ข้อมูลต้นทาง ระบบหรือผู้ให้บริการ และกิจกรรมที่ AI ทำได้ แยกการเสนอ การจับคู่ การบันทึก การตัดหนี้หรือผลต่าง และการจ่ายเงินออกจากกัน อย่าให้คำว่าอัตโนมัติครอบคลุมอำนาจทั้งหมดโดยไม่ตั้งใจ

สำรวจทั้งการใช้ที่อนุมัติแล้วและการใช้จริงที่ยังไม่อยู่ในทะเบียน รวมข้อมูลที่พนักงานส่งให้เครื่องมือภายนอก ตรวจข้อกำหนดของกิจการ กรอบรายงานทางการเงิน การรักษาความลับ และสิทธิ์เข้าถึง ก่อนเลือกวิธีดำเนินการ

เลือก Human Oversight แล้วพิสูจน์ว่าทำได้

นิยามต่อไปนี้เป็นภาษาสำหรับออกแบบใน Playbook ไม่ใช่การจัดระดับบังคับร่วมกันของทุกมาตรฐาน แนวทางจริยธรรมยุโรปกล่าวถึง HITL, HOTL และ HIC ส่วน DTA ออสเตรเลียอธิบาย HOOTL ด้วย เราใช้ Human-in-command เป็นชั้นกำกับนโยบาย เป้าหมาย ขอบเขตและการหยุด ซึ่งครอบรูปแบบการทำงานอื่นได้ [9–10]

พิจารณาผลกระทบ ความสามารถแก้กลับ ความเร็วของความเสียหาย การตรวจพบ การจำกัดวง และกำลังของผู้สอบทานร่วมกัน HITL ก็อาจล้มเหลวเมื่อผู้ตรวจไม่มีเวลา ข้อมูล หรือความสามารถ หากยังควบคุมไม่ได้ ให้ลดขอบเขต เปลี่ยนขั้นตอน หรือพักการใช้

เชื่อมอำนาจและการควบคุมโดยไม่สร้างอนุมัติซ้ำทุกจุด

DOA ระบุว่าใครตัดสินเรื่องใด ภายใต้เงื่อนไขอะไร RACI อธิบายบทบาทการทำงาน ส่วนสิทธิ์ในระบบทำให้ขอบเขตนั้นเกิดจริง ผู้ที่เป็น Accountable ใน RACI ไม่ได้มีอำนาจลงนามหรืออนุมัติตามกฎหมายโดยอัตโนมัติ

การอนุมัติกฎหรือขอบเขตให้ระบบดำเนินการไม่ทดแทนการอนุมัติรายธุรกรรมที่กฎหมาย นโยบาย หรือเงื่อนไขกำหนดไว้ AI ไม่ใช่บุคคลผู้รับมอบอำนาจ แบ่งแยกการสร้างหรือแก้กฎ การอนุมัติกฎ และการตรวจผลตามความเสี่ยง พร้อมจัดการผลประโยชน์ขัดกันเมื่อคนมีหลายบทบาท

ฝ่ายบริหารรับผิดชอบการจัดให้มีและดำเนินการควบคุม หน่วยความเสี่ยงหรือกำกับการปฏิบัติตามข้อกำหนดสนับสนุนและท้าทายตามบทบาท Internal Audit ให้ความเชื่อมั่นอย่างเป็นอิสระ ส่วนคณะกรรมการตรวจสอบอยู่ในบทบาทกำกับดูแล ไม่ใช่หน่วยปฏิบัติสายที่สอง [6]

สร้างชุดเอกสารขั้นต่ำที่เชื่อมกัน

ใช้รหัสอ้างอิงให้ค้นจากผลลัพธ์กลับไปยังแหล่งข้อมูล ความเสี่ยง กฎ ผู้ตัดสินและรุ่นที่ใช้ได้ ไม่ต้องบังคับว่าทุกเอกสารใช้รหัสเดียวกันหรือสัมพันธ์แบบหนึ่งต่อหนึ่ง แบบฟอร์มเป็นเครื่องช่วยคิด ไม่ใช่หลักฐานว่าควบคุมได้เพียงเพราะกรอกครบ

ทดสอบก่อนเริ่มใช้และตัดสินจากผลจริง

แยกการประเมินการออกแบบ การนำไปใช้จริง และการทำงานในช่วงที่ทดสอบ กำหนดเกณฑ์ผ่านไว้ก่อน ครอบคลุมรายการปกติและผิดปกติ ข้อมูลขาดหรือผิดงวด สิทธิ์ การเปลี่ยนรุ่น การล้มเหลวของการแจ้งเตือน การหยุด และวิธีสำรอง เปรียบเทียบกับผลที่ตรวจยืนยันอย่างอิสระ เพราะวิธีเดิมก็อาจผิด

หากทดสอบข้อผิดพลาดจำลอง ให้ใช้สภาพแวดล้อมที่อนุมัติและแยกจากรายการจริง ไม่แทรกข้อมูลผิดในบัญชีจริง การผ่าน IT General Controls ไม่พิสูจน์ว่าตรรกะการจับคู่หรือการคำนวณเฉพาะงานถูกต้อง ต้องทดสอบส่วนที่ใช้ตัดสินด้วย

เริ่มใช้ได้เมื่อผู้มีอำนาจเห็นผลทดสอบ ข้อจำกัด และความเสี่ยงคงเหลือครบตามขอบเขต การอนุมัติแบบมีเงื่อนไขต้องระบุวันสิ้นสุด เพดาน ผู้ติดตาม และเกณฑ์พักใช้ เรื่องที่ขัดข้อกำหนดบังคับไม่ใช่สิ่งที่ยอมรับความเสี่ยงแทนได้ อย่าผ่อนเกณฑ์ย้อนหลังเพียงเพื่อให้ผลผ่าน

วางการหยุดและกลับมาใช้ให้เป็นส่วนหนึ่งของกระบวนการ

ประเมินวงความเสียหายจากอัตราการทำงาน ระยะเวลาตรวจพบและหยุด ความผิดพลาดร่วมกัน และความสามารถย้อนแก้ ไม่ดูเฉพาะมูลค่าต่อรายการ เพดานทางการเงินไม่ทดแทนข้อจำกัดด้านข้อมูลส่วนบุคคล การทุจริต หรือข้อกำหนดอื่น

ตัวอย่างเดินงานตั้งแต่รับข้อมูลจนถึงตัดสินและติดตาม

กรณีสมมติ: มีเงินรับสองรายการจำนวนเท่ากันจากลูกค้าคนละราย AI เสนอจับคู่กับใบแจ้งหนี้ แม้ยอดรวมเท่ากับรายการธนาคาร แต่เอกสารอ้างอิงของหนึ่งคู่ไม่ตรง กระบวนการที่ออกแบบต้องทำให้รายการนี้ถูกพักและถึงคนที่ตัดสินได้ก่อนนำผลไปใช้

ผู้รับผิดชอบหลักของกระบวนการรับเงินดูแลให้ขั้นตอนทั้งหมดเชื่อมกัน ผู้รับผิดชอบระบบดูแลสิทธิ์และการเปลี่ยนแปลงตามหน้าที่ ผู้จัดทำตรวจข้อมูลต้นทาง ผู้สอบทานตรวจเรื่องที่กำหนด และผู้มีอำนาจอนุมัติการบันทึกหรือการปรับปรุงตาม DOA จึงต้องระบุบทบาทแยกกัน แม้บางบทบาทจะเป็นบุคคลเดียวกัน

ตัวอย่างบันทึกที่แสดงการสอบทานและการใช้ดุลยพินิจ

ข้อความว่า “ตรวจแล้ว เห็นชอบตาม AI” ยังไม่บอกว่าผู้สอบทานตรวจอะไรหรือเหตุใดจึงรับข้อเสนอ สำหรับเรื่องสำคัญ บันทึกควรเชื่อมสิ่งที่เห็นกับข้อสรุป โดยระบุแหล่งข้อมูล ประเด็นที่ตรวจ ผลที่พบ การแก้ไข เหตุผลและข้อจำกัดตามความเสี่ยงของงาน

ตัวอย่างสมมติ: “ตรวจรายการธนาคาร หลักฐานรับเงินและใบแจ้งหนี้ พบว่าคู่ที่ AI เสนอมีจำนวนเงินเท่ากันแต่เลขอ้างอิงเป็นของลูกค้าอีกคน จึงไม่รับข้อเสนอนี้ พักรายการและตรวจยืนยันกับผู้รับผิดชอบลูกหนี้ เมื่อได้หลักฐานที่สอดคล้องกันจึงเสนอคู่ที่แก้ไขให้ผู้มีอำนาจพิจารณาตาม DOA พร้อมเก็บเอกสารและบันทึกสิ่งที่แก้”

ข้อความนี้แสดงการพิจารณาข้อมูลที่ขัดกับข้อเสนอ แต่ไม่แปลว่าผู้สอบทานอนุมัติการบันทึกบัญชี ตัดหนี้หรือยอมรับความเสี่ยงทั้งหมด ต้องระบุการจัดทำ การสอบทาน การอนุมัติและการดำเนินการตามบทบาทจริง ส่วนข้อสงสัยที่ยังไม่จบต้องมีผู้ติดตามและกำหนดเวลา

ไม่ควรคัดลอกข้อความตัวอย่างไปลงนามโดยไม่ได้ตรวจจริง รายการประจำอาจใช้แบบฟอร์มหรือผลตรวจตามเกณฑ์ที่เหมาะสม ส่วนรายการที่ใช้ดุลยพินิจสูงต้องมีเหตุผลละเอียดขึ้นตามสาระ หลักฐานที่ดีช่วยให้ประเมินการควบคุมได้ แต่ไม่รับประกันว่าผู้สอบบัญชีจะพึ่งพาการควบคุมนั้น

สองกรณีสมมติที่ช่วยแยกอำนาจและดุลยพินิจ

ประมาณการผลขาดทุนด้านเครดิต: AI อาจช่วยจัดข้อมูล วิเคราะห์สถานการณ์ และร่างคำอธิบาย ผู้ตัดสินต้องพิจารณาความเหมาะสมของวิธี สมมติฐาน ข้อมูลคาดการณ์ และอคติ ใช้ข้อกำหนด TFRS 9 เมื่อกิจการและรายการอยู่ในขอบเขต ไม่สมมติว่าทุกกิจการ SME ใช้กรอบเดียวกัน [7]

งานจับคู่รับเงินปริมาณสูง: การเสนอคู่ไม่เท่ากับการอนุมัติบันทึก ตัดหนี้หรือผลต่าง หรือจ่ายเงิน ทดสอบยอดควบคุม รายการซ้ำ การระบุตัวผู้จ่ายและเอกสารอ้างอิง รวมการสุ่มตรวจรายการที่ระบบระบุว่าผ่าน ยอดรวมตรงกันอาจยังซ่อนการจับคู่ผิดตัว ตรวจย้อนหลังรายเดือนอย่างเดียวไม่แสดงว่า HOTL หยุดความเสียหายทัน

หลักฐานที่จัดทำช่วยการสอบทานและการประเมิน แต่ไม่ได้รับรองว่าผู้สอบบัญชีจะพึ่งการควบคุม ผู้สอบบัญชีประเมินและกำหนดวิธีตรวจตามมาตรฐาน เช่น TSA 330 และ TSA 540 (ปรับปรุง) อย่างเป็นอิสระ [8]

ใช้กรอบอ้างอิงอย่างตรงสถานะ

ตรวจฉบับ ขอบเขตผู้ใช้ ประเภทระบบ และวันที่มีผลก่อนกล่าวว่าองค์กรต้องทำอะไร การนำแนวคิดต่างกรอบมาเชื่อมกันใน Playbook นี้เป็นการสังเคราะห์ของ DHISORA ไม่ใช่ตารางเทียบเพื่อรับรองการปฏิบัติตามกฎหมาย

วัดคุณค่าหลังรวมต้นทุนของการควบคุม

กำหนดฐานเปรียบเทียบ (baseline) ก่อนทดลอง ได้แก่ ระยะเวลาทำงานและสอบทาน งานแก้ซ้ำ ข้อผิดพลาดที่หลุดผ่าน ข้อยกเว้นค้าง และต้นทุนรวม วัดร่วมกับความสามารถอธิบายและตรวจสอบย้อนกลับ ไม่ใช้จำนวนคำสั่ง AI หรือเวลาผลิตชิ้นงานเป็นตัวแทนคุณค่าทั้งหมด

อัตราการเปลี่ยนหรือไม่รับผลระบบ (override rate) ต่ำอาจแปลว่าผลดี หรือผู้ตรวจไม่ท้าทายก็ได้ ต้องอ่านกับผลตรวจที่เป็นอิสระ ความครบถ้วนของข้อมูล และภาระงาน หลักฐานลายมือชื่อหรือชื่อ framework ไม่ใช่เหตุผลเพียงพอสำหรับราคาที่สูงขึ้น คุณค่าควรอยู่ที่การตัดสินใจและผลการดำเนินงานที่ดีขึ้น

ดาวน์โหลด Playbook และแบบฟอร์มสองภาษา

อ่าน Playbook ฉบับ PDF ซึ่งมีแนวทางปฏิบัติ 12 บท กรณีสมมติ 2 เรื่อง และแบบฟอร์ม 8 ชุด หากต้องการกรอกหรือปรับแบบฟอร์ม ให้ดาวน์โหลดชุดแบบฟอร์ม Word แยกต่างหาก ทั้งสองรูปแบบมีภาษาไทยและภาษาอังกฤษ

ฉบับเผยแพร่เพื่อการศึกษาและอ้างอิงทั่วไป | Version 1.0.1 | 10 October 2026

เอกสารนี้ให้ความรู้และแนวทางทั่วไป ไม่ใช่คำแนะนำเฉพาะกิจการ ความเห็นทางกฎหมาย รายงานให้ความเชื่อมั่น หรือการรับรองระบบ ตัวอย่างและแบบฟอร์มต้องปรับและสอบทานตามข้อเท็จจริง อำนาจ ความเสี่ยง และข้อกำหนดที่ใช้บังคับก่อนใช้ การดาวน์โหลดไม่ถือเป็นการว่าจ้างหรือการยืนยันรับงานจาก DHISORA Advisory

อนุญาตให้อ้างอิงและปรับแบบฟอร์มใช้ภายในกิจการ โดยระบุที่มา เลขรุ่น และการแก้ไขของผู้ใช้ การเผยแพร่ฉบับเต็ม ดัดแปลงเพื่อเผยแพร่ หรือใช้เชิงพาณิชย์ต้องขออนุญาตก่อน เว้นแต่กฎหมายอนุญาต โปรดอ่านรายละเอียดในไฟล์และข้อกำหนดการใช้เว็บไซต์ ขอบเขตและสิทธิการใช้

ดาวน์โหลด Playbook ภาษาไทย (PDF)

ดาวน์โหลด Playbook ภาษาอังกฤษ (PDF)

ดาวน์โหลดแบบฟอร์มแก้ไขได้ ภาษาไทย (Word)

ดาวน์โหลดแบบฟอร์มแก้ไขได้ ภาษาอังกฤษ (Word)

เผยแพร่ 10 ตุลาคม 2569 ข้อเสนอและแบบฟอร์มในบทความนี้จัดทำโดย DHISORA เพื่อการประเมินและออกแบบ ไม่ใช่ความเห็นทางกฎหมาย การรับรองระบบ หรือรายงานให้ความเชื่อมั่น งานเทคนิค ความปลอดภัย และกฎหมายต้องใช้ผู้เชี่ยวชาญที่เหมาะสมเมื่อจำเป็น