ทำไมเรื่องนี้ระเบิดในรอบ 10 ปีที่ผ่านมา#

จนถึงประมาณปี 2014 — โลกธุรกิจคิดว่า “data is the new oil” — เก็บได้ก็เก็บไว้ก่อน — ใช้ทำอะไรค่อยคิดทีหลัง. Data hoarding = strategy ของบริษัท tech ทั่วโลก

แต่มี 3 เหตุการณ์ใหญ่ ที่เปลี่ยนเกมทั้งหมด:

1. GDPR ของยุโรป (มีผลบังคับ 25 พฤษภาคม 2018) — General Data Protection Regulation (กฎหมายคุ้มครองข้อมูลส่วนบุคคลของสหภาพยุโรป) — กฎหมายที่ปฏิวัติเรื่อง privacy ทั่วโลก. ค่าปรับสูงสุด = 4% ของรายได้ทั่วโลก หรือ €20 ล้าน (แล้วแต่อันไหนสูงกว่า). British Airways โดน £20M. Meta โดน €1.2B ในปี 2023. Amazon โดน €746M

2. Cambridge Analytica Scandal (มีนาคม 2018) — Facebook ปล่อยให้ third-party app ดูดข้อมูลของ user 87 ล้านคน ผ่าน permission ของ “เพื่อนของ user ที่กดอนุญาต” — แล้ว Cambridge Analytica เอาไปทำ psychographic profiling สำหรับ political campaign. Mark Zuckerberg ต้องไปนั่งให้การที่ US Congress. Facebook โดนปรับ $5B โดย FTC ในปี 2019. เคสนี้คือจุด tipping point ของ public consciousness เรื่อง privacy

3. PDPA ของไทย (มีผลบังคับ 1 มิถุนายน 2022) — Personal Data Protection Act (พ.ร.บ. คุ้มครองข้อมูลส่วนบุคคล) — กฎหมายไทยที่ design ตาม GDPR. ค่าปรับสูงสุด 5 ล้านบาท ต่อกรณี. ทำให้บริษัทไทยทุกขนาด ต้องมี DPO (Data Protection Officer) + ทำ Privacy Notice + มีกระบวนการรองรับสิทธิ์ของเจ้าของข้อมูล

ใน 10 ปีนี้ — privacy เปลี่ยนจาก “เรื่องของคน geek” → กลายเป็น กฎหมาย + ความคาดหวังของลูกค้า + brand risk ที่ผู้บริหารหลีกเลี่ยงไม่ได้

มุมผู้บริหาร: ถ้าผู้บริหารของคุณยังคิดว่า “บริษัทเรา secure แล้ว — privacy เป็นเรื่องเดียวกัน” — นี่คือ red flag ใหญ่ที่สุดของ Part 3. ในข่าวเคยเห็นเคสบริษัทไทยขนาดใหญ่หลายราย — มี security infrastructure ระดับโลก แต่โดนปรับ PDPA หลายล้านบาทเพราะ เก็บข้อมูลเกิน + ไม่มี privacy notice + ไม่มีกระบวนการรองรับ data subject right. การลงทุนใน privacy ≠ การลงทุนเพิ่มใน security. มันเป็น disciplines คนละสาย ที่ใช้ skill set + framework + KPI ต่างกัน. ตำแหน่งที่บริษัทขนาดกลางในไทยควรมี — DPO ที่รายงานตรงต่อ CEO หรือ board (ไม่ใช่ใต้ CISO และห้ามใต้ CIO เด็ดขาด — conflict of interest เพราะ CIO อยากเก็บ data เยอะ DPO อยากให้เก็บน้อย)

1. Lawfulness, Fairness, Transparency — ต้องมีฐานทางกฎหมาย + บอกลูกค้าตรงๆ#

คำถาม: บริษัทคุณ มีสิทธิ์อะไร ในการเก็บข้อมูลของลูกค้าคนนี้?

GDPR + PDPA กำหนด ฐานทางกฎหมาย (lawful basis) ที่จะเก็บ + ใช้ข้อมูลส่วนบุคคล มีทั้งหมด 6 ทาง:

1. Consent (ความยินยอม) — ลูกค้ายินยอมแบบ freely given + specific + informed + unambiguous
2. Contract (สัญญา) — จำเป็นเพื่อปฏิบัติตามสัญญา (เช่น เก็บที่อยู่เพื่อส่งของที่ลูกค้าสั่ง)
3. Legal obligation (กฎหมายบังคับ) — บัญชี ภาษี ต้องเก็บตามที่กฎหมายไทยกำหนด
4. Vital interests (ประโยชน์สำคัญต่อชีวิต) — ฉุกเฉินทางการแพทย์
5. Public task (ภารกิจสาธารณะ) — เฉพาะหน่วยงานรัฐ
6. Legitimate interests (ประโยชน์อันชอบธรรม) — เช่น fraud prevention. ต้องผ่าน balancing test ว่าประโยชน์ของบริษัท ไม่ override สิทธิ์ของเจ้าของข้อมูล

