ช่วงที่ 1 — ตั้งเจ้าภาพและวางโครง (ตอน 01–04)#

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

• ตอนที่ 02 — AI Governance + ความพร้อม เราเริ่มจากคำว่า AI Governance (การกำกับดูแล AI) ที่จริงๆ แล้วแปลว่า “ใครเป็นคนตัดสินใจ และตัดสินด้วยหลักอะไร” และก่อนจะกระโดดเข้าไปคุม เราต้องเช็กก่อนว่าองค์กร “พร้อมแค่ไหน” ใน 3 มุม คือ ประโยชน์ ความเสี่ยง และทรัพยากร เพราะบางองค์กรปัญหาจริงคือ “คนไม่มีทักษะ” ไม่ใช่ “ไม่มีนโยบาย” แก้ผิดจุดก็เสียเวลาเปล่า
• ตอนที่ 03 — บทบาทและกฎบัตร AI เราแบ่งงานว่าใครทำอะไร ตั้งแต่บอร์ด/ผู้บริหาร, คณะกรรมการขับเคลื่อน AI ที่มาจากหลายแผนก, ไปจนถึง AI Lead และเครื่องมือตั้งต้นอย่าง AI Charter (กฎบัตร AI) ซึ่งเป็นเอกสารหน้าเดียวที่บอกว่าโครงการนี้ทำเพื่ออะไร ขอบเขตแค่ไหน ใครรับผิดชอบ ใครเซ็นอนุมัติ หลักที่ผมย้ำหนักสุดคือ ความรับผิดชอบสูงสุดมอบหมายต่อไม่ได้
• ตอนที่ 04 — กรอบมาตรฐานและกฎหมาย เราแยกให้ชัดระหว่าง “มาตรฐานที่เราเลือกใช้เอง” (สมัครใจ ปรับได้) กับ “กฎหมายที่เราต้องตาม” (บังคับ ไม่ทำมีโทษ) สองอย่างนี้หน้าตาคล้ายกันแต่ผลตามกฎหมายต่างกันลิบ และ AI เป็นพื้นที่ที่กฎหมายทั่วโลกกำลังเปลี่ยนเร็วมาก

ช่วงนี้คือการ “ตั้งหัวหน้าให้พนักงานใหม่ และเขียนกรอบกว้างๆ ว่าเขาต้องอยู่ใต้กฎอะไรบ้าง” ครับ

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

ช่วงที่ 2 — ตัดสินใจและตั้งกติกา (ตอน 05–08)#

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

• ตอนที่ 05 — Use case และ Business Case AI ไม่ได้เหมาะกับทุกงาน เราเรียนรู้ที่จะถามว่า “งานนี้ AI ทำแล้วคุ้มไหม วัดผลตอบแทนยังไง และมันมีขีดจำกัดตรงไหน” ก่อนจะลงทุน เพราะการตัดสินใจว่า “ยังไม่ใช้ AI ตรงนี้” ก็เป็นคำตอบที่ถูกต้องได้บ่อยกว่าที่คิด
• ตอนที่ 06 — สร้างเอง vs ซื้อ + คุม vendor เราชั่งน้ำหนักระหว่าง “สร้าง AI เอง” กับ “ซื้อสำเร็จรูปมาใช้” และที่สำคัญคือเรื่อง Shared Responsibility Model ซึ่งเป็นความเข้าใจที่ว่า ต่อให้เราซื้อ AI จาก vendor มาใช้ ความรับผิดชอบบางส่วนก็ไม่เคยหลุดจากมือเรา ถ้า AI ที่เราเอามาใช้ทำพลาด คนที่ลูกค้าฟ้องและแบรนด์ที่เสียคือเรา
• ตอนที่ 07 — AUP และ AI Policy นี่คือ “คู่มือพนักงาน” ตัวจริง เราเขียน AI Acceptable Use Policy (นโยบายการใช้ AI ที่ยอมรับได้) เพื่อบอกพนักงานว่าอะไรทำได้ อะไรห้าม ก่อนที่พวกเขาจะเอาข้อมูลลับไปวางในเครื่องมือ AI โดยไม่รู้ว่าผิด
• ตอนที่ 08 — จริยธรรม AI เราคุยเรื่องที่กฎหมายไปไม่ถึงแต่กระทบคนจริง ทั้งอคติ (bias), ความเป็นธรรม, ความสามารถในการอธิบาย (explainability), ลิขสิทธิ์ และสิทธิมนุษยชน เพราะ AI ที่ตัดสินใจเลือกปฏิบัติกับคนกลุ่มหนึ่งโดยไม่มีใครอธิบายได้ว่าทำไม คือความเสี่ยงต่อชื่อเสียงที่ร้ายแรงมาก

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

