sarunjade_

PDPA กับแชทบอทเก็บข้อมูลลูกค้า: ขอ Consent ตรงไหนบ้าง

ถ้าธุรกิจกำลังจะให้แชทบอทเก็บชื่อ เบอร์โทร หรือข้อมูลอื่นของลูกค้า คำถามที่ต้องตอบให้ได้ก่อนคือ "ต้องขอ consent ตอนไหน" — คำตอบสั้นๆ คือ

ต้องขอความยินยอมก่อนหรือขณะเก็บข้อมูล ไม่ใช่หลังจากเก็บไปแล้ว

และต้องบอกลูกค้าด้วยว่าจะเก็บข้อมูลอะไร เอาไปทำอะไร ก่อนที่บอทจะถามคำถามแรกที่เก็บข้อมูลส่วนบุคคล

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

บทความนี้จะพาไล่ดูทีละจุดว่าในขั้นตอนสนทนาของแชทบอท ต้องขอ consent ตรงไหนบ้าง เก็บอะไรได้ไม่ได้ และกรณีข้อมูลอ่อนไหว (เช่นบอทคลินิก) ต้องระวังอะไรเพิ่ม

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

สารบัญ

PDPA คืออะไร ทำไมแชทบอทที่เก็บข้อมูลลูกค้าต้องสนใจ

PDPA (พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562) คือกฎหมายไทยที่กำหนดว่าธุรกิจต้องขอความยินยอมจากเจ้าของข้อมูลก่อนเก็บ ใช้ หรือเปิดเผยข้อมูลส่วนบุคคล เว้นแต่จะมีฐานทางกฎหมายอื่นรองรับ

(สรุปสาระสำคัญ PDPA, สภาดิจิทัลเพื่อเศรษฐกิจและสังคมแห่งประเทศไทย)

แชทบอทที่เก็บชื่อ เบอร์โทร อีเมล หรือแม้แต่ที่อยู่จัดส่งของลูกค้าเข้า Google Sheet หรือ CRM ก็เข้าข่าย "ผู้ควบคุมข้อมูลส่วนบุคคล" ตามกฎหมายนี้ทันที ไม่ว่าธุรกิจจะเล็กหรือใหญ่แค่ไหน

ประเด็นที่มักเข้าใจผิดคือคิดว่า "ธุรกิจเล็ก ยอดขายไม่เยอะ คงไม่ถูกตรวจ"

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

แชทบอทเพจร้านขายของเล็กๆ ที่ให้ลูกค้าพิมพ์ชื่อ-ที่อยู่เพื่อจัดส่งสินค้า ก็เข้าเกณฑ์เดียวกับระบบ CRM ขององค์กรใหญ่ ต่างกันแค่ปริมาณข้อมูลและความเสี่ยงถ้าเกิดปัญหา

ในทางปฏิบัติ ความแตกต่างของ "ผู้ควบคุมข้อมูล" (data controller) กับ "ผู้ประมวลผลข้อมูล" (data processor) ก็มีผลกับความรับผิดชอบ

ถ้าธุรกิจเป็นคนตัดสินใจว่าจะเก็บข้อมูลอะไร เอาไปทำอะไร ธุรกิจคือผู้ควบคุมข้อมูล ต้องรับผิดชอบเรื่องการขอ consent เอง

แม้จะจ้างบริษัทภายนอกมาสร้างแชทบอทให้ก็ตาม ผู้พัฒนาระบบเป็นเพียงผู้ประมวลผลข้อมูลแทนธุรกิจเท่านั้น

หน้าที่ขอ consent ที่ถูกต้องยังคงเป็นของเจ้าของธุรกิจ

ทำไมเรื่องนี้สำคัญ — ความเสี่ยงถ้าปล่อยให้บอทเก็บข้อมูลโดยไม่ขอ consent

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

(PDPA Focus: เรื่องของ "ความยินยอม", pdpathailand.com)

