AI กอเวอนานซ์ (AI Governance) ในองค์กร BPO แบบไฮบริด คือโครงสร้างการกำกับดูแลที่ระบุอำนาจการตัดสินใจ ความรับผิดชอบ และช่องทางการตรวจสอบเกี่ยวกับการใช้งาน AI ไว้อย่างชัดเจน ในระบบ BPO ที่พนักงานที่เป็นมนุษย์และ AI ทำงานร่วมกัน

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

คู่มือฉบับนี้จัดทำขึ้นเพื่อผู้ปฏิบัติงานที่กำลังประสบปัญหาความไม่ชัดเจนของขอบเขตความรับผิดชอบดังกล่าว โดยจะอธิบายขั้นตอนการออกแบบการกำกับดูแลใน 3 ระดับ ได้แก่ สัญญา กระบวนการ และองค์กร เป็นลำดับขั้นตอน พร้อมทั้งอ้างอิงกรอบการทำงานที่เป็นมาตรฐานสากลและระดับประเทศ เช่น NIST AI RMF 1.0 และ "แนวทางปฏิบัติสำหรับผู้ประกอบการ AI (ฉบับที่ 1.0)" ของกระทรวงกิจการภายในและการสื่อสาร และกระทรวงเศรษฐกิจ การค้า และอุตสาหกรรมของญี่ปุ่น เพื่อให้แนวทางปฏิบัติที่สามารถนำไปใช้ได้จริงในหน้างานทันที

บทสรุป: เนื่องจาก Hybrid BPO มีการตัดสินใจที่เชื่อมโยงกันระหว่างมนุษย์และ AI ทำให้ขอบเขตความรับผิดชอบในสัญญา BPO แบบเดิมมักจะมีความคลุมเครือ

ใน Hybrid BPO ที่พนักงานที่เป็นมนุษย์และ AI ทำงานร่วมกันในขั้นตอนเดียวกัน จะเกิดความท้าทายด้านธรรมาภิบาลซ้อนทับกันสามประการ ได้แก่ "ช่องว่างแห่งความรับผิดชอบ" (Responsibility Gap) ภายในขั้นตอนการทำงาน, ความเสี่ยงเชิงโครงสร้างที่เกิดจากความสัมพันธ์สามฝ่ายระหว่างผู้ว่าจ้าง ผู้รับจ้าง และผู้ให้บริการ AI และการที่กรอบสัญญาที่มีอยู่เดิมไม่รองรับการใช้งาน AI โดยจะอธิบายรายละเอียดในหัวข้อ H3 ถัดไป

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

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

จุดที่มักเกิดช่องว่างดังกล่าวมีอยู่ 3 ประการ ประการแรกคือ ขอบเขตของการตัดสินใจที่ไม่ชัดเจน เมื่อ AI ให้ "คำแนะนำ" และมนุษย์เป็นผู้ "อนุมัติ" หากไม่มีการกำหนดว่าการกระทำใดคือการตัดสินใจขั้นสุดท้าย ความรับผิดชอบก็จะยังคงลอยเคว้งอยู่ ประการที่สองคือ การแยกส่วนของบันทึกข้อมูล (Log) หากบันทึกการประมวลผลของระบบ AI และบันทึกการตรวจสอบ/อนุมัติของมนุษย์ถูกเก็บไว้ในระบบที่แยกจากกัน การติดตามย้อนหลังจะทำได้ยากอย่างยิ่ง ประการที่สามคือ การซ้ำซ้อนและการตกหล่นของบทบาทหน้าที่ การที่ผู้รับผิดชอบหลายคนต่างคิดว่า "น่าจะมีคนตรวจสอบแล้ว" ทำให้เกิดสภาวะที่ไม่มีใครรับผิดชอบอย่างแท้จริง

NIST AI Risk Management Framework (AI RMF 1.0 ซึ่งเผยแพร่เมื่อวันที่ 26 มกราคม 2023) ได้แนะนำให้มีการกำหนดบทบาทของ "การกำกับดูแลโดยมนุษย์ (Human Oversight)" ให้ชัดเจนในการสร้างความเชื่อมั่นให้กับระบบ AI จากมุมมองนี้ การจัดทำเอกสารระบุ "ขอบเขตที่ AI ตัดสินใจ" และ "ขอบเขตที่มนุษย์ตัดสินใจ" ไว้ตั้งแต่ขั้นตอนการออกแบบขั้นตอนการทำงาน (Workflow) จึงเป็นสิ่งที่ขาดไม่ได้

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

ความเสี่ยงหลักที่เกิดจากความสัมพันธ์ของทั้งสามฝ่ายมีดังนี้:

• การ "โยนความรับผิดชอบ": ในกรณีที่ AI ตัดสินใจผิดพลาด มักเกิดกรณีที่ผู้ว่าจ้างอ้างว่าเป็น "ปัญหาของเครื่องมือ AI ที่ผู้รับจ้างเลือก" ในขณะที่ผู้รับจ้างก็อ้างว่าเป็น "ปัญหาความแม่นยำของโมเดลจาก AI Vendor"
• ความไม่สมมาตรของข้อมูล (Information Asymmetry): AI Vendor มักไม่เปิดเผยข้อมูลจำเพาะภายในของโมเดล ทำให้ผู้รับจ้างมักตกอยู่ในสถานะที่ไม่สามารถอธิบายการทำงานของโมเดลให้ผู้ว่าจ้างเข้าใจได้อย่างเพียงพอ
• ห่วงโซ่สัญญาที่ขาดช่วง: เนื่องจากสัญญาระหว่างผู้ว่าจ้างกับผู้รับจ้าง และสัญญาระหว่างผู้รับจ้างกับ AI Vendor เป็นสัญญาที่แยกจากกัน จึงอาจทำให้กลไกการเรียกร้องค่าเสียหายแบบต่อเนื่องไม่ทำงานเมื่อเกิดเหตุการณ์ไม่พึงประสงค์ (Incident)

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

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

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

