มาตรการกำกับดูแล AI ในองค์กรอาจสำคัญกว่าการแข่งขันสู่แนวหน้าของ AI

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

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

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

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

PCI DSS ชี้แนวทาง

โชคดีที่เราเคยผ่านสถานการณ์แบบนี้มาแล้ว เมื่อ 20 ปีก่อน ความมั่นคงปลอดภัยของเว็บแอปพลิเคชันอาศัยการตรวจสอบโค้ดเป็นระยะ การสแกนแบบสแตติก และวินัยของนักพัฒนาเป็นหลัก ต่อมา ข้อกำหนด 6.6 ของ PCI DSS ซึ่งประกาศใช้ในปี 2006 และเริ่มบังคับใช้ตั้งแต่ปี 2008 กำหนดให้องค์กรที่จัดการข้อมูลผู้ถือบัตรต้องตรวจสอบโค้ดแอปพลิเคชันทั้งหมดเพื่อหาช่องโหว่ หรือติดตั้งมาตรการควบคุมทางเทคนิคแบบอัตโนมัติ ในเวลาต่อมา ทางเลือกในการตรวจสอบโค้ดถูกยกเลิก และกำหนดให้ต้องใช้มาตรการควบคุมทางเทคนิค

อย่างไรก็ตาม PCI DSS ไม่ได้เริ่มต้นจากการเป็นกฎหมาย แต่เริ่มจากมาตรฐานตามสัญญาที่ปรับเปลี่ยนตลาด ซึ่งน่าจะเกิดขึ้นได้เร็วกว่าการออกกฎหมาย เพราะสัญญาดำเนินการได้เร็วกว่ากฎหมายของรัฐบาล

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

แก้ปัญหาด้านการปฏิบัติงาน แล้วการปฏิบัติตามข้อกำหนดจะตามมา

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

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

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

ย้ายการรักษาความมั่นคงปลอดภัยมาไว้ในเส้นทางการอนุมาน

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

เริ่มต้นอย่างไร

เมื่อพิจารณาทิศทางของกฎระเบียบ องค์กรควรเริ่มดำเนินการสามเรื่องนี้ตั้งแต่ตอนนี้:

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

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