สิ่งที่ควรคิด ก่อนนำ AI มาใช้ในงาน Cybersecurity แบบไม่ขายฝัน

ช่วงนี้ ถ้าคุยกับคนทำงานสาย security ไม่ว่าจะเป็นฝั่ง SOC, consult, compliance, หรือ engineering มักจะมีคำถามคล้ายกัน คือ เราควรเอา AI มาใช้ตรงไหน และควรเริ่มเมื่อไร คำถามนี้ ฟังดูง่าย แต่ในทางปฏิบัติ ไม่ง่ายเลย เพราะงาน Cybersecurity ไม่ได้วัดกันแค่ว่า ทำงานเร็วขึ้นไหม แต่ยังวัดกันที่ ความถูกต้อง ความน่าเชื่อถือ ความสามารถในการอธิบายเหตุผล และผลกระทบถ้าตัดสินใจพลาด

ผมคิดว่า ปัญหาของหลายทีม ไม่ใช่ ไม่ยอมใช้ AI แต่คือ รีบใช้ AI ก่อนจะตอบให้ได้ว่า workflow ปัจจุบันติดคอขวดตรงไหนกันแน่ บางทีมหวังว่า AI จะช่วยลด alert fatigue แต่สุดท้ายกลับได้ output ที่อ่านเร็วขึ้นจริง แต่ตรวจสอบยากขึ้น บางทีมอยากใช้ AI ช่วยเขียน report ให้ลูกค้า แต่ถ้า source data ยังไม่เป็นระบบ ก็แปลว่ากำลังเร่งความเร็ว ในกระบวนการที่ยังไม่เสถียร

ดังนั้น ถ้าจะมองแบบไม่ขายฝัน ผมเห็นว่า ก่อนนำ AI มาใช้ในงาน Cybersecurity ควรตอบคำถามหลักให้ชัดอย่างน้อย 5 เรื่อง ด้านล่างนี้

1. ต้องรู้ก่อนว่า จะให้ AI ช่วยงานอะไร ไม่ใช่แค่ช่วยทุกอย่าง

คำถามแรก ที่ควรถาม ไม่ใช่ เราใช้ model ไหนดี แต่คือ งานไหนที่เสียเวลาเยอะ ซ้ำบ่อย และมี pattern ชัดพอให้ AI ช่วยได้ โดยไม่เพิ่มความเสี่ยงเกินจำเป็น

ตัวอย่างงานที่มักเหมาะกับการเริ่มต้น มีเช่น

• การสรุป incident note จากข้อมูลดิบ หลายแหล่ง
• การช่วยจัดหมวดหมู่ finding เบื้องต้น ก่อนให้ analyst ตรวจทาน
• การช่วยร่าง executive summary จากรายงานทางเทคนิค
• การช่วยเตรียม checklist สำหรับ discovery call หรือ assessment รอบแรก
• การช่วยแปลงภาษาจาก technical detail ให้คนธุรกิจอ่านเข้าใจง่ายขึ้น

ในทางกลับกัน งานที่ไม่ควรรีบโยนให้ AI รับผิดชอบเต็มตัว คือ งานที่มีผลต่อการตัดสินใจสำคัญ เช่น การฟันธง root cause โดยไม่มี context ครบ การให้คำแนะนำเชิงกฎหมาย หรือการตัดสินว่าเหตุการณ์ไหนต้อง escalate ทันทีโดยไม่มี human review

จุดนี้ สำคัญมาก เพราะถ้าเริ่มจากโจทย์ที่กว้างเกินไป ทีมจะประเมิน ROI ไม่ได้ และพอผลลัพธ์ไม่ดี ก็จะสรุปเร็วเกินไปว่า AI ใช้ไม่ได้ ทั้งที่จริง ปัญหาอาจอยู่ที่เราเลือก use case ผิดตั้งแต่ต้น