「ในสัญญาของเราไม่มีการระบุเรื่อง AI ไว้เลย แบบนี้จะปลอดภัยจริงหรือ」— ในหน้างานของ Hybrid BPO มีหลายกรณีที่การดำเนินงานยังคงดำเนินต่อไปพร้อมกับความกังวลเช่นนี้

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

ปัญหาหลักมีดังนี้:

• การกำหนดขอบเขตงานอ้างอิงจากจำนวนแรงงานคน: สัญญาแบบดั้งเดิมกำหนดขอบเขตงานโดยอิงจาก "จำนวนพนักงานกี่คน และใช้เวลาทำงานกี่ชั่วโมง" ซึ่งไม่สอดคล้องกับความเป็นจริงที่ AI สามารถจัดการปริมาณงานได้อย่างยืดหยุ่น
• มาตรฐานคุณภาพตั้งอยู่บนพื้นฐานพฤติกรรมของมนุษย์: ดัชนีชี้วัดใน SLA (Service Level Agreement) ถูกกำหนดโดยคาดการณ์จากอัตราความผิดพลาดและความเร็วในการตอบสนองของมนุษย์ ทำให้ขาดดัชนีสำหรับวัดการตัดสินใจที่ผิดพลาดของ AI หรือปัญหา Model Drift
• ไม่มีการรองรับการเปลี่ยนแปลงหรืออัปเดตโมเดล: หากผู้ให้บริการ AI ทำการ Silent Update โมเดล ผู้ว่าจ้างอาจไม่ทราบและส่งผลให้คุณภาพของงานเปลี่ยนไป แต่ในสัญญาเดิมไม่ได้ระบุถึงหน้าที่ในการแจ้งเตือนหรือขั้นตอนการอนุมัติไว้
• ความคลุมเครือของขอบเขตการใช้ข้อมูล: ไม่มีข้อกำหนดที่ครอบคลุมกรณีที่ข้อมูลส่วนบุคคลหรือข้อมูลทางธุรกิจถูกนำไปใช้ในการเรียนรู้ของ AI ทำให้ปัญหาที่คณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (PPC) ของญี่ปุ่นได้ออกประกาศเตือนเกี่ยวกับการใช้บริการ Generative AI ในเดือนมิถุนายน 2023 ยังคงเป็นช่องว่างทางสัญญาที่ไม่ได้แก้ไข

หากดำเนินการโดยไม่ได้จัดระเบียบเงื่อนไขเบื้องต้นซึ่งเป็นรากฐานของการออกแบบ จะทำให้เกิดการแก้ไขครั้งใหญ่ในภายหลังได้ง่าย ดังนั้น ให้ตรวจสอบตามลำดับดังนี้: ประการแรกคือระดับการพึ่งพา AI ในแต่ละงาน ประการที่สองคือขอบเขตอำนาจหน้าที่ของผู้มีส่วนได้ส่วนเสีย (Stakeholders) และประการที่สามคือกฎหมายที่เกี่ยวข้อง

การเริ่มต้นออกแบบธรรมาภิบาล (Governance) สิ่งที่ขาดไม่ได้คือการทำให้เห็นภาพชัดเจนว่า "ในแต่ละกระบวนการทำงาน AI มีส่วนร่วมในการตัดสินใจมากน้อยเพียงใด"

ในช่วงแรก เรามักจะคิดว่า "ควรใช้กฎเกณฑ์เดียวกันกับทุกงานที่ใช้ AI" แต่ในความเป็นจริง ระดับการพึ่งพา AI และระดับการมีส่วนร่วมของมนุษย์ในแต่ละงานนั้นแตกต่างกันมาก การใช้ธรรมาภิบาลแบบเหมารวมจึงนำไปสู่ปัญหาการกำกับดูแลที่เข้มงวดเกินไปในบางจุดและหละหลวมในบางจุดพร้อมกัน ดังนั้น การบริหารจัดการแบบแบ่งระดับตามความจำเป็น (Tiered management) จึงมีประสิทธิภาพมากกว่า

แกนหลักของการทำ Mapping

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

