1.1 Legal basis + Consent — “ฐานทางกฎหมาย” คือใบอนุญาตในการใช้ข้อมูล#

privacy พื้นฐานของ AI วางอยู่บนหลักเดียวกับการคุ้มครองข้อมูลส่วนบุคคลที่องค์กรทำกันอยู่แล้ว — คือต้องมี legal basis (ฐานทางกฎหมายในการประมวลผลข้อมูล) ก่อนจะแตะข้อมูลส่วนบุคคลของใคร. และฐานทางกฎหมายที่เจ้าของกิจการเจอบ่อยที่สุดคือ consent (ความยินยอม).

consent ในชีวิตจริงมักมาในรูปของ “การยอมรับเงื่อนไขการให้บริการ” (terms of service) ครับ. เวลาลูกค้ากดยอมรับเงื่อนไขตอนสมัครบริการ — นั่นคือเขา “ยินยอม” ให้เราใช้ข้อมูลของเขา ในแบบที่ระบุไว้ เพื่อแลกกับการได้รับบริการนั้น.

แต่จุดที่ผู้บริหารส่วนใหญ่พลาด คือ — consent มันผูกกับ “จุดประสงค์” (purpose) เสมอ ไม่ใช่ผูกกับ “ตัวข้อมูล”. หลักง่ายๆ มี 2 ชั้น:

• ข้อมูลที่ จำเป็นต่อการให้บริการ → การที่ลูกค้ากดยอมรับเงื่อนไข = ยินยอมให้ใช้ได้ (สำหรับจุดประสงค์นั้น)
• ข้อมูลที่ จะเอาไปใช้นอกเหนือจากบริการที่ตกลงกัน → ต้องขอ consent เพิ่ม (explicit consent) ต่างหาก

กลับไปที่สายการบินสมมติของเราครับ. ลูกค้ากรอกชื่อ+อีเมลเพื่อสมัครสะสมไมล์ — ตอนสมัคร สายการบินต้องบอกชัดเจน (มักอยู่ในเงื่อนไขการสมัคร) ว่า เก็บอะไร, เก็บไปทำไม, และมันช่วยให้เข้าร่วมโปรแกรมยังไง. แค่นี้ใช้ข้อมูลในขอบเขตของ “โปรแกรมสะสมไมล์” ได้. แต่ถ้าวันหนึ่งอยากเอาอีเมลไป ส่งการตลาดที่ไม่เกี่ยวกับโปรแกรมสะสมไมล์ — ต้องไปขอ consent เฉพาะเรื่องนั้นเพิ่ม.

แล้วมันมาเกี่ยวกับ AI ตรงไหน? ตรงนี้แหละครับคือจุดที่ AI ทำให้เรื่องแปลกไป:

ลองนึกภาพต่อ — สายการบินอยากเอา AI มาช่วยสร้าง คำแนะนำทริปท่องเที่ยวเฉพาะบุคคล ให้ลูกค้าแต่ละคน. เพื่อทำแบบนั้น AI ต้องเอา ประวัติการบินของลูกค้า ไปเรียนรู้. คำถามคือ — ตอนลูกค้าสมัคร เงื่อนไขที่เขากดยอมรับ ครอบคลุมการเอาข้อมูลไปเทรน AI เพื่อแนะนำทริปไหม?

• ถ้า ครอบคลุม → เดินหน้าได้
• ถ้า ไม่ครอบคลุม → ต้องขอ consent เพิ่ม ก่อนเอาข้อมูลลูกค้าไปเทรนโมเดล AI — ห้ามแอบเอาไปใช้

นี่คือคอนเซ็ปต์ที่ผมเรียกว่า “consent-for-training” ครับ — ความยินยอมในการนำข้อมูลไปฝึกโมเดล AI ต้องเป็นความยินยอมแยกต่างหาก ไม่ใช่เหมารวมว่า “ลูกค้าให้ข้อมูลมาแล้ว เอาไปทำอะไรก็ได้”. และเครื่องมือที่ช่วยให้เราไม่หลงทำผิด คือ การติดป้ายข้อมูล (tagging) + data management control — เพื่อให้รู้ตลอดว่าข้อมูลก้อนไหน “ยินยอมให้ใช้ทำอะไรได้บ้าง”

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

1.2 สิทธิ 5 ข้อของเจ้าของข้อมูล — และทำไม AI ทำให้รักษามันยากขึ้น#

นอกจากต้องมี legal basis แล้ว กฎหมายคุ้มครองข้อมูลส่วนบุคคลสมัยใหม่ยังให้ “สิทธิ” (rights) แก่เจ้าของข้อมูล (data subject — คือตัวบุคคลที่ข้อมูลนั้นพูดถึง) ด้วย. มี 5 สิทธิหลักที่ผู้บริหารต้องจำให้ขึ้นใจ เพราะ AI ทำให้การรักษาสิทธิเหล่านี้ “ยากขึ้นทุกข้อ”:

ขอขยายข้อที่อันตรายที่สุดสำหรับเจ้าของกิจการ — “สิทธิที่จะถูกลืม” (right to be forgotten) ครับ.

ลองนึกภาพสถานการณ์จริง — สมมติว่าลูกค้าคนหนึ่งของสายการบินสมมติเรา ส่งหนังสือมาว่า “ผมขอถอนความยินยอม ลบข้อมูลผมออกจากระบบทั้งหมด”. ในโลกเก่า — ง่ายมาก เราแค่ลบ record ของเขาออกจากฐานข้อมูล จบ. แต่ในโลก AI — ถ้าข้อมูลของเขาถูกเอาไป เทรนโมเดล ไปแล้ว ความรู้ของเขา “ถูกหลอมรวม” เข้าไปอยู่ในตัวโมเดลแล้ว. การลบ record ในฐานข้อมูลไม่ได้ลบสิ่งที่โมเดลเรียนรู้ไปแล้ว. และการ “เทรนโมเดลใหม่ทั้งตัว” เพื่อเอาข้อมูลคนเดียวออก อาจมีต้นทุนมหาศาล.

นี่ไม่ใช่ปัญหาทางเทคนิคที่เราจะโยนให้ทีม IT แก้คนเดียวครับ — มันเป็น ความเสี่ยงทางกฎหมายและธุรกิจที่ผู้บริหารต้องคิดตั้งแต่ก่อนเริ่มเทรน ว่า “ถ้าวันหนึ่งมีคนขอให้ลืม เราจะทำได้ยังไง”. นี่คือเหตุผลที่ control อย่าง differential privacy (ทำให้โมเดลไม่ “จำ” ข้อมูลของบุคคลใดบุคคลหนึ่งได้) สำคัญมาก — เดี๋ยวเล่าในส่วน control

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

1.3 Third-party AI — DPIA + DPA เมื่อข้อมูลออกนอกบ้าน#

จนถึงตรงนี้เราพูดถึงกรณีที่เรา “คุมข้อมูลเอง” ครับ. แต่ความซับซ้อนพุ่งขึ้นทันทีเมื่อเราเอาข้อมูลไปป้อนให้ AI ของเจ้าอื่น (third-party AI) — เพราะข้อมูลลูกค้าของเรากำลัง “ออกนอกบ้าน” ไปอยู่ในมือคนอื่น.

ลองนึกภาพ — สมมติว่าบริษัทพัฒนาแอปเล็กๆ แห่งหนึ่งอยากใส่ฟีเจอร์น่ารักๆ คือ “สร้างคำอวยพรวันเกิดเฉพาะบุคคล” ให้ผู้ใช้แต่ละคน โดยใช้ AI สำเร็จรูปของเจ้าอื่นมาช่วยเขียน. ฟังดูเป็นฟีเจอร์เล็กๆ ไม่มีพิษภัย. แต่เบื้องหลัง — บริษัทต้องส่ง ชื่อและวันเกิดของผู้ใช้ ออกไปให้ผู้ให้บริการ AI ภายนอก. ทันทีที่ข้อมูลส่วนบุคคลออกนอกบ้าน มี 2 อย่างที่ผู้บริหารต้องทำเพิ่ม:

จุดที่ผมอยากเน้น — DPIA เป็นเรื่องที่ต้องทำอยู่แล้วกับทุกฟีเจอร์ใหม่ ไม่ใช่เพิ่งมามีเพราะ AI. แต่พอเป็น third-party AI เราต้องทำ DPIA บวกกับ DPA เพิ่มเข้าไป. คิดง่ายๆ — DPIA คือ “เราประเมินความเสี่ยงเอง” ส่วน DPA คือ “เราผูกมัดคู่สัญญาให้รับผิดชอบ”.

1.4 กับดักที่เจ้าของกิจการตกบ่อยที่สุด — ข้อมูลรั่วเพราะ “คัดลอกไปใช้ผิดที่”#

มีกับดักหนึ่งที่ผมเห็นบ่อยมาก และคู่มือก็ยกเป็นตัวอย่างเตือน — คือเรื่อง “ข้อมูลที่ปลอดภัยในที่หนึ่ง กลับรั่วเพราะถูกคัดลอกไปใช้ในอีกที่หนึ่ง”.

ลองนึกภาพต่อจากสายการบินสมมติเราครับ. เดิมที ข้อมูลลูกค้าโปรแกรมสะสมไมล์ถูกเก็บอย่างดี — เข้าถึงได้เฉพาะคนกลุ่มเล็กๆ ที่ดูแลโปรแกรม, มีการควบคุมการเข้าถึงชัดเจน. ปลอดภัยมาก ในบริบทของ “การทำโปรแกรมสะสมไมล์”.

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

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

