AAISM Series ตอนที่ 25 : D3 - สถาปัตยกรรม AI ที่ปลอดภัย — Secure-by-Design + DevSecOps สำหรับ AI

Series: AAISM — AI Security Management สำหรับเจ้าของกิจการ (มุม Deployer/ผู้บริหาร)

ตอนที่ 25 / Domain 3 — AI Technologies & Controls (บทใหญ่ที่สุด เทคนิคที่สุด)

(สารบัญเต็มจะตามมาครับ — ตอนนี้ขอเล่าไล่เป็นตอนๆ ไปก่อน)

📚 พื้นฐานที่ควรอ่านคู่กัน: ตอนนี้ผมจะพูดเรื่อง DevSecOps เยอะมาก — แนวคิดที่เอา “ความปลอดภัย” ไปฝังเข้าไปในทุกขั้นตอนของการพัฒนาและดูแลระบบ แทนที่จะเอามาแปะทีหลัง. ถ้าใครยังไม่แม่นว่า DevSecOps / Shift-Left / CI-CD pipeline คืออะไร ผมแนะนำให้อ่าน CyberSecurity Foundation EP.34 — DevSecOps + Shift-Left ก่อนสักรอบ. ตอนนี้ผมจะ ไม่สอนพื้นฐาน DevSecOps ซ้ำ — แต่จะเล่าเฉพาะ มุมที่ AI ทำให้ภาพมันแปลกไปจากซอฟต์แวร์ธรรมดา และ มุมที่ผู้บริหารต้องตัดสินใจเลือก control

เอาล่ะครับ มาถึง Domain 3 แล้ว โดเมนที่ใหญ่ที่สุดและเทคนิคที่สุดของทั้งคอร์ส.

ขอเตือนไว้ก่อนเลยนะ ว่า Domain 3 จะมีศัพท์เทคนิคโผล่มาเยอะกว่าทุกโดเมนที่ผ่านมา แต่ขอให้ใจเย็นๆ ผมไม่ได้จะสอนคุณสร้างโมเดล AI (นั่นเป็นงานของ data scientist) แล้วก็ไม่ได้จะสอนคุณตรวจ AI แบบ auditor ด้วย. มุมที่ยืนอยู่ตลอด Domain 3 คือมุมเดิมที่เราใช้มาตั้งแต่ต้น —

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

เปรียบเหมือนเจ้าของบ้านที่จะสร้างบ้าน คุณไม่ต้องผสมปูนเอง ไม่ต้องเดินสายไฟเอง แต่ต้องอ่านแบบแปลนเป็น พอที่จะรู้ว่า “ตรงนี้ทำไมต้องมีเสาเข็ม” “ทำไมห้องน้ำต้องกันซึม” “ทำไมต้องวางท่อก่อนเทพื้น ไม่ใช่มาทุบทีหลัง” จะได้คุยกับผู้รับเหมารู้เรื่อง ตรวจงานเป็น แล้วก็ไม่โดนหลอก. Domain 3 ก็คือ “แบบแปลนของบ้าน AI” นี่แหละ และตอนนี้เราเริ่มกันที่ฐานราก คือ สถาปัตยกรรม (Architecture)

ทบทวนสั้นๆ: เราเดินมาถึงไหนแล้ว#

จำ hero metaphor ของซีรีส์นี้ได้ไหมครับ — AI = พนักงานใหม่เก่งสุดๆ ที่ต้องกำกับ

Domain 1 เราคุยเรื่อง “ตั้งกฎ” — governance, policy, ใครรับผิดชอบอะไร เหมือนเขียนสัญญาจ้างและ job description ให้พนักงานคนนี้
Domain 2 เราคุยเรื่อง “มองความเสี่ยง” — พนักงานคนนี้เสี่ยงพังตรงไหน โดนโจมตีตรงไหน แล้วตัดสินใจว่าจะรับมือยังไง (accept / avoid / mitigate / transfer)
Domain 3 — ที่เรากำลังจะเข้านี้ — คือ “ลงมือคุมงานจริงในแต่ละวัน”. เราตัดสินใจแล้วว่าจะ “mitigate” ความเสี่ยง — Domain 3 คือ คลังเครื่องมือจริงๆ ที่เราหยิบมาคุมพนักงานคนนี้ในแต่ละจุด

และจุดเริ่มต้นของการคุมงานจริง ก่อนที่พนักงานคนนี้จะเริ่มทำงานวันแรกด้วยซ้ำ ก็คือเรื่อง “เราจะวางโต๊ะทำงานให้เขาตรงไหน เสียบเข้าระบบไหน เก็บงานเขาไว้ที่ไหน” นั่นแหละครับคือ สถาปัตยกรรม AI ที่ปลอดภัย (AI Security Architecture)

1. ก่อนอื่น — เราเป็นใครในวงจร AI? (Provider / Producer / Customer)#

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

คู่มือ AAISM บอกว่า control ที่เราต้องวาง มันขึ้นอยู่กับว่าเราเล่นบทบาทไหนในวงจร AI มีอยู่ 3 บทบาทหลัก ผมขอเรียบเรียงเป็นภาษาคนแบบนี้ครับ:

บทบาท	เราทำอะไร	เทียบกับร้านอาหาร
AI Provider (ผู้ให้บริการ AI)	เอาระบบ AI ของคนอื่น (หรือของเรา) มาห่อเป็น “สินค้า/บริการ” แล้วส่งต่อให้ลูกค้าใช้	เป็น “แฟรนไชส์” — เอาสูตรกลางมาเปิดสาขาขายต่อ
AI Producer (ผู้ผลิต AI)	ออกแบบ พัฒนา เทรน เทสต์ และ deploy โมเดลเอง — มี data scientist, model designer ในทีม	เป็น “เชฟที่คิดสูตรเอง” — ทำตั้งแต่วัตถุดิบ
AI Customer (ผู้ใช้ AI)	หยิบ AI ของคนอื่นมาใช้ ในงานเรา ไม่ว่าใช้เองหรือส่งต่อให้พนักงาน/ลูกค้าใช้	เป็น “ลูกค้าที่สั่งอาหารมากิน” — ไม่ได้ทำครัวเอง

มุมผู้บริหาร: ก่อนจะวาง control อะไรเลย ให้ถามตัวเองข้อเดียว — “เราคิดสูตรเอง หรือซื้อสูตรเขามาใช้?” เจ้าของกิจการ mass ส่วนใหญ่ — ผมขอเดาว่า 90% ขึ้นไป — เป็น AI Customer ครับ คือเราซื้อ ChatGPT Enterprise มาใช้ ซื้อ Copilot มาเสียบ Office ซื้อ AI ของ vendor มาเสียบระบบ CRM. เราไม่ได้เทรนโมเดลเอง. การรู้ตรงนี้ชัดๆ สำคัญมาก เพราะมันบอกว่า control ก้อนไหน “เป็นของเรา” และก้อนไหน “เราต้องไปบีบให้ vendor ทำ” (จำ Shared Responsibility Model จาก Domain 2 ได้ไหมครับ — เรื่องนี้ต่อยอดโดยตรง)

ทำไมถึงตอบผิดบ่อย? เพราะหลายองค์กรเริ่มจากเป็น Customer (ซื้อมาใช้) แล้ววันหนึ่งก็ค่อยๆ ขยับเป็น Producer โดยไม่รู้ตัว เช่น เริ่มเอาข้อมูลลูกค้าของเราไป fine-tune (ปรับจูนโมเดลด้วยข้อมูลเฉพาะของเรา) หรือเริ่มสร้าง AI agent ที่ผูกหลายโมเดลเข้าด้วยกัน. พอข้ามเส้นจาก “ใช้” ไปเป็น “ผลิต/ปรับแต่ง” ความรับผิดชอบด้านความปลอดภัยมันก็เปลี่ยนไปทั้งชุด แต่หลายคนยังคิดว่าตัวเองเป็นแค่ลูกค้าอยู่เลย. นั่นแหละคือจุดที่ control เริ่มมีรู.

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

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

2. หัวใจของตอนนี้: Secure-by-Design — ความปลอดภัยที่ “ฝัง” ไม่ใช่ “แปะ”#

ถ้าให้เลือกแนวคิดเดียวจากตอนนี้ที่อยากให้เจ้าของกิจการจำติดตัวกลับไป ผมเลือกคำนี้ครับ Secure-by-Design (ความปลอดภัยตั้งแต่ออกแบบ)

2.1 Secure-by-Design คืออะไร (ภาษาคน)#

Secure-by-design คือกระบวนการที่ทำให้สินค้า/ระบบเทคโนโลยี “ถูกสร้างขึ้นในแบบที่ปกป้องตัวเองจากคนร้ายได้อย่างสมเหตุสมผล” คือฝังแนวคิดความปลอดภัยเข้าไปในงาน ตั้งแต่วินาทีแรกที่เริ่มออกแบบ ไปจนถึงวันที่เลิกใช้ ไม่ใช่ไปนึกได้ทีหลังตอนจะส่งมอบ.

ลองนึกภาพแบบนี้ครับ. สมมติว่าคุณกำลังสร้างบ้านใหม่.

แบบ “แปะทีหลัง” (ที่เราทำกันมาตลอดในยุคเก่า) ก็คือ สร้างบ้านเสร็จสวยงาม เข้าอยู่แล้ว ค่อยมานึกได้ว่า “เอ๊ะ ลืมติดกลอนประตู ลืมทำรั้ว ลืมติดกล้อง” แล้วก็ไล่แปะทีหลัง. ผลคือกลอนเก๊กับวงกบ รั้วเตี้ยไป กล้องติดมุมอับ เพราะบ้านมันไม่ได้ออกแบบมาให้มีของพวกนี้ตั้งแต่แรก
แบบ “Secure-by-Design” ก็คือ ตอนเขียนแบบแปลน สถาปนิกคิดเรื่องความปลอดภัยพร้อมกับคิดเรื่องห้องนอนห้องครัวไปเลย. ตำแหน่งประตู หน้าต่าง รั้ว กล้อง ไฟ ถูกออกแบบให้ทำงานร่วมกันตั้งแต่ต้น

