Erik Meijer ชวนมองเส้นแบ่งระหว่าง AI ที่ให้คำตอบกับ AI Agent ที่มีสิทธิ์ลงมือทำ คำตอบที่ดูปลอดภัยไม่ได้ยืนยันว่าการกระทำระหว่างสร้างคำตอบนั้นปลอดภัยด้วย โดยเฉพาะเมื่อเครื่องมือที่เรียกใช้สามารถแก้ข้อมูลหรือลบไฟล์ได้
ในคลิปจากช่อง AI Engineer เขาเสนอให้เปลี่ยนจากการเชื่อเจตนาของ agent ไปสู่การตรวจแผนและหลักฐานก่อนเกิดผลกระทบต่อระบบจริง เขาระบุว่างานนี้เป็นบทสอนแนวคิดจากระบบชนิดข้อมูลและคอมไพเลอร์ ไม่ใช่การประกาศผลิตภัณฑ์
แนวคิด formal verification หรือการตรวจคุณสมบัติด้วยวิธีพิสูจน์เชิงรูปแบบ อาจฟังเป็นเรื่องของนักพัฒนา แต่คำถามหลักตามที่เขาเสนอคือ จะทำให้แผนของ agent ตรวจได้ก่อนลงมืออย่างไร และเราต้องกำหนดคุณสมบัติใดให้ชัดก่อนจะเรียกว่าปลอดภัย
แยก AI ที่ให้คำตอบออกจาก AI ที่มีสิทธิ์ลงมือทำ
ในแบบจำลองที่ Meijer ใช้อธิบาย AI แบบให้คำตอบรับคำถามแล้วส่งคำตอบกลับมา การลงมือทำตามคำตอบยังอยู่ที่คน เขาใช้ภาพนี้เป็นจุดตั้งต้นเพื่อเปรียบเทียบกับระบบที่เรียกเครื่องมือเองได้
เมื่อเพิ่ม tool calls หรือการเรียกเครื่องมือ agent สามารถสร้างผลกระทบต่อข้อมูลและระบบภายนอกระหว่างทำงานได้ ขอบเขตผลกระทบขึ้นอยู่กับเครื่องมือและสิทธิ์ที่ระบบเปิดให้
เขาชี้ว่าการเพิ่ม IO ซึ่งแทนการคำนวณที่มีผลต่อโลกภายนอกในตัวอย่างภาษา Lean ทำให้การสร้างคำตอบอาจมีผลข้างเคียง เช่น ลบไฟล์ไปแล้วก่อนส่งคำตอบที่ดูปลอดภัยกลับมา นี่เป็นตัวอย่างความเสี่ยงที่เขายก ไม่ใช่ผลทดสอบของ agent ทุกระบบ
หากใช้แนวคิดนี้มองงานธุรกิจ ตัวอย่างต่อไปนี้เป็นรายการสิทธิ์สมมติของ VibeSolo เพื่อช่วยตั้งคำถามเรื่องผลกระทบ ไม่ใช่ระบบที่ผู้พูดนำมาแสดงหรือกรณีความเสียหายที่ยืนยันแล้ว
- คืนเงิน ออกคูปอง หรือเปลี่ยนราคาโดยไม่มีวงเงินกำกับ
- ส่งอีเมลหรือข้อความถึงลูกค้าจำนวนมาก
- แก้ไขข้อมูลลูกค้า สต๊อก หรือรายการบัญชี
- เข้าถึงไฟล์สัญญา เงินเดือน หรือข้อมูลส่วนบุคคล
- เชื่อมต่อระบบชำระเงินและทำรายการแทนทีมงาน
ข้อคิดจาก VibeSolo คือให้พิจารณาทั้งความสามารถและสิทธิ์ที่เปิดให้ agent ความสามารถในการให้เหตุผลไม่ได้ยืนยันเองว่าทุกการกระทำที่เครื่องมืออนุญาตจะตรงกับกติกาของเรา
เข้าใจว่าทำไม prompt injection จึงอันตรายเมื่อ Agent มี tools
Meijer กล่าวถึง prompt injection หรือข้อความจากแหล่งข้อมูลที่พยายามชักจูงให้โมเดลเปลี่ยนคำสั่ง เขามองว่าปัญหาอยู่ที่การนำคำสั่งและข้อมูลมาปะปนกัน และความเสี่ยงจะมีผลต่อระบบจริงเมื่อ agent เรียกเครื่องมือได้
ในคำอธิบายของเขา ความเสี่ยงที่ต้องดูร่วมกันมีทั้งข้อมูลส่วนตัว เนื้อหาที่ไม่น่าเชื่อถือ และเครื่องมือที่ทำงานได้จริง
เขาเรียกชุดความเสี่ยงนี้ว่า lethal trifecta ซึ่งหมายถึงองค์ประกอบอันตรายสามอย่างที่อยู่ร่วมกัน ได้แก่ ข้อมูลส่วนตัว เนื้อหาที่ไม่น่าเชื่อถือ และความสามารถในการใช้เครื่องมือ บทความนี้ใช้คำดังกล่าวตามคำอธิบายของผู้พูด ไม่ได้อ้างว่าทุกระบบที่มีสามอย่างจะถูกโจมตีสำเร็จเสมอ
ตัวอย่างสมมติของ VibeSolo คือ agent ฝ่ายจัดซื้ออ่านอีเมลผู้ขายที่มีข้อความชักจูงให้แก้บัญชีรับเงิน หากมันเข้าถึงทั้งอีเมล รายชื่อผู้ขาย และระบบจ่ายเงินได้ สิ่งที่เราต้องตรวจจึงรวมถึงการกระทำที่จะเปลี่ยนข้อมูล ไม่ใช่แค่ความถูกต้องของข้อความสรุป ตัวอย่างนี้ไม่ได้เป็นเหตุการณ์ที่ผู้พูดรายงาน
ตั้งกติกาให้ชัดก่อนให้ AI เชื่อมต่อระบบจริง
Meijer ตั้งข้อสังเกตว่า คำว่า “คำตอบปลอดภัย” หรือ “คำถามเหมาะสม” ในความหมายกว้างๆ ไม่ใช่คุณสมบัติทางคณิตศาสตร์ที่พิสูจน์ได้โดยไม่มีนิยามชัดเจน เขาจึงหันไปอธิบายการทำให้การคำนวณและแผนตรวจสอบได้ แทนการรับรองเจตนาของโมเดล
มุมที่ VibeSolo เห็นว่านำไปคิดต่อได้คือ กำหนดให้ชัดว่าเราต้องการตรวจคุณสมบัติอะไรของการกระทำ ไม่ใช่ถือว่าการตอบได้ดีแปลว่าทุกการกระทำผ่านกติกาแล้ว
หากจะออกแบบกติกาสำหรับงานธุรกิจ เราอาจเริ่มจากตัวอย่างสมมติต่อไปนี้ ตัวอย่างนี้เป็นข้อเสนอของ VibeSolo ไม่ใช่ข้อกำหนดจากผู้พูดหรือระบบ formal proof ที่ใช้งานเสร็จแล้ว
- กำหนดวงเงินคืนต่อคำสั่งซื้อที่ทีมยอมให้ระบบดำเนินการได้
- กำหนดว่าการโอนเงินแบบใดต้องรอผู้รับผิดชอบอนุมัติ
- ระบุว่าข้อมูลชุดใดอ่านได้เพื่อทำงานแต่ละประเภท
- ระบุให้ชัดว่าการลบถาวรเป็นการกระทำที่อนุญาตหรือห้าม
- กำหนดขอบเขตการส่งข้อความภายนอกและขั้นอนุมัติ
- กำหนดว่าต้องใช้หลักฐานใดในการแก้ข้อมูลรับเงินของผู้ขาย
กติกาที่จะตรวจได้ต้องบอกว่า ใครทำอะไร กับข้อมูลใด ภายใต้เงื่อนไขอะไร การเขียนกติกาธุรกิจให้ชัดเป็นจุดเริ่มคิด แต่ยังไม่เท่ากับพิสูจน์ความปลอดภัยของการนำไปใช้งานจริง
ให้ Agent เสนอแผน แทนการอนุญาตให้ลงมือทันที
ข้อเสนอของ Meijer คือแยกการสร้างแผนออกจากการลงมือทำจริง เขาใช้คำว่า air-gap เพื่ออธิบายการเลื่อนการทำงานที่มีผลข้างเคียงออกไป ให้โมเดลส่งแผนมาก่อนแล้วตรวจแผนก่อนเรียกใช้เครื่องมือ ไม่ได้หมายความว่าต้องตัดเครือข่ายทางกายภาพเสมอไป
อย่างไรก็ตาม เขาชี้ว่าแผนที่อยู่ในรูป IO ธรรมดายังเป็นกล่องดำที่ตรวจรายละเอียดภายในไม่ได้ตามแบบจำลองที่กำลังใช้ การเลื่อนการทำงานออกไปจึงเป็นเพียงขั้นแรก ยังไม่พอที่จะพิสูจน์ว่าแผนปลอดภัย
ความต่างที่สำคัญในข้อเสนอของเขาคือ ไม่ใช่แค่ให้ AI เขียนเหตุผลภาษาธรรมชาติที่ฟังน่าเชื่อ แต่ต้องทำให้การคำนวณที่เสนออยู่ในรูปที่นำไปวิเคราะห์และตรวจคุณสมบัติได้
หากเทียบกับงานร้านค้าออนไลน์ เราอาจใช้ลำดับสมมติต่อไปนี้เพื่ออธิบายการแยกเสนอแผนออกจากลงมือ นี่เป็นตัวอย่างของ VibeSolo ไม่ใช่เดโมที่ผู้พูดแสดง และไม่ได้มีหลักฐานพิสูจน์เชิงรูปแบบกำกับ
- Agent รับเรื่องลูกค้าที่แจ้งว่าสินค้าชำรุด
- Agent ตรวจเลขคำสั่งซื้อ เงื่อนไขการรับประกัน และหลักฐานที่ลูกค้าส่ง
- Agent สร้างแผนคืนเงินไปยังช่องทางเดิม และเสนอว่าจะบันทึกเหตุผลในระบบลูกค้า
- ระบบตรวจว่าเงินคืนอยู่ในวงเงิน สินค้ายังอยู่ในช่วงรับประกัน และไม่มีคำขอซ้ำ
- ระบบตัดสินว่าผ่านกติกาที่กำหนดหรือส่งเคสให้เจ้าหน้าที่ ก่อนเปิดให้ดำเนินการต่อ
ลำดับนี้ช่วยแสดงจุดตรวจที่ต้องมี แต่การตรวจเงื่อนไขในตัวอย่างไม่ใช่คำรับรองว่าระบบคืนเงินจริงปลอดภัยครบทุกกรณี และคลิปไม่ได้ให้ผลทดสอบการลดงานหรือเวลาจากตัวอย่างนี้
เปลี่ยนแผนให้เป็นสิ่งที่ตรวจสอบได้ ไม่ใช่ข้อความสวยงาม
ขั้นต่อมาที่ Meijer เสนอคือแปลงแผนให้เป็น “โปรแกรม” ที่แทนการคำนวณ ไม่ใช่ IO ที่ตรวจข้างในไม่ได้ เขาใช้แนวคิด free monad ซึ่งในบริบทนี้ช่วยแทนลำดับการคำนวณเป็นโครงสร้างข้อมูลสำหรับนำไปวิเคราะห์ก่อนรัน และเชื่อมกับ proof-carrying code หรือโปรแกรมที่มีหลักฐานพิสูจน์คุณสมบัติกำกับ
เขาอธิบายว่าเมื่อแผนอยู่ในรูปโปรแกรม เราจึงนำวิธีจากคอมไพเลอร์มาตรวจได้ เช่น วิเคราะห์การไหลของข้อมูลและตรวจชนิดข้อมูล เขายังกล่าวถึงการตามข้อมูลที่ไม่น่าเชื่อถือหรือ taint analysis เป็นแนวทางต่อโจทย์สามองค์ประกอบ แต่บทความนี้ไม่ได้ยืนยันว่าเป็นวิธีป้องกันการโจมตีทุกรูปแบบแล้ว
ช่วงท้ายเขาอธิบายตัวแปลคำสั่งแบบเวียนกลับอย่างง่ายและการพิสูจน์ตามโครงสร้าง พร้อมกล่าวว่าโมเดลสร้างหลักฐานเหล่านี้ได้ และมีงานของนักวิชาการที่นำแนวคิดคล้ายกันไปทำบน GitHub ข้อมูลส่วนนี้เป็นคำอธิบายของผู้พูด ยังไม่ได้ตรวจซอร์สโค้ด สร้างหลักฐานซ้ำ หรือทดสอบระบบจริงอย่างอิสระ
ข้อจำกัดที่ต้องแยกให้ชัดตามข้อคิดของ VibeSolo คือ “พิสูจน์แล้ว” ต้องตอบให้ได้ว่าพิสูจน์คุณสมบัติใด ภายใต้แบบจำลองและเงื่อนไขอะไร ความถูกต้องของคุณสมบัติที่ระบุไม่ได้รับรองเรื่องนอกนิยาม เช่น ทุกการตอบสนองจะเห็นใจลูกค้า หรือทุกส่วนของเครื่องมือและระบบภายนอกจะปราศจากข้อผิดพลาด
การอนุมัติโดยคนหรือการตั้งกติกาแบบ if/then จึงไม่ควรถูกเรียกว่า formal proof เพียงเพราะมีด่านก่อนรัน แนวคิดที่คลิปชวนสำรวจคือทำให้แผนตรวจได้และมีหลักฐานต่อคุณสมบัติที่กำหนด โดยต้องประเมินการนำไปใช้งานจริงแยกจากภาพอธิบายในบทสอน
ใช้หลักความปลอดภัยนี้กับธุรกิจไทยแบบเป็นลำดับ
ข้อคิดสำหรับคนทำระบบคือเริ่มจากระบุให้ได้ว่า agent อ่านอะไร เสนออะไร และส่วนใดจะสร้างผลกระทบจริง ตัวอย่างอย่างสรุปรายงาน จัดหมวดหมู่อีเมล หรือร่างข้อความอาจช่วยให้วางลำดับงานได้ แต่ต้องดูข้อมูลและเครื่องมือที่ใช้จริงด้วย ไม่ใช่ถือว่าชื่องานอย่างเดียวบอกระดับความเสี่ยงได้
แนวทางประยุกต์ของ VibeSolo คือแยกสิทธิ์อ่านและสิทธิ์เปลี่ยนแปลง กำหนดจุดตรวจและเหตุผลการอนุมัติ แล้วทดสอบว่าขอบเขตนั้นทำงานตามที่ตั้งใจ การตรวจและการอนุมัติในระดับงานธุรกิจเป็นคนละข้อกล่าวอ้างกับความปลอดภัยที่พิสูจน์เชิงรูปแบบ จึงต้องรายงานผลตามสิ่งที่ตรวจได้จริง
บทเรียนจากข้อเสนอของ Meijer คือ AI Agent ไม่ควรได้รับความไว้วางใจเพียงเพราะตอบดีหรือวางแผนเก่ง เขาเสนอให้แยกการสร้างแผนออกจากการรัน และแทนแผนด้วยโปรแกรมที่ตรวจคุณสมบัติได้ก่อนเกิดผลข้างเคียง นี่เป็นทิศทางเชิงสถาปัตยกรรมที่ต้องตรวจการนำไปใช้ ไม่ใช่คำรับรองว่า agent ทุกระบบปลอดภัยแล้ว
ที่มา: วิดีโอของ Erik Meijer จากช่อง AI Engineer อัปโหลดวันที่ 13 กรกฎาคม 2026 เวลา 19:25:09 UTC หรือวันที่ 14 กรกฎาคม 2026 เวลา 02:25:09 น. ตามเวลาไทย สรุปจากคำบรรยายที่บันทึกได้ช่วง 00:12–20:53 ซึ่งขาดช่วงต้นและท้าย ไม่ได้ตรวจการทำงานของระบบหรือหลักฐานพิสูจน์อย่างอิสระ วันอัปโหลดเป็นวันของแหล่งข้อมูล ไม่ใช่วันเผยแพร่บทความนี้
