AAISM Series — คู่มือคุม AI ในมุมคนบริหาร (ไม่ใช่มุมผู้ตรวจ) ตอนที่ 31 / Domain 3 — AI Technologies & Controls (บทเทคนิคที่ใหญ่ที่สุดของซีรีส์) ซีรีส์นี้เล่าจากมุม “เจ้าของกิจการ / CISO ที่เอา AI มาใช้จริง” ว่าต้องตัดสินใจ + เลือก control อะไรบ้าง (สารบัญเต็มจะตามมา)

📚 ตอนนี้ผมจะ ไม่ อธิบายตั้งแต่ศูนย์ว่า “data poisoning หน้าตาเป็นยังไง”, “เทรนโมเดลคือทำอะไร” หรือ “การสำรองข้อมูล (backup) สำคัญยังไง” เพราะภัยพื้นฐานของ AI เคยปูไว้แล้วใน CyberSecurity Foundation ตอนที่ 38 — AI & Blockchain Security ส่วนเรื่องการกำกับข้อมูลและบทบาท DBA ปูไว้ใน Database 101 และเราเพิ่งคุยภัยเทคนิคของ AI แบบไล่ทีละตัวกันไปแล้วใน AAISM ตอนที่ 19 ตอนนี้ผมจะไม่ย้ำนิยาม แต่จะลงลึกอีกชั้นในมุมที่ตอนก่อนไม่ได้พูด — มุมเจ้าของที่ต้องตัดสินใจว่า “ของพิเศษที่ AI สร้างขึ้นมา เราจะสำรองอะไร คุมความถูกต้องของอะไร แล้วเลือก control ตัวไหนถึงจะคุ้ม”

ลองนึกภาพโรงงานผลิตชิ้นส่วนแห่งหนึ่ง (สมมติขึ้นมาให้เห็นภาพนะครับ) เจ้าของลงทุนก้อนใหญ่กว่าครึ่งปีจ้างทีมมาเทรนโมเดล AI ตรวจคุณภาพชิ้นงานจากภาพถ่ายบนสายพานเอง — ไม่ได้ซื้อสำเร็จรูป แต่เอาภาพชิ้นงานดี-เสียที่สะสมมาหลายปีมาสอนโมเดลจนแม่นมาก จับรอยร้าวที่ตาคนมองไม่เห็นได้

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

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

สองฉากนี้คือหัวใจของตอนนี้ครับ — เรื่องแรกคือ “AI สร้างของพิเศษอะไรขึ้นมาบ้าง แล้วเราต้องสำรองอะไร” (data backup) เรื่องที่สองคือ “เราจะกันไม่ให้ของพวกนั้นถูกแอบแก้/วางยาได้ยังไง” (data integrity) ทั้งคู่เป็นเรื่อง “เลือก control ให้ถูก” ล้วนๆ ไม่ใช่เรื่องที่เจ้าของต้องลงไปแกะโค้ดเอง

ตั้งหลักก่อน — Domain 3 คือ “ลงมือคุมงานจริงในแต่ละวัน”#

ทั้งซีรีส์นี้ผมชวนมองว่า AI = พนักงานใหม่เก่งสุดๆ คนหนึ่งที่เราต้องกำกับ ตอน Domain 1 เราพูดเรื่อง “ตั้งกฎ + วางโครงสร้างให้พนักงานคนนี้” ตอน Domain 2 เราพูดเรื่อง “มองความเสี่ยงว่ามันพังตรงไหนได้บ้าง” พอมาถึง Domain 3 — บทที่หนาที่สุดและเทคนิคที่สุดของทั้งซีรีส์ — มันคือ “ลงมือคุมงานจริงในแต่ละวัน” คือเรื่องของเครื่องมือและมาตรการที่ลงไปคุมจริงๆ

ขอเตือนใจตัวเองกับคนอ่านไว้ก่อนเลยว่า Domain 3 มันเทคนิคจัด มีศัพท์อย่าง embedding, checkpoint, ETL, vector เต็มไปหมด แต่ เราจะไม่เล่าแบบครูสอนวิทยาศาสตร์ข้อมูล (data scientist) ที่สอนสร้างโมเดล และไม่เล่าแบบผู้ตรวจ (auditor) ที่ไล่ติ๊กว่าผ่านหรือไม่ผ่าน เราจะเล่าเท่าที่เจ้าของกิจการต้อง “เข้าใจพอเพื่อเลือก control ให้ถูก” เท่านั้น คือรู้ว่าของชิ้นนี้คืออะไร พังแล้วเจ็บยังไง แล้วมาตรการตัวไหนที่ควรสั่งให้ทีมทำ