ความต่างก็คือ แบบแรก ความปลอดภัยเป็น “ของแถม” ที่มาทีหลังและมักจะหลวม ส่วนแบบหลัง ความปลอดภัยเป็น “โครงสร้าง” ที่ฝังอยู่ในตัวบ้าน. กับ AI ก็เหมือนกันเป๊ะ แถมยิ่งสำคัญกว่าอีก เพราะ AI แก้ทีหลังมันยากกว่าซอฟต์แวร์ธรรมดามาก (เดี๋ยวเล่าเรื่องนี้ในหัวข้อ emergency change)

2.2 หลัก 3 ข้อของ Secure-by-Design#

คู่มืออ้างกรอบ secure-by-design (ซึ่งเป็นแนวทางสาธารณะที่ CISA และหน่วยงานความมั่นคงไซเบอร์หลายประเทศผลักดัน) มี 3 หลักใหญ่. ผมขอแปลเป็นภาษาเจ้าของกิจการ พร้อมโยงว่ามันหมายถึงอะไรในโลก AI:

หลักการ	แปลเป็นภาษาคน	ในโลก AI หมายถึง
1. รับผิดชอบผลลัพธ์ความปลอดภัยของลูกค้า (Take ownership of customer security outcomes)	“ความปลอดภัยของลูกค้าเป็นภาระของเรา ไม่ใช่ของลูกค้า” — เราต้องทำให้ระบบปลอดภัยมาแต่โรงงาน ไม่ใช่โยนให้ลูกค้าไปตั้งค่าเอง	จัดการ consent ของข้อมูล ที่เอามาเทรนให้ถูกต้อง, ทำ data pipeline (ท่อลำเลียงข้อมูล) ให้ปลอดภัย
2. โปร่งใสและรับผิดชอบแบบสุดทาง (Embrace radical transparency and accountability)	“กล้าเปิดเผยว่าระบบเราทำงานยังไง พังตรงไหน” — ไม่ปิดบัง ไม่ขายผ้าเอาหน้ารอด	ทำให้ AI อธิบายได้ (explainability) และ โปร่งใส — ตอบได้ว่าทำไมโมเดลถึงตัดสินใจแบบนี้
3. สร้างโครงสร้างองค์กรและภาวะผู้นำเพื่อบรรลุเป้าความปลอดภัย (Build organizational structures and leadership to achieve security goals)	“ความปลอดภัยต้องมีเจ้าภาพระดับผู้นำ ไม่ใช่ปล่อยให้ฝ่าย IT แบกคนเดียว”	วาง AI governance และ oversight ให้มีคนระดับบริหารดูแลจริงจัง

มุมผู้บริหาร: สังเกตไหมครับว่าทั้ง 3 ข้อไม่มีข้อไหนเป็นเรื่องเทคนิคล้วนๆ เลย — มันเป็นเรื่อง “ใครรับผิดชอบ” “เปิดเผยแค่ไหน” “ใครเป็นเจ้าภาพ”. นี่คือเหตุผลที่ secure-by-design เป็นเรื่องของผู้บริหารโดยตรง ไม่ใช่เรื่องของช่าง. ถ้าคุณเป็น Customer (ซื้อ AI มาใช้) — ข้อ 1-2 คือสิ่งที่คุณควร เรียกร้องจาก vendor (“คุณรับผิดชอบความปลอดภัยให้เราแค่ไหน?” “คุณอธิบายได้ไหมว่าโมเดลทำงานยังไง?”). ส่วนข้อ 3 คือสิ่งที่ คุณต้องทำเองในบ้านคุณ — vendor ทำให้ไม่ได้.

จุดสำคัญที่คู่มือย้ำ แล้วผมก็เห็นด้วยมากคือ DevSecOps และ secure development life cycle ไม่ได้เปลี่ยนรูปแบบเพราะมี AI โครงเดิมยังใช้ได้. แต่สิ่งที่ต้องทำคือ เอา “ความปลอดภัยของ AI” ไปฝังเข้าไปในทุกขั้นตอนของโครงเดิมนั้น. แล้วมันก็ครอบคลุม 2 มุมพร้อมกัน:

ใช้ AI มาช่วยงานพัฒนา (เช่น ใช้ AI ช่วยเขียนโค้ด ช่วยตรวจโค้ด)
พัฒนาตัว AI เอง (เช่น สร้างโมเดลใหม่ หรือเอาโมเดลมาปรับจูน)

ทั้งสองมุมต้องการให้โครงสร้างพื้นฐาน “ถูกสร้างมาเพื่อ AI secure-by-design” ตั้งแต่ต้น — และต้องมี กระบวนการเฉพาะ สำหรับการออกแบบและพัฒนา AI อย่างมีความรับผิดชอบ ที่ถูกเขียนเป็นลายลักษณ์อักษร สื่อสารให้ทุกคนรู้ และทบทวนเป็นระยะ.

3. DevSecOps Continuum — ฝัง AI (และความปลอดภัย) เข้าไปทุกขั้นตอน#

