ความยินยอมและสิทธิที่จะถูกลืม

🌐 มีให้อ่านอีก 28 ภาษา

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

ภาพสร้างด้วย AI

แปลโดย AI ชุมชนยังไม่ได้ตรวจทาน อ่านเป็นภาษาอังกฤษ

โมดูลที่ 5 จาก 6 ในบท คุณภาพและธรรมาภิบาลข้อมูล บทที่ 5 ของหลักสูตร Data Architect แต่ละโมดูลอ่านแยกกันได้ ก่อนหน้า: กฎหมายความเป็นส่วนตัวกำหนดการออกแบบ · ถัดไป: ปกป้อง เก็บรักษา และพิสูจน์

คำถามที่โมดูลนี้ตอบ: คุณออกแบบเพื่อความยินยอม และเพื่อการลบข้อมูลของบุคคลได้อย่างไร?

Steve Trucking มีเบอร์โทรศัพท์ของผู้รับ คำถามง่ายๆ: เราส่งข้อความหาเขาได้ไหม? อาจได้ เรื่องการจัดส่งวันนี้? พรุ่งนี้? เราใช้เบอร์นั้นเพื่อโปรโมชันได้ไหม? ถ้าเขาบอกว่าไม่รับข้อความ หรือรับการอัปเดตการจัดส่งแต่ไม่รับการตลาด แล้วเปลี่ยนใจล่ะ?

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

ความยินยอมคือข้อมูล

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

ใช้โมเดลที่ Salesforce สร้างไว้แล้ว

จุดยืนของผม: ใช้โมเดลความยินยอมที่มีมาให้ทุกครั้งที่ทำได้ แทนที่จะสร้างสิ่งเดียวกันใหม่ในฟิลด์ที่กำหนดเอง โมเดลข้อมูลความยินยอมของ Salesforce จัดการความยินยอมสี่ระดับ แต่ละระดับเป็นคำถามที่เจาะจงขึ้น (Understand the Salesforce Consent Data Model (opens in a new tab) ภาษาอังกฤษ):

• ความยินยอมระดับรวม บน Individual: บุคคลนี้คือใคร และเขาปฏิเสธทุกอย่างหรือไม่?
• ความยินยอมระดับช่องทาง (Contact Point Type Consent): เราใช้ช่องทางประเภทนี้ได้ไหม เช่น SMS หรืออีเมล?
• ความยินยอมระดับจุดติดต่อ (contact point): แล้วเบอร์โทรศัพท์หรือที่อยู่อีเมลเฉพาะนี้ล่ะ?
• จุดประสงค์การใช้ข้อมูล (data use purpose): ด้วยเหตุผลอะไร: การแจ้งเตือนการจัดส่ง งานบริการ การตลาด?

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

Click to enlarge

คำถามสี่ข้อ แต่ละข้อแคบกว่าข้อก่อน แฟล็ก opt-in เดียวตอบข้อใดได้ไม่ดีเลย

จุดประสงค์สำคัญ

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

และความยินยอมไม่ได้เป็นฐานทางกฎหมายเสมอไป การใช้บางอย่างอาศัยฐานอื่นที่กฎหมายกำหนด และนั่นเป็นการตัดสินของฝ่ายกฎหมาย อย่าสร้างสถาปัตยกรรมที่สมมติว่าทุกการตัดสินใจด้านความเป็นส่วนตัวคือช่องติ๊ก opt-in รองรับสิ่งที่นโยบายบอก: ถ้าการใช้หนึ่งขึ้นอยู่กับความยินยอม ก็สร้างโมเดลและบังคับใช้ความยินยอม ถ้าใช้ฐานอื่น ก็ยังเก็บสิ่งที่จำเป็นเพื่อตัดสินว่าการใช้นั้นได้รับอนุญาตหรือไม่

ความยินยอมมีวงจรชีวิตและผู้มีอำนาจชี้ขาด

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

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

ทีนี้บุคคลนั้นบอกว่า: ลืมฉันเสีย

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

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

Click to enlarge

คำขอให้ลืมคือการตัดสินใจสำหรับทุกสำเนา

นาฬิกากำลังเดิน

คำขอเหล่านี้มาพร้อมกำหนดเวลา ภายใต้ GDPR องค์กรต้องดำเนินการตามคำขอของบุคคลโดยไม่ชักช้าเกินสมควร และภายในหนึ่งเดือนนับจากที่ได้รับ สำหรับคำขอที่ซับซ้อนหรือมีจำนวนมาก ขยายได้อีกสองเดือน แต่ต้องแจ้งบุคคลนั้นภายในเดือนแรก พร้อมเหตุผล (Article 12(3), Regulation (EU) 2016/679 (opens in a new tab) ภาษาอังกฤษ) กฎหมายอื่นกำหนดเวลาของตัวเอง ฝ่ายกฎหมายจะบอกคุณว่าฉบับไหนใช้บังคับ ไม่ว่าแบบไหน หนึ่งเดือนก็ไม่นานพอจะสำรวจภาพรวมระบบ นั่นคือกำหนดเวลาที่แผนที่ของสำเนาต้องเอาชนะให้ได้