มุมผู้บริหาร: ผมขอย้ำเส้นแบ่งบทบาทตรงนี้ก่อนเข้าเนื้อ เพราะมันสำคัญสุดในทั้ง Domain 3 — งานของเจ้าของไม่ใช่ “ลงไปตั้งค่า backup เองหรือเขียนสคริปต์ ETL เอง” นั่นเป็นงานทีมเทคนิค หน้าที่ของเจ้าของคือ เป็นเจ้าของความเสี่ยง + เป็นคนเลือก control — ตัดสินใจว่า “ของชิ้นไหนสำคัญพอที่ต้อง backup”, “ความถูกต้องของข้อมูลตรงไหนที่พลาดแล้วธุรกิจเจ็บหนัก”, และ “เราจะลงเงินลงคนไปคุมจุดไหนก่อน” ความผิดพลาดที่เจอบ่อยคือเจ้าของเหมาว่า “เรื่อง backup เรื่อง integrity เป็นเรื่องเทคนิค ปล่อยทีมไปจัดการ” — แต่พอเกิดเรื่อง คนที่รับผลกระทบทางธุรกิจคือเจ้าของ ดังนั้นการ “เลือกว่าจะคุมอะไร” ต้องเป็นเจ้าของที่ร่วมตัดสินใจ ไม่ใช่ปล่อยให้ทีมเทคนิคเดาเอาเองว่าอะไรสำคัญ

ส่วนที่ 1 — การสำรองข้อมูลของ AI (Data Backup): สำรอง “ของที่ AI สร้าง” ไม่ใช่แค่ “ของที่เอาไปสอน”#

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

ความเข้าใจผิดข้อแรก — “ข้อมูลดิบที่เอาไปเทรน ไม่จำเป็นต้อง backup ซ้ำ”#

ฟังดูแปลกแต่จริงครับ ข้อมูลส่วนใหญ่ที่เอามาเทรนโมเดล AI มันมักจะ มาจากที่อื่นอยู่แล้ว — ดึงมาจากฐานข้อมูลลูกค้าที่มี backup ของตัวเองอยู่แล้ว, ดึงมาจากระบบขายที่ backup อยู่แล้ว, หรือเป็นข้อมูลสาธารณะที่ดาวน์โหลดมาใหม่ได้เสมอ

ดังนั้นการเอา “ข้อมูลดิบชุดเดียวกัน” มา backup ซ้ำอีกที่หนึ่งโดยเฉพาะเพื่องาน AI จึงมัก ซ้ำซ้อนเปล่าๆ (redundant) เปลืองพื้นที่ เปลืองเงิน และที่แย่กว่านั้นคือยิ่งกระจายสำเนาข้อมูลส่วนบุคคลไปอีกที่ ก็ยิ่งเพิ่มจุดที่ข้อมูลรั่วได้ ความเข้าใจผิดที่เจ้าของหลายคนมีคือ “AI สำคัญ เพราะงั้น backup ทุกอย่างให้หมดเลย” — ซึ่งกลับกลายเป็นเสียเงินผิดที่และเพิ่มความเสี่ยงโดยไม่ได้อะไรกลับมา

แล้วต้อง backup อะไรกันแน่ — “ของใหม่ที่เกิดขึ้นระหว่างกระบวนการสร้าง AI”#

ของที่ต้อง backup จริงๆ คือ ของที่เพิ่งถูกสร้างขึ้นมาใหม่ระหว่างทางทำ AI ซึ่งถ้าหายแล้วต้องลงทุนสร้างใหม่ทั้งหมด ลองดูตารางนี้ครับ ผมเรียบเรียงเองให้เจ้าของเห็นภาพว่าแต่ละอย่างคืออะไรแล้วทำไมถึงสำคัญ:

ของที่ AI สร้างขึ้น	มันคืออะไร (ภาษาคน)	ถ้าหายไปแล้วเจ็บยังไง
ข้อมูลที่ผ่านการเตรียมแล้ว (postprocessed data)	ข้อมูลดิบที่ทีมเอามาล้าง ทำความสะอาด จัดรูปแบบ จนพร้อมป้อนเข้าโมเดล	งานล้างข้อมูลใช้เวลาและแรงคนมาก ถ้าหายต้องล้างใหม่ทั้งหมด
ข้อมูลที่แปลงเป็น token แล้ว (tokenized data)	ข้อมูลที่ถูกแปลงเป็นรหัสตัวเลขให้เครื่องอ่านได้ มักเก็บเป็นไฟล์ binary	ถ้าหายต้องแปลงใหม่ ซึ่งกินเวลาประมวลผลและทรัพยากรเครื่อง
น้ำหนักของโมเดล (model weights)	“สมอง” ของ AI ที่เกิดจากการเทรน เก็บเป็นไฟล์ binary เฉพาะทาง	นี่คือของที่แพงที่สุด ถ้าหาย = เทรนใหม่ตั้งแต่ศูนย์ เสียเงิน GPU + เวลาเป็นสัปดาห์/เดือน
โครงสร้างและพารามิเตอร์ของโมเดล (architecture/parameters)	สูตรว่าโมเดลมีกี่ชั้น ขนาด embedding เท่าไร มักเก็บเป็นไฟล์ JSON/YAML	ถ้าหายจะกู้สมองโมเดลกลับมาใช้ไม่ได้ เพราะไม่รู้ว่าน้ำหนักนั้นวางในโครงแบบไหน

ในรายการนี้ ตัวที่เจ้าของต้องจำให้ขึ้นใจคือ น้ำหนักของโมเดล (model weights) — เพราะมันคือผลลัพธ์ที่แพงที่สุดของทั้งโปรเจกต์ มันคือ “เงินและเวลาที่ลงไปทั้งหมดถูกตกผลึกเป็นไฟล์ก้อนเดียว” ถ้าฮาร์ดดิสก์ที่เก็บมันพังแล้วไม่มี backup เราไม่ได้แค่เสียไฟล์ เราเสียทั้งโปรเจกต์ที่ต้องเริ่มใหม่

ของพิเศษอีกชุด — เก็บไว้เพื่อ “อธิบายได้ว่าโมเดลตัดสินใจยังไง”#

ของอีกกลุ่มที่ต้องเก็บ ไม่ได้เก็บเพื่อกู้ระบบ แต่เก็บเพื่อ “ตอบคำถามว่าทำไมโมเดลถึงตัดสินใจแบบนี้” ในวันข้างหน้า

จุดที่ทำให้ AI ต่างจากซอฟต์แวร์ทั่วไปคือ ซอฟต์แวร์ปกติมี source code ที่บอกชัดว่า “ถ้าเงื่อนไขนี้ ให้ทำอย่างนี้” เราอ่านโค้ดก็เข้าใจว่ามันจะทำอะไร แต่โมเดล GenAI เป็น ของที่ไม่ตายตัว (nondeterministic) ป้อนคำถามเดิมสองครั้งอาจได้คำตอบไม่เหมือนกันเป๊ะ แล้วก็ไม่มี “โค้ด” ให้ไล่อ่านว่าทำไมมันตอบแบบนั้น มันเลยยากที่จะอธิบายว่าโมเดลมาถึงคำตอบนี้ได้ยังไง

เพราะแบบนี้ องค์กรจึงควรเก็บสำเนา 3 อย่างนี้ไว้:

ชุดข้อมูลที่ใช้เทรนและใช้ทดสอบ (training & testing datasets) — เก็บไว้ในสภาพ ณ ตอนที่ใช้สร้างโมเดลรุ่นนั้น
ผลการวัดประสิทธิภาพของโมเดล (model performance results) — โมเดลรุ่นนั้นแม่นแค่ไหน ตอนปล่อยใช้
ผลการทดสอบอคติ (bias testing results) — เคยทดสอบแล้วว่ามันเอนเอียงกับกลุ่มไหนไหม ผลเป็นยังไง

ทำไมเจ้าของต้องสน? เพราะวันหนึ่งถ้ามีลูกค้าหรือหน่วยงานกำกับถามว่า “ทำไม AI ของคุณปฏิเสธ/ตัดสินใจกับฉันแบบนี้” ถ้าเราเก็บของพวกนี้ไว้ เราก็ตอบได้ว่า “โมเดลรุ่นนี้เทรนจากข้อมูลชุดนี้ ทดสอบแล้วได้ผลแบบนี้ อคติอยู่ในเกณฑ์เท่านี้” แต่ถ้าไม่เก็บ เราก็ได้แต่ยักไหล่ ซึ่งในเชิงกฎหมายและชื่อเสียงคือหายนะ

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

กรอบคิดเรื่อง backup ของ AI ในมุมเจ้าของ — เริ่มจาก “หายแล้วเจ็บแค่ไหน”#

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

