302.ai ข้อมูลรั่ว คือเหตุที่ Cybernews รายงานว่าพบคลาวด์ Azure ของ 302.ai ตัวกลางที่รวม ChatGPT, Claude, Grok, DeepSeek และ Gemini ไว้ในบัญชีเดียว เปิดสาธารณะอยู่ รวม 22.72TB ราว 17.6 ล้านไฟล์ มี chat log กว่า 144,000 ชุด บางชุดมีที่อยู่บ้านของผู้ใช้ บทความนี้เหมาะกับ SME และนักพัฒนาไทยที่ต่อแชตบอตผ่านตัวกลาง AI ราคาถูก
ลองนึกภาพคลินิกความงามในกรุงเทพฯ (ตัวอย่างสมมติ) ที่จ้างฟรีแลนซ์ทำแชตบอตตอบลูกค้าใน LINE OA ฟรีแลนซ์เลือกตัวกลาง AI ที่ถูกที่สุดเพื่อประหยัดค่า API ลูกค้าพิมพ์ชื่อ เบอร์โทร วันเกิด และปัญหาผิวลงแชตทุกวัน เจ้าของคลินิกไม่เคยรู้ว่าข้อความถูกเก็บไว้ที่ไหน
สรุปสั้น: ตามรายงานของ Cybernews คลาวด์ของ 302.ai เปิดทิ้งไว้ มีไฟล์ 22.72TB และ chat log กว่า 144,000 ชุด ปิดแล้วเมื่อ 8 กันยายน 2569 ไม่พบหลักฐานว่ามีคนดาวน์โหลด ธุรกิจไทยที่ส่งข้อมูลลูกค้าผ่านตัวกลาง AI ยังเป็นผู้ควบคุมข้อมูลตาม PDPA ต้องมีสัญญาผู้ประมวลผลข้อมูล ตรวจการส่งข้อมูลไปต่างประเทศ และประเมินหน้าที่แจ้งเหตุ
302.ai ข้อมูลรั่ว คืออะไร เกิดอะไรขึ้น
302.ai ข้อมูลรั่ว คือการที่ storage bucket บน Azure ของ 302.ai ซึ่งพัฒนาโดย Univerads Technology Limited บริษัทฮ่องกงที่ก่อตั้งปี 2563 (ค.ศ. 2020) เปิดให้ใครก็เข้าถึงได้ ตามรายงานของ Cybernews ที่สื่อหลายแห่งรายงานต่อ เหตุนี้ไม่ใช่การเจาะระบบของเจ้าของโมเดลอย่าง OpenAI หรือ Google
| ประเด็น | ข้อเท็จจริงตามรายงาน |
|---|---|
| ขนาด | ราว 17.6 ล้านไฟล์ รวม 22.72TB (รูปราว 9TB วิดีโอ 7.7TB เสียง 5.6TB) |
| chat log | กว่า 144,000 ชุด มีพรอมต์ คำตอบ โมเดลที่ใช้ ค่า token และเวลา · ไฟล์ ZIP กว่า 26,000 ไฟล์ |
| ข้อมูลส่วนบุคคล | บางชุดมีวันเกิด เพศ ข้อมูลติดต่อ และที่อยู่บ้าน |
| ลูกค้าองค์กร | มี log จากแชตบอตบริการลูกค้าของผู้ผลิตตุ๊กตาเพศรายใหญ่ (ไม่ระบุชื่อ) |
| สถานะ | ปิดแล้ว ไม่พบหลักฐานว่ามีผู้ไม่หวังดีดาวน์โหลด · 302.ai ยังไม่ตอบสื่อ |
ไทม์ไลน์ตามรายงาน:
- 2 สิงหาคม 2569 นักวิจัยของ Cybernews พบ bucket ที่เปิดสาธารณะ
- 11 สิงหาคม 2569 แจ้ง 302.ai
- 8 กันยายน 2569 นักวิจัยพบว่า bucket ถูกปิดแล้ว
- 21 ตุลาคม 2569 Cybernews เผยแพร่ผลการตรวจพบ
- ยังไม่ทราบ ว่าเปิดทิ้งไว้ตั้งแต่เมื่อไร
302.ai ข้อมูลรั่ว กระทบธุรกิจไทยอย่างไร
302.ai ข้อมูลรั่ว กระทบธุรกิจไทยตรงที่ SME และนักพัฒนาไทยนิยมใช้ตัวกลาง AI ราคาถูกเชื่อมแชตบอต LINE OA หรือเพจ ถ้าข้อมูลลูกค้าวิ่งผ่านตัวกลาง ธุรกิจไทยก็ยังเป็นผู้ควบคุมข้อมูลตาม PDPA ไม่ว่าตัวกลางจะอยู่ฮ่องกงหรือที่ไหน ส่วนนี้เป็นการวิเคราะห์ของผู้เขียน
ใช้ AI ผ่านตัวกลาง ใครรับผิดถ้าข้อมูลลูกค้ารั่ว
ธุรกิจไทยที่เลือกใช้ตัวกลางยังต้องรับผิดในฐานะผู้ควบคุมข้อมูล เพราะเป็นคนตัดสินใจส่งข้อมูลลูกค้าออกไป PDPA มาตรา 40 กำหนดหน้าที่ของผู้ประมวลผลข้อมูล และให้ผู้ควบคุมต้องมีข้อตกลงกับผู้ประมวลผล ธุรกิจที่ส่งข้อมูลผ่านตัวกลางโดยไม่มีข้อตกลงจึงมีความเสี่ยงทางกฎหมายตั้งแต่ก่อนเกิดเหตุ
ทำไมตัวกลาง AI จึงเสี่ยงกว่าการต่อตรงกับเจ้าของโมเดล
ตัวกลาง AI เสี่ยงกว่าเพราะเพิ่มผู้ถือข้อมูลอีกหนึ่งชั้นที่ธุรกิจมองไม่เห็น กรณี 302.ai แสดงว่าตัวกลางเก็บ chat log ทั้งพรอมต์และคำตอบไว้เอง ความเสี่ยงจึงไม่ได้อยู่ที่ OpenAI หรือ Google แต่อยู่ที่ชั้นกลาง บทเรียนเรื่องผู้ประมวลผลทำข้อมูลรั่วเคยเกิดในญี่ปุ่นและสรุปไว้ใน ญี่ปุ่นข้อมูลรั่วต่อเนื่อง skyticket 14.6 ล้าน คาราโอเกะ 8.7 ล้าน Lawson 2.16 ล้าน รัฐเรียกประชุมฉุกเฉิน สัญญา DPA ของธุรกิจไทยต้องมีข้อไหน
แชตบอตบริการลูกค้าเก็บข้อมูลอ่อนไหวได้แค่ไหน
แชตบอตเก็บข้อมูลอ่อนไหวได้มากกว่าที่เจ้าของธุรกิจคิด เพราะลูกค้าพิมพ์เรื่องส่วนตัวลงไปเอง log จากแชตบอตของผู้ผลิตตุ๊กตาเพศในเหตุนี้คือตัวอย่างชัด ข้อมูลพฤติกรรมทางเพศหรือสุขภาพเป็นข้อมูลอ่อนไหวตาม PDPA มาตรา 26 คลินิกและโรงพยาบาลเอกชนจึงเสี่ยงเป็นพิเศษ
ฟรีแลนซ์และเอเจนซีที่ทำแชตบอตให้ลูกค้าต้องระวังอะไร
ฟรีแลนซ์และเอเจนซีต้องบอกลูกค้าให้ชัดว่าข้อความวิ่งผ่านผู้ให้บริการรายใด เพราะลูกค้าซึ่งเป็นผู้ควบคุมข้อมูลต้องรู้เพื่อทำสัญญาและแจ้งเจ้าของข้อมูล ถ้าแอบเปลี่ยนไปใช้ตัวกลางที่ถูกกว่า เมื่อเกิดเหตุจะกลายเป็นข้อพิพาททันที
เทียบกับกฎหมายไทย: 302.ai ข้อมูลรั่ว กับหน้าที่ตาม PDPA
PDPA ของไทยมีหน้าที่ครอบคลุมเหตุแบบ 302.ai อยู่แล้ว แม้ตัวกลางจะอยู่ต่างประเทศ ตารางนี้เทียบสิ่งที่เกิดขึ้นกับหน้าที่ของธุรกิจไทยที่ส่งข้อมูลผ่านตัวกลาง
| ประเด็น | กรณี 302.ai (ตามรายงาน) | กฎหมายไทย |
|---|---|---|
| สัญญากับตัวกลาง | ไม่ทราบว่าลูกค้าองค์กรมีข้อตกลงหรือไม่ | PDPA ม.40 หน้าที่ผู้ประมวลผล และข้อตกลงระหว่างผู้ควบคุมกับผู้ประมวลผล |
| ข้อมูลไปต่างประเทศ | เก็บบน Azure ของบริษัทฮ่องกง | PDPA ม.28–29 การส่งข้อมูลไปต่างประเทศ |
| ความปลอดภัย | bucket เปิดสาธารณะ | PDPA ม.37(1) มาตรการรักษาความมั่นคงปลอดภัยที่เหมาะสม |
| การแจ้งเหตุ | 302.ai ยังไม่ตอบสื่อ ไม่ทราบว่าแจ้งผู้ใช้หรือไม่ | PDPA ม.37(4) แจ้ง สคส. ภายใน 72 ชม. นับจากรู้เหตุ |
ช่องว่างที่พบบ่อยคือธุรกิจไทยไม่รู้ด้วยซ้ำว่าใช้ตัวกลาง เพราะฟรีแลนซ์หรือปลั๊กอินเป็นคนเลือก เมื่อไม่รู้ก็ไม่มีสัญญาและประเมินการแจ้งเหตุไม่ทัน แต่หน้าที่ตาม PDPA ไม่ได้หายไปเพราะไม่รู้
ถ้าไม่ทำอะไรเลย ธุรกิจไทยเสี่ยงอะไร
ถ้าไม่ทำอะไร ธุรกิจไทยเสี่ยง 3 เรื่อง เรื่องแรกคือผิดหน้าที่ผู้ควบคุมข้อมูลเพราะไม่มีข้อตกลงกับผู้ประมวลผลตามมาตรา 40 เรื่องที่สองคือรู้เหตุแล้วไม่ประเมินการแจ้ง สคส. ภายใน 72 ชั่วโมงตามมาตรา 37(4)
เรื่องที่สามคือความเสียหายต่อชื่อเสียง ลูกค้าที่พิมพ์ที่อยู่บ้านลงแชตจะโทษแบรนด์ที่เขาคุยด้วย ไม่ใช่ตัวกลางในฮ่องกง บทเรียนเรื่องผู้ให้บริการภายนอกทำให้แบรนด์ต้องรับเรื่องแทนมีให้เห็นใน Canva ยืนยันข้อมูลลูกค้าองค์กรรั่วผ่าน Canny ที่เชื่อม Salesforce องค์กรไทยที่ใช้ Canva ต้องเช็กสัญญา DPA และแจ้งเหตุ
SME ไทยที่ใช้แชตบอต AI ควรทำอะไรตอนนี้
SME ไทยที่ใช้แชตบอต AI ควรทำ 5 เรื่องนี้ เพื่อไม่ให้เหตุแบบ 302.ai ข้อมูลรั่วกลายเป็นปัญหาของแบรนด์ตัวเอง (กรอบเวลาเป็นข้อเสนอของผู้เขียน)
- 1. เจ้าของธุรกิจและฝ่ายไอทีไล่เส้นทางข้อมูล AI ภายใน 7 วัน ทำรายการแชตบอต ปลั๊กอิน และ API key ทุกตัว ว่าวิ่งผ่านผู้ให้บริการรายใด ต่อตรงหรือผ่านตัวกลาง
- 2. ถ้าพบว่าใช้ 302.ai ให้ DPO ประเมินเหตุทันที สอบถามผู้ให้บริการว่าข้อมูลลูกค้าอยู่ในชุดที่หลุดหรือไม่ และบันทึกเหตุผลการตัดสินใจแจ้งหรือไม่แจ้ง สคส. ภายใน 72 ชั่วโมงนับจากรู้เหตุ
- 3. ฝ่ายกฎหมายทำข้อตกลงผู้ประมวลผลข้อมูลภายใน 30 วัน ระบุระยะเวลาเก็บ log ประเทศที่เก็บ หน้าที่แจ้งเหตุ และการลบข้อมูลเมื่อเลิกใช้
- 4. ผู้ดูแลแชตบอตตัดข้อมูลระบุตัวตนก่อนส่งให้ AI ภายใน 30 วัน ปิดบังเบอร์โทร ที่อยู่ และเลขบัตร และไม่ส่งข้อมูลสุขภาพไปให้ AI ถ้าไม่จำเป็น
- 5. ฝ่ายจัดซื้อเพิ่มหัวข้อ “ตัวกลาง AI” ในแบบประเมินผู้ขายทุกไตรมาส ถามว่าเก็บ log หรือไม่ นานเท่าไร เก็บที่ประเทศใด แล้วเทียบกับ PDPA มาตรา 28
ธุรกิจที่ยังไม่มีเอกสารสัญญาเหล่านี้ ดูตัวอย่างได้ที่ ชุดสัญญาประมวลผลและแบ่งปันข้อมูล (DPA/DSA) ของ Kooru และอ่านวิธีประเมินผู้ขายใน 44 รัฐสหรัฐฯ ปรับ Labcorp $2.3M เพราะ vendor ทำข้อมูลรั่ว บทเรียน Vendor Governance ที่ธุรกิจไทยใช้ได้ทันที
มุมมองผู้เชี่ยวชาญ
เหตุ 302.ai บอกว่าความเสี่ยงของ AI ไม่ได้อยู่ที่โมเดลดังที่ทุกคนจับตา แต่อยู่ที่ชั้นกลางที่ไม่มีใครถาม ค่า API ที่ถูกลงครึ่งหนึ่ง อาจหมายถึงข้อมูลลูกค้าที่ไปนอนอยู่ในคลาวด์ของคนที่คุณไม่เคยเซ็นสัญญาด้วย จุดที่องค์กรมักพลาดคือคิดว่าใช้ “ChatGPT” อยู่ ทั้งที่จริงใช้ผ่านตัวกลาง ทุกตัวกลางคือผู้ประมวลผลข้อมูลอีกรายที่ต้องประเมินเหมือนผู้ขายทั่วไป
— Phuwara Krobtaku —
LL.M. (IP & IT) | M.S. (IT) | Thai Barrister & Attorney-at-Law
ประวัติผู้เขียน · นโยบายบรรณาธิการ
คำถามที่พบบ่อยเกี่ยวกับ 302.ai ข้อมูลรั่ว
302.ai ข้อมูลรั่ว มีข้อมูลอะไรหลุดบ้าง
ตามรายงานของ Cybernews มีไฟล์ราว 17.6 ล้านไฟล์ รวม 22.72TB ทั้งรูป วิดีโอ เสียง และ chat log กว่า 144,000 ชุด บางชุดมีวันเกิด เพศ ข้อมูลติดต่อ และที่อยู่บ้านของผู้ใช้
ข้อมูลจาก 302.ai ถูกนำไปใช้แล้วหรือยัง
Cybernews ไม่พบหลักฐานว่ามีผู้ไม่หวังดีดาวน์โหลด และ bucket ปิดแล้วเมื่อ 8 กันยายน 2569 แต่ไม่ทราบว่าเปิดทิ้งไว้ตั้งแต่เมื่อไร และ 302.ai ยังไม่ตอบสื่อ
ใช้ ChatGPT ผ่านตัวกลาง ต้องทำสัญญา DPA ไหม
ต้องมี ถ้าตัวกลางจัดการข้อมูลส่วนบุคคลของลูกค้าแทนธุรกิจ PDPA มาตรา 40 ให้ผู้ควบคุมข้อมูลมีข้อตกลงกับผู้ประมวลผล และถ้าข้อมูลไปเก็บต่างประเทศต้องดูมาตรา 28 ประกอบ
ธุรกิจไทยต้องแจ้ง สคส. ไหม ถ้าข้อมูลลูกค้าอยู่ในชุดที่หลุด
ต้องประเมิน ถ้ารู้ว่าข้อมูลลูกค้าอยู่ในชุดที่หลุดและมีความเสี่ยงต่อสิทธิของเจ้าของข้อมูล ต้องแจ้ง สคส. ภายใน 72 ชั่วโมงนับจากรู้เหตุตาม PDPA มาตรา 37(4)
อ่านต่อ: ความรู้ที่เกี่ยวกับเรื่องนี้
- สัญญาประมวลผลข้อมูลส่วนบุคคล (ผู้ควบคุม–ผู้ประมวลผล) ต้องมีอะไรบ้าง — มาตรา 40 บังคับให้มีข้อตกลงกับผู้ประมวลผล หน้านี้รวมข้อที่ต้องเขียนเมื่อส่งข้อมูลลูกค้าให้ตัวกลาง AI หรือผู้ทำแชตบอต (ok.aipdpa.com)
- คู่มือ: วิธีเลือกใช้คลาวด์สาธารณะให้สอดคล้องแนวทาง NCSA เมื่อไรต้องใช้ศูนย์ข้อมูลในไทย — เหตุ 302.ai เกิดบนคลาวด์ต่างประเทศ คู่มือนี้ช่วยตัดสินว่าข้อมูลลูกค้าแบบไหนควรเก็บในศูนย์ข้อมูลในไทย (aipdpa.com)
แหล่งอ้างอิง
- Insurance Business (อ้างงานวิจัยของ Cybernews) — Millions of AI files exposed in leak that caught a sex doll maker’s chatbot — อ่านที่ Insurance Business
- Tech Times UK — AI Data Leak Exposes 22.7TB of Files, Including Private Chats and Sex Doll Support Logs — อ่านที่ Tech Times UK
- TechRadar — รายงานเหตุเดียวกัน (อ้างตามสรุปข่าว ไม่มีลิงก์ใน input)
บทความนี้เป็นการสรุปข่าวและให้ข้อมูลทั่วไป ไม่ใช่คำแนะนำทางกฎหมาย หากต้องการคำปรึกษาเฉพาะกรณีของธุรกิจคุณ ควรปรึกษาผู้เชี่ยวชาญ
