ทำไมเรื่องนี้ระเบิดในรอบ 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 ที่จับต้องได้ทันที — ไม่ต้องรอเกิดเรื่อง