ทีนี้มาดูภาพใหญ่ว่า “ฝังความปลอดภัยเข้าไปทุกขั้นตอน” หน้าตาเป็นยังไง.

DevSecOps มองวงจรการทำงานเป็น “ลูปไม่รู้จบ” (infinity loop) ที่หมุนวนระหว่างฝั่ง Dev (พัฒนา) กับ Ops (ดูแลระบบ) ไม่ใช่เส้นตรงที่ทำเสร็จแล้วจบ. แล้วมันก็แบ่งเป็น 8 ช่วงงานหลักที่หมุนวนกันไป. คู่มือยกงานวิจัยที่อธิบายว่า AI สามารถเข้าไปแทรกได้ทุกช่วง ของลูปนี้.

ขอวาดภาพลูปให้เห็นก่อน แล้วค่อยอธิบายแต่ละช่วงนะครับ:

1
            ╔═══════════ DEV (พัฒนา) ═══════════╗ ╔══════════ OPS (ดูแล) ══════════╗
2
            ║                                    ║ ║                                 ║
3
   Plan ──► Code ──► Build ──► Test ──► Release ─╫─► Deploy ──► Operate ──► Monitor ─╫─┐
4
     ▲                                            ║ ║                                 ║ │
5
     └────────────────────────────────────────────────────────────────────────────────┘
6
                          (หมุนวนไม่รู้จบ — feedback กลับเข้า Plan ใหม่)
7

8
   ◄─── "ความปลอดภัยถูกฝังในทุกการกระทำ" ───►   ◄─ "AIOps คอยจับ pattern + ทำนายล่วงหน้า" ─►

8 ช่วงงานในลูป — และตัวอย่างที่ AI เข้าไปช่วยในแต่ละช่วง (ผมเลือกมาเฉพาะตัวที่เจ้าของกิจการน่าจะเห็นภาพ ไม่ได้เอามาครบทุกบรรทัด):

ช่วง	ทำอะไร	AI เข้าไปช่วยยังไง (ตัวอย่าง)
Plan (วางแผน)	เก็บ requirement, วางขอบเขตงาน	AI อ่าน requirement ที่เขียนเป็นภาษาคน แล้วจับจุดที่ “กำกวม/ขัดกันเอง”, ช่วยร่าง user story, ช่วยระบุภัยตั้งแต่วางแผน (threat modeling)
Code (เขียนโค้ด)	เขียนโปรแกรม	AI ช่วยเขียนโค้ดคู่กับคน (pair programming), เตือนช่องโหว่ตอนพิมพ์, ช่วยรีวิวโค้ด, แนะนำการปรับโครงสร้างโค้ด
Build (ประกอบ)	รวมโค้ดเป็นตัวรัน	AI วิเคราะห์ผลกระทบของการ merge, จับช่องโหว่ความปลอดภัย, ทำ software composition analysis (ตรวจ component ของคนอื่นที่เราเอามาใช้)
Test (ทดสอบ)	ทดสอบว่าใช้งานได้	AI สร้าง test case จากภาษาคน, สร้างข้อมูลทดสอบ, ทำนายว่าเทสต์ไหนคุ้มที่จะรัน, เทสต์ที่ “ซ่อมตัวเองได้”
Release (ปล่อยรุ่น)	เตรียมส่งออกสู่ production	AI ตรวจ compliance, สร้างสคริปต์ deploy, ทำนายความเสี่ยง/โอกาสสำเร็จของการปล่อยรุ่น
Deploy (นำขึ้นใช้จริง)	เอาขึ้นระบบจริง	AI จัดสภาพแวดล้อมอัตโนมัติ, rollback แบบ real-time, จับความผิดปกติด้วย ML
Operate (เดินเครื่อง)	ดูแลให้ระบบทำงานทุกวัน	AI จัดคิว support ticket, ตัดสินใจ “ซ่อมตัวเอง”, ผู้ช่วยเสมือนตอบคำถาม, knowledge base ที่ขับด้วย GenAI
Monitor (เฝ้าดู)	เฝ้าระวังปัญหา	AI เชื่อมโยง event, กรอง false alarm (สัญญาณเตือนหลอก), หาสาเหตุรากของปัญหา (root cause)

สองข้อความสำคัญที่อยู่ “ตรงกลางลูป” และผมอยากให้เจ้าของกิจการจำ:

ฝั่ง Dev — “Security is infused into all actions” (ความปลอดภัยถูกฝังในทุกการกระทำ). ไม่ใช่มีขั้นตอน “ตรวจความปลอดภัย” แยกออกมาอันเดียวตอนท้าย — แต่ทุกช่วงมีความปลอดภัยแทรกอยู่
ฝั่ง Ops — “AIOps engines provide correlation and predictive monitoring” (เครื่องยนต์ AIOps ช่วยเชื่อมโยงและทำนายล่วงหน้า). คือใช้ AI มาเฝ้าดูระบบ แล้วทำนายปัญหาก่อนมันเกิด

