0. ภาพใหญ่ก่อน — “ตู้ control” ของ Domain 3 มีอะไรบ้าง#

คู่มือ AAISM เปิด Domain 3 ด้วยการ โยนกล่องเครื่องมือทั้งตู้ออกมาวางตรงหน้า — เป็นตารางยาวเหยียดของ control หลายสิบตัว แบ่งเป็นหมวดใหญ่ๆ เช่น Technical/Security/Privacy, Operation & Life Cycle, SDLC, และ Ethical/Human Values.

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

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

คู่มือยังบอกอีกว่า — เราไม่ต้องคิด control พวกนี้ขึ้นมาเองจากศูนย์. มี กรอบสาธารณะ (public frameworks) ที่เขาคิดมาให้แล้ว หยิบมาใช้ได้เลย เช่น NIST AI Risk Management Framework, Cloud Security Alliance AI Controls Matrix, MITRE ATLAS, OWASP Top 10 for LLM Applications, ไปจนถึงเฟรมเวิร์กของเจ้าใหญ่ๆ อย่าง Google (Secure AI Framework) และ IBM. ผมเคยพูดถึงพวกนี้ใน Domain 2 — ในตอนนี้เราจะ “หยิบของจริง” จากกรอบพวกนี้มาใช้

เอาล่ะครับ เปิดตู้ control กันเลย — เริ่มที่ตัวพื้นฐานที่สุดและสำคัญที่สุด

1. Access Control — “ใครให้พนักงาน AI แตะข้อมูลอะไรได้บ้าง”#

ลองนึกภาพแบบนี้ครับ. สมมติว่าคุณเป็นเจ้าของบริษัทแห่งหนึ่ง แล้วจ้าง “พนักงานใหม่เทพๆ” (AI) เข้ามาช่วยวิเคราะห์ข้อมูล. คำถามแรกสุดที่ HR กับฝ่ายไอทีจะถามคือ — “จะให้เขาถือกุญแจห้องไหนบ้าง?”

นี่แหละครับคือหัวใจของ Access Control (การควบคุมการเข้าถึง). ในระบบไอทีปกติ เรื่องนี้ค่อนข้างตรงไปตรงมา — ใครมีสิทธิ์เปิดไฟล์ไหน เข้าระบบไหนได้. แต่พอเป็น AI มันมี มุมแปลกที่ผู้บริหารต้องรู้ ซึ่งคู่มือ AAISM ชี้ไว้ชัดมาก

2. Zero Trust สำหรับ AI — “ไม่เชื่อแบบหลับหูหลับตา” (สองชั้น)#

มาถึงหัวใจของตอนนี้ครับ — Zero Trust (ความไม่ไว้ใจเป็นค่าเริ่มต้น).

อย่างที่บอกในกล่อง bridge ด้านบน — แนวคิด Zero Trust พื้นฐานในโลกไซเบอร์ปกติค่อนข้างชัด: “never trust, always verify” — อย่าเชื่อว่าใครปลอดภัยจนกว่าจะพิสูจน์ตัว ต่อให้เขาอยู่ “ในออฟฟิศ” แล้วก็ตาม (ผมเล่าละเอียดไว้ใน CyberSec EP.17). พอเอามาใช้กับ AI — มันมีมุมที่ แปลกและลึกกว่าระบบปกติ ซึ่งคู่มือ AAISM แยกไว้สวยมาก เป็น 2 ชั้น ที่ผู้บริหารต้องแยกให้ออก:

1
   Zero Trust สำหรับ AI = 2 ชั้น
2

3
   ชั้นที่ 1 ────────────────────────────────────
4
   "ไม่เชื่อว่า ใครที่เข้ามา คือคนจริง / ปลอดภัย"
5
   (Zero Trust แบบไอทีดั้งเดิม — ยกมาใช้กับ AI)
6
        → คุมการเข้าถึง "ตัวโมเดล + ข้อมูล"
7

8
   ชั้นที่ 2 ────────────────────────────────────
9
   "ไม่เชื่อว่า คำตอบของ AI ถูกต้อง เสมอไป"
10
   (อันนี้ใหม่ — เฉพาะกับ AI)
11
        → ตั้งคำถามกับ "ผลลัพธ์" ของโมเดลเอง