ลองนึกภาพต่ออีกฉากครับ สมมติว่าเจ้าของร้านคนเดิมอยากเอา AI มาช่วยคัดกรองใบสมัครพนักงาน เพราะมีคนสมัครเข้ามาเยอะมาก ฟังดูเป็น use case ที่คุ้มดี แต่พอลองคิดตามกติกาที่วางไว้ในช่วงนี้ คำถามก็เริ่มโผล่ทีละข้อ “ถ้าเราซื้อเครื่องมือสำเร็จรูปมา แล้วมันคัดเอนเอียงตามเพศหรืออายุโดยไม่มีใครอธิบายได้ว่าทำไม ใครรับผิด vendor หรือเรา?” คำตอบจาก Shared Responsibility คือ “เรา” เพราะเราคือคนที่เอามาใช้กับผู้สมัครจริง สุดท้ายเจ้าของจึงตัดสินใจว่าจะใช้ AI แค่ช่วย “จัดเรียงเอกสาร” แต่ให้คนเป็นผู้ตัดสินใจขั้นสุดท้าย พร้อมเขียนลงนโยบายชัดเจนว่า “ห้ามให้ AI เป็นคนปฏิเสธผู้สมัครเองโดยไม่มีคนตรวจ” นี่คือตัวอย่างที่ use case, Shared Responsibility, นโยบาย และจริยธรรม ทำงานร่วมกันในการตัดสินใจเดียว

ช่วงที่ 3 — รู้จักสินทรัพย์ ป้องกัน และเตรียมรับมือ (ตอน 09–12)#

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

• ตอนที่ 09 — บัญชี AI และ Shadow AI เราทำ “ทะเบียนรายชื่อ” ว่าบริษัทมี AI กี่ตัว ใช้ตรงไหนบ้าง รวมถึง Shadow AI (AI เถื่อนที่พนักงานแอบใช้เองโดยองค์กรไม่รู้) ซึ่งเป็นช่องโหว่ที่เจ้าของกิจการมองไม่เห็นบ่อยที่สุด เพราะหลักง่ายๆ คือ “ของที่เราไม่รู้ว่ามีอยู่ เราคุมไม่ได้”
• ตอนที่ 10 — ข้อมูลคือหัวใจของ AI เราเข้าใจว่า AI เก่งแค่ไหนก็แพ้ข้อมูลขยะ จึงต้องจัดประเภทข้อมูล ดูคุณภาพ ดูเรื่องการขอความยินยอม (consent) และใช้เครื่องมืออย่าง model card (เอกสารกำกับโมเดล) เพราะข้อมูลที่ป้อนเข้าไปสอน AI คือสิ่งที่กำหนดว่ามันจะแม่นหรือเพี้ยน
• ตอนที่ 11 — สร้าง AI Security Program เราวางโปรแกรมความปลอดภัยเป็นระบบ พร้อมตัวชี้วัด (KPI/KRI) และแยกให้ชัดสองด้าน คือ security FOR AI (ปกป้องตัว AI จากการถูกโจมตี) กับ AI FOR security (ใช้ AI มาช่วยงานความปลอดภัยของเรา)
• ตอนที่ 12 — Incident Response และ Business Continuity เรื่องสุดท้ายคือเตรียมแผนเผื่อวันที่พนักงานคนนี้ทำงานพัง ทั้งแผนรับมือเหตุ (Incident Response) และแผนให้ธุรกิจเดินต่อได้ (Business Continuity) เพราะคำถามไม่ใช่ “ถ้า AI พลาด” แต่คือ “เมื่อ AI พลาด เราพร้อมแค่ไหน”

ช่วงนี้คือการ “เปิดบัญชีดูว่ามีพนักงาน AI กี่คน ดูแลข้อมูลที่เขาแตะ วางระบบความปลอดภัยรอบตัวเขา และเตรียมแผนเผื่อวันที่เขาทำพลาด” ครบทั้งห้าดินแดนพอดี

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

ทั้ง 12 ตอนต่อกันเป็นเส้นเดียว#

ลองมองภาพรวมทั้งโดเมนเป็นแผนผังเดียวครับ ผมวาดให้เห็นว่าเราเดินจากซ้ายไปขวายังไง:

1
  ช่วง 1: ตั้งเจ้าภาพ + วางโครง
2
  ┌──────────────────────────────────────────────┐
