เมื่อหน้าเว็บพยายามสั่งผู้ช่วย AI: ทีมการตลาดควรรับมือ Prompt Injection อย่างไร

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

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

คำสั่งที่แฝงมากับแหล่งข้อมูลเข้ามาได้อย่างไร

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

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

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

เขียนพรอมป์ต์ให้ชัด แล้ววางข้อจำกัดไว้ในระบบด้วย

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

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

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

สำรวจเส้นทางข้อมูล ก่อนเพิ่มความสามารถให้ผู้ช่วย

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

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

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

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

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

ออกแบบการทดลองให้เห็นทั้งงานที่สำเร็จและสิ่งที่ไม่ควรเกิด

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

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

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

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

เริ่มจากหนึ่งงานที่ทีมยังใช้ประโยชน์ได้ภายใต้ข้อจำกัด

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

ตรวจสอบแหล่งข้อมูลทางการที่อ้างอิงเมื่อ 23 กันยายน 2026 ตามเวลาบางกอก หรือ 22 กันยายนตามเวลา UTC