และในทางปฏิบัติ ความเสี่ยงที่พบบ่อยกว่าโทษทางกฎหมายคือความไม่ไว้ใจของลูกค้าเอง — ลูกค้าที่รู้สึกว่าบอท "ขอเบอร์โทรแบบไม่บอกเหตุผล" มักเลิกคุยกลางคัน ซึ่งกระทบอัตราการปิดการขายโดยตรง

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

มองในมุมของคนออกแบบระบบ ความเสี่ยงแบ่งได้เป็นสามชั้นที่ต่างกัน ชั้นแรกคือความเสี่ยงทางกฎหมายตรงๆ (โทษแพ่ง อาญา ปกครองตามที่กล่าวไว้ในคำถามท้ายบทความ)

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

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

ทำให้ต้องขอ consent ใหม่ทั้งฐานข้อมูล ซึ่งเสียเวลาและอัตราตอบกลับจะต่ำกว่าการขอตั้งแต่ต้นทางมาก

ธุรกิจที่วางระบบขอ consent ถูกต้องตั้งแต่แรกจึงประหยัดทั้งความเสี่ยงและต้นทุนในระยะยาว

หลักการตาม PDPA คือ ต้องขอความยินยอม "ก่อนหรือขณะ" เก็บรวบรวมข้อมูล พร้อมแจ้งวัตถุประสงค์ของการเก็บไปพร้อมกัน (Thailand Issues Guidelines on PDPA Consent and Notification Requirements, Tilleke & Gibbins)

