ผู้นำทางความคิด

การกำกับดูแล AI ไม่ใช่ปัญหาของ C-Suite แต่เป็นปัญหาของฐานข้อมูล

mm
เพิ่ม Unite.AI ลงในแหล่งข้อมูลที่คุณต้องการบน Google

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

MIT’ส The GenAI Divide: State of AI in Business 2025 พบว่า 95% ของ AI Pilots ขององค์กรไม่สามารถส่งมอบผลกระทบทางธุรกิจที่วัดได้ มีเพียง 5% ที่เข้าสู่การผลิตและสร้างผลตอบแทนทางการเงินที่แท้จริง การวิจัยนี้รวมถึงการนำ AI ไปใช้มากกว่า 300 ครั้งและการสัมภาษณ์ผู้บริหารมากกว่า 150 ครั้ง และสรุปว่าข้อจำกัดหลักไม่ใช่ความสามารถของแบบจำลอง แต่เป็นการผสมผสานองค์กรที่มีข้อบกพร่อง ส่วนใหญ่ขององค์กรปฏิบัติต่อเรื่องนี้ว่าเป็นปัญหานโยบายที่ต้องแก้ไขที่ระดับผู้บริหาร ฉันจะแย้งว่าการกำกับดูแล AI เป็นความท้าทายของระบบ และเริ่มต้นที่ชั้นข้อมูล

ทำไมโครงการ AI จึงหยุดชะงักในช่วงต้น

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

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

สิ่งนี้ทำให้เกิดช่องว่างที่กว้างขึ้นระหว่างสิ่งที่ระบบ AI สามารถแสดงใน môi trườngที่ควบคุมและอะไรที่องค์กรสามารถนำไปใช้ได้อย่างปลอดภัยและเชื่อถือได้

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

สิ่งนี้ทำให้เกิดความเสี่ยงด้านการปฏิบัติงานและกฎระเบียบที่แท้จริง รวมถึงการเปิดเผยข้อมูลโดยไม่ตั้งใจ ขอบเขตข้อมูลที่ไม่ชัดเจนระหว่างสภาพแวดล้อม และการตรวจสอบระบบที่ไม่เพียงพอ ปัญหาเหล่านี้เกิดขึ้นโดยตรงในการทบทวนการเตรียมการผลิตและการประเมินความสอดคล้องกับกฎระเบียบ การสำรวจขององค์กรแสดงอย่างต่อเนื่องว่า ปัญหาคุณภาพข้อมูลและการกำกับดูแล เป็นสาเหตุหลักของโครงการ AI ที่ล้มเหลว โดยอ้างถึง 60-70% ของกรณี การเพิ่มปัญหานี้คือการเพิ่มขึ้นของการอาศัยโครงสร้างพื้นฐานของบุคคลที่สามและบริการฐานข้อมูลที่จัดการ ซึ่งสามารถทำให้การเป็นเจ้าของข้อมูลแตกกระจายและทำให้การปฏิบัติตามกฎระเบียบซับซ้อนมากขึ้น ในหลายกรณี องค์กรสมมติว่าการกำกับดูแลถูกจัดการโดยแพลตฟอร์มโดยอัตโนมัติ เมื่อในความเป็นจริงความรับผิดชอบถูกกระจายไปทั่วหลายชั้นของสแต็ค

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

ฐานข้อมูลคือชั้นการกำกับดูแลที่แท้จริง

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

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

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

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

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

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

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

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

ใน môi trường AI ความแตกต่างนี้กำหนดว่าระบบสามารถ ขยายขนาดหรือ หยุดชะงัก

เมื่อเอเย่นต์เข้ามาในภาพ

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

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

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

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

จากการทดลองไปสู่ AI ที่พร้อมสำหรับการผลิต

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

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

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

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

ในองค์กรที่มีความเป็นมืออาชีพ ภาระงาน AI ถูกปฏิบัติต่อด้วยความเข้มงวดเหมือนกับระบบที่มีการควบคุมอื่นๆ ซึ่งหมายถึงการบันทึกที่สอดคล้อง การควบคุมการเข้าถึงอย่างเข้มงวด การตรวจสอบอย่างต่อเนื่อง และโครงสร้างความรับผิดชอบที่ชัดเจนระหว่างทีม นอกจากนี้ยังต้องการการเทียบเคียงที่ใกล้ชิดระหว่างการวิศวกรรมข้อมูล การพัฒนาแพลตฟอร์ม ความปลอดภัย และการปฏิบัติตามกฎระเบียบตั้งแต่เนิ่นๆ ไม่ใช่ในภายหลัง

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

การกำกับดูแลคือความจำเป็นทางสถาปัตยกรรม

สุดท้าย การสนทน حولการกำกับดูแล AI ต้องขยายออกไปนอกเหนือจากนโยบายและเข้าสู่สถาปัตยกรรม

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

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

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

ฟิลิป เมอร์ริกคือ Co-Founder และ CPO ที่ pgEdge นักประกอบการ เทคโนโลยี และผู้บริหารที่มีประสบการณ์สูงซึ่งมีประสบการณ์ในการสร้างโครงสร้างพื้นฐานข้อมูลและแพลตฟอร์มคลาวด์ที่ขับเคลื่อนระบบ AI ในปัจจุบัน เขาเป็น Co-Founder และ/หรือ CEO ของ webMethods, EDB, SparkPost, Fugue และ pgEdge และได้นำบริษัทต่างๆ จากการเริ่มต้นจนถึงการเสนอขายหุ้นแก่ประชาชนทั่วไป (IPO) และมีการออกจากบริษัทสามครั้งในระดับ 9-10 ตัวเลข