• พึ่งพา AI สูง / มนุษย์มีส่วนร่วมน้อย (เช่น การลงบัญชีอัตโนมัติจากใบแจ้งหนี้, การตัดสินคะแนนเครดิต): เนื่องจากความผิดพลาดของ AI จะกลายเป็นผลลัพธ์ของงานโดยตรง จึงจำเป็นต้องมีธรรมาภิบาลที่เข้มงวดที่สุด
• พึ่งพา AI สูง / มนุษย์มีส่วนร่วมสูง (เช่น การที่พนักงานตรวจสอบและส่งข้อความตอบกลับลูกค้าที่ AI ร่างไว้ให้): แม้มนุษย์จะเป็นผู้ตรวจสอบขั้นสุดท้าย แต่หากพึ่งพา AI มากเกินไปอาจทำให้การตรวจสอบกลายเป็นเพียงพิธีกรรม ดังนั้น การวัดอัตราการแก้ไข (Override rate) อย่างสม่ำเสมอจึงเป็นวิธีที่มีประสิทธิภาพ
• พึ่งพา AI ต่ำ / มนุษย์มีส่วนร่วมสูง (เช่น การพิจารณาสินเชื่อที่ AI นำเสนอข้อมูลตัวเลือก แต่มนุษย์เป็นผู้ตัดสินใจ): ปัจจุบันมนุษย์ยังเป็นหลัก แต่เมื่อการใช้ AI พัฒนาขึ้น หมวดหมู่ของงานอาจเปลี่ยนไป จึงจำเป็นต้องมีการประเมินซ้ำอย่างสม่ำเสมอ

ขั้นตอนการทำ Mapping

1. ย่อยกระบวนการทำงานเป้าหมายออกเป็น "ขั้นตอนการตัดสินใจ" (Judgment steps)
2. ระบุสิ่งที่ AI ส่งออกมาในแต่ละขั้นตอน (เช่น การจำแนกประเภท, คะแนน, ข้อความ ฯลฯ)
3. บันทึกว่ามนุษย์ตรวจสอบหรือแก้ไขผลลัพธ์เหล่านั้นมากน้อยเพียงใด โดยแบ่งเป็น "ตรวจสอบตลอดเวลา / สุ่มตรวจ / ไม่มีการตรวจสอบ"

อุปสรรคแรกในการออกแบบธรรมาภิบาล (Governance) คือการเริ่มต้นโดยที่ยังนิยามไม่ชัดเจนว่า "ใครคือผู้มีส่วนได้ส่วนเสีย" ใน Hybrid BPO นั้นมีผู้มีส่วนได้ส่วนเสียที่ครอบคลุมหลายองค์กร ไม่เพียงแค่เจ้าของกระบวนการทำงาน (Business Owner) ภายในบริษัทเท่านั้น แต่ยังรวมถึงผู้ให้บริการ BPO, ผู้จำหน่าย AI (AI Vendor), ฝ่ายกฎหมาย และฝ่ายความปลอดภัยของข้อมูลอีกด้วย

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

เมื่อระบุผู้มีส่วนได้ส่วนเสียครบถ้วนแล้ว ขั้นตอนต่อไปคือการตรวจสอบ "อำนาจการกำกับดูแล" (Governance Authority) ของแต่ละฝ่าย โดยสามารถแบ่งประเภทอำนาจออกเป็น 3 ประเภทหลัก ได้แก่ อำนาจการตัดสินใจ (Decision-making authority) ในการอนุมัติ หยุด หรือเปลี่ยนแปลงการใช้งาน AI, อำนาจการตรวจสอบ (Monitoring authority) ในการดูและประเมินบันทึก (Log) หรือตัวชี้วัดประสิทธิภาพ และหน้าที่ในการรายงาน (Reporting obligation) เมื่อเกิดเหตุการณ์ผิดปกติหรืออุบัติการณ์ต่อผู้บังคับบัญชา

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

"กฎหมายฉบับใดบ้างที่ใช้บังคับกับงาน BPO ของบริษัทเรา" เป็นคำถามที่มักได้ยินบ่อยครั้งจากผู้ปฏิบัติงานหน้างาน การหาคำตอบสำหรับคำถามนี้ให้ได้ก่อนเริ่มออกแบบธรรมาภิบาล (Governance) ถือเป็นสิ่งที่จำเป็นอย่างยิ่ง

กฎหมาย กฎระเบียบ และมาตรฐานอุตสาหกรรมหลักที่ควรตรวจสอบ สามารถแบ่งออกได้เป็น 3 ระดับ ดังนี้:

มาตรฐานสากลและระดับโลก

• NIST AI RMF 1.0 (ประกาศเมื่อ 26 มกราคม 2023): กรอบการทำงานที่เป็นระบบสำหรับการระบุ ประเมิน และรับมือกับความเสี่ยงด้าน AI สามารถใช้เป็นมาตรฐานการบริหารจัดการความเสี่ยงเมื่อมีการนำ AI มาใช้ในงาน BPO
• ISO/IEC 42001:2023 (ออกเมื่อเดือนธันวาคม 2023): มาตรฐานสากลสำหรับระบบการจัดการ AI (AI Management System)

บทสรุป: หัวใจสำคัญของการออกแบบคือการแบ่งแยกการตัดสินใจระหว่าง AI และมนุษย์ในระดับกระบวนการทำงาน และระบุบทบาทของทั้งสามฝ่ายให้ชัดเจนด้วยตาราง RACI

การออกแบบเมทริกซ์เพื่อแสดงความรับผิดชอบให้เห็นภาพชัดเจนถือเป็นจุดเริ่มต้นของการกำกับดูแล (Governance) โดยดำเนินการผ่าน 3 ขั้นตอน ได้แก่ การแบ่งบทบาทหน้าที่ในระดับงาน, การกำหนดความรับผิดชอบด้วยตาราง RACI และการระบุเส้นทางการยกระดับปัญหา (Escalation path) ให้เป็นลายลักษณ์อักษร