แปลงเป็นขั้นตอนแชทบอทจริงคือ:

  • ก่อนบอทถามคำถามแรกที่เป็นข้อมูลส่วนบุคคล (ชื่อ เบอร์โทร อีเมล ที่อยู่) ต้องมีข้อความขอความยินยอมคั่นก่อนเสมอ — ไม่ใช่ถามชื่อ-เบอร์ไปพร้อมกับคำทักทายแรก
  • ข้อความขอ consent ต้องแยกจากเนื้อหาอื่น อ่านเข้าใจง่าย ไม่ใช่ซ่อนอยู่ในข้อความยาวๆ ที่ลูกค้าไม่ทันอ่าน (Consent Requirements under Thailand's Data Protection Framework, Securiti)
  • ถ้าลูกค้าปฏิเสธหรือไม่ตอบ บอทต้องหยุดเก็บข้อมูลจุดนั้น ไม่ใช่ถามซ้ำจนกว่าลูกค้าจะยอม

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

บอทสามารถทักทายลูกค้า อธิบายว่าทำอะไรได้บ้าง และถามความต้องการเบื้องต้น (เช่น "สนใจสอบถามเรื่องอะไรคะ") ได้โดยยังไม่ต้องขอ consent เพราะยังไม่ได้เก็บข้อมูลส่วนบุคคล

จุดที่ต้องแทรกข้อความขอ consent คือขั้นตอนถัดไปทันทีที่บอทกำลังจะถาม "ชื่อ-เบอร์โทร" เพื่อบันทึกเข้าระบบ ไม่ใช่ก่อนหน้านั้น

การแทรกเร็วเกินไป (เช่นขอ consent ตั้งแต่ข้อความทักทายแรกก่อนลูกค้ารู้ด้วยซ้ำว่าจะคุยเรื่องอะไร) มักทำให้ลูกค้ารู้สึกสะดุดและหลุดออกจากบทสนทนาไปเลยโดยไม่จำเป็น

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

ถ้าทั้งสองรอบเป็นวัตถุประสงค์เดียวกันที่แจ้งไว้ตั้งแต่ต้น (เช่น "เพื่อดำเนินการสั่งซื้อ") ไม่จำเป็นต้องขอ consent ซ้ำทุกรอบ

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

ข้อมูลทั่วไป (ชื่อ เบอร์โทร อีเมล) เก็บได้เมื่อขอความยินยอมแบบทั่วไปและแจ้งวัตถุประสงค์ชัดเจนแล้ว

แต่ข้อมูลอ่อนไหว เช่น ข้อมูลสุขภาพ ข้อมูลการเงิน หรือข้อมูลชีวมิติ ต้องได้รับ "ความยินยอมโดยชัดแจ้ง" (explicit consent) ซึ่งเข้มกว่าความยินยอมทั่วไป (Securiti: Consent Requirements under Thailand's Data Protection Framework)

ตัวอย่างที่พบบ่อยในงานแชทบอท:

  • แชทบอทร้านค้าออนไลน์เก็บชื่อ-ที่อยู่จัดส่ง — ข้อมูลทั่วไป ขอ consent แบบมาตรฐานพอ
  • แชทบอทคลินิกความงามหรือคลินิกเสริมความงามที่ถามอาการ ประวัติการรักษา หรือรับรูปภาพใบหน้าเพื่อคัดกรองก่อนพบแพทย์ — เข้าข่ายข้อมูลสุขภาพ ต้องขอ explicit consent แยกต่างหาก ไม่ใช้ consent ก้อนเดียวกับการเก็บชื่อ-เบอร์โทรทั่วไป

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

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

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

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

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

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

แนวทางที่ PDPC (สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล) วางไว้ระบุว่าความยินยอมต้องมาจาก "การกระทำที่ชัดแจ้ง" เช่น การกดปุ่มยืนยัน การติ๊กช่องยินยอม หรือการตอบข้อความยืนยันอย่างชัดเจน ไม่ใช่การนิ่งเฉยหรือไม่ตอบ

(Thailand Issues Guidelines on PDPA Consent and Notification Requirements, Tilleke & Gibbins)

ในหน้าแชทบอทจริง ทำได้หลายรูปแบบ:

  • ปุ่มกดยืนยัน "ยินยอม / ไม่ยินยอม" ก่อนบอทถามข้อมูลส่วนบุคคล
  • ข้อความสั้นๆ แจ้งวัตถุประสงค์ พร้อมลิงก์ไปหน้านโยบายความเป็นส่วนตัวแบบเต็ม ให้ลูกค้ากดยืนยันรับทราบ
  • เก็บ log ว่าลูกค้ายืนยันความยินยอมเมื่อไหร่ ผ่านช่องทางไหน เพื่อใช้อ้างอิงย้อนหลังได้หากถูกตรวจสอบ

จุดสำคัญที่มักถูกมองข้าม: การขอความยินยอมต้องแยกเป็นเรื่องๆ ตามวัตถุประสงค์

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

ในแง่กลไกทางเทคนิค การขอ consent ผ่านแชทบอทมีข้อจำกัดที่หน้าเว็บทั่วไปไม่มี เช่น บนแพลตฟอร์มแชทอย่าง LINE หรือ Facebook Messenger การแสดงผลเป็น "ปุ่มกด" (quick reply หรือ template button) ทำได้ง่ายและนับเป็นการกระทำที่ชัดแจ้งตามเกณฑ์

แต่ถ้าออกแบบให้ลูกค้าต้อง "พิมพ์คำว่ายินยอม" เองจะมีความเสี่ยงเรื่องการตีความคำตอบผิด (เช่นลูกค้าพิมพ์ "ครับ" หรือ "ok" ซึ่งกำกวมกว่าการกดปุ่มที่มีค่าตายตัว)

แนวทางที่ปลอดภัยกว่าคือใช้ปุ่มกดที่มีค่าแน่นอนเสมอเมื่อแพลตฟอร์มรองรับ และเก็บ log แบบมีโครงสร้าง (เช่น timestamp, user id, ข้อความ consent เวอร์ชันที่แสดงตอนนั้น, ปุ่มที่กด) แทนการเก็บแค่ข้อความดิบ

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

ควรหลีกเลี่ยงรูปแบบที่เข้าข่าย "dark pattern" ด้วย เช่น ปุ่ม "ยินยอม" ตัวใหญ่เด่น ส่วนปุ่ม "ไม่ยินยอม" ทำให้เล็กหรือซ่อนไว้ในข้อความ หรือออกแบบให้กดข้าม (skip) แล้วนับเป็นการยินยอมโดยปริยาย

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

ลูกค้ามีสิทธิถอนความยินยอมได้ทุกเมื่อ และขั้นตอนการถอนต้องง่ายพอๆ กับตอนที่ให้ความยินยอมไว้ตั้งแต่แรก (Securiti: Consent Requirements under Thailand's Data Protection Framework)

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

แล้วมีขั้นตอน (อัตโนมัติหรือให้แอดมินดำเนินการ) ลบข้อมูลออกจาก Google Sheet หรือ CRM ที่บอทเชื่อมอยู่ ไม่ใช่แค่รับคำขอแล้วเงียบไป

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

อาจมีทั้งใน Google Sheet ที่ใช้บันทึกออเดอร์ ใน CRM ที่ใช้ติดตามลูกค้า ใน log การสนทนาดิบที่เก็บไว้เพื่อ debug ระบบ และบางครั้งอยู่ใน log ของแพลตฟอร์มส่งข้อความเอง (เช่น LINE, Facebook) ซึ่งธุรกิจควบคุมไม่ได้โดยตรง

เวลาออกแบบขั้นตอนลบข้อมูล ควรทำรายการให้ชัดว่าข้อมูลลูกค้าไหลไปเก็บที่ไหนบ้างตั้งแต่ตอนออกแบบระบบ ไม่ใช่มาไล่หาตอนลูกค้าขอลบจริง

เพราะจุดที่ตกหล่นบ่อยที่สุดคือ log การสนทนาดิบที่ไม่มีใครนึกถึงตอนออกแบบตั้งแต่แรก

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

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

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

ก่อนปล่อยแชทบอทที่เก็บข้อมูลลูกค้าให้ใช้งานจริง ใช้เช็กลิสต์นี้ไล่ตรวจทีละข้อ ถ้าตอบ "ไม่ใช่" หรือ "ไม่แน่ใจ" ข้อไหน ควรแก้ก่อนเปิดใช้งาน:

  1. บอทถามชื่อ-เบอร์โทร-ที่อยู่ก่อนมีข้อความขอ consent หรือไม่ — ลองไล่บทสนทนาตั้งแต่ข้อความแรกจนถึงจุดที่บอทเก็บข้อมูลชิ้นแรก ถ้ามีคำถามที่เก็บข้อมูลส่วนบุคคลก่อนข้อความขอความยินยอม ต้องแก้ทันที นี่คือจุดที่ธุรกิจส่วนใหญ่พลาดที่สุด
  2. ข้อความขอ consent บอกวัตถุประสงค์ชัดเจนหรือไม่ — อ่านข้อความขอ consent ของบอทตัวเองแล้วถามว่า "ลูกค้าจะรู้ไหมว่าข้อมูลนี้เอาไปทำอะไร" ถ้าเขียนแค่ "ยินยอมให้เก็บข้อมูล" โดยไม่ระบุวัตถุประสงค์ ถือว่ายังไม่ครบ
  3. ถ้าบอทเก็บข้อมูลเพื่อหลายวัตถุประสงค์ (ติดต่อกลับ + ส่งโปรโมชัน) แยกขอ consent เป็นข้อๆ หรือไม่ — ถ้ารวมเป็นปุ่มยินยอมเดียวครอบคลุมทุกวัตถุประสงค์ ต้องแยกใหม่ให้ลูกค้าเลือกได้เป็นข้อๆ
  4. มีปุ่ม "ไม่ยินยอม" ที่มองเห็นชัดเจนพอๆ กับปุ่ม "ยินยอม" หรือไม่ — ตรวจว่าปุ่มปฏิเสธไม่ได้ถูกซ่อนหรือทำให้เล็กจนสังเกตยาก และถ้าลูกค้ากด "ไม่ยินยอม" บอทตอบสนองถูกต้องหรือไม่ (หยุดเก็บข้อมูล ไม่ใช่ถามซ้ำ)
  5. มีการเก็บ log ว่าลูกค้ายินยอมเมื่อไหร่ ผ่านช่องทางไหน เวอร์ชันข้อความไหน หรือไม่ — ถ้าระบบหลังบ้านไม่มีบันทึกนี้เลย เมื่อถูกตรวจสอบภายหลังจะไม่มีหลักฐานอ้างอิง ควรมีอย่างน้อย timestamp และ user id ที่ผูกกับการกดยินยอม
  6. ถ้าเก็บข้อมูลอ่อนไหว (สุขภาพ การเงิน ชีวมิติ) มีขั้นตอนขอ explicit consent แยกจาก consent ทั่วไปหรือไม่ — เช็กเฉพาะกับบอทสายคลินิก ความงาม หรือการเงิน ว่าไม่ได้ใช้ปุ่มยินยอมเดียวกันกับการเก็บชื่อ-เบอร์โทรทั่วไป
  7. มีช่องทางให้ลูกค้าขอถอน consent หรือขอลบข้อมูลผ่านแชทได้โดยตรงหรือไม่ — ลองพิมพ์คำขอถอน consent เข้าไปในบอทจริงแล้วดูว่าบอทตอบสนองอย่างไร ถ้าบอทไม่เข้าใจคำสั่งเลยหรือเงียบไป ต้องเพิ่ม flow นี้
  8. ทำรายการไว้หรือยังว่าข้อมูลลูกค้าไหลไปเก็บที่ไหนบ้าง (Sheet, CRM, log การสนทนา) — ถ้ายังไม่เคยทำรายการนี้ ควรทำก่อน เพราะเป็นจุดเดียวที่ทำให้ตอบคำขอลบข้อมูลได้ครบจริง ไม่ตกหล่น

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

โดยบอทจะถาม (1) ชื่อ-เบอร์โทรเพื่อติดต่อกลับยืนยันนัด (2) อาการที่ลูกค้ากังวล และ (3) ขอรูปภาพผิวหน้าบริเวณที่มีปัญหาเพื่อให้แพทย์ดูก่อนนัดจริง

ถ้าใช้กรอบจากบทความนี้ไล่ทีละขั้น จะวางบทสนทนาได้ประมาณนี้:

  • ขั้นที่ 1 — ก่อนถามข้อมูลใดๆ: บอททักทายและอธิบายว่า "ระบบนี้จะช่วยคัดกรองอาการเบื้องต้นก่อนนัดพบแพทย์" ยังไม่ต้องขอ consent เพราะยังไม่ได้เก็บข้อมูลส่วนบุคคล
  • ขั้นที่ 2 — ก่อนถามชื่อ-เบอร์โทร: ต้องแทรกข้อความขอ consent แบบทั่วไปก่อน ระบุวัตถุประสงค์ชัดเจนว่า "เก็บชื่อ-เบอร์โทรเพื่อติดต่อยืนยันนัดหมายเท่านั้น" พร้อมปุ่ม "ยินยอม / ไม่ยินยอม" ที่มองเห็นเท่ากัน ถ้าลูกค้ากด "ไม่ยินยอม" บอทต้องหยุดและแนะนำให้โทรจองคิวแทน ไม่ใช่ถามซ้ำ
  • ขั้นที่ 3 — ก่อนถามอาการและขอรูปภาพ: นี่คือจุดที่ต้องแยกขอ explicit consent ต่างหาก เพราะเข้าข่ายข้อมูลสุขภาพ ข้อความต้องระบุให้ชัดกว่าขั้นที่ 2 เช่น "ข้อมูลอาการและรูปภาพนี้จะถูกส่งให้แพทย์ผู้ดูแลเท่านั้น เพื่อประเมินก่อนวันนัด และจะเก็บไว้ไม่เกิน [ระยะเวลาที่ร้านกำหนด]" ปุ่มยินยอมของขั้นนี้ต้องแยกจากปุ่มขั้นที่ 2 — ลูกค้าอาจยินยอมให้เบอร์โทรแต่ปฏิเสธการส่งรูปภาพ ระบบต้องรองรับกรณีนี้ได้ เช่น ให้นัดได้โดยไม่ต้องส่งรูป แล้วให้แพทย์ประเมินหน้างานแทน
  • ขั้นที่ 4 — บันทึก log: ทุกครั้งที่ลูกค้ากดยินยอมในขั้นที่ 2 และ 3 ระบบหลังบ้านบันทึก timestamp, user id, และเวอร์ชันข้อความ consent ที่แสดง ณ ตอนนั้น แยกเป็นสองบันทึกเพราะเป็นสองวัตถุประสงค์ที่ต่างกัน
  • ขั้นที่ 5 — เผื่อกรณีลูกค้าขอถอนภายหลัง: ถ้าลูกค้าทักกลับมาขอลบรูปภาพหลังจากพบแพทย์แล้ว ทีมงานต้องรู้ว่ารูปภาพนั้นถูกส่งต่อไปเก็บที่ไหนบ้าง (เช่น ในระบบแชท ในโฟลเดอร์ที่แพทย์ใช้ดูเคส) เพื่อลบให้ครบทุกจุดตามที่ทำรายการไว้ล่วงหน้าในเช็กลิสต์ข้อ 8

จากตัวอย่างสมมตินี้จะเห็นว่า

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

ไม่ใช่รวบทุกอย่างไว้ในปุ่มเดียวตั้งแต่ต้นบทสนทนา

คำถามที่พบบ่อย

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

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

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

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

แชทบอทคลินิกที่ถามอาการหรือรับรูปภาพลูกค้า ต้องขอ consent ต่างจากบอททั่วไปไหม ต่างกัน — ข้อมูลสุขภาพจัดเป็นข้อมูลอ่อนไหวตาม PDPA ต้องขอ "ความยินยอมโดยชัดแจ้ง" แยกต่างหาก ไม่รวมกับการขอ consent เก็บชื่อ-เบอร์โทรทั่วไป

ไม่ขอ consent ก่อนเก็บข้อมูล มีโทษอะไรบ้าง กฎหมายกำหนดโทษไว้ทั้งทางแพ่ง อาญา และปกครอง ขึ้นอยู่กับลักษณะการฝ่าฝืน รายละเอียดควรตรวจสอบกับที่ปรึกษากฎหมายหรือแนวปฏิบัติของ PDPC โดยตรงสำหรับกรณีเฉพาะของแต่ละธุรกิจ

หมายเหตุสำคัญ

บทความนี้เป็นแนวทางปฏิบัติระดับผู้ทำระบบแชทบอท (practitioner-level guidance) สรุปจากแหล่งอ้างอิงสาธารณะเกี่ยวกับ PDPA ไม่ใช่คำแนะนำทางกฎหมาย (not legal advice)

หากธุรกิจมีข้อมูลอ่อนไหวหรือมีความเสี่ยงเฉพาะกรณี ควรปรึกษาที่ปรึกษากฎหมายด้าน PDPA โดยตรงก่อนออกแบบขั้นตอนขอความยินยอมจริง

เขียนโดย: Jade (Sarunjade) — ผู้ออกแบบและวางระบบแชทบอท AI ให้ธุรกิจไทย ผ่านการทดสอบจริงก่อน go-live ทุกโปรเจกต์

หากธุรกิจกำลังวางระบบแชทบอทที่ต้องเก็บข้อมูลลูกค้า ดูรายละเอียดบริการที่ ระบบแชทบอท AI หรืออ่านเพิ่มเติมเรื่องการออกแบบบอทเฉพาะทางในบทความ "แชทบอทคลินิก: คัดกรองเคสก่อนหมอ vs แค่ตอบ FAQ"

อยากรู้ว่าระบบแชทบอทที่กำลังจะทำ ควรขอ consent ตรงไหนบ้างสำหรับธุรกิจของคุณโดยเฉพาะ? ทักมาคุยแบบไม่มีข้อผูกมัด