เส้น “ใครคุมได้มากแค่ไหน” — สิ่งที่ต้องเข้าใจก่อนอื่น#

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

ลองมองเป็นเส้นต่อเนื่องแบบนี้ครับ:

1
  AI ที่เราพัฒนาเองในบ้าน
2
  → คุมความเสี่ยงและสภาพแวดล้อมได้มากที่สุด
3
  ├───────────────────────────────────────────────┤
4

5
  AI ที่เราซื้อ/เช่าจาก provider ภายนอก
6
  → คุมความเสี่ยงและสภาพแวดล้อมได้น้อยที่สุด
7
  ├───────────────────────────────────────────────┤

และไม่ว่าจะอยู่ตรงไหนของเส้นนี้ AI ที่เราใช้ยังแบ่งได้อีกตามว่า “เอาไปทำอะไร”:

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

Provider กับ Deployer ต้องทำอะไรบ้าง — เทียบกันชัดๆ#

กฎหมาย AI ของสหภาพยุโรป (EU AI Act) เป็นกรอบที่แยกบทบาทสองฝั่งนี้ชัดที่สุด และกำหนดหน้าที่ให้แต่ละฝั่งไม่เหมือนกัน ขอเรียบเรียงเป็นตารางเทียบให้เห็นภาพว่าใครต้องทำอะไร:

ลองอ่านคอลัมน์ขวาให้ดีนะครับ — นี่คือ “การบ้าน” ของเราในฐานะ deployer ไม่มีข้อไหนที่บอกว่า “ปล่อยให้ provider ทำหมด” เลย เราต้องคุมข้อมูลที่ป้อนเข้า ต้องมีคนกำกับ ต้องเฝ้าดูผลลัพธ์ ต้องบอกลูกค้าว่ากำลังคุยกับ AI และต้องเก็บหลักฐานการใช้งาน

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

NIST มองห่วงโซ่ AI ละเอียดกว่านั้น — “AI Actors” หลายบทบาท#

ฝั่งสหรัฐฯ มีกรอบจัดการความเสี่ยง AI ของ NIST (เรียกว่า NIST AI RMF) ซึ่งไม่ได้แบ่งแค่ provider กับ deployer แบบกฎหมายยุโรป แต่ใช้คำกว้างกว่าว่า “AI Actors” (ผู้มีบทบาทเกี่ยวกับ AI) แล้วแตกย่อยว่าในแต่ละช่วงของวงจร AI มีใครเกี่ยวข้องบ้าง

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

📚 ใครยังไม่คุ้นว่า “actor / threat actor” และเรื่องบทบาทขององค์กรในงานความปลอดภัยทำงานยังไง ผมเล่าพื้นฐานเรื่องผู้มีบทบาทและโครงสร้างองค์กรไว้ในตอนเก่าๆ ของซีรีส์ CyberSecurity Foundation และ Org Anatomy 101 แล้วครับ ตอนนี้โฟกัสเฉพาะว่าบทบาทเหล่านี้ “แมป” ลงเป็นความรับผิดของเรายังไง

จุดที่ผมอยากให้สังเกตคือ — สามแถวล่างของตารางนี้ (นำไปใช้ / ใช้งาน-เฝ้าระวัง / กำกับดูแล) เกือบทั้งหมดคือคนของเรา โดยเฉพาะแถวสุดท้าย “กำกับดูแล” ที่มีคำว่า ผู้บริหารองค์กร ผู้นำระดับสูง คณะกรรมการบริษัท — นี่คือการบอกตรงๆ ว่าความรับผิดชอบสูงสุดต่อการใช้ AI จบที่โต๊ะผู้บริหาร ไม่ใช่ที่ผู้ขาย

มุมผู้บริหาร: ความต่างของสองกรอบนี้สรุปง่ายๆ ได้ว่า — กฎหมายยุโรป (EU AI Act) บอกชัดเป็นข้อๆ ว่าใครต้องทำอะไร (provider/deployer แยกหน้าที่ตายตัว มีบทลงโทษถ้าไม่ทำ) ส่วน กรอบ NIST ยืดหยุ่นกว่า (บอกว่ามีบทบาทอะไรบ้าง แต่ไม่ฟันธงว่าใครต้องรับผิดชอบข้อไหน ปล่อยให้องค์กรไปจัดเอง) สำหรับเจ้าของกิจการ ความหมายคือ: ถ้าธุรกิจเราแตะตลาด/ลูกค้าในยุโรป เราเลี่ยงหน้าที่ตามกฎหมายยุโรปไม่ได้แม้บริษัทจะอยู่ไทย (กฎหมายนี้บังคับข้ามพรมแดน) ส่วนถ้าจะวางระบบให้รัดกุมโดยสมัครใจ กรอบ NIST คือเครื่องมือที่ใช้ได้กับทุกอุตสาหกรรม

บทเรียนแชตบอตสายการบิน — เคสที่กลายเป็นคดีจริง#

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

