สารบัญ
AAISM Series — คู่มือคุม AI ในมุมคนบริหาร (ไม่ใช่มุมผู้ตรวจ) ตอนที่ 29 / Domain 3 — AI Technologies & Controls (บทเทคนิคที่สุด แต่เรายังเล่ามุมบริหาร) ซีรีส์นี้เล่าจากมุม “เจ้าของกิจการ / CISO ที่เอา AI มาใช้จริง” ว่าต้องตัดสินใจอะไรและรับความเสี่ยงเอง (สารบัญเต็มจะตามมา)
📚 ตอนนี้คำว่า “data governance” (การกำกับดูแลข้อมูลแบบเป็นระบบ) จะโผล่มาตลอดทั้งตอน ใครยังไม่แม่นว่าพื้นฐานมันคืออะไร — ใครเป็นเจ้าของข้อมูล, ใครเป็น data steward (คนดูแลข้อมูลรายชุด), การจัดชั้นความลับ, วงจรชีวิตข้อมูล (data life cycle) — ผมเล่าไว้ละเอียดแล้วที่ Database 101 — Data Governance ตอนนี้เราจะไม่สอนซ้ำ เราจะหยิบโครงเดิมนั้นมาใส่บริบท AI โดยเฉพาะ ว่ามันต่างจากการดูแลข้อมูลปกติยังไง และมีจุดไหนที่ AI ทำให้ของเดิมเปลี่ยนไปจนต้องคุมแน่นขึ้น
เราเดินทางมาถึง Domain 3 แล้วครับ โดเมนที่ใหญ่ที่สุดและเทคนิคที่สุดของทั้งเล่ม เป็นบทที่ว่าด้วย “เทคโนโลยี AI กับ control ที่ต้องเอามาคุมมันจริงๆ” ถ้า Domain 1 คือ “ตั้งกฎ ตั้งทีม ตั้งนโยบาย” และ Domain 2 คือ “มองให้ออกว่าเสี่ยงตรงไหน” Domain 3 ก็คือ “ลงมือคุมงานจริงในแต่ละวัน” เราจะไม่ได้คุยเรื่องลอยๆ อีกแล้ว แต่จะลงไปถึงระดับ “ข้อมูลชุดนี้มาจากไหน เก็บไว้ตรงไหน ใครเปิดดูได้ และพอเลิกใช้แล้วลบทิ้งยังไงให้สะอาด”
ก่อนอื่นขอเตือนตัวเองกับทุกคนไว้แต่เนิ่นๆ เราไม่ได้จะมาเป็นนักวิทยาศาสตร์ข้อมูล (data scientist) และไม่ได้จะมาเป็นผู้ตรวจสอบ (auditor) หน้าที่ของเราในฐานะคนบริหารคือ “เข้าใจพอที่จะเลือก control ให้ถูก” คือรู้ว่าข้อมูลมันเสี่ยงตรงไหนในเส้นทางของมัน แล้วเลือกได้ว่าจะวางการ์ดตรงไหน ใครต้องทำ และต้องเขียนอะไรลงนโยบาย ไม่ใช่ต้องลงไปเขียนโค้ดหรือเดินตรวจเอง
ทบทวนแว่นที่เราใส่ — AI = พนักงานใหม่เก่งๆ ที่ต้องกำกับ
ทั้งซีรีส์นี้ผมชวนมองว่า AI = พนักงานใหม่เก่งสุดๆ คนหนึ่งที่เราต้องกำกับ ไม่ใช่เครื่องวิเศษที่เสกแล้วจบ
มาถึง Domain 3 แว่นอันเดิมยังใช้ได้ แต่โฟกัสเปลี่ยนไปนิดนึง ถ้าก่อนหน้านี้เราคุยเรื่อง “จะรับพนักงานคนนี้เข้ามาไหม” และ “เขาอาจทำพังตรงไหน” ตอนนี้เราขยับมาที่ “ลงมือคุมงานเขาในแต่ละวันยังไง” โดยเฉพาะเรื่องที่สำคัญที่สุดของพนักงานคนนี้ นั่นคือ ข้อมูล
ลองคิดง่ายๆ ครับ พนักงานเก่งๆ คนนี้เก่งได้เพราะอะไร? เพราะ ข้อมูลที่เราป้อนให้เขากิน ถ้าเราป้อนข้อมูลที่เราไม่มีสิทธิ์ใช้ เขาก็พาเราไปผิดกฎหมาย ถ้าเราป้อนข้อมูลขยะ เขาก็ให้คำตอบขยะกลับมา ถ้าเราปล่อยให้ใครก็ได้เข้าถึงคลังข้อมูลที่เขาใช้ ความลับบริษัทก็รั่ว และพอเขาทำงานเสร็จ ข้อมูลที่เหลือค้างอยู่ในมือเขา ถ้าเราลืมเก็บกวาด — วันหนึ่งมันจะกลายเป็นระเบิดเวลา
เพราะฉะนั้น Data Governance สำหรับ AI ก็คือ “การคุมว่าพนักงานคนนี้กินอะไร, จับอะไร, เก็บอะไรไว้ และทิ้งอะไรยังไง” ตลอดเส้นทางตั้งแต่ข้อมูลเข้ามาจนถึงข้อมูลถูกทำลาย
มุมผู้บริหาร: คนส่วนใหญ่พอได้ยินคำว่า “AI” จะตื่นเต้นกับตัวโมเดล — โมเดลไหนเก่งกว่า, ตอบฉลาดแค่ไหน แต่ความจริงที่คนบริหารต้องจำให้ขึ้นใจคือ “ความเสี่ยงที่ทำให้บริษัทโดนปรับ โดนฟ้อง ข้อมูลหลุด ส่วนใหญ่ไม่ได้อยู่ที่ตัวโมเดล — มันอยู่ที่ข้อมูลที่ไหลเข้า-ไหลออกจากโมเดล” เพราะฉะนั้นถ้าคุณจะลงแรงคุมอะไรเป็นอันดับแรก ให้คุมข้อมูล ไม่ใช่ไปไล่เปรียบเทียบว่าโมเดลเจ้าไหนฉลาดกว่า
ภาพใหญ่ก่อน — ข้อมูลมีเส้นทางชีวิต และเราต้องคุมทุกป้าย
ตำรา AAISM วางกรอบ Data Governance สำหรับ AI ไว้ตามเส้นทางชีวิตของข้อมูล (data life cycle) — ตั้งแต่ “เกิด” จนถึง “ตาย” ผมขอวาดเป็นเส้นทางง่ายๆ แบบนี้ครับ:
[1] ได้ข้อมูลมา [2] จัดเตรียม [3] เอาไปใช้ + เก็บ [4] เก็บนาน + ทำลาย Acquisition → Organization & → Utilization & → Retention & (ที่มา + consent) Preparation Storage Destruction "มาจากไหน? "เส้นทางไหล/ "ใช้กับ AI/ "เก็บนานแค่ไหน/ ใช้ได้ไหม?" ใครแตะได้/ เก็บปลอดภัย/ ลบยังไงให้สะอาด?" ของจริงไหม?" เข้ารหัส?"จุดที่ต้องเข้าใจตั้งแต่ต้น — ทุกป้ายในเส้นทางนี้คือจุดที่ข้อมูลเปราะบาง (vulnerable) และต้องมี control คุม ตำราย้ำว่า “ความรับผิดชอบไม่ได้ขึ้นกับว่าเราถือข้อมูลไว้นานแค่ไหน” — เราจะถือข้อมูลไว้เสี้ยววินาทีหรือสิบปี ความรับผิดชอบเรื่อง CIA (ความลับ-ความถูกต้อง-ความพร้อมใช้) ก็เท่ากัน ถือปุ๊บก็รับผิดชอบปั๊บ
อีกประโยคที่ตำราเน้นและคนบริหารควรจำ Data Governance ของ AI ไม่ใช่ของใหม่ที่ต้องสร้างจากศูนย์ มันต้อง “ต่อยอดจากระบบดูแลข้อมูลเดิมที่บริษัทมีอยู่แล้ว” ถ้าระบบเดิมยังพัง (ข้อมูลกระจัดกระจาย ไม่รู้ว่าอะไรอยู่ไหน ไม่มีคนดูแลชัดเจน) แล้วเอา AI มาวางทับ มันจะยิ่งขยายรอยร้าวเดิมให้ใหญ่ขึ้น ไม่ใช่แก้
มุมผู้บริหาร: ถ้าทีมมาเสนอว่า “เราจะเริ่มทำ data governance สำหรับ AI ใหม่หมดเลยครับ แยกจากของเดิม” — ให้เบรกไว้ก่อน คำถามที่ต้องถามคือ “ระบบดูแลข้อมูลเดิมของเรามันใช้งานได้จริงไหม?” ถ้าใช้ได้ → ต่อยอด ถ้ายังพัง → ต้องซ่อมของเดิมให้ใช้ได้ก่อน เพราะการมีสองระบบที่ไม่คุยกันคือสูตรของหายนะ — ข้อมูลจะหลุดผ่านช่องว่างระหว่างสองระบบนั่นแหละ
ป้ายที่ 1 — Data Acquisition: ก่อนป้อนข้อมูลให้ AI ต้องถามว่า “มาจากไหน ใช้ได้ไหม”
นี่คือป้ายแรกและสำคัญที่สุดในมุมกฎหมาย ตำราเปรียบเทียบไว้สวยมาก ข้อมูลทุกชุดที่จะเอาไปป้อน AI ควรมี “เอกสารกำกับ” เหมือนสินค้านำเข้าที่ต้องมีใบขนส่งให้ศุลกากรตรวจก่อนเข้าประเทศ เราต้องตอบให้ได้ว่าข้อมูลนี้ มาจากไหน และ มีฐานทางกฎหมายอะไรให้เราเอามาใช้
ในทางปฏิบัติคือต้องมี 2 อย่าง อย่างแรกคือ ข้อตกลงการประมวลผลข้อมูล (data processing agreement) สัญญาที่ระบุว่าใครส่งข้อมูลให้ใคร ใช้ทำอะไรได้บ้าง อย่างที่สองคือ ขั้นตอนปฏิบัติงานมาตรฐาน (SOP) ที่บอกว่าข้อมูลนี้ที่มาคืออะไรและมีสิทธิ์รับมาใช้เพราะอะไร
5 คำถามที่ต้องถามก่อนรับข้อมูลเข้ามาใช้กับ AI
ตำราให้ชุดคำถามที่ทีมความปลอดภัยควรถามทุกครั้งก่อนรับข้อมูลเข้ามา ผมขอเรียบเรียงเป็นภาษาคนพร้อมตัวอย่างไทยสมมติ และเติมว่า “ถ้าตอบไม่ได้ คนบริหารควรทำยังไง”:
| # | คำถามที่ต้องตอบให้ได้ | แปลเป็นภาษาคน + ตัวอย่าง (สมมติ) | ถ้าตอบไม่ได้ → คนบริหารสั่งอะไร |
|---|---|---|---|
| 1 | ข้อมูลนี้มาจากไหน และตอนนี้เราอยู่ตรงไหนของวงจรชีวิตข้อมูลชุดนี้? | ถ้าบริษัท A ส่งข้อมูลให้บริษัท B ผ่านสัญญา — สัญญานั้นบอกชัดไหมว่า “แหล่งต้นทางจริงๆ” ของข้อมูลคือใคร? ลองนึกภาพบริษัทรับซื้อรายชื่อลูกค้ามาจากนายหน้า แต่ไม่รู้ว่านายหน้าไปเอามาจากไหนต่อ | ห้ามรับข้อมูลที่ “สาวต้นตอไม่ได้” เข้าระบบ AI — สั่งให้ทวนสัญญาจนเห็นต้นทางจริง |
| 2 | ถ้าไม่ใช่ข้อมูลส่วนบุคคล แล้วมีความรับผิดชอบอะไรติดมาบ้าง? | ข้อมูลที่ไม่เกี่ยวคนก็ใช่ว่าใช้ได้ตามใจ — มันอาจเป็น ความลับทางการค้า / ข้อมูลกรรมสิทธิ์ เช่น สูตรการผลิต ข้อมูลราคาต้นทุนของคู่ค้า ที่มีเงื่อนไขห้ามเอาไปใช้ต่อ | สั่งทีมกฎหมายระบุให้ชัดว่า “อะไรนับเป็นความลับ/กรรมสิทธิ์” ของข้อมูลชุดนี้ ก่อนเอาไปใช้ |
| 3 | ข้อมูลนี้นับเป็นข้อมูลส่วนบุคคลหรือเปล่า? | คำถามที่ดูง่ายแต่หลอก — เพราะข้อมูลที่ดูเหมือนไม่เกี่ยวคน บ่อยครั้ง โยงกลับไปหาคนได้ (เดี๋ยวขยายต่อ) | ถ้าตอบไม่ชัดว่าเป็นหรือไม่เป็น → ให้ถือว่า “เป็น” ไว้ก่อน แล้วคุมตามกฎคุ้มครองข้อมูล |
| 4 | มี consent (ความยินยอม) ครบไหม — และตรงกับสิ่งที่จะเอาไปทำหรือเปล่า? | จุดที่พลาดบ่อยมาก — เจ้าของข้อมูลยินยอมให้ใช้ “เพื่อทำงานประจำอัตโนมัติ” ไม่ได้แปลว่า ยินยอมให้เอาไปฝึกโมเดล AI ทำอย่างอื่น ขอบเขตของ consent ต้องตรงกับงานที่ทำจริง | ห้ามใช้ข้อมูลข้าม “วัตถุประสงค์ที่ขอ consent มา” — ถ้าจะใช้ใหม่ต้องไปขอ consent ใหม่ |
| 5 | ถ้ามี consent แล้ว — มันยังไม่หมดอายุใช่ไหม? | consent มีวันหมดอายุ! วันที่ยินยอมต้องสอดคล้องกับ นโยบายข้อมูลของบริษัท และ กฎหมายของประเทศที่เจ้าของข้อมูลอยู่ ลองนึกภาพ consent ที่ขอไว้เมื่อ 5 ปีก่อน ภายใต้กฎหมายคนละฉบับกับวันนี้ | ตั้งรอบทบทวน consent — ของที่หมดอายุ/กฎเปลี่ยน ต้องหยุดใช้จนกว่าจะ refresh |
กับดักที่อันตรายที่สุด — “consent มีแล้ว แต่ใช้ผิดวัตถุประสงค์”: นี่คือจุดที่บริษัทดีๆ โดนปรับกันมานักต่อนัก หลายคนเข้าใจว่า “มี consent = ทำอะไรกับข้อมูลก็ได้” — ผิดครับ consent มันมีขอบเขตติดมาด้วยเสมอ ลูกค้ายอมให้ใช้เบอร์โทรเพื่อยืนยันออเดอร์ ไม่ได้แปลว่ายอมให้เอาเบอร์ไปป้อน AI เพื่อทำนายพฤติกรรมการซื้อ การเอาข้อมูลไป “ใช้ใหม่” กับ AI โดยไม่ดูว่า consent เดิมครอบคลุมไหม คือความผิดพลาดอันดับต้นๆ — และ AI ทำให้มันเกิดง่ายขึ้นมาก เพราะป้อนข้อมูลทีนึงมันเอาไปใช้ได้สารพัด
ทำไม “ข้อมูลที่ดูไม่เกี่ยวคน” ถึงอันตรายกว่าที่คิด
ตำราชี้จุดที่คนมองข้ามบ่อย — ในยุคที่อุปกรณ์ IoT (อุปกรณ์ที่เชื่อมเน็ตได้ เช่น เซ็นเซอร์ กล้อง สมาร์ตวอตช์) เต็มไปหมด ข้อมูลที่เกี่ยวกับคนมันเพิ่มขึ้นแบบทวีคูณ และเส้นแบ่งระหว่าง “ข้อมูลคน” กับ “ข้อมูลไม่เกี่ยวคน” ก็เบลอลงเรื่อยๆ
ตัวอย่างที่ตำรายกไว้ดีมาก — สมมติเรามีชุดข้อมูล “อุณหภูมิน้ำ” ฟังดูไม่เกี่ยวคนเลยใช่ไหมครับ แต่พอคิดให้ลึก — ใครเป็นคนตัดสินใจว่าจะวัดที่จุดไหน, วางเครื่องมือตรงไหน, แม่นยำแค่ไหน สิ่งเหล่านี้ล้วนโยงกลับไปหา “คน” ทั้งนั้น ตำราใช้คำว่า “ลายนิ้วมือดิจิทัลของมนุษย์อยู่ในทุกขั้นตอนของการประมวลผลข้อมูล”
ในมุมบริหารแปลว่า อย่าเพิ่งวางใจว่าข้อมูลชุดนี้ “ไม่ใช่ข้อมูลส่วนบุคคล” แล้วจะใช้ได้สบาย ให้ตั้งสมมติฐานเริ่มต้นว่า “อาจโยงถึงคนได้” ไว้ก่อน แล้วค่อยพิสูจน์ว่าไม่โยง ปลอดภัยกว่ากลับด้านเยอะ
มุมผู้บริหาร: คำถามที่คนบริหารควรถามทีมทุกครั้งที่จะเริ่มโปรเจกต์ AI ใหม่คือสองข้อสั้นๆ — “ข้อมูลที่จะใช้มาจากไหน?” และ “เรามีสิทธิ์เอามาใช้แบบนี้จริงไหม?” ถ้าทีมตอบแบบกล้อมแกล้ม (“ก็เก็บๆ ไว้แหละครับ”, “น่าจะใช้ได้มั้ง”) — นั่นคือสัญญาณว่า ป้ายที่ 1 ยังไม่ผ่าน อย่าเพิ่งให้ไฟเขียว เพราะถ้าฐานข้อมูลตั้งต้นผิดกฎหมาย ทุกอย่างที่ต่อยอดจากมันก็เป็นผลไม้พิษหมด
ป้ายที่ 2 — Data Organization & Preparation: เส้นทางไหล, ใครแตะได้, ของจริงไหม
รับข้อมูลเข้ามาแล้ว ป้ายต่อไปคือการ “จัดบ้านให้ข้อมูล” ตำราย้ำหลักการสำคัญว่า ทีมพัฒนา AI ต้องทำงานใกล้ชิดกับทีม data governance และ กระบวนการ AI ต้องผ่านการตรวจสอบความปลอดภัยในระดับเดียวกับงานประมวลผลข้อมูลอื่นๆ ทุกประการ จะมาอ้างว่า “เป็น AI เลยขอข้ามขั้นตอน” ไม่ได้ ต้องเข้มเท่าเดิม จริงๆ เข้มกว่าด้วยซ้ำ
ตำราแบ่ง control หลักของป้ายนี้เป็น 3 ตัว ผมขอเล่าทีละตัวในมุมที่ว่า “คนบริหารต้องเข้าใจอะไรเพื่อสั่งให้ถูก”:
Control 2.1 — Dataflow Mapping: ทำแผนที่ “ทางเดินของข้อมูล”
Dataflow mapping คือการทำแผนที่ว่า ข้อมูลแต่ละชิ้นมันไหลไปไหนบ้าง ตั้งแต่ต้นทางจนปลายทาง — เหมือนทำผังว่าน้ำจากแหล่งต้นน้ำไหลผ่านท่อไหน เก็บที่ถังไหน ใช้ที่จุดไหน ตำราบอกว่ารายละเอียดควรมีพอๆ กับ “data dictionary” (พจนานุกรมข้อมูล — เอกสารที่อธิบายว่าข้อมูลแต่ละช่องหมายถึงอะไร) หรือบัญชีรายการข้อมูล (data inventory) ที่บริษัทควรมีอยู่แล้ว
จุดที่ AI ทำให้ต่างจากเดิมคือ แผนที่นี้ต้องละเอียดถึงระดับ “ฮาร์ดแวร์ที่ใช้ประมวลผล” ด้วย และต้องรู้ว่าข้อมูลอยู่ที่ไหนในทุกขั้นตอน ไม่ว่าจะ on-premises (เครื่องเราเอง), cloud (เครื่องเช่าบนเน็ต) หรือ hybrid (ผสม) และที่สำคัญที่สุดคือ ถ้า AI มีการ “ฝึกต่อ” (training) ที่ทำให้มันปรับตัวเองอัตโนมัติ ต้องรู้ว่าข้อมูลตัวไหนจะได้รับผลกระทบจากการฝึกนั้น และต้องมีแผนเฝ้าระวัง
ทำไมเรื่องนี้สำคัญในมุมบริหาร? ตำราบอกชัดว่า แผนที่นี้ต้องใช้ร่วมกับขั้นตอนเก็บหลักฐานในแผนรับมือเหตุการณ์ (incident response) พูดง่ายๆ คือ ถ้าวันหนึ่งข้อมูลหลุดหรือ AI ทำงานผิดพลาด แผนที่ dataflow นี่แหละที่จะบอกเราว่า “ความเสียหายไปถึงไหนแล้ว ข้อมูลอะไรกระทบบ้าง” ถ้าไม่มีแผนที่ พอเกิดเรื่องขึ้นมาเราก็งมอยู่ในความมืด ไม่รู้ด้วยซ้ำว่าต้องไปแจ้งใคร
มุมผู้บริหาร: ลองถามทีมว่า “ถ้าพรุ่งนี้ข้อมูลในระบบ AI ของเราหลุด คุณบอกผมได้ไหมภายใน 1 ชั่วโมงว่ามันกระทบข้อมูลของลูกค้ากี่ราย และข้อมูลนั้นไหลไปค้างอยู่ที่ไหนบ้าง?” — ถ้าทีมตอบไม่ได้ แปลว่า dataflow map ยังไม่สมบูรณ์ และนี่ไม่ใช่เรื่องเทคนิคจุกจิก — มันคือเรื่องที่จะตัดสินว่าบริษัทจะ “แจ้งเหตุข้อมูลรั่วได้ทันตามกฎหมาย” หรือ “โดนปรับซ้ำเพราะแจ้งช้า”
Control 2.2 — Access Control Review: ใครแตะข้อมูลได้ และแตะได้แค่ไหน
ป้ายนี้คือเรื่อง สิทธิ์เข้าถึงข้อมูล ตำราชี้จุดละเอียดที่คนชอบมองข้าม สิทธิ์ในแต่ละขั้นของข้อมูลควรแยกกัน ตัวอย่างที่ตำรายกคือ คนที่มีหน้าที่ “โหลดข้อมูลเข้าระบบ” (เขียนข้อมูลเข้า) ไม่จำเป็นต้องมีสิทธิ์ “เปิดดูข้อมูลที่เก็บไว้” (อ่านข้อมูลออก) สองอย่างนี้คนละสิทธิ์กัน และต้องแยกให้ชัด โดยเฉพาะสิทธิ์ “อ่าน” กับ “เขียน” ต่อข้อมูลที่เก็บอยู่ ต้องตรวจอย่างใกล้ชิด
หลักที่ตำราเน้นคือ principle of least privilege (หลักให้สิทธิ์น้อยที่สุดเท่าที่จำเป็น) — ให้เฉพาะคนที่จำเป็นจริงๆ เข้าถึง ชุดข้อมูลฝึก (training data), ชุดข้อมูลทดสอบ (testing data) และตัวโมเดลโดยตรง ได้ ไม่ใช่เปิดให้ทุกคนในทีมเข้าถึงหมด
ในมุมพนักงานใหม่เก่งๆ ของเรา เปรียบได้กับ “ห้องที่เก็บความรู้ลับของพนักงานคนนี้” เราไม่ปล่อยให้ใครเดินเข้าออกห้องนั้นได้ตามใจ มีแต่คนที่จำเป็นต้องเข้าจริงๆ เท่านั้น และคนที่เข้าไป “หยิบของวางลงชั้น” (เขียน) กับคนที่เข้าไป “อ่านของบนชั้น” (อ่าน) ก็เป็นคนละกุญแจกัน
กับดักที่พบบ่อย — “สิทธิ์เข้าถึงข้อมูลไหลข้ามฟังก์ชัน”: ตำราเตือนชัดในป้ายถัดไปด้วย — คนที่ทำงานกับข้อมูล “คล้ายๆ กัน” ในงานอื่น ไม่ควรได้สิทธิ์เข้าถึงข้อมูล AI โดยอัตโนมัติ ลองนึกภาพทีมการตลาดที่ดูข้อมูลลูกค้าเพื่อทำแคมเปญอยู่แล้ว — ไม่ได้แปลว่าเขาควรเข้าถึง “ชุดข้อมูลฝึก AI” ที่มีข้อมูลลูกค้าชุดเดียวกันได้ทันที เพราะวัตถุประสงค์การใช้ต่างกัน และความเสี่ยงก็ต่างกัน การ “ให้สิทธิ์เพราะดูคล้ายกัน” คือช่องโหว่ที่เงียบที่สุด
Control 2.3 — Data Integrity Monitoring: ข้อมูลที่ AI กินอยู่ “ยังเป็นของจริง” ไหม
Data integrity คือ “ความถูกต้องครบถ้วนของข้อมูล” — ป้ายนี้คือการเฝ้าระวังว่ากระบวนการที่ไป “ยุ่ง” กับข้อมูลก่อนป้อน AI ไม่ได้ทำให้ข้อมูลเพี้ยน ตำราระบุ 3 กระบวนการที่ต้องจับตา:
- Data minimization (การลดข้อมูลให้เหลือเท่าที่จำเป็น) — ตัดข้อมูลส่วนเกินทิ้ง เก็บเฉพาะที่ต้องใช้
- Data cleansing (การทำความสะอาดข้อมูล) — แก้ข้อมูลผิด ข้อมูลซ้ำ ข้อมูลขาด
- Data standardization (การจัดรูปแบบข้อมูลให้เป็นมาตรฐานเดียวกัน) — เช่น วันที่ต้องเขียนรูปแบบเดียวกันหมด
จุดที่ตำราเน้นคือ ทุกครั้งที่มีการ “จัดการข้อมูล” (data manipulation) คนที่เป็น data steward (ผู้ดูแลข้อมูลรายชุด) ต้องบันทึกรายละเอียดว่าทำอะไรไปบ้าง ทำไม? เพราะถ้าวันหนึ่ง AI ให้คำตอบแปลกๆ เราต้องสาวกลับได้ว่า “เพราะตอนเตรียมข้อมูลมีใครไปแก้อะไรหรือเปล่า”
นอกจาก 3 control หลักนี้ ตำรายังเพิ่มรายการที่ทีมความปลอดภัยต้องดูเป็นพิเศษสำหรับข้อมูลที่ AI ใช้:
| สิ่งที่ต้องทำเพิ่มสำหรับข้อมูล AI | แปลเป็นภาษาคน + ทำไมสำคัญ |
|---|---|
| ทบทวนข้อตกลงแบ่งปันข้อมูล (data sharing agreements) + เอกสารแผนที่ข้อมูลเฉพาะของโมเดลที่ใช้ | ดูให้ชัดว่า “ใครแชร์ข้อมูลให้ใคร ใช้ทำอะไรได้” — เอกสารนี้อาจเป็นภายในหรือภายนอก ขึ้นกับว่าเราพัฒนา AI เองหรือใช้ของคนอื่น |
| รู้ตำแหน่งข้อมูลที่ “พักชั่วคราว” (temporarily housed) — และลบทิ้งทันทีหลังประมวลผลเสร็จ | จุดที่คนลืมบ่อยมาก — AI มักสร้างข้อมูลพักชั่วคราวระหว่างทำงาน ถ้าลืมลบ มันค้างอยู่เป็นจุดรั่ว ตำราใช้คำว่า “ลบอย่างปลอดภัยทันที” |
| ใช้กระบวนการบริหารความเสี่ยงทุกครั้งที่นำเข้าข้อมูลจากแหล่งภายนอก | ข้อมูลจากข้างนอก = ความเสี่ยงใหม่ทุกครั้ง อย่ารับเข้ามาแบบไม่ประเมิน |
| เพิ่มการเฝ้าระวังความปลอดภัยเฉพาะกระบวนการ AI ซ้อนทับ การเฝ้าระวังปกติ | AI ต้องการการมอนิเตอร์ “ชั้นพิเศษ” เพิ่มจากที่ทำกับข้อมูลทั่วไปอยู่แล้ว ไม่ใช่แทนที่ |
| การตัดสินใจเรื่อง security ของ AI ต้องมาจากทีมที่ “รอบรู้และหลากหลาย” (informed and diverse team) | ไม่ปล่อยให้คนเดียว/แผนกเดียวตัดสิน เพราะ AI กระทบหลายมุม — กฎหมาย ความเป็นส่วนตัว เทคนิค ธุรกิจ |
มุมผู้บริหาร: สังเกตว่าตำราย้ำคำว่า “ทีมที่หลากหลาย” ซ้ำหลายรอบในเรื่อง AI — นี่ไม่ใช่ความถูกต้องทางการเมือง แต่เป็นเรื่องการบริหารความเสี่ยงจริงๆ เพราะการตัดสินใจเรื่องข้อมูล AI มันข้ามแดน ถ้าให้ทีม IT ตัดสินคนเดียว เขาจะมองแต่มุมเทคนิค ลืมมุมกฎหมาย/จริยธรรม/ธุรกิจ หน้าที่ของคนบริหารคือ “จัดให้การตัดสินใจสำคัญๆ เรื่องข้อมูล AI ผ่านสายตาหลายแผนก” ไม่ใช่ออกแบบให้เร็วแต่ตาบอดข้างเดียว
อีกประโยคที่ตำราทิ้งท้ายป้ายนี้และคนบริหารควรจำ — “ควรทำการประเมินความเสี่ยงด้านความปลอดภัย (security risk assessment) ทั้งก่อน ระหว่าง และหลังการประมวลผล AI” ไม่ใช่ประเมินครั้งเดียวตอนเริ่มแล้วจบ — เพราะข้อมูลและความเสี่ยงมันเคลื่อนตลอดเส้นทาง
ป้ายที่ 3 — Data Utilization & Storage: ตอนใช้งานจริงกับ AI ต้องคุมอะไร
ป้ายนี้คือ “ระหว่างที่ AI ทำงานจริง” ตำราบอกว่าการใช้ข้อมูลจะ เฉพาะทางมากขึ้น ตามชนิดของ AI ที่ใช้ และจุดสำคัญที่ตำรายกคือ ไม่ว่าจะ “สร้าง LLM ของบริษัทเอง” หรือ “เอา LLM สำเร็จรูปมาใช้” ก็มีข้อควรระวังด้านความปลอดภัยคล้ายกันมาก (LLM = large language model โมเดลภาษาขนาดใหญ่ แบบ ChatGPT)
ตำราชี้ 4 เรื่องที่ต้องคุมในป้ายนี้ ผมขอเล่าในมุมบริหาร:
3.1 — Privacy-by-design ต้องเฝ้าถี่ขึ้นเมื่อมี “การตัดสินใจอัตโนมัติ”
Privacy-by-design (ออกแบบให้ปกป้องความเป็นส่วนตัวตั้งแต่ต้น) เป็นหลักที่เรารู้กันอยู่แล้ว แต่ตำราเตือนว่าพอ AI มี automated decision making (การตัดสินใจอัตโนมัติ คือ AI ตัดสินเองโดยไม่มีคนกดยืนยันทีละครั้ง) ต้องเฝ้าหลักนี้ ถี่ขึ้นกว่าปกติ ไม่ว่าการตัดสินใจนั้นจะประมวลในระบบเราเองหรือพึ่งระบบภายนอก
ทำไม? เพราะ การตัดสินใจอัตโนมัติมันสร้าง “ข้อมูลใหม่” ขึ้นมา และข้อมูลใหม่นี้เสี่ยงต่อ hallucination (อาการ AI “มั่ว” คือสร้างคำตอบที่ฟังดูน่าเชื่อแต่ผิด) ซึ่งกลายเป็นความเสี่ยงด้านความปลอดภัยได้
3.2 — ข้อมูลใหม่ที่ AI สร้างขึ้น “ก็ต้องผ่านป้ายที่ 1 อีกรอบ”
นี่คือจุดที่ลึกและคนมองข้ามบ่อยสุด ตำราบอกชัดว่า เมื่อ AI สร้างข้อมูลใหม่ขึ้นมา (เช่น AI เขียนสรุป สร้างรายงาน สร้างคำทำนาย) ข้อมูลใหม่นั้นต้องผ่านกระบวนการ acquisition แบบเดียวกับป้ายที่ 1 อีกรอบ คือต้องถามว่า “ข้อมูลที่ AI สร้างนี้ ใช้ได้ไหม เก็บได้ไหม โยงถึงคนไหม”
แปลว่าวงจรนี้มัน วน ครับ ข้อมูลออกจาก AI ไม่ใช่ “จุดจบ” แต่เป็น “ข้อมูลใหม่ที่ต้องเริ่มดูแลตั้งแต่ต้นอีกครั้ง”
3.3 — Dynamic Information Flow Controls: กฎที่ปรับตามสถานการณ์
ตำราพูดถึง dynamic information flow controls คือนโยบายที่กำหนดว่า “ข้อมูลไหลไปไหนได้/ไม่ได้” โดย ปรับเปลี่ยนได้ตามสถานการณ์ เช่น เมื่อภัยคุกคามเปลี่ยน, ภารกิจเปลี่ยน, หรือระดับความเสี่ยงที่บริษัทรับได้ (risk tolerance) เปลี่ยน
พูดง่ายๆ คือ กฎการไหลของข้อมูลไม่ใช่ตั้งครั้งเดียวจบ แต่ต้องทบทวนและปรับได้ เหมือนด่านตรวจที่บางช่วงเข้มขึ้นบางช่วงผ่อนลง ตามสถานการณ์ภัย
3.4 — Storage + เข้ารหัส + จัดชั้นข้อมูลที่ AI สร้าง
ป้ายสุดท้ายของเรื่อง storage ตำราบอกว่า ข้อมูลที่ AI สร้างขึ้น ก็ต้องถูกจัดชั้นความลับ (classification) เหมือนข้อมูลอื่นๆ ของบริษัท ตามที่กำหนดไว้ในขั้นตอน dataflow mapping ไม่ใช่ว่า “AI สร้างมา เลยเป็นของไม่มีชั้น” และเรื่องที่ตำราเน้นเป็นพิเศษคือ encryption (การเข้ารหัส) ในทุกสถานะ และความสม่ำเสมอในการใช้
“ทุกสถานะ” หมายถึงเข้ารหัสตอนข้อมูลเก็บนิ่งอยู่ (at rest), ตอนข้อมูลวิ่งบนเครือข่าย (in transit), และในอุดมคติคือตอนกำลังประมวลผลด้วย (in use) คำสำคัญคือ “ความสม่ำเสมอ” เข้ารหัสบ้างไม่เข้ารหัสบ้างคือช่องโหว่ เพราะจุดที่ลืมเข้ารหัสนั่นแหละที่โจรเจาะ
มุมผู้บริหาร: ป้ายที่ 3 มีหลุมพรางอันใหญ่สำหรับคนบริหาร — “output ของ AI ก็คือข้อมูลที่ต้องดูแล ไม่ใช่ผลงานฟรีที่เอาไปใช้ได้เลย” หลายบริษัทลงทุนคุมข้อมูล “ขาเข้า” อย่างดี แต่พอ AI สร้างผลลัพธ์ออกมา กลับปล่อยให้พนักงานก๊อปไปแปะที่ไหนก็ได้ ส่งต่อใครก็ได้ ทั้งที่ในนั้นอาจมีข้อมูลส่วนบุคคล ความลับบริษัท หรือข้อมูลที่ AI มั่วขึ้นมา คำถามที่ต้องถามคือ — “ผลลัพธ์ที่ AI สร้าง เราจัดชั้นความลับมันหรือยัง และมันถูกเข้ารหัส/คุมการเข้าถึงเท่ากับข้อมูลต้นทางไหม?”
ป้ายที่ 4 — Data Retention & Destruction: เก็บนานแค่ไหน แล้วทิ้งยังไงให้สะอาด
ป้ายสุดท้าย และเป็นป้ายที่ “ไม่เซ็กซี่” ที่สุด เลยถูกละเลยมากที่สุด แต่กลับเป็นจุดที่เกิดเรื่องเงียบๆ บ่อยที่สุด
เก็บนานแค่ไหน — Retention Schedule
ตำราบอกชัด — บริษัทควรมี retention schedule (ตารางกำหนดระยะเวลาเก็บข้อมูล) ที่ครอบคลุม ทั้งข้อมูลที่ AI ใช้ และข้อมูลที่ AI สร้างขึ้น และต้องเฝ้าระวังความปลอดภัย + การพักข้อมูล (staging) อย่างสม่ำเสมอ
ประโยคที่คนบริหารต้องขีดเส้นใต้คือ “ข้อมูลที่ค้างอยู่หลังกระบวนการจบแล้ว เป็นความเสี่ยงที่สูงกว่า เพราะมันมักถูกลืม” ข้อมูลที่ไม่มีใครใช้แต่ยังนอนอยู่ในระบบ = ของล่อโจรที่ไม่มีใครเฝ้า และตำราย้ำว่า ข้อมูลทุกชิ้นที่เก็บไว้ ต้องมีเหตุผลเขียนกำกับในตาราง retention ว่าเก็บไว้ทำไม เก็บแบบ “เผื่อได้ใช้” โดยไม่มีเหตุผลชัด = ผิดหลัก
นอกจากนี้ ตำรายังบอกให้มี audit capability (ความสามารถในการตรวจสอบย้อนหลัง) ที่ให้ทีมความปลอดภัยดูได้ว่า ข้อมูลที่ไม่ได้ใช้งานแล้ว มีใครเข้าไปแตะบ่อยแค่ไหน เพราะการที่มีคนเข้าถึงข้อมูลเก่าที่ไม่ควรมีใครยุ่งแล้ว คือสัญญาณผิดปกติ
ทิ้งยังไงให้สะอาด — Data Destruction
ตำราวางหลักการทำลายข้อมูลไว้หลายชั้น ผมขอเรียบเรียง:
- ทำลายตามตาราง retention — ไม่ใช่ลบมั่วตอนนึกได้ และ ต้องมีเอกสารบันทึกการทำลาย (documentation of destruction) ตามกระบวนการทำลายข้อมูลของบริษัท — ลบแล้วต้องพิสูจน์ได้ว่าลบจริง
- กับดักสำคัญ — ถ้า AI ให้ผลลัพธ์ผิดปกติ อย่าเพิ่งลบ! ตำราเตือนว่า ถ้าข้อมูลจากกระบวนการ AI ออกมา “แปลก/ผิดคาด” ต้องพิจารณาก่อนว่า ควรทำ incident response (สอบสวนเหตุการณ์) ก่อนทำลายไหม เพราะข้อมูลนั้นอาจเป็น หลักฐานที่ต้องใช้สืบสวน — ลบทิ้งไป = ทำลายหลักฐานโดยไม่ตั้งใจ
- การตัดสินใจทำลายต้องผ่าน “โครงสร้างกำกับที่หลากหลาย” (diverse governance structure) — อีกครั้งที่ตำราย้ำว่าอย่าให้คนเดียวตัดสินเรื่องสำคัญ
- กำหนดระยะเก็บตั้งแต่ตอนออกแบบ — ตอนตัดสินใจเรื่อง acquisition/utilization/storage ต้องกำหนด “เก็บนานแค่ไหน” ไปพร้อมกันเลย ตามหลัก security-by-design — และ ข้อมูลที่ AI สร้างก็ต้องใช้เกณฑ์เดียวกัน ตำราบอกว่าควรระบุ retention ของข้อมูลที่ AI สร้างไว้ในขั้นตอน dataflow mapping และอาจ ตั้งให้ทำลายอัตโนมัติ ได้ด้วย
หลุมพรางพิเศษของ Deep Learning — “ข้อมูลที่ลบไม่เห็น”
ตำราทิ้งข้อควรระวังที่ลึกมากไว้ท้ายป้ายนี้ — สำหรับ Deep Learning (DL — การเรียนรู้เชิงลึกที่ใช้ neural network หลายชั้น) มีปัญหาพิเศษคือ “การสร้างและการลบข้อมูลอาจไม่โปร่งใสในทุกขั้นตอนของการประมวลผล”
แปลเป็นภาษาคน คือกับ AI แบบ DL บางที เราไม่เห็นด้วยซ้ำว่าข้อมูลถูกสร้างหรือถูกลบตรงไหนข้างใน เพราะมันเกิดในชั้นที่ซ่อนอยู่ (hidden layers) ที่มนุษย์มองไม่เห็นโดยตรง สิ่งนี้กระทบ integrity ของข้อมูล และสร้างช่องโหว่ที่คาดไม่ถึง ตำราจึงสรุปว่า DL ต้องการการเฝ้าระวังสภาพแวดล้อม (continual monitoring) ในระดับที่สูงกว่างานที่ไม่ใช่ AI มาก
กับดักที่อันตรายที่สุดของทั้งตอน — “ลืมเก็บกวาด”: ถ้าจะมีกับดักเดียวที่อยากให้เจ้าของกิจการจำจากตอนนี้ — คือ “ข้อมูลที่ค้างอยู่หลังเลิกใช้” เพราะมันเป็นจุดบอด: ไม่มีใครใช้ = ไม่มีใครดู = ไม่มีใครเฝ้า แต่มันยังมีค่าพอให้โจรอยากได้ และยังเป็นภาระตามกฎหมายอยู่ ที่แย่กว่านั้นคือกับ DL บางทีข้อมูลค้างอยู่ในที่ที่เรา “มองไม่เห็น” ด้วยซ้ำ ทางแก้ในมุมบริหารคือ — ทำให้การทำลายข้อมูลเป็นส่วนหนึ่งของแผนตั้งแต่วันแรก ไม่ใช่เรื่องที่ค่อยคิดทีหลัง และถ้าทำได้ ให้ตั้งระบบทำลายอัตโนมัติตามตาราง เพื่อไม่ต้องพึ่ง “ความจำของคน”
มุมผู้บริหาร: มีความตึงเครียดอันหนึ่งที่คนบริหารต้องตัดสิน — “เก็บข้อมูลไว้นาน = เสี่ยงและเป็นภาระ” แต่ “ลบเร็วไป = อาจทำลายหลักฐานที่ต้องใช้ตอนสอบสวน” ตำราให้ทางออกที่สมดุล: ลบตามตารางที่กำหนดไว้ล่วงหน้า ยกเว้น กรณีผลลัพธ์ผิดปกติที่อาจต้องสืบสวน — กรณีนั้นให้ “หยุด ตรวจสอบ แล้วค่อยตัดสินใจ” หน้าที่ของคนบริหารคือทำให้ทีมรู้ว่า “เมื่อไหร่ลบได้เลย เมื่อไหร่ต้องหยุดถามก่อน” — เขียนเป็นกติกาให้ชัด อย่าให้พนักงานเดาเอง
สรุปป้ายทั้ง 4 — ตารางที่คนบริหารเอาไปใช้ได้จริง
ก่อนไปดู control list สุดท้าย ผมขอรวบทั้ง 4 ป้ายไว้ในตารางเดียว เพื่อให้เห็นภาพว่า แต่ละป้าย คำถามหลักคืออะไร และ control หลักมีอะไร:
| ป้าย | คำถามหลักที่คนบริหารต้องตอบได้ | Control หลัก | จุดที่ AI ทำให้ต่างจากข้อมูลปกติ |
|---|---|---|---|
| 1. Acquisition (ได้ข้อมูลมา) | ข้อมูลมาจากไหน? เรามีสิทธิ์ใช้ไหม? consent ครบและตรงไหม? | data processing agreement, SOP, 5 คำถามตรวจที่มา/consent | consent ต้องตรง “วัตถุประสงค์ AI” ที่ทำจริง · ข้อมูลที่ดูไม่เกี่ยวคนก็อาจโยงถึงคน |
| 2. Organization & Prep (จัดเตรียม) | ข้อมูลไหลไปไหน? ใครแตะได้? ยังเป็นของจริงไหม? | dataflow mapping, access control review (least privilege), data integrity monitoring | แผนที่ต้องละเอียดถึงฮาร์ดแวร์ + รองรับการฝึกต่อ · ลบข้อมูลพักชั่วคราวทันที · เฝ้าระวังชั้นพิเศษ |
| 3. Utilization & Storage (ใช้ + เก็บ) | ใช้กับ AI ปลอดภัยไหม? เก็บ+เข้ารหัสครบไหม? | privacy-by-design (ถี่ขึ้น), dynamic flow controls, encryption ทุกสถานะ, จัดชั้น output | output ของ AI = ข้อมูลใหม่ที่ต้องดูแลตั้งแต่ต้นอีกรอบ · ระวัง hallucination |
| 4. Retention & Destruction (เก็บนาน + ทำลาย) | เก็บนานแค่ไหน? ลบยังไงให้สะอาด? ลบได้เลยหรือต้องสืบก่อน? | retention schedule, audit access, documented destruction, auto-destroy | DL อาจสร้าง/ลบข้อมูลในที่ที่มองไม่เห็น · ผลผิดปกติอาจต้องสืบก่อนลบ |
ป้ายที่ 5 — สรุป Control ที่ต้องเลือกใช้ (มุม “เลือกให้ถูก”)
ตำราปิดท้ายด้วยรายการ control มาตรฐานสำหรับ data governance ของ AI — ตรงนี้คือหัวใจของ Domain 3 ในมุมบริหาร เพราะหน้าที่เราคือ “เลือก control ให้ถูกกับความเสี่ยง” ไม่ใช่ใส่ทุกอันให้ครบแล้วงบบาน ผมขอเรียบเรียงเป็น 6 control พร้อมบอกว่า “คนบริหารควรถามอะไรก่อนเลือกใช้”:
| Control | ทำอะไร (ภาษาคน) | คนบริหารถามอะไรก่อนเลือก |
|---|---|---|
| เข้ารหัส + กำหนดระยะเก็บข้อมูล AI (retention & encryption protocols) | เข้ารหัสข้อมูล AI + ตั้งตารางว่าเก็บนานแค่ไหนชัดเจน | ”ข้อมูล AI ของเราเข้ารหัสครบทุกสถานะไหม และมีตารางลบที่บังคับใช้จริงไหม?” |
| ฐานข้อมูล AI รวมศูนย์ (centralized AI database management) | ตั้งฐานข้อมูลกลางเก็บรายละเอียด AI ที่เสี่ยงสูง + ตรวจ compliance สม่ำเสมอ + ให้แผนกคุยกัน | ”เรารู้ไหมว่าตอนนี้บริษัทมีระบบ AI เสี่ยงสูงกี่ตัว และข้อมูลมันถูกรวมศูนย์ให้ตรวจได้ไหม?” |
| ประเมินผลกระทบต่อความเป็นส่วนตัว (data privacy impact assessment) | ชุดเครื่องมือบังคับ encryption + anonymization (ลบตัวตน) + access control / มีช่องทางแจ้งเหตุละเมิด + คุ้มครองคนแจ้ง | ”ก่อนเปิดระบบ AI ที่แตะข้อมูลคน เราประเมินผลกระทบความเป็นส่วนตัวแล้วหรือยัง?” |
| จัดเก็บ + สำรองข้อมูล (data storage & archiving) | สำรองข้อมูลอัตโนมัติ + ทดสอบกู้คืนสม่ำเสมอ + สำรองทั้งโค้ด ข้อมูลฝึก ข้อมูลอ่อนไหว | ”ถ้าระบบ AI ล่ม เรากู้ข้อมูลฝึกและโค้ดกลับมาได้ไหม และเคยทดสอบจริงหรือเปล่า?” |
| ส่งข้อมูลปลอดภัย (secure data transfer) | เก็บข้อมูลฝึก AI ด้วยการเข้ารหัส + โปรโตคอลส่งข้อมูลปลอดภัย + firewall | ”ข้อมูลฝึกของเราตอนวิ่งไปมาในระบบ ถูกเข้ารหัสและผ่านด่านป้องกันครบไหม?“ |
| anonymization + access control (ฝังในการประเมินความเป็นส่วนตัว) | ลบ/บังตัวตนคนออกจากข้อมูล + คุมว่าใครเข้าถึงได้ + เทรนคนด้วยสถานการณ์จริง + ทดสอบเจาะระบบเป็นระยะ | ”เราลบตัวตนออกจากข้อมูลฝึกได้ไหม และเคยให้คนนอกลองเจาะดูจุดอ่อนไหม?” |
มุมผู้บริหาร: อย่าอ่าน control list นี้แล้ว “สั่งทำให้ครบทุกข้อ” — นั่นคือกับดักของคนที่อยากปลอดภัยแต่ไม่เข้าใจความเสี่ยง control แต่ละตัวมีต้นทุน (เงิน เวลา ความช้าของงาน) หน้าที่ของคนบริหารคือ “เลือก control ให้พอดีกับความเสี่ยงจริงของระบบนั้น” — ระบบ AI ที่แตะข้อมูลคนจำนวนมากและตัดสินใจสำคัญ ควรใส่ control เต็มชุด ส่วนระบบ AI ที่เล่นกับข้อมูลทั่วไปความเสี่ยงต่ำ ใส่เท่าที่จำเป็นก็พอ การ “เลือกให้ถูก” คืองานของเรา ไม่ใช่ “ใส่ให้ครบ” — เพราะงบและความเร็วของธุรกิจก็เป็นทรัพยากรที่ต้องบริหารเหมือนกัน
เชื่อมกับเฟรมเวิร์กสาธารณะ — เราไม่ได้คิดเรื่องนี้คนเดียว
เพื่อให้เห็นว่าหลักการในตอนนี้ไม่ใช่ของลอยๆ มีเฟรมเวิร์กสาธารณะที่พูดเรื่องเดียวกันและคนบริหารอ้างอิงได้:
- NIST AI Risk Management Framework (AI RMF 1.0) — กรอบบริหารความเสี่ยง AI ของรัฐบาลสหรัฐฯ ฟังก์ชัน MAP ของเขาว่าด้วยการรู้ว่าข้อมูลมาจากไหนและไหลไปไหน (ตรงกับป้าย 1-2 ของเรา) ส่วน MANAGE ว่าด้วยการคุมตลอดวงจร — อ่านได้ที่ nist.gov
- OWASP Top 10 for LLM Applications — รายการความเสี่ยงสำหรับแอป LLM โดยเฉพาะ มีข้อ Sensitive Information Disclosure (ข้อมูลอ่อนไหวรั่วผ่าน output) และ Data and Model Poisoning (ข้อมูลฝึกถูกวางยา) — ตรงกับเรื่อง output ที่เราต้องจัดชั้นและ integrity ที่เราต้องเฝ้า — owasp.org
- MITRE ATLAS — ฐานความรู้ภัยคุกคามต่อระบบ ML/AI โดยเฉพาะ มีเทคนิคโจมตีผ่านข้อมูลฝึกและ data supply chain — atlas.mitre.org
- พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (PDPA) — กฎหมายไทยที่บังคับเรื่อง consent, วัตถุประสงค์การใช้, และสิทธิเจ้าของข้อมูล — ตรงกับป้ายที่ 1 ของเราเป๊ะๆ ใครทำ AI กับข้อมูลคนไทยต้องดูตัวนี้ก่อนเลย
รวบให้จำ — Data Governance ของ AI ใน 5 ประโยค
ถ้าจะให้เจ้าของกิจการจำตอนนี้แค่ไม่กี่ประโยค ผมขอสรุปแบบนี้ครับ:
- ความเสี่ยงที่ทำให้บริษัทเจ็บจริง อยู่ที่ข้อมูลที่ไหลเข้า-ออกจาก AI ไม่ใช่ที่ตัวโมเดล — ลงแรงคุมข้อมูลก่อน
- ก่อนป้อนข้อมูล ถามสองคำ — “มาจากไหน?” และ “เรามีสิทธิ์ใช้แบบนี้จริงไหม?” — โดยเฉพาะเรื่อง consent ต้องตรงวัตถุประสงค์
- ต้องมีแผนที่ว่าข้อมูลไหลไปไหน + ใครแตะได้ (least privilege) — เพื่อตอบให้ได้ตอนเกิดเหตุว่า “เสียหายไปถึงไหน”
- output ของ AI ก็คือข้อมูลใหม่ที่ต้องดูแลตั้งแต่ต้นอีกรอบ — จัดชั้น เข้ารหัส คุมการเข้าถึง เหมือนข้อมูลต้นทาง
- ทำลายข้อมูลตามตารางตั้งแต่วันแรก — แต่ถ้าผลผิดปกติ หยุดสืบก่อนลบ และระวัง DL ที่ “ลบไม่เห็น”
ทั้งหมดนี้ร้อยกลับไปที่แว่นเดิม AI = พนักงานใหม่เก่งๆ ที่ต้องกำกับ และ Domain 3 ก็คือ “การลงมือคุมงานเขาในแต่ละวัน” โดยเริ่มจากสิ่งที่สำคัญที่สุดของพนักงานคนนี้ นั่นคือ คุมว่าเขากินอะไร จับอะไร เก็บอะไร และทิ้งอะไรยังไง
ตอนนี้เราคุยเรื่อง “การกำกับดูแลข้อมูล” (data governance) ซึ่งเป็นเรื่อง “นโยบายและกระบวนการ” — ป้ายต่อไปใน Domain 3 เราจะขยับเข้าใกล้ตัวข้อมูลมากขึ้น ไปสู่ “Data Security” — เรื่องที่ตึงเครียดที่สุดของยุค AI: ทำไม CIO/CISO ที่เคย “ล็อกข้อมูลให้แน่น” กลับถูกบอร์ดกดดันให้ “เปิดข้อมูลให้ AI ใช้มากขึ้น” แล้วเราจะบาลานซ์สองแรงที่สวนทางนี้ยังไง ไว้เจอกันตอนหน้าครับ
อ้างอิงเนื้อหา: AAISM — Domain 3: Section 3.4 (Data Governance — 3.4.1 Data Acquisition, 3.4.2 Data Organization & Preparation, 3.4.3 Data Utilization & Storage, 3.4.4 Data Retention & Destruction, 3.4.5 Summary of Data Governance Controls) แหล่งสาธารณะที่อ้างถึงโดยตรง: NIST AI Risk Management Framework (AI RMF 1.0) — MAP/MANAGE functions (nist.gov) · OWASP Top 10 for LLM Applications — Sensitive Information Disclosure & Data/Model Poisoning (owasp.org) · MITRE ATLAS — adversarial threats to ML data supply chain (atlas.mitre.org) · พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (PDPA)