ของชิ้นนั้น	สร้างใหม่ยากไหม	ความสำคัญต่อ backup
ข้อมูลดิบจากแหล่งภายนอก	ง่าย (โหลด/ดึงใหม่ได้)	ต่ำ — มัก redundant อย่าเสียเงิน backup ซ้ำ
ข้อมูลดิบที่อยู่ในระบบเราอยู่แล้ว	มี backup ที่ระบบต้นทางอยู่แล้ว	ต่ำ — พึ่ง backup เดิมของระบบนั้นได้
ข้อมูลที่ล้าง/เตรียมแล้ว	ปานกลาง (ต้องทำซ้ำด้วยแรงคน)	กลาง — backup ถ้างานเตรียมหนักมาก
น้ำหนักโมเดลที่เทรนเสร็จ	ยากมาก (เทรนใหม่ = เงิน+เวลาก้อนใหญ่)	สูงสุด — ต้อง backup เสมอ
โครงสร้าง/พารามิเตอร์โมเดล	ยาก (ถ้าไม่มี กู้น้ำหนักกลับไม่ได้)	สูง — backup คู่กับน้ำหนักเสมอ
ข้อมูล+ผลทดสอบเพื่ออธิบายโมเดล	กู้คืนไม่ได้เลยถ้าไม่เก็บ ณ ตอนนั้น	สูง — เก็บเพื่อความรับผิดชอบ/กฎหมาย

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

กับดักที่เจอบ่อยเรื่อง backup ของ AI#

ผมขอรวบกับดักที่เจ้าของควรระวัง (เรียบเรียงจากปัญหาที่พบบ่อยในการนำ AI มาใช้):

กับดัก “backup ข้อมูล แต่ลืม backup โมเดล” — อันคลาสสิกในฉากต้นเรื่อง สำรองภาพถ่าย/ข้อมูลครบ แต่ลืมตัวที่แพงที่สุดคือน้ำหนักโมเดล
กับดัก “มี backup แต่กู้ไม่ได้จริง” — ไฟล์ backup เสีย, ลืมรหัสถอด encryption, หรือ format เปลี่ยนจนเปิดไม่ออก ต้องมีการ “ซ้อมกู้” เป็นระยะ
กับดัก “backup ทุกอย่างเหมือนกันหมด” — เอาข้อมูลส่วนบุคคลไป backup กระจายหลายที่โดยไม่จำเป็น ยิ่งเพิ่มจุดรั่ว แทนที่จะเลือก backup เฉพาะของที่จำเป็น
กับดัก “เก็บแต่โมเดล ไม่เก็บที่มา” — เก็บโมเดลไว้ แต่ไม่เก็บข้อมูล/ผลทดสอบที่ใช้สร้างมัน วันที่ต้องอธิบายว่า “ทำไมโมเดลตัดสินแบบนี้” เลยตอบไม่ได้

ส่วนที่ 2 — ความถูกต้องของข้อมูล AI (Data Integrity): กันไม่ให้ข้อมูลและโมเดลถูก “แอบแก้”#

มาถึงครึ่งหลังของตอน ซึ่งเป็นหัวใจจริงๆ ครับ — เรื่อง integrity หรือ “ความถูกต้องครบถ้วนไม่ถูกแอบแก้” ของทั้งข้อมูลและตัวโมเดล

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

ทำไมเจ้าของต้องกลัว? เพราะภัยกลุ่มนี้มันมี 2 ลักษณะที่อันตราย อย่างแรก มันเงียบ ระบบไม่ล่ม ไม่ขึ้น error AI ยังตอบ ยังทำงานปกติ แต่ตอบผิด/เอนเอียง อย่างที่สอง มันเกิด “ก่อน” ที่เราจะใช้งาน คือถูกวางยาตั้งแต่ตอนสร้าง พอเอามาใช้จริงมันก็ผิดมาตั้งแต่ต้น เหมือนพนักงานที่ถูกสอนผิดมาตั้งแต่วันแรก เขาทำงานขยันมาก แต่ทำผิดด้วยความมั่นใจเต็มที่

3 ฉากที่ความถูกต้องของ AI ถูกทำลายได้#

source ของ AAISM วาง 3 ฉากนี้ไว้ ขอเล่าในมุมเจ้าของพร้อมตัวอย่างไทยสมมติ:

ฉากที่ 1 — วางยาข้อมูล (Data Poisoning)#

คืออะไร: ผู้โจมตี (หรือคนในที่ไม่หวังดี) เข้าไปแก้ “ข้อมูลที่ใช้สอนโมเดล” เพื่อบิดพฤติกรรมของโมเดล