มีบริษัทซอฟต์แวร์เจ้าหนึ่ง (เป็น provider) พัฒนาแชตบอตบริการลูกค้าที่ขับเคลื่อนด้วย AI แล้วสายการบินแห่งหนึ่ง (เป็น deployer) สมัครใช้แชตบอตตัวนี้ เอามาเสียบไว้บนหน้าเว็บเพื่อตอบคำถามลูกค้า

วันหนึ่งลูกค้าคนหนึ่งถามแชตบอตเรื่องส่วนลดค่าตั๋วกรณีพิเศษ แชตบอต “มั่นใจมาก” ตอบไปว่าลูกค้าขอเงินคืนย้อนหลังได้ — ทั้งที่จริงสายการบินไม่มีนโยบายคืนเงินแบบนั้นเลย ลูกค้าเชื่อตามที่แชตบอตบอก พอไปขอเงินคืนจริงกลับถูกปฏิเสธ เรื่องจึงไปถึงการตัดสิน

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

ลองสรุปบทเรียนเป็นข้อๆ ที่เจ้าของกิจการเอาไปใช้ได้เลย:

แล้วเส้นแบ่ง “ความรับผิดชอบ” ระหว่างสองฝั่งอยู่ตรงไหน?#

แม้ deployer จะเลี่ยงความรับผิดต่อลูกค้าไม่ได้ แต่ก็ไม่ได้แปลว่า provider ลอยตัวนะครับ เส้นแบ่งหลักการอยู่ตรงนี้:

• Provider (คนสร้าง/ขาย) รับผิดชอบเรื่อง — คุณภาพ ความปลอดภัย และความเสี่ยงที่ติดมากับตัว AI เอง (เช่น โมเดลถูกฝึกมาดีไหม มีช่องโหว่ไหม เข้ารหัสน้ำหนักโมเดลปลอดภัยไหม)
• Deployer (คนเอามาใช้ = เรา) รับผิดชอบเรื่อง — การใช้ AI อย่างปลอดภัยและมีจริยธรรมภายในงานของเรา และการดูแลผลกระทบที่เกิดกับผู้ใช้และผู้เกี่ยวข้อง

จุดที่ต้องระวังเพิ่มคือ — เรา (deployer) มักเป็นฝ่ายที่คุยกับลูกค้าตรงๆ ส่วน provider อาจไม่เคยเจอลูกค้าเราเลย แล้วแต่รูปแบบธุรกิจของเขา นั่นยิ่งตอกย้ำว่าเวลาเกิดเรื่องกับลูกค้า คนแรกที่ต้องรับหน้าคือเรา

และมีกรณีพิเศษที่ต้องรู้ — บางครั้งบริษัทหนึ่งเป็นทั้ง provider และ deployer พร้อมกัน เช่น บริษัทที่สร้าง AI ขึ้นเองแล้วก็เอามาใช้ในบริการตัวเองด้วย กรณีนี้ต้องแบกหน้าที่ทั้งสองฝั่ง

มุมผู้บริหาร: ถ้าจะจำเรื่องนี้ประโยคเดียว — “เราเอา AI มาใช้ = เรารับความเสี่ยงนั้นเข้าบ้าน” ไม่ใช่ฝากไว้กับผู้ขาย คำถามจริงที่ต้องตอบก่อนเปิดให้ AI คุยกับลูกค้าคือ “ถ้ามันให้คำมั่น/ข้อมูลผิดกับลูกค้า เราพร้อมจะถูกถือว่าให้คำมั่นนั้นเองไหม?” ถ้ายังไม่พร้อม ทางแก้ไม่ใช่การเขียน disclaimer แต่คือ (1) จำกัดขอบเขตที่ AI ตอบได้ (2) ให้คนตรวจก่อนเรื่องสำคัญ (HITL) และ (3) ใส่เงื่อนไขในสัญญากับผู้ขายว่าถ้าความเสียหายมาจากข้อบกพร่องของโมเดลเขา เขาต้องร่วมรับผิดชอบ

ทำไมมันเหมือนคลาวด์เป๊ะ#

จำตอน Cloud Shared Responsibility (CyberSec EP.32) ได้ไหมครับ — หลักคือ “ผู้ให้บริการคลาวด์ดูแลความปลอดภัย ของ คลาวด์ (ตัวเครื่อง ศูนย์ข้อมูล โครงสร้างพื้นฐาน) ส่วนเราดูแลความปลอดภัย บน คลาวด์ (ข้อมูลของเรา ใครเข้าถึงได้ ตั้งค่าถูกไหม)” และเส้นแบ่งนั้นเลื่อนไปมาตามแบบบริการที่เราเลือก

AI ก็ใช้หลักเดียวกันเป๊ะครับ:

1
   คลาวด์:  ผู้ให้บริการดูแล "ตัวคลาวด์"  |  เราดูแล "สิ่งที่เราเอาขึ้นไปวางบนคลาวด์"
2
      AI :  provider ดูแล "ตัวโมเดล"      |  เราดูแล "วิธีที่เราเอาโมเดลมาใช้ + ข้อมูลที่ป้อนเข้า"

