กฎหมายความเป็นส่วนตัวกำหนดการออกแบบ

🌐 มีให้อ่านอีก 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 ชุมชนยังไม่ได้ตรวจทาน อ่านเป็นภาษาอังกฤษ

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

คำถามที่โมดูลนี้ตอบ: กฎหมายความเป็นส่วนตัวและกฎระเบียบอุตสาหกรรมเรียกร้องอะไรจากการออกแบบ Salesforce?

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

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

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

กฎหมายไม่ได้หยุดที่พรมแดน

ความเข้าใจผิดที่ใหญ่ที่สุดก่อน: “เราไม่ได้อยู่ในยุโรป GDPR จึงไม่ใช้บังคับ” อาจใช่ อาจไม่ ขอบเขตทางอาณาเขตของ GDPR เอื้อมไปถึงองค์กรนอก EU ที่เสนอสินค้าหรือบริการให้คนใน EU หรือเฝ้าติดตามพฤติกรรมของพวกเขาที่นั่น (มาตรา 3, Regulation (EU) 2016/679 (opens in a new tab) ภาษาอังกฤษ) ดังนั้นสำนักงานใหญ่ของบริษัทอยู่ที่ไหนจึงไม่ใช่จุดจบของคำถาม ลูกค้า พนักงาน คนที่คุณถือข้อมูลอยู่ ระบบของคุณ ผู้ประมวลผลของคุณอยู่ที่ไหน? ข้อมูลเดินทางไปที่ไหน? นั่นคือภาพรวมระบบของบทที่ 4 อีกครั้ง คุณตัดสินใจเรื่องความเป็นส่วนตัวได้ดีไม่ได้ถ้าไม่รู้ว่าข้อมูลไปที่ไหน

กฎระเบียบที่คุณควรรู้จัก

นี่คือชื่อที่สถาปนิกควรรู้ พร้อมสิ่งที่แต่ละฉบับครอบคลุม มันเป็นตารางให้รู้จัก ไม่ใช่เมทริกซ์การบังคับใช้: อย่าอ่านแล้วตัดสินว่า “เรามีลูกค้าในแคลิฟอร์เนีย ข้อกำหนด X จึงใช้บังคับ” นั่นเป็นการตัดสินของฝ่ายกฎหมาย งานของคุณคือรู้มากพอจะถามคำถามก่อนที่ระบบจะถูกสร้าง

กฎหมายหรือมาตรฐาน	ที่ไหนหรืออะไร	ทำไมสถาปนิกควรรู้จัก
GDPR (opens in a new tab)	สหภาพยุโรป	ข้อมูลส่วนบุคคล การประมวลผลที่ชอบด้วยกฎหมาย สิทธิของบุคคล การเก็บรักษา การโอน ความเป็นส่วนตัวตั้งแต่การออกแบบ
CCPA ตามที่แก้ไขโดย CPRA (opens in a new tab)	แคลิฟอร์เนีย	สิทธิของผู้บริโภคเหนือข้อมูลส่วนบุคคลที่ธุรกิจเก็บเกี่ยวกับพวกเขา
PIPEDA (opens in a new tab)	แคนาดา	วิธีที่องค์กรภาคเอกชนจัดการข้อมูลส่วนบุคคล
LGPD (opens in a new tab)	บราซิล	กฎหมายทั่วไปว่าด้วยการคุ้มครองข้อมูลส่วนบุคคลของบราซิล
Privacy Act 1988 (opens in a new tab)	ออสเตรเลีย	วิธีที่องค์กรจัดการข้อมูลส่วนบุคคล ภายใต้ Australian Privacy Principles
HIPAA (opens in a new tab)	การดูแลสุขภาพในสหรัฐฯ	ข้อมูลสุขภาพที่ได้รับการคุ้มครองในบริบทที่ครอบคลุม
PCI DSS (opens in a new tab)	บัตรชำระเงิน	การปกป้องข้อมูลบัญชีบัตรชำระเงิน
Sarbanes-Oxley (SOX) (opens in a new tab)	บริษัทมหาชนในสหรัฐฯ	การควบคุมและหลักฐานเบื้องหลังการรายงานทางการเงิน
COPPA (opens in a new tab)	สหรัฐฯ เด็กบนโลกออนไลน์	ข้อมูลส่วนบุคคลที่เก็บทางออนไลน์จากเด็ก