กับดักคลาสสิคของบริษัทไทย — เซ็น checkbox “ยอมรับ Privacy Policy” ที่มีข้อความ 30 หน้า + คลิกเดียวยอมรับทุกอย่าง — อันนี้ GDPR / PDPA ไม่ยอมรับเป็น valid consent เพราะไม่ specific + ไม่ informed. ที่ถูกต้องคือ — แยก consent ต่อ purpose. ลูกค้าเลือกได้ว่า — ยอมให้ส่งของ (ใช่ บังคับ) — ยอมให้ส่ง marketing email (ไม่บังคับ ติ๊กเอง) — ยอมให้แชร์ data กับ partner (ไม่บังคับ ติ๊กเอง)

Transparency = ลูกค้าต้องอ่าน Privacy Notice แล้วเข้าใจในภาษาคนได้ว่า — บริษัทเก็บอะไร + เก็บไปทำอะไร + เก็บนานเท่าไร + แชร์กับใคร + ลูกค้ามีสิทธิ์อะไรบ้าง

2. Purpose Limitation — เก็บเพื่อวัตถุประสงค์เฉพาะ ห้ามใช้นอกเหนือ#

คำถาม: ตอนเก็บข้อมูลของลูกค้าคนนี้ — บอกเขาว่าจะใช้ทำอะไร — แล้ววันนี้ ใช้ตามที่บอกหรือเปล่า?

ลองนึก scenario — ลูกค้า A ยอมให้ที่อยู่ของบ้านบริษัทคุณ เพื่อ ส่งของที่ซื้อ. นี่คือ purpose ที่บอกไว้

ปี ถัดมา — บริษัทคุณตัดสินใจ — ขายข้อมูลที่อยู่ของลูกค้า A ให้บริษัท insurance ทำ direct mail. นี่คือ purpose ใหม่ที่ไม่ได้บอกลูกค้า A ก่อน = ผิด Purpose Limitation

ที่ถูกต้อง — ถ้าบริษัทคุณจะใช้ data ใน purpose ใหม่ที่ไม่เคยบอก — ต้องขอ consent ใหม่ หรือ ระบุไว้ใน Privacy Notice ตั้งแต่แรก

นี่คือเหตุที่ Cambridge Analytica เป็น scandal — Facebook ปล่อยให้ developer เก็บ data ของ user ผ่าน “This is your digital life” quiz app โดย purpose ที่บอก user = “แค่ทำ academic research”. แต่จริงๆ — data ถูกขายต่อให้ Cambridge Analytica เพื่อทำ psychographic targeting ทางการเมือง. นี่คือ violation of Purpose Limitation ระดับ 87 ล้านคน

3. Data Minimization — เก็บเท่าที่จำเป็น ไม่เก็บเกิน#

คำถาม: ข้อมูลที่บริษัทคุณเก็บจากลูกค้าคนนี้ — จำเป็นทุกฟิลด์ ต่อ purpose ที่บอกไว้ไหม?

นี่คือหลักการที่ผมคิดว่า disruptive ที่สุด ต่อ business culture ของไทย

วัฒนธรรมเก่า — “เก็บไว้ก่อน เผื่อจะได้ใช้”. วัฒนธรรมใหม่ตามกฎหมาย — “เก็บเท่าที่ใช้ ใช้เกินไม่ได้”

ลองนึก ตัวอย่างจริง — app delivery food ของบริษัทขนาดกลางในไทย. ตอนสมัคร ฟอร์มถาม:

• ชื่อ-นามสกุล → จำเป็น (ต้องส่งให้ rider)
• เบอร์โทร → จำเป็น (rider โทรหา)
• ที่อยู่ → จำเป็น (ส่งของ)
• email → จำเป็น (ส่ง receipt)
• วันเกิด → ไม่จำเป็น (แต่บริษัทอยากได้ทำ marketing)
• เลขบัตรประชาชน → ไม่จำเป็น (ไม่ใช่ business KYC)
• เพศ → ไม่จำเป็น (irrelevant)
• รายได้ต่อเดือน → ไม่จำเป็น (irrelevant)
• อาชีพ → ไม่จำเป็น (irrelevant)
• เลขที่บัญชีธนาคาร → ไม่จำเป็น (จ่ายผ่าน gateway)

ที่ถูกต้อง — เก็บเฉพาะ 4 ฟิลด์แรก. ที่เกินมา = violation of Data Minimization

อ้าว — แต่ถ้าบริษัทยังอยากได้ data พวกนี้ ทำยังไง? คำตอบ = ทำให้เป็น optional + ระบุ purpose ใหม่ใน privacy notice + ขอ consent แยกต่างหาก. ลูกค้าเลือกได้ — ไม่บังคับเป็นเงื่อนไขการสมัคร

4. Accuracy — ข้อมูลต้องถูกต้อง ทันสมัย ลูกค้าขอแก้ได้#

คำถาม: ข้อมูลของลูกค้าคนนี้ที่บริษัทคุณมี — ถูกต้องและทันสมัย ไหม? — ลูกค้าขอแก้ได้ง่ายแค่ไหน?

ลองนึก scenario — ลูกค้าเปลี่ยนที่อยู่. ส่งอีเมลบอกบริษัท. บริษัทไม่มีกระบวนการแก้ — รอ ลูกค้าเข้า account portal แก้เอง — แต่ portal มี bug. 6 เดือนผ่านไป — ข้อมูลผิดทั้ง marketing system + logistics system + CRM

นี่ดูเหมือนเรื่องเล็ก — แต่ GDPR/PDPA บอกชัด — เจ้าของข้อมูลมีสิทธิ์ขอแก้ (Right to Rectification) — และบริษัทต้องตอบสนองภายใน 30 วัน (GDPR) / 30 วัน (PDPA — แต่ขยายได้ถึง 60 วันในกรณีซับซ้อน)

Implementation จริง — บริษัทต้องมี:

• Self-service portal — ให้ลูกค้าแก้เองได้
• Customer service workflow — รับเรื่องและ propagate การแก้ไปทุก system (CRM + marketing + logistics + analytics + data warehouse)
• Data lineage tracking — รู้ว่า data field นี้กระจายไปอยู่ใน system ไหนบ้าง

5. Storage Limitation — เก็บเท่าที่จำเป็น หมดเวลาก็ต้องลบ#

คำถาม: ข้อมูลที่บริษัทเก็บไว้ — เก็บได้นานแค่ไหน — มีนโยบายลบเมื่อหมดความจำเป็นไหม?

นี่คือ principle ที่บริษัทไทยอ่อนที่สุด. วัฒนธรรมการเก็บ data ของไทยคือ — “backup tape ปี 2008 ยังอยู่ครับ ไม่กล้าทิ้ง” + “data warehouse ของเรามีข้อมูลของลูกค้าตั้งแต่ปีที่ก่อตั้ง”

ตามกฎหมาย — ต้องมี Data Retention Policy ที่ระบุ:

• data ประเภทไหน เก็บนานแค่ไหน
• หมดเวลาแล้ว ลบยังไง (จาก production + backup + cold storage)
• proof of deletion ใครเก็บ + audit ได้ไหม

ตัวอย่างที่บริษัทไทยใช้กันบ่อย:

ที่ผิด pattern คลาสสิคของวงการ:

• เก็บ raw log + raw event ของลูกค้า ตลอดชีพ → ไม่ผ่าน storage limitation
• ลบจาก production แต่ backup tape ยังอยู่ → ไม่ผ่าน (backup ก็ต้องลบตามนโยบาย)
• ลบจาก system หลัก แต่ data analyst download copy ไปทำ ad-hoc analysis เก็บใน laptop → ไม่ผ่าน (เรียก shadow data)

มุมผู้บริหาร: Data retention policy เป็น project ที่ผู้บริหารมองว่า “งานเอกสาร” — เลื่อนไปเรื่อยๆ. ที่จริง — มันคือ project ที่ลด liability ของบริษัทมากที่สุดที่ทำได้ในงบต่ำ. ถ้าบริษัทคุณโดน breach วันนี้ — บริษัทรับผิดต่อข้อมูลลูกค้าทุกคนที่ยังอยู่ใน database. ลูกค้า inactive 10 ปียังอยู่ → liability เพิ่ม. การลบข้อมูลที่หมดความจำเป็น = ลด surface area ของ liability โดยตรง + ลด storage cost. ถ้ายังไม่มี retention policy เป็นทางการ — นี่คือ quick win ที่ ROI สูงสุดในปีนี้

Pseudonymization — แทนที่ identifier ด้วย token (ย้อนกลับได้ ถ้ามี key)#

Pseudonymization (การใช้นามแฝง) = เอา personal identifier (ชื่อ / เลขบัตรประชาชน / email) ออกจาก data record — แทนที่ด้วย token หรือ pseudonym — แต่ เก็บ mapping table แยกไว้

ลองนึกภาพ — database 1 ที่เก็บ:

1
record_id: USR-7A3F
2
purchase: iPhone 15 Pro
3
amount: 45000

แล้ว database 2 (separate vault) เก็บ:

1
USR-7A3F → สมชาย ศรีนคร / 1-2345-67890-12-3 / 0812345678

ถ้าใครได้แค่ database 1 — เห็นแต่ token = ไม่รู้ว่าเป็นใคร. แต่ถ้าได้ทั้ง 2 database → ย้อนกลับเป็นชื่อจริงได้

GDPR Recital 26 + Article 4(5) — บอกชัดเลยว่า pseudonymized data ยังคงเป็น personal data เพราะ “สามารถ re-identify ได้ถ้ามี additional information”. หมายความว่า — GDPR + PDPA ยังคุ้มครอง

Pseudonymization เป็น security measure ที่ดี — ช่วยลด blast radius ของ breach (โจรได้ database 1 อย่างเดียว = ไร้ค่า). แต่มัน ไม่ใช่ get-out-of-GDPR card. คุณยังต้องเคารพ data subject right + retention policy + purpose limitation

Anonymization — ลบ identifier ถาวร (ย้อนกลับไม่ได้)#

Anonymization (การทำให้นิรนาม) = ทำให้ data ไม่สามารถ re-identify กลับเป็นบุคคลได้ — ถาวร + ไม่มี key

ถ้าทำได้จริง — data ที่ anonymize แล้ว ไม่ถือเป็น personal data ตาม GDPR — หลุดออกจากขอบเขตของกฎหมาย

แต่นี่คือจุดที่ engineering ยากที่สุด — true anonymization ทำได้ยากกว่าที่คิดมาก

Netflix Prize 2007 — เคสที่ทำให้วงการเข้าใจว่า anonymization ยากแค่ไหน#

เคสคลาสสิคที่ออกในตำราทุกเล่ม — Netflix Prize

ปี 2006 — Netflix เปิด competition — ให้รางวัล $1M กับคนที่ทำ recommendation algorithm ดีกว่าของ Netflix 10%. Netflix release dataset ของ rating ของ user 480,000 คน. “Anonymized” — เอาชื่อออก แทนที่ด้วย user ID

ปี 2007 — นักวิจัย 2 คนจาก University of Texas (Narayanan + Shmatikov) ลองทำสิ่งที่เรียกว่า re-identification attack — ใช้ rating data จาก IMDB (public) ที่ user หลายคนใช้ชื่อจริง — มา cross-reference กับ Netflix dataset

ผลลัพธ์ — re-identify ได้ 99% ของ user ใน Netflix dataset โดยใช้ rating + เวลา rating จาก IMDB

ทำไมทำได้ — เพราะ rating pattern ของแต่ละคนเป็น fingerprint. คนที่ดู Documentary หายากเฉพาะ 3 เรื่อง + rate ในวันใกล้กัน = unique signature ที่หาได้ใน 2 platforms

Netflix ยกเลิก Prize ปี 2 หลังโดนฟ้องและ FTC สอบ

บทเรียน: การ “เอาชื่อออก” ไม่ใช่ anonymization. Quasi-identifier (ข้อมูลที่ดู harmless แต่รวมกันแล้วระบุตัวได้) — เช่น ZIP code + วันเกิด + เพศ — ทำ re-identify ได้ 87% ของประชากรสหรัฐ (งานวิจัยของ Latanya Sweeney 2000)

Strava Heatmap 2018 — anonymized aggregate ที่เปิดฐานทัพลับ#

ปี 2018 มีอีกเคสที่ดังมาก — Strava (app วิ่ง/ปั่นจักรยาน) release global heatmap — แสดงเส้นทางที่ user ทั้งโลก วิ่ง/ปั่นบ่อย — anonymized และ aggregate แล้ว (รวมเป็น heatmap ไม่ระบุตัวคน)

ดูปลอดภัย ใช่ไหม? — ไม่

นักวิเคราะห์ open-source intelligence — เปิด heatmap ดูพื้นที่ใน Syria, Afghanistan, Niger, Djibouti — เห็นเส้นทางวิ่งที่ชัดมากในรูปแบบของรั้วทหาร — กลายเป็นว่า ฐานทัพลับของ US military + special forces เปิดที่ตั้งให้โลกรู้ เพราะทหารใช้ Strava วิ่งออกกำลังกายในฐาน

Aggregate ที่ดู safe — เปิด location ของ secret military base ทั่วโลก

บทเรียน — anonymization กับ aggregation ไม่เท่ากับ privacy. ถ้า data ที่ aggregate มี pattern ที่ unique → ยังระบุได้อยู่ดี. ในเคส Strava — ตัวเส้นทางคือ unique fingerprint ของ physical infrastructure

มุมผู้บริหาร: ก่อน release dataset ของบริษัทออกสู่สาธารณะ (หรือแชร์กับ partner / vendor) — อย่าใช้คำว่า “anonymized” จนกว่าจะผ่าน privacy review โดยคนที่เข้าใจ re-identification attack. ในข่าวมีเคสบริษัทไทยที่เปิด “anonymized open data” สำหรับ research — แต่เปิดให้ re-identify ได้เพราะมี ZIP + ปีเกิด + เพศ + อาชีพ. ที่ปลอดภัยกว่าคือ — ทำ pseudonymization + เก็บ key vault แยก + มี contract กับคนที่ใช้ data — ห้าม re-identify + ลบเมื่อใช้เสร็จ. การ “release public dataset” ของบริษัทควรถือเป็น high-risk activity ที่ต้องผ่าน DPIA (อยู่ในหัวข้อ 5)

1. k-anonymity — ต้องเหมือนคนอื่นอย่างน้อย k คน#

k-anonymity (k-นิรนาม) = หลักการที่บอกว่า — record แต่ละแถวใน dataset — ต้อง identical ในส่วนของ quasi-identifier กับ record อื่น อย่างน้อย k-1 records

ลองนึก dataset ของผู้ป่วย:

1
อายุ | ZIP code | เพศ | โรค
2
35   | 10110    | M  | เบาหวาน
3
35   | 10110    | M  | ความดัน
4
35   | 10110    | M  | หัวใจ
5
35   | 10110    | M  | ไต
6
35   | 10110    | M  | ตา

ถ้า k=5 → ทุก record มีคนเหมือนกัน 4 คน (5 รวมตัวเอง) — โจรเห็น record ไหน — ไม่รู้ว่าเป็นใครใน 5 คนนี้

วิธีทำให้ได้ k-anonymity = generalization (อายุ 33 → กลุ่ม “30-39”) + suppression (ลบบาง field) จนกว่าทุก record ใน dataset มีคู่แฝดอย่างน้อย k-1 records

ข้อจำกัด — ถ้าทุกคนในกลุ่ม k คน เป็นโรคเดียวกัน (เช่น โรค “เบาหวาน” ทั้งหมด) → โจรยังรู้ว่าคุณเป็นเบาหวาน (เรียก homogeneity attack). ต้องใช้ extension เช่น l-diversity หรือ t-closeness เพื่อกัน

2. Differential Privacy — เพิ่ม noise ใน aggregate stats#

Differential Privacy (DP) = วิธีคิดที่ Cynthia Dwork จาก Microsoft Research เสนอปี 2006. ปัจจุบันถือเป็น gold standard ของ privacy ใน data publication

ภาพในใจง่ายๆ: ก่อนเผยแพร่ aggregate statistic (เช่น “ค่าเฉลี่ยรายได้ของ user ในเขต A”) — เพิ่ม random noise (mathematical noise) เข้าไปในผลลัพธ์ — noise มีขนาดที่ออกแบบให้:

• ผลลัพธ์ยังใช้งานได้ (สถิติยัง accurate ในระดับ aggregate)
• คนภายนอกไม่สามารถบอกได้ว่า — record ของบุคคล X อยู่ใน dataset นี้หรือเปล่า

มี parameter ตัวหนึ่งชื่อ ε (epsilon) — เป็น privacy budget. ε เล็ก = noise มาก = privacy แรง แต่ utility ลด. ε ใหญ่ = noise น้อย = utility ดี แต่ privacy อ่อน

ใครใช้จริงในวงการ:

• Apple (2016) — เริ่มใช้ Differential Privacy ใน iOS เพื่อเก็บ emoji usage + keyboard suggestions + Safari crash data จาก user — โดย Apple ไม่เห็น raw data ของ user คนไหน
• Google — ใช้ใน Chrome (RAPPOR system) + ใน COVID-19 mobility report
• US Census 2020 — เป็น census แรกในประวัติศาสตร์อเมริกา ที่ใช้ Differential Privacy ในการ release ผลลัพธ์ — เพื่อกัน re-identification ของ household
• Microsoft — มีในหลาย product ของ Office + Windows telemetry

Differential Privacy = เรื่องที่ผู้บริหารควรถาม CTO ว่า — “เราใช้ DP ใน analytics ของเราหรือยัง” ถ้า answer = “DP คืออะไร” → red flag

3. Homomorphic Encryption — compute บน encrypted data โดยไม่ decrypt#

Homomorphic Encryption (HE) = encryption ประเภทพิเศษที่ — ทำ computation บน ciphertext (data ที่ encrypt แล้ว) ได้โดยไม่ต้อง decrypt

ลองนึกภาพ — ลูกค้า A ส่ง data ของตัวเอง (encrypted) ให้ cloud provider. cloud compute average + search + aggregate ได้บน ciphertext. ส่งผลลัพธ์ (encrypted) กลับมา. ลูกค้า A decrypt แล้วได้ผลลัพธ์ที่ถูกต้อง — cloud provider ไม่เคยเห็น plaintext ของ data เลย

ฟังดูเหมือนหนังไซไฟ ใช่ไหม — แต่บริษัทใหญ่เริ่มใช้จริงแล้ว:

• IBM เปิด HElib + OpenFHE ให้ใช้ฟรี
• Microsoft มี SEAL library สำหรับ HE
• Apple ใช้ HE ใน Private Cloud Compute ของ Apple Intelligence (2024) — เพื่อให้ AI ทำงานบน cloud โดย Apple ไม่เห็น query
• Banking sector — เริ่มใช้สำหรับ fraud detection ระหว่างธนาคาร — ธนาคาร A ตรวจ pattern ของ transaction กับ ธนาคาร B ได้โดยไม่เห็น data ของกันและกัน

ข้อจำกัด — HE ช้ามาก เมื่อเทียบกับ plaintext compute (10-1000 เท่า depending on operation). ใช้ในกรณีที่ privacy มี value สูงกว่า performance penalty

4. Federated Learning — train ML model โดย data ไม่ออกจากเครื่อง#

Federated Learning = วิธี train machine learning model ที่ data ไม่ออกจาก device ของ user — แทนที่จะส่ง data ขึ้น cloud — ส่ง model weight (พารามิเตอร์ของ model) เท่านั้น

ภาพในใจ:

1. server ส่ง model เปล่าๆ ไปที่ device ของ user ทุกคน
2. แต่ละ device train model ด้วย data ของตัวเอง (รูปภาพในมือถือ / text ที่พิมพ์ / behavior pattern)
3. แต่ละ device ส่งกลับ แค่ weight update ไม่ใช่ raw data
4. server รวม weight update จากทุก device → ได้ model ที่ดีขึ้น
5. iterate ใหม่

ใครใช้จริง:

• Google Gboard (Android keyboard) — train suggestion model โดยที่ Google ไม่เห็นว่าใครพิมพ์อะไร
• Apple — ใช้ใน Siri suggestion + QuickType
• Healthcare research — โรงพยาบาลหลายแห่งร่วม train AI วินิจฉัยโรค โดยที่ patient record ไม่ออกจากโรงพยาบาล

5. Secure Multi-Party Computation (MPC) — 2 บริษัท join data without revealing#

Secure Multi-Party Computation (MPC) = ระบบที่ให้ 2 หรือมากกว่าบริษัท compute ฟังก์ชันร่วมกัน โดยที่ ไม่มีฝ่ายไหนเปิดเผย private input ของตัวเอง

ตัวอย่างที่จับต้องได้ — ปัญหา Millionaire’s Problem (Yao 1982) — 2 เศรษฐีอยากรู้ว่า ใครรวยกว่ากัน โดยที่ ไม่ต้องบอกตัวเลขของตัวเอง. MPC ทำได้

ในวงการจริง:

• Boston Women’s Workforce Council — รวม salary data จากหลาย company เพื่อ analyze gender pay gap — โดยไม่มี company ไหนเปิด salary ของตัวเอง
• Banks — ทำ shared fraud database — ธนาคาร A เช็คได้ว่า customer ของตัวเองมี history ที่ ธนาคาร B หรือไม่ — โดยไม่เห็น customer list ของ ธนาคาร B
• Pharma — ทำ clinical trial pooling โดยไม่เปิด patient data

มุมผู้บริหาร: PETs ไม่ใช่เรื่องของ research lab อีกต่อไป — เป็น production-grade เทคโนโลยีที่ FAANG + รัฐบาลใช้จริง. ถ้าบริษัทคุณมี data ที่มี value แต่ติดข้อจำกัดทาง privacy ที่จะแชร์หรือ analyze — อย่าตัด opportunity ทันที — มี PET ที่อาจ unlock value โดยไม่ละเมิด privacy. การลงทุนใน PET ในระยะ 2-3 ปีข้างหน้า = เตรียมตัวสำหรับ competitive advantage เมื่อ regulation เข้มขึ้น. บริษัทไทยที่มี cross-border data flow (ส่ง data ไป cloud ต่างประเทศ) ควรพิจารณาเรื่องนี้ก่อนใคร เพราะ PDPA + GDPR + จีน CSL/PIPL เริ่มบังคับ data localization + cross-border restriction มากขึ้นทุกปี

Ann Cavoukian 7 Principles — กรอบคิดที่กฎหมายทั่วโลกยืม#

Privacy by Design (PbD) เป็นแนวคิดที่ Ann Cavoukian (อดีต Information & Privacy Commissioner ของ Ontario, Canada) เสนอในปี 1990s — และกลายเป็นมาตรฐานของวงการในปี 2010 หลังถูกรับรองในงาน International Conference of Data Protection Authorities

GDPR Article 25 — บัญญัติ “Data Protection by Design and by Default” เป็นข้อกฎหมายโดยตรง — ใช้แนวคิดของ Cavoukian เป็นฐาน

7 หลักการ:

1. Proactive not Reactive; Preventative not Remedial — ป้องกันก่อน ไม่ใช่แก้หลังเกิดเรื่อง
2. Privacy as the Default Setting — ค่า default ของระบบ = privacy เต็ม (user ไม่ต้องทำอะไรก็ปลอดภัย)
3. Privacy Embedded into Design — built-in ในสถาปัตยกรรม ไม่ใช่ bolt-on ตอนใกล้ launch
4. Full Functionality — Positive-Sum, not Zero-Sum — privacy + security + functionality ไปด้วยกันได้ ไม่ใช่ trade-off
5. End-to-End Security — Full Lifecycle Protection — ปกป้องตั้งแต่เก็บ → ใช้ → archive → destroy
6. Visibility and Transparency — โปร่งใส ตรวจสอบได้
7. Respect for User Privacy — Keep it User-Centric — user เป็นศูนย์กลาง ไม่ใช่ company

หลักการที่ผมคิดว่าใช้งานหนักที่สุดในระดับ engineering = ข้อ 2 (Privacy as Default). ลองเปรียบเทียบให้เห็นภาพ:

Bad design:

1
[ ] Send me marketing email (default = unchecked)
2
[x] Share my data with partners for offers (default = CHECKED!)
3
[x] Use my data to train AI (default = CHECKED!)

Good design (Privacy by Default):

1
[ ] Send me marketing email (default = unchecked)
2
[ ] Share my data with partners for offers (default = unchecked)
3
[ ] Use my data to train AI (default = unchecked)

User ที่ click “Sign up” ไป — ค่า default ต้องเป็น minimum exposure. ถ้า user อยากให้เพิ่ม — ต้อง opt-in โดยรู้ตัว. นี่คือสิ่งที่ GDPR + PDPA บังคับ — ห้าม pre-checked box สำหรับ optional consent

DPIA — Data Protection Impact Assessment#

อีกเครื่องมือสำคัญที่ผู้บริหารควรรู้ — DPIA (Data Protection Impact Assessment)

DPIA = กระบวนการประเมินผลกระทบต่อ privacy ของ โปรเจคใหม่ที่ใช้ personal data — ทำ ก่อน launch ไม่ใช่หลัง

GDPR Article 35 + PDPA — บังคับให้ทำ DPIA ในกรณี:

• โปรเจคใช้ข้อมูล sensitive (สุขภาพ / ศาสนา / political opinion / biometric)
• ใช้ AI / automated decision-making ที่กระทบสิทธิ์ user (เช่น credit scoring)
• มี large-scale surveillance / monitoring
• ใช้ data ของผู้เยาว์

โครงสร้าง DPIA ทั่วไป:

1. Describe — โปรเจคนี้ใช้ data อะไร / เก็บจากใคร / เก็บนานเท่าไร / ใช้ทำอะไร / แชร์กับใคร
2. Assess necessity & proportionality — จำเป็นไหม + ใช้ data minimum หรือไม่ + มีทางอื่นที่ privacy-friendly กว่าไหม
3. Identify risks to data subjects — ความเสี่ยงต่อ user ถ้าโปรเจคนี้พัง (financial loss / discrimination / reputation damage / identity theft)
4. Identify mitigation measures — control ที่จะใส่ (encryption / access control / anonymization / retention policy / consent flow)
5. Sign-off — DPO + business owner + (กรณีเสี่ยงสูงมาก) regulator

DPIA ไม่ใช่ paperwork — มันคือ discipline ที่บังคับให้ engineering team คิดเรื่อง privacy ตั้งแต่ design phase — ไม่ใช่ตอนใกล้ launch แล้วเพิ่งนึกได้

Cambridge Analytica — เคสที่ Privacy by Design พังตั้งแต่ design phase#

กลับมาที่เคสที่เปิด EP — Cambridge Analytica

ปัญหาของ Facebook Platform ในปี 2014 ที่ทำให้เกิด scandal — มันคือ failure ของ Privacy by Design ระดับสถาปัตยกรรม:

1. Friend Permission ของ Facebook Platform — ถ้า user A ติดตั้ง app — app ดูข้อมูลของ เพื่อนทั้งหมดของ user A ได้ — โดยที่เพื่อนไม่ได้กดยินยอม → violation of Lawfulness + Consent
2. Purpose Limitation ไม่มี — app ขอ data ในนาม “academic research” → ส่งต่อให้ Cambridge Analytica ทำ political profiling → violation of Purpose Limitation
3. Privacy as Default = pre-checked permission default → user ไม่รู้ตัวว่ายินยอม → violation
4. DPIA = ไม่มีกระบวนการ. Facebook Platform เปิดให้ developer 3rd party ใช้โดยไม่มี review เรื่อง privacy impact → violation of accountability

ผลลัพธ์ — Facebook โดน $5B FTC fine (2019) + £500K UK ICO fine + ค่าใช้จ่ายในการ restructure ทั้ง platform

บทเรียน — Privacy by Design ราคาถูก ถ้าทำตั้งแต่ design phase. ราคาแพงมาก ถ้าต้องไป retrofit หลังจาก scale แล้ว — บางครั้งต้อง re-architect ทั้ง system

มุมผู้บริหาร: บริษัทไทยปี 2026 — DPIA ควรเป็น checkpoint บังคับก่อน go-live เหมือน pen test. workshop 2 ชั่วโมงต่อ project ก็พอ. เคสที่บริษัทไทยโดนปรับ PDPA ปี 2023-2024 เกินครึ่งคือ project ที่ launch โดยไม่มี privacy review. และข้อสำคัญที่สุด — DPO ห้ามรายงานใต้ CIO/CTO เด็ดขาด เพราะ KPI ตรงข้าม (CIO อยากเก็บ data เยอะ ↔ DPO อยากเก็บน้อย). ใส่ใต้กัน = neutralize ทั้งฟังก์ชัน DPO

สิ่งที่ผู้นำต้องจำ#

ข้อแรก — Privacy ≠ Security. ถ้าผู้บริหารของคุณยังเข้าใจว่าเรื่องเดียวกัน บริษัทอยู่ในความเสี่ยงทางกฎหมาย

นี่คือคำแนะนำที่ผมอยากให้คุณจำที่สุดของ EP นี้ครับ. Security = ปกป้องของบริษัทจากโจร. Privacy = ปกป้องลูกค้าจากบริษัทเอง. ใช้ skill set + framework + KPI + reporting line ต่างกัน

Action plan สำหรับบริษัทไทยขนาดกลาง:

1. มี DPO ที่ทำหน้าที่จริง — ตำแหน่งนี้บังคับโดย PDPA สำหรับบริษัทที่เก็บ personal data ขนาดใหญ่. ห้ามรวมกับ CISO หรือ Compliance Officer — เพราะ scope งานต่างกัน. ห้ามรายงานใต้ CIO/CTO — conflict of interest
2. ทำ Data Inventory — ก่อนทุกอย่าง — รู้ว่าบริษัทคุณ เก็บ data อะไร / ที่ไหน / นานแค่ไหน / แชร์กับใคร. ถ้า DPO ถาม “บริษัทเรามี personal data field อะไรบ้าง” แล้วไม่มีคำตอบใน 1 สัปดาห์ = ขั้นแรกที่ต้องทำ
3. เขียน Privacy Notice + Consent flow ใหม่ — ตาม PDPA. แยก consent ต่อ purpose. ไม่ pre-checked. ภาษาคนที่ลูกค้าอ่านเข้าใจ
4. ทำ Data Retention Policy — กำหนดเวลาเก็บแต่ละประเภท + กระบวนการลบจริง (รวม backup)
5. ทำ DPIA template + บังคับ DPIA ในทุก project ใหม่ ที่ใช้ personal data
6. มี process รองรับ Data Subject Rights — ลูกค้าขอ access / rectification / erasure / portability — บริษัทตอบใน 30 วัน

ทั้ง 6 ข้อนี้ — ทำได้ในงบประมาณบริษัทขนาดกลาง — ไม่ต้องลงทุน enterprise platform. แต่ต้องทำตั้งแต่วันนี้

ข้อสอง — Data Minimization + Storage Limitation คือ control ที่ ROI สูงที่สุดของ privacy

ข้อนี้เป็น mindset shift ที่ผู้บริหารหลายคนยังไม่เห็นภาพครับ — ข้อมูลที่ไม่เก็บ = ข้อมูลที่โจรขโมยไม่ได้ + ไม่ต้อง encrypt + ไม่ต้องจ่าย storage + ไม่ต้องจ่ายค่าปรับถ้าหลุด

วัฒนธรรมเก่าของวงการ — “data is the new oil” → เก็บไว้ก่อน. วัฒนธรรมใหม่ — “data is the new uranium” → useful แต่ liability สูง ต้องจัดการให้ดี + ลดให้น้อยที่สุด

ลอง exercise ในบริษัทคุณ:

• List ทุก field ที่บริษัทเก็บจากลูกค้า — ทำตาราง
• ติ๊กว่า field ไหน “จำเป็น” จริงๆ สำหรับ business operation — ไม่ใช่ “เผื่ออาจจะใช้”
• ลบ field ที่ไม่จำเป็น — จาก form ใหม่ + จาก database เก่า (anonymize หรือ ลบ)
• กำหนด retention period ของแต่ละ field — และมีระบบลบอัตโนมัติ

ในเคสบริษัทไทยขนาดกลางที่ทำตามนี้ — โดยทั่วไปลด data volume ลงได้ 40-60% — ลด storage cost + ลด compliance burden + ลด breach impact ในคราวเดียว. นี่คือ win-win-win ที่หาได้ยากในงาน IT

นอกจากนั้น — เคสจริงในข่าวเช่น Marriott (500M record + ค่าปรับ $24M ICO) — กว่าครึ่งของ record ที่หลุด คือลูกค้า inactive หลายปีที่ไม่ควรเก็บอยู่แล้ว. ถ้า Marriott ทำ retention policy ดี — impact ของ breach จะลดลงมหาศาล

ใน scenario ที่ insurance industry เริ่มสังเกต — บริษัทที่ทำ Privacy Engineering ดี → cyber insurance premium ต่ำกว่า peer 15-25%. นี่คือ financial value ที่จับต้องได้ทันที — ไม่ต้องรอเกิดเรื่อง