ตัวอย่างสมมติให้เห็นภาพ: กลับไปที่โรงงานตรวจชิ้นงานในฉากต้นเรื่อง — สมมติว่ามีคนแอบเปลี่ยน label ของภาพชิ้นงานเสียบางส่วนให้เป็น “ดี” พอเทรนเสร็จ โมเดลก็เรียนรู้ผิด แล้วปล่อยของเสียผ่านสายพานไปขายลูกค้า โดยที่หน้าจอยังขึ้นเขียวว่า “ผ่าน QC” ทุกครั้ง

เจ้าของเจ็บยังไง: สินค้ามีตำหนิหลุดออกไป → ลูกค้าร้องเรียน → เคลม → เสียชื่อเสียง ทั้งหมดนี้เกิดเงียบๆ จนกว่าจะมีคนร้องเรียนเข้ามา

ฉากที่ 2 — วางยาโมเดล (Model Tampering)#

คืออะไร: ผู้โจมตีเข้าไปแก้ตัวโมเดลโดยตรง — แก้น้ำหนัก (weights), โครงสร้าง (architecture), หรือพารามิเตอร์ เพื่อให้โมเดลให้ผลผิด เอนเอียง หรือเป็นอันตราย

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

เจ้าของเจ็บยังไง: ต่างจากวางยาข้อมูลตรงที่ — ฉากนี้ไม่ต้องแตะข้อมูลเลย แค่แตะ “สมอง” โดยตรง ดังนั้นต่อให้ข้อมูลเทรนสะอาดแค่ไหน ถ้าโมเดลที่ deploy ออกไปถูกสับเปลี่ยน/แก้ไขกลางทาง ก็จบ

ฉากที่ 3 — วางยา embedding (Embedding Tampering)#

คืออะไร: อันนี้เทคนิคสุดในสามฉาก ขอแปลเป็นภาษาคนก่อน “embedding” คือการแปลงคำ/ภาพ/เสียงให้กลายเป็นชุดตัวเลข (vector) ที่โมเดลใช้เข้าใจความหมายและความใกล้เคียงของสิ่งต่างๆ ส่วน “embedding matrices” คือตารางตัวเลขก้อนใหญ่ที่เก็บการแปลงนี้ไว้ ถ้ามีคนแอบไปแก้ตัวเลขในตารางนี้ ผลลัพธ์ของโมเดลก็จะเบี้ยวไป

ตัวอย่างสมมติ: ลองนึกภาพผู้ช่วย AI ตอบลูกค้าที่ใช้ระบบค้นหาแบบเข้าใจความหมาย (semantic search) ดึงคำตอบจากคู่มือบริษัท ถ้ามีคนแอบแก้ embedding ให้คำว่า “การรับประกัน” ไปใกล้เคียงกับเนื้อหาที่ผิด ผู้ช่วยก็อาจตอบลูกค้าเรื่องเงื่อนไขประกันผิดไปเลย ทั้งที่คู่มือต้นฉบับถูกต้องทุกอย่าง

เจ้าของเจ็บยังไง: นี่เป็นจุดที่เจ้าของไม่ต้องเข้าใจกลไกลึก แต่ต้องเข้าใจหลักการว่า AI มี “ของกลาง” หลายชั้น คือตั้งแต่ข้อมูลดิบ ไปเป็น embedding ไปจนถึงตัวโมเดล แล้วทุกชั้นถ้าถูกแตะ ผลลัพธ์ก็เพี้ยน ดังนั้นการคุมการเข้าถึงต้องครอบทุกชั้น ไม่ใช่แค่คุมข้อมูลดิบแล้วคิดว่าปลอดภัย

ผมขอสรุป 3 ฉากนี้เป็นตารางให้เจ้าของจำง่าย (เรียบเรียงเอง):

ฉาก	เป้าที่ถูกแตะ	เกิดตอนไหน	คำถามที่เจ้าของต้องตอบ
วางยาข้อมูล (data poisoning)	ข้อมูลที่ใช้สอน	ก่อน/ระหว่างเทรน	รู้ที่มาข้อมูลทุกชุดไหม ใครแตะข้อมูลเทรนได้บ้าง
วางยาโมเดล (model tampering)	น้ำหนัก/โครงสร้างโมเดล	ระหว่างเทรน + ตอน deploy	ใครแตะไฟล์โมเดลได้ ตอนเอาขึ้นใช้มีการเช็คว่าโมเดลไม่ถูกแก้ไหม
วางยา embedding	ตาราง embedding (vector)	ระหว่างเตรียม + ตอนใช้งาน	vector database ของเราคุม access แค่ไหน ใครแก้ได้