2. ข้อมูลที่กำลังจะส่งเข้า AI คือข้อมูลแบบไหน และใครรับความเสี่ยง

งาน Cybersecurity เกี่ยวข้องกับข้อมูลที่อ่อนไหวกว่างานทั่วไปค่อนข้างมาก เช่น

• log ภายในองค์กร
• รายชื่อ asset และ topology
• รายละเอียด vulnerability ที่ยังไม่ปิด
• incident timeline
• ข้อมูลผู้ใช้งาน หรือข้อมูลลูกค้า
• เอกสารนโยบายภายใน

พอเอา AI เข้ามา คำถามจึงไม่ใช่แค่ ส่งได้หรือไม่ได้ แต่ต้องถามต่อว่า ส่งไปที่ไหน เก็บไว้นานแค่ไหน ใช้เพื่อ training หรือไม่ มีข้อตกลงด้าน data handling แบบใด และถ้าข้อมูลหลุด หรือถูกใช้นอกขอบเขต ใครเป็นคนรับผลกระทบ

ทีมจำนวนมาก มักข้ามขั้นตอนนี้ เพราะเห็นแค่ว่า tool ใช้งานง่าย แต่ในโลกจริง ถ้าข้อมูลต้นทางมีความลับสูง ต่อให้ model ดีมาก ก็ไม่ได้แปลว่า ควรใช้งานทันที บางครั้ง ทางออกที่เหมาะกว่า อาจเป็นการเริ่มจากข้อมูลที่ลดความอ่อนไหวแล้ว เช่น scrub identifier ออกก่อน ตัดส่วนที่ไม่จำเป็น หรือใช้ AI เฉพาะกับ summary layer แทน raw evidence

จากประสบการณ์จริง สิ่งที่ควรเขียนให้ชัดตั้งแต่แรก คือ policy ภายในระดับใช้งาน ไม่จำเป็นต้องเริ่มจากเอกสารใหญ่เสมอไป แต่อย่างน้อย ควรมีคำตอบว่า

1. ข้อมูลประเภทไหน ห้ามส่งเข้า AI
2. ข้อมูลประเภทไหน ส่งได้ ถ้าผ่านการลดความอ่อนไหวแล้ว
3. ใครเป็นผู้อนุมัติ exception
4. ต้องเก็บ audit trail อะไรบ้าง
5. ถ้า output ผิดพลาด จะย้อนกลับไปตรวจ source อย่างไร

หลายองค์กร มองข้ามประเด็นนี้ แล้วค่อยกลับมาแก้ทีหลัง ซึ่งมักแพงกว่า และสร้างความไม่มั่นใจให้ทีมปฏิบัติการโดยไม่จำเป็น

3. ต้องออกแบบ human review ให้ชัด อย่าปล่อยให้ AI เป็นคนสุดท้ายที่แตะงาน

ผมคิดว่า ประโยคที่ใช้ได้เสมอในงาน Cybersecurity คือ AI ควรช่วยคิด ช่วยจัดระเบียบ ช่วยเร่งงาน แต่ไม่ควรเป็นผู้รับผิดชอบคนสุดท้าย

เหตุผลไม่ใช่เพราะ AI ไม่มีประโยชน์ แต่เพราะงาน security มีเรื่อง context เยอะมาก เช่น ความสำคัญของ asset, business impact, ความพร้อมของทีม, ข้อจำกัดเรื่อง downtime, หรือแม้แต่ประวัติความเสี่ยงของลูกค้ารายนั้น สิ่งเหล่านี้ ต่อให้ model เก่ง ก็ยังไม่มีทางเข้าใจเท่าคนที่ถือ ownership ของระบบจริง

ถ้าจะใช้ AI ให้ปลอดภัยขึ้น ผมแนะนำให้แบ่ง workflow ออกเป็น 3 ชั้น

ชั้นที่ 1: Preparation

