Judgment และ Risk: บริหารความเสี่ยงเมื่อ AI เป็นทั้งเครื่องมือและแหล่งความเสี่ยง

บทที่ 1: Human Oversight · บทที่ 2: Judgment และ DOA

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

Use case คือการใช้ AI ในกิจกรรมที่มีวัตถุประสงค์และขอบเขตเฉพาะ เช่น เสนอจับคู่รับเงินกับใบแจ้งหนี้ ส่วน Risk Register คือทะเบียนที่ระบุเหตุการณ์เสี่ยง สาเหตุ ผลกระทบ ผู้รับผิดชอบและแนวทางจัดการ การเขียนเพียงว่า “AI อาจผิด” ยังไม่ช่วยให้เลือกการควบคุมหรือผู้ตัดสินได้

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

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

แยกการประเมินออกจากการยอมรับความเสี่ยง

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

Risk Appetite คือประเภทและระดับความเสี่ยงที่องค์กรเต็มใจรับเพื่อบรรลุเป้าหมาย ส่วน Risk Tolerance ใช้กำหนดขอบเขตความคลาดเคลื่อนที่ยอมรับได้ในการปฏิบัติ และ Risk Capacity สะท้อนความสามารถรองรับความเสี่ยง ต้องนิยามให้สอดคล้องกันในกรอบขององค์กร

ฝ่ายบริหารเสนอและแปลงกรอบเป็นเกณฑ์ปฏิบัติ คณะกรรมการหรือผู้กำกับที่เหมาะสมให้ทิศทางและกำกับตามบทบาท ไม่จำเป็นต้องส่งการยอมรับความเสี่ยงทุกเรื่องถึงคณะกรรมการ แต่ต้องมีอำนาจตาม DOA และเรื่องที่สงวนไว้ Risk Appetite ไม่ใช่อำนาจให้ฝ่าฝืนกฎหมาย มาตรฐาน หรือหน้าที่วิชาชีพ [1, 8]

มอง AI ผ่านความเสี่ยงสามด้าน

การแบ่งสามด้านนี้เป็นกรอบอธิบายของ DHISORA เพื่อไม่ให้ความเสี่ยงถูกฝากไว้กับ IT เพียงฝ่ายเดียว ไม่ใช่หมวดบังคับจากมาตรฐาน

Judgment Risk ต้องมีนิยามและหลักฐาน

ในบทความนี้ Judgment Risk หมายถึงความเสี่ยงที่การตัดสินใจสำคัญไม่ได้รับการพิจารณาอย่างเพียงพอ หรืออิงข้อมูลและสมมติฐานที่บิดเบือน องค์กรอาจบันทึกเป็นความเสี่ยงแยกหรือเชื่อมกับความเสี่ยงเดิม ไม่จำเป็นต้องสร้างหมวดใหม่ทุกกรณี แนวคิดนี้สอดคล้องบางส่วนกับความเสี่ยงปฏิสัมพันธ์คนกับ AI ที่ NIST กล่าวถึง แต่ไม่ใช่นิยามมาตรฐานเดียวกัน [4]

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

ประเมินวงความเสียหายและความผิดพลาดร่วมกัน

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

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

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

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

แปลง Risk Appetite เป็นขอบเขตที่ปฏิบัติได้

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

เชื่อม use case กับกระบวนการปิดบัญชี

อย่าเขียนเพียงว่า AI เสี่ยง ควรระบุเหตุ สิ่งที่อาจผิด ผลต่อเป้าหมาย ผู้รับผิดชอบ และกิจกรรมควบคุม เชื่อมทะเบียนการใช้ AI (AI Use-case Register) → ทะเบียนความเสี่ยง (Risk Register) → ตารางความเสี่ยงและการควบคุม (Risk and Control Matrix: RCM) → คู่มืออำนาจอนุมัติ (DOA) → หลักฐานการสอบทาน โดยใช้รหัสอ้างอิงที่เชื่อมโยงกันและไม่ต้องสร้างทะเบียนซ้ำหากระบบเดิมรองรับ

บทบาทความเสี่ยงและความเป็นอิสระ

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

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

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

กรอบอ้างอิงต้องแยกสถานะ

COSO ERM ช่วยเชื่อมความเสี่ยงกับกลยุทธ์ ส่วน COSO Internal Control และแนวทาง GenAI ช่วยออกแบบการควบคุม ไม่ใช่สิ่งเดียวกันและไม่ได้ทำให้การอ้างกรอบเท่ากับการควบคุมมีประสิทธิผล [1–2]

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

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

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

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

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