มุมผู้บริหาร: ตารางข้างบนดูเหมือนเรื่องของทีมเทคนิคล้วนๆ — แต่มันมี 2 นัยที่ผู้บริหารต้องเห็น. นัยที่ 1: AI ตอนนี้ไม่ได้อยู่แค่ “ปลายทาง” (ตัวสินค้าที่ลูกค้าใช้) แต่มันแทรกอยู่ในเครื่องมือที่ทีมเราใช้พัฒนาด้วย — แปลว่าถ้าทีมเอา AI ช่วยเขียนโค้ด คุณก็มี “AI customer” เพิ่มขึ้นในบ้านโดยอาจไม่รู้ตัว และต้องวาง control เรื่องนี้ด้วย (เช่น โค้ดที่ AI generate มาเอาไปใช้ได้เลยไหม ลิขสิทธิ์เป็นยังไง). นัยที่ 2: “ทุกช่วงมีความปลอดภัยฝังอยู่” แปลว่าคุณไม่ควรอนุมัติงบความปลอดภัยเป็นก้อนเดียวตอนท้ายโปรเจกต์ — มันต้องกระจายอยู่ในทุกเฟส. ถ้าทีมเสนอแผนที่ “ความปลอดภัยอยู่เฟสสุดท้ายเฟสเดียว” — นั่นคือสัญญาณว่ายังคิดแบบ “แปะทีหลัง” อยู่

🚩 Trap pattern: “เราใช้ DevSecOps อยู่แล้ว เลยไม่ต้องทำอะไรเพิ่มกับ AI”#

นี่คือกับดักที่ผมเจอบ่อย. หลายองค์กรที่มี DevSecOps อยู่แล้วคิดว่า “เรามี pipeline ความปลอดภัยพร้อม เอา AI มาเสียบได้เลย.” ผิดครับ. ที่คู่มือบอกคือ “โครง DevSecOps ไม่เปลี่ยน” แต่คุณต้อง เอาความปลอดภัยเฉพาะของ AI ไปฝังเพิ่ม ในโครงนั้น เช่น การจัดการ consent ของข้อมูลเทรน การตรวจ data poisoning การทำ AI red teaming. โครงเดิมมันรองรับซอฟต์แวร์ธรรมดา แต่ AI มีความเสี่ยงเฉพาะตัวที่ pipeline เดิมมองไม่เห็น.

4. Data Dependency — พนักงานคนนี้ “ติดข้อมูล” หนักกว่าที่คุณคิด#

มาถึงเรื่องที่ผมว่าเป็น “หัวใจที่ซ่อนอยู่” ของสถาปัตยกรรม AI แล้วก็เป็นจุดที่ทำให้ AI ต่างจากซอฟต์แวร์ธรรมดาอย่างสิ้นเชิง.

4.1 ทำไม AI ถึง “ติดข้อมูล” แบบถอนตัวไม่ได้#

ซอฟต์แวร์ธรรมดา — คุณเขียนกฎไว้ในโค้ด เช่น “ถ้ายอดเกิน 10,000 ให้แจ้งเตือน”. กฎนี้ตายตัว. ข้อมูลที่ไหลผ่านเปลี่ยน แต่ตัวกฎไม่เปลี่ยน.

AI ไม่ใช่แบบนั้น. คู่มือใช้คำว่า AI มี “fundamental dependency on data” คือ AI พึ่งพาข้อมูลในระดับรากฐาน ทั้งเพื่อสร้างความสามารถหลักของมัน และเพื่อสร้าง “คำสั่ง” ที่มันใช้ตัดสินใจ. พูดง่ายๆ ก็คือ ตัวพนักงานคนนี้ “เป็น” สิ่งที่ข้อมูลสอนเขามา. ความสามารถของเขาไม่ได้มาจากกฎที่โปรแกรมเมอร์เขียน แต่มาจากรูปแบบ (pattern) ที่เขาเรียนรู้จากข้อมูลตอนเทรน.

ผลที่ตามมาคือสิ่งที่คู่มือเรียกว่า AI “sensitive ต่อการเปลี่ยนแปลงของข้อมูล” อย่างมาก — ใน 2 ด้าน:

การเปลี่ยนแปลงของข้อมูลที่ใช้เทรน (ฐานความรู้ของเขา)
การเปลี่ยนแปลงของแหล่งข้อมูลและการเตรียมข้อมูล (data sources & preprocessing) ที่ป้อนเข้าไปตอนใช้งานจริง

ลองนึกภาพแบบนี้ครับ. สมมติว่าโรงงานแห่งหนึ่งจ้างพนักงานควบคุมคุณภาพมือทอง. เขาเก่งเพราะฝึกมา 10 ปีกับชิ้นงานแบบหนึ่ง จำได้แม่นว่าชิ้นดีหน้าตายังไง ชิ้นเสียหน้าตายังไง. วันดีคืนดี โรงงานเปลี่ยนวัตถุดิบ เปลี่ยนสีพลาสติก เปลี่ยนขนาดชิ้นงานนิดหน่อย สำหรับคนทั่วไปแทบไม่ต่าง แต่พนักงานมือทองคนนี้เริ่มตัดสินผิด เพราะ “หน้าตาที่เขาคุ้น” มันเปลี่ยนไป. เขาไม่ได้โง่ลงนะ แต่โลกที่เขาเรียนมามันเปลี่ยน.