ใช้ AI ช่วยรวมข้อมูล ช่วยสรุป ช่วยดึงประเด็น หรือช่วยเสนอ draft แรก เพื่อให้คนไม่ต้องเริ่มจากศูนย์

ชั้นที่ 2: Verification

ให้ analyst หรือ consultant ตรวจว่า สิ่งที่ AI สรุปมานั้น ตรงกับ source หรือไม่ มี hallucination หรือ overclaim หรือเปล่า และมีประเด็นไหน ที่หายไปเพราะ prompt ไม่ครอบคลุม

ชั้นที่ 3: Decision and communication

ขั้นสุดท้าย ให้คนเป็นผู้ตัดสินใจ ว่าจะส่งต่ออย่างไร จะใช้ถ้อยคำระดับไหน จะเร่งด่วนแค่ไหน และใครควรรับรู้

ในมุมนี้ ถ้าทีมยังตอบไม่ได้ว่า ใคร review output ของ AI และ review จาก source ไหน แปลว่า ยังไม่พร้อมจะเอา AI เข้าสู่ production workflow แบบจริงจัง

4. ต้นทุนจริง ไม่ได้จบที่ค่าสมาชิก แต่รวมถึง integration และ maintenance

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

• เวลาในการทำ prompt และ template ให้ใช้ซ้ำได้
• เวลาในการ clean input data
• เวลาในการตรวจ output ทุกครั้ง
• เวลาในการเชื่อมระบบ กับ ticket, report, knowledge base, หรือ SIEM
• เวลาในการปรับ process เมื่อทีมใช้จริงแล้วเจอ edge case
• ค่าเสียโอกาส ถ้าทีมหลงไปกับ output ที่ดูดี แต่ไม่แม่นพอ

สำหรับทีมเล็ก หรือทีมที่มี backlog แน่นอยู่แล้ว สิ่งที่ตอบโจทย์กว่า อาจไม่ใช่โครงการ AI ใหญ่ แต่เป็น automation เล็ก ที่ช่วยลดงานซ้ำชัดเจน เช่น template สำหรับ incident summary, playbook สำหรับ client communication, หรือ preset prompt ที่ผูกกับประเภทงานไม่กี่แบบก่อน

ผมมักแนะนำให้คิดเหมือนลงทุนระบบใหม่หนึ่งชิ้น คือ ถ้าจะเอาเข้าจริง ต้องดูทั้งค่าเริ่มต้น ค่าเปลี่ยนพฤติกรรมคน และค่าดูแลหลังใช้งาน ไม่ใช่ดูแค่ subscription หน้าเว็บไซต์

5. ต้องวัดผลให้เป็น ไม่อย่างนั้น จะเหลือแค่ความรู้สึกว่าเร็วขึ้น

ทีมจำนวนมาก บอกว่า AI ช่วยได้ แต่พอถามว่า ช่วยได้เท่าไร ตรงไหน และคุ้มกับความเสี่ยงหรือไม่ กลับตอบยาก เพราะไม่เคยกำหนด baseline ตั้งแต่แรก

ถ้าจะเริ่ม pilot ผมมองว่า ควรมี metric ที่จับต้องได้ เช่น

• เวลาที่ใช้ทำ report ฉบับแรก ลดลงกี่เปอร์เซ็นต์
• เวลาที่ analyst ใช้กับงานสรุปซ้ำ ลดลงเท่าไร
• อัตรา error ของ output ก่อน review อยู่ระดับไหน
• reviewer ใช้เวลาตรวจเพิ่มขึ้น หรือ ลดลง
• stakeholder อ่านแล้วเข้าใจมากขึ้นหรือไม่
• มีกรณีไหนที่ output ของ AI ทำให้ตัดสินใจผิด หรือเกือบผิด

สิ่งสำคัญ คือ metric ต้องผูกกับงานจริง ไม่ใช่ผูกกับความว้าวของ demo เพราะของที่โชว์ได้ดี ไม่ได้แปลว่า ของที่ deploy แล้วจะตอบโจทย์เสมอ

