10 ข้อผิดพลาดเรื่อง PDPA สำหรับเว็บไซต์ ที่เอเจนซีและฟรีแลนซ์ทำเว็บไซต์ควรหลีกเลี่ยง
หลายเอเจนซีทำเว็บไซต์เสร็จ ส่งมอบ ปิดโปรเจกต์ แล้วพบว่า Cookie Banner ที่ติดตั้งไว้ไม่ทำงานตามที่ตกลง หรือ Privacy Policy ไม่ตรงกับ Tag ที่ลูกค้าเพิ่มทีหลัง นี่คือข้อผิดพลาดที่เกิดซ้ำในงานเอเจนซี

💬 สรุปสั้น ๆ
ข้อผิดพลาดเรื่อง PDPA ที่เอเจนซีทำเว็บไซต์เจอบ่อยที่สุดไม่ใช่การลืมติด Cookie Banner แต่คือการไม่กำหนดขอบเขตความรับผิดชอบเรื่อง PDPA ไว้ในสัญญาตั้งแต่ต้น ทำให้ไม่มีใครดูแลต่อหลังส่งมอบเมื่อลูกค้าเพิ่ม Tag หรือเปลี่ยนปลั๊กอินเอง
สารบัญ
งานทำเว็บไซต์ส่วนใหญ่จบที่การส่งมอบไฟล์และปิดใบแจ้งหนี้ แต่ประเด็น PDPA ไม่ได้จบที่วันส่งมอบ เพราะเว็บไซต์ยังมี Tracking Script ทำงานต่อ ลูกค้ายังเพิ่มปลั๊กอินเองได้ และ Privacy Policy ที่เอเจนซีร่างไว้ก็อาจไม่ตรงกับสิ่งที่เว็บไซต์เก็บจริงอีกต่อไปภายในไม่กี่เดือน ข้อผิดพลาดที่รวมไว้ในบทความนี้มาจากรูปแบบงานเอเจนซีและฟรีแลนซ์ทำเว็บไซต์โดยเฉพาะ ไม่ใช่รายการทั่วไปที่ใช้ได้กับทุกธุรกิจ
ข้อผิดพลาดจากขั้นตอน Discovery และทำสัญญา
1. ไม่ระบุขอบเขตความรับผิดชอบเรื่อง PDPA ไว้ในสัญญา
สัญญาจ้างทำเว็บไซต์ส่วนใหญ่ระบุขอบเขตงานด้านดีไซน์และฟังก์ชัน แต่ไม่ระบุว่าใครรับผิดชอบเรื่อง Cookie Consent, Privacy Policy และการตรวจ Tracking Script เมื่อไม่มีข้อตกลงชัดเจน ทั้งสองฝ่ายมักเข้าใจต่างกันว่างานนี้รวมอยู่ในสโคปหรือไม่ และไม่มีใครเป็นเจ้าของงานต่อหลังส่งมอบ
2. ไม่เก็บ Business Questionnaire ก่อนเริ่มงาน
การไม่ถามลูกค้าตั้งแต่ต้นว่าเว็บไซต์จะเก็บข้อมูลอะไร ใช้ระบบ CRM หรือ Chat ตัวไหน มี Third-party Script อะไรบ้าง ทำให้ Privacy Policy ที่ร่างขึ้นภายหลังกลายเป็นแม่แบบทั่วไปที่ไม่ตรงกับธุรกิจจริง
3. ไม่แจ้งลูกค้าว่า Policy Generator เป็นจุดเริ่มต้น ไม่ใช่จบงาน
เมื่อใช้เครื่องมือช่วยร่าง Privacy Policy โดยไม่อธิบายให้ลูกค้าเข้าใจว่าต้องมีคนตรวจสอบและปรับให้ตรงกับกิจกรรมจริงของธุรกิจ ลูกค้าอาจเข้าใจผิดว่าเอกสารที่ได้พร้อมใช้งานทันทีโดยไม่ต้องทบทวนอีก
ข้อผิดพลาดจากขั้นตอนพัฒนาเว็บไซต์
4. ติดตั้ง Tag ผ่าน Google Tag Manager แบบ Hardcode ไม่ผูกกับ Consent
นักพัฒนาหลายคนติดตั้ง GTM แล้วปล่อยให้ Tag ทำงานทันทีที่หน้าโหลด โดยไม่ตั้งค่า Consent Initialization ก่อน ทำให้ Pixel การตลาดหรือ Analytics ยิงออกไปก่อนที่ผู้ใช้จะกดยินยอมด้วยซ้ำ
5. เลือกปลั๊กอิน Cookie Consent จากราคาหรือความนิยม ไม่ได้ทดสอบการบล็อก Script จริง
ปลั๊กอินบางตัวแสดง Banner ได้สวยงามแต่ไม่ได้บล็อก Script เบื้องหลังจริงเมื่อผู้ใช้กด Reject เอเจนซีที่ไม่ทดสอบ Network Log หลังติดตั้งจะไม่รู้ว่า Banner ที่ติดไปเป็นเพียงของตกแต่งหน้าเว็บ
6. ใช้ Theme หรือปลั๊กอินที่ฝัง Script ของตัวเองโดยไม่รู้ตัว
ธีมสำเร็จรูปและปลั๊กอินเสริมหลายตัวฝัง Font, Analytics หรือ Chat Widget ของตัวเองมาโดยอัตโนมัติ นักพัฒนาที่ไม่ตรวจ Network Request ทั้งหมดของเว็บไซต์ก่อนส่งมอบ อาจไม่รู้ว่ามี Script เหล่านี้ทำงานอยู่
ข้อผิดพลาดจากขั้นตอนส่งมอบและดูแลต่อเนื่อง
7. ไม่มี Retainer หรือรอบตรวจซ้ำหลังส่งมอบ
เมื่อโปรเจกต์ปิดแล้ว ไม่มีใครตรวจซ้ำว่าลูกค้าเพิ่ม Tag การตลาดใหม่ อัปเดตปลั๊กอิน หรือเปลี่ยน CRM หรือไม่ ความเสี่ยงด้าน PDPA จึงสะสมเงียบ ๆ โดยไม่มีใครรู้จนกว่าจะมีปัญหาเกิดขึ้น
8. ไม่ส่งมอบเอกสารว่าตั้งค่าอะไรไว้บ้าง
เมื่อไม่มี Handover Document ระบุว่า Cookie Category ใดถูกจัดไว้อย่างไร Consent Mode ตั้งค่าแบบไหน ทีมลูกค้าเองหรือเอเจนซีรายถัดไปที่มาดูแลต่อจะไม่รู้ว่าอะไรถูกตั้งใจทำและอะไรเป็นค่าเริ่มต้นของปลั๊กอิน
9. ไม่แยก Client Workspace เมื่อดูแลหลายเว็บไซต์พร้อมกัน
เอเจนซีที่ดูแลหลายลูกค้าพร้อมกันแล้วใช้บัญชีหรือการตั้งค่ารวมกัน เสี่ยงต่อการตั้งค่า Consent หรือ Policy ผิดเว็บ โดยเฉพาะเมื่อใช้ Template เดียวกันแล้วลืมปรับให้ตรงกับแต่ละธุรกิจ
10. ไม่แจ้งลูกค้าเรื่องขอบเขตความรับผิดชอบทางกฎหมาย
เอเจนซีสามารถติดตั้ง จัดหมวด และร่างเอกสารเบื้องต้นให้ลูกค้าได้ แต่ไม่ควรปล่อยให้ลูกค้าเข้าใจว่าการที่เอเจนซีทำงานเหล่านี้เท่ากับมีผู้เชี่ยวชาญกฎหมายรับรองความถูกต้องแล้ว หากไม่มีการตรวจจากผู้เชี่ยวชาญจริง ควรระบุขอบเขตนี้ให้ชัดเจนตั้งแต่ต้น
ทำไมข้อผิดพลาดเหล่านี้ถึงเกิดซ้ำในงานเอเจนซี
งานเอเจนซีมักมีทีมดีไซน์ นักพัฒนา และฝ่ายขายทำงานคนละช่วงเวลากัน ต่างจากทีม In-house ที่มีเจ้าของเว็บไซต์คนเดียวดูแลต่อเนื่อง เมื่อไม่มีจุดส่งต่อข้อมูลที่ชัดเจนระหว่างขั้นตอน ความรับผิดชอบเรื่อง PDPA จึงตกหล่นระหว่างรอยต่อของแต่ละขั้น คู่มือ PDPA สำหรับเว็บไซต์สำหรับเอเจนซีและฟรีแลนซ์ อธิบายภาพรวมของ Workflow ที่ควรมีไว้ตั้งแต่ต้นจนจบโปรเจกต์ ส่วนแนวทางเชิงปฏิบัติเพิ่มเติมดูได้จากBest Practices ด้าน PDPA สำหรับเว็บไซต์ของเอเจนซี
ตัวอย่างสถานการณ์ที่เจอบ่อยในงานเอเจนซี
กรณีต่อไปนี้ไม่ใช่เหตุการณ์สมมติ แต่เป็นรูปแบบที่เกิดซ้ำเมื่อโปรเจกต์ทำเว็บไซต์ผ่านหลายมือและหลายช่วงเวลา
ทีมการตลาดของลูกค้าเพิ่ม Pixel เอง
หลังส่งมอบเว็บไซต์ไปสามเดือน ทีมการตลาดของลูกค้าติดตั้ง Facebook Pixel ผ่าน Plugin เองโดยไม่แจ้งเอเจนซี Pixel ตัวนี้ไม่ได้ถูกผูกกับ Consent ที่เคยตั้งค่าไว้ ทำให้ Banner เดิมทำงานไม่ครอบคลุม Script ใหม่ที่เพิ่มเข้ามาทีหลัง
เปลี่ยนนักพัฒนาแล้วไม่มีใครรู้ว่าตั้งค่าอะไรไว้
เมื่อเอเจนซีเดิมหยุดดูแลและมีนักพัฒนาอิสระเข้ามาต่อ หากไม่มีเอกสารส่งมอบ นักพัฒนาคนใหม่มักไม่กล้าแก้ Cookie Consent เดิมเพราะไม่รู้ว่าตั้งค่าตามเจตนาเดิมหรือเป็นเพียงค่าเริ่มต้นของปลั๊กอิน สุดท้ายปล่อยผ่านไปโดยไม่มีใครตรวจซ้ำ
ลูกค้าเปลี่ยนแพ็กเกจ Hosting แล้ว Cache เก่าค้าง
การย้าย Hosting หรือเปลี่ยนปลั๊กอิน Cache บางครั้งทำให้หน้าเว็บที่ผู้ใช้เห็นเป็นเวอร์ชัน Cache เก่าที่ยังมี Banner หรือ Policy รุ่นก่อนแก้ไข ทั้งที่ฝั่งระบบจัดการเนื้อหาอัปเดตล่าสุดแล้ว จุดนี้ต้องตรวจแยกต่างหากหลัง Deploy ทุกครั้ง
พร้อมตรวจสอบความน่าเชื่อถือของเว็บไซต์คุณหรือยัง?
ทดลองใช้งาน trusty ฟรี ไม่ต้องใช้บัตรเครดิต เริ่มสแกนได้ทันที
คำถามที่พบบ่อย
เอเจนซีต้องรับผิดชอบทาง PDPA แทนลูกค้าไหม
โดยทั่วไปเจ้าของเว็บไซต์ยังเป็นผู้รับผิดชอบหลักในฐานะผู้ควบคุมข้อมูล เอเจนซีทำหน้าที่ติดตั้งและให้คำแนะนำเชิงเทคนิค ขอบเขตความรับผิดชอบที่ชัดเจนควรระบุไว้ในสัญญาตั้งแต่ต้น
ถ้าไม่มี Retainer จะป้องกันข้อผิดพลาดหลังส่งมอบได้อย่างไร
อย่างน้อยควรส่งมอบเอกสารสรุปการตั้งค่าและแนะนำให้ลูกค้าตรวจ Tag ใหม่ทุกครั้งที่เพิ่มปลั๊กอินหรือ Third-party Script แม้จะไม่มีสัญญาดูแลต่อเนื่องก็ตาม
ปลั๊กอิน Cookie Consent ราคาถูกใช้ได้ไหม
ใช้ได้ถ้าทดสอบแล้วว่าบล็อก Script จริงตามที่ผู้ใช้เลือก ราคาไม่ใช่ตัวชี้วัดว่าปลั๊กอินทำงานถูกต้อง ต้องทดสอบ Network Log ก่อนส่งมอบทุกครั้ง
เช็กลิสต์ปฏิบัติ
- ระบุขอบเขตความรับผิดชอบเรื่อง PDPA ไว้ในสัญญาก่อนเริ่มงานทุกโปรเจกต์
- เก็บ Business Questionnaire เรื่องข้อมูลที่เว็บไซต์จะเก็บก่อนร่าง Privacy Policy
- ทดสอบ Network Log ว่า Cookie Consent บล็อก Script จริงหลังผู้ใช้กด Reject
- ตั้งค่า Consent Initialization ใน GTM ก่อน Tag เริ่มทำงาน
- ตรวจ Theme และปลั๊กอินทั้งหมดว่าฝัง Script อะไรมาโดยอัตโนมัติ
- ส่งมอบเอกสารสรุปการตั้งค่า Cookie Category และ Consent Mode ให้ลูกค้า
- แยก Client Workspace ให้ชัดเจนเมื่อดูแลหลายเว็บไซต์พร้อมกัน
ข้อผิดพลาดที่พบบ่อย
- ใช้ Privacy Policy Template เดิมกับลูกค้าหลายรายโดยไม่ปรับให้ตรงกับธุรกิจแต่ละราย
- ลืมแจ้งลูกค้าว่าเมื่อเพิ่ม Tag การตลาดใหม่ต้องอัปเดต Cookie Inventory ด้วย
- ปิดโปรเจกต์โดยไม่มีใบส่งมอบระบุว่า Consent Banner ตั้งค่าหมวดใดไว้อย่างไร
- ไม่ทดสอบ Reject All บนอุปกรณ์มือถือ ทำให้พลาดปัญหาที่เกิดเฉพาะบน Mobile
สรุป
ข้อผิดพลาดเรื่อง PDPA ของเอเจนซีทำเว็บไซต์ส่วนใหญ่ไม่ได้เกิดจากความไม่รู้เรื่องกฎหมาย แต่เกิดจากช่องว่างของ Workflow ระหว่างขั้นตอนทำสัญญา พัฒนา และส่งมอบ การกำหนดขอบเขตความรับผิดชอบและทดสอบ Script จริงก่อนส่งมอบทุกครั้งช่วยลดความเสี่ยงเหล่านี้ได้อย่างเป็นระบบ
แหล่งข้อมูลอ้างอิง
คำถามที่พบบ่อย
เอเจนซีต้องรับผิดชอบทาง PDPA แทนลูกค้าไหม
โดยทั่วไปเจ้าของเว็บไซต์ยังเป็นผู้รับผิดชอบหลักในฐานะผู้ควบคุมข้อมูล เอเจนซีทำหน้าที่ติดตั้งและให้คำแนะนำเชิงเทคนิค ขอบเขตความรับผิดชอบที่ชัดเจนควรระบุไว้ในสัญญาตั้งแต่ต้น
ถ้าไม่มี Retainer จะป้องกันข้อผิดพลาดหลังส่งมอบได้อย่างไร
อย่างน้อยควรส่งมอบเอกสารสรุปการตั้งค่าและแนะนำให้ลูกค้าตรวจ Tag ใหม่ทุกครั้งที่เพิ่มปลั๊กอินหรือ Third-party Script แม้จะไม่มีสัญญาดูแลต่อเนื่องก็ตาม
ปลั๊กอิน Cookie Consent ราคาถูกใช้ได้ไหม
ใช้ได้ถ้าทดสอบแล้วว่าบล็อก Script จริงตามที่ผู้ใช้เลือก ราคาไม่ใช่ตัวชี้วัดว่าปลั๊กอินทำงานถูกต้อง ต้องทดสอบ Network Log ก่อนส่งมอบทุกครั้ง
บทความที่เกี่ยวข้อง (Related Articles)
ดูบทความอื่นในหมวด Privacy Fundamentalsรวมคู่มือและเช็กลิสต์ที่เกี่ยวข้องกับหัวข้อนี้ใน Trusty Knowledge Centerอ่านต่อในหัวข้อเดียวกัน

