Judgment และ Human Oversight ในงานการเงิน: ออกแบบการควบคุมและหลักฐานเพื่อการสอบทาน

การกำกับ การสอบทาน และการอนุมัติต้องระบุให้ชัด

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

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

ผู้รับผิดชอบหลักของกระบวนการ (Process Owner) ดูแลผลลัพธ์และการประสานงานภายในอำนาจ ส่วนผู้รับผิดชอบระบบงาน (System Owner) ดูแลระบบที่สนับสนุนงานตามหน้าที่ คู่มืออำนาจอนุมัติ (Delegation of Authority: DOA) และตารางบทบาท RACI ซึ่งระบุผู้ปฏิบัติ ผู้รับผิดชอบต่อผลสำเร็จ ผู้ให้ความเห็นและผู้รับทราบ ต้องสอดคล้องกับสิทธิ์จริง รายละเอียดแต่ละบทบาทอธิบายใน Playbook

เงื่อนไขที่ทำให้ดุลยพินิจเกิดขึ้นจริง

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

สี่รูปแบบของ Human Oversight

นิยาม HITL, HOTL และ HOOTL ต่อไปนี้ใช้คำอธิบายของ Australian Digital Transformation Agency ประกอบการออกแบบ ส่วน Human-in-command อ้างแนวทางจริยธรรมของ European AI High-Level Expert Group ซึ่งกล่าวถึง HITL, HOTL และ HIC ด้วย ศัพท์อาจมีรายละเอียดต่างกันตามสาขา จึงต้องระบุความหมาย ขั้นตอนและสิทธิ์จริงในเอกสารขององค์กร [1–2]

HIC ใช้ร่วมกับรูปแบบอื่นได้

ตัวอย่างความต่างของจังหวะ: HITL ให้รายการรอคนพิจารณาก่อนดำเนินการ HOTL ให้ระบบทำงานในขอบเขตพร้อมส่งสัญญาณถึงคนที่แทรกแซงได้ทัน ส่วน HOOTL ให้ระบบดำเนินการในวงจรที่กำหนดโดยไม่มีคนตัดสินแต่ละรอบ ทั้งสามยังต้องมีการกำกับเป้าหมาย ขอบเขตและเงื่อนไขเปลี่ยนหรือหยุดในระดับ HIC

HITL, HOTL และ HOOTL อธิบายความสัมพันธ์ระหว่างมนุษย์กับวงจรการตัดสินใจของงาน ส่วน HIC อธิบายการกำกับระดับองค์กร จึงไม่ใช่บันไดสี่ขั้นที่ต้องเดินจาก HITL ไปจบที่ HIC [1–2]

ในองค์กรเดียวกัน อาจใช้ HIC กำกับทุกกระบวนการ ใช้ HITL กับการอนุมัติรายการสำคัญ ใช้ HOTL กับงานกระทบยอด และใช้ HOOTL กับงานจัดหมวดที่ผลกระทบต่ำ นี่เป็นตัวอย่างการออกแบบ ไม่ใช่ข้อสรุปว่างานประเภทใดปลอดภัยโดยอัตโนมัติ

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

Internal Control กับ AI Governance ทำหน้าที่ต่างกัน

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

AI Governance กำหนดทิศทาง ขอบเขตและความรับผิดชอบ Internal Control ทำให้กระบวนการมีจุดป้องกันและตรวจพบความผิดพลาด Analysis ตรวจข้อมูลและสมมติฐาน ส่วน Professional Judgment พิจารณาความเหมาะสม ความมีสาระสำคัญ และข้อยกเว้น ก่อนผู้มีอำนาจตัดสินใจ

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

เชื่อม Human Oversight กับ COSO อย่างไร

COSO มีห้าองค์ประกอบ ได้แก่ สภาพแวดล้อมการควบคุม (Control Environment) การประเมินความเสี่ยง (Risk Assessment) กิจกรรมการควบคุม (Control Activities) สารสนเทศและการสื่อสาร (Information and Communication) และกิจกรรมติดตามผล (Monitoring Activities) เอกสาร GenAI ปี 2026 ประยุกต์กรอบเดิมกับความเสี่ยง AI รวมถึงงาน Judgment และ Human–AI Interaction [3]

COSO ไม่ได้กำหนดให้ทุกงานใช้ HITL หรือให้ชื่อ loop เป็นหลักฐานว่าระบบดี ตารางนี้เป็นการประยุกต์ของ DHISORA เพื่อเชื่อมกรอบกับจุดควบคุมที่ออกแบบและทดสอบได้

กรอบ มาตรฐาน และกฎหมายมีสถานะต่างกัน

NIST AI RMF เป็นกรอบสมัครใจ มีหน้าที่หลัก Govern, Map, Measure และ Manage ส่วน ISO/IEC 42001:2023 เป็นมาตรฐานระบบบริหารจัดการ AI และ ETDA มีแนวทางการประยุกต์ใช้ GenAI สำหรับองค์กร [4–6]