ตัวอย่าง workflow ที่เริ่มได้จริง แบบความเสี่ยงไม่สูงเกินไป

ถ้าผมต้องเริ่มในทีมเล็ก วันนี้ ผมจะเริ่มจาก workflow ประมาณนี้

1. เลือกงานเดียว ที่ปวดจริง เช่น การสรุป finding สำหรับ executive update
2. จำกัด input ให้ชัด ว่ามาจากเอกสารชนิดไหน
3. เขียน prompt เวอร์ชันแรก ให้บอก audience, format, และข้อห้ามชัดเจน
4. ให้คนในทีมทดลองใช้ กับเคสเก่า 10 ถึง 20 เคส
5. เปรียบเทียบกับวิธีเดิม ทั้งเวลา และคุณภาพ
6. เก็บข้อผิดพลาดที่เจอบ่อย แล้วแก้ที่ process ก่อนแก้ที่ model
7. ค่อยขยาย use case เมื่อทีมเริ่มเชื่อใจ workflow มากขึ้น

ตัวอย่าง prompt ที่ practical และไม่คาดหวังเกินจริง อาจเขียนแบบนี้

Role: cybersecurity reporting assistant
Task: create a first draft executive summary from validated technical findings
Audience: IT manager and business owner
Need: risk summary, likely business impact, recommended next action, items that require human confirmation
Constraints: do not invent evidence, do not assign severity without source support, mark uncertainty clearly
Output language: Thai
Tone: calm, practical, credible

prompt ลักษณะนี้ ช่วยบังคับขอบเขตการใช้งานได้ดี เพราะไม่ได้สั่งให้ AI ตัดสินทุกอย่าง แต่สั่งให้ช่วยร่างในรูปแบบที่ reviewer ตรวจต่อได้ง่าย

คำถามสั้น ๆ ที่ควรถามก่อนอนุมัติใช้งานจริง

ก่อนกดใช้งานในทีม ผมคิดว่า หัวหน้าทีม หรือ owner ของ workflow ควรถามคำถามต่อไปนี้ให้ครบ

• ถ้าวันนี้ AI ตอบผิด เราจะจับได้ตรงไหน
• ถ้าข้อมูลที่ป้อนเข้าไปมีความลับสูง เรามี control อะไรรองรับ
• ถ้า tool ตัวนี้หยุดให้บริการ เรากลับไปทำงานแบบเดิมได้ไหม
• reviewer มีเวลาและความสามารถพอจะตรวจ output หรือไม่
• คนในทีมเข้าใจข้อจำกัดของมันจริง หรือกำลังเชื่อเพราะ output อ่านลื่น
• เรามีหลักฐานอะไรว่า workflow ใหม่นี้ ดีกว่าเดิม ไม่ใช่แค่ดูทันสมัยกว่าเดิม

คำถามพวกนี้ อาจฟังดูช้า แต่จริง ๆ แล้วช่วยให้การทดลองใช้ AI มีโอกาสสำเร็จมากกว่า เพราะทีมรู้ตั้งแต่ต้นว่า กำลัง optimize งานไหน และกำลังยอมรับความเสี่ยงแบบใด

สรุปแบบตรงไปตรงมา

AI ในงาน Cybersecurity มีประโยชน์จริง โดยเฉพาะกับงานสรุป งานจัดระเบียบข้อมูล งานร่างเอกสาร และงานที่มีรูปแบบซ้ำ แต่ประโยชน์นั้น จะเกิดก็ต่อเมื่อทีมรู้ก่อนว่า ปัญหาจริงคืออะไร ข้อมูลที่ใช้มีความอ่อนไหวแค่ไหน ใครเป็นคนตรวจ ใครเป็นคนรับผิดชอบ และจะวัดผลอย่างไร

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

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