นี่แหละครับ data dependency — AI ถูกเทรนด้วยข้อมูลที่มี “หน้าตา” เฉพาะ (โครงสร้าง คุณภาพ ความเกี่ยวข้องแบบหนึ่ง). พอข้อมูลที่ป้อนเข้าไปตอนใช้งานจริง หน้าตาเปลี่ยนไป แม้แค่นิดเดียว ผลลัพธ์ก็เพี้ยนได้เลย.

4.2 แล้วผู้บริหารต้องวาง control อะไร?#

คู่มือชี้ทางไว้ชัด ขอเรียบเรียงเป็น checklist ของผมเองนะครับ:

สิ่งที่ต้องทำ	ทำไมสำคัญ (มุมผู้บริหาร)
เขียนเอกสาร “ข้อมูลขาเข้าที่โมเดลต้องการ” (data input requirements)	โมเดล “คาดหวัง” ข้อมูลหน้าตาแบบหนึ่ง — ถ้าไม่จดไว้ ก็ไม่มีทางรู้ว่าวันหนึ่งข้อมูลจริง “หลุดกรอบ”
เทียบข้อมูลจริงในการใช้งาน กับข้อมูลที่โมเดลคาดหวัง	ถ้าหน้าตาเริ่มเพี้ยน ต้องจับได้ — ไม่งั้นผลลัพธ์เพี้ยนเงียบๆ โดยไม่มี error เด้ง
เพิ่มขั้น preprocessing (ปรับ-ทำให้เป็นมาตรฐาน) ถ้าข้อมูลเปลี่ยน	ดึงข้อมูลใหม่ให้กลับเข้า “กรอบที่โมเดลรับได้” ก่อนป้อน
เฝ้าระวังความเสี่ยงจาก AI supply chain	ข้อมูลที่ “โดนวางยา” (poisoned), ข้อมูลที่ถูกแก้, หรือการพึ่งพาโมเดลของบุคคลที่สาม — ต้องจัดการให้ disruption “เอาอยู่”

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

4.3 มุมที่เจ้าของกิจการมองข้าม: ข้อมูลขาเข้าไม่ได้อยู่ในมือเราเสมอ#

จุดที่คู่มือแอบเตือน แล้วผมอยากขยายต่อก็คือ การเปลี่ยนแปลงของข้อมูล มันมักไม่ได้เริ่มจากเรา แล้วก็ไม่ได้อยู่ใต้การควบคุมของเราด้วย.

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

นี่แหละคือเหตุผลที่การเฝ้าข้อมูลขาเข้าไม่ใช่งาน “ตั้งค่าครั้งเดียวจบ” มันคืองานที่ต้องมีคน (หรือเครื่องมือ) เฝ้าตลอดเวลา เพราะตัวกระตุ้นมันมาจากข้างนอกบ้านเราเอง.

5. Data Storage — ข้อมูลที่ AI “ผลิต” ทุกวัน มันไปกองอยู่ตรงไหน?#

เรื่องสุดท้ายของตอนนี้ แล้วก็เป็นเรื่องที่ผมว่าเจ้าของกิจการ “ลืม” บ่อยที่สุด.

5.1 ปัญหาไม่ใช่ “เก็บได้ไหม” แต่คือ “เก็บแล้วลืม”#

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

ข้อมูลปริมาณมหาศาลที่ AI ผลิตออกมา มักเป็นสิ่งที่เรา “ไม่ได้คาดคิด” ว่าจะมี — แล้วมันเปิดความเสี่ยงเรื่องข้อมูลรั่ว (data leakage) และการนำไปใช้ผิด (misuse)

ลองคิดดูครับ. พนักงาน AI คนนี้ นอกจากเขาจะ “กิน” ข้อมูล (input + ข้อมูลเทรนที่อาจต้องเก็บไว้) เขายัง “ถ่าย” ข้อมูลออกมา ตลอดเวลาด้วย (output ทุกชิ้น, log ทุกการตัดสินใจ, ผลพลอยได้ระหว่างทาง). แล้วของที่เขาถ่ายออกมานี่แหละ มันกองอยู่ที่ไหนสักที่ในระบบเรา โดยที่เราอาจไม่เคยตั้งใจให้มันอยู่ตรงนั้น.

หน้าที่ที่คู่มือมอบให้ ในฐานะคนวางสถาปัตยกรรม คือต้อง ระบุให้ชัดว่า input และ output ของ AI จะถูกเก็บ “ที่ไหน” และ “อย่างไร” ตั้งแต่ตอนออกแบบ (เห็นไหมครับ กลับมาที่ secure-by-design อีกแล้ว คือคิดเรื่องที่เก็บข้อมูลตั้งแต่เขียนแบบแปลน ไม่ใช่รอตอนมันล้นแล้ว).

5.2 ความเสี่ยง 3 ตัวที่ตามมาจากเรื่องนี้#