3
  │ เปิดโดเมน (แผนที่ 5 ดินแดน)                     │
4
  │   → Governance + ความพร้อม                     │
5
  │     → บทบาท + AI Charter                        │
6
  │       → กรอบมาตรฐาน vs กฎหมาย                  │
7
  └──────────────────────────────────────────────┘
8
                       │
9
  ช่วง 2: ตัดสินใจ + ตั้งกติกา
10
  ┌──────────────────────────────────────────────┐
11
  │ Use case + คุ้มไหม (business case)             │
12
  │   → สร้างเอง vs ซื้อ + Shared Responsibility    │
13
  │     → AUP / AI Policy (คู่มือพนักงาน)           │
14
  │       → จริยธรรม (bias / เป็นธรรม / อธิบายได้)   │
15
  └──────────────────────────────────────────────┘
16
                       │
17
  ช่วง 3: รู้จักสินทรัพย์ + ป้องกัน + รับมือ
18
  ┌──────────────────────────────────────────────┐
19
  │ บัญชี AI + Shadow AI                            │
20
  │   → ข้อมูลคือหัวใจ (คุณภาพ / consent)            │
21
  │     → AI Security Program (KPI/KRI)            │
22
  │       → Incident Response + Business Continuity│ ← จบ D1
23
  └──────────────────────────────────────────────┘

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

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

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

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

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

บทเรียนที่ 1 — ความรับผิดชอบเรื่อง AI มอบหมายต่อไม่ได้#

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

คุณจ้าง AI มาทำงานได้ มอบงานให้มันได้ ซื้อ AI จาก vendor มาใช้ก็ได้ แต่ถ้ามันทำพลาดจนเกิดความเสียหาย คนที่ต้องรับผิดตามกฎหมายและต่อหน้าสังคมคือ คุณในฐานะเจ้าของกิจการ ไม่ใช่ “ตัว AI” และไม่ใช่ vendor ที่คุณซื้อมา

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

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

บทเรียนที่ 2 — เริ่มจาก “ใครเป็นเจ้าภาพ” ไม่ใช่ “ซื้อเครื่องมืออะไร”#

เจ้าของกิจการหลายคนพอได้ยินคำว่า AI ก็รีบถามว่า “ควรซื้อเครื่องมือตัวไหนดี” แต่จาก Domain 1 เราเห็นแล้วว่านั่นคือคำถามที่ผิดลำดับ

คำถามแรกที่ถูกต้องคือ “ใครเป็นเจ้าภาพ ใครตัดสินใจ และตัดสินด้วยหลักอะไร” เพราะถ้าไม่มีเจ้าภาพ ต่อให้ซื้อเครื่องมือดีแค่ไหนมา สุดท้ายก็จะกลายเป็นภาพเดิม คือทุกแผนกต่างคนต่างใช้ ไม่มีใครคุมภาพรวม และเกิด Shadow AI กระจายทั่วองค์กร

นี่คือเหตุผลที่ผมจัดลำดับ Domain 1 ให้เริ่มจากเรื่อง governance และบทบาท (ตอน 02-03) ก่อนเรื่องเทคนิคและเครื่องมือทั้งหมด เพราะเครื่องมือเป็นแค่ “อุปกรณ์” ส่วนการตัดสินใจว่าใครรับผิดชอบคือ “ฐานราก” ลองคิดเทียบกับการสร้างบ้านครับ เราไม่ได้เริ่มจากการเลือกเฟอร์นิเจอร์ แต่เริ่มจากการวางเสาเข็มก่อนเสมอ

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

บทเรียนที่ 3 — “สิ่งที่เราไม่รู้ว่ามีอยู่” คือความเสี่ยงที่อันตรายที่สุด#

ตลอด Domain 1 มีธีมเงียบๆ อันหนึ่งที่โผล่ซ้ำหลายตอน ทั้ง Shadow AI ที่พนักงานแอบใช้, ข้อมูลที่ป้อนเข้า AI โดยไม่มีใครตรวจ, ไปจนถึงสัญญา vendor ที่ไม่มีใครอ่านว่าข้อมูลลูกค้าถูกเก็บไว้ที่ไหน

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

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

มุมผู้บริหาร: สิ่งที่ยอมรับไม่ได้ไม่ใช่ “มีความเสี่ยง” เพราะทุกองค์กรมีความเสี่ยง สิ่งที่ยอมรับไม่ได้คือ “ไม่รู้ว่ามันมีอยู่” เพราะความเสี่ยงที่รู้ตัว เราตัดสินใจได้ว่าจะรับ จะเลี่ยง หรือจะลด แต่ความเสี่ยงที่มองไม่เห็น มันจะมาเจอเราเองในวันที่เราไม่ทันตั้งตัว