อัปเดต PDPA สำหรับเว็บไซต์ ปี 2026: สิ่งที่เอเจนซีและฟรีแลนซ์ทำเว็บไซต์ต้องทบทวน
ทีมพัฒนาเว็บไซต์ที่วางระบบ PDPA ไว้เมื่อสองปีก่อนอาจไม่ทันประกาศและแนวปฏิบัติล่าสุด บทความนี้สรุปสิ่งที่เอเจนซีต้องทบทวนใหม่ในปี 2026

วิธี Audit PDPA สำหรับเว็บไซต์ ของเอเจนซีและฟรีแลนซ์ทำเว็บไซต์ พร้อม Evidence ที่ควรเก็บ
เอเจนซีจำนวนมากส่งมอบเว็บไซต์แล้วปล่อยผ่านเรื่อง PDPA ไปเลย คู่มือนี้อธิบายวิธี Audit PDPA สำหรับเว็บไซต์ลูกค้าแบบเป็นระบบ พร้อม Evidence ที่ควรเก็บไว้ทุกรอบตรวจ
เนื้อหานี้จัดทำขึ้นเพื่อให้ข้อมูลทั่วไปเท่านั้น ไม่ถือเป็นคำแนะนำทางกฎหมาย กรุณาปรึกษาผู้เชี่ยวชาญด้านกฎหมายหรือ Data Protection Officer ของหน่วยงานท่านก่อนนำไปปฏิบัติจริง
พร้อมตรวจสอบความน่าเชื่อถือของเว็บไซต์คุณหรือยัง?
ทดลองใช้งาน trusty ฟรี ไม่ต้องใช้บัตรเครดิต เริ่มสแกนได้ทันที