สารบัญ
AAISM Series — คู่มือคุม AI ในมุมคนบริหาร (ไม่ใช่มุมผู้ตรวจ) ตอนที่ 30 / Domain 3 — AI Technologies & Controls (บทเทคนิคที่ใหญ่และหนักที่สุดของซีรีส์) ซีรีส์นี้เล่าจากมุม “เจ้าของกิจการ / CISO ที่เอา AI มาใช้จริง” ว่าต้องตัดสินใจอะไรบ้าง (สารบัญเต็มจะตามมา)
📚 ตอนนี้จะมีคำว่า “เข้ารหัส (encryption)”, “ถอดรหัส (decryption)”, “เข้ารหัสตอนเก็บ (at rest)”, “เข้ารหัสตอนส่ง (in transit)” โผล่มาเต็มไปหมด — ผมจะ ไม่ อธิบายตั้งแต่ศูนย์ว่า “การเข้ารหัสทำงานยังไง”, “กุญแจสมมาตร/อสมมาตรต่างกันตรงไหน”, “ทำไมการบริหารกุญแจ (key management) ถึงสำคัญกว่าตัวอัลกอริทึมเอง” เพราะปูพื้นเรื่อง cryptography ไว้ละเอียดแล้วใน CyberSecurity Foundation ตอนที่ 19-23 — Cryptography 101 ใครยังไม่แม่นพื้นฐานพวกนี้แวะไปอ่านชุดนั้นก่อนได้ครับ ตอนนี้เราจะไม่ย้ำว่า “เข้ารหัสคืออะไร” แต่จะลงลึกในมุมที่ชุดนั้นยังไม่ได้พูด — เมื่อข้อมูลถูกเอาไปป้อน AI มันถูกแปลงร่าง เก็บในที่ใหม่ และบางจังหวะถูกถอดรหัสออกมา แล้วเจ้าของต้องเลือก control อะไรเพิ่มจากของเดิม
ลองนึกภาพบริษัทประกันขนาดกลางแห่งหนึ่ง (สมมติขึ้นมาให้เห็นภาพนะครับ) เก็บข้อมูลลูกค้ามาหลายสิบปี ทั้งประวัติสุขภาพ เลขบัตรประชาชน ประวัติการเคลม ข้อมูลการเงิน ทุกอย่างนอนนิ่งอยู่ในฐานข้อมูลที่ถูกล็อกแน่นหนา ใครจะเข้าถึงต้องขออนุมัติ มีบันทึกครบ เข้ารหัสไว้ทั้งก้อน ทีมไอทีก็ภูมิใจว่า “ข้อมูลเราปลอดภัยมาก”
แล้ววันหนึ่งบอร์ดสั่งลงมาว่า “เราต้องเอา AI มาช่วยประเมินความเสี่ยงการรับประกัน และทำผู้ช่วยตอบลูกค้าให้ได้ภายในปีนี้” ทีม data science ก็เริ่มงาน แต่เพื่อจะสอน AI ได้ พวกเขาต้อง ดึงข้อมูลลับทั้งหมดออกมาจากที่ที่ล็อกไว้ เอามากองรวมกันที่ใหม่ แปลงให้เป็นตัวเลขที่เครื่องอ่านได้ แล้วเก็บไว้ในฐานข้อมูลรูปแบบใหม่ที่ทีมไอทีไม่เคยเห็นมาก่อน
คำถามที่ทำให้ CISO นิ่งไปก็คือ “ตอนนี้ข้อมูลลับของเราไม่ได้อยู่ในที่เดิมที่เราล็อกไว้แล้ว มันถูกก๊อปไปแปลงร่างเก็บที่ใหม่หลายที่ การล็อกแบบเดิมยังคุมได้อยู่ไหม? แล้วจังหวะที่มันถูกถอดรหัสออกมาให้ AI อ่าน เรากันยังไง?” นี่แหละครับคือเรื่องของตอนนี้
ตั้งหลักก่อน — Domain 3 คือช่วง “ลงมือคุมงานจริง”
ทั้งซีรีส์นี้ผมชวนมองว่า AI = พนักงานใหม่เก่งสุดๆ คนหนึ่งที่เราต้องกำกับ Domain 1 เราคุยเรื่อง “ตั้งกฎ-วางโครงสร้างให้พนักงานคนนี้”, Domain 2 เราคุยเรื่อง “มองความเสี่ยง-ภัยที่มันเจอได้” มาถึง Domain 3 นี่คือช่วง “ลงมือคุมงานจริงในแต่ละวัน” เป็นบทที่เทคนิคที่สุดของทั้งซีรีส์ เพราะมันลงไปถึงตัวเทคโนโลยีและตัว control จริงๆ
แต่ผมขอย้ำตั้งแต่ต้นว่า แม้บทนี้จะเทคนิคแค่ไหน เราก็ยังเล่าในมุมเจ้าของอยู่ดี ไม่ใช่มุม data scientist ที่จะสอนสร้างโมเดล และไม่ใช่มุมผู้ตรวจที่จะมาไล่เช็กว่าผ่านไม่ผ่าน เป้าหมายของเราคือ “เข้าใจพอที่จะเลือก control ให้ถูก” คือเข้าใจว่าข้อมูลมันไหลไปไหน ถูกแปลงร่างยังไง เพื่อจะตัดสินใจได้ว่าต้องเอาเงิน คน เครื่องมือไปวางตรงไหน
เรื่องของตอนนี้แคบลงมาที่ data security สำหรับ AI คือ “การคุมความปลอดภัยของข้อมูล” ในบริบทที่เอาข้อมูลไปป้อน AI ซึ่งมันไม่เหมือนการคุมข้อมูลในระบบไอทีปกติ
มุมผู้บริหาร: ก่อนเข้าเนื้อ ขอวางความจริงข้อใหญ่ที่สุดของตอนนี้ไว้ก่อน แต่ก่อน CIO/CISO มีหน้าที่ “ล็อกข้อมูลให้แน่น เข้าถึงให้น้อยที่สุด” แต่พอบอร์ดสั่งให้เอา AI มาใช้ หน้าที่กลับด้านเลยครับ ตอนนี้พวกเขาถูกขอให้ “เปิดข้อมูลให้เข้าถึงได้มากขึ้น” เพื่อให้ AI เอาไปเรียนรู้ได้ ความตึงเครียดระหว่าง “ปลอดภัย” กับ “เข้าถึงได้” นี่แหละคือโจทย์หลักของทั้งตอน เจ้าของต้องเข้าใจว่าการเปิดข้อมูลให้ AI = เพิ่มพื้นที่เสี่ยง แล้วจึงต้องวาง control เพิ่มเพื่อชดเชย ไม่ใช่เปิดเฉยๆ แล้วหวังว่าของเดิมจะเอาอยู่
ภาพใหญ่ก่อน — ข้อมูลของ AI ไม่ได้นอนนิ่งเหมือนเดิม
ในระบบไอทีปกติ ข้อมูลลับมักอยู่ในที่เดียว ฐานข้อมูลหนึ่งก้อน เข้ารหัสไว้ ล็อก access ไว้ จบ เราคุมง่ายเพราะมันอยู่กับที่
แต่พอเอาข้อมูลไปป้อน AI มันต้อง เดินทางและแปลงร่างหลายขั้น ก่อนจะกลายเป็นสิ่งที่โมเดลเรียนรู้ได้ และในแต่ละขั้นมันถูกเก็บในรูปแบบใหม่ ที่ใหม่ และมีจุดเสี่ยงใหม่ที่ของเดิมไม่เคยมี
ผมขอวาดเส้นทางคร่าวๆ ให้เห็นภาพก่อน (โครงนี้ผมเรียบเรียงเองเพื่อให้เจ้าของเห็นภาพรวม ไม่ต้องจำรายละเอียดเทคนิค):
ข้อมูลจริง รวมกองที่ใหม่ แปลงเป็นตัวเลข เก็บรูปแบบใหม่ โมเดลเรียนรู้ (ในระบบเดิม) → (data lake) → (tokenization) → (vector DB, → (ตอนเทรน ลับ, เข้ารหัส รวมจากหลายที่ แตกเป็น token binary files) token+embedding ล็อกแน่น มากองรวม + embedding อยู่ใน GPU/RAM) │ │ │ │ │ จุดเสี่ยงเดิม จุดเสี่ยงใหม่ 1 จุดเสี่ยงใหม่ 2 จุดเสี่ยงใหม่ 3 จุดเสี่ยงใหม่ 4 (คุมเป็นอยู่แล้ว) รวมกอง=เป้าใหญ่ ข้อมูลถูกถอดรหัส ฐานข้อมูลชนิดใหม่ ข้อมูลโผล่ใน access ไม่ย้ายตาม เพื่อแปลง ที่ทีมไม่คุ้น หน่วยความจำชั่วคราวสามคำที่ตอนนี้จะเจาะคือสามจุดกลางของเส้นทางนี้ — และตรงกับสามหัวข้อย่อยของ data security สำหรับ AI:
| หัวข้อ | ภาษาคน | คำถามหลักที่เจ้าของต้องตอบ |
|---|---|---|
| Data Encoding (การแปลงข้อมูลเป็นรหัสตัวเลข) | ข้อมูลถูกแปลงเป็นตัวเลขแล้วเก็บที่ใหม่ | ของที่แปลงร่างแล้วนี้ เราล็อกเหมือนต้นฉบับหรือยัง |
| Data Access (การเข้าถึงข้อมูล) | ข้อมูลถูกรวมกองที่ใหม่ ใครเข้าได้บ้าง | พอรวมกอง access เดิมยังตามมาคุมไหม |
| Data Confidentiality (การรักษาความลับ) | บางจังหวะข้อมูลต้องถูกถอดรหัสออกมา | จังหวะที่มันเปลือย เรากันยังไง |
เราจะเจาะทีละหัวข้อครับ
หัวข้อที่ 1 — Data Encoding: เมื่อข้อมูลลับถูกแปลงเป็นตัวเลขแล้วเก็บที่ใหม่
มันคืออะไร (ภาษาคน)
AI โดยเฉพาะพวก deep learning (DL — โมเดลที่เลียนแบบสมองเป็นชั้นๆ) มันอ่าน “ข้อความ” หรือ “รูปภาพ” ตรงๆ ไม่ได้ครับ มันอ่านได้แต่ ตัวเลข ดังนั้นก่อนจะเอาข้อมูลดิบไปสอนโมเดล ทีมต้องแปลงข้อมูลให้กลายเป็นตัวเลขเสียก่อน กระบวนการแปลงนี้มีสองขั้นที่เจ้าของควรรู้จักชื่อไว้:
ขั้นที่ 1 — Tokenization (การแตกเป็นชิ้นเล็ก)
คือการเอาข้อความยาวๆ มาหั่นเป็นชิ้นเล็กๆ เรียกว่า “token” — token อาจเป็นคำ, ส่วนของคำ, หรือตัวอักษร แล้วแต่วิธี เปรียบเทียบง่ายๆ คือ ก่อนพนักงานใหม่จะอ่านเอกสารได้ เราต้องตัดเอกสารเป็นคำๆ ติดป้ายเลขประจำตัวให้แต่ละคำก่อน เช่นคำว่า “ลูกค้า” = เลข 4471, “เคลม” = เลข 882 พอแปลงครบ เอกสารทั้งฉบับก็กลายเป็นแถวของตัวเลข
ขั้นที่ 2 — Embedding (การแปลงเป็นพิกัดความหมาย)
token ที่เป็นเลขเฉยๆ ยังไม่พอ โมเดลต้องเข้าใจ “ความหมาย” และ “ความเกี่ยวข้อง” ของแต่ละ token ด้วย embedding คือการแปลง token แต่ละตัวให้กลายเป็น ชุดตัวเลขยาวๆ (เรียกว่า vector หรือเวกเตอร์) ที่เปรียบเสมือน “พิกัด” บอกตำแหน่งความหมายของคำนั้นในจักรวาลความหมาย คำที่ความหมายใกล้กัน (เช่น “หมา” กับ “สุนัข”) ก็จะมีพิกัดอยู่ใกล้กัน
ไม่ต้องจำรายละเอียดคณิตนะครับ จำแค่ว่า: ข้อความ → token (ตัวเลขประจำคำ) → embedding (พิกัดความหมายเป็นชุดตัวเลขยาว)
จุดที่เจ้าของต้องสะดุด — ของที่แปลงร่างแล้วก็ยังเป็นข้อมูลลับ
ตรงนี้คือกับดักความคิดที่อันตรายที่สุดของหัวข้อนี้ครับ หลายคนพอเห็นข้อมูลถูกแปลงเป็น “ตัวเลขมั่วๆ” แล้วก็รู้สึกว่า “มันไม่ใช่ข้อความที่อ่านรู้เรื่องแล้วนี่ คงไม่ลับแล้วมั้ง” ผิดครับ token และ embedding ที่สร้างจากข้อมูลลับ มันก็ยังเป็นตัวแทนของข้อมูลลับนั้นอยู่ดี คนที่มีโมเดลและ embedding สามารถถอดความหมายกลับ หรือใช้มันรั่วข้อมูลเดิมออกมาได้
แล้วของพวกนี้ถูกเก็บไว้ตรงไหนบ้าง? นี่คือจุดที่ทีมไอทีเดิมมักไม่รู้:
| สิ่งที่เก็บ | เก็บในรูปแบบไหน | จุดที่เจ้าของต้องระวัง |
|---|---|---|
| ข้อมูลที่ tokenize แล้ว | ไฟล์ binary (เช่นรูปแบบ TFRecords ของ TensorFlow) | “ไฟล์ binary อ่านไม่ออกด้วยตาเปล่า” ≠ “ปลอดภัย” — ต้องเข้ารหัส + คุม access เหมือนไฟล์ลับทั่วไป |
| token + embedding ตอนกำลังเทรน | อยู่ในหน่วยความจำ (RAM) หรือบนการ์ดจอ (GPU) | ข้อมูลโผล่อยู่ในหน่วยความจำชั่วคราวระหว่างเทรน — เครื่องที่เทรนต้องถูกคุมเข้มเหมือนเครื่องที่ถือข้อมูลลับ |
| สถานะโมเดลระหว่างทาง (checkpoint) | ไฟล์ checkpoint (เช่นนามสกุล .ckpt, .pth) | เป็นไฟล์ที่ทีมเซฟไว้ระหว่างเทรนเผื่อต้องกลับมาต่อ — มักถูกลืม ไม่ถูกนับว่าเป็นข้อมูลที่ต้องคุม |
(ชื่อนามสกุลไฟล์พวกนี้ — TFRecords, .ckpt, .pth — เจ้าของไม่ต้องจำหรอกครับ แค่ให้พอรู้ว่า “มันมีไฟล์พวกนี้เกิดขึ้นในกระบวนการ AI และต้องถามทีมว่าไฟล์พวกนี้ถูกคุมเหมือนข้อมูลต้นฉบับไหม”)
Vector Database — ฐานข้อมูลชนิดใหม่ที่ทีมไอทีอาจไม่เคยเจอ
ข้อมูลไม่ได้แปลงเป็น vector แค่ตอนเทรนนะครับ เดี๋ยวนี้ embedding (พิกัดความหมายที่เป็นชุดตัวเลข) ถูกเก็บถาวรไว้ในฐานข้อมูลชนิดใหม่ที่เรียกว่า vector database (ฐานข้อมูลเวกเตอร์) ซึ่งมาแรงมากเพราะ GenAI และ “การค้นแบบเข้าใจความหมาย (semantic search)”
มันต่างจากฐานข้อมูลที่เราคุ้นยังไง? ฐานข้อมูลแบบเดิม (relational database) เก็บข้อมูลเป็นตารางแถว-คอลัมน์ ค้นหาแบบ “ตรงเป๊ะ” (หาคำว่า “เคลม” ก็เจอแถวที่มีคำว่า “เคลม”) แต่ vector database เก็บข้อมูลเป็นพิกัดความหมาย แล้วค้นแบบ “ใกล้เคียงความหมาย” (ถามเรื่อง “การเรียกร้องค่าสินไหม” มันก็ดึงแถวเรื่อง “เคลม” มาให้ได้ แม้จะไม่มีคำตรงกันเลย) นี่แหละคือหัวใจที่ทำให้ผู้ช่วย AI ตอบคำถามจากเอกสารบริษัทได้
ในมุมเจ้าของ ปัญหาคือ vector database มันคือ “ที่เก็บข้อมูลลับ” อีกที่หนึ่งที่เพิ่งโผล่ขึ้นมาในบริษัท และทีมไอทีเดิมอาจไม่มีประสบการณ์คุมมัน การล็อกแบบเดิมที่ทำกับฐานข้อมูลปกติอาจไม่ครบ เพราะ vector database มีจุดคุมเฉพาะของมันเพิ่ม
| สิ่งที่ต้องคุมใน vector database | ทำไม |
|---|---|
| Access control + เข้ารหัส | พื้นฐานเหมือนฐานข้อมูลลับทั่วไป — แต่ห้ามลืมว่ามันคือข้อมูลลับ |
| การออกแบบและคุม “vector index” | index คือดัชนีที่ใช้ค้นข้อมูลในฐานนี้ — ถ้าใครเข้าถึง index ได้ ก็เท่ากับมีกุญแจค้นทั้งคลังความหมาย จุดนี้เป็น control เฉพาะที่ฐานข้อมูลธรรมดาไม่มี |
มุมผู้บริหาร: คำถามที่เจ้าของควรถามทีมในหัวข้อนี้ไม่ใช่ “tokenization ทำงานยังไง” (นั่นเป็นเรื่องของทีม) แต่เป็น “พอเราเอาข้อมูลลับไปป้อน AI มันถูกก๊อปไปแปลงร่างเก็บไว้ที่ไหนใหม่บ้าง — ไฟล์ binary, checkpoint, vector database — แล้วทุกที่ที่เกิดใหม่นั้นถูกล็อกและเข้ารหัสเหมือนต้นฉบับหรือยัง?” กับดักที่อันตรายคือ บริษัทล็อกฐานข้อมูลต้นทางไว้แน่นมาก แต่ปล่อยให้ “สำเนาที่แปลงร่างแล้ว” นอนเปลือยอยู่ในที่ใหม่โดยไม่มีใครคุม เพราะคิดว่า “มันเป็นแค่ตัวเลข ไม่ลับแล้ว” — ความเสี่ยงไม่ได้หายไปกับการแปลงร่าง มันแค่ย้ายที่
กับดักที่พบบ่อย (หัวข้อ 1):
- “ไฟล์ binary อ่านไม่ออก = ปลอดภัย” → ผิด อ่านไม่ออกด้วยตาคน ไม่ได้แปลว่าเครื่องถอดกลับไม่ได้
- “vector database ก็แค่ฐานข้อมูล ทีม DBA เดิมคุมได้” → คุมพื้นฐานได้ แต่ลืม index control และอาจไม่รู้ว่ามันถือข้อมูลลับ
- “checkpoint เป็นแค่ไฟล์ชั่วคราวระหว่างเทรน” → checkpoint ถือสถานะที่ฝังข้อมูลลับไว้ ถ้าไม่ลบ/ไม่คุม ก็เป็นช่องรั่ว
หัวข้อที่ 2 — Data Access: เมื่อข้อมูลถูกรวมกองที่ใหม่ การล็อกเดิมตามไม่ทัน
มันคืออะไร (ภาษาคน)
เพื่อจะสอน AI ทีมต้องรวบรวมข้อมูลจาก หลายแหล่ง มากองรวมกันที่เดียว ข้อมูลลูกค้าจากระบบ A ประวัติธุรกรรมจากระบบ B ข้อมูลจากระบบ C เอามากองในที่เก็บกลางที่เรียกว่า data lake (ทะเลสาบข้อมูล คือที่เก็บข้อมูลดิบขนาดใหญ่จากหลายแหล่งรวมกัน)
ฟังดูเป็นเรื่องดีนะ ข้อมูลอยู่ที่เดียว ทีมทำงานสะดวก แต่การ “รวมกอง” นี่แหละที่สร้างความเสี่ยงใหม่ขึ้นมาหลายอย่าง
📚 เรื่องการคุมว่า “ใครเข้าถึงอะไรได้บ้าง (access control / least privilege)” ตัวพื้นฐานปูไว้แล้วในชุด IAM ตอนที่ 10-17 ตอนนี้ผมจะไม่ย้ำว่า least privilege คืออะไร แต่จะเล่าเฉพาะมุมที่ “การรวมกองข้อมูลเพื่อ AI” ทำให้ access control เดิมพังได้ยังไง
ความเสี่ยงที่เกิดจากการ “รวมกอง”
ผมขอแยกความเสี่ยงเป็น 4 ข้อให้เห็นชัด (เรียบเรียงเองจากแนวคิดในคู่มือ):
1. รวมกองแล้วกลายเป็นเป้าใหญ่ — ขโมยทีเดียวได้หมด
ตอนข้อมูลกระจายอยู่ตามระบบต่างๆ ขโมยที่หนึ่งได้แค่ส่วนเดียว แต่พอรวมเป็น data lake ก้อนเดียว มันกลายเป็น “ตู้เซฟใบใหญ่ที่สุดในบริษัท” เจาะได้ทีเดียวก็เอาไปได้หมด แล้วยิ่งข้อมูลถูกรวบและจัดระเบียบไว้เรียบร้อยแล้ว การดูดออกไป (exfiltrate) ก็ยิ่งง่ายกว่าตอนที่มันกระจัดกระจาย เปรียบเทียบคือ แต่ก่อนเอกสารลับกระจายอยู่หลายตึก ขโมยลำบาก แต่พอเอามากองรวมในห้องเดียว โจรเข้าห้องเดียวก็ได้ไปทุกอย่าง
2. ย้ายข้อมูลแล้วลืมย้าย “การล็อก” ตามไปด้วย
นี่คือข้อที่อันตรายเงียบๆ ที่สุดครับ ข้อมูลแต่ละแหล่งต้นทางมันมีการล็อก (access control) และการเข้ารหัสของมันเองอยู่แล้ว แต่พอ ย้ายข้อมูลจากต้นทางมาที่ data lake การล็อกเดิมมักไม่ได้ถูกย้ายตามมาด้วย เช่น ที่ระบบต้นทางข้อมูลสุขภาพถูกจำกัดให้เฉพาะแผนกการแพทย์เข้าได้ แต่พอก๊อปมากองที่ data lake กลับกลายเป็น “ใครในทีม data science ก็เข้าได้หมด” ข้อมูลที่เคยลับสุดยอดก็กลายเป็นเปิดกว้างโดยที่ไม่มีใครตั้งใจ
3. การ “สำรวจข้อมูล” ทำให้ขอบเขตการเข้าถึงบานออก
ก่อนสร้างโมเดล data scientist ต้อง “สำรวจ (explore)” ข้อมูลก่อนว่าจะเอาไอเดียไหนมาทำได้บ้าง ขั้นตอนนี้ทำให้พวกเขาขอเข้าถึงข้อมูล กว้างกว่า ที่ข้อมูลนั้นเคยถูกเก็บมาเพื่อใช้ตอนแรก เช่น ข้อมูลที่เก็บมาเพื่อ “ออกกรมธรรม์” อาจถูกขอเอาไปสำรวจเพื่อทำโมเดลการตลาด ซึ่งมันเกินวัตถุประสงค์เดิมที่ลูกค้ายินยอม ตรงนี้กระทบทั้งเรื่อง least privilege และเรื่องความเป็นส่วนตัว (privacy)
4. รวมกองแล้วเพิ่ม “จำนวนระบบที่ต้องดูแลตามกฎ”
พอก๊อปข้อมูลจากหลายแหล่งมารวม + ทำสำเนาเพื่อสำรวจและเทรน เท่ากับเราสร้าง ระบบใหม่ๆ ที่ต้องถูกคุมให้ครบตามกฎหมาย/มาตรฐาน เพิ่มขึ้นเรื่อยๆ ขอบเขตของงาน compliance บานออกโดยอัตโนมัติ ทุกที่ที่ข้อมูลลับไปอยู่ = อีกหนึ่งที่ที่ต้องป้องกันและต้องพิสูจน์ได้ว่าป้องกันแล้ว
control ที่เจ้าของต้องสั่งให้มี
| ความเสี่ยงจากการรวมกอง | control ที่ต้องวาง |
|---|---|
| รวมกอง = เป้าใหญ่ | คุมเข้มเป็นพิเศษที่ data lake (เข้ารหัส, monitor การดูดข้อมูลออก, จำกัด export) |
| ล็อกเดิมไม่ตามมา | ทบทวน dataflow ทั้งเส้น — ไล่ดูว่าข้อมูลไหลจากต้นทางไปไหนบ้าง แล้วเทียบว่าการล็อกที่ปลายทาง “เข้มเท่าต้นทาง” ไหม |
| สำรวจข้อมูลทำขอบเขตบาน | ทบทวนว่าการเอาข้อมูลไปใช้ตรงกับวัตถุประสงค์ที่เก็บมาแต่แรกไหม |
| ระบบในขอบเขตเพิ่ม | ทบทวน networking policy ให้ข้อมูลถูก “กักบริเวณ” อยู่ในระบบที่ได้รับอนุญาตเท่านั้น |
หัวใจของหัวข้อนี้คือคำว่า “ทบทวน dataflow” เจ้าของต้องสั่งให้ทีมวาดแผนที่ว่าข้อมูลไหลจากไหนไปไหน ผ่านระบบอะไรบ้าง ใครแตะได้บ้าง แล้วเทียบทุกจุดว่าการล็อกสอดคล้องกันตลอดเส้นทาง ไม่ใช่แน่นแค่ต้นทางแล้วหลวมที่ปลายทาง
มุมผู้บริหาร: คำถามเด็ดที่เจ้าของควรถามคือ “ข้อมูลที่ระบบต้นทางเราล็อกไว้ว่าเฉพาะแผนก X เข้าได้ พอมันถูกก๊อปมากองที่ data lake เพื่อทำ AI ตอนนี้ใครเข้าถึงมันได้บ้าง? เท่าเดิมหรือกว้างกว่าเดิม?” ถ้าทีมตอบไม่ได้ทันที แปลว่าการล็อกไม่ได้ถูกย้ายตามข้อมูลมา ซึ่งเป็นช่องโหว่ที่พบบ่อยมากและมองไม่เห็นด้วยตา เพราะระบบยัง “ทำงานปกติ” ไม่มีอะไรล่มให้เห็น
กับดักที่พบบ่อย (หัวข้อ 2):
- “เราเข้ารหัส data lake แล้ว = ปลอดภัย” → เข้ารหัสกัน “คนนอก” แต่ปัญหาส่วนใหญ่คือ “คนในที่เข้าถึงได้กว้างเกิน” หลังย้ายข้อมูล
- “data lake ทีม data ดูแล จบ” → ทีม data ดูแลความสะดวก แต่อาจไม่ได้ดูแลความสอดคล้องของ access control กับต้นทาง
- “รวมข้อมูลไว้ที่เดียวจัดการง่ายกว่า” → ง่ายต่อทีม = ง่ายต่อโจรเหมือนกัน ต้องชั่งน้ำหนัก
หัวข้อที่ 3 — Data Confidentiality: จังหวะที่ข้อมูลลับ “ต้องเปลือย” ให้ AI อ่าน
ปัญหาที่ฝืนธรรมชาติของ AI
นี่คือหัวข้อที่เจ็บปวดที่สุดในเชิงหลักการครับ และเป็นจุดที่ทำให้ data security ของ AI ต่างจากระบบไอทีปกติอย่างชัดเจนที่สุด
ในระบบไอทีปกติ เราอยากให้ข้อมูลลับ ถูกเข้ารหัส/ปิดบังไว้ตลอดเวลา ยิ่งเปิดเผยน้อยยิ่งดี ระบบที่จัดการข้อมูลสุขภาพ-การเงิน-ส่วนบุคคล มักมีการปิดบัง (obfuscation) และเข้ารหัสครอบไว้
แต่ปัญหาคือ AI หลายตัวต้องการให้ข้อมูล “อ่านออกด้วยเครื่อง (machine readable)” ถึงจะทำงานได้ โดยเฉพาะวิธี tokenization ยอดนิยมอย่าง BPE (byte-pair encoding) และ WordPiece ที่ใช้กันแพร่หลายในโมเดลภาษา สองวิธีนี้ต้องการ ข้อความที่เป็น cleartext (ข้อความเปลือยที่ยังไม่เข้ารหัส) เพื่อจะแตกมันเป็น token และแปลงเป็นเมทริกซ์ตัวเลขได้
ผลที่ตามมาที่เจ้าของต้องเข้าใจก็คือ ในบางจังหวะของกระบวนการพัฒนา AI ข้อมูลลับบางส่วน “จำเป็นต้องถูกถอดรหัสออกมา” เพราะถ้ายังเข้ารหัสอยู่ AI มันแตก token ไม่ได้ มันเลยฝืนธรรมชาติของการรักษาความลับแบบเดิมที่อยากให้มันเข้ารหัสตลอดเวลา
เปรียบเทียบง่ายๆ คือ เราอยากให้เอกสารลับอยู่ในซองปิดผนึกตลอด แต่พนักงาน AI คนนี้มันอ่านผ่านซองไม่ได้ มันต้อง “แกะซองอ่าน” ก่อนถึงจะเรียนรู้ได้ ช่วงที่แกะซองนั่นแหละคือช่วงที่เอกสารเปลือยและเสี่ยงที่สุด
ทางออกในอนาคต — Homomorphic Encryption (แต่ยังไม่พร้อมตอนนี้)
มีเทคโนโลยีหนึ่งที่เป็นความหวังในการแก้ปัญหานี้ ชื่อว่า homomorphic encryption (การเข้ารหัสแบบฮอมอมอร์ฟิก) แนวคิดของมันแทบจะเหมือนเวทมนตร์ครับ คือมันทำให้ AI สามารถ เรียนรู้และประมวลผลข้อมูลได้ทั้งๆ ที่ข้อมูลยังเข้ารหัสอยู่ ไม่ต้องถอดรหัสออกมาเลย ข้อมูลลับไม่ต้องเปลือยสักวินาที พนักงาน AI อ่านได้ทั้งที่ซองยังปิดผนึก
ฟังดูเป็นคำตอบที่สมบูรณ์แบบใช่ไหมครับ แต่นี่คือจุดสำคัญที่เจ้าของต้องเข้าใจ มันยังใช้จริงในวงกว้างไม่ได้ในตอนนี้ เพราะการประมวลผลบนข้อมูลที่เข้ารหัสไว้ กินทรัพยากรการคำนวณมหาศาล ช้าและแพงกว่าการประมวลผลข้อมูลปกติหลายเท่าตัวมาก จนไม่คุ้มในการใช้งานจริงส่วนใหญ่
มุมผู้บริหาร: ถ้ามีใคร (โดยเฉพาะเวนเดอร์) มาขายว่า “ระบบเราใช้ homomorphic encryption นะ ข้อมูลคุณไม่ต้องถอดรหัสเลย ปลอดภัย 100%” — เจ้าของควรตั้งคำถามต่อทันทีว่า “ใช้กับงานทั้งหมดจริงหรือใช้แค่บางส่วน? แล้วต้นทุนการประมวลผล/ความเร็วเป็นยังไง?” เพราะ ณ ตอนนี้มันยังไม่ใช่เทคโนโลยีที่ใช้ครอบคลุมได้ในทางปฏิบัติทั่วไป รู้จักมันไว้ในฐานะ “ทิศทางอนาคต” ที่ควรจับตา ไม่ใช่ “ของที่พร้อมพึ่งวันนี้”
แล้ววันนี้ต้องทำยังไง — Compensating Controls
ในเมื่อข้อมูลยัง “ต้องเปลือย” ในบางจังหวะ และเทคโนโลยีที่จะแก้ที่ต้นเหตุยังไม่พร้อม สิ่งที่เจ้าของต้องสั่งให้ทำคือวาง compensating control (มาตรการชดเชย — control ที่เอามาทดแทนเมื่อแก้ที่ต้นเหตุไม่ได้) ล้อมจังหวะที่ข้อมูลเปลือยเอาไว้ ให้แน่นที่สุด:
| มาตรการชดเชย | ทำเพื่ออะไร |
|---|---|
| จำกัดการเข้าถึงข้อมูล production ที่ยังไม่เข้ารหัส | ลดจำนวนคน/ระบบที่แตะข้อมูลเปลือยให้น้อยที่สุดเท่าที่งานจะเดินได้ |
| เฝ้าดู (monitor) การใช้งานข้อมูลอ่อนไหว | จับได้เร็วถ้ามีการแตะข้อมูลเปลือยผิดปกติ — เพราะกันไม่ให้เปลือยเลยไม่ได้ ก็ต้องเฝ้าตอนมันเปลือยแทน |
| เข้ารหัสระดับดิสก์ (disk-level encryption) | เป็นเกราะชั้นลึก (defense in depth) — ถึงข้อมูลจะต้องเปลือยตอนประมวลผล แต่ตอนนอนอยู่บนดิสก์ก็ยังถูกเข้ารหัสไว้ |
หลักคิดคือ เมื่อ กันไม่ให้ข้อมูลเปลือยเลยไม่ได้ เราก็ต้อง (1) ทำให้มันเปลือย น้อยที่สุด เท่าที่งานจะเดินได้ (2) ให้ คนน้อยที่สุด แตะมันตอนเปลือย และ (3) เฝ้าดู ทุกครั้งที่มันเปลือย พร้อมวางเกราะหลายชั้นซ้อนไว้ เผื่อชั้นหนึ่งพลาดยังมีอีกชั้นรับ
มุมผู้บริหาร: หัวข้อนี้สอนบทเรียนสำคัญที่สุดของ data security สำหรับ AI — อย่าคาดหวังว่าจะ “เข้ารหัสทุกอย่างตลอดเวลา” ได้เหมือนระบบเดิม เพราะธรรมชาติของ AI บังคับให้ต้องมีจังหวะที่ข้อมูลเปลือย เจ้าของจึงต้องเปลี่ยนคำถามจาก “เราเข้ารหัสครบไหม” มาเป็น “จุดที่ข้อมูลต้องเปลือยมีตรงไหนบ้าง เปลือยน้อยที่สุดแล้วหรือยัง ตอนนั้นใครแตะได้ แล้วเราเฝ้าดูมันอยู่ไหม” นี่คือการคิดแบบ “ยอมรับว่าป้องกัน 100% ไม่ได้ จึงคุมให้แคบและเฝ้าให้ดี” ซึ่งเป็นมุมที่เป็นผู้ใหญ่กว่าการหวังจะล็อกทุกอย่างตายตัว
กับดักที่พบบ่อย (หัวข้อ 3):
- “เราเข้ารหัสข้อมูลทุกอย่าง = AI ปลอดภัยจากข้อมูลรั่ว” → ลืมว่ามันต้องถูกถอดรหัสตอน tokenize อยู่ดี
- “homomorphic encryption แก้ได้หมดแล้ว” → ยังแพง/ช้าเกินไปสำหรับงานจริงทั่วไป ณ ตอนนี้
- “ถ้ากันไม่ได้ ก็ปล่อยไป” → กันที่ต้นเหตุไม่ได้ ไม่ได้แปลว่าปล่อย ต้องวาง compensating control + monitor แทน
ร้อยทั้งสามหัวข้อเข้าด้วยกัน — เจ้าของถามอะไร
สามหัวข้อนี้จริงๆ แล้วคือเรื่องเดียวกัน “ข้อมูลลับของเราเดินทางและแปลงร่างไปทั่วเมื่อเอาไปป้อน AI การล็อกแบบนอนนิ่งที่เดียวแบบเดิมจึงไม่พอ” เจ้าของไม่ต้องลงไปทำเอง แต่ต้องถามให้ครบทั้งเส้นทาง:
| ช่วงของข้อมูล | คำถามที่เจ้าของต้องถาม |
|---|---|
| ตอนแปลงร่าง (encoding) | สำเนาที่แปลงเป็น token/embedding/vector DB/checkpoint ถูกล็อก+เข้ารหัสเหมือนต้นฉบับไหม |
| ตอนรวมกอง (access) | พอรวมที่ data lake แล้ว access เดิมตามมาคุมไหม หรือใครๆ ก็เข้าได้ |
| ตอนต้องเปลือย (confidentiality) | จุดที่ข้อมูลต้องถูกถอดรหัสมีตรงไหน เปลือยน้อยสุดแล้วไหม ใครแตะได้ เฝ้าดูอยู่ไหม |
จุดร่วมที่อยากให้เจ้าของจำขึ้นใจ 3 ข้อ:
- การแปลงร่างไม่ได้ทำให้ความลับหายไป token, embedding, vector มันยังเป็นตัวแทนข้อมูลลับอยู่ อย่าเผลอคิดว่า “เป็นตัวเลขแล้วไม่ลับ”
- ความเสี่ยงเดินตามข้อมูลไป ทุกที่ที่ข้อมูลลับไปอยู่ (ที่ใหม่ ฐานข้อมูลชนิดใหม่ เครื่องที่เทรน) = อีกหนึ่งจุดที่ต้องคุมและต้องพิสูจน์ได้ว่าคุมแล้ว ต้องวาด dataflow ให้เห็นทั้งเส้น
- เลิกหวังจะเข้ารหัส 100% ตลอดเวลา ธรรมชาติ AI บังคับให้มีจังหวะเปลือย จึงต้องคิดแบบ “คุมให้แคบ เฝ้าให้ดี วางเกราะหลายชั้น” แทน
และอย่าลืมหัวใจของทั้งซีรีส์ เราเป็น เจ้าของความเสี่ยง ไม่ต้องลงไปแกะ tokenizer หรือเขียนโค้ดเข้ารหัสเอง แต่ต้องเข้าใจเส้นทางของข้อมูลพอที่จะ ถามถูก ตัดสินใจถูก และเลือก control ให้ลงตรงจุด ที่เหลือเป็นงานทีมเทคนิค
ตอนหน้าเราจะเดินต่อในเส้นเรื่อง Domain 3 พอรู้แล้วว่า “ข้อมูล” ที่ป้อนพนักงาน AI ต้องคุมยังไง คำถามถัดไปคือเรื่องที่ลึกขึ้นไปอีกชั้น คือ ความเป็นส่วนตัว จริยธรรม ความน่าเชื่อถือ และความปลอดภัยของตัวพนักงาน AI เอง ว่าเราจะคุมพฤติกรรมของมันให้ “ไว้ใจได้และไม่ทำร้ายใคร” ได้ยังไง ซึ่งเป็นอีกชุด control ที่เจ้าของต้องเลือกให้เป็นครับ
อ้างอิงแนวคิดหลักจาก: NIST AI Risk Management Framework (AI RMF 1.0) สำหรับกรอบการคุมความเสี่ยงข้อมูลในวงจรชีวิต AI, แนวทาง least privilege และ data security ตามหลัก information security ทั่วไป เนื้อหาด้านเทคนิค (tokenization, embedding, vector database, BPE/WordPiece, homomorphic encryption) เรียบเรียงและยกตัวอย่างขึ้นใหม่ในมุมผู้บริหาร
AAISM — Domain 3: Section 3.5 Data Security (3.5.1 Data Encoding, 3.5.2 Data Access, 3.5.3 Data Confidentiality/Secrecy)