ผมจะเล่าทีละชั้น

1
   เข้มสุด  │ 1. Deny access — ไม่ให้ AI ต่อเน็ตเลย (ถ้าทำได้)
2
            │ 2. Implement access controls — ถ้าต้องต่อ ใช้นโยบายเดิมขององค์กรคุม
3
            │ 3. Block restricted websites — บล็อกเว็บอันตราย (URL/spam filter)
4
            │ 4. Control access to data — จำกัดให้แตะเฉพาะข้อมูลตาม use case ที่อนุมัติ
5
   ผ่อนสุด  │ 5. Ensure data validation — ตรวจข้อมูลที่ LLM ใช้ว่าถูก/ไม่เป็นพิษ

3. AI Acceptable Use Policy (AUP) — “กฎกติกาใช้พนักงานคนนี้”#

control สามตัวต่อไปสั้นกว่า แต่สำคัญไม่แพ้กัน. เริ่มที่ AI Acceptable Use Policy หรือ AUP — นโยบายการใช้งานที่ยอมรับได้

ในมุมง่ายๆ — AUP คือ “คู่มือพนักงาน” สำหรับการใช้ AI ในองค์กร. มันคือเอกสารที่บอก “ใช้ AI ทำอะไรได้ / ทำอะไรไม่ได้” อย่างชัดเจน. คู่มือ AAISM บอกว่า AUP เป็น control ที่ “จำเป็นต้องมี” (required) — ไม่ใช่ทางเลือก — สำหรับองค์กรที่จะใช้ AI อย่างมีความรับผิดชอบ

ลักษณะสำคัญที่คู่มือชี้:

• AUP เป็นเรื่องของ “อะไร” และ “ทำไม” (the what and why) — เป็นภาพใหญ่ที่บอก เจตนา ขององค์กร ไม่ใช่คู่มือเทคนิคทีละขั้น
• มันสะท้อน เป้าหมาย วัตถุประสงค์ และวัฒนธรรม ขององค์กร
• เหมือน AUP ทั่วไป — มันบอก กิจกรรมที่ “ต้องทำ” และ “ห้ามทำ” ชัดเจน
• มันต้อง สมดุลระหว่างประโยชน์ของ AI กับความเสี่ยง — ไม่ใช่ห้ามหมด และไม่ใช่ปล่อยเสรี

ผมเคยเล่า AUP แบบละเอียดไปแล้วตอน Domain 1 (ตอนที่ 7) — ในมุม Domain 3 นี้ ประเด็นคือ AUP กลายเป็น “control ตัวหนึ่ง” ในตู้เครื่องมือ ไม่ใช่แค่เอกสารนโยบายลอยๆ. มันคือ control ที่จัดการ “ความเสี่ยงด้านคน” — เพราะ control ทางเทคนิคทั้งหลาย (DLP, segmentation) จะอ่อนแรงทันที ถ้าคนในองค์กรไม่รู้ว่า “อะไรทำได้/ไม่ได้”

มุมผู้บริหาร: AUP ที่ดีไม่ใช่เอกสาร 40 หน้าที่ไม่มีใครอ่าน. มันคือ “เส้นแบ่งที่พนักงานจำได้” — เช่น “ห้ามแปะข้อมูลลูกค้าลงใน AI สาธารณะ”, “ใช้ AI ร่างได้ แต่คนต้องตรวจก่อนส่งออก”, “ห้ามใช้ AI ตัดสินใจเรื่อง [X] โดยไม่มีคนอนุมัติ”. ถ้าพนักงานท่องเส้นแบ่งพวกนี้ไม่ได้ — AUP ของคุณยาวเกินไป. และข้อสำคัญที่สุด: AUP ที่เขียนแล้วไม่บังคับใช้/ไม่อบรม = กระดาษเปล่า (เรื่องการอบรมจะโยงไปหัวข้อ AI Security Awareness ตอนหน้า)

4. AI Audits & Traceability — “ย้อนรอยได้ไหมว่าเขาตัดสินจากอะไร”#

ทีนี้มาถึงปัญหาคลาสสิกของ AI — “กล่องดำ” (black box).