บทเรียนที่ 4 — เขียนกฎ “ก่อน” ที่จะต้องใช้ ไม่ใช่ “หลัง” เกิดเหตุ#

จาก AUP/นโยบาย (ตอน 07) ไปจนถึงแผนรับมือเหตุ (ตอน 12) มีหลักร่วมกันอยู่ข้อหนึ่ง คือ เอกสารพวกนี้มีคุณค่าก็ต่อเมื่อเขียนไว้ “ล่วงหน้า”

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

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

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

บทเรียนที่ 5 — AI คือพนักงานที่ต้อง “กำกับต่อเนื่อง” ไม่ใช่ “ติดตั้งเสร็จแล้วลืม”#

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

AI เรียนรู้ ปรับตัว และเปลี่ยนพฤติกรรมได้ตามข้อมูลที่มันเจอ ฉะนั้นการมีตัวชี้วัด (KPI/KRI ในตอน 11) การเฝ้าดูคุณภาพข้อมูล และการตรวจสอบผลลัพธ์อย่างสม่ำเสมอ จึงไม่ใช่ทางเลือก แต่เป็นส่วนหนึ่งของการ “จ้าง” พนักงานคนนี้

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

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

ผมขอสรุป 5 บทเรียนนี้เป็นตารางให้หยิบไปใช้ง่ายๆ ครับ:

สิ่งที่เปลี่ยนไปในหัวเจ้าของกิจการ หลังจบ Domain 1#

ถ้าให้ผมชี้ว่า Domain 1 เปลี่ยน “วิธีคิด” ของเจ้าของกิจการไปยังไง ผมว่ามันคือการเปลี่ยนมุมมองที่มี AI สามอย่าง

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

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

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

กับดักที่เจ้าของกิจการชอบติดตลอด Domain 1#

ก่อนจะปิด ผมขอรวบ “กับดักความคิด” ที่โผล่ซ้ำหลายตอนตลอดทั้งโดเมนไว้ที่เดียว เพราะมันคือด้านกลับของ 5 บทเรียนข้างบน รู้กับดักไว้ ก็เลี่ยงได้ก่อนจะเดินไปเหยียบ:

• กับดักที่ 1 — “ซื้อ AI จาก vendor ใหญ่ๆ แล้ว = หมดห่วง” ❌ ไม่จริง Shared Responsibility บอกชัดว่าส่วนของเราไม่เคยเป็นศูนย์ ถ้าข้อมูลลูกค้ารั่วผ่าน AI ที่เราเอามาใช้ คนที่ถูกฟ้องคือเรา ไม่ใช่ vendor
• กับดักที่ 2 — “AI มันฉลาด เชื่อมันได้เลย” ❌ AI ที่ตอบผิดแบบมั่นหน้า (hallucinate) อันตรายกว่า AI ที่บอกว่า “ไม่รู้” เพราะมันชวนให้เราเชื่อโดยไม่ตรวจ
• กับดักที่ 3 — “ไม่มีใครในบริษัทใช้ AI หรอก เราไม่ได้ประกาศให้ใช้” ❌ Shadow AI เกิดขึ้นเพราะพนักงานอยากทำงานเร็วขึ้น ไม่ใช่เพราะมีคนสั่ง การ “ไม่เคยทำบัญชี” ไม่ได้แปลว่า “ไม่มี” — แปลว่า “เรามองไม่เห็น”
• กับดักที่ 4 — “เขียนนโยบาย AI ไว้ก็พอ แค่มีเอกสารก็จบ” ❌ นโยบายที่ไม่มีคนสื่อสาร ไม่มีคนบังคับใช้ และไม่มีแผนรับมือเหตุรองรับ ก็แค่ไฟล์ในโฟลเดอร์ที่ไม่มีใครเปิด
• กับดักที่ 5 — “ติดตั้ง AI เสร็จแล้วก็เหมือนติดตั้งซอฟต์แวร์ จบงาน” ❌ AI เปลี่ยนพฤติกรรมได้ตลอด ของที่แม่นวันนี้อาจเพี้ยนในอีกหกเดือน โดยไม่มี error เด้งเตือน

ถ้าจะให้ผมสรุป Domain 1 ทั้งโดเมนเป็นประโยคเดียวสำหรับเจ้าของกิจการ ก็คือ:

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