Oracle เปิด Deep Trust AI Architecture วางสิทธิ์และกฎธุรกิจไว้ใต้ชั้น Agent

Oracle ประกาศ Deep Trust AI Architecture เมื่อ 26 ตุลาคม 2026 ในงาน AI World โดยเสนอ blueprint สำหรับวางความปลอดภัยและกฎธุรกิจไว้ในสี่ชั้น ได้แก่ software platform, data, data access และ application development แทนการพึ่งให้ Agent หรือแอปแต่ละตัวทำการตรวจทั้งหมดอย่างถูกต้องเอง ข่าวนี้เป็นประกาศสถาปัตยกรรมและความสามารถจากผู้ขาย ไม่ใช่ผลรับรองอิสระว่าระบบที่ใช้ AI จะปลอดภัยทุกกรณี

ทำไมจุดบังคับสิทธิ์จึงสำคัญเมื่อมีทางเข้าข้อมูลเพิ่ม

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

ในประกาศ Oracle อธิบาย Deep Data Security สำหรับบังคับสิทธิ์ที่ฐานข้อมูล และ SQL Assertions สำหรับรักษากฎธุรกิจ ส่วน Deep Trust Data APIs ให้เข้าถึง logical business objects แทนการเปิด SQL อิสระ แนวคิดเหล่านี้ชี้ให้เห็นการแยกหน้าที่: โมเดลช่วยตีความงาน ส่วนระบบที่มีอำนาจควรตรวจว่าการกระทำนั้นทำได้จริงก่อนเปลี่ยนข้อมูล

ตัวตนต้องไม่สูญหายระหว่าง Agent กับฐานข้อมูล

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

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

กฎธุรกิจต้องทนต่อการเขียนพร้อมกัน

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

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

คำตอบจาก SQL ต้องมีนิยามทางธุรกิจประกอบ

Oracle ระบุ Deep NL2SQL สำหรับเพิ่มบริบททางธุรกิจและข้อมูล รวมถึงการรับ feedback ที่ผ่านการตรวจสอบก่อนนำกลับใช้ ประเด็นสำหรับองค์กรคือคำว่า “รายได้” หรือ “ลูกค้าที่ใช้งาน” อาจมีนิยามต่างกันตามทีม แม้ SQL รันสำเร็จและไม่มี syntax error ก็ยังให้คำตอบผิดความหมายได้

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

เปลี่ยน Blueprint ให้เป็นหลักฐานที่ตรวจได้

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

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

แหล่งต้นทาง: Oracle Deep Trust AI Architecture announcement ประกาศวันที่ 26 ตุลาคม 2026