ลบ ลบการระบุตัวตน หรือเก็บไว้?

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

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

คุณลบสิ่งที่หาไม่เจอไม่ได้

ก่อนที่คุณจะลบข้อมูลของใครได้ คุณต้องหาเขาให้เจอ คำขอมาจากที่อยู่อีเมล พันธมิตรค้าปลีกรายหนึ่งส่ง “Jane Smith” อีกรายส่ง “J. Smith” และเบอร์โทรศัพท์เปลี่ยนไปแล้ว ผู้รับไม่ได้เป็นผู้ติดต่อเลย รายละเอียดของเขาอยู่บนการจัดส่งแต่ละครั้ง บุคคลเดียวกันได้รับการจัดส่งจากพันธมิตรสองรายที่ต่างกัน ระบบหนึ่งรู้จักเขาด้วยอีเมล อีกระบบด้วย external ID การลบขึ้นอยู่กับตัวตน และคุณไม่อยากลบข้อมูลของคนอื่นเพราะการจับคู่ของคุณหละหลวมเกินไป สถาปัตยกรรมตัวตนเป็นส่วนหนึ่งของสถาปัตยกรรมความเป็นส่วนตัว

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

รูปถ่ายและข้อความอิสระก็เป็นข้อมูล

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

และข้อความอิสระก็อันตราย คุณลบชื่อ เบอร์โทร และที่อยู่ แล้วไปเจอหมายเหตุการจัดส่งนี้: “โทรหา Jane ที่ 602-555-0198 รหัสประตู 4821 มีสุนัขอยู่ในสนาม” นั่นไง การจัดประเภทหมายเหตุการจัดส่งว่าอ่อนไหวบอกคุณว่าอาจมีปัญหา แต่มันไม่ได้หาและลบข้อมูลส่วนบุคคลข้างในข้อความ บางครั้งคำตอบที่ดีที่สุดคือหยุดไม่ให้รายละเอียดส่วนตัวที่ไม่จำเป็นไปลงตรงนั้นเลย ควบคุมก่อนว่าข้อมูลส่วนบุคคลไปที่ไหน

Privacy Center เป็นเครื่องมือ ไม่ใช่สถาปัตยกรรมทั้งหมด

Privacy Center ของ Salesforce ช่วยดำเนินกระบวนการเหล่านี้ นโยบายสิทธิที่จะถูกลืมของมันสร้างแยกตามออบเจกต์ เพื่อเก็บทุกอย่างที่คุณต้องการลบ และรันกับเรกคอร์ดลูกค้าเฉพาะราย (Delete Data with Right to Be Forgotten Policies (opens in a new tab) ภาษาอังกฤษ) นั่นมีประโยชน์ แต่ “เราซื้อ Privacy Center แล้ว จึงเสร็จ” ไม่ใช่สถาปัตยกรรม ข้อมูลของบุคคลนั้นอาจอยู่นอกขอบเขตของเครื่องมือใดเครื่องมือหนึ่ง: Data 360 คลังข้อมูล ระบบของพันธมิตร ที่เก็บถาวร ล็อก การค้นหา ไฟล์ บทสนทนาของเอเจนต์ องค์กรยังต้องมีคำตอบระดับองค์กร และคุณต้องตรวจว่าแต่ละเครื่องมือครอบคลุมอะไรจริงก่อนพึ่งพามัน

การโอนย้ายและการพิสูจน์

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

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

นอกเหนือจากการสอบ: AI เปลี่ยนอะไร AI สร้างจุดประสงค์ใหม่และสำเนาใหม่ การอนุญาตให้ใช้ข้อมูลเพื่อให้บริการไม่ได้ครอบคลุมการใช้เป็น grounding ของเอเจนต์ การปรับแต่งเฉพาะบุคคล หรือการฝึกโมเดลโดยอัตโนมัติ Data Use Purpose คือที่ตามธรรมชาติในการแยกสิ่งเหล่านั้น และข้อมูลส่วนบุคคลอาจอยู่รอดใน prompt บริบท grounding บทสนทนา บทสรุป ดัชนีการค้นหาและดัชนีเวกเตอร์ และล็อก “เราลบเรกคอร์ดต้นทางแล้ว” ไม่ใช่คำตอบที่ครบถ้าชั้น AI ยังจำได้อยู่

สิ่งที่สถาปนิกต้องตัดสินใจในเรื่องนี้

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

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

ศึกษาเพิ่มเติม

• Salesforce Help, Understand the Salesforce Consent Data Model (opens in a new tab) (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-14)
• Regulation (EU) 2016/679 (GDPR) (opens in a new tab), Article 12(3) กำหนดเวลาสำหรับการดำเนินการตามคำขอ (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-14)
• Salesforce Help, Delete Data with Right to Be Forgotten Policies (opens in a new tab) (Privacy Center ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-14)