ทำไมการกำกับดูแล AI จึงล้มเหลวอย่างต่อเนื่อง

ปัญหาไม่ใช่ว่าองค์กรไม่มีนโยบาย AI แต่นโยบายเหล่านั้นไม่ได้ทำอะไรจริงๆ

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

การแก้ปัญหาไม่ใช่การเพิ่มเอกสาร แต่เป็นการปฏิบัติต่อการกำกับดูแลเหมือนซอฟต์แวร์

ช่องว่างการกำกับดูแลสามารถวัดได้แล้ว

การนำ AI ไปใช้ได้เร่ง速ขึ้นอย่างมาก ในขณะที่โครงสร้างพื้นฐานการกำกับดูแลไม่ได้ตามทัน การศึกษาของ Ernst & Young ในเดือนกันยายน 2025 พบว่าเพียง 10% ของบริษัทพร้อมที่จะตรวจสอบระบบ AI อย่างเต็มที่ ในเวลาเดียวกัน การวิจัยของ Ponemon พบว่า 92% ขององค์กรระบุว่า AI ที่สร้างขึ้นใหม่เปลี่ยนแปลงวิธีการเข้าถึงและแบ่งปันข้อมูลของพนักงาน แต่มีเพียง 18% เท่านั้นที่รวมการกำกับดูแล AI เข้ากับโปรแกรมความเสี่ยงภายใน

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

การกำกับดูแลที่สามารถจัดส่งได้

แนวคิดนี้ง่ายมาก: หากการกำกับดูแลไม่สามารถล้มเหลวในการสร้างได้ ก็ไม่สามารถป้องกันการผลิตได้

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

รูปแบบการดำเนินงานดูเหมือนนี้:

นโยบาย → การควบคุม → หลักฐาน → เมตริก

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

การควบคุมไม่ใช่คำแนะนำ หลักฐานไม่ใช่เอกสาร และหากการควบคุมต้องการความพยายามด้วยมือเพื่อสร้างหลักฐาน มันไม่ใช่การควบคุม มันคือความหวัง

ระดับความเสี่ยง ไม่ใช่การแสดงความเสี่ยง

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

NIST AI Risk Management Framework ที่เผยแพร่ในปี 2023 ให้โครงสร้างพื้นฐานสำหรับการคิดเกี่ยวกับสิ่งนี้ โดยการแมปความเสี่ยงของ AI ข้ามสี่ฟังก์ชัน: จัดการ, แผนที่, วัด, และจัดการ โมเดลการกำกับดูแลขององค์กรที่มีประสิทธิผลสร้างขึ้นจากตรรกะนี้ด้วยระดับความเสี่ยงที่เป็นรูปธรรม:

สิ่งนี้ให้ความชัดเจนแก่ทีมวิศวกรรม ซึ่งเป็นสิ่งที่กระบวนการกำกับดูแลมักไม่ได้ให้: ไม่ใช่ “เราควรทำอะไร?” แต่ “ระดับนี้คืออะไร และสิ่งนั้นจะช่วยให้เราทำอะไร?”
การกำกับดูแลที่ดีจะกำจัดความคลุมเครือ การกำกับดูแลที่ดีจะกำจัดการถกเถียง

นโยบายเป็นโค้ด: จากคำแนะนำไปสู่การบังคับใช้

นโยบายที่เขียนในเอกสารเป็นเพียงคำแนะนำ นโยบายที่เขียนเป็นโค้ดในกระบวนการเป็นไปได้

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

Open Policy Agent — โครงการ Cloud Native Computing Foundation ที่จบการศึกษา — แสดงให้เห็นวิธีการที่กฎสามารถถูกปรับเปลี่ยน พิจารณา และบังคับใช้อย่างสม่ำเสมอในระบบวิศวกรรม โครงร่างนี้เข้าใจแล้ว ช่องว่างคือทีม AI ไม่ได้นำไปใช้

ระบบ AI ที่ปลอดภัยที่สุดไม่ใช่ระบบที่มีนโยบายที่ดีที่สุด แต่เป็นระบบที่ไม่สามารถละเมิดนโยบายได้

การควบคุมเฉพาะ LLM: ที่ที่มันสนุก

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

การกำกับดูแลที่มีประสิทธิผลสำหรับระบบ GenAI ต้องการการควบคุมที่สร้างขึ้นโดยเฉพาะสำหรับการทำงานของ LLM: การแยกความแตกต่างอย่างเข้มงวดระหว่างคำสั่งระบบและอินพุตของผู้ใช้ การเข้าถึงเครื่องมือและการอนุญาต การตรวจสอบเอาต์พุตก่อนการดำเนินการ การป้องกันการขโมยข้อมูล และค่าเริ่มต้นปลอดภัยสำหรับการล้มเหลวอย่างมีเกียรติ

สิ่งเหล่านี้สอดคล้องกับชั้นความเสี่ยงของ OWASP Top 10 สำหรับ LLM Applications – โครงสร้างพื้นฐานที่ขับเคลื่อนด้วยชุมชนซึ่งครอบคลุมผู้เชี่ยวชาญที่มีส่วนร่วมมากกว่า 600 คนจาก 18 ประเทศ การกำกับดูแล LLM นั้นไม่เกี่ยวกับสิ่งที่โมเดลรู้ แต่เกี่ยวกับสิ่งที่ระบบอนุญาตให้ทำ

หลักฐานคือโครงสร้างพื้นฐาน ไม่ใช่เอกสาร

ผู้ตรวจสอบไม่เชื่อใจความตั้งใจ พวกเขเชื่อใจหลักฐาน

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

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

ข้อโต้แย้งที่แท้จริง: การกำกับดูแลเป็นตัวเร่ง

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

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

การกำกับดูแลจะขยายตัวเมื่อมันเป็นโครงสร้างพื้นฐาน มันไม่ขยายตัวเมื่อมันเป็นเพียงความรู้สึก

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