จุดร่วมของทั้ง 3 ฉากที่เจ้าของต้องจับให้ได้คือ — มันคือเรื่องของ “ใครแตะของกลางของ AI ได้บ้าง” ทั้งหมด ซึ่งโยงไปสู่ control ตัวที่สำคัญที่สุดในเรื่องนี้ คือ การคุมการเข้าถึง (access control) ที่ผมจะพูดถัดไป

ภัยที่ไม่ได้มาจากคนร้าย — ความผิดพลาดจากขั้นตอนเตรียมข้อมูล (ETL)#

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

ขอแปล ETL เป็นภาษาคนก่อนครับ — ETL ย่อมาจาก Extract, Transform, Load คือกระบวนการ 3 ขั้นที่ทีมทำกับข้อมูลก่อนเอาไปเทรน:

Extract (ดึงออก) — ดึงข้อมูลออกจากแหล่งต่างๆ
Transform (แปลง) — ล้าง จัดรูปแบบ รวม แปลงหน่วย ฯลฯ ให้พร้อมใช้
Load (โหลดเข้า) — เอาข้อมูลที่เตรียมเสร็จไปวางไว้ที่ที่จะใช้เทรน

ในงาน AI ทีมต้องทำ ETL บ่อยมาก และ ทุกขั้นตอนมีโอกาสทำข้อมูลพังโดยไม่ตั้งใจ เช่น แปลงหน่วยผิด (เซนติเมตรปนนิ้ว), รวมไฟล์แล้วข้อมูลซ้ำ, ล้างข้อมูลแล้วตัดของสำคัญทิ้งไปด้วย, หรือ map คอลัมน์ผิดจนค่าสลับช่อง พอข้อมูลที่ “ผิดโดยไม่ตั้งใจ” นี้ถูกป้อนเข้าโมเดล ผลที่ได้ก็เพี้ยนเหมือนถูกวางยา — แค่คราวนี้ไม่มีคนร้าย มีแต่ความเลินเล่อ

control ที่ source แนะนำสำหรับ ETL (ผมเรียบเรียงในมุมเจ้าของ) คือ ให้ กำหนด แล้วจดบันทึก แล้วทดสอบ แล้วค่อยนำไปใช้ ข้อกำหนดและตรรกะของ ETL ให้ชัดเจน พูดง่ายๆ คือ “อย่าให้ทีมเตรียมข้อมูลแบบมือเปล่าตามใจแต่ละคน” แต่ต้องมีสูตรที่เขียนไว้ชัด ทดสอบแล้วว่าถูก แล้วทำตามนั้นทุกครั้ง เพื่อให้ข้อมูลที่ออกมาเชื่อถือได้สม่ำเสมอ

มุมผู้บริหาร: เจ้าของหลายคนพอได้ยินคำว่า “data integrity” ก็นึกถึงแต่ “แฮกเกอร์มาวางยา” แล้วทุ่มงบไปกับการป้องกันการโจมตีอย่างเดียว แต่ในความเป็นจริงที่ผมอยากให้เจ้าของจำคือ — ข้อมูลพังเพราะ ETL ผิดพลาด เกิดบ่อยกว่าและกัดกินเงียบกว่าการถูกโจมตี เจ้าของไม่ต้องไปตรวจสคริปต์ ETL เอง แต่ควรถามทีมว่า “ขั้นตอนเตรียมข้อมูลของเรามีสูตรที่เขียนไว้ชัดและทดสอบแล้วไหม หรือพึ่งความจำของคนใดคนหนึ่ง?” — ถ้าคำตอบคือ “พี่คนนั้นทำอยู่คนเดียว เขารู้ดี” นั่นคือสัญญาณอันตราย เพราะวันที่เขาลาออกหรือทำพลาด เราจะไม่มีทางรู้เลยว่าข้อมูลที่ป้อนเข้าโมเดลเริ่มเพี้ยนตั้งแต่เมื่อไร

control 4 ตัวที่ใช้คุมความถูกต้อง — แล้วเจ้าของเลือกตัวไหน#

นอกจากเรื่อง ETL แล้ว source ยังให้ control เพิ่มอีกชุดสำหรับรักษา integrity ขอเอามาเรียงในมุม “เจ้าของเลือก control” พร้อมแปลให้เป็นภาษาคน:

control	แปลเป็นภาษาคน	คุมภัยตัวไหนได้
Anomaly detection (ตรวจจับความผิดปกติ)	ตั้งระบบเฝ้าดูว่าข้อมูลเทรนมีอะไรแปลกๆ ผิดจากปกติไหม	จับ data poisoning + ความผิดพลาดจาก ETL ได้ตั้งแต่เนิ่นๆ
แยกข้อมูลเทรน ออกจากข้อมูลใช้งานจริง (separate training from production)	อย่าให้ข้อมูลที่ใช้สอนปนกับข้อมูลที่ระบบใช้รันจริง	ลดความเสี่ยงปนเปื้อน + กันข้อมูลจริงรั่วเข้าไปในชุดเทรน
Data validation + ensemble models	ตรวจสอบความถูกต้องของข้อมูลก่อนใช้ + ใช้หลายโมเดลช่วยกันตัดสิน	ลดผลกระทบถ้าโมเดลตัวเดียวถูกบิด (หลายตัวช่วยถ่วงดุล)
Model hardening (เสริมความแกร่งโมเดล)	ทำให้โมเดลทนต่อการถูกหลอก/ถูกบิดมากขึ้น	ลดโอกาสที่ data/model poisoning จะสำเร็จ

แต่ control ที่ผมอยากเน้นเป็นพิเศษ และเป็น “ตัวคุ้มที่สุดสำหรับเจ้าของ” ไม่ได้อยู่ในตารางนี้ — มันคือ การคุมการเข้าถึงอย่างเข้มงวด (robust access control) ทั่วทั้งเส้นทางเดินของข้อมูล AI ตามหลัก สิทธิ์น้อยที่สุดเท่าที่จำเป็น (least privilege)

ทำไมตัวนี้ถึงคุ้มที่สุด? เพราะภัย integrity ทั้ง 3 ฉาก (วางยาข้อมูล, วางยาโมเดล, วางยา embedding) มีรากเดียวกันคือ “มีคนที่ไม่ควรแตะได้ ไปแตะของกลางของ AI” ถ้าเราคุมได้ว่า “ใครเข้าถึงข้อมูลเทรน/โมเดล/embedding ได้บ้าง และให้สิทธิ์เท่าที่จำเป็นจริงๆ” — เราก็ปิดประตูภัยทั้ง 3 ฉากพร้อมกันด้วยมาตรการเดียว นี่คือเหตุผลที่ในการตัดสินใจเลือก control “การคุม access ให้รัดกุมทั่วทั้ง dataflow” มักเป็นคำตอบที่ดีที่สุดเมื่อต้องกันความเสี่ยงเรื่องการวางยาข้อมูลกับข้อมูลอ่อนไหว — ดีกว่าการพึ่ง backup (ซึ่งช่วยตอน “กู้คืน” ไม่ใช่ “ป้องกัน”) และดีกว่าการพึ่งสแกนช่องโหว่แบบทั่วไป (ซึ่งจับภัยเฉพาะทางของ AI ไม่ได้)

มุมผู้บริหาร: ขอแยกความเข้าใจผิดที่เจ้าของชอบสับสนตรงนี้ให้ชัด — “backup” กับ “การกันการวางยา” เป็นคนละเรื่องกัน อย่าเอามาแทนกัน backup ช่วยเรา “กู้กลับมา” หลังของหาย/พัง แต่ backup ไม่ได้ป้องกัน ไม่ให้ข้อมูลถูกวางยาตั้งแต่แรก (ที่แย่กว่านั้น ถ้า backup ข้อมูลที่ถูกวางยาไว้แล้ว เราก็แค่เก็บของเสียไว้อีกชุด) สิ่งที่ “ป้องกัน” การวางยาคือ การคุม access + ตรวจที่มาข้อมูล + ตรวจจับความผิดปกติ ต่างหาก ดังนั้นเวลาทีมเสนอว่า “เราทำ backup แล้ว ปลอดภัยจาก poisoning” — เจ้าของต้องจับได้ว่านั่นตอบผิดคำถาม

เอาทั้งสองส่วนมาประกอบ — “เลือก control ให้ครบทั้งกัน-และ-กู้”#

สุดท้ายผมอยากให้เจ้าของเห็นภาพรวมว่า ทั้ง backup และ integrity มันทำงานคนละหน้าที่แต่ต้องมีคู่กัน เปรียบกับ “พนักงาน AI” ของเราแบบนี้ครับ:

1
            กันไว้ก่อน (Integrity)                    กู้คืนทีหลัง (Backup)
