การเปลี่ยนแปลงทางสถาปัตยกรรมที่จำเป็นสำหรับการควบคุมเอเย่นต์ AI

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

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

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

เหตุใดการควบคุมจึงล้มเหลวในยุคแห่งการรวมตัว

สถาปัตยกรรมองค์กรได้เข้าสู่ยุคแห่งการรวมตัว ข้อมูลและกระบวนการทำงานข้ามหลายคลาวด์ เซ็นเตอร์ข้อมูลส่วนตัว และสภาพแวดล้อมขอบ

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

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

นี่คือจุดที่เอเย่นต์เปิดเผยรอยต่อระหว่างระบบ

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

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

จากนโยบายสู่แพลตฟอร์ม

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

• ระนาบควบคุมที่รวมเป็นหนึ่ง

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

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

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

• ผ้าขนหนูข้อมูลที่ยึดหลักมาตรฐานเปิด

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

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

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

• การมองเห็นและติดตามในเวลาจริง

เอเย่นต์สามารถควบคุมได้ก็ต่อเมื่อคุณสามารถมองเห็นอะไรที่พวกเขากำลังทำอยู่ที่ runtime

การมองเห็นใน这里ไม่ใช่แค่ “สิ่งที่ดี” แต่เป็นพื้นฐานสำหรับการควบคุมที่ runtime และการรับมือเหตุการณ์

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

ปฏิบัติต่อเอเย่นต์เหมือน “เพื่อนร่วมงานดิจิทัล”

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

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

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

สิ่งที่เปลี่ยนแปลงในปี 2026: เอเย่นต์ย้ายจากการทดลองสู่การผลิต

2026 คือปีที่การทดลองสิ้นสุดลง และเอเย่นต์เข้าไปอยู่ในตำแหน่งการผลิต

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

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

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

เป้าหมายไม่ใช่การเลือกความเร็ว แต่เป็นการสร้างสถาปัตยกรรมที่รองรับทั้งสองความเร็ว

รายการตรวจสอบเชิงปฏิบัติสำหรับการควบคุมเอเย่นต์ที่ runtime

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

หากคุณไม่สามารถตอบคำถามเหล่านี้ได้ ให้รักษาการติดตั้งเอเย่นต์เหมือนกับเหตุการณ์การผลิตที่รอเกิดขึ้น

การเปลี่ยนแปลงการควบคุมต้องเป็นสถาปัตยกรรม หรือไม่เช่นนั้นจะไม่มีอยู่

เอเย่นต์จะกลายเป็นส่วนเสริมมาตรฐานของการดำเนินงานองค์กร คำถามคือว่าพวกเขาจะกลายเป็นส่วนเสริมที่เชื่อถือได้ของการดำเนินงานองค์กรหรือไม่

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

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

นั่นคือวิธีที่คุณจะได้เอเย่นต์ที่เคลื่อนที่เร็วโดยไม่ทำลายองค์กร