ในการออกแบบการแบ่งบทบาทหน้าที่ หลายคนมักคิดในตอนแรกว่า "ควรให้ AI จัดการทุกขั้นตอนที่สามารถทำได้โดยอัตโนมัติ" แต่ในความเป็นจริงแล้ว การย่อยกระบวนการทำงานออกเป็นส่วนย่อยๆ และระบุขอบเขตความรับผิดชอบระหว่าง AI กับมนุษย์ให้ชัดเจนตามประเภทของการตัดสินใจ จะช่วยให้การติดตามความรับผิดชอบเมื่อเกิดเหตุการณ์ไม่คาดคิด (Incident) ทำได้ง่ายกว่ามาก

ขั้นแรก ให้แบ่งงานที่เกี่ยวข้องออกเป็นหน่วยกระบวนการ (เช่น การป้อนข้อมูล → การตรวจสอบความถูกต้อง → การอนุมัติ → การส่งออกข้อมูล) จากนั้นให้กำหนดประเภทการตัดสินใจ 3 รูปแบบสำหรับแต่ละขั้นตอน ดังนี้:

• AI ตัดสินใจโดยลำพัง (Human-out-of-the-loop): ขั้นตอนที่มีกฎเกณฑ์ชัดเจนและผลกระทบจากการตัดสินใจผิดพลาดมีน้อย เช่น การตรวจสอบข้อมูลตามรูปแบบมาตรฐาน หรือการตรวจสอบความถูกต้องของข้อมูล
• AI ช่วยเหลือและมนุษย์ตัดสินใจ (Human-in-the-loop): ขั้นตอนที่ AI ทำหน้าที่ให้คะแนนหรือเสนอทางเลือก โดยมีผู้รับผิดชอบเป็นผู้ตัดสินใจขั้นสุดท้าย (เช่น การคัดกรองเบื้องต้นในการพิจารณาสินเชื่อ)
• มนุษย์ตัดสินใจโดยลำพัง (Human-only): ขั้นตอนที่มีผลกระทบสูงหากเกิดการตัดสินใจผิดพลาด เช่น การอนุมัติที่มีผลทางกฎหมาย หรือการแจ้งเตือนเรื่องสำคัญแก่ลูกค้า

สิ่งสำคัญคือต้องจัดทำเอกสารการแบ่งประเภทนี้ในรูปแบบเมทริกซ์ "กระบวนการทำงาน × ประเภทการตัดสินใจ" หากพึ่งพาเพียงการตกลงด้วยวาจาหรือความเคยชิน จะทำให้เกิด "ปัญหาตรายาง" (Rubber-stamping) ซึ่งเป็นกรณีที่มนุษย์ยอมรับผลลัพธ์จาก AI โดยปราศจากการตรวจสอบได้ง่าย

ตาราง RACI เป็นเครื่องมือที่ใช้สรุปว่า "ใครรับผิดชอบอะไร" แต่ในรูปแบบ Hybrid BPO นั้นมีผู้เกี่ยวข้องถึงสามฝ่าย ได้แก่ ผู้ว่าจ้าง ผู้รับจ้าง และผู้ให้บริการ AI ดังนั้นหากนำ RACI ที่ใช้สำหรับสัญญาแบบสองฝ่ายทั่วไปมาปรับใช้โดยตรง มักจะเกิดการเกี่ยงความรับผิดชอบเมื่อเกิดเหตุการณ์ไม่คาดคิดว่า "นั่นอยู่นอกเหนือขอบเขตความรับผิดชอบของเรา" ด้วยเหตุนี้ จึงจำเป็นต้องออกแบบทั้งแถว (งาน) และคอลัมน์ (ผู้รับผิดชอบ) ใหม่ให้สอดคล้องกับโครงสร้างสามฝ่าย

เมื่อจัดระเบียบวิธีการกำหนดบทบาทแต่ละส่วนแล้ว สำหรับ R (Responsible - ผู้รับผิดชอบการปฏิบัติงาน) ในงานที่ AI ประมวลผลอัตโนมัติ ผู้รับจ้างที่เป็นโอเปอเรเตอร์จะเป็นผู้รับผิดชอบ ส่วนผู้ให้บริการ AI จะจำกัดความรับผิดชอบไว้เพียงการรับประกันการทำงานของโมเดลเท่านั้น สำหรับ A (Accountable - ผู้รับผิดชอบผลลัพธ์) โดยหลักการแล้วผู้ว่าจ้างจะเป็นผู้ถือความรับผิดชอบสูงสุดต่อผลลัพธ์ของงาน และจะเป็นผู้รับหน้าในกรณีที่มีการร้องเรียนจากภายนอกหรือมีหน้าที่ต้องรายงานต่อหน่วยงานกำกับดูแล สำหรับ C (Consulted - ผู้ที่ต้องปรึกษา) คือการดึงทั้งผู้ว่าจ้างและผู้รับจ้างเข้ามามีส่วนร่วมเมื่อมีการเปลี่ยนแปลงหรือปรับจูนโมเดล AI เพื่อป้องกันการเปลี่ยนแปลงข้อกำหนดโดยพลการจากฝ่ายใดฝ่ายหนึ่ง สำหรับ I (Informed - ผู้ที่ต้องได้รับแจ้ง) คือการกำหนดให้ต้องแจ้งผู้ให้บริการ AI ทราบเมื่อเกิดเหตุการณ์ไม่คาดคิด และให้มีส่วนร่วมในการพิจารณามาตรการป้องกันการเกิดซ้ำ

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

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