ลองนึกภาพพนักงานเทพคนนี้อีกครั้งครับ. เขาเก่งมาก ตัดสินใจเร็วมาก. แต่พอคุณถามเขาว่า “ทำไมถึงตัดสินแบบนี้?” — เขาตอบว่า ”…ก็รู้สึกว่ามันถูก”. นั่นแหละครับปัญหา. AI หลายตัว โดยเฉพาะโมเดลของเจ้าใหญ่ (proprietary models) เป็น กล่องดำ — เห็นแค่ “input เข้า → output ออก” แต่ไม่เห็นว่า “ข้างในมันคิดยังไง”

control ที่มาแก้เรื่องนี้มี 2 คำที่ต้องแยกให้ออก:

5. Supply Chain Controls — “คุมพนักงานที่เราเช่ามา”#

หัวข้อนี้ผมเล่ายาวไปแล้วตอนปิด Domain 2 (ตอนที่ 23 — เรื่อง First→Nth party supply chain) — ในมุม Domain 3 มันกลับมาในฐานะ “control ที่ต้องลงมือทำ” ผมจะเล่าเฉพาะมุมที่ Domain 3 เน้น

ความจริงที่คู่มือตอกย้ำ: องค์กรส่วนใหญ่ “ไม่ได้สร้างโมเดล AI เอง” — เราพึ่ง vendor. แปลว่าพนักงานเทพคนนี้ จริงๆ แล้ว “เราเช่ามา” ไม่ใช่ “ลูกเราเอง”. การพึ่ง vendor บังคับให้เราต้อง ขยายการตรวจสอบ (due diligence) และการเฝ้าระวัง (monitoring) ให้ครอบคลุมมุมเฉพาะของ AI

นอกจากคำถามตรวจสอบ vendor ทั่วไป (ที่ใช้กับ supplier ทุกประเภท) คู่มือบอกว่าสำหรับ AI ต้องถามเพิ่ม:

control ที่คู่มือเน้นเพิ่ม 2 อย่าง:

1. ดึง critical third parties เข้า AI audit program — vendor ที่สำคัญจริงๆ (เช่น คนเทรนโมเดล, ผู้ให้บริการ API) ต้อง อยู่ในขอบเขตการตรวจสอบของเรา ไม่ใช่ปล่อยให้เขาตรวจตัวเอง
2. Supplier risk management assessment — ประเมินว่า “บริการของ supplier รายนี้กระทบธุรกิจเรายังไง” + ใช้ continuous monitoring ครอบคลุมโมเดล AI ของ third-party ที่เราใช้ด้วย

มุมผู้บริหาร: หลักการเดิมจาก Domain 2 ที่ผมย้ำตลอด — การจ้าง vendor ไม่ได้ “โอน” ความรับผิดออกจากเรา. ถ้าโมเดลที่เราเช่ามาทำพัง ลูกค้าฟ้อง — เขาฟ้อง “เรา” ไม่ใช่ฟ้อง vendor. ดังนั้น supply chain control ไม่ใช่ “งานเอกสารกับฝ่ายจัดซื้อ” — มันคือ การยืดแขนของ governance เราออกไปคลุมพนักงานที่เราเช่ามา เพราะสุดท้ายเรารับผิดในงานเขา

6. Shadow AI — “พนักงานในออฟฟิศแอบจ้าง AI ผีนอกระบบ”#

มาถึงเรื่องที่ผมว่า น่ากลัวเงียบๆ ที่สุด ในตอนนี้ — Shadow AI

คุณคงเคยได้ยินคำว่า Shadow IT — การที่พนักงานแอบใช้ซอฟต์แวร์/บริการที่ฝ่ายไอทีไม่ได้อนุมัติ (เช่น แอบใช้ Dropbox ส่วนตัวเก็บไฟล์งาน). Shadow AI คือเวอร์ชัน AI ของมัน — การที่พนักงานแอบใช้แอป AI ที่องค์กรไม่ได้อนุมัติ

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

คู่มือเตือนชัดว่า Shadow AI นำมาซึ่ง:

• ข้อมูลรั่วโดยไม่ตั้งใจ (accidental data breaches)
• ละเมิดกฎระเบียบ (compliance violations)
• เสียชื่อเสียง (reputational damage)

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

1
   1. ระบุให้เจอ (identify)  — มีใครแอบใช้ AI ผีอยู่บ้าง?