2
                  │                                          │
3
   ┌──────────────┴──────────────┐          ┌────────────────┴───────────────┐
4
   │ คุม access ใครแตะของ AI ได้   │          │ สำรองน้ำหนักโมเดล + โครงสร้าง    │
5
   │ ตรวจที่มาข้อมูลเทรน           │          │ สำรองข้อมูล/ผลทดสอบเพื่ออธิบาย    │
6
   │ ตรวจจับความผิดปกติ            │          │ ซ้อมกู้คืนเป็นระยะ                │
7
   │ คุมสูตร ETL ให้ชัดและทดสอบ     │          │ (อย่า backup ข้อมูลดิบซ้ำเปล่าๆ)   │
8
   └──────────────────────────────┘          └─────────────────────────────────┘
9
         "พนักงานถูกสอนผิด/ถูกแก้ไม่ได้"            "ถ้าพนักงานหาย จ้างกลับได้เร็ว"

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

สรุปตอนนี้ — เจ้าของจำ 4 ข้อนี้พอ#

Domain 3 เป็นบทเทคนิคจัด แต่ถ้าเจ้าของจับ 4 ข้อนี้ได้ ก็เลือก control เรื่องความถูกต้องของข้อมูล AI ได้ถูกแล้วครับ:

AI สร้าง “ของพิเศษ” ที่ต้อง backup คนละแบบกับระบบปกติ — ที่สำคัญสุดคือ “น้ำหนักโมเดล” ไม่ใช่ข้อมูลดิบ (ข้อมูลดิบมัก backup ที่อื่นอยู่แล้ว อย่าทำซ้ำ) และต้องเก็บข้อมูล/ผลทดสอบไว้ “อธิบายโมเดล” ได้ในวันข้างหน้า
ความถูกต้องของ AI ถูกทำลายได้ 3 ทาง — วางยาข้อมูล (แก้ที่ข้อมูลสอน), วางยาโมเดล (แก้ที่สมองโดยตรง), วางยา embedding (แก้ที่ตัวเลขกลาง) ทั้งหมดเกิดเงียบ ระบบไม่ล่ม
ข้อมูลพังจาก ETL ผิดพลาด เกิดบ่อยกว่าถูกโจมตี — ต้องมีสูตรเตรียมข้อมูลที่เขียนชัด ทดสอบแล้ว ไม่ใช่พึ่งความจำของคนคนเดียว
control ที่คุ้มที่สุดคือ “คุม access ทั่วทั้งเส้นทางข้อมูล” ตามหลักสิทธิ์น้อยสุดเท่าที่จำเป็น — มันปิดประตูภัยทั้ง 3 ฉากพร้อมกัน และอย่าสับสนว่า backup = ป้องกันการวางยา (มันคนละเรื่อง)

และอย่าลืมว่า — เราเป็น เจ้าของความเสี่ยง + เป็นคนเลือก control เราไม่ต้องลงไปตั้งค่า backup หรือเขียน ETL เอง แต่เราต้องเข้าใจพอที่จะถามคำถามถูก, ตัดสินใจว่าจะลงเงินคุมจุดไหนก่อน, และจับได้เมื่อทีมตอบผิดคำถาม

ตอนหน้าเราจะเดินต่อในเส้นทางของ Domain 3 — ในเมื่อคุมข้อมูลและความถูกต้องของมันได้แล้ว คำถามถัดไปคือเรื่องของ control กลุ่มถัดไปที่ครอบคลุมความเป็นส่วนตัว จริยธรรม ความน่าเชื่อถือ และความปลอดภัยของ AI ที่เราจะค่อยๆ แกะกันต่อครับ

อ้างอิงแนวคิดหลักจาก: NIST AI Risk Management Framework (AI RMF 1.0, NIST AI 100-1, https://www.nist.gov/itl/ai-risk-management-framework) สำหรับกรอบการมองความเสี่ยง/ความถูกต้องของข้อมูล, MITRE ATLAS — Adversarial Threat Landscape for Artificial-Intelligence Systems (https://atlas.mitre.org) สำหรับนิยามการวางยาข้อมูล/โมเดล, OWASP Top 10 for LLM Applications และ OWASP AI Exchange (https://genai.owasp.org) สำหรับภัยของ data/model integrity เนื้อหาเรียบเรียงและยกตัวอย่างขึ้นใหม่ในมุมผู้บริหาร

AAISM — Domain 3: Section 3.5.4 Data Backup และ 3.5.5 Data Integrity