คู่มือชี้ความเสี่ยง 3 ตัวที่ผูกกับเรื่อง data storage ผมขอกางให้เห็นภาพ:

ความเสี่ยง	คืออะไร (ภาษาคน)	ตัวอย่างที่เห็นภาพ
Shadow IT (ไอทีเงา)	ระบบ/ที่เก็บข้อมูลที่เกิดขึ้น “นอกสายตา” ฝ่าย IT — ไม่มีใครอนุมัติ ไม่มีใครคุม	พนักงานเอา output ของ AI ไปเซฟไว้ใน cloud drive ส่วนตัว เพื่อความสะดวก — ข้อมูลบริษัทหลุดออกนอกระบบโดยไม่มีใครรู้
Drift (การเลื่อนไหล)	ข้อมูล/ค่าตั้งค่า ค่อยๆ เคลื่อนออกจาก “มาตรฐาน” ที่ตั้งไว้ จนระบบเพี้ยนแบบเงียบๆ	ข้อมูลที่ AI ผลิตสะสมไปเรื่อยๆ จนสภาพแวดล้อมข้อมูล “ไม่เหมือนวันแรก” แล้ว
Access control (การคุมสิทธิ์เข้าถึง)	ใครมีสิทธิ์แตะข้อมูลที่ AI ผลิต — ถ้าคุมไม่ดี คนที่ไม่ควรเห็นก็เห็น	output ของ AI อาจมีข้อมูลอ่อนไหวปนอยู่ (เพราะ AI สังเคราะห์มาจากข้อมูลหลายแหล่ง) แต่ถูกเก็บในที่ที่ใครก็เข้าถึงได้

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

🚩 Trap pattern: “ข้อมูลที่ AI สร้าง = ข้อมูลใหม่ที่ไม่มีเจ้าของ ไม่ต้องคุม”#

ผิดเต็มประตูครับ. ข้อมูลที่ AI ผลิต ก็คือข้อมูลขององค์กร เหมือนข้อมูลอื่นทุกประการ ต้องถูกจัดชั้นความลับ ต้องมีคนคุมสิทธิ์ ต้องอยู่ในตารางเก็บ-ทำลายข้อมูล. ความเข้าใจผิดว่า “มันเป็นแค่ output ของเครื่อง ไม่ใช่ข้อมูลจริง” นี่แหละคือต้นทางของข้อมูลรั่วครั้งใหญ่. ที่อันตรายกว่านั้นคือ output ของ AI อาจ สังเคราะห์ข้อมูลอ่อนไหวขึ้นมาใหม่ จากการต่อจิ๊กซอว์ข้อมูลหลายชิ้น (เช่น เดาข้อมูลส่วนตัวลูกค้าจากพฤติกรรมการซื้อ) กลายเป็นข้อมูลที่อ่อนไหวกว่าข้อมูลตั้งต้นด้วยซ้ำ.

6. ทำไม “ฝังตั้งแต่ออกแบบ” ถึงสำคัญกับ AI มากกว่าซอฟต์แวร์ธรรมดา — เรื่อง emergency change#

ก่อนปิดตอน ผมขอเชื่อมทุกอย่างเข้าด้วยกันด้วยเหตุผลที่ทำให้ secure-by-design สำคัญกับ AI เป็นพิเศษ.

ในซอฟต์แวร์ธรรมดา เจอบั๊กหรือช่องโหว่ โปรแกรมเมอร์เขียน patch แก้เฉพาะจุดได้ ใช้เวลา “ชั่วโมงถึงไม่กี่วัน” เร็ว ตรงจุด.

แต่ AI แก้แบบนั้นไม่ได้. การเทรนโมเดลใหม่ใช้เวลา “ชั่วโมงถึงเป็นสัปดาห์” ซึ่งมันไม่เข้ากับความคาดหวังของโลกความปลอดภัยที่ “บั๊กวิกฤตต้องแก้ใน 1-2 วัน” เลย. พอ AI มีปัญหาด่วน เราเลยทำได้แค่ทางเลือกอ้อมๆ เช่น:

Rollback ไปโมเดลรุ่นเก่า ถ้าปัญหาเพิ่งโผล่หลังเปลี่ยนโมเดล อาจถอยกลับรุ่นก่อนได้ (แต่ต้องมั่นใจว่าปัญหานี้ไม่ได้ฝังอยู่ในข้อมูลเทรนของรุ่นเก่าด้วย)
เพิ่มด่านกรอง input/output แก้ตัวโมเดลไม่ทันก็ไปเพิ่มซอฟต์แวร์ “นอกตัวโมเดล” มากรองสิ่งที่เข้าและออก เพื่อกันของเสียก่อนถึงโมเดล และกันของเสียก่อนออกจากโมเดล