รายการนี้ยาวขึ้นเรื่อยๆ (รัฐในสหรัฐฯ มีกฎหมายของตัวเองมากขึ้น) และกฎหมายก็เปลี่ยน นั่นคือเหตุผลที่ผมไม่อยากให้คุณท่องจำตารางแล้วคิดว่าได้เรียนสถาปัตยกรรมความเป็นส่วนตัวแล้ว เรียนรู้ชื่อ แล้วเรียนรู้คำถามที่อยู่ได้นานกว่ามัน

สิ่งที่กฎหมายเหล่านี้มีร่วมกัน

รายละเอียดต่างกัน แต่กฎหมายความเป็นส่วนตัวฉบับใหญ่ๆ วนกลับมาที่เรื่องเดิมไม่กี่เรื่อง และแต่ละเรื่องก็ตกลงบนสถาปัตยกรรม

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

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

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

ความรับผิดชอบ (accountability) คุณต้องแสดงได้ว่าปฏิบัติตามกฎ: บันทึกว่าคุณประมวลผลอะไรและทำไม การประเมินผลกระทบสำหรับการประมวลผลที่มีความเสี่ยงสูง และภายใต้ GDPR และ LGPD ต้องมีเจ้าหน้าที่คุ้มครองข้อมูลส่วนบุคคล (DPO) สถาปัตยกรรมต้องผลิตบันทึกเหล่านั้นออกมาได้

เริ่มจากสิ่งที่เป็นข้อมูลส่วนบุคคล

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

มันอยู่ที่ไหน?

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

Click to enlarge

เบอร์โทรศัพท์เดียว หลายสำเนา ความเป็นส่วนตัวใช้กับสำเนาด้วย

ทำไมคุณจึงได้รับอนุญาตให้ใช้มัน?

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

การเก็บน้อยลงคือการตัดสินใจทางสถาปัตยกรรม

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

การเก็บรักษาเป็นส่วนหนึ่งของโมเดล

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

นิรนาม แฝง เข้ารหัส ปิดบัง

แทน “Jane Smith” ด้วย 7F92A1 Jane กลายเป็นนิรนามหรือยัง? ไม่ ถ้าอีกตารางยังบอกว่า 7F92A1 = Jane Smith นั่นคือการแฝงข้อมูล (pseudonymization): ตัวระบุโดยตรงถูกแทนที่ แต่ข้อมูลยังเชื่อมโยงกลับได้ด้วยข้อมูลที่เก็บแยกไว้ และภายใต้ GDPR ข้อมูลแฝงยังเป็นข้อมูลส่วนบุคคล (มาตรา 4(5)) การทำให้เป็นข้อมูลนิรนาม (anonymization) ไปไกลกว่านั้น: ข้อมูลไม่สามารถเชื่อมโยงกับบุคคลได้อย่างสมเหตุสมผลอีกต่อไป (บทนำข้อ 26 หรือ Recital 26) ดังนั้นเมื่อมีคนพูดว่า “เราไม่ต้องลบหรอก แค่เอาชื่อออก” ให้ระวัง ถ้ายังระบุตัวบุคคลได้อย่างสมเหตุสมผล คุณยังไม่ได้ข้ามเส้นนั้น ผลลัพธ์จะเป็นไปตามกฎหมายหรือไม่เป็นการตัดสินของฝ่ายกฎหมาย งานของสถาปนิกคือบอกให้ชัดว่าระบบทำอะไร: เชื่อมโยงกลับได้ไหม คีย์อะไรยังเหลืออยู่ การจับคู่อยู่ที่ไหน?