2
            │
3
   2. ประเมิน (assess)       — มันเสี่ยงแค่ไหน?
4
            │
5
   3. จัดการ (act)           — "เอาออก" หรือ "ดึงเข้าระบบ"
6
                               ให้ถูกควบคุม

7. AI Incident Management — “เมื่อพนักงานเทพทำพัง”#

control ตัวสุดท้ายของตอนนี้ — AI Incident Management (การจัดการเหตุการณ์ผิดปกติของ AI)

หลายองค์กรมี แผนรับมือเหตุการณ์ความปลอดภัย (incident response) อยู่แล้ว — แผนว่า “ถ้าโดน hack / ข้อมูลรั่ว จะทำยังไง”. คู่มือบอกว่า เราไม่ต้องสร้างใหม่ทั้งหมด — แต่ต้อง “เพิ่มมุม AI” เข้าไปในแผนเดิม. เพราะ AI พังได้ในรูปแบบที่ระบบปกติไม่มี

AI พังได้แบบไหนบ้างที่ต้องเพิ่มเข้าแผน:

สังเกตว่า 3 แถวล่างเป็นเหตุการณ์ที่ “ระบบไอทีปกติไม่มี” — firewall เดิมของคุณไม่รู้จัก “model poisoning” และแผน IR เดิมไม่มีช่อง “AI ตัดสินลำเอียง”. นี่คือเหตุผลที่ต้อง ขยายแผนเดิม

คู่มือยังเน้นว่า ขั้นตอนรับมือ AI incident ต้องครอบคลุมวงจรเต็ม — identify → contain → mitigate → restore (ระบุ → กักกัน → บรรเทา → กู้คืน) เหมือน IR ปกติ แต่ปรับให้เข้ากับ AI. และต้อง identify contingency process — มีแผนสำรองเผื่อ “ข้อมูล/โมเดลของ third-party” ล่มด้วย (เพราะอย่างที่บอกข้อ 5 — เราพึ่ง vendor)

(เรื่อง AI Incident Response เต็มรูปแบบ + Business Continuity ผมเล่าละเอียดตอน Domain 1 ตอนที่ 12 — ในตอนนี้ขอเน้นว่ามันเป็น “control ตัวหนึ่งใน Domain 3” ที่ต้องมี ไม่ใช่ของแถม)

มุมผู้บริหาร: คำถามที่ผู้บริหารต้องถามตรงๆ คือ — “ถ้าพรุ่งนี้เช้า AI ของเราตัดสินผิดจนลูกค้าเสียหาย / หรือข้อมูลรั่วผ่าน AI — แผนรับมือเราพร้อมไหม หรือเรามีแต่แผนรับมือ ‘แบบ hack เดิมๆ’?” AI ล้มเหลวในแบบที่แผน IR เดิมไม่ครอบคลุม. การ “เพิ่มมุม AI เข้าแผนเดิม” เป็นการลงทุนที่ถูกมากเมื่อเทียบกับความเสียหายตอนเกิดจริง — และมันคือสิ่งที่ทำให้องค์กรตอบหน่วยงานกำกับได้ว่า “เราเตรียมพร้อมแล้ว” ไม่ใช่ “เราไม่เคยคิดถึงมันเลย”

สรุป Domain 3 ตอนแรก — จาก “แผน” สู่ “ตู้ control รายวัน”#

มาทบทวนกันสั้นๆ ครับ. ตอนนี้คือ ตอนเปิด Domain 3 — โดเมนที่เราเลิก “วางแผนบนกระดาษ” แล้วลงมือ “คุมพนักงาน AI ในแต่ละวัน” ด้วยเครื่องมือจริง. 7 control ที่เราเปิดดูวันนี้ ร้อยเรียงกันเป็นเรื่องเดียว:

1
   พนักงาน AI มานั่งโต๊ะในออฟฟิศแล้ว — เราคุมเขายังไง?
2

3
   ① Access Control ── ใครให้เขาแตะข้อมูลอะไร (ระวังกุญแจทะลุกำแพง)
4
   ② Zero Trust ───── ไม่เชื่อ 2 ชั้น:
5
                      • ไม่เชื่อว่า "ใครเข้ามา" ปลอดภัย
