สารบัญ
AAISM Series — คู่มือคุม AI ในมุมคนบริหาร (ไม่ใช่มุมผู้ตรวจ) ตอนที่ 10 / Domain 1 — AI Governance & Program Management ซีรีส์นี้เล่าจากมุม “เจ้าของกิจการ / CISO ที่เอา AI มาใช้จริง” ว่าต้องตัดสินใจอะไรบ้าง (สารบัญเต็มจะตามมา)
📚 ตอนนี้ผมจะ ไม่ ปูพื้นตั้งแต่ศูนย์ว่า “data governance คืออะไร” หรือ “ทำไมต้องจัดประเภทข้อมูล” เพราะเล่าไว้ละเอียดแล้วสองที่ — เรื่องการดูแลข้อมูลแบบเป็นระบบ ใครเป็นเจ้าของข้อมูล ใครดูแล อ่านได้ที่ Database 101 — Data Governance ส่วนเรื่อง “จัดชั้นความลับของข้อมูล + วงจรชีวิตข้อมูล” อ่านได้ที่ CyberSecurity Foundation ตอนที่ 18 — Data Classification & Lifecycle ตอนนี้เราจะหยิบเฉพาะมุมที่ AI ทำให้เรื่องเดิมเปลี่ยนไป กับคำถามที่เจ้าของกิจการต้องตัดสินใจจริงๆ ครับ
ลองนึกภาพร้านอาหารแห่งหนึ่งที่เพิ่งจ้างเชฟใหม่เข้ามา (สมมติขึ้นมาให้เห็นภาพนะครับ) เชฟคนนี้ฝีมือดีมาก แต่มีนิสัยพิเศษอย่างหนึ่ง — เขาจะทำอาหารได้อร่อยแค่ไหน ขึ้นอยู่กับวัตถุดิบที่เราซื้อมาให้ล้วนๆ ถ้าเราให้ของสดเกรดดี เขาทำออกมาเป็นจานเด็ด ถ้าเราให้ของใกล้เสีย ผักช้ำ เนื้อไม่สด ต่อให้เขาเก่งแค่ไหน จานที่ออกมาก็พัง
ทั้งซีรีส์นี้ผมชวนมองว่า AI = พนักงานใหม่เก่งสุดๆ คนหนึ่งที่เราต้องกำกับ และในตอนนี้ ความจริงข้อหนึ่งของพนักงานคนนี้ก็คือ — เขาเก่งหรือพังขึ้นอยู่กับ “อาหาร” ที่เราป้อน อาหารของ AI คือ “ข้อมูล” ครับ
นี่ไม่ใช่คำพูดสวยๆ แต่เป็นความจริงเชิงเทคนิค ซอฟต์แวร์สมัยก่อนเราเขียนโค้ดบอกมันทีละขั้นว่าต้องทำอะไร (ผิดที่โค้ด ก็แก้โค้ด) แต่ AI ยุคนี้ “เรียนรู้” เอาเองจากข้อมูลที่เราป้อน เพราะฉะนั้นปัญหาของ AI ส่วนใหญ่ ไม่ว่าจะ AI ตอบมั่ว (hallucination) AI ลำเอียง หรือ AI ตัดสินใจพลาด สาวกลับไปแล้วมักเจอต้นตอที่ “ข้อมูล” ทั้งนั้น ข้อมูลที่เอียง ข้อมูลที่ไม่ครบ ข้อมูลที่ติดป้ายผิด ข้อมูลที่ไม่เกี่ยวข้อง
ฉะนั้นในมุมเจ้าของกิจการ คำถามของตอนนี้ไม่ใช่ “AI ทำงานยังไง” แต่เป็น “ฉันต้องออกแบบการคุม ‘ข้อมูล’ ยังไง ให้พนักงาน AI ของฉันได้กินของดี ไม่ใช่ของเสีย — และไม่ทำให้ฉันโดนฟ้องเรื่องข้อมูลลูกค้า” เรามาไล่กันทีละเรื่องครับ
ภาพรวมก่อน — 7 คำถามที่เจ้าของกิจการต้องตอบเรื่องข้อมูล AI
ตอนนี้เนื้อหาเยอะ ผมขอวางแผนที่ไว้ก่อนว่าเราจะเดินผ่านอะไรบ้าง ทุกหัวข้อจริงๆ แล้วคือ “คำถามที่ผู้บริหารต้องตอบ” ทั้งนั้น:
| เรื่อง | คำถามที่เจ้าของกิจการต้องตอบ |
|---|---|
| บัญชีข้อมูล (Data Inventory/Catalog) | เรามีข้อมูลอะไรบ้าง เก็บที่ไหน ใครเป็นเจ้าของ — เรารู้จริงไหม? |
| ตามรอยข้อมูล (Dataflow & Lineage) | ข้อมูลไหลจากไหนไปไหน ตอนพังจะตามต้นตอเจอไหม? |
| จัดประเภท (Classification) | ข้อมูลชิ้นไหนลับ ชิ้นไหนเปิดเผยได้ — ปนกันมั่วรึเปล่า? |
| เก็บข้อมูลมาฝึก (Collection: consent / fit-for-purpose / data lag) | เอาข้อมูลลูกค้ามาฝึก AI ได้ไหม ขอความยินยอมหรือยัง ข้อมูลเก่าไปรึเปล่า? |
| คุณภาพข้อมูล (Data Quality) | ข้อมูลที่ป้อนเข้าไปสะอาดพอไหม หรือป้อนขยะเข้า-ได้ขยะออก? |
| ข้อมูลเอียง / ข้อมูลขาด (Balancing & Scarcity) | ข้อมูลเรากระจุกตัวจนทำให้ AI ลำเอียงไหม ข้อมูลที่ใช้ได้จริงพอไหม? |
| บัตรประจำตัวโมเดล (Model Card) | โมเดลที่เราใช้/ซื้อมา มี “ฉลากกำกับ” บอกความสามารถและข้อจำกัดไหม? |
ไม่ต้องตกใจกับจำนวนนะครับ จริงๆ มันต่อเนื่องกันเป็นเรื่องเดียว เริ่มจากรู้ว่ามีข้อมูลอะไร แล้วรู้ว่ามันไหลไปไหน จากนั้นจัดชั้นมัน เลือกเก็บมาฝึกอย่างถูกกฎ เช็คว่าสะอาดและไม่เอียง แล้วก็ติดฉลากให้โมเดล เดินตามนี้แล้วจะเห็นภาพเอง
เรื่องที่ 1 — บัญชีข้อมูล (Data Inventory): “เรามีของอะไรบ้าง ในครัวเรารู้ไหม”
กลับไปที่ร้านอาหารของเรา ก่อนเชฟจะทำกับข้าวได้ เราต้องรู้ก่อนว่าในตู้เย็น ในสต็อก เรามีวัตถุดิบอะไรบ้าง อยู่ตรงไหน ของชิ้นไหนใกล้หมดอายุ ใครเป็นคนสั่งเข้ามา ถ้าครัวไหน “ไม่รู้ว่าตัวเองมีของอะไร” ครัวนั้นวุ่นวายแน่นอน
องค์กรก็เหมือนกันครับ Data Inventory (บัญชีข้อมูล) คือรายการของ “ทรัพย์สินข้อมูล” ทั้งหมดที่องค์กรมี ฟังดูพื้นๆ แต่เชื่อไหมว่าบริษัทจำนวนมากตอบไม่ได้ว่าตัวเองมีข้อมูลอะไรเก็บไว้ที่ไหนบ้าง พอจะเอา AI มาใช้ทีนี้ถึงค่อยมาตกใจ
มันมีของอยู่ชุดหนึ่งที่คนชอบสับสน เพราะชื่อคล้ายกัน ผมขอแยกให้เห็นด้วยภาษาคน:
| คำศัพท์ | ภาษาคน | มันคืออะไร |
|---|---|---|
| Data Inventory | ”บัญชีรวมของทั้งบ้าน” | รายการทรัพย์สินข้อมูลทั้งหมดในองค์กร |
| Data Dictionary | ”ฉลากในตู้แต่ละใบ” | บัญชีข้อมูลระดับ “แอปฯ เดียว” — บอกว่าในระบบนี้มีข้อมูลอะไรบ้าง แต่ละช่องหมายถึงอะไร |
| Business Glossary | ”ภาษากลางของบ้าน” | รายการ “นิยามคำ” ที่ใช้ร่วมกัน เช่น คำว่า “ลูกค้า” ในทุกระบบหมายถึงอันเดียวกัน |
| Data Catalog | ”สมุดสารบัญใหญ่ของทั้งบ้าน” | บัญชีข้อมูลแบบละเอียดของทั้งองค์กร ที่ผูกบัญชีข้อมูลเข้ากับบริบทธุรกิจ (เก็บ “ข้อมูลเกี่ยวกับข้อมูล” ไม่ได้เก็บตัวข้อมูลจริง) |
จุดที่เจ้าของกิจการควรเก็บไปคิดคือ — Data Catalog เก็บแต่ metadata (ข้อมูลที่อธิบายข้อมูลอีกที เช่น ใครเป็นเจ้าของ จัดชั้นความลับไว้ระดับไหน อัปเดตล่าสุดเมื่อไหร่) ไม่ได้เก็บตัวข้อมูลจริง เหมือนสารบัญหนังสือที่บอกว่าเรื่องไหนอยู่หน้าไหน แต่ไม่ได้ก๊อปเนื้อหาทั้งเล่มมาไว้
แล้วใครทำอะไรในระบบนี้? source แบ่งบทบาทไว้ชัดเจน ผมเรียบเรียงเป็น 3 ฝ่าย:
- Data Stewards (ผู้เชี่ยวชาญเนื้อข้อมูล) — คนที่ “รู้เรื่องข้อมูลนั้นจริง” หน้าที่คือดูแล เพิ่มกฎเชิงธุรกิจ ใส่บริบทองค์กร จดบันทึก
- ตัว Data Catalog เอง — เก็บ glossary, dictionary, metadata, การติดป้าย (tagging), การจัดหมวด, การตามรอย (lineage), คุณภาพ, audit trail ฯลฯ
- ฝ่าย Governance (กำกับดูแล) — ตั้งนโยบาย คุมกระบวนการ ดูแลเรื่องกฎหมาย (เช่น GDPR) จัดการความเสี่ยง อนุมัติหรือปฏิเสธการเปลี่ยนแปลง
มุมผู้บริหาร: สิ่งที่คุณต้องตัดสินใจที่นี่ไม่ใช่ “จะใช้เครื่องมือ catalog ตัวไหน” (นั่นงานทีม IT) แต่คือ “ใครเป็นเจ้าของข้อมูลแต่ละชุด (Data Owner) และใครดูแลความปลอดภัยมัน (Data Custodian)” ถ้าตอบสองคำถามนี้ไม่ได้ AI project ของคุณจะสะดุดตั้งแต่ก้าวแรก เพราะไม่มีใครยอมเซ็นอนุมัติให้เอาข้อมูลไปใช้ — ไม่ใช่เพราะหวง แต่เพราะ “ไม่รู้ว่าตัวเองมีสิทธิ์เซ็นไหม”
ทำบัญชีข้อมูลยังไง — 4 ขั้นแบบเข้าใจง่าย
ถ้าองค์กรยังไม่มีคลัง metadata กลาง แต่ต้องการทำบัญชีข้อมูล (เช่น เพื่อทำ Privacy Impact Assessment — การประเมินผลกระทบด้านความเป็นส่วนตัวก่อนเอาข้อมูลไปใช้) source แนะนำวิธีง่ายๆ 4 ขั้นที่ผมขอเล่าด้วยภาษาคน:
- Plan (วางแผน) — กำหนดก่อนว่า “ข้อมูล” ในนิยามของเราคืออะไร จะรวมกระดาษด้วยไหม จะรวมข้อมูลที่ vendor สร้างให้ไหม ขอบเขตแค่ไหน
- Decide (ตัดสินใจ) — ตกลงว่าจะบันทึก “คุณสมบัติ” อะไรของข้อมูลบ้าง (เช่น ใครสร้าง ใครเป็นเจ้าของ เก็บที่ไหน อัปเดตบ่อยแค่ไหน มีสิทธิ์ใช้ได้แค่ไหน)
- Populate (เก็บข้อมูลเข้า) — ลงมือรวบรวมจริง ด้วยวิธีต่างๆ เช่น ให้เจ้าของข้อมูลกรอกเอง สัมภาษณ์ ทำแบบสอบถาม หรือทำระบบอัตโนมัติให้กรอกฟอร์มทุกครั้งที่สร้างข้อมูลใหม่
- Publish (เผยแพร่) — รวบรวมแล้วทำให้คนเข้าถึงได้ อาจเป็นแค่ Excel หรือทำเป็นฐานข้อมูลเลยก็ได้ แต่ ต้องดูความลับก่อนเผยแพร่ บางชุดต้องขออนุญาตก่อนถึงดูได้
และนี่ไม่ใช่ทำครั้งเดียวจบ — ข้อมูลองค์กรเปลี่ยนตลอด ฉะนั้น 4 ขั้นนี้ควรวนทำเป็นรอบ เช่น ปีละครั้ง หรือเมื่อมีเหตุใหญ่ (ควบรวมกิจการ ปิดโครงการใหญ่)
มุมผู้บริหาร: “คุณสมบัติของข้อมูล” ที่ควรบังคับให้บันทึกอย่างน้อยที่สุด ในมุมคนบริหารคือ 4 ตัวนี้ — ใครเป็นเจ้าของ (Data Owner), จุดประสงค์ที่เก็บมา (Purpose), เก็บไว้ที่ไหน (Location), และสิทธิ์/ข้อจำกัดในการใช้ (Rights & Restrictions) เพราะสี่ตัวนี้คือสิ่งที่จะถูกถามแน่ๆ ตอนมีคนขอเอาข้อมูลไปฝึก AI — โดยเฉพาะช่อง “จุดประสงค์ที่เก็บมา” จะกลับมาหลอกหลอนเราในเรื่อง consent ที่จะเล่าต่อไป
เรื่องที่ 2 — ตามรอยข้อมูล (Dataflow & Lineage): “วัตถุดิบชิ้นนี้มาจากไหน ไปไหนต่อ”
รู้ว่ามีของอะไรแล้ว ทีนี้ต้องรู้ว่า ของมัน “ไหล” ไปไหนบ้าง ในร้านอาหาร วัตถุดิบไม่ได้อยู่นิ่งๆ มันเดินทาง — จากซัพพลายเออร์ → เข้าตู้เย็น → เข้าครัว → ออกเป็นจาน ถ้าวันหนึ่งลูกค้าท้องเสีย เราต้องตามรอยกลับได้ว่าวัตถุดิบชิ้นไหนเป็นต้นเหตุ มาจากซัพพลายเออร์เจ้าไหน
ข้อมูลในองค์กรก็เดินทางแบบนี้ครับ และมันมักจะ “ไหลตามทางที่ง่ายที่สุด” (path of least resistance) เพราะคนส่วนใหญ่มองข้อมูลเป็นแค่ “เครื่องมือ” ไม่ใช่ “ทรัพย์สินที่ต้องดูแล” ผลคือถ้าไม่มีมาตรฐานคุม ข้อมูลก็ไหลกระจัดกระจายไปทั่ว ควบคุมคุณภาพและความเป็นส่วนตัวไม่ได้
เครื่องมือที่ใช้มองเรื่องนี้มีหลายแบบ ผมขอแยกให้เห็นบทบาทต่างกัน:
| เครื่องมือ | มองแบบไหน | เหมาะกับ |
|---|---|---|
| Dataflow Diagram | มองแนวนอน — ข้อมูลไหลจาก “ระบบไป-ระบบ” ในภาพกว้าง (ต้นทาง → ประมวลผล → ปลายทาง) | ดูภาพรวมว่าข้อมูลวิ่งข้ามระบบทั้งองค์กรยังไง |
| Usage/Activity Diagram | มองแนวตั้ง — ข้อมูลผ่าน “ขั้นตอนการทำงาน” ทีละสเต็ปในแอปฯ เดียว | ดูรายละเอียดเวิร์กโฟลว์ซับซ้อน เพื่อคุมคุณภาพ/ความเป็นส่วนตัว |
| Value Stream + Swim Lanes | มองว่า “ใคร/ฝ่ายไหน” แตะข้อมูลในแต่ละขั้น | ดูว่าแต่ละแผนก (ขาย, สัญญา, กฎหมาย, จัดส่ง) จับข้อมูลตรงไหนบ้าง |
สองตัวแรกไม่ได้แทนกัน แต่ เสริมกัน — Dataflow Diagram ดูภาพกว้าง, Usage Diagram ดูรายละเอียด อยากคุมเรื่องความเป็นส่วนตัวให้ดี ควรมีทั้งคู่
Data Lineage — สายเลือดของข้อมูล
ทีนี้มาถึงคำที่สำคัญที่สุดของเรื่องนี้ครับ Data Lineage (การตามรอยสายข้อมูล) คือการตามรอยข้อมูลให้ไกลกว่าแค่ “ระบบที่บันทึกครั้งแรก” — ตามไปทั้งสาย ตั้งแต่แหล่งกำเนิด ผ่านการแปลงรูป (transform) เก็บที่ไหน เอาไปใช้ทำอะไร ออกผลลัพธ์อะไร
ทำไมเรื่องนี้ถึงสำคัญกับ AI มาก? ลองนึกภาพว่าวันหนึ่ง AI ของคุณให้ผลลัพธ์ที่ผิดพลาด หรือมีคนร้องเรียนว่า “ทำไม AI เอาข้อมูลส่วนตัวฉันไปใช้” ถ้าคุณมี data lineage ที่ดี คุณจะตามรอยกลับได้ว่า ข้อมูลก้อนที่มีปัญหานี้มาจากแหล่งไหน ผ่านมือใครมาบ้าง ซึ่งสำคัญมากทั้งตอนหาสาเหตุปัญหา (root cause) และตอนต้องพิสูจน์กับหน่วยงานกำกับว่าเราคุมข้อมูลส่วนบุคคล (PII/PHI) ได้จริง
ข้อจริงที่ต้องยอมรับ — data lineage ทำมือไม่ไหวครับ ขอบเขตมันใหญ่และเปลี่ยนตลอด ฉะนั้นต้องใช้เครื่องมือช่วยอัตโนมัติ และเคล็ดลับสำคัญคือ อย่าพยายามทำทั้งองค์กรพร้อมกัน — ให้เริ่มจากระบบที่สำคัญที่สุดก่อน แล้วไล่ย้อนจากปลายน้ำขึ้นต้นน้ำ
มุมผู้บริหาร: คำถามทดสอบง่ายๆ ที่เจ้าของกิจการถามทีมได้เลยคือ — “ถ้าพรุ่งนี้ลูกค้าคนหนึ่งขอให้เราลบข้อมูลเขาออกจากระบบ AI ทั้งหมด เราตามไปลบได้ครบทุกที่ไหม?” ถ้าทีมตอบไม่ได้แบบมั่นใจ แปลว่า data lineage ของเรายังไม่พอ และนั่นคือความเสี่ยงทางกฎหมายโดยตรง (PDPA ให้สิทธิ์เจ้าของข้อมูลขอลบได้)
เรื่องที่ 3 — จัดประเภทข้อมูล (Classification): “ของลับ vs ของเปิดเผยได้”
เรื่องการจัดชั้นความลับของข้อมูลพื้นฐาน ผมเล่าไว้ใน CyberSec EP.18 แล้ว ตอนนี้ขอย้ำแค่หลักการสั้นๆ แล้วโฟกัสว่า AI ทำให้เรื่องนี้เปลี่ยนไปยังไง
หลักการคือ ข้อมูลไม่ได้สำคัญเท่ากันหมด เราจึง “จัดประเภท” มันตามลักษณะร่วม ที่น่าสนใจคือข้อมูลชิ้นเดียวถูกจัดได้หลายแบบพร้อมกัน (เหมือนปลาโลมาเป็นทั้ง “สัตว์เลี้ยงลูกด้วยนม” และ “สัตว์น้ำ” ได้พร้อมกัน) source แบ่งการจัดประเภทไว้ 3 มุมหลัก ผมเรียบเรียงเป็นตาราง:
| มุมการจัดประเภท | คืออะไร | ตัวอย่าง |
|---|---|---|
| Critical Data Elements (ข้อมูลสำคัญยิ่งยวด) | ข้อมูลที่กระทบธุรกิจหนักที่สุด ต้องติดป้าย-ตามรอยเป็นพิเศษ มักหาเจอจากการดูว่ากระบวนการไหนสำคัญสุด (จาก BIA) | ข้อมูลที่ถ้าหายแล้วธุรกิจหยุดชะงัก |
| Data Security Level (ระดับชั้นความลับ) | จัดตามว่าใครเข้าถึงได้ — Public / Internal / Confidential / Restricted | Public = ข่าวประชาสัมพันธ์ · Restricted = ข้อมูลที่หลุดแล้วถึงขั้นโดนคดี |
| Data Sensitivity Type (ประเภทความอ่อนไหว) | ข้อมูลบางชนิดต้องดูแลพิเศษ เช่น PII (ข้อมูลระบุตัวตน), PHI (ข้อมูลสุขภาพ) — และแต่ละประเทศนิยามไม่เหมือนกัน | ในยุโรป “ศาสนา/การเป็นสมาชิกสหภาพแรงงาน” ถือว่าอ่อนไหว แต่ในสหรัฐฯ ไม่ |
จุดที่อยากให้เจ้าของกิจการจำคือ — ระดับชั้นความลับเป็นตัวกำหนดว่าต้องคุมข้อมูลด้วยมาตรการอะไร (เช่น ต้องเข้ารหัสไหม แชร์ออกนอกได้ไหม) และมาตรฐานการจัดชั้นนี้ต้องทำร่วมกันทั้งองค์กร — ฝ่ายธุรกิจ, privacy, security, compliance ต้องนั่งโต๊ะเดียวกัน ไม่ใช่ให้ฝ่าย IT คิดเองคนเดียว
AI Data Classification — ทำไม AI ทำให้เรื่องเดิม “ยากขึ้น”
นี่คือมุมที่ AI เพิ่มเข้ามาจริงๆ และเจ้าของกิจการต้องระวัง การจัดประเภทข้อมูลที่เคยยากอยู่แล้ว พอมี AI ยิ่ง ยากขึ้นไปอีก ด้วยสองสถานการณ์:
สถานการณ์แรก — ของลับกับของไม่ลับปนกันจนแยกไม่ออก ลองนึกภาพบริษัทซอฟต์แวร์แห่งหนึ่ง (สมมตินะครับ) ที่เขียนโค้ดเอง ซึ่งโค้ดนั้นถือเป็นความลับและทรัพย์สินทางปัญญา (IP) แต่ในโค้ดเดียวกันนั้นก็มีการหยิบ open-source ของคนอื่นมาผสม ทีนี้พอจะเอาโค้ดทั้งกองนี้ไปฝึก AI ช่วยเขียนโปรแกรม — มันแยกไม่ออกแล้วว่าตรงไหนของเรา (ลับ) ตรงไหนของคนอื่น (เปิด) จัดชั้นผิดเมื่อไหร่ก็เกิดความเสี่ยงทันที
สถานการณ์ที่สอง — เอาข้อมูลลับไปฝึกโมเดลที่คนนอกใช้ได้ อันนี้อันตรายมาก ลองนึกภาพว่าเราเอา “ข้อมูลลับของลูกค้า” ไปฝึกโมเดล แล้วเอาโมเดลนั้นไปเปิดให้คนทั่วไปใช้ — ความลับที่ฝังอยู่ในโมเดลอาจ “รั่ว” ออกมาทางคำตอบได้ ฉะนั้นต้องเช็คให้ตรงกันเสมอว่า ความอ่อนไหวของข้อมูลที่เอาไปฝึก ต้องไม่สูงกว่าสิทธิ์ของคนที่จะมาใช้โมเดล
Data Confidentiality — ความลับต้องตามติดข้อมูลทุกจุด
มีกับดักทางเทคนิคหนึ่งที่เจ้าของกิจการควรรู้ไว้ (จะได้ถามทีมถูก) — เวลาข้อมูลเดินทางผ่านขั้นตอนการพัฒนา AI “ป้ายกำกับความลับ” มักหล่นหายระหว่างทาง ผมสรุปจุดเสี่ยงเป็นตาราง:
| ข้อมูลอยู่ตรงไหน | กับดักที่ต้องระวัง |
|---|---|
| ต้นทางข้อมูล (Data Source) | พอดึงข้อมูลออกมา metadata (เจ้าของ, ชั้นความลับ) และ control (สิทธิ์เข้าถึง, การปิดบัง) อาจ ไม่ติดตามมาด้วย |
| Data Lake (ทะเลสาบข้อมูล) | เอาข้อมูลทุกชั้นความลับมากองรวมกันเพื่อสะดวกในการสร้างโมเดล → ของที่เคยลับอาจหลุดให้คนทั่วไปเห็น ถ้าไม่รักษาสิทธิ์เข้าถึงเดิมไว้ |
| แพลตฟอร์มสำรวจ/ฝึกข้อมูล (เช่น Jupyter Notebook) | ข้อมูลหลายชั้นความลับถูกเก็บปนกันในไฟล์ทดลอง |
| Vector Database | ฐานข้อมูลแบบใหม่ที่แปลงเอกสาร/ภาพ/เสียงเป็น “เวกเตอร์” (ตัวเลขทางคณิตศาสตร์) — ของเดิมไม่ได้เก็บตรงๆ แต่ต้องคิดวิธีคุมการเข้าถึงแบบใหม่ |
| ระบบ AI ตอนใช้งานจริง (Production) | ข้อมูลสดที่ไหลเข้าโมเดลตอนใช้งาน ก็ต้องมีการจัดชั้น/คุมเหมือนตอนฝึก |
มุมผู้บริหาร: คำถามที่ผู้บริหารควรถามทีมเทคนิคคือ — “ตอนเราเอาข้อมูลจากระบบเดิมไปกองรวมใน data lake เพื่อฝึก AI สิทธิ์การเข้าถึงเดิมยังอยู่ไหม หรือกลายเป็นว่าใครก็เปิดดูได้?” เพราะกับดักที่เจ็บที่สุดคือข้อมูลที่เคยล็อกแน่นหนาในระบบเดิม พอย้ายมา data lake แล้ว “หลุดล็อก” โดยไม่มีใครตั้งใจ
เรื่องที่ 4 — เก็บข้อมูลมาฝึก AI (Data Collection): consent, fit-for-purpose, data lag
มาถึงเรื่องที่ผมว่าเครียดที่สุดสำหรับเจ้าของกิจการ — การเอาข้อมูลมาฝึก AI เพราะมันแตะเรื่องกฎหมายโดยตรง
ก่อนอื่น องค์กรต้องมีที่รวมข้อมูลไว้ที่เดียว (มักเรียก data warehouse หรือ data lake) เพื่อเอาไปฝึกโมเดล และมีหลักคิดเรื่องข้อมูลขนาดใหญ่ที่เรียกว่า “5 V” ที่เกี่ยวกับ AI ผมขอเล่าด้วยภาษาคน:
| V | ภาษาคน |
|---|---|
| Volume | ปริมาณ — มีข้อมูลมากแค่ไหน |
| Velocity | ความเร็ว — ข้อมูลเกิด/ไหลเร็วแค่ไหน |
| Variety | ความหลากหลาย — ข้อมูลมีกี่แบบ |
| Veracity | ความน่าเชื่อถือ — คุณภาพ ความถูกต้อง ความครบถ้วน |
| Value | คุณค่า — เอาข้อมูลไปทำอะไรให้ธุรกิจได้ |
และข้อมูลที่เอามาฝึกแบ่งเป็นสองแบบ — Structured (มีโครงสร้าง) เช่น ตารางในฐานข้อมูล กับ Unstructured (ไม่มีโครงสร้าง) เช่น ไฟล์ Office, รูป, เสียง, วิดีโอ, โพสต์โซเชียล
แต่หัวใจของเรื่องนี้อยู่ที่ความเสี่ยง 3 อย่างที่ source ชี้ไว้ — consent, fit-for-purpose, data lag ทั้งสามอันคือคำถามที่ผู้บริหารต้องตอบให้ได้ก่อนเซ็นอนุมัติให้เอาข้อมูลไปฝึก
Consent (ความยินยอม) — เรื่องที่ทำให้โดนปรับได้จริง
นี่คือเส้นแบ่งที่เจ้าของกิจการต้องคมที่สุด:
- ข้อมูลที่บริษัทสร้างเองภายใน (เช่น เอกสารงาน รายงานภายใน) — ส่วนใหญ่เอามาฝึก AI ได้เลย (ยกเว้นข้อมูลอ่อนไหว/ข้อมูลส่วนบุคคล)
- ข้อมูลที่ลูกค้าไว้ใจฝากไว้กับเรา (Customer Data) — อันนี้ต้องระวังหนัก เพราะมักต้องขอความยินยอมเพิ่ม ขึ้นอยู่กับว่าตอนเก็บข้อมูลมา เราบอกลูกค้าว่าจะเอาไปใช้ทำอะไร
จำช่อง “จุดประสงค์ที่เก็บมา (Purpose)” ในบัญชีข้อมูลที่ผมย้ำไว้ตอนต้นได้ไหมครับ? นี่คือจุดที่มันกลับมาหลอกหลอน — ถ้าตอนเก็บข้อมูลลูกค้าเราบอกว่า “เก็บไว้เพื่อจัดส่งสินค้า” แต่วันนี้จะเอาไปฝึก AI ซึ่งเป็นคนละจุดประสงค์ เราอาจต้องขอความยินยอมใหม่
กฎหมายอย่าง GDPR (ยุโรป) และ PDPA (ไทย) บังคับให้ต้องขอความยินยอมในการประมวลผลข้อมูลส่วนบุคคล และ EU AI Act ยังขยายไปถึงการ “ทดสอบ” ระบบ AI ความเสี่ยงสูงในสภาพจริงด้วย — ต้องขอ informed consent (ความยินยอมที่รับรู้ข้อมูลครบ) ก่อนเอาคนมาร่วมทดสอบ
มุมผู้บริหาร: สิ่งที่ผู้บริหารต้อง ออกแบบเป็น control ไม่ใช่แค่รู้ คือ — “กระบวนการถอนความยินยอม” ถ้าวันหนึ่งลูกค้าบอกว่า “ไม่ยอมให้เอาข้อมูลฉันไปฝึก AI แล้ว” หรือ “ขอถอนที่เคยยอมไว้” เราต้องมีกระบวนการ ดึงข้อมูลของเขาออกจากชุดข้อมูลฝึก ได้จริง ถ้าทำไม่ได้ = เสี่ยงโดนปรับ + เสียความเชื่อใจลูกค้า และอย่าลืมลากฝ่ายกฎหมาย/privacy เข้ามาในวง AI governance ตั้งแต่ต้น — นี่ไม่ใช่เรื่องที่ทีมเทคนิคตัดสินเองได้
Fit for Purpose (เหมาะกับงานจริงไหม)
ก่อนทุ่มเงินทำ AI ต้องเช็คว่ามัน “เหมาะกับงาน” จริงไหม source ชี้สัญญาณว่า ไม่เหมาะ ไว้ 3 อย่าง ผมเล่าด้วยภาษาคน:
- ข้อมูลมีอยู่ก็จริง แต่เอามาใช้ไม่ได้ — มันถูกขังอยู่ในระบบเก่า เข้าถึงยาก หยิบมาฝึกไม่ได้
- ข้อมูลมีไม่ละเอียด/ไม่พอ/ไม่น่าเชื่อถือพอ ที่จะทำให้โมเดลเก่งได้
- งานที่จะเอา AI ไปทำมันต้องห้ามตามกฎหมาย (use case ที่ถูกจัดเป็นความเสี่ยงสูงหรือต้องห้าม)
Data Lag (ข้อมูลตกยุค) — เชฟที่จำสูตรเก่าเมื่อปีที่แล้ว
กลับมาที่เชฟของเราอีกที — ถ้าเชฟเรียนสูตรอาหารมาตั้งแต่ปีที่แล้ว แต่วันนี้รสนิยมลูกค้าเปลี่ยนไปแล้ว เขาก็จะทำอาหารที่ “เคยอร่อย” แต่ไม่ตรงใจคนยุคนี้
AI ก็เป็นแบบนี้ครับ มันถูกฝึกด้วย “ข้อมูลในอดีต” และการฝึกใช้เวลาเป็นสัปดาห์เป็นเดือน ระหว่างนั้นโลกก็เปลี่ยนไปแล้ว เกิดช่องว่างระหว่าง “ข้อมูลที่ฝึกไว้” กับ “ความจริงวันนี้” — เรียกว่า data lag หรือ model drift ผลคือโมเดลแม่นยำน้อยลงเรื่อยๆ เมื่อเวลาผ่านไป
วิธีแก้มีสองทางหลัก:
- ฝึกใหม่ด้วยข้อมูลล่าสุด (เหมาะกับโมเดลเล็ก)
- ใช้เทคนิค RAG (Retrieval Augmented Generation) — แทนที่จะฝึกโมเดลใหม่ทั้งตัว ก็ “ป้อนข้อมูลล่าสุดที่เกี่ยวข้องเข้าไปตอนถาม” ให้โมเดลตอบโดยอ้างอิงของใหม่ (โมเดลฐานเดิมไม่ต้องเปลี่ยน แค่ป้อนบริบทสดเข้าไป)
มุมผู้บริหาร: ถ้าเจ้าของกิจการได้ยินทีมพูดว่า “โมเดลเราเริ่มแม่นน้อยลง” อย่าเพิ่งคิดว่าโมเดลพัง — บ่อยครั้งมันคือ data lag ธรรมดา และสิ่งที่ต้องตัดสินใจคือ “เราจะลงทุนฝึกใหม่ทั้งตัว หรือใช้ RAG ป้อนข้อมูลสดเข้าไปก็พอ?” RAG มักถูกกว่าและเร็วกว่ามากสำหรับงานส่วนใหญ่ — เป็นคำตอบที่ควรพิจารณาก่อน
เรื่องที่ 5 — คุณภาพข้อมูล (Data Quality): ขยะเข้า-ขยะออก
หลักการอมตะของวงการข้อมูลคือ “Garbage In, Garbage Out” — ป้อนขยะเข้าไป ก็ได้ขยะออกมา และกับ AI หลักนี้ยิ่งจริงกว่าเดิม เพราะ “ผลลัพธ์ของ AI ดีได้แค่ข้อมูลที่มันถูกฝึกมา”
ข้อมูลดิบมักเต็มไปด้วยข้อผิดพลาด ตกหล่น ไม่ครบ ฉะนั้นก่อนเอาไปฝึกต้อง “สำรวจและทำความสะอาด” (data cleansing) ก่อน source ให้มิติวัดคุณภาพข้อมูลไว้ 6 ด้าน ผมเรียบเรียงเป็นตารางพร้อมตัวอย่างไทย (สมมติ):
| มิติคุณภาพ | แปลว่า | ตัวอย่าง (สมมติ) |
|---|---|---|
| Accuracy (ถูกต้อง) | ตรงกับความจริง ไม่มี error | ที่อยู่ลูกค้าพิมพ์ผิด เลขสลับกัน ทำให้ส่งของผิดบ้าน |
| Completeness (ครบถ้วน) | มีครบทุกช่องที่จำเป็น ไม่ขาด | ช่อง “เบอร์โทร” ของลูกค้าครึ่งหนึ่งว่างเปล่า |
| Consistency (สอดคล้องกัน) | รูปแบบเหมือนกันทั้งชุด | วันที่บางที่เขียน 1 พ.ค. 2567 บางที่เขียน 2024/05/01 ปนกันมั่ว |
| Timeliness (ทันเวลา) | ข้อมูลสดใหม่ พร้อมใช้เมื่อต้องการ | ระบบนำทางต้องใช้พิกัด GPS ล่าสุด ไม่ใช่ของเมื่อชั่วโมงก่อน |
| Validity (ถูกกติกา) | ตรงตามกฎเชิงธุรกิจ/เทคนิคที่ตั้งไว้ | เลขบัตรประชาชนต้องมี 13 หลักเท่านั้น |
| Uniqueness (ไม่ซ้ำซ้อน) | ไม่มีข้อมูลซ้ำ | ลูกค้าคนเดียวถูกบันทึกซ้ำ 3 รายการ |
มุมผู้บริหาร: เจ้าของกิจการไม่ต้องลงไปทำความสะอาดข้อมูลเอง แต่ต้อง “ตั้งมาตรฐานว่าคุณภาพระดับไหนถึงจะยอมให้เอาไปฝึก AI ได้” และต้องเข้าใจว่า งานทำความสะอาดข้อมูลกินเวลาและงบประมาณมากกว่าที่คิดเสมอ — ถ้าทีมขอเวลาเตรียมข้อมูลนานกว่าตอนทำตัวโมเดล นั่นเป็นเรื่องปกติ ไม่ใช่ทำงานช้า
เรื่องที่ 6 — ข้อมูลเอียงและข้อมูลขาด (Balancing & Scarcity)
สองเรื่องนี้คนละอย่างกัน แต่เกี่ยวพันกัน และเป็นต้นตอของ “AI ลำเอียง” ที่เป็นข่าวบ่อยๆ
Data Balancing — ข้อมูลเอียงทำให้ AI ลำเอียง
ลองนึกภาพบริษัทแห่งหนึ่ง (สมมติ) จะฝึก AI คัดใบสมัครงาน แต่ข้อมูลพนักงานเก่าที่เอามาฝึก 90% เป็นผู้ชาย ผลคือ AI จะ “เรียนรู้” ว่าผู้ชายคือคนที่ควรรับ แล้วลำเอียงกีดกันผู้สมัครหญิงโดยอัตโนมัติ — ทั้งที่ไม่มีใครตั้งใจ
นี่คือ Data Imbalance (ข้อมูลไม่สมดุล) — เกิดเมื่อชุดข้อมูลฝึกมีตัวอย่างของกลุ่มน้อย (minority class) ไม่พอ ทำให้ผลลำเอียง ที่น่าสนใจคือมันเอียงได้สองทาง — ทั้งข้อมูลกลุ่มน้อย “น้อยเกินไป” หรือบางทีองค์กรแก้เกินจน “มากเกินจริง” ก็เพี้ยนได้
วิธีแก้คือต้องจัดการตั้งแต่ต้น — สำรวจการกระจายของข้อมูลตอนเก็บ แล้วใช้เทคนิคปรับสมดุล (เพิ่มตัวอย่างกลุ่มน้อย, ลดตัวอย่างกลุ่มมาก, หรือปรับวิธีคำนวณ)
Data Scarcity — มีข้อมูลเยอะ แต่ “ใช้ได้” น้อย
เรื่องนี้ย้อนแย้งแต่จริงมากครับ — องค์กรส่วนใหญ่มีข้อมูลล้นมือ แต่ข้อมูลที่ “เอาไปฝึก AI ได้จริง” กลับขาดแคลน เพราะติดเงื่อนไขสารพัด:
- คุณภาพข้อมูลไม่ดีพอ
- ขาดข้อมูลกลุ่มน้อย/กลุ่มหลากหลาย
- ขาดข้อมูลที่ได้รับความยินยอมหรือมีสิทธิ์ใช้ (วนกลับมาเรื่อง consent อีกแล้ว)
- ข้อมูลถูกขังในระบบเก่าที่เข้าถึงไม่ได้
- ขาดข้อมูลที่ติดป้ายกำกับ (labeled data) ไว้
วิธีแก้มีสองทางหลัก:
- Augmentation (เติมข้อมูล) — หาข้อมูลที่ขาดมาเติม, ซื้อจากแหล่งที่น่าเชื่อถือ, หรือ สร้างข้อมูลสังเคราะห์ (synthetic data) ที่เลียนแบบการกระจายที่ต้องการ
- Model Selection (เลือกโมเดลให้เหมาะกับข้อมูลที่มี) — ถ้าข้อมูลน้อย ก็เลือกโมเดลที่ทำงานได้ดีกับข้อมูลน้อย เพื่อเลี่ยงปัญหา overfitting (โมเดลจำข้อมูลฝึกแม่นเกินจนใช้กับของจริงไม่ได้)
มุมผู้บริหาร: ถ้าทีมเสนอใช้ “ข้อมูลสังเคราะห์ (synthetic data)” ผู้บริหารควรถามต่อว่า — มันเลียนแบบความจริงได้แม่นพอไหม และมันช่วยแก้ปัญหา “ข้อมูลลับ/ความยินยอม” ได้จริง (เพราะไม่ใช่ข้อมูลคนจริง) แต่ก็ต้องระวังว่าถ้าสังเคราะห์มาเอียง ก็จะส่งต่อความเอียงเข้าโมเดลเหมือนกัน — synthetic data เป็นเครื่องมือดี แต่ไม่ใช่ยาวิเศษ
เรื่องที่ 7 — Model Card: “บัตรประจำตัวพนักงาน AI”
ปิดท้ายด้วยเครื่องมือที่ผมชอบที่สุดเพราะมัน “จับต้องได้” ที่สุด — Model Card
กลับไปที่ภาพพนักงานใหม่ — เวลาเรารับคนเข้าทำงาน เรามีประวัติย่อ (resume) ที่บอกว่าเขาเรียนมาอะไร เคยทำอะไร เก่งเรื่องไหน มีข้อจำกัดอะไร Model Card ก็คือ “resume ของพนักงาน AI” นั่นเอง — เป็นไฟล์ที่แนบมากับโมเดล บอกรายละเอียดสำคัญแบบกระชับ ทำให้เราตัดสินใจได้ว่าจะเอาโมเดลนี้ไปใช้กับงานไหน เชื่อถือได้แค่ไหน
source ให้องค์ประกอบหลักของ model card ไว้ ผมเรียบเรียงเป็นตารางในมุม “เจ้าของกิจการอ่านแล้วได้อะไร”:
| หัวข้อใน Model Card | บอกอะไรเรา | เจ้าของกิจการเอาไปใช้ |
|---|---|---|
| Model Details (ข้อมูลโมเดล) | ชื่อ, เวอร์ชัน, พารามิเตอร์, ใบอนุญาต, ใครรับผิดชอบ | รู้ว่าใครต้องรับผิดถ้ามีปัญหา + ใช้ถูกลิขสิทธิ์ไหม |
| Use Case (กรณีใช้งาน) | โมเดลนี้ออกแบบมาเพื่ออะไร ใครควรใช้ | เช็คว่าตรงกับงานเราไหม (fit for purpose) |
| Architecture (สถาปัตยกรรม) | ออกแบบยังไง ต้องใช้ฮาร์ดแวร์/เทคโนโลยีอะไรรัน | ประเมินต้นทุนและความพร้อมของระบบเรา |
| Training Info (ข้อมูลที่ใช้ฝึก) | ฝึกด้วยข้อมูลอะไร มาจากไหน เมื่อไหร่ การกระจายเป็นยังไง | เช็คเรื่อง bias, consent, และ data lag |
| Performance Metrics (ผลการทำงาน) | โมเดลทำงานแม่นแค่ไหน อะไรกระทบผลลัพธ์ | ตั้งความคาดหวังให้สมจริง |
| Limitations & Biases (ข้อจำกัด/อคติ) | จุดอ่อน ข้อจำกัด อคติที่รู้อยู่แล้ว | รู้ว่าห้ามเอาไปทำอะไร ก่อนเกิดเรื่อง |
| Ethical Considerations (จริยธรรม) | ประเด็นความเป็นส่วนตัว ความเป็นธรรม ผลกระทบต่อสังคม | ประเมินความเสี่ยงด้านชื่อเสียง/กฎหมาย |
โมเดลดังๆ ในตลาด (เช่น Meta Llama, OpenAI GPT) มักมี model card มาให้ และมีเทมเพลตให้โหลดใช้ — แต่มีข้อควรระวัง ที่ source เตือนไว้ คือเทมเพลตสำเร็จรูปมัก “รายละเอียดไม่พอ” อย่าเอามากรอกแบบขอไปที
มุมผู้บริหาร: กฎเหล็กข้อหนึ่งที่ผู้บริหารตั้งได้เลย — “ห้ามรับโมเดลใดเข้ามาใช้ในองค์กร ถ้าไม่มี model card” ไม่ว่าจะซื้อ จ้างทำ หรือทำเอง เพราะถ้าโมเดลไม่มีฉลากบอกข้อจำกัดและอคติ เท่ากับเรารับพนักงานเข้ามาโดยไม่ดู resume เลย — แล้ววันที่มันทำพลาด เราจะตอบหน่วยงานกำกับหรือลูกค้าไม่ได้เลยว่า “เรารู้ข้อจำกัดของมันมาก่อน”
สรุปสั้นๆ ให้ตัวเองจำได้
อ่านมาถึงตรงนี้ ขอจดกันลืมไว้สามอย่างครับ
อย่างแรก — ปัญหาของ AI ส่วนใหญ่คือปัญหาของ “ข้อมูล” AI ตอบมั่ว ลำเอียง ตัดสินใจพลาด สาวกลับไปมักเจอต้นตอที่ข้อมูล ฉะนั้นถ้าจะคุม AI ให้ดี ต้องเริ่มที่คุมข้อมูลให้ดีก่อน — รู้ว่ามีอะไร (inventory), รู้ว่ามันไหลไปไหน (lineage), จัดชั้นมัน (classification)
อย่างที่สอง — เรื่องที่โดนปรับได้จริงคือ “consent” ข้อมูลที่บริษัทสร้างเองใช้ได้ค่อนข้างอิสระ แต่ข้อมูลลูกค้าต้องดูว่าตอนเก็บมาบอกว่าจะใช้ทำอะไร และต้องมีกระบวนการ “ถอนความยินยอม + ดึงข้อมูลออกจากชุดฝึก” ได้จริง ลากฝ่ายกฎหมาย/privacy เข้ามาตั้งแต่ต้น
อย่างที่สาม — ตั้งกฎง่ายๆ สองข้อที่คุมได้วันนี้ หนึ่ง: ข้อมูลต้องผ่านมาตรฐานคุณภาพและเช็คความเอียงก่อนเอาไปฝึก · สอง: ทุกโมเดลที่เข้าองค์กรต้องมี model card สองกฎนี้ไม่ต้องเป็นผู้เชี่ยวชาญก็ตั้งได้ และมันกันปัญหาได้เยอะมาก
ถ้าจะสรุปแบบที่เจ้าของกิจการน่าจะพยักหน้าตาม — “งั้นพนักงาน AI ของฉัน จะเก่งหรือพัง อยู่ที่ฉันป้อนของดีให้มันรึเปล่า และฉันรู้รึเปล่าว่าป้อนอะไรเข้าไป” ใช่เลยครับ นั่นแหละหัวใจของตอนนี้
ตอนหน้าเราจะขยับจากเรื่อง “ข้อมูลและทรัพย์สิน AI” ไปสู่เรื่องที่ใหญ่ขึ้น — “การวางโครงสร้างโปรแกรมความมั่นคงปลอดภัยสำหรับ AI ทั้งระบบ” ว่าเจ้าของกิจการต้องตั้งอะไรบ้างให้ AI ทั้งองค์กรปลอดภัย ไว้เจอกันครับ
อ้างอิงเนื้อหา: AAISM — Domain 1: Section 1.12 (Data Inventory and Management) ครอบคลุมหัวข้อย่อย 1.12.1 Data Inventory · 1.12.2 Dataflow Diagrams & Data Lineage · 1.12.3 Data Classification · 1.12.4 Data Collection for AI (Consent / Fit for Purpose / Data Lag) · 1.12.5 AI Data Classification · 1.12.6 Data Confidentiality · 1.12.7 Data Quality · 1.12.8 Data Balancing · 1.12.9 Data Scarcity · 1.12.10 Model Cards แหล่งสาธารณะที่อ้างถึงโดยตรง: General Data Protection Regulation (GDPR) · พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (PDPA) · EU Artificial Intelligence Act · Open Data Institute (แนวทางทำ data inventory)
