บทนำ
สวัสดีครับ ในยุคปัจจุบัน องค์กรจำนวนมากเริ่มนำ Generative AI เข้ามาช่วยเพิ่มประสิทธิภาพในการทำงาน เช่น การสรุปเอกสาร การเขียนอีเมล การวิเคราะห์ข้อมูล การช่วยเขียนโปรแกรม และการค้นหาความรู้ภายในองค์กร เครื่องมือเหล่านี้ช่วยลดเวลาในการทำงานและเพิ่มความสะดวกให้กับพนักงานอย่างมาก
อย่างไรก็ตาม การใช้งาน AI ก็ทำให้เกิดความเสี่ยงด้านความปลอดภัยรูปแบบใหม่ โดยเฉพาะปัญหา AI Data Leakage หรือการรั่วไหลของข้อมูลผ่านระบบ AI ซึ่งอาจเกิดจากการที่พนักงานนำข้อมูลลับไปใส่ใน prompt, อัปโหลดไฟล์ภายในองค์กรเข้า AI, ใช้เครื่องมือ AI ที่องค์กรไม่ได้อนุมัติ หรือเชื่อมต่อ AI เข้ากับระบบภายในโดยไม่มีการควบคุมที่เหมาะสม
OWASP ได้จัดให้ Sensitive Information Disclosure เป็นหนึ่งในความเสี่ยงสำคัญของ LLM Application โดยระบุว่าระบบ AI อาจเปิดเผยข้อมูลสำคัญผ่าน input, output, log หรือการเชื่อมต่อกับระบบอื่น หากไม่มีมาตรการควบคุมที่ดีพอ
1. Generative AI คืออะไร และทำไมองค์กรนิยมใช้
Generative AI คือเทคโนโลยีปัญญาประดิษฐ์ที่สามารถสร้างเนื้อหาใหม่ได้ เช่น ข้อความ รูปภาพ โค้ด ตาราง สรุปเอกสาร หรือคำตอบจากข้อมูลที่ผู้ใช้ป้อนเข้าไป ตัวอย่างเครื่องมือที่องค์กรนิยมใช้ เช่น ChatGPT, Microsoft Copilot, Google Gemini, Claude, GitHub Copilot และ AI Assistant อื่น ๆ
เหตุผลที่องค์กรนิยมใช้ Generative AI ได้แก่
- ช่วยลดเวลาการทำงานซ้ำ ๆ
- ช่วยสรุปเอกสารจำนวนมาก
- ช่วยเขียนหรือปรับปรุงข้อความทางธุรกิจ
- ช่วยนักพัฒนาเขียนและตรวจสอบโค้ด
- ช่วยวิเคราะห์ข้อมูลและสร้างรายงาน
- ช่วยให้พนักงานทำงานได้เร็วขึ้น
ถึงแม้ Generative AI จะมีประโยชน์มาก แต่การนำไปใช้ในองค์กรต้องมีการควบคุม เพราะ AI อาจได้รับข้อมูลสำคัญจากผู้ใช้งาน และข้อมูลเหล่านั้นอาจถูกเก็บในระบบ, log, history, telemetry หรือถูกส่งต่อไปยังบริการภายนอกได้ หากองค์กรไม่เข้าใจเงื่อนไขการใช้งานและนโยบายข้อมูลของแต่ละเครื่องมือ
2. AI Data Leakage คืออะไร
AI Data Leakage คือเหตุการณ์ที่ข้อมูลสำคัญขององค์กรถูกเปิดเผยหรือส่งออกไปยังระบบ AI โดยไม่ได้รับอนุญาต หรือถูกนำไปใช้งานผิดวัตถุประสงค์ผ่านเครื่องมือ AI เช่น พนักงานคัดลอกข้อมูลลูกค้าไปถาม AI, อัปโหลดไฟล์สัญญาเข้า chatbot, นำ source code ภายในไปให้ AI ช่วยแก้ไข หรือใช้ AI coding assistant ที่ส่งข้อมูลจากโปรเจกต์ภายในออกไปยังผู้ให้บริการภายนอก
ความเสี่ยงนี้อาจเกิดขึ้นได้ทั้งจากความไม่ตั้งใจของพนักงาน และจากการตั้งค่าระบบ AI ที่ไม่เหมาะสม เช่น AI มีสิทธิ์เข้าถึงไฟล์ภายในมากเกินไป หรือ AI Agent สามารถเรียก API ภายในองค์กรได้โดยไม่มีการจำกัดสิทธิ์
NIST ได้เผยแพร่แนวทาง AI Risk Management Framework: Generative AI Profile เพื่อช่วยให้องค์กรระบุ ประเมิน และจัดการความเสี่ยงเฉพาะของ Generative AI รวมถึงประเด็นด้าน privacy, security และ governance
3. สาเหตุของข้อมูลรั่วไหลผ่าน AI
3.1 การใส่ข้อมูลลับใน Prompt
หนึ่งในสาเหตุที่พบบ่อยที่สุดคือการที่ผู้ใช้นำข้อมูลลับไปใส่ใน prompt โดยตรง เช่น
- “ช่วยสรุปข้อมูลลูกค้าชุดนี้ให้หน่อย”
- “ช่วยวิเคราะห์ไฟล์รายรับรายจ่ายของบริษัท”
- “ช่วยแก้โค้ดนี้ให้หน่อย นี่คือ API key และ database connection”
- “ช่วยร่างอีเมลจากสัญญาฉบับนี้”
ปัญหาคือ prompt ที่ใส่เข้าไปอาจถูกบันทึกไว้ในระบบของผู้ให้บริการ AI หรืออยู่ในประวัติการใช้งาน หากไม่มีการตั้งค่าความปลอดภัยที่เหมาะสม ข้อมูลที่ควรอยู่ภายในองค์กรอาจหลุดออกไปยัง third-party service ได้
3.2 การอัปโหลดไฟล์ภายในองค์กร
หลายเครื่องมือ AI รองรับการอัปโหลดไฟล์ เช่น PDF, Word, Excel, source code, log file หรือไฟล์สัญญา เพื่อให้ AI ช่วยสรุป วิเคราะห์ หรือแปลงข้อมูล แต่หากไฟล์ที่อัปโหลดมีข้อมูลสำคัญ เช่น รายชื่อลูกค้า เลขที่บัญชี ข้อมูลทางการเงิน หรือข้อมูลโครงการภายใน ก็อาจทำให้เกิด data leakage ได้
ตัวอย่างเช่น พนักงานอัปโหลดไฟล์รายชื่อลูกค้าพร้อมเบอร์โทรศัพท์และอีเมลเข้า AI เพื่อให้ช่วยจัดกลุ่มข้อมูล แม้จะไม่ได้ตั้งใจเปิดเผยข้อมูล แต่ข้อมูลนั้นได้ถูกส่งออกไปยังระบบภายนอกองค์กรแล้ว
3.3 การใช้ Shadow AI
Shadow AI คือการที่พนักงานใช้งานเครื่องมือ AI โดยไม่ได้รับอนุญาตจากองค์กร เช่น ใช้บัญชีส่วนตัวเข้า AI tool แล้วนำข้อมูลงานไปประมวลผล โดยฝ่าย IT หรือ Security ไม่สามารถมองเห็น ควบคุม หรือตรวจสอบได้
Microsoft อธิบายว่า Shadow AI เป็นความเสี่ยงสำคัญ เพราะองค์กรไม่สามารถป้องกันข้อมูลที่ตนเองมองไม่เห็นได้ และข้อมูลอาจถูกส่งไปยัง AI app ที่ไม่มีการกำกับดูแลด้าน retention, compliance หรือ data protection ที่เหมาะสม
ตัวอย่าง Shadow AI ได้แก่
- ใช้ chatbot ส่วนตัวสรุปเอกสารลับ
- ใช้ AI แปลเอกสารลูกค้าโดยไม่ได้รับอนุญาต
- ใช้ AI tool ฟรีช่วยวิเคราะห์ไฟล์ภายใน
- ใช้ browser extension AI ที่ไม่ได้ผ่านการตรวจสอบ
- ใช้ AI note-taking bot บันทึกประชุมภายใน
3.4 การใช้ AI Coding Assistant
AI Coding Assistant เช่น GitHub Copilot, Cursor, Claude Code หรือเครื่องมือช่วยเขียนโค้ดอื่น ๆ ช่วยให้นักพัฒนาทำงานได้เร็วขึ้น แต่ก็มีความเสี่ยงด้านข้อมูลรั่วไหลเช่นกัน โดยเฉพาะเมื่อเครื่องมือสามารถเข้าถึง source code, configuration file, environment variable หรือ secret ภายในโปรเจกต์ได้
ความเสี่ยงที่อาจเกิดขึ้น ได้แก่
- source code ภายในถูกส่งไปยัง AI service
- API key หรือ access token ถูกแนบไปกับ context
- AI แนะนำโค้ดที่ไม่ปลอดภัย
- AI agent อ่านไฟล์ที่ไม่ควรอ่าน
- prompt injection ในไฟล์ README หรือ comment หลอกให้ AI ส่งข้อมูลออกไป
OWASP Top 10 for LLM Applications ระบุความเสี่ยงอย่าง Prompt Injection, Sensitive Information Disclosure, Excessive Agency และ System Prompt Leakage ซึ่งเกี่ยวข้องโดยตรงกับ AI assistant และ AI agent ที่สามารถอ่านข้อมูลหรือเรียกใช้งานเครื่องมืออื่นได้
3.5 การเชื่อม AI กับระบบภายใน
องค์กรจำนวนมากเริ่มนำ AI มาเชื่อมกับระบบภายใน เช่น knowledge base, ticket system, CRM, email, SharePoint, Google Drive, Jira, Slack หรือ database เพื่อให้ AI ตอบคำถามจากข้อมูลภายในองค์กรได้
แม้วิธีนี้จะช่วยเพิ่มประสิทธิภาพ แต่ก็มีความเสี่ยงหากกำหนดสิทธิ์ไม่เหมาะสม เช่น
- AI เข้าถึงเอกสารที่ผู้ใช้จริงไม่มีสิทธิ์เข้าถึง
- AI ดึงข้อมูลลูกค้าจาก CRM มาแสดงให้ผู้ใช้ผิดกลุ่ม
- AI เชื่อมต่อกับ database ด้วยสิทธิ์สูงเกินจำเป็น
- AI agent สามารถเรียก API ภายในโดยไม่มีการตรวจสอบ
- ข้อมูลภายในถูกนำไปสร้าง embedding หรือ index โดยไม่มี data classification
ความเสี่ยงลักษณะนี้มักเกี่ยวข้องกับการตั้งค่าสิทธิ์ผิดพลาด หรือการให้ AI มีอำนาจมากเกินไป ซึ่งควรควบคุมด้วยหลัก Least Privilege และการตรวจสอบ log อย่างสม่ำเสมอ
4. ตัวอย่างข้อมูลที่อาจรั่วไหล
4.1 ข้อมูลลูกค้า
ข้อมูลลูกค้าเป็นข้อมูลที่มีความอ่อนไหวสูง เช่น ชื่อ ที่อยู่ เบอร์โทรศัพท์ อีเมล เลขบัตรประชาชน ประวัติการซื้อสินค้า หรือข้อมูลการติดต่อ หากข้อมูลเหล่านี้ถูกนำไปใส่ใน AI โดยไม่มีการปกปิดหรือควบคุม อาจเกิดการละเมิดความเป็นส่วนตัวและกฎหมายคุ้มครองข้อมูลส่วนบุคคล
4.2 Source Code
Source code เป็นทรัพย์สินสำคัญขององค์กร หากโค้ดภายในถูกส่งเข้า AI ภายนอก อาจทำให้ logic ของระบบ, algorithm, endpoint, business rule หรือช่องโหว่ของระบบถูกเปิดเผยได้ โดยเฉพาะโค้ดที่เกี่ยวข้องกับ authentication, payment, encryption หรือระบบภายใน
4.3 API Key / Access Token
API key, access token, private key และ credential เป็นข้อมูลที่อันตรายมากหากรั่วไหล เพราะผู้ไม่หวังดีอาจนำไปใช้เข้าถึงระบบแทนองค์กรได้ เช่น เรียก API, อ่านฐานข้อมูล, เข้าถึง cloud storage หรือควบคุม service account
GitHub และเครื่องมือ DevSecOps หลายประเภทจึงมีระบบ Secret Scanning เพื่อช่วยตรวจจับ credential ที่หลุดอยู่ใน source code หรือ repository และควรใช้ร่วมกับการ rotate/revoke key ทันทีเมื่อพบการรั่วไหล
4.4 เอกสารสัญญา
เอกสารสัญญามักมีข้อมูลสำคัญ เช่น เงื่อนไขทางธุรกิจ ราคา ข้อตกลงทางกฎหมาย ชื่อคู่ค้า รายละเอียดโครงการ หรือข้อมูลลับทางการค้า หากอัปโหลดเข้า AI ที่ไม่ได้รับอนุญาต อาจทำให้ข้อมูลที่มีข้อผูกพันทางกฎหมายรั่วไหลได้
4.5 ข้อมูลทางการเงิน
ข้อมูลทางการเงิน เช่น งบประมาณ รายรับรายจ่าย ใบแจ้งหนี้ รายงานกำไรขาดทุน เงินเดือน หรือแผนการลงทุน เป็นข้อมูลที่มีความอ่อนไหวสูง หากรั่วไหลอาจส่งผลต่อการแข่งขันทางธุรกิจ ความน่าเชื่อถือ และความมั่นคงขององค์กร
5. ผลกระทบต่อองค์กร
AI Data Leakage อาจส่งผลกระทบต่อองค์กรหลายด้าน ได้แก่
5.1 ความเสียหายด้านชื่อเสียง
หากข้อมูลลูกค้าหรือข้อมูลภายในรั่วไหล องค์กรอาจสูญเสียความเชื่อมั่นจากลูกค้า คู่ค้า และผู้ถือหุ้น
5.2 ความเสี่ยงด้านกฎหมายและ Compliance
การรั่วไหลของข้อมูลส่วนบุคคลอาจทำให้องค์กรละเมิดกฎหมายคุ้มครองข้อมูล เช่น PDPA, GDPR หรือข้อกำหนดด้านอุตสาหกรรม
5.3 ความเสียหายทางธุรกิจ
ข้อมูลสัญญา แผนธุรกิจ source code หรือข้อมูลทางการเงินที่รั่วไหล อาจทำให้คู่แข่งได้เปรียบ หรือทำให้เกิดความเสียหายทางการเงินโดยตรง
5.4 ความเสี่ยงด้าน Cyber Attack
หาก API key, access token หรือข้อมูลระบบภายในรั่วไหล ผู้ไม่หวังดีอาจนำไปใช้โจมตีต่อ เช่น เข้าถึงระบบ cloud, ขโมยข้อมูลเพิ่ม หรือยกระดับสิทธิ์ในระบบ
5.5 ความเสี่ยงจากการควบคุมไม่ได้
เมื่อข้อมูลถูกส่งออกไปยัง AI tool ที่องค์กรไม่ได้ควบคุม องค์กรอาจไม่สามารถรู้ได้ว่าข้อมูลถูกเก็บไว้นานเท่าไร ถูกนำไปใช้ต่อหรือไม่ หรือมีใครสามารถเข้าถึงข้อมูลนั้นได้บ้าง
6. แนวทางป้องกัน
6.1 จัดทำนโยบายการใช้ AI ภายในองค์กร
องค์กรควรกำหนด AI Usage Policy อย่างชัดเจน เช่น ข้อมูลประเภทใดห้ามนำเข้า AI, เครื่องมือ AI ใดที่อนุญาตให้ใช้, ใครสามารถใช้งานได้, ต้องขออนุมัติเมื่อใด และมีข้อกำหนดเรื่องการอัปโหลดไฟล์อย่างไร
ตัวอย่างนโยบายที่ควรมี:
- ห้ามใส่ข้อมูลลูกค้าจริงลงใน AI สาธารณะ
- ห้ามอัปโหลดเอกสารลับเข้า AI ที่ไม่ได้รับอนุญาต
- ห้ามใส่ API key, password หรือ token ลงใน prompt
- ให้ใช้เฉพาะ AI tool ที่องค์กรอนุมัติ
- ต้อง anonymize หรือ mask ข้อมูลก่อนใช้งาน AI
6.2 ใช้หลัก Least Privilege
เมื่อเชื่อม AI กับระบบภายใน ควรใช้หลัก Least Privilege คือให้ AI เข้าถึงเฉพาะข้อมูลที่จำเป็นเท่านั้น เช่น หาก AI ใช้ตอบคำถามจากเอกสาร HR ก็ควรเข้าถึงเฉพาะเอกสาร HR ที่ได้รับอนุญาต ไม่ควรเข้าถึงทุกไฟล์ในองค์กร
หลักนี้ควรใช้กับทั้ง user account, service account, API token, plugin, connector และ AI agent
6.3 ใช้ Data Loss Prevention หรือ DLP
องค์กรควรใช้ระบบ DLP เพื่อตรวจจับและป้องกันการส่งข้อมูลสำคัญออกไปยัง AI tool เช่น ตรวจจับเลขบัตรประชาชน อีเมลลูกค้า เลขบัญชี API key หรือไฟล์ที่มี classification เป็น confidential
DLP สามารถช่วย block, warn หรือ log การใช้งานที่เสี่ยงได้ เช่น เมื่อพนักงานพยายามคัดลอกข้อมูลลูกค้าไปใส่ใน AI prompt
6.4 ใช้ Secret Scanning
สำหรับทีมพัฒนา ควรเปิดใช้ Secret Scanning เพื่อตรวจจับ API key, token, private key หรือ password ที่อาจอยู่ใน source code, commit history, prompt หรือ output จาก AI coding assistant
หากพบ secret หลุด ควรดำเนินการทันที ได้แก่
- revoke key เดิม
- rotate key ใหม่
- ตรวจสอบ log ว่ามีการใช้งานผิดปกติหรือไม่
- ปรับ permission ของ key ให้แคบลง
- ป้องกันไม่ให้ secret ถูก commit ซ้ำ
6.5 ควบคุม Shadow AI
องค์กรควรค้นหาและควบคุมการใช้ AI ที่ไม่ได้รับอนุญาต เช่น ผ่าน CASB, SWG, endpoint management, browser control หรือ network monitoring เพื่อดูว่ามีพนักงานใช้งาน AI tool ใดบ้าง
แนวทางควบคุม Shadow AI ได้แก่
- ทำรายการ AI tool ที่อนุญาตและไม่อนุญาต
- block AI app ที่มีความเสี่ยงสูง
- แจ้งเตือนเมื่อมีการส่งข้อมูลสำคัญออกไป
- ให้พนักงานมีทางเลือก AI ที่ปลอดภัยและใช้งานง่าย
- อบรมให้เข้าใจความเสี่ยงของการใช้ AI ส่วนตัวกับข้อมูลองค์กร
6.6 Logging and Monitoring
ควรเปิดใช้งาน logging and monitoring สำหรับการใช้งาน AI เช่น
- ใครใช้งาน AI
- ใช้เครื่องมือใด
- อัปโหลดไฟล์อะไร
- มีการเชื่อมต่อกับระบบใด
- AI เรียก API ใดบ้าง
- มีการเข้าถึงข้อมูลเกินสิทธิ์หรือไม่
- มี prompt หรือ output ที่มีข้อมูลสำคัญหรือไม่
Log เหล่านี้ช่วยให้ทีม Security ตรวจสอบ incident ได้เร็วขึ้น หากเกิดข้อมูลรั่วไหลหรือมีการใช้งานผิดปกติ
6.7 Data Masking และ Anonymization
ก่อนนำข้อมูลเข้า AI ควรทำ data masking หรือ anonymization เพื่อลดความเสี่ยง เช่น
- เปลี่ยนชื่อจริงเป็น Customer A
- ลบเลขบัตรประชาชน
- ลบเบอร์โทรศัพท์
- ซ่อนเลขบัญชีบางส่วน
- ลบ API key และ token
- ใช้ข้อมูลตัวอย่างแทนข้อมูลจริง
วิธีนี้ช่วยให้พนักงานยังใช้ AI ช่วยวิเคราะห์หรือสรุปงานได้ โดยลดโอกาสที่ข้อมูลจริงจะรั่วไหล
6.8 AI Security Awareness Training
องค์กรควรอบรมพนักงานให้เข้าใจว่า AI ไม่ใช่พื้นที่ปลอดภัยสำหรับข้อมูลลับเสมอไป และควรใช้ AI อย่างระมัดระวัง โดยเนื้อหาการอบรมควรครอบคลุมเรื่อง
- ข้อมูลประเภทใดห้ามใส่ใน AI
- วิธีใช้ AI อย่างปลอดภัย
- ความเสี่ยงของ Shadow AI
- การปกปิดข้อมูลก่อนใช้งาน AI
- การรายงานเหตุการณ์เมื่อเผลอใส่ข้อมูลลับลง AI
7. สรุป
AI Data Leakage เป็นความเสี่ยงสำคัญขององค์กรยุคใหม่ เนื่องจาก Generative AI ถูกนำมาใช้ในงานหลายด้าน ทั้งการสรุปเอกสาร การเขียนโปรแกรม การวิเคราะห์ข้อมูล และการเชื่อมต่อกับระบบภายใน แม้ AI จะช่วยเพิ่มประสิทธิภาพในการทำงาน แต่หากขาดการควบคุม อาจทำให้ข้อมูลสำคัญขององค์กรรั่วไหลได้
สาเหตุหลักของข้อมูลรั่วไหลผ่าน AI ได้แก่ การใส่ข้อมูลลับใน prompt, การอัปโหลดไฟล์ภายใน, การใช้ Shadow AI, การใช้ AI Coding Assistant และการเชื่อม AI เข้ากับระบบภายในโดยให้สิทธิ์มากเกินไป ข้อมูลที่อาจรั่วไหลมีทั้งข้อมูลลูกค้า source code, API key, access token, เอกสารสัญญา และข้อมูลทางการเงิน
ดังนั้น องค์กรควรกำหนดนโยบายการใช้ AI อย่างชัดเจน ใช้หลัก least privilege เปิดใช้ DLP และ secret scanning ควบคุม Shadow AI ตรวจสอบ log อย่างต่อเนื่อง และอบรมพนักงานให้เข้าใจความเสี่ยง เพื่อให้สามารถใช้ AI ได้อย่างปลอดภัยและเกิดประโยชน์สูงสุดต่อองค์กร
บทบาทของ Personar ในการลดผลกระทบจาก AI Data Leakage
แม้องค์กรจะมีนโยบายควบคุมการใช้งาน AI แล้ว แต่ความเสี่ยงจาก AI Data Leakage ยังคงเกิดขึ้นได้ เช่น พนักงานอาจเผลอนำข้อมูลลูกค้า Source Code API Key หรือเอกสารภายในไปใส่ใน AI Tool ที่ไม่ได้รับอนุญาต หรือใช้ Shadow AI โดยที่ฝ่าย IT ไม่สามารถตรวจสอบได้ทันที เมื่อข้อมูลเหล่านี้หลุดออกไปแล้ว สิ่งสำคัญคือองค์กรต้องสามารถตรวจพบเหตุการณ์ได้เร็วที่สุด เพื่อลดความเสียหายและดำเนินการตอบสนองได้ทันเวลา
ในจุดนี้ Personar สามารถเข้ามามีบทบาทในฐานะเครื่องมือด้าน Data Leak Monitoring และ Threat Intelligence ที่ช่วยเฝ้าระวังว่ามีข้อมูลขององค์กรปรากฏอยู่บนแหล่งข้อมูลภายนอกหรือไม่ เช่น ข้อมูลรั่วไหลบนอินเทอร์เน็ต ข้อมูลบัญชีผู้ใช้ที่ถูกเปิดเผย Credential ที่รั่วไหล หรือ Source Code ที่หลุดออกไป โดยการตรวจพบข้อมูลเหล่านี้ได้เร็วจะช่วยให้องค์กรสามารถประเมินขอบเขตความเสียหาย แจ้งเตือนทีมที่เกี่ยวข้อง และดำเนินการแก้ไขได้ทันที เช่น เปลี่ยนรหัสผ่าน ยกเลิก API Key หรือ Access Token ที่รั่วไหล ตรวจสอบ Log ย้อนหลัง และแจ้งผู้ที่ได้รับผลกระทบ
ดังนั้น Personar ไม่ได้ทำหน้าที่แทนมาตรการป้องกันหลัก เช่น AI Usage Policy, DLP, Least Privilege หรือ Secret Scanning แต่เป็นเครื่องมือสำคัญในขั้นตอน Detection และ Incident Response หลังจากเกิดความเสี่ยงหรือข้อมูลเริ่มรั่วไหลแล้ว ช่วยให้องค์กร “รู้ตัวเร็ว” ลดเวลาที่ข้อมูลรั่วไหลโดยไม่มีใครทราบ และลดโอกาสที่ผู้ไม่หวังดีจะนำข้อมูลไปใช้โจมตีต่อ
https://www.paloaltonetworks.com/resources/infographics/llm-applications-owasp-10