6
                      • ไม่เชื่อว่า "คำตอบเขา" ถูกเสมอ (Ability/Integrity/Benevolence)
7
   ③ AUP ─────────── กฎกติกาว่าใช้เขาทำอะไรได้/ไม่ได้
8
   ④ Audit/Trace ─── ย้อนรอยได้ว่าเขาตัดสินจากอะไร (กันกล่องดำ)
9
   ⑤ Supply Chain ── คุมพนักงานที่ "เช่ามา" (เรารับผิด ไม่ใช่ vendor)
10
   ⑥ Shadow AI ───── จับ AI ผีนอกระบบ (เปิดทางปลอดภัย + ปิดทางอันตราย)
11
   ⑦ Incident Mgmt ─ เมื่อเขาทำพัง รับมือยังไง (เพิ่มมุม AI เข้าแผนเดิม)

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

1. “เลือก control ให้ถูก” คืองานของผู้บริหาร ไม่ใช่ “ทำให้ครบทุกช่อง” — control ทุกตัวมีต้นทุน. หน้าที่เราคือจับคู่ control กับความเสี่ยงให้ “พอดี” ไม่ใช่ตีเช็คเปล่าทั้งตารางเพื่อความสบายใจ
2. Zero Trust กับ AI ลึกกว่าระบบปกติ — เพราะต้องไม่เชื่อ “คำตอบ” ของมันด้วย — “ระบบทำงานได้” ไม่เท่ากับ “ระบบตัดสินถูก”. AI ที่ตอบลื่นๆ น่าเชื่อถือ อาจกำลังตัดสินผิดอย่างมั่นใจ
3. control ส่วนใหญ่ “ไม่ใช่ของใหม่” — แต่ต้อง “ขยายมาคลุม AI” — IAM, DLP, encryption, IR plan เรามีอยู่แล้ว. ข่าวดีคือไม่ต้องเริ่มจากศูนย์. ข่าวร้ายคือถ้าพื้นฐานไม่แน่น AI จะขยายรอยร้าวเดิมให้ใหญ่ขึ้น

ทั้งหมดนี้ยังคงมุมเดิมที่ผมย้ำตลอดซีรีส์ — เราเป็นผู้บริหาร/deployer ไม่ใช่ data scientist และไม่ใช่ auditor. เราไม่ต้อง config เอง ไม่ต้องถือ checklist มาตรวจ — แต่เราต้อง เข้าใจพอที่จะเลือก control ให้ถูก สั่งทีมให้ถูก และจัดงบให้ถูก

เกริ่นตอนหน้า#

Domain 3 เพิ่งเปิดตู้ control ออกมาให้เห็นภาพรวมและตัวที่ “เกี่ยวกับคนและการเข้าถึง” เท่านั้นครับ. ในตู้ยังมีเครื่องมืออีกหลายหมวดที่เรายังไม่ได้แกะ — ตั้งแต่ control ที่จัดการ “ข้อมูลเข้า-ออก” ของ AI, การวาง security architecture สำหรับ AI โดยเฉพาะ, การคุม วงจรชีวิตของโมเดล (life cycle), ไปจนถึงเรื่อง bias / explainability / human oversight ที่จะทำให้เรา “เชื่อคำตอบ” ของพนักงานเทพคนนี้ได้อย่างมีหลักการ

ตอนหน้าเราจะเดินลึกเข้าไปในตู้ control นี้อีกขั้น — ไปด้วยกันครับ 🙂

อ้างอิงแนวคิด: AAISM — Domain 3: Section 3.10.3 (Access Controls), 3.10.4 (Zero Trust), 3.10.5 (AI Acceptable Use Policy), 3.10.6 (AI Audits and Traceability), 3.10.7 (Security Controls for the Supply Chain), 3.10.8 (Shadow AI) และ 3.10.9 (AI Incident Management). กรอบแนวคิดสาธารณะที่อ้างถึง: NIST AI Risk Management Framework, Cloud Security Alliance AI Controls Matrix, MITRE ATLAS, OWASP Top 10 for LLM Applications, Google Secure AI Framework. ตัวอย่างทั้งหมดในบทเป็นกรณีสมมติเพื่อประกอบความเข้าใจ ไม่ใช่เหตุการณ์จริงหรือการรับรองบริการใด