แม้จะมีการกำหนดบทบาทด้วยตารางความรับผิดชอบ (RACI Matrix) แล้ว แต่หากเส้นทางการติดต่อสื่อสารเมื่อเกิดเหตุการณ์ผิดปกติยังคงคลุมเครือ ก็มีความเสี่ยงที่การตอบสนองจะล่าช้าและส่งผลให้ความเสียหายขยายวงกว้างขึ้น ดังนั้น การจัดทำเอกสารระบุเส้นทางการยกระดับปัญหา (Escalation Path) และผู้มีอำนาจตัดสินใจขั้นสุดท้ายไว้ล่วงหน้า จึงถือเป็น "สองเสาหลักของการออกแบบธรรมาภิบาล" ควบคู่ไปกับตาราง RACI

ประเด็นสำคัญในการออกแบบเส้นทางการยกระดับปัญหา (Escalation Path) มีดังนี้:

• การกำหนดเงื่อนไขตัวกระตุ้น (Trigger Conditions): ระบุเงื่อนไขที่ต้องเริ่มกระบวนการยกระดับปัญหาให้ชัดเจนด้วยตัวเลขหรือสถานะ เช่น กรณีคะแนนความเชื่อมั่น (Confidence Score) ของ AI ต่ำกว่าเกณฑ์ หรือกรณีจำนวนรายการประมวลผลเปลี่ยนแปลงอย่างกะทันหัน
• ระดับการยกระดับปัญหาแบบเป็นขั้นเป็นตอน: กำหนดระดับตามความรุนแรง เช่น "พนักงานหน้างาน → หัวหน้างานของผู้รับจ้าง → ผู้รับผิดชอบงานของผู้ว่าจ้าง → ระดับบริหาร"
• การกำหนดกรอบเวลา (Time-box): ระบุระยะเวลาในการตอบสนองของแต่ละระดับให้ชัดเจน (เช่น การยกระดับขั้นที่ 1 ต้องทำภายใน 30 นาทีหลังจากตรวจพบ) พร้อมทั้งกำหนดกฎการเลื่อนระดับอัตโนมัติหากเกินกำหนดเวลา
• ช่วงเวลาการมีส่วนร่วมของผู้ให้บริการ AI (AI Vendor): ระบุช่วงเวลาที่จะเรียกตัวผู้ให้บริการในกรณีที่สงสัยว่าเกิดจากความบกพร่องของตัวโมเดลเอง รวมถึงระบุผู้รับผิดชอบหลักให้สอดคล้องกับสัญญา

สำหรับการระบุผู้มีอำนาจตัดสินใจขั้นสุดท้าย จำเป็นต้องกำหนดให้ชัดเจนในแต่ละหมวดหมู่งานว่า ระหว่างผู้ว่าจ้างกับผู้รับจ้าง ฝ่ายใดเป็น "ผู้มีอำนาจตัดสินใจขั้นสุดท้าย (Go/No-Go)"

ไม่ว่าการออกแบบจุดแบ่งความรับผิดชอบ (Responsibility Boundary) จะมีความละเอียดรอบคอบเพียงใด หากไม่ได้ระบุไว้ในสัญญา ก็จะไม่เกิดผลผูกพันทางกฎหมาย องค์กรที่ดำเนินงานโดยอาศัยเพียงข้อตกลงด้วยวาจาหรือเอกสารภายใน มักจะประสบปัญหาการโต้เถียงกันไปมาว่า "ใครจะเป็นผู้รับผิดชอบค่าเสียหาย" เมื่อเกิดเหตุการณ์ AI Incident ขึ้น

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

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

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

สิ่งที่ควรระบุไว้ในสัญญาในฐานะภาระหน้าที่ในการแจ้งเตือน มีดังนี้:

• ประเภทของการเปลี่ยนแปลง: จำแนกประเภทเป็น ไมเนอร์แพตช์ (แก้ไขบั๊ก) / ไมเนอร์เวอร์ชัน (ปรับปรุงประสิทธิภาพ) / เมเจอร์เวอร์ชัน (เปลี่ยนแปลงสถาปัตยกรรม) และกำหนดระยะเวลาแจ้งเตือนล่วงหน้า (Lead time) สำหรับแต่ละประเภท
• ผู้รับแจ้งและวิธีการ: กำหนดให้ผู้รับผิดชอบงานและผู้รับผิดชอบด้านความปลอดภัยของผู้ว่าจ้างเป็นผู้รับแจ้ง โดยยึดหลักการแจ้งเตือนผ่านอีเมลควบคู่กับการเปิดทิกเก็ต (Ticket)
• เนื้อหาการแจ้งเตือน: กำหนดให้สรุปภาพรวมของการเปลี่ยนแปลง, ขอบเขตผลกระทบ, ความเป็นไปได้ในการย้อนกลับ (Rollback) และสรุปผลการทดสอบ เป็นรายการที่ต้องระบุให้ครบถ้วน

ประเด็นสำคัญในการออกแบบขั้นตอนการอนุมัติ มีดังนี้:

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