EU AI Act เป็นกฎหมาย โดย Article 14 กล่าวถึง human oversight สำหรับระบบ high-risk ภายใต้ขอบเขตกฎหมาย ให้สามารถเข้าใจข้อจำกัด เฝ้าระวังการเชื่อผลอัตโนมัติมากเกินไป และแทรกแซงหรือหยุดได้อย่างเหมาะสม ไม่ใช่คำสั่งให้ AI ทุกงานต้องมีผู้อนุมัติทุกครั้ง [7]

สำหรับธุรกิจไทย ต้องตรวจบทบาท ประเภทระบบ ความเกี่ยวข้องกับ EU และวันเริ่มใช้ข้อกำหนดที่เกี่ยวข้องก่อนสรุปการบังคับใช้ Article 2 มีขอบเขตที่อาจครอบคลุมบางกรณีนอก EU จึงไม่ควรสรุปจากที่ตั้งบริษัทอย่างเดียว บทความนี้ใช้กฎหมายเป็นข้อมูลเปรียบเทียบ ไม่ใช่ความเห็นทางกฎหมายเฉพาะกิจการ [8]

ตัวอย่างการปิดบัญชีและรายงานบริหาร

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

เลือกรูปแบบจากความเสี่ยง ไม่ใช่จากชื่อ loop

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

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

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

AI ไม่ใช่ผู้รับผิดชอบอีกคนในการแบ่งแยกหน้าที่

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

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

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

หลักฐานเพื่อการสอบทาน ไม่ใช่คำรับประกันการพึ่งพา

ผู้บริหารรับผิดชอบรายงานและการควบคุม คณะกรรมการกำกับตามบทบาท ส่วนผู้สอบบัญชีประเมินหลักฐานและวิธีตรวจสอบอย่างเป็นอิสระ TSA 330 ย่อหน้า 20 ระบุวิธีตรวจสอบเนื้อหาสาระที่เกี่ยวข้องกับกระบวนการปิดงบการเงิน รวมถึงการเทียบงบกับบันทึกบัญชีและตรวจรายการปรับปรุงที่มีสาระสำคัญ ไม่ได้แปลว่าผู้สอบบัญชีต้องทดสอบการควบคุมทุกจุดหรือรับรอง AI ทุกตัว [10]

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

ทดสอบทั้งระบบและกระบวนการสอบทาน

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

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

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

ข้ออ้างอิงเพิ่มเติมที่ต้องอ่านตามขอบเขต

แนวนโยบาย ธปท. ลงวันที่ 12 กันยายน 2568 ใช้กับผู้ให้บริการทางการเงินตามขอบเขตที่ระบุ เอกสารกล่าวถึง human in the loop และ human over the loop โดยให้พิจารณาระดับการมีส่วนร่วมตามความเสี่ยง ไม่ใช่ข้อกำหนดรูปแบบเดียวสำหรับทุกธุรกิจ คำว่า over ในเอกสารนี้หมายถึงระบบทำงานอัตโนมัติแต่คนเข้าควบคุมหรือระงับได้ จึงใกล้เคียง HOTL ในบทความนี้ [9]

European Commission ระบุ ณ วันที่ตรวจสอบว่าข้อกำหนดระบบ high-risk เริ่มใช้ 2 ธันวาคม 2570 สำหรับระบบตาม Annex III และกลุ่ม high-risk ที่เข้าเกณฑ์ผลิตภัณฑ์ตาม Annex I 2 สิงหาคม 2571 หลัง AI Omnibus มีผล 27 กรกฎาคม 2569 ไม่ควรสรุปว่าข้อกำหนด AI Act ทั้งหมดถูกเลื่อน เพราะส่วนอื่นมีตารางใช้ต่างกัน ต้องตรวจบทบาท ประเภทระบบ ข้อบทเฉพาะ และความเกี่ยวข้องกับ EU [11]

แนวคิดการโต้แย้งโมเดลอย่างมีเหตุผลนำมาประยุกต์เชิงออกแบบได้ แต่ไม่ควรอ้าง SR 11-7 เป็นแนวทางปัจจุบันโดยไม่ชี้แจง Federal Reserve ระบุว่า SR 26-2 วันที่ 17 เมษายน 2569 แทนที่ SR 11-7 แล้ว และมีขอบเขตด้านธนาคาร ไม่ใช่ข้อบังคับทั่วไปของธุรกิจไทยหรือการรับรอง GenAI [12]

ออกแบบให้ควบคุมได้ก่อนขยายการใช้

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

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

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

อ่านภาพรวม: บทสรุป Judgment และ Human Oversight

บทที่ 4: ออกแบบกระบวนการและระบบควบคุม

บทที่ 3: Judgment และ Risk

อ่านต่อ: Judgment และ DOA เมื่อใช้ AI ช่วยจัดทำ

หารือกระบวนการการเงินและจุดควบคุม

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