ความต่างสำคัญที่ผมอยากเตือนคือ — เส้นแบ่งของ AI ต้องเขียนไว้ในสัญญาให้ชัด ไม่ใช่เดาเอาเอง โดยเฉพาะเรื่อง ข้อตกลงระดับบริการ (SLA), การรับมือเหตุ, และเงื่อนไขการแจ้งเตือนเมื่อเกิดเหตุ ถ้าไม่เขียนไว้ พอเกิดเรื่องจริงจะเถียงกันไม่จบว่า “นี่งานใคร”

แผนที่ความรับผิดชอบ — ฝั่งเรา (Deployer) ต้องดูแลอะไร#

ขอเรียบเรียงเป็นแผนที่ว่า ในฐานะ deployer เราต้องดูแล “ชั้น” ไหนบ้าง พร้อมแปลเป็นภาษาคนและตัวอย่างที่เห็นภาพ:

ขยายความข้อที่เป็นการบ้านหลักของ deployer แบบกระชับ:

• ตรวจสอบและทดสอบ — ตรวจ AI สม่ำเสมอ ดูการตั้งค่าด้านความเป็นส่วนตัวและความปลอดภัย และทดสอบเจาะระบบเพื่อหาจุดอ่อนของ control ที่ใช้อยู่
• กำกับข้อมูล — วางระบบกำกับข้อมูลให้แน่น ทั้งคุณภาพ ความครบถ้วน ความเป็นส่วนตัว ความปลอดภัย และตามรอยที่มา-การแปลงข้อมูลได้
• ตัวตนและสิทธิ์เข้าถึง — คุมการเข้าถึง AI และข้อมูลให้รัดกุม
• วางแผนรับมือเหตุ — มีแผนรับมือเหตุด้านความปลอดภัยที่เกี่ยวกับ AI โดยเฉพาะ ทั้งการเขียนแผน ฝึกคน และซ้อมแผน
• ตรวจสอบโมเดล — ทดสอบและตรวจรับโมเดลอย่างเข้มข้น รวมถึงทดสอบแบบจำลองการโจมตีเพื่อหาและกำจัดอคติ/ช่องโหว่
• จัดการความเสี่ยงห่วงโซ่อุปทาน — ประเมินความมั่นคงปลอดภัยของผู้ขายและผู้ขายของเขา ตรวจแนวปฏิบัติด้านความปลอดภัย ฐานะการเงิน ชื่อเสียง และใส่ข้อกำหนดเรื่องความปลอดภัย การแจ้งเหตุ/การละเมิด และความเป็นส่วนตัวไว้ในสัญญา
• ความโปร่งใสและอธิบายได้ — ให้ผู้ใช้รู้ตัวเสมอเมื่อมีปฏิสัมพันธ์กับ AI เลือกโมเดลที่อธิบายเหตุผลการตัดสินใจได้บ้าง และคอยเฝ้าดูผลลัพธ์ว่าผิดปกติไหม

📚 หลายข้อข้างบนเป็นเรื่องที่เราเคยคุยลึกในตอนก่อนๆ ของ Domain นี้แล้ว — การกำกับข้อมูลสำหรับ AI, การรับมือเหตุ AI, และการจัดการผู้ขาย AI ตอนนี้ผมจึงไม่ลงรายละเอียดซ้ำ แค่ชี้ว่า “ทั้งหมดนี้ตกอยู่ในมือเราในฐานะ deployer” ไม่ใช่ของผู้ขาย

แผนที่ความรับผิดชอบ — ฝั่งผู้ขาย (Provider) ต้องดูแลอะไร#

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

สรุปหน้าที่หลักของ provider แบบสั้นๆ: ดูแล ความปลอดภัยของข้อมูล (ข้อมูลฝึก น้ำหนักโมเดล ค่าพารามิเตอร์ log), การพัฒนาโมเดล (มีกรอบจริยธรรม เขียนโค้ดปลอดภัย ใช้ข้อมูลที่ลดอคติ), ความโปร่งใส (ให้เอกสารและเครื่องมือช่วยให้ลูกค้าเข้าใจว่ามันทำงานยังไง), การปฏิบัติตามมาตรฐาน (มีใบรับรอง), การรับมือเหตุ (มีแผนและประสานกับเรา) และ การจัดการช่องโหว่ (อุดช่องโหว่เชิงรุก)

เครื่องมือเดียวที่ทำให้เส้นแบ่งนี้มีผลจริง — สัญญา#

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

• ข้อตกลงระดับบริการ (SLA) — ผู้ขายรับประกันอะไร ตอบสนองเร็วแค่ไหน
• การรับมือเหตุ — เกิดเหตุที่ฝั่งเขาแล้วเขาต้องทำอะไร ประสานกับเรายังไง
• เงื่อนไขการแจ้งเตือนเมื่อเกิดเหตุ — เขาต้องบอกเราภายในกี่ชั่วโมง ผ่านช่องทางไหน

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