ใช้คำให้แม่นยำ เพราะมันแก้ปัญหาต่างกัน การเข้ารหัสปกป้องข้อมูลจากการเปิดเผยโดยไม่ได้รับอนุญาต ผู้ใช้ที่ได้รับอนุญาตยังถอดรหัสได้ การปิดบัง (masking) เปลี่ยนสิ่งที่ผู้ใช้หรือสภาพแวดล้อมบางกลุ่มเห็น การแฝงข้อมูลแยกตัวตนโดยตรงออกไปโดยยังมีทางกลับ การทำให้เป็นข้อมูลนิรนามลบความสามารถในการระบุตัวบุคคลอย่างสมเหตุสมผล มีแค่อย่างสุดท้ายที่นำข้อมูลออกจากความเป็น “ข้อมูลส่วนบุคคล”

กฎระเบียบกลายเป็นข้อกำหนด

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

Click to enlarge

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

และการปฏิบัติตามกฎไม่ใช่ผลิตภัณฑ์ คุณซื้อ “compliance: เปิด” ไม่ได้ การเข้ารหัสสนับสนุนข้อกำหนดได้ ฟีเจอร์การตรวจสอบให้หลักฐาน เครื่องมือการเก็บรักษาดำเนินการตามนโยบาย ข้อมูลความยินยอมสนับสนุนการใช้ที่ได้รับอนุญาต แต่การซื้อไลเซนส์ฟีเจอร์ไม่ได้ทำให้สถาปัตยกรรมปฏิบัติตามกฎ การปฏิบัติตามกฎมาจากการออกแบบทั้งหมด: คน นโยบาย กระบวนการ ข้อมูล การควบคุม และหลักฐาน Salesforce เป็นส่วนหนึ่งของมัน ไม่ใช่ทั้งหมด และถ้านโยบายหนึ่งสำคัญพอจะบังคับใช้ ให้ถามว่ามันสำคัญพอจะพิสูจน์หรือไม่: ใครเข้าถึงเรกคอร์ดนี้วันที่ 17 มีนาคม ใครเปลี่ยนฟิลด์นี้ การส่งออกนั้นมีอะไรบ้าง? โมดูลที่ 6 ครอบคลุมเรื่องหลักฐาน

ความเป็นส่วนตัวเปลี่ยนภาพรวมระบบ

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

คำถามที่อยู่ได้นานกว่ากฎระเบียบ

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

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

ธรรมาภิบาล AI กำลังกลายเป็นกฎหมาย

AI เพิ่มผู้ใช้ข้อมูลที่มีธรรมาภิบาลอีกรายหนึ่ง ระบบ AI ใช้ข้อมูลนี้ได้ไหม เพื่อจุดประสงค์อะไร ในฐานะ grounding รวมกับอะไร พูดซ้ำในผลลัพธ์ บันทึกไว้ที่ไหน นานเท่าไร? ธรรมาภิบาลของ AI กำลังย้ายจากนโยบายบริษัทเข้าไปในกฎหมาย: AI Act ของสหภาพยุโรป (Regulation (EU) 2024/1689 (opens in a new tab) ภาษาอังกฤษ) คือตัวอย่างแรกในวงกว้าง สิ่งที่มันกำหนดขึ้นอยู่กับระบบและการใช้งาน ทิศทางสำหรับสถาปนิกชัดเจน: AI ไม่ได้อยู่นอกธรรมาภิบาล มันคืออีกผู้ใช้ของข้อมูลที่มีธรรมาภิบาล

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

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

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

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

• แหล่งข้อมูลทางการของกฎระเบียบลิงก์ไว้ในตารางด้านบน (ภาษาอังกฤษหรือภาษาของแต่ละประเทศ ตรวจสอบเมื่อ 2026-10-14)
• Regulation (EU) 2016/679 (GDPR) (opens in a new tab): มาตรา 3 (ขอบเขตทางอาณาเขต) มาตรา 4(5) (การแฝงข้อมูล) บทนำข้อ 26 (ข้อมูลนิรนาม)
• Regulation (EU) 2024/1689 (AI Act) (opens in a new tab), EUR-Lex