มุมผู้บริหาร: นี่คือเหตุผลที่ลึกที่สุดว่าทำไม secure-by-design ถึงสำคัญกับ AI มากกว่าซอฟต์แวร์ธรรมดา — เพราะ AI “แก้ทีหลัง” ได้ช้าและแพงกว่ามาก. กับซอฟต์แวร์ธรรมดา เราอาจ “ปล่อยก่อน แล้วค่อยแก้” ได้บ้าง. กับ AI การ “ปล่อยก่อนแล้วค่อยแก้” อาจหมายถึงระบบตอบผิดให้ลูกค้าเป็นสัปดาห์ระหว่างรอเทรนใหม่. ดังนั้นเงินและเวลาที่ลงไปกับการ “ออกแบบให้ถูกตั้งแต่ต้น” — มันคุ้มกว่าเสมอ. และข้อสุดท้าย — การแก้ฉุกเฉินทุกครั้งต้องผ่านการอนุมัติของผู้มีส่วนได้เสีย เหมือนกระบวนการ change management ปกติขององค์กร ไม่ใช่ปล่อยให้ทีมเทคนิคแอบ rollback เงียบๆ คนเดียว.

สรุปตอนที่ 25 — ปุ่มแรกของเสื้อ#

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

4 ข้อคิดที่อยากให้ติดไม้ติดมือจากตอนนี้:

รู้ก่อนว่าเราเป็นใคร Provider / Producer / Customer. เจ้าของกิจการส่วนใหญ่เป็น Customer (ซื้อมาใช้) แต่ระวังตอนที่เราข้ามเส้นไปเป็น Producer (เริ่ม fine-tune) โดยไม่รู้ตัว เพราะ control เปลี่ยนทั้งชุด
ความปลอดภัยต้อง “ฝัง” ไม่ใช่ “แปะ” secure-by-design คือการคิดเรื่องความปลอดภัยตั้งแต่เขียนแบบแปลน แล้วฝังเข้าไปทุกขั้นของ DevSecOps ไม่ใช่เฟสสุดท้ายเฟสเดียว
AI “ติดข้อมูล” ในระดับราก มันตอบผิดได้เงียบๆ เมื่อข้อมูลขาเข้าค่อยๆ เปลี่ยนไป (data dependency) ดังนั้น control ที่สำคัญคือ “เฝ้าเทียบข้อมูลขาเข้าต่อเนื่อง” ไม่ใช่ตรวจครั้งเดียวตอนติดตั้ง
อย่าลืมข้อมูลที่ AI “ถ่าย” ออกมา output ทุกชิ้นคือข้อมูลองค์กรที่ต้องจัดชั้นความลับ คุมสิทธิ์ แล้วก็มีที่อยู่ชัดเจน ไม่งั้นกลายเป็น shadow IT และข้อมูลรั่ว

และเหนือสิ่งอื่นใด AI แก้ทีหลังช้าและแพงกว่าซอฟต์แวร์ธรรมดามาก นั่นแหละคือเหตุผลที่ “ออกแบบให้ถูกตั้งแต่ต้น” มันคุ้มเสมอ.

เกริ่นตอนหน้า — จากฐานราก สู่ “ชีวิตของพนักงาน AI”#

ตอนนี้เราวางฐานรากของบ้าน AI เสร็จแล้ว รู้ว่าเราเป็นใคร วางความปลอดภัยให้ฝังตั้งแต่ออกแบบ เข้าใจว่า AI ติดข้อมูลแค่ไหน แล้วก็ข้อมูลที่มันผลิตไปอยู่ที่ไหน.

ตอนหน้า เราจะเดินตาม “ชีวิตของพนักงาน AI” ตั้งแต่วันแรกถึงวันเกษียณ — ที่เรียกกันว่า AI Life Cycle (วงจรชีวิต AI): ตั้งแต่ตอนวางแผน-ออกแบบ, เก็บข้อมูลมาเทรน, สร้าง/ปรับโมเดล, ทดสอบ (รวมถึงเรื่องสนุกๆ อย่าง AI red teaming — การจ้างคนมาลองโจมตี AI ของเราเองเพื่อหาจุดอ่อน), ปล่อยใช้จริง, เฝ้าดู ไปจนถึงวัน “ปลดระวาง”. แต่ละช่วงมีความเสี่ยงและ control เฉพาะของมัน — และมุมผู้บริหารคือ “เราต้องคุมอะไรในแต่ละช่วง”

เพราะการคุมพนักงานเก่งๆ คนหนึ่ง ไม่ได้จบแค่วันที่เซ็นสัญญาจ้าง — มันคือการดูแลกันไปตลอดเส้นทาง 🙂

แล้วเจอกันตอนหน้าครับ

อ้างอิงแนวคิด: AAISM — Domain 3: Section 3.2 (AI Security Architecture and Design) — รวม 3.2.1 Architecture Considerations / Secure by Design + DevSecOps continuum, 3.2.2 Data Dependency, 3.2.3 Data Storage และบทบาท AI provider/producer/customer. กรอบแนวคิดสาธารณะที่อ้างถึง: หลัก Secure-by-Design (แนวทาง CISA), แนวคิด DevSecOps continuum, NIST AI RMF 1.0, OWASP Top 10 for LLM Applications, MITRE ATLAS. ตัวอย่างทั้งหมดในบทเป็นกรณีสมมติเพื่อประกอบความเข้าใจเท่านั้น