แม้แต่ในฟังก์ชัน "การกำกับดูแล (GOVERN)" ที่ระบุไว้ใน NIST AI RMF 1.0 ก็ยังแนะนำให้รวมการจัดการการเปลี่ยนแปลงของระบบ AI เข้าไว้ในกระบวนการตรวจสอบอย่างต่อเนื่องด้วยเช่นกัน

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

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

「ข้อมูลที่ส่งมอบให้ผู้ให้บริการ BPO ได้ถูกนำไปใช้ในการเรียนรู้ของ AI หรือไม่ คุณสามารถยืนยันเรื่องนี้ได้หรือไม่」— มีผู้รับผิดชอบจำนวนไม่น้อยที่ไม่สามารถตอบคำถามนี้ได้ทันที

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

• ความเป็นเจ้าของข้อมูล: ระบุให้ชัดเจนว่าความเป็นเจ้าของข้อมูลทางธุรกิจ ข้อมูลส่วนบุคคล และบันทึกการทำธุรกรรมที่ผู้ว่าจ้างจัดหาให้ ยังคงเป็นของผู้ว่าจ้าง
• การห้ามหรือเงื่อนไขการใช้ข้อมูลเพื่อการเรียนรู้: หากผู้ให้บริการ AI จะใช้ข้อมูลของผู้ว่าจ้างในการเรียนรู้ใหม่ (Re-learning) หรือการปรับจูนโมเดล (Fine-tuning) จะต้องได้รับความยินยอมเป็นลายลักษณ์อักษรล่วงหน้าเท่านั้น
• การจำกัดการให้ข้อมูลแก่บุคคลที่สาม: ห้ามมิให้ผู้รับจ้างหรือผู้ให้บริการ AI ให้หรือแบ่งปันข้อมูลที่ได้รับแก่บุคคลที่สาม ซึ่งรวมถึงบริษัทในเครือและผู้รับช่วงต่อ (Subcontractor) โดยหลักการ และให้ระบุข้อยกเว้นไว้ให้ชัดเจน

คณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (Personal Information Protection Commission) ได้ระบุในเอกสาร "ข้อควรระวังเกี่ยวกับการใช้บริการ Generative AI" ที่เผยแพร่เมื่อวันที่ 2 มิถุนายน 2023 ถึงความเป็นไปได้ที่การป้อนข้อมูลส่วนบุคคลเข้าสู่บริการ Generative AI จะเข้าข่ายข้อบังคับเรื่องการให้ข้อมูลแก่บุคคลที่สาม ในสัญญา BPO จึงจำเป็นต้องใช้สัญญาเพื่อปิดความเสี่ยงในการรั่วไหลของข้อมูลผ่านทางผู้รับจ้างจากมุมมองนี้ด้วย

นอกจากนี้ Regulation (EU) 2024/1689 (AI Act) ยังกำหนดข้อกำหนดด้านธรรมาภิบาลข้อมูล (Data Governance) สำหรับระบบ AI ที่มีความเสี่ยงสูง ดังนั้นหากมีแผนขยายธุรกิจไปทั่วโลก จำเป็นต้องตรวจสอบความสอดคล้องไม่เพียงแต่กับกฎระเบียบภายในประเทศเท่านั้น แต่รวมถึงกฎระเบียบในต่างประเทศด้วย

นอกเหนือจากสัญญาแล้ว การแนบแผนผังการไหลของข้อมูล (Data Flow Diagram) (ข้อมูลใดผ่านระบบใดบ้าง) เป็นเอกสารแนบท้าย จะช่วยทำหน้าที่เป็นหลักฐานสำหรับการตรวจสอบ (Audit) ได้อีกด้วย

แม้จะจัดทำสัญญาและแต่งตั้งผู้รับผิดชอบในผังองค์กรแล้ว แต่เพียงแค่นั้นก็ยังไม่เพียงพอที่จะทำให้หน้างานขับเคลื่อนไปได้ เมื่อผู้เขียนได้เข้าร่วมการทบทวนการดำเนินงาน (Operation Review) ของโครงการ BPO มักพบสถานการณ์ที่ว่า "มีการเก็บ Log ไว้แต่ไม่มีใครดู" หรือ "มีการจัดอบรมเพียงครั้งเดียวตอนเริ่มงาน" อยู่บ่อยครั้ง สิ่งที่สำคัญหลังจากจบขั้นตอนการออกแบบคือ การทำให้ระบบธรรมาภิบาล (Governance) กลายเป็นส่วนหนึ่งของจังหวะการทำงานประจำวัน ต่อไปนี้จะขออธิบายวิธีการนำมาตรการทั้ง 3 ประการ ได้แก่ การจัดเก็บ Log, การทบทวนโมเดล (Model Review) และการจัดอบรม เข้าไปรวมอยู่ในกระบวนการปฏิบัติงานตามลำดับ

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

รายการขั้นต่ำที่ควรบันทึก มีดังนี้:

• ข้อมูลนำเข้า (Input Data): เนื้อหาคำขอที่ส่งให้ AI (ข้อมูลส่วนบุคคลต้องผ่านการทำ Masking แล้ว)
• ผลลัพธ์ (Output Result): การตัดสินใจ ค่าแนะนำ หรือคะแนนที่ AI ส่งกลับมา
• ข้อมูลประกอบเหตุผลในการตัดสินใจ: ชื่อโมเดลที่ใช้ เวอร์ชัน เวลาที่ประมวลผล และคะแนนความเชื่อมั่น (Confidence Score)
• บันทึกการแทรกแซงโดยมนุษย์: การมีอยู่ของการ Override, ID ของผู้แทรกแซง, เนื้อหาที่แก้ไข และเหตุผลในการแก้ไข
• การดำเนินการขั้นสุดท้าย: เนื้อหาที่นำไปใช้ในระบบงานและผู้รับผิดชอบ

ประเด็นสำคัญในการออกแบบการจัดเก็บล็อก มี 3 ข้อดังนี้:

• การป้องกันการแก้ไข (Tamper Prevention): จัดเก็บล็อกไว้ในพื้นที่จัดเก็บแบบเขียนได้อย่างเดียว (Write-only storage) หรือจัดเก็บพร้อมค่า Hash เพื่อให้สามารถตรวจพบการแก้ไขย้อนหลังได้
• การระบุระยะเวลาจัดเก็บให้ชัดเจน: ระบุจำนวนปีที่จัดเก็บไว้ในสัญญาจ้างให้ชัดเจน และให้สอดคล้องกับภาระหน้าที่ในการเก็บรักษาบันทึกตามกฎหมาย (เช่น ระยะเวลาการจัดการตามกฎหมายคุ้มครองข้อมูลส่วนบุคคล)
• การแยกสิทธิ์การเข้าถึง: แยกสิทธิ์การดูล็อกระหว่างผู้ปฏิบัติงาน ผู้ตรวจสอบภายใน และผู้ว่าจ้างออกจากกัน และต้องบันทึกด้วยว่าใครเป็นผู้เข้าดูและดูเมื่อใด

ทั้งนี้ ใน "แนวทางปฏิบัติสำหรับผู้ประกอบการ AI (ฉบับที่ 1.0)" (เผยแพร่เมื่อเดือนเมษายน 2024) ของกระทรวงกิจการภายในและการสื่อสาร และกระทรวงเศรษฐกิจ การค้า และอุตสาหกรรม ประเทศญี่ปุ่น ก็ได้แนะนำให้มีการเก็บรักษาบันทึกการใช้งานระบบ AI และรับรองความสามารถในการตรวจสอบย้อนกลับ (Traceability) ไว้ด้วยเช่นกัน

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

รอบพื้นฐานของการทบทวนประสิทธิภาพโมเดล

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

ตัวอย่างตัวชี้วัดที่ควรตรวจสอบในระหว่างการทบทวน มีดังนี้

• ความแม่นยำ (Accuracy), ความเที่ยงตรง (Precision), และความครอบคลุม (Recall): หากส่วนต่างจากการทบทวนครั้งก่อนเกินค่าเกณฑ์ที่กำหนด ให้ดำเนินการ Escalation ทันที
• อัตราการ Override โดยมนุษย์: หากสัดส่วนที่ผู้รับผิดชอบพลิกกลับการตัดสินใจของ AI เพิ่มขึ้นอย่างรวดเร็ว ให้ถือเป็นสัญญาณในการประเมินโมเดลใหม่
• การเปลี่ยนแปลงในการจำแนกประเภทข้อผิดพลาด: หากรูปแบบการตัดสินใจผิดพลาดเริ่มกระจุกตัวอยู่ในหมวดหมู่ใดหมวดหมู่หนึ่ง ให้สงสัยว่าข้อมูลที่ใช้ฝึกอาจมีความลำเอียง

การออกแบบขั้นตอนการ Override โดยมนุษย์

สิ่งสำคัญคือการกำหนดให้ Override ไม่ใช่ "การกระทำที่ปฏิเสธการตัดสินใจของ AI" แต่เป็นการทำงานปกติของ Governance โครงสร้างหลักของขั้นตอนมีดังนี้

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

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

ในการออกแบบการฝึกอบรม การยึดหลักสามประการต่อไปนี้จะช่วยเพิ่มประสิทธิผลได้:

• หลักสูตรแบ่งตามบทบาท: เรียนรู้ผ่านสถานการณ์จำลองที่เฉพาะเจาะจงสำหรับแต่ละบทบาท เช่น ผู้อนุมัติ, ผู้ปฏิบัติงาน, และผู้ตรวจสอบคุณภาพ เพื่อให้เข้าใจว่า 「ตนเองต้องตัดสินใจตรงจุดไหน และต้องรายงานเรื่องใดขึ้นไป (Escalation)」
• การแบ่งปันกรณีศึกษาจากเหตุการณ์จริง: นำตัวอย่างความคลาดเคลื่อนในการตัดสินใจของ AI หรือการประมวลผลที่ผิดพลาดที่เคยเกิดขึ้นจริงมาทำเป็นสื่อการสอนโดยปกปิดข้อมูลส่วนบุคคล เพื่อให้ตระหนักว่า 「เป็นสิ่งที่สามารถเกิดขึ้นได้」
• การฝึกอบรมซ้ำอย่างสม่ำเสมอ: ทบทวนเนื้อหาอย่างน้อยทุกครึ่งปีเพื่อให้สอดคล้องกับการอัปเดตโมเดล AI หรือการเปลี่ยนแปลงกระบวนการทำงาน

สำหรับการสร้างวัฒนธรรมการรายงานผล การรักษาความปลอดภัยทางจิตวิทยา (Psychological Safety) เป็นสิ่งที่ขาดไม่ได้ หากปราศจากสภาพแวดล้อมที่เอื้อให้พนักงานกล้ารายงานเมื่อ 「รู้สึกว่าการตัดสินใจของ AI ผิดปกติ」 ปัญหาก็จะยังคงถูกซ่อนอยู่ใต้ผิวน้ำต่อไป โดยมาตรการต่อไปนี้ถือว่ามีประสิทธิภาพ:

บทสรุป: ความล้มเหลวที่มักเกิดขึ้นในการออกแบบ AI Governance สามารถสรุปได้เป็นสองประเด็นหลัก คือ สภาวะที่ "ไม่มีใครรับผิดชอบ" และการที่เอกสารด้านธรรมาภิบาลกลายเป็นเพียง "รูปแบบที่ไร้ผล"

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

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

ขั้นตอนที่มีประสิทธิภาพในการป้องกันสถานการณ์นี้มีดังนี้:

• แต่งตั้ง "เจ้าของ" (Owner) การตัดสินใจของ AI ในแต่ละหน่วยงาน: ระบุตัวบุคคลที่จะเป็น "ผู้ให้การอนุมัติขั้นสุดท้ายต่อผลลัพธ์ของ AI" ในแต่ละกระบวนการทำงาน และระบุไว้ในตาราง RACI ให้ชัดเจน โดยต้องรับประกันผ่านทั้งสัญญาและกฎระเบียบภายในว่า แม้จะเป็นผลลัพธ์ที่ AI ตัดสินใจ แต่ผู้อนุมัติจะต้องเป็นผู้รับผิดชอบ
• จำกัดขอบเขตการใช้ผลลัพธ์ของ AI ไว้ล่วงหน้า: ใช้การแยกสีในผังกระบวนการทำงาน (Workflow) เพื่อระบุว่า "สถานการณ์ใดที่ใช้การตัดสินใจของ AI เป็นการตัดสินใจขั้นสุดท้าย" และ "สถานการณ์ใดที่ใช้เป็นเพียงข้อมูลอ้างอิง" โดยในขั้นตอนการตัดสินใจขั้นสุดท้ายจะต้องมีขั้นตอนการลงนามอนุมัติโดยมนุษย์เสมอ
• กำหนดให้คำพูดที่ว่า "AI เป็นคนตัดสิน" เป็นหัวข้อในการบันทึกและรายงาน: เพิ่มช่อง "ระดับการพึ่งพา AI" (AI Dependency) ลงในรูปแบบรายงาน เพื่อให้มีการแชร์กรณีที่ปล่อยให้ AI ตัดสินใจแทนทั้งหมดในการรายงานผลการปฏิบัติงานประจำวันหรือการทบทวนงาน การทำให้เห็นภาพชัดเจนขึ้นมักจะช่วยเปลี่ยนทัศนคติของคนในหน้างานได้
• ระบุตัวจุดชนวนความรับผิดชอบเมื่อเกิดเหตุการณ์ในสัญญาให้ชัดเจน: กำหนดไว้ใน SLA ว่าเมื่อเกิดความเสียหายจาก AI "ใครมีหน้าที่แจ้งเตือนเป็นลำดับแรก" และ "จุดเริ่มต้นของการประเมินความเสียหายอยู่ที่ใด"

แนวทางสำหรับผู้ประกอบการ AI ของกระทรวงกิจการภายในและการสื่อสาร และกระทรวงเศรษฐกิจ การค้า และอุตสาหกรรม (ฉบับที่ 1.

สถานการณ์ที่เอกสารธรรมาภิบาล (Governance document) กลายเป็นเพียง "เอกสารที่มีไว้ให้ครบ" มักเกิดขึ้นในช่วง 6 เดือนถึง 1 ปีหลังจากเริ่มนำมาใช้ ยิ่งรู้ตัวช้าว่าเอกสารเหล่านั้นกลายเป็นเพียงเปลือกนอก ต้นทุนในการแก้ไขก็จะยิ่งสูงขึ้น ดังนั้น การสร้างนิสัยในการสังเกตสัญญาณเตือนระหว่างการปฏิบัติงานประจำวันจึงเป็นเรื่องสำคัญ

สัญญาณเตือนที่พบบ่อยคือ เมื่อเกิดเหตุการณ์ไม่คาดคิด (Incident) แล้วผู้รับผิดชอบแต่ละคนกลับอ้างอิงเอกสารคนละฉบับ นอกจากนี้ ควรระวังกรณีที่ตารางแบ่งขอบเขตความรับผิดชอบ (Responsibility Matrix) ไม่ได้รับการอัปเดตมานานกว่าครึ่งปี หรือรายงานการประชุมทบทวนประจำที่มีการบันทึกว่า "ไม่มีการเปลี่ยนแปลงจากครั้งก่อน" ติดต่อกันหลายครั้ง แต่กรณีที่ร้ายแรงที่สุดคือการที่พนักงานหน้างานไม่ทราบถึงการมีอยู่ของเอกสารธรรมาภิบาล หรือไม่เคยเปิดอ่านเลยแม้แต่ครั้งเดียว

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

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