นี่คือบทเรียนสำคัญของ privacy ในยุค AI — ความปลอดภัยไม่ได้ติดมากับตัวข้อมูล แต่ติดมากับ “บริบทและสภาพแวดล้อม” ที่ข้อมูลถูกใช้. พอเอาข้อมูลออกจากสภาพแวดล้อมที่ปลอดภัย ไปไว้ในที่ใหม่ (เช่น environment ของทีม dev) ความปลอดภัยเดิมหายไปทันที.

และนี่ก็โยงไปอีกประเด็นที่คู่มือชี้ — เรื่อง dev กับ production environment. ทีมพัฒนาเคยชินกับการแยก environment ทดสอบ (dev) ออกจาก environment จริง (production). แต่พอเอา AI มาเสียบ คำถามใหม่โผล่มา:

• เมื่อ AI ที่เราใช้ ไม่ได้อยู่ในระบบปิดของเราเอง (เช่น เรียกใช้ AI ภายนอก) — ทั้งที่กระบวนการพัฒนาเราเป็นระบบปิด — จะเกิดความเสี่ยงด้านความปลอดภัยอะไรขึ้นบ้าง?
• ต้องเพิ่ม การป้องกันอะไร เพื่อไม่ให้เกิดเหตุการณ์ ข้อมูลรั่ว (data leakage)?

มุมผู้บริหาร: เวลาอนุมัติให้ทีมเอาข้อมูลลูกค้าไปทำ “โปรเจกต์ทดลอง AI” — อย่าคิดแค่ว่า “ข้อมูลต้นทางปลอดภัยดี”. ต้องถามต่อว่า “ข้อมูลจะถูกคัดลอกไปวางที่ไหน และที่นั่นปลอดภัยเท่าต้นทางไหม?” ส่วนใหญ่ข้อมูลไม่ได้รั่วจากที่เก็บหลัก — มันรั่วจาก “สำเนา” ที่ใครบางคนคัดลอกไปไว้ในที่ที่ไม่มีใครดูแล

1.5 Control สำหรับ Privacy ของ AI — เครื่องมือ 5 ตัวที่ผู้บริหารควรรู้จัก#

ทีนี้มาถึงส่วนที่ผู้บริหารต้อง “เลือกใช้” จริงครับ — มี control พื้นฐาน 5 ตัวสำหรับคุม privacy ของ AI. ผมเรียบเรียงเป็นตารางพร้อม “เลือกใช้เมื่อไหร่” เพื่อให้เป็น checklist ตัดสินใจได้:

ผมขอเน้น differential privacy อีกครั้ง เพราะมันเป็นคำตอบทางเทคนิคต่อปัญหา “สิทธิที่จะถูกลืม” ที่ผมเล่าไปข้อ 1.2. ไอเดียคือ — แทนที่จะให้โมเดลเรียนรู้ข้อมูลของแต่ละคน “ตรงๆ” เราใส่ “สัญญาณรบกวน” (noise) เข้าไปอย่างมีหลักการ ทำให้โมเดลเรียนรู้ “ภาพรวมของกลุ่ม” ได้ แต่ไม่สามารถ “ชี้ตัว” หรือ “พ่นข้อมูลของคนใดคนหนึ่ง” ออกมาได้. ผลคือ — ถึงแม้ลบ record คนนั้นไม่ได้จากในตัวโมเดล แต่โมเดลก็ “ไม่เคยจำเขาเป็นรายบุคคล” ตั้งแต่แรก ความเสี่ยงเลยต่ำลงมาก.

ในมุมผู้บริหาร — เราไม่ต้องรู้สูตรคณิตศาสตร์ของ differential privacy ครับ. เราแค่ต้องรู้ว่า “มีเครื่องมือนี้อยู่ และมันแก้ปัญหา ‘โมเดลจำข้อมูลคนจริง’ ได้” — แล้วถามทีมว่า “โปรเจกต์เราจำเป็นต้องใช้ไหม”. นั่นแหละคือการ “เลือก control ให้ถูก”.

2.1 เส้นแดง EU AI Act — งานที่ AI ทำไม่ได้เด็ดขาด (Unacceptable Uses)#

ในตอนก่อนๆ (Domain 2) ผมเคยเล่าเรื่อง EU AI Act ไว้แล้ว — กฎหมาย AI ของสหภาพยุโรปที่จัดระดับการใช้ AI เป็นชั้นๆ ตามความเสี่ยง (unacceptable / high / limited / minimal). ในตอนนี้ผมขอเจาะชั้นบนสุด — ชั้นที่เรียกว่า “unacceptable” (ยอมรับไม่ได้).

ชั้นนี้คือ “เส้นแดง” ครับ — การใช้ AI ที่ EU AI Act มองว่า “อาจสร้างความเสียหายร้ายแรงต่อมนุษย์” และ ห้ามทำเด็ดขาด ไม่ว่าจะคุ้มทางธุรกิจแค่ไหน. นี่คือรายการที่ผู้บริหารควรรู้จัก:

ผมรู้ว่ารายการนี้อ่านดูไกลตัวธุรกิจไทยทั่วไปครับ — เจ้าของร้านอาหารคงไม่คิดทำ “ระบบให้คะแนนสังคม”. แต่ประเด็นที่ผมอยากให้ติดไว้คือ บางเส้นแดง “ใกล้ตัว” กว่าที่คิด:

• ร้านค้าที่อยากเอา AI อ่านสีหน้าลูกค้า/พนักงาน เพื่อ “วัดความพอใจ” → เฉียดเส้น emotion recognition
• บริษัทที่อยากเอา AI ดูดรูปหน้าคนจากโซเชียล มาทำระบบจดจำลูกค้า → ชน untargeted facial scraping
• HR ที่อยากเอา AI จัดกลุ่มผู้สมัครจากลักษณะอ่อนไหว → เสี่ยง biometric categorization

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

2.2 กลยุทธ์ฝังจริยธรรมตั้งแต่ออกแบบ — 4 เรื่องที่ผู้บริหารต้องสั่งให้ทำ#

จริยธรรมไม่ใช่เรื่องที่ “มาคิดทีหลังตอนเกิดปัญหา” ครับ — มันต้องถูก คุยและบันทึกไว้ในกระบวนการกำกับดูแล (governance) ตั้งแต่ต้น และ ฝังความเสี่ยงด้านจริยธรรมเข้าไปในการออกแบบ control ทุกตัว. คู่มือแนะนำ 4 กลยุทธ์ ที่ผมเรียบเรียงเป็น “สิ่งที่ผู้บริหารสั่งให้ทำได้จริง”:

ผมชอบข้อ “ความหลากหลายในทีม” เป็นพิเศษครับ — เพราะมันแก้ปัญหา bias (อคติ) ได้ที่ต้นเหตุ. ถ้าทีมที่ออกแบบ AI เป็นคนกลุ่มเดียวกันหมด (เช่น วิศวกรชายอายุใกล้กัน) พวกเขามักมองข้ามผลกระทบต่อคนกลุ่มอื่นโดยไม่รู้ตัว. การมีคนหลากหลายในห้อง = มีคนช่วยทักว่า “เดี๋ยวนะ แบบนี้มันไม่แฟร์กับลูกค้ากลุ่ม X นะ” ตั้งแต่ก่อนปล่อยของ.

2.3 Ethics Controls — เครื่องมือคุมจริยธรรม 6 ตัว#

สุดท้ายของส่วน ethics — มาดู control จริงที่ผู้บริหารเลือกใช้ได้ครับ. มี 6 ตัวหลัก:

control ที่เป็น “หัวใจ” ของทั้งหมดคือ Human oversight (HITL) ครับ — เพราะมันคือคำตอบโดยตรงต่อปัญหา “AI ตัดสินใจเองโดยคนไม่ทันดู” ที่ผมเล่าไปต้นส่วน. แต่ HITL ไม่ใช่ “เอาคนมายืนดูเฉยๆ” — มันต้องออกแบบว่า “จุดไหนคนต้องอนุมัติก่อน, จุดไหน AI ทำเองได้แต่คนตรวจทีหลัง, จุดไหน AI ทำเองล้วนได้”. เรื่อง HITL ละเอียดนี้จะมาเต็มๆ ในส่วน Safety (3.9) ตอนถัดไป — ตอนนี้ขอแค่ปักหมุดว่า “มันคือ ethics control ที่สำคัญที่สุด” ไว้ก่อน

มุมผู้บริหาร: การตั้ง “คณะกรรมการจริยธรรม AI” ฟังดูเป็นเรื่องขององค์กรใหญ่ — แต่สำหรับธุรกิจ mass ไม่จำเป็นต้องตั้งคณะกรรมการเป็นทางการก็ได้. หัวใจคือ “มีคนที่ไม่ใช่คนสร้าง AI คอยตั้งคำถามจริยธรรมก่อนปล่อยของ”. อาจเป็นแค่การให้เจ้าของกิจการ + คนนอกทีมเทคนิค 1-2 คน นั่งคุยกัน 30 นาทีก่อนอนุมัติทุกโปรเจกต์ AI ก็พอ — สำคัญที่ “มีคนถาม” ไม่ใช่ “มีกระดาษ”