ระเบียบการใช้งาน Generative AI ที่สำนักงานใหญ่ในญี่ปุ่นจัดทำขึ้น ถูกส่งลงมาถึงบริษัทในเครือที่ประเทศไทย พอเปิดอ่านก็พบข้อห้ามเรียงกันเป็นแถว แต่คำถามแรกที่เกิดขึ้นที่หน้างานจริงกลับเป็น “แล้วตกลงทำอะไรได้บ้าง” บทความนี้ตั้งอยู่บนแนวคิดว่า สิ่งที่ระเบียบต้องปกป้องไม่ใช่การอนุญาตหรือห้ามใช้เครื่องมือ แต่คือสองเรื่อง ได้แก่ เส้นทางที่ข้อมูลไหลออกไปนอกบริษัท และความรับผิดชอบในการตรวจรับผลลัพธ์ที่ AI สร้างขึ้น จากแนวคิดนี้ เราจะไล่อุดช่องโหว่ 4 จุดที่เปิดอยู่ในระเบียบฉบับสำนักงานใหญ่ไปทีละจุด
ทำไมระเบียบการใช้งาน Generative AI จึงกลายเป็นเอกสารที่แจกแล้วจบ
การปรึกษาในทำนองว่า แจกระเบียบไปแล้วแต่หน้างานไม่เปลี่ยน มีเข้ามามากขึ้นเรื่อย ๆ สาเหตุไม่ได้อยู่ที่สำนวนดีหรือไม่ดี แต่อยู่ที่การเขียนออกมาเป็นรายการข้อห้าม ทั้งที่ยังไม่ได้ตกลงกันว่าเอกสารฉบับนี้มีไว้ปกป้องอะไร รายการข้อห้ามดูครอบคลุมดีในสายตาคนเขียน แต่สำหรับคนอ่านแล้วมันคือเอกสารที่ผู้อ่านใช้ตัดสินใจไม่ได้ว่างานที่ตนเองทำอยู่ตรงกับข้อใด และเอกสารที่ผู้อ่านใช้ตัดสินใจไม่ได้ ย่อมหลุดออกจากการปฏิบัติงานจริงตั้งแต่วินาทีที่อ่านจบ
ลำดับของปัญหาที่กลับหัวกลับหาง
ในผลสำรวจแนวโน้มของบริษัทเกี่ยวกับ Generative AI ซึ่งบริษัทวิจัย Teikoku Databank ของญี่ปุ่นจัดทำระหว่างวันที่ 17 มีนาคม ถึง 31 มีนาคม 2026 มีการส่งแบบสำรวจไปยังบริษัททั่วประเทศญี่ปุ่น 23,349 แห่ง และได้รับคำตอบที่ใช้ได้ 10,312 แห่ง คิดเป็นอัตราการตอบกลับ 44.2% บริษัทที่ตอบว่ากำลังใช้งาน Generative AI อยู่มี 34.5% แยกเป็นใช้งานอย่างมาก 4.4% และใช้งานอยู่บ้าง 30.2% เมื่อแยกตามขนาด บริษัทขนาดใหญ่อยู่ที่ 46.5% ธุรกิจขนาดกลางและขนาดย่อมอยู่ที่ 32.4% และธุรกิจรายย่อยอยู่ที่ 28.0%
สิ่งที่ควรจับตาไม่ใช่ตัวเลขอัตราการใช้งาน แต่คือลำดับของปัญหาที่บริษัทเหล่านั้นยกขึ้นมา
| ลำดับ | ปัญหาในการนำ Generative AI ไปใช้ | สัดส่วนผู้ตอบ |
|---|---|---|
| 1 | ความถูกต้องของข้อมูล | 50.4% |
| 2 | ขาดบุคลากรเชี่ยวชาญและองค์ความรู้ | 41.3% |
| 3 | ขอบเขตงานที่ควรนำ Generative AI ไปใช้ | 40.0% |
| 4 | ความเสี่ยงที่ข้อมูลจะรั่วไหล | 33.5% |
| 5 | การวางกฎเรื่องผู้รับผิดชอบเมื่อเกิดปัญหา | 25.5% |
บริษัทที่ยกความเสี่ยงข้อมูลรั่วไหลขึ้นมาเป็นปัญหามีอยู่ 33.5% ขณะที่บริษัทซึ่งยกเรื่องการวางกฎว่าใครรับผิดชอบเมื่อเกิดปัญหา มีเพียง 25.5% ลำดับกลับหัวกลับหางกันอยู่ และนี่คือจุดตั้งต้นของบทความนี้ เหตุผลคือข้อมูลรั่วไหลนั้นอุดได้เป็นส่วนใหญ่ด้วยการควบคุมทางเทคนิค แต่ความรับผิดชอบนั้นการควบคุมทางเทคนิคอุดไม่ได้เลยแม้แต่น้อย ทั้งการตั้งค่าปิดการนำข้อมูลไปฝึกโมเดล และการแยก tenant ล้วนมีผลต่อคำถามที่ว่าข้อมูลที่ป้อนเข้าไปจะไปจบที่ไหน แต่คำถามที่ว่าใครเป็นคนตรวจสอบตัวเลขที่ AI ให้มาแล้วนำไปใช้ในงานจริง ไม่มีอยู่ในหน้าจอตั้งค่าใด ๆ ทั้งสิ้น จุดนี้มีแต่ระเบียบเท่านั้นที่กำหนดได้
นโยบายเดินหน้าไปก่อนเพียงลำพัง
ในสมุดปกขาวด้านสารสนเทศและการสื่อสาร ฉบับปี 2025 ของกระทรวงกิจการภายในและการสื่อสารของประเทศญี่ปุ่น มีผลสำรวจความก้าวหน้าของเทคโนโลยีสารสนเทศและการสื่อสารล่าสุด ซึ่งจัดทำในปี 2025 ระบุว่าบริษัทญี่ปุ่นที่กำหนดนโยบายการใช้ Generative AI ไว้ว่าจะใช้งานเชิงรุก มีสัดส่วน 49.7% ในปีงบประมาณ 2024 เพิ่มขึ้นจาก 42.7% ในปีงบประมาณ 2023 หรือขึ้นมา 7 จุดภายในเวลาหนึ่งปี การที่เกือบครึ่งประกาศว่าจะใช้งานเชิงรุก เมื่อมองกลับด้านก็แปลว่าการประกาศนโยบายวิ่งนำหน้าการออกแบบวิธีปฏิบัติไปแล้ว
ปัญหาคือเอกสารที่ควรมาเติมช่องว่างระหว่างนโยบายกับการปฏิบัติ กลับถูกเขียนออกมาเป็นรายการข้อห้าม บริษัทที่ประกาศว่าจะใช้งานเชิงรุก กลับแจกเอกสารที่เรียงแต่ประโยคว่าห้ามทำสิ่งนี้ลงไปที่หน้างาน และในบริษัทในเครือต่างประเทศ ช่องว่างนี้ยังถ่างออกไปอีกเพราะมีกำแพงภาษาคั่นกลาง
สิ่งที่ระเบียบต้องปกป้องจริง ๆ
สิ่งที่ระเบียบต้องปกป้องย่อลงเหลือสองเรื่องได้ เรื่องแรกคือเส้นทางที่ข้อมูลไหลออกไปนอกบริษัท ข้อมูลประเภทใด ผ่านเส้นทางใด ออกไปได้ถึงระดับใด นี่คือการออกแบบฝั่งขาเข้า และมีผลก่อนเกิดเหตุ อีกเรื่องคือความรับผิดชอบในจังหวะที่ผลลัพธ์ของ AI ถูกนำไปใช้ในงานจริง ใครเป็นคนตรวจสอบ ออกไปข้างนอกในนามของใคร และเมื่อผิดพลาดขึ้นมาจะย้อนกลับไปดูบันทึกชุดใด นี่คือการออกแบบฝั่งขาออก และมีผลหลังเกิดเหตุ
การอนุญาตหรือห้ามใช้เครื่องมือ เป็นเพียงผลลัพธ์ที่อนุมานออกมาจากสองเรื่องนี้ แต่ระเบียบจำนวนมากกลับเขียนโดยเอาการอนุญาตหรือห้ามใช้เครื่องมือมาเป็นตัวตั้ง เมื่อตัวตั้งคือผลลัพธ์ ทุกครั้งที่มีเครื่องมือใหม่ออกมาก็ต้องแก้ไขระเบียบ และช่วงเวลาที่การแก้ไขตามไม่ทันก็จะกลายเป็นช่องว่างทั้งหมด สำหรับวิธีเดินเรื่องการนำไปใช้งานตั้งแต่ต้น เราเขียนไว้แล้วในบทความที่รวบรวมขั้นตอนการนำ Generative AI มาใช้ บทความนี้จึงจำกัดขอบเขตไว้ที่ว่าอะไรคือสิ่งที่ปกป้องบริษัทหลังจากนำมาใช้แล้ว
ช่องโหว่ 4 จุดที่ทำให้ระเบียบฉบับสำนักงานใหญ่ใช้ไม่ได้ในไทย
ระเบียบของสำนักงานใหญ่ที่ญี่ปุ่น เขียนขึ้นบนสมมติฐานว่าใช้กฎหมายญี่ปุ่น เขียนให้พนักงานที่อ่านภาษาญี่ปุ่น และวางอยู่บนสภาพแวดล้อมไอทีที่สำนักงานใหญ่เป็นผู้ดูแล สมมติฐานทั้งสามข้อนี้พังลงพร้อมกันทั้งหมดเมื่อมาถึงบริษัทในเครือที่ประเทศไทย

ผลของการพังนั้นเปิดเป็นช่องโหว่ ซึ่งขอสรุปไว้ก่อนเป็นตาราง หัวข้อถัดจากนี้จะไล่อธิบายทั้ง 4 จุดตามลำดับ
| ช่องโหว่ | เกิดอะไรขึ้น | สิ่งที่ขาดหายไปในฉบับสำนักงานใหญ่ |
|---|---|---|
| ช่องโหว่ที่ 1 เขตอำนาจกฎหมาย | ระเบียบตั้งอยู่บนกฎหมายญี่ปุ่นเพียงอย่างเดียว | การเก็บ log การใช้งานและการแต่งตั้งผู้รับผิดชอบกำกับดูแล ตามที่ร่างกฎหมาย AI ของไทยกำหนดให้ผู้นำไปใช้งานต้องทำ |
| ช่องโหว่ที่ 2 ภาษา | ระเบียบยังเป็นภาษาญี่ปุ่น หรือแปลมาเฉพาะส่วนข้อห้าม | ข้อความที่พนักงานท้องถิ่นเอางานของตนเองไปเทียบแล้วตัดสินใจได้ |
| ช่องโหว่ที่ 3 เส้นทาง | เขียนเป็นรายการเครื่องมือที่อนุญาตกับที่ห้าม | การสำรวจตัวเส้นทางที่ข้อมูลไหลออกนอกบริษัท |
| ช่องโหว่ที่ 4 ความรับผิดชอบ | ไม่มีการกำหนดว่าจะจัดการอย่างไรเมื่อผลลัพธ์ที่ผิดของ AI ไปถึงมือลูกค้า | ผู้ตรวจรับผลลัพธ์ และบันทึกการตรวจรับ |
ทั้ง 4 จุดนี้ไม่ใช่ข้อบกพร่องที่แยกขาดจากกัน แต่ล้วนมีสาเหตุร่วมกันเพียงข้อเดียว คือระเบียบสมมติว่าผู้อ่านเป็นคนที่อยู่ในสภาพแวดล้อมของสำนักงานใหญ่ ใช้ภาษาของสำนักงานใหญ่ อยู่ใต้กฎหมายที่สำนักงานใหญ่รู้จัก และใช้เครื่องมือที่สำนักงานใหญ่รู้จัก บริษัทในเครือต่างประเทศหลุดออกจากสมมติฐานเหล่านี้ทั้งหมด ช่องโหว่จึงเปิดขึ้นพร้อมกัน 4 จุด
ช่องโหว่สร้างระเบียบที่ต่อให้ทำตามก็ยังไม่พอ
เรื่องนี้เข้าใจผิดกันง่าย จึงขอเขียนไว้ก่อน ช่องโหว่ทั้ง 4 จุดไม่ใช่เรื่องที่พนักงานท้องถิ่นฝ่าฝืนระเบียบ แต่เป็นเรื่องที่ต่อให้ทำตามระเบียบครบถ้วนทุกข้อ บริษัทก็ยังไม่ได้รับการปกป้อง
สมมติว่าฉบับสำนักงานใหญ่เขียนว่าห้ามใช้ Generative AI แบบไม่เสียค่าใช้จ่ายในงานของบริษัท และพนักงานท้องถิ่นทำตามอย่างซื่อสัตย์ คนคนนั้นอาจหันไปใช้ส่วนขยายแปลภาษาบนเบราว์เซอร์เพื่อแปลใบเสนอราคาภายในบริษัทแทน ในเมื่อระเบียบไม่ได้เขียนถึงส่วนขยายแปลภาษา จึงไม่ถือว่าฝ่าฝืน แต่ข้อมูลออกไปนอกบริษัทเรียบร้อยแล้ว นี่คือช่องโหว่ที่ 3 เรื่องเส้นทาง
เรื่องเดียวกันเกิดกับช่องโหว่ที่ 4 ด้วย สมมติว่าพนักงานทำตามข้อกำหนดที่ว่าห้ามนำผลลัพธ์ไปใช้ตรง ๆ โดยอ่านและแก้ไขด้วยตนเองก่อนส่งให้ลูกค้า แต่บันทึกที่ระบุว่าได้อ่านและแก้ไขแล้วนั้นไม่มีอยู่ที่ใดเลย เมื่อผ่านไปครึ่งปีแล้วมีการทักท้วงเข้ามา สิ่งที่บริษัทหยิบมาแสดงได้มีเพียงตัวบทของระเบียบ ระเบียบถูกปฏิบัติตามแล้ว แต่ความรับผิดชอบยังว่างเปล่าอยู่เหมือนเดิม
บริษัทในเครือแก้ไขระเบียบของสำนักงานใหญ่ไม่ได้
บริษัทลูกของบริษัทญี่ปุ่นจำนวนมากไม่มีอำนาจแก้ไขระเบียบระดับกลุ่มบริษัทที่สำนักงานใหญ่กำหนดไว้ ดังนั้นถึงจะรู้ตัวว่ามีช่องโหว่ สิ่งที่ทำได้ในพื้นที่ก็มีเพียงการจัดทำเอกสารเสริมขึ้นมาอีกฉบับ แต่นี่ก็เป็นแนวทางออกแบบที่สมจริงอยู่แล้ว ไม่ต้องรอให้ฉบับสำนักงานใหญ่ถูกรื้อทั้งฉบับ ให้คงฉบับสำนักงานใหญ่ไว้เป็นระเบียบระดับบน แล้วเติมแนวปฏิบัติของบริษัทในไทยเพิ่มอีกหนึ่งแผ่น ซึ่งกำหนด 4 หัวข้อที่ฉบับสำนักงานใหญ่ไม่ได้แตะไว้
| บท | สิ่งที่ต้องกำหนด | ตรงกับช่องโหว่ |
|---|---|---|
| บทที่ 1 การจัดประเภทข้อมูล | แบ่งข้อมูลที่บริษัทในไทยใช้งานออกเป็น 4 ประเภท และกำหนดว่าประเภทใดป้อนเข้า Generative AI ได้ | เป็นฐานของช่องโหว่ที่ 3 และ 4 |
| บทที่ 2 การออกแบบเส้นทางที่อนุญาต | แจกแจงเส้นทางที่ข้อมูลออกไปนอกบริษัท แล้วกำหนดว่าเส้นทางใดอนุญาต เส้นทางใดต้องปิด | ช่องโหว่ที่ 3 |
| บทที่ 3 ความรับผิดชอบในการตรวจรับผลลัพธ์ | กำหนดขั้นตอนการนำผลลัพธ์ของ AI ไปใช้ในงาน และวิธีเก็บบันทึกการตรวจรับ | ช่องโหว่ที่ 4 |
| บทที่ 4 log และโครงสร้างการกำกับดูแล | กำหนดขอบเขตและระยะเวลาเก็บ log ผู้รับผิดชอบกำกับดูแล และช่องทางรับเรื่องเมื่อหน่วยงานรัฐสอบถาม | ช่องโหว่ที่ 1 |
ทั้ง 4 บทนี้ตรงกับหน้าที่ซึ่งร่างกฎหมาย AI ของไทยกำลังจะกำหนดให้ผู้นำไปใช้งานต้องปฏิบัติ ตามที่จะอธิบายต่อไป ดังนั้นต่อให้กฎหมายผ่านออกมา ก็ไม่ต้องเขียนใหม่ ในทางกลับกัน ระเบียบที่ไปหยิบตัวบทสำเร็จรูปจากที่ใดที่หนึ่งมาเรียงต่อกัน มักต้องทำใหม่ทั้งชุดเมื่อเนื้อหาของกฎหมายนิ่งแล้ว สิ่งที่ต้องกำหนดก่อนลงมือเขียนระเบียบจึงไม่ใช่ตัวบท แต่คือเนื้อหาของ 4 บทนี้
ช่องโหว่ที่ 1 เขตอำนาจกฎหมาย ร่างกฎหมาย AI ของไทยกำหนดหน้าที่ให้ฝ่ายผู้ใช้
ขอทำความเข้าใจข้อเท็จจริงให้ตรงกันก่อน ร่างพระราชบัญญัติว่าด้วยปัญญาประดิษฐ์ของประเทศไทย (Draft Act on Artificial Intelligence) ณ วันที่เขียนบทความนี้คือ 7 สิงหาคม 2026 ยังไม่มีผลบังคับใช้ มีบทความบางฉบับเขียนว่าบังคับใช้แล้ว แต่คำอธิบายจากสำนักงานกฎหมายหลายแห่งล้วนกล่าวถึงเอกสารฉบับนี้ในฐานะร่าง (draft) ทั้งสิ้น สันนิษฐานว่าเกิดจากการสับสนกับวันที่กฎหมาย AI ของเวียดนามมีผลบังคับใช้ ซึ่งจะกล่าวถึงในหัวข้อถัดไป สำหรับประเทศไทย คำอธิบายที่ถูกต้องคือร่างกฎหมายเผยแพร่ออกมาแล้วและปิดรับฟังความคิดเห็นไปแล้ว
หน่วยงานที่รับผิดชอบคือสำนักงานพัฒนาธุรกรรมทางอิเล็กทรอนิกส์ (ETDA) ซึ่งเผยแพร่ร่างฉบับใหม่เมื่อวันที่ 2 กรกฎาคม 2026 และเปิดรับฟังความคิดเห็นสาธารณะเป็นเวลาประมาณ 30 วัน ช่วงเวลารับฟังความคิดเห็นคาดว่าปิดลงในช่วงต้นเดือนสิงหาคม 2026
อย่างไรก็ตาม การที่ยังไม่มีผลบังคับใช้ไม่ใช่เหตุผลที่จะเลื่อนการจัดทำระเบียบออกไป เพราะโครงสร้างของหน้าที่ซึ่งร่างกฎหมายวางไว้เป็นคนละชนิดกับสิ่งที่ระเบียบของญี่ปุ่นมีอยู่แต่เดิม ระยะผ่อนผันหลังกฎหมายผ่านก็สั้น และสิ่งที่ร่างกฎหมายเรียกร้องส่วนใหญ่ก็สมเหตุสมผลในฐานะการควบคุมภายในองค์กรอยู่แล้ว แม้ไม่มีกฎหมายก็ตาม
การแบ่งความเสี่ยงออกเป็น 3 ประเภทในร่างกฎหมาย
ร่างกฎหมายแบ่งระบบ AI ออกเป็น 3 ประเภท
| ประเภท | สถานะ | ความหมายสำหรับบริษัททั่วไป |
|---|---|---|
| Prohibited AI | AI ที่ใช้ในวัตถุประสงค์ต้องห้าม | วัตถุประสงค์ที่เข้าข่ายนี้ ห้ามทั้งพัฒนา ให้บริการ และนำไปใช้ |
| High-Risk AI | AI ที่เข้าข่ายความเสี่ยงสูง | มีหน้าที่บริหารจัดการเพิ่มเติม รวมถึงธรรมาภิบาลข้อมูลที่สอดคล้องกับพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล (PDPA) |
| Designated AI | ประเภทที่จะถูกกำหนดโดยพระราชกฤษฎีกาในอนาคต | อาจกลายเป็นสิ่งที่ต้องแจ้ง ต้องขึ้นทะเบียน หรือต้องขออนุญาต ตามที่พระราชกฤษฎีกากำหนด |
ประเภท Designated AI มีน้ำหนักเป็นพิเศษในทางปฏิบัติ เพราะแม้วันนี้จะยังไม่เข้าข่าย แต่พระราชกฤษฎีกาฉบับเดียวก็อาจทำให้ต้องแจ้งหรือขึ้นทะเบียนได้ ถ้าไม่เตรียมไว้ล่วงหน้าว่าเมื่อเข้าข่ายแล้วจะยื่นอะไรได้บ้าง ก็จะต้องมาเร่งสร้างบันทึกกันในวันที่ถูกกำหนดพอดี
ทั้งนี้ ร่างกฎหมายยังมีบทบัญญัติเรื่องการบังคับใช้นอกราชอาณาจักรด้วย การพัฒนา การให้บริการ และการนำ AI ไปใช้ที่ส่งผลกระทบต่อบุคคลในประเทศไทย เข้าข่ายแม้การกระทำนั้นจะเกิดขึ้นนอกประเทศ หากระบบที่รันอยู่บนเซิร์ฟเวอร์ของสำนักงานใหญ่ในญี่ปุ่นส่งผลต่อพนักงานหรือลูกค้าในประเทศไทย การอ้างว่าระบบอยู่ในญี่ปุ่นเพียงอย่างเดียวไม่ทำให้หลุดจากขอบเขต สำหรับสภาพแวดล้อมด้านกฎระเบียบของประเทศไทยและสถานะการเป็นศูนย์กลางของภูมิภาค เราเรียบเรียงไว้ในบทความที่สรุปการใช้ AI และสภาพแวดล้อมด้านกฎระเบียบของไทย ด้วยเช่นกัน
หน้าที่ของผู้นำไปใช้งาน จุดที่ระเบียบของญี่ปุ่นไม่มี
สิ่งที่ส่งผลโดยตรงกับบริษัททั่วไปคือหน้าที่ของผู้นำไปใช้งาน ซึ่งหมายถึงฝ่ายที่นำ AI ไปใช้ ประเด็นสำคัญคือผู้ที่ถูกระบุชื่อให้มีหน้าที่ ไม่ใช่บริษัทที่พัฒนา AI แต่เป็นบริษัททั่วไปที่ซื้อมาใช้งาน
| หน้าที่ของผู้นำไปใช้งาน | เมื่อแปลงลงเป็นระเบียบต้องเขียนอะไร |
|---|---|
| ดำเนินระบบบริหารความเสี่ยง | การประเมินความเสี่ยงรายวัตถุประสงค์ และความถี่ในการทบทวนผลประเมิน |
| ปฏิบัติตามคำสั่งและข้อกำหนดของผู้ให้บริการ | ผู้รับผิดชอบและขั้นตอนในการกระจายเงื่อนไขการใช้งานและวัตถุประสงค์ต้องห้ามเข้าสู่องค์กร |
| แต่งตั้งผู้ที่สามารถกำกับดูแลได้ | ตำแหน่งงาน ชื่อ และขั้นตอนส่งมอบงานเมื่อเปลี่ยนตัวผู้รับผิดชอบกำกับดูแล |
| เก็บ log การใช้งานไว้อย่างน้อย 6 เดือน | จะนับอะไรเป็น log สถานที่จัดเก็บ ระยะเวลาเก็บ และวิธีปฏิบัติในการลบ |
| แจ้งหน่วยงานรัฐเมื่อพบความเสี่ยงที่ไม่ได้คาดการณ์ไว้ | ช่องทางที่ระบุว่าใครเป็นผู้ตัดสิน และแจ้งในนามของใคร |
ลองเปิดระเบียบของสำนักงานใหญ่ขึ้นมาแล้วตรวจดูว่ามีข้อกำหนดที่รองรับทั้ง 5 ข้อนี้หรือไม่ ส่วนใหญ่แล้วสิ่งที่มีคือประโยคเดียวที่ใกล้เคียงกับคำว่าให้ปฏิบัติตามข้อตกลงการใช้บริการของผู้ให้บริการ ไม่มีทั้งการแต่งตั้งผู้รับผิดชอบกำกับดูแล ไม่มีทั้งระยะเวลาเก็บ log และไม่มีช่องทางแจ้งหน่วยงานรัฐ เหตุผลนั้นง่ายมาก เพราะกฎหมายปัจจุบันของญี่ปุ่นไม่ได้เรียกร้องสิ่งเหล่านี้ อะไรที่กฎหมายไม่ได้กำหนดก็จะไม่ถูกเขียนลงในระเบียบ นี่คือช่องโหว่เรื่องเขตอำนาจกฎหมาย
น้ำหนักของข้อกำหนดที่ให้เก็บ log 6 เดือน
ในบรรดา 5 ข้อ ข้อที่ใช้เวลาเตรียมนานที่สุดคือการเก็บ log การใช้งานไว้ 6 เดือน เพราะเป็นข้อเดียวที่ย้อนหลังไปสร้างขึ้นมาทีหลังไม่ได้ การแต่งตั้งผู้รับผิดชอบกำกับดูแลจะทำพรุ่งนี้ก็ยังทัน การประเมินความเสี่ยงจะเขียนสัปดาห์นี้ก็ยังทัน แต่ log ไม่มีทางมีอยู่ก่อนวันที่เริ่มเก็บ
และตราบใดที่ยังใช้ Generative AI แบบไม่เสียค่าใช้จ่ายผ่านบัญชีส่วนตัว บริษัทย่อมเก็บ log ไม่ได้ในเชิงโครงสร้าง เพราะบันทึกว่าใครป้อนอะไรเข้าไปเมื่อใดไม่ได้อยู่ใต้การดูแลของบริษัท เพียงจุดเดียวนี้ก็ทำให้เห็นแล้วว่าการปล่อยให้ใช้บริการฟรีโดยไม่ห้ามและไม่อนุญาต เป็นโครงสร้างที่ตอบหน้าที่ของผู้นำไปใช้งานไม่ได้
บทลงโทษและลำดับการบังคับใช้
ร่างกฎหมายกำหนดค่าปรับทางปกครองไว้ที่ 1,000,000 ถึง 5,000,000 บาท ต่อการฝ่าฝืนหนึ่งครั้ง และยังกำหนดความเป็นไปได้ของคำสั่งระงับการให้บริการและคำสั่งให้ผู้ให้บริการอินเทอร์เน็ตปิดกั้นการเข้าถึงด้วย สิ่งที่ควรสนใจมากกว่าตัวเลขค่าปรับคือหน่วยนับที่ว่าต่อการฝ่าฝืนหนึ่งครั้ง หากพบข้อบกพร่องชนิดเดียวกันในหลายวัตถุประสงค์การใช้งาน แต่ละรายการก็อาจถูกนับเป็นการฝ่าฝืนแยกกัน
การบังคับใช้แบ่งเป็น 2 ขั้น บทบัญญัติที่เป็นแกนกลางมีผลทันทีเมื่อประกาศในราชกิจจานุเบกษา ส่วนบทบัญญัติเรื่องการบริหารความเสี่ยงและการกำกับดูแลมีผลเมื่อพ้น 180 วัน ตัวเลข 180 วันดูเหมือนยาว แต่ความหมายจะเปลี่ยนไปทันทีเมื่อนำมารวมกับหน้าที่เก็บ log ไว้ 6 เดือน การจะมี log ครบ 6 เดือน ณ วันที่บทบัญญัติมีผล แปลว่าต้องเริ่มเก็บตั้งแต่ 6 เดือนก่อนหน้านั้น พูดอีกอย่างคือ 180 วันนี้มีความยาวพอดีกับการเริ่มเก็บ log ในวันแรกของระยะผ่อนผัน และหากเริ่มออกแบบหลังกฎหมายผ่านแล้วจะไม่ทัน
นอกจากนี้ ร่างกฎหมายยังมีบทบัญญัติให้จัดตั้ง AI Governance Center ภายใต้ ETDA และระบุความสัมพันธ์กับพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล (PDPA) ไว้ชัดเจน หากแยกระเบียบเรื่อง Generative AI ออกจากการปฏิบัติตาม PDPA จะกลายเป็นการบริหารซ้ำซ้อนและทำต่อไม่ไหว จึงควรออกแบบให้วางทับอยู่บนแนวปฏิบัติ PDPA ที่มีอยู่เดิม
ช่องโหว่ที่ 1 ตอนต่อ กฎหมาย AI ของเวียดนามมีผลบังคับใช้ไปแล้ว
ต่างจากไทยที่ยังไม่มีผลบังคับใช้ กฎหมาย AI ของเวียดนาม (Law on Artificial Intelligence) ผ่านออกมาและมีผลบังคับใช้แล้ว หากสับสนสองเรื่องนี้ จะทำให้กำหนดขอบเขตการบังคับใช้ของระเบียบผิดไปทั้งฉบับ
กฎหมาย AI ของเวียดนามมีเลขที่ No.134/2025/QH15 ผ่านเมื่อวันที่ 10 ธันวาคม 2025 และมีผลบังคับใช้ตั้งแต่วันที่ 1 มีนาคม 2026 ใช้บังคับทั้งกับผู้ประกอบการในประเทศและผู้ประกอบการต่างชาติ โดยมีระยะผ่อนผันให้กับระบบที่มีอยู่เดิม
| กลุ่มเป้าหมาย | เส้นตายของระยะผ่อนผัน |
|---|---|
| ระบบ AI เดิมโดยทั่วไป | 1 มีนาคม 2027 |
| ระบบ AI ในสาขาการแพทย์ การศึกษา และการเงิน | 1 กันยายน 2027 |
เมื่อมองจากบริษัทแม่ในญี่ปุ่น การอ่านที่ถูกต้องคือ chatbot หรือกลไกสร้างเอกสารที่เดินอยู่แล้วในฐานปฏิบัติงานที่เวียดนาม จำเป็นต้องปรับให้เข้ากับข้อกำหนดของกฎหมายภายในวันที่ 1 มีนาคม 2027 หากเป็นวัตถุประสงค์ที่เกี่ยวข้องกับการแพทย์ การศึกษา หรือการเงิน ก็ขยายไปได้ถึงวันที่ 1 กันยายน 2027 ไม่ว่าทางใดเวลาที่เหลือก็ไม่ยาวนัก
หน้าที่ด้านความโปร่งใสของผู้ให้บริการกับผู้นำไปใช้งานไม่เหมือนกัน
สิ่งที่ส่งผลก่อนในทางปฏิบัติคือหน้าที่ด้านความโปร่งใส ซึ่งมีเนื้อหาต่างกันระหว่างฝ่ายที่ให้บริการกับฝ่ายที่นำไปใช้
| สถานะ | เนื้อหาของหน้าที่ด้านความโปร่งใส |
|---|---|
| ผู้ให้บริการ (provider) | ติดเครื่องหมายกำกับเสียง ภาพ และวิดีโอที่ AI สร้างขึ้น ในรูปแบบที่เครื่องอ่านได้ |
| ผู้นำไปใช้งาน (deployer) | ระบุให้ชัดว่าเป็นสิ่งที่ AI สร้างขึ้น ในกรณีที่อาจทำให้เกิดความสับสนเกี่ยวกับความแท้จริงของเหตุการณ์หรือบุคคล |
โดยปกติบริษัททั่วไปจะอยู่ในฐานะผู้นำไปใช้งาน หน้าที่ที่ได้รับไม่ใช่การฝังเครื่องหมายที่เครื่องอ่านได้ด้วยตนเอง แต่คือการระบุให้ชัดเมื่ออาจทำให้เข้าใจผิด ดังนั้นถ้าไม่เขียนเป็นเกณฑ์การตัดสินภายในองค์กร แต่ไปเขียนเป็นการตั้งค่าเครื่องมือ ก็จะใช้งานจริงไม่ได้ จำเป็นต้องยกตัวอย่างให้เห็นภาพว่าอะไรถือว่าอาจทำให้เกิดความสับสน โดยอิงกับงานจริงของบริษัทในพื้นที่ เช่น การสร้างภาพสินค้า ภาพบุคคลในวารสารภายในองค์กร และเสียงบรรยายในวิดีโออธิบายสำหรับลูกค้า จุดเหล่านี้คือสถานการณ์ที่ต้องใช้การตัดสินใจ ทั้งนี้ กฎหมายฉบับเดียวกันนี้ยังกำหนดกลไก sandbox และสิทธิ์เข้าถึงโครงสร้างพื้นฐาน AI ของประเทศก่อนรายอื่นไว้ด้วย
วางสองประเทศคู่กันแล้วแนวทางออกแบบระเบียบจะชัดขึ้น
ไทยยังไม่มีผลบังคับใช้ เวียดนามบังคับใช้แล้ว ความไม่สมมาตรนี้ส่งผลโดยตรงต่อวิธีเขียนระเบียบ เพราะถ้าแยกเขียนตัวบทตามเขตอำนาจกฎหมายแต่ละแห่ง ทุกครั้งที่ฝ่ายใดฝ่ายหนึ่งขยับ ก็ต้องแก้ไขทั้งฉบับ
แทนที่จะทำเช่นนั้น ให้แยกส่วนที่ใช้ร่วมกันออกจากส่วนที่ขึ้นกับเขตอำนาจกฎหมาย ส่วนที่ใช้ร่วมกันคือ 4 บท ได้แก่ การจัดประเภทข้อมูล การออกแบบเส้นทางที่อนุญาต ความรับผิดชอบในการตรวจรับผลลัพธ์ และ log กับโครงสร้างการกำกับดูแล ส่วนที่ขึ้นกับเขตอำนาจกฎหมายให้เหลือเฉพาะตัวเลขและชื่อเฉพาะ เช่น ระยะเวลาเก็บขั้นต่ำ ชื่อหน่วยงานรัฐที่ต้องแจ้ง และถ้อยคำที่ต้องแสดงให้ชัด การแบ่งแบบนี้ทำให้เมื่อกฎหมาย AI ของไทยผ่านออกมา สิ่งที่ต้องแก้มีเพียงไม่กี่บรรทัด ระเบียบของบริษัทที่มีฐานปฏิบัติงานในต่างประเทศ ควรใส่ความง่ายในการแก้ไขเข้าไปเป็นข้อกำหนดของการออกแบบตั้งแต่แรก
ช่องโหว่ที่ 2 ภาษา ไม่ใช่การแปล แต่คือการทำใหม่ให้ตัดสินใจได้
หลายบริษัทคิดว่าแปลฉบับสำนักงานใหญ่เป็นภาษาไทยแล้วก็ถือว่าจบเรื่องการขยายผลไปยังพื้นที่ แต่ต่อให้แปลแล้วก็ยังลงสู่การปฏิบัติไม่ได้ เหตุผลไม่ได้อยู่ที่คุณภาพของการแปล แต่อยู่ที่วิธีเขียนของต้นฉบับ
ระเบียบภาษาญี่ปุ่นมักลงท้ายประโยคด้วยรูปที่แปลว่าห้ามกระทำ ถ้าแปลอย่างซื่อตรง ภาษาไทยก็จะกลายเป็นรายการข้อห้ามเช่นกัน สิ่งที่เหลืออยู่ในมือพนักงานท้องถิ่นที่อ่านจบคือรายชื่อพฤติกรรมที่ถูกห้ามเท่านั้น แต่สิ่งที่หน้างานต้องการคือด้านตรงข้าม นั่นคือคำตอบว่าเมื่อทำงานชิ้นนี้ จะป้อนข้อมูลระดับใดเข้าเครื่องมือใดได้บ้าง ดังนั้นก่อนจะแปล ต้องเขียนต้นฉบับใหม่โดยเปลี่ยนตัวตั้งจากพฤติกรรม ไปเป็นประเภทของข้อมูลที่กำลังใช้งาน เมื่อตัวตั้งเป็นข้อมูลแล้ว ต่อให้เครื่องมือเปลี่ยนหรืองานเปลี่ยน วิธีตัดสินใจก็ยังคงเดิม
จุดที่พังเมื่อแปล
เมื่อลองนำระเบียบภาษาญี่ปุ่นไปทำเป็นภาษาไทยหรือภาษาเวียดนามจริง จะพบว่าสำนวนที่รักษาความหมายไว้ไม่ได้นั้นมีรูปแบบซ้ำ ๆ
| สำนวนที่พังง่าย | ทำไมจึงพัง | วิธีเขียนใหม่ |
|---|---|---|
| ข้อมูลลับ หรือ ข้อมูลสำคัญ | ไม่ได้ให้คำนิยาม ขอบเขตจึงเปลี่ยนไปตามผู้อ่านแต่ละคน | นิยามชื่อประเภทให้ชัด และแนบตัวอย่างรูปธรรมอย่างน้อย 3 รายการ |
| ขออนุมัติจากผู้บังคับบัญชาตามความจำเป็น | ไม่รู้ว่าใครเป็นผู้ตัดสิน ในทางปฏิบัติการอนุมัติจะถูกข้ามไป | เขียนเป็นเงื่อนไขว่าข้อมูลประเภทใดจึงต้องขออนุมัติ |
| บริหารจัดการอย่างเหมาะสม | ระบุพฤติกรรมไม่ได้ และตรวจสอบในการ audit ก็ไม่ได้ | เขียนสถานที่จัดเก็บและระยะเวลาเก็บออกมาเป็นตัวเลข |
| โดยหลักการแล้วห้ามกระทำ | ไม่มีทั้งที่ยื่นขอข้อยกเว้นและเกณฑ์ตัดสิน เหลือแต่หลักการลอย ๆ | ระบุเงื่อนไขที่ยอมรับข้อยกเว้นและหน่วยงานที่รับคำขอให้ชัด |
| ใช้งานภายในขอบเขตที่จำเป็นต่อการทำงาน | อำนาจกำหนดขอบเขตตกไปอยู่ที่ตัวบุคคล | แจกแจงวัตถุประสงค์ออกมา และกำหนดว่านอกเหนือจากที่แจกแจงต้องสอบถามก่อน |
ทั้ง 5 สำนวนนี้ ตอนอ่านเป็นภาษาญี่ปุ่นจะไม่รู้สึกว่ากำกวมนัก เพราะผู้อ่านช่วยเติมความหมายจากบริบทให้เอง พอแปลแล้วช่องว่างสำหรับการเติมนั้นหายไป เหลือเป็นเอกสารที่ความกำกวมยังอยู่ครบถ้วน
ตัดสินใจก่อนว่าจะใช้ภาษาใดในการปฏิบัติงาน
ในบริษัทในเครือที่ประเทศไทย ระเบียบต้องเดินทางไปมาระหว่าง 3 ภาษา สำนักงานใหญ่เขียนเป็นภาษาญี่ปุ่น พนักงานญี่ปุ่นที่ประจำการในไทยอ่านเป็นภาษาอังกฤษ และพนักงานไทยนำไปปฏิบัติเป็นภาษาไทย สิ่งที่ต้องตัดสินใจคือฉบับใดเป็นฉบับหลัก ถ้าคงให้ฉบับภาษาญี่ปุ่นเป็นฉบับหลัก ฉบับภาษาไทยก็จะเป็นเพียงคำแปลอ้างอิง แต่พนักงานไทยส่วนใหญ่ไม่ได้อ่านภาษาญี่ปุ่น การตัดสินใจจริงจึงเกิดขึ้นบนฉบับภาษาไทยอยู่ดี
จุดลงตัวที่สมจริงคือโครงสร้าง 2 ชั้น โดยให้เอกสารนโยบายระดับบนใช้ฉบับภาษาญี่ปุ่นของสำนักงานใหญ่เป็นฉบับหลัก ส่วนแนวปฏิบัติของบริษัทในไทยใช้ฉบับภาษาไทยเป็นฉบับหลัก สิ่งที่ต้องใส่ไว้ในแนวปฏิบัติมีเพียง 4 เรื่อง คือ การจัดประเภทข้อมูล เส้นทางที่อนุญาต ขั้นตอนการตรวจรับ และวิธีเก็บบันทึก ถ้า 4 เรื่องนี้อ่านเป็นภาษาไทยได้ การปฏิบัติงานก็เดินได้
เงื่อนไขตั้งต้นกำลังเปลี่ยน เพราะโมเดลที่รองรับภาษาไทยมีมากขึ้น
มีระเบียบบางฉบับที่ตั้งสมมติฐานเงียบ ๆ ว่าจะใช้งานเป็นภาษาอังกฤษ แต่สมมติฐานนั้นก็กำลังพังลงเช่นกัน
ในประเทศไทยมีโครงการชื่อ ThaiLLM ที่พัฒนาโมเดลพื้นฐานสำหรับภาษาไทย โดยมีสำนักงานพัฒนาวิทยาศาสตร์และเทคโนโลยีแห่งชาติ (NSTDA) กระทรวงการอุดมศึกษา วิทยาศาสตร์ วิจัยและนวัตกรรม และ NECTEC เป็นแกนหลัก งบประมาณอยู่ที่ 80 ล้านบาท ขนาดโมเดลมี 2 แบบคือ 8 พันล้านพารามิเตอร์ และ 30 พันล้านพารามิเตอร์ ฝึกด้วยข้อมูลขนาดเกิน 100,000 ล้านโทเค็น โดยมีโมเดลย่อย 4 ตัวอยู่ในโครงการ ได้แก่ OpenThaiGPT จาก AIEAT, Pathumma จาก NECTEC, Typhoon-S จาก SCB 10X และ THaLLE จาก KBTG ซึ่ง KBTG, SCB 10X และ VISTEC ได้เริ่มนำไปใช้งานแล้ว วัตถุประสงค์การใช้งานก็ไม่ได้หยุดอยู่ที่ chatbot แต่คาดหมายไปถึงการใช้งานแบบ agent เช่น งานอัตโนมัติ การสนับสนุนการตัดสินใจ การเชื่อมต่อกับระบบภายในองค์กร และบริการที่ติดต่อกับลูกค้าโดยตรง
ความหมายต่อระเบียบนั้นชัดเจน ตัวเลือกที่จะใช้ Generative AI ในงานเป็นภาษาไทยตรง ๆ กลายเป็นเรื่องจริงขึ้นมาแล้ว เดิมทีต้องมีขั้นตอนแปลเป็นภาษาอังกฤษก่อนป้อนเข้าไป และขั้นตอนนั้นเองที่ช่วยยับยั้งการนำข้อมูลออกไปโดยไม่ตั้งใจ เมื่อป้อนเป็นภาษาไทยได้เลย แรงยับยั้งนั้นก็หายไป ระเบียบที่ตั้งอยู่บนสมมติฐานว่าใช้ภาษาอังกฤษ จะทำให้การใช้งานเป็นภาษาไทยเกิดขึ้นนอกกรอบของระเบียบ
การอุดช่องโหว่ด้านภาษาจึงไม่ใช่การเพิ่มความแม่นยำของการแปล แต่คือการกำหนดว่าใครตัดสินใจด้วยภาษาใด แล้วใส่ข้อมูลลงในระเบียบให้มากพอที่จะตัดสินใจด้วยภาษานั้นได้
ช่องโหว่ที่ 3 เส้นทาง จากแบบแจกแจงเครื่องมือ ไปสู่แบบเส้นทางข้อมูล
วิธีเขียนระเบียบการใช้งาน Generative AI ที่พบมากที่สุดคือการทำรายการเครื่องมือที่อนุญาตกับเครื่องมือที่ห้าม ฝ่ายบริหารจัดการเข้าใจง่าย แต่วิธีเขียนแบบนี้จับเส้นทางที่ข้อมูลไหลออกนอกบริษัทไม่ได้

ลองดูว่าการเขียนด้วยชื่อเครื่องมือทำให้อะไรหลุดไปบ้าง โดยวางคู่กับเส้นทางที่เกิดขึ้นจริงในบริษัทในเครือ
| เส้นทาง | อะไรออกไป | รายการเครื่องมือจับได้หรือไม่ |
|---|---|---|
| ใช้งานผ่านบัญชีส่วนตัวจากเบราว์เซอร์บนเครื่องส่วนตัว | เนื้อหาทั้งหมดของเอกสารที่ป้อนเข้าไป | จับไม่ได้ เพราะเครื่องอยู่นอกการดูแลของบริษัท |
| วางข้อความลงในเว็บแปลภาษาแบบไม่เสียค่าใช้จ่าย | เนื้อหาทั้งหมดของสัญญาและเอกสารข้อกำหนด | จับไม่ได้ เพราะไม่ถูกรับรู้ว่าเป็น Generative AI |
| ฟังก์ชัน AI ในแอปแชท | ประวัติการสนทนาและไฟล์แนบ | จับไม่ได้ เพราะอนุญาตไว้แล้วในฐานะช่องทางติดต่อสื่อสาร |
| ส่วนขยายบนเบราว์เซอร์ | เนื้อหาของหน้าจอที่กำลังเปิดอยู่ | จับไม่ได้ เพราะการติดตั้งเป็นดุลพินิจของแต่ละคน |
| แอปถอดเสียงการประชุมอัตโนมัติ | เสียงของการประชุมและชื่อผู้เข้าร่วม | จับไม่ได้ เพราะเป็นฟังก์ชันหนึ่งของเครื่องมือประชุม |
| การตั้งค่าที่ยังเปิดให้นำข้อมูลไปฝึกโมเดล | ข้อมูลทั้งหมดที่ป้อนเข้าไป | จับไม่ได้ เพราะตัวเครื่องมือได้รับอนุญาตอยู่แล้ว |
ในบรรดา 6 เส้นทางนี้ สิ่งที่รายการอนุญาตและห้ามตามชื่อเครื่องมือรับมือได้ แทบจะเป็นศูนย์ เหตุผลร่วมกันคือทุกเส้นทางล้วนไม่ทำให้ผู้ใช้รู้สึกว่ากำลังใช้บริการ Generative AI อยู่ คนที่วางข้อความลงในเว็บแปลภาษาไม่ได้คิดว่าตนเองกำลังใช้ Generative AI และพฤติกรรมที่ไม่ได้ถูกรับรู้ ย่อมหยุดไม่ได้ด้วยกฎที่ตั้งอยู่บนการรับรู้ ยิ่งไปกว่านั้น ยิ่งแจกแจงเครื่องมือที่ห้ามมากเท่าไร Shadow AI ก็ยิ่งเพิ่มขึ้น เพราะผู้ใช้เพียงหลบชื่อที่ถูกห้ามแล้วย้ายไปใช้บริการที่ชื่ออื่น การแจกแจงยังสอนวิธีอ่านว่าถ้าไม่มีอยู่ในรายการก็แปลว่าใช้ได้
เขียนด้วยเส้นทางแล้วอะไรเปลี่ยนไป
ให้ใช้ตัวเส้นทางที่ข้อมูลไหลออกนอกบริษัทเป็นตัวตั้ง แทนที่จะใช้ชื่อเครื่องมือ สิ่งที่ต้องเขียนลงในระเบียบมี 3 ข้อ ข้อแรกคือคำนิยามของเส้นทางที่ได้รับอนุญาต โดยนิยามจากการประกอบกันของเงื่อนไข เช่น ส่งจากเครื่องที่บริษัทดูแล ด้วยบัญชีที่บริษัทดูแล ไปยังบริการที่มีสัญญายกเว้นการนำข้อมูลไปฝึกโมเดล ข้อที่สองคือหลักการว่าจะไม่นำข้อมูลออกไปทางอื่นนอกจากเส้นทางที่ได้รับอนุญาต ข้อที่สามคือหน่วยงานที่รับคำขอและเกณฑ์ตัดสิน เมื่อต้องการเพิ่มเส้นทางใหม่
วิธีเขียนแบบนี้ทำให้ไม่ต้องแก้ไขระเบียบเมื่อมีบริการใหม่ออกมา เพราะเพียงข้อเท็จจริงที่ว่ายังไม่ได้อยู่ในเส้นทางที่อนุญาต ก็กำหนดวิธีปฏิบัติได้แล้ว การแก้ไขจะจำเป็นก็ต่อเมื่อต้องการเพิ่มเส้นทางขึ้นอีกหนึ่งเส้นเท่านั้น
สิ่งที่อุดเส้นทางได้คือการตั้งค่า ไม่ใช่ตัวหนังสือในระเบียบ
ช่องโหว่เรื่องเส้นทางอุดไม่ได้ด้วยตัวหนังสือในระเบียบเพียงอย่างเดียว สิ่งที่อุดได้คือการตั้งค่าทางเทคนิค ส่วนระเบียบคือเอกสารที่ให้เหตุผลรองรับการตั้งค่านั้น พูดให้เป็นรูปธรรมคือ การออกบัญชีที่บริษัทเป็นผู้ดูแล การควบคุมการติดตั้งส่วนขยายบนเครื่องที่ใช้ทำงาน การตั้งค่าเริ่มต้นของฟังก์ชันบันทึกเสียงและถอดเสียงในเครื่องมือประชุม และการตรวจสอบข้อสัญญาที่ยกเว้นการนำข้อมูลไปฝึกโมเดลตอนทำสัญญา เมื่อทำครบ 4 ข้อนี้แล้วจึงเขียนลงในระเบียบว่าเส้นทางที่ได้รับอนุญาตหมายถึงโครงสร้างชุดนี้ หลายบริษัทแจกระเบียบก่อนแล้วผลักการตั้งค่าไปทีหลัง ผลคือระเบียบลอยอยู่ตามลำพัง สำหรับขั้นตอนการสำรวจสิทธิ์การเข้าถึงและบัญชีผู้ใช้ เราเรียบเรียงไว้ในบทความที่ว่าด้วยการนำ Microsoft Copilot มาใช้และการสำรวจสิทธิ์การเข้าถึง ในโครงสร้างที่ให้ Generative AI อ่านข้อมูลภายในองค์กร สิทธิ์การเข้าถึงที่มีอยู่เดิมจะกลายเป็นขอบเขตของผลลัพธ์โดยตรง จึงควรถือว่าการออกแบบเส้นทางกับการสำรวจสิทธิ์การเข้าถึงเป็นงานเดียวกัน
ช่องโหว่ที่ 4 ความรับผิดชอบ กำหนดการตรวจรับผลลัพธ์ AI ไว้เป็นข้อกำหนด
ในบรรดาช่องโหว่ทั้ง 4 จุด จุดนี้คือจุดที่ถูกเขียนถึงน้อยที่สุด อย่างที่กล่าวไปแล้วว่าบริษัทที่ยกเรื่องการวางกฎว่าใครรับผิดชอบเมื่อเกิดปัญหาขึ้นมาเป็นประเด็น มีเพียง 25.5% ซึ่งน้อยกว่า 33.5% ที่ยกเรื่องความเสี่ยงข้อมูลรั่วไหล ทั้งที่ในความเป็นจริง สถานการณ์ที่บริษัทถูกเรียกให้ชี้แจงคือตอนที่ผลลัพธ์ผิดพลาดหลุดออกไปข้างนอก
ระเบียบจำนวนมากมีประโยคทำนองว่าให้ถือผลลัพธ์ของ Generative AI เป็นเพียงข้อมูลอ้างอิง และให้มนุษย์เป็นผู้ตัดสินใจขั้นสุดท้าย ทิศทางถูกต้อง แต่ในฐานะข้อกำหนดแล้วใช้งานไม่ได้ เพราะไม่ได้ระบุว่าใคร ณ จุดใด และด้วยอะไรจึงจะถือว่าได้ตัดสินใจแล้ว การจะทำให้ใช้งานได้ต้องเติมให้ครบ 4 ข้อต่อไปนี้
| สิ่งที่ต้องกำหนด | ตัวอย่างวิธีเติม |
|---|---|
| ผู้ตรวจรับ | ผู้ที่อยู่ในฐานะอนุมัติผลงานชิ้นนั้นในเชิงงาน ระบุด้วยชื่อตำแหน่ง |
| สิ่งที่ต้องตรวจรับ | ตัวเลข ชื่อเฉพาะ วันที่ แหล่งอ้างอิง และชื่อกฎหมาย แจกแจงรายการที่ต้องตรวจสอบออกมา |
| วิธีตรวจรับ | เทียบกับเอกสารต้นทาง สิ่งที่เทียบไม่ได้ก็ไม่ใช้ |
| บันทึกการตรวจรับ | เก็บไว้ว่าใครตรวจสอบเมื่อใด โดยผูกกับผลงานชิ้นนั้น |
สิ่งที่หน้างานไม่ชอบที่สุดคือข้อที่ 4 เรื่องบันทึก แต่ถ้าไม่มีบันทึก สิ่งที่บริษัทหยิบมาแสดงได้ในภายหลังก็จะเหลือแค่ตัวบทของระเบียบ เหมือนกับเรื่อง log ในหัวข้อก่อนหน้า บันทึกเป็นสิ่งที่ย้อนไปสร้างทีหลังไม่ได้
วิธีเขียนที่ทำให้การบันทึกเบาลง
เคล็ดลับที่ทำให้บันทึกได้ต่อเนื่องคือการเปลี่ยนความละเอียดของบันทึกไปตามชนิดของผลงาน ถ้าพยายามบันทึกทุกอย่างด้วยน้ำหนักเท่ากันหมด จะทำต่อไปไม่ไหว
| ชนิดของผลงาน | ความละเอียดของบันทึก |
|---|---|
| บันทึกย่อและสรุปสำหรับใช้ภายในองค์กร | ไม่ต้องบันทึก เพราะขอบเขตการเข้าถึงจำกัดอยู่ภายในองค์กร |
| เอกสารประกอบการตัดสินใจภายในองค์กร | ระบุชื่อผู้จัดทำและผู้ตรวจสอบไว้บนตัวเอกสาร |
| เอกสารที่ส่งให้ลูกค้าและคู่ค้า | เก็บผู้ตรวจสอบ วันที่ตรวจสอบ และรายการที่ตรวจสอบ ไว้ 1 บรรทัด |
| เอกสารที่เกี่ยวกับสัญญา ใบเสนอราคา และข้อกำหนดทางเทคนิค | นอกจากข้างต้น ให้เก็บที่อยู่ของเอกสารต้นทางที่ใช้เทียบไว้ด้วย |
ถ้าแบ่งเป็น 4 ระดับแบบนี้ สิ่งที่ต้องบันทึกจะเหลือเพียงบางส่วน และภาระของหน้างานจะจบลงที่การเติมอีก 1 บรรทัดเฉพาะสิ่งที่ส่งออกไปหาลูกค้าเท่านั้น
อย่าแบ่งขั้นตามระดับที่ปล่อยให้ AI ทำ
มีแนวคิดหนึ่งที่ควรเลี่ยงตอนเขียนข้อกำหนด นั่นคือการแบ่งความรับผิดชอบเป็นขั้นตามสัดส่วนที่ AI มีส่วนร่วม เช่น ถ้า AI สร้างทั้งฉบับต้องให้ผู้บังคับบัญชาอนุมัติ แต่ถ้าเป็นบางส่วนก็ไม่ต้อง แนวคิดนี้ใช้งานจริงไม่ได้ เพราะข้อความถูกเขียนทับ ตัวเลขถูกคัดลอกย้ายที่ และเส้นแบ่งว่าตรงไหนคือผลลัพธ์ของ AI จะเลือนหายไปหลังจากนั้น การวางเกณฑ์ที่แยกแยะไม่ได้ลงในข้อกำหนด ทำให้การตัดสินตกไปอยู่ที่การแจ้งของแต่ละบุคคล และสุดท้ายก็เท่ากับไม่มีเกณฑ์อยู่ดี
ให้แบ่งขั้นตามวิธีที่ผลลัพธ์ถูกนำไปใช้แทน ว่าอยู่ภายในองค์กร ออกไปข้างนอก หรือมีผลผูกพันตามสัญญา วิธีการนำไปใช้เป็นสิ่งที่แยกแยะได้แม้ในภายหลัง หลักการของข้อกำหนดว่าด้วยการตรวจรับ คือให้วางเฉพาะเกณฑ์ที่แยกแยะได้เท่านั้น
อนึ่ง ในเวียดนามมีการกำหนดหน้าที่ให้ผู้นำไปใช้งานต้องระบุให้ชัดว่าเป็นสิ่งที่ AI สร้างขึ้น ในกรณีที่อาจทำให้เกิดความสับสนเกี่ยวกับความแท้จริง หากจะสร้างภาพหรือวิดีโอสำหรับลูกค้าที่ฐานปฏิบัติงานในเวียดนาม ก็ต้องรับมือสองชั้น คือภายในองค์กรเก็บบันทึกการตรวจรับ และภายนอกองค์กรระบุให้ชัด การตรวจรับมีไว้กำหนดว่าใครรับผิดชอบภายในองค์กร ส่วนการระบุให้ชัดมีไว้คุ้มครองผู้รับสารภายนอก วัตถุประสงค์ต่างกัน จึงควรเขียนแยกเป็นคนละข้อ
การแจกแจงรายการที่ต้องตรวจรับยังมีผลพลอยได้อีกอย่าง คือทำให้รู้ว่าต้องสอนอะไรในการอบรม เนื้อหาของการอบรมภายในองค์กรก็คือการสอนงานเทียบตัวเลข ชื่อเฉพาะ วันที่ แหล่งอ้างอิง และชื่อกฎหมาย กับเอกสารต้นทาง เมื่อเขียน prompt เก่งขึ้น ผลลัพธ์จะดูน่าเชื่อถือมากขึ้น แต่ความน่าเชื่อถือไม่ใช่ความถูกต้อง
การจัดประเภทข้อมูล 4 ประเภทที่ต้องกำหนดก่อนเขียนระเบียบ
ช่องโหว่ 3 จุดที่ผ่านมา ล้วนต้องการเงื่อนไขตั้งต้นเดียวกัน นั่นคือจะแบ่งข้อมูลที่ใช้งานอย่างไร ถ้าเขียนข้อกำหนดโดยที่ยังไม่มีการจัดประเภท คำที่ไม่ได้นิยาม เช่น ข้อมูลลับ หรือ ข้อมูลสำคัญ จะกระจายอยู่เต็มไปหมด และการปฏิบัติงานจะหยุดชะงักทันทีที่แปลออกไป

การจัดประเภทเพียง 4 ประเภทก็เพียงพอ ถ้าเพิ่มมากกว่านี้จะจำไม่ได้ ถ้าลดลงกว่านี้การตัดสินใจจะหยาบเกินไป
| ประเภท | สิ่งที่รวมอยู่ | ป้อนเข้า Generative AI ได้หรือไม่ |
|---|---|---|
| L1 ข้อมูลสาธารณะ | ข้อความที่เผยแพร่บนเว็บไซต์ของบริษัท แคตตาล็อก บทความทางเทคนิคที่เผยแพร่แล้ว | ได้ ไม่จำกัดเส้นทาง |
| L2 ข้อมูลทั่วไปภายในองค์กร | คู่มือการทำงานภายใน รายงานการประชุม รายงานภายในองค์กร อีเมลงานทั่วไป | ได้เฉพาะเส้นทางที่ได้รับอนุญาต |
| L3 ข้อมูลเกี่ยวกับคู่ค้า | ใบเสนอราคา แบบชิ้นงาน เอกสารข้อกำหนด ราคา เงื่อนไขสัญญา ชื่อคู่ค้า | ได้เฉพาะเส้นทางที่ได้รับอนุญาตซึ่งมีสัญญายกเว้นการนำข้อมูลไปฝึกโมเดล |
| L4 ข้อมูลส่วนบุคคลและความลับสำคัญ | ข้อมูลส่วนบุคคลของพนักงาน เงินเดือน ข้อมูลสุขภาพ แผนการลงทุนที่ยังไม่เปิดเผย กรรมวิธีเฉพาะของบริษัท | ไม่ป้อน แม้จะผ่านการสรุปย่อหรือทำให้ไม่ระบุตัวตนแล้วก็ไม่ป้อน |
การทำตารางนี้ขึ้นมาคืองานชิ้นแรกของการจัดทำระเบียบ ตัวข้อกำหนดค่อยเขียนทีหลัง ถ้าสลับลำดับกัน จะกลายเป็นการพยายามนิยามประเภทข้อมูลอยู่ในตัวข้อกำหนด ซึ่งทั้งยาวและกำกวมไปพร้อมกัน
หลักการเมื่อลังเลว่าจะขีดเส้นตรงไหน
การวางหลักการไว้ 2 ข้อจะช่วยให้การถกเถียงจบเร็วขึ้น ข้อแรก เมื่อลังเลให้วางไว้ที่ประเภทสูงกว่า เพราะประเภทผ่อนลงมาทีหลังได้ แต่ข้อมูลที่ออกไปแล้วเอากลับไม่ได้ ข้อที่สอง ให้ตัดสินด้วยคำถามว่าถ้าข้อมูลชิ้นนั้นไปอยู่ในมือคู่แข่งแล้วจะเดือดร้อนหรือไม่ ถ้าเดือดร้อนก็คือ L3 ขึ้นไป วิธีนี้ให้ผลที่ทำซ้ำได้มากกว่าการถกเถียงเรื่องความลับในเชิงนามธรรม
อีกเรื่องที่เป็นปัญหาบ่อยในทางปฏิบัติคือกรณีที่ข้อมูลกลายเป็นเรื่องอ่อนไหวเมื่อนำมาประกอบกัน ชื่อคู่ค้าอย่างเดียวเป็น L3 จำนวนอย่างเดียวเป็น L2 แต่เมื่อมาครบทั้งคู่ก็อ่านเนื้อหาของธุรกิจออก ในตารางการจัดประเภทจึงต้องใส่ประโยคหนึ่งไว้เสมอว่า หากข้อมูลที่ป้อนในครั้งเดียวกันมีหลายประเภทปะปนกัน ให้ถือตามประเภทที่สูงที่สุด
สำหรับ L4 เราแนะนำให้ขีดเส้นว่าไม่ป้อนแม้จะทำให้ไม่ระบุตัวตนแล้ว เพราะไม่มีการกำหนดว่าใครเป็นผู้ตัดสินความเหมาะสมของการทำให้ไม่ระบุตัวตน ต่อให้ลบชื่อออกไป ถ้ายังเหลือแผนก ตำแหน่ง และปีที่เข้าทำงาน ก็ยังระบุตัวบุคคลได้ การปล่อยให้แต่ละคนตัดสิน จะทำให้ความแตกต่างของการตัดสินกลายเป็นความเสี่ยงข้อมูลรั่วไหลโดยตรง เส้นที่เรียบง่ายที่สุดคือเส้นที่ถูกรักษาไว้ได้มากที่สุด อนึ่ง ในร่างกฎหมาย AI ของไทยระบุว่าหน้าที่ของ AI ความเสี่ยงสูงรวมถึงธรรมาภิบาลข้อมูลที่สอดคล้องกับพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล ดังนั้นข้อมูลที่มีข้อมูลส่วนบุคคลอยู่ด้วย ไม่ควรจบอยู่แค่ในระเบียบเรื่อง Generative AI แต่ควรบริหารบนทะเบียนชุดเดียวกับแนวปฏิบัติ PDPA ที่มีอยู่เดิม จึงจะสมจริง
เมื่อให้ AI อ่านข้อมูลภายใน การจัดประเภทจะกลายเป็นสิทธิ์การเข้าถึง
ตารางการจัดประเภทจะเห็นผลจริงตอนที่เริ่มใช้โครงสร้างซึ่งให้ Generative AI อ่านเอกสารภายในองค์กร ในโครงสร้างแบบนี้ ไม่ว่าผู้ใช้จะป้อนอะไรเข้าไป ฝั่งระบบก็จะอ่านเอกสารภายในองค์กรขึ้นมาสร้างคำตอบอยู่ดี พูดอีกอย่างคือควบคุมแค่ข้อมูลขาเข้าไม่พอ ต้องควบคุมขอบเขตของเอกสารที่ให้ระบบอ่านด้วยการจัดประเภทด้วย เช่น ตัดโฟลเดอร์ที่เก็บ L4 ออกจากขอบเขตทั้งโฟลเดอร์ และให้เฉพาะแผนกที่มีสิทธิ์เข้าถึงเท่านั้นที่ค้นหา L3 ได้ สำหรับวิธีดำเนินการอย่างเป็นรูปธรรม เราเรียบเรียงไว้ในบทความที่ว่าด้วยการเชื่อมต่อข้อมูลภายในองค์กร
สิ่งที่ต้องระวังคือการตั้งค่าสิทธิ์ของโฟลเดอร์ที่แชร์กันอยู่เดิม จะกลายเป็นขอบเขตของผลลัพธ์โดยตรง โฟลเดอร์ที่แชร์กันมาหลายปีมักมีจุดที่คนซึ่งไม่ควรเห็นกลับมองเห็นได้อยู่เสมอ เพียงแต่ยังไม่ปรากฏออกมาเพราะมนุษย์ไม่ได้เดินไปเปิดดู และมันจะโผล่ออกมาทันทีที่วางกลไกการค้นหาทับลงไป งานทำตารางการจัดประเภทจึงเป็นงานเดียวกับการสำรวจสิทธิ์การเข้าถึงโดยพฤตินัย ทั้งนี้ ตารางการจัดประเภทต้องเก็บให้จบใน A4 หนึ่งแผ่นเสมอ เพราะเกณฑ์ที่ยาวหลายหน้าจะไม่ถูกเปิดดู และเกณฑ์ที่ไม่ถูกเปิดดูก็เท่ากับไม่มี
3 ตัวเลือกของสภาพแวดล้อม Generative AI ที่ปลอดภัย และการทำให้ค่าใช้จ่ายตรวจทานได้
เมื่อ 4 บทของระเบียบนิ่งแล้ว สิ่งที่ตัดสินใจได้ต่อไปคือสภาพแวดล้อม ในหัวข้อนี้จะเปรียบเทียบ 3 ตัวเลือก ตัวเลขทั้งหมดเป็นการประมาณการภายใต้สมมติฐานที่บทความนี้ตั้งขึ้น ไม่ใช่การแสดงราคาทั่วไปในตลาด เราเปิดเผยสมมติฐานทั้งหมด จึงขอให้ผู้อ่านแทนค่าด้วยตัวเลขของบริษัทตนเองแล้วตรวจทานการคำนวณอีกครั้ง
ตัวเลือก A คือการปล่อยผ่านบริการที่ไม่เสียค่าใช้จ่าย ซึ่งเป็นการคงสภาพเดิม พนักงานใช้ Generative AI แบบไม่เสียค่าใช้จ่ายผ่านบัญชีส่วนตัว และบริษัทไม่ได้ทั้งห้ามและอนุญาต ตัวเลือก B คือ SaaS สำหรับองค์กร บริษัททำสัญญาแล้วแจกบัญชีให้พนักงาน ยกเว้นการนำข้อมูลไปฝึกโมเดล และเก็บ log ได้จากหน้าจอผู้ดูแลระบบ ตัวเลือก C คือ tenant ของบริษัทเองร่วมกับ API โดยเตรียม tenant ของตนเองบน cloud แล้วสร้างกลไกเรียกใช้ผ่าน API ขึ้นมาเอง แลกกับการที่ออกแบบการเก็บบันทึกได้อย่างอิสระ แต่ต้องบวกชั่วโมงทำงานสำหรับการสร้างและการดูแล
สมมติฐานของการประมาณการ
เริ่มจากเปิดสมมติฐานออกมาให้หมดก่อน การประมาณการที่ปิดส่วนนี้ไว้จะตรวจทานไม่ได้
| รายการสมมติฐาน | ค่าที่บทความนี้ตั้งไว้ | เหตุผลที่ตั้งค่านี้ |
|---|---|---|
| จำนวนคนที่เกี่ยวข้อง | 50 คน | ขนาดที่สมมติจากฝ่ายสนับสนุนและฝ่ายเทคนิคของบริษัทในเครือที่ประเทศไทย |
| อัตราค่าแรงต่อชั่วโมง | 50 บาทต่อชั่วโมง | ค่าที่แปลงจากค่าแรงรายวัน 400 บาท หารด้วยวันละ 8 ชั่วโมง |
| ค่าบริการรายที่นั่งของ SaaS สำหรับองค์กร | 500 บาทต่อคนต่อเดือน | ระดับที่เราใช้เป็นเกณฑ์อ้างอิงมาตลอดในการพิจารณาครั้งก่อน ๆ |
| ระยะเวลาประเมิน | 12 เดือน | เฉพาะปีแรก ไม่คิดการลดลงของภาระในปีถัดไป |
| สกุลเงิน | ใช้บาทอย่างเดียว | เพราะถ้าแทรกการแปลงอัตราแลกเปลี่ยนเข้ามา จะตรวจทานการคำนวณไม่ได้ |
| การแปลงผลประโยชน์เป็นตัวเงิน | ไม่ทำ | เพราะไม่มีค่าที่วัดจริงของเวลาที่ลดลงได้ |
อัตราค่าแรงต่อชั่วโมง 50 บาทต่อชั่วโมง เป็นค่าที่แปลงจากการทำงานหน้างาน 1 ชั่วโมง ส่วนอัตราจริงของฝ่ายบริหารจัดการและผู้รับผิดชอบงานไอทีจะสูงกว่านี้ การใช้อัตราที่ต่ำจะทำให้ชั่วโมงทำงานภายในองค์กรถูกประเมินต่ำกว่าความจริง และเกิดความเอนเอียงที่ทำให้การสร้างระบบเองดูได้เปรียบ เราจึงทำการวิเคราะห์ความอ่อนไหวไว้ในหัวข้อท้าย
ตัวเลือก A การปล่อยผ่านบริการที่ไม่เสียค่าใช้จ่าย
| รายการค่าใช้จ่าย | ปริมาณ | จำนวนเงิน |
|---|---|---|
| ค่าลิขสิทธิ์ | 0 | 0 บาท |
| ชั่วโมงทำงานสำหรับตรวจสอบ Shadow AI | 8 ชั่วโมงต่อเดือน คูณ 12 เดือน เท่ากับ 96 ชั่วโมง | 4,800 บาท |
| ชั่วโมงทำงานสำหรับสอบสวนเมื่อเกิดเหตุ | 40 ชั่วโมง คูณ ปีละ 1 ครั้ง | 2,000 บาท |
| รวมทั้งปี | 136 ชั่วโมง | 6,800 บาท |
ช่องปริมาณเป็นค่าที่ตั้งไว้ชั่วคราว โดยมีสมมติฐานว่าผู้อ่านจะแทนด้วยผลจริงของบริษัทตนเอง หากมองแต่จำนวนเงิน ตัวเลือก A ถูกกว่าอย่างเทียบไม่ติด ตารางนี้จึงเป็นตารางที่แสดงข้อจำกัดของการเปรียบเทียบด้วยค่าใช้จ่ายไปด้วยในตัว เพราะตัวเลือก A มีสิ่งที่ขาดหายไปโดยไม่ปรากฏเป็นจำนวนเงิน นั่นคือบริษัทไม่สามารถเก็บ log การใช้งานไว้ได้ ร่างกฎหมาย AI ของไทยกำหนดให้ผู้นำไปใช้งานเก็บ log การใช้งานไว้อย่างน้อย 6 เดือน และการใช้ผ่านบัญชีส่วนตัวไม่มีวิธีใดที่จะทำได้ ภายใต้ร่างกฎหมายที่วางค่าปรับทางปกครองไว้ที่ 1,000,000 ถึง 5,000,000 บาท ต่อการฝ่าฝืนหนึ่งครั้ง การวางสิ่งที่ขาดหายไปนี้ไว้นอกตารางค่าใช้จ่ายแล้วเปรียบเทียบกัน ย่อมไม่ตรงไปตรงมา
ตัวเลือก B SaaS สำหรับองค์กร
| รายการค่าใช้จ่าย | ปริมาณ | จำนวนเงิน |
|---|---|---|
| ค่าลิขสิทธิ์ | 500 บาท คูณ 50 คน คูณ 12 เดือน | 300,000 บาท |
| ชั่วโมงทำงานสำหรับตั้งค่าเริ่มต้น | 40 ชั่วโมง | 2,000 บาท |
| ชั่วโมงทำงานสำหรับดูแลและสำรวจรายการ | 4 ชั่วโมงต่อเดือน คูณ 12 เดือน เท่ากับ 48 ชั่วโมง | 2,400 บาท |
| รวมทั้งปี | 88 ชั่วโมง บวกค่าลิขสิทธิ์ | 304,400 บาท |
ตัวเลือก B มีค่าใช้จ่ายส่วนใหญ่อยู่ที่ค่าบริการรายที่นั่ง และใช้ชั่วโมงทำงานภายในองค์กรน้อย ค่าใช้จ่ายเพิ่มขึ้นตามจำนวนคน แต่ภาระของผู้รับผิดชอบแทบไม่เปลี่ยน ดังนั้นตอนที่คนยังน้อยจะดูแพง และยิ่งคนมากขึ้น ช่องว่างกับการสร้างระบบเองก็ยิ่งแคบลง
ตัวเลือก C tenant ของบริษัทเองร่วมกับ API
| รายการค่าใช้จ่าย | ปริมาณ | จำนวนเงิน |
|---|---|---|
| ค่า API ตามปริมาณการใช้ | แปรผันตามปริมาณการใช้งาน | X ประเมินตอนทำสัญญา |
| ชั่วโมงทำงานสำหรับสร้างระบบ | 320 ชั่วโมง | 16,000 บาท |
| ชั่วโมงทำงานสำหรับดูแลและบำรุงรักษา | 16 ชั่วโมงต่อเดือน คูณ 12 เดือน เท่ากับ 192 ชั่วโมง | 9,600 บาท |
| รวมทั้งปี ไม่รวมค่าตามปริมาณการใช้ | 512 ชั่วโมง | 25,600 บาท บวก X |
สาเหตุที่ไม่เติมตัวเลขลงในช่องค่า API ตามปริมาณการใช้ ก็เพราะวางเหตุผลรองรับไม่ได้ ราคาต่อหน่วยเปลี่ยนไปตามโมเดลและรูปแบบสัญญา ส่วนปริมาณการใช้เปลี่ยนไปตามวัตถุประสงค์ ถ้าใส่ตัวเลขสมมติลงไป ช่องเดียวนั้นก็พลิกข้อสรุปได้ทั้งหมด เงื่อนไขของการประมาณการที่ตรวจทานได้คือ ช่องที่เติมไม่ได้ก็ไม่เติม
เมื่อเทียบตัวเลือก B กับตัวเลือก C จะเห็นว่ายอดรวมทั้งปีของตัวเลือก B คือ 304,400 บาท ส่วนตัวเลือก C คือ 25,600 บาท บวก X ดังนั้นทั้งสองจะเท่ากันเมื่อ X เท่ากับ 278,800 บาท คิดเป็นรายเดือนได้ 23,233 บาท และหารด้วยจำนวน 50 คน จะได้ประมาณ 465 บาทต่อคนต่อเดือน อ่านได้ว่าถ้าหนึ่งคนใช้ API มูลค่าตั้งแต่ประมาณ 465 บาทต่อเดือนขึ้นไป ตัวเลือก B จะถูกกว่า และถ้าต่ำกว่านั้น ตัวเลือก C จะถูกกว่า ค่านี้ออกมาจากสมมติฐานอย่างเป็นกลไก จึงคำนวณใหม่ได้ทันทีเมื่อเปลี่ยนจำนวนคนและชั่วโมงทำงานของบริษัทตนเอง
การวิเคราะห์ความอ่อนไหว ปรับอัตราค่าแรงต่อชั่วโมง
อัตราค่าแรงต่อชั่วโมงเป็นตัวแปรที่ขยับง่ายที่สุดในบรรดาสมมติฐาน เวลาปรับตรงนี้ ต้องปรับการแปลงชั่วโมงทำงานภายในองค์กรที่ใส่ไว้ในฝั่งค่าใช้จ่ายให้เป็นตัวเงินไปพร้อมกันทั้งหมดด้วย ถ้าขยับข้างเดียวข้อสรุปจะบิดเบี้ยว
| อัตราค่าแรงต่อชั่วโมง | ตัวเลือก A ที่ 136 ชั่วโมง | ตัวเลือก B ที่ 88 ชั่วโมง บวกค่ารายที่นั่ง | ส่วนคงที่ของตัวเลือก C ที่ 512 ชั่วโมง | จุดที่เท่ากัน X | คิดเป็นต่อคนต่อเดือน |
|---|---|---|---|---|---|
| 50 บาทต่อชั่วโมง | 6,800 บาท | 304,400 บาท | 25,600 บาท | 278,800 บาท | ประมาณ 465 บาท |
| 100 บาทต่อชั่วโมง | 13,600 บาท | 308,800 บาท | 51,200 บาท | 257,600 บาท | ประมาณ 429 บาท |
| 150 บาทต่อชั่วโมง | 20,400 บาท | 313,200 บาท | 76,800 บาท | 236,400 บาท | ประมาณ 394 บาท |
สิ่งที่อ่านได้มีเพียงข้อเดียว คือยิ่งอัตราค่าแรงต่อชั่วโมงสูงขึ้น จุดที่เท่ากัน X ก็ยิ่งต่ำลง เพราะตัวเลือก C ซึ่งมีชั่วโมงทำงานเป็นตัวครอบงำ ได้รับผลกระทบจากการขึ้นของอัตราค่าแรงมากกว่า บริษัทที่มีค่าใช้จ่ายด้านบุคลากรสูง จึงมีเงื่อนไขที่ทำให้การสร้างระบบเองได้เปรียบแคบลง ในบริษัทที่อัตราจริงของผู้รับผิดชอบงานไอทีสูงกว่าค่าที่แปลงจากงานหน้างาน ตัวเลือก C ที่ดูถูกกว่าอาจพลิกกลับทันทีที่ปรับอัตราให้ตรงกับความเป็นจริง
เหตุผลที่ไม่เขียนผลประโยชน์และระยะเวลาคืนทุน
การประมาณการชุดนี้ไม่ได้แปลงเวลาที่ลดลงเป็นตัวเงิน เพราะไม่มีค่าที่วัดจริง หากนำตัวเลขที่ไม่มีอยู่จริงไปกองไว้ฝั่งผลประโยชน์ ต่อให้ฝั่งค่าใช้จ่ายแม่นยำเพียงใด ข้อสรุปก็จะถูกตัดสินด้วยค่าที่ตั้งขึ้นลอย ๆ อยู่ดี ด้วยเหตุผลเดียวกันเราจึงไม่เขียนระยะเวลาคืนทุน เมื่อผลประโยชน์ไม่มีเหตุผลรองรับ ระยะเวลาคืนทุนก็ไม่มีเหตุผลรองรับ และระยะเวลาคืนทุนที่ไม่มีเหตุผลรองรับ ไม่ใช่วัตถุดิบของการตัดสินใจ แต่เป็นเครื่องประดับที่ทำให้การตัดสินใจไม่สะดุด
การเลือกตัวเลือกไม่ได้ทำด้วยขนาดของค่าใช้จ่าย แต่ทำด้วยคำถามว่าตอบข้อกำหนดที่ระเบียบกำหนดไว้ได้หรือไม่ เก็บ log ไว้ 6 เดือนได้หรือไม่ ยกเว้นการนำข้อมูลไปฝึกโมเดลได้หรือไม่ และเป็นสัญญาที่รองรับข้อมูลประเภท L3 ได้หรือไม่ ให้เลือกตัวเลือกที่ค่าใช้จ่ายต่ำที่สุดในบรรดาตัวเลือกที่ตอบครบทั้ง 3 ข้อนี้ ตัวเลือก A ถูกที่สุดแต่ตอบข้อแรกไม่ได้ จึงหลุดออกจากรายชื่อตัวเลือก และการคำนวณจุดที่เท่ากันจะเริ่มมีความหมายก็ต่อเมื่อเหลือเพียงตัวเลือก B กับตัวเลือก C แล้วเท่านั้น สำหรับการเปรียบเทียบด้านฟังก์ชัน เราเขียนไว้ในบทความเปรียบเทียบเครื่องมือ Generative AI สำหรับองค์กร
ลำดับ 90 วันที่ทำให้ระเบียบลงสู่การปฏิบัติจริง
ระเบียบไม่ได้เสร็จในวันที่เขียนจบ แต่เสร็จในวันที่การปฏิบัติงานเริ่มเดิน ต่อไปนี้คือลำดับ 90 วันตั้งแต่จัดทำแนวปฏิบัติของบริษัทในไทยจนทำให้มันเดินได้ ลำดับมีความหมายในตัวเอง จึงห้ามสลับที่กัน
| ช่วงเวลา | สิ่งที่ต้องทำ | เงื่อนไขว่าเสร็จแล้ว |
|---|---|---|
| สัปดาห์ที่ 1 ถึง 2 | จัดทำร่างการจัดประเภทข้อมูล 4 ประเภท | ชื่อประเภทและตัวอย่าง 3 รายการ เก็บได้จบใน A4 หนึ่งแผ่น |
| สัปดาห์ที่ 3 | ค้นหาเส้นทางที่ข้อมูลออกไปนอกบริษัทให้ครบ | มีรายการเส้นทางที่อนุญาตและเส้นทางที่ต้องปิด |
| สัปดาห์ที่ 4 | กำหนดสิ่งที่ต้องตรวจรับและความละเอียดของบันทึก | กำหนดได้แล้วว่าผลงานชนิดใดต้องบันทึกหรือไม่ต้อง |
ตลอด 30 วันนี้ไม่ต้องเขียนตัวข้อกำหนดแม้แต่บรรทัดเดียว แค่ตัดสินใจเท่านั้น ถ้าเริ่มเขียนตัวข้อกำหนดก่อน จะกลายเป็นการเอาคำกำกวมไปถมสิ่งที่ยังไม่ได้ตัดสินใจ และจะพังทันทีที่แปล ในขั้นค้นหาเส้นทาง ควรใส่การสัมภาษณ์พนักงานท้องถิ่นเข้าไปด้วยเสมอ เพราะเครื่องมือที่ฝ่ายบริหารจัดการรับรู้ กับเครื่องมือที่หน้างานใช้จริง ไม่ตรงกัน
วันที่ 31 ถึง 60 อุด
เป็นช่วงที่แปลงสิ่งที่ตัดสินใจไว้ให้เป็นการตั้งค่าทางเทคนิค ตรงนี้คือจุดที่หลุดง่ายที่สุด
| เป้าหมาย | เนื้อหาการตั้งค่า |
|---|---|
| บัญชีผู้ใช้ | ออกบัญชีที่บริษัทเป็นผู้ดูแล และหยุดการใช้บัญชีส่วนตัวในงานของบริษัท |
| เครื่องที่ใช้ทำงาน | ควบคุมการติดตั้งส่วนขยายบนเบราว์เซอร์ของเครื่องที่ใช้ทำงาน |
| เครื่องมือประชุม | ตรวจสอบค่าเริ่มต้นของฟังก์ชันบันทึกเสียงและถอดเสียง และปิดการใช้งานหากจำเป็น |
| สัญญา | ตรวจสอบการยกเว้นการนำข้อมูลไปฝึกโมเดลในสัญญาของบริการที่ใช้อยู่ |
| log | กำหนดว่าจะเก็บอะไรไว้เป็น log แล้วเริ่มเก็บ |
ในบรรดานี้ การเริ่มเก็บ log มีลำดับความสำคัญสูงสุด เพราะ log ย้อนไปสร้างทีหลังไม่ได้ ต่อให้การตั้งค่าอื่นยังไม่เสร็จ ก็ควรเริ่มเก็บก่อน ในช่วงเวลาเดียวกันให้เขียนตัวข้อกำหนดของแนวปฏิบัติไปด้วย งานจะเบาเพราะเป็นเพียงการคัดลอกสิ่งที่ตัดสินใจไว้แล้วลงมา ภาษาที่ใช้เขียนให้ใช้ภาษาที่บริษัทในไทยใช้ตัดสินใจ การเขียนด้วยภาษาที่ใช้ตัดสินใจก่อนแล้วค่อยแปลเป็นภาษาญี่ปุ่นเพื่ออธิบายให้สำนักงานใหญ่ฟัง จะพังน้อยกว่าการเขียนเป็นภาษาญี่ปุ่นแล้วแปลออกมา
วันที่ 61 ถึง 90 ทำให้เดิน
ในการประชุมชี้แจง อย่าอ่านข้อห้ามให้ฟังทีละข้อ เพราะจำไม่ได้ ให้หยิบงานจริงของบริษัทในไทยมา 3 ชิ้นแทน แล้วให้ผู้เข้าร่วมตอบว่างานชิ้นนี้เป็นข้อมูลประเภทใด และใช้ได้ผ่านเส้นทางใด จุดที่คำตอบแตกออกเป็นหลายทาง แปลว่าตารางการจัดประเภทหรือคำนิยามของเส้นทางยังขาดอะไรบางอย่าง ให้เก็บกลับไปแก้ทันที ความสมบูรณ์ของระเบียบวัดได้ตรงนี้
การแต่งตั้งผู้รับผิดชอบกำกับดูแลก็ทำในช่วงนี้ เป็นรายการที่ผู้นำไปใช้งานจะถูกเรียกร้องหากร่างกฎหมาย AI ของไทยผ่านออกมา และไม่จำเป็นต้องรอให้ผ่านก่อน ให้กำหนดด้วยตำแหน่งงาน ระบุชื่อ และเติมขั้นตอนส่งมอบงานเมื่อเปลี่ยนตัวไว้อีก 1 บรรทัด จะควบตำแหน่งก็ได้ แต่อย่าปล่อยให้ว่าง ทั้งนี้ สิ่งที่เห็นผลจริงในขั้นของการทำให้ติดเป็นนิสัย ไม่ใช่ตัวระเบียบ แต่คือการที่หน้างานรับรู้ว่าขอบเขตที่ใช้ได้อยู่ตรงไหน ถ้าสื่อสารออกไปแต่ข้อห้าม การใช้งานก็จะหยุด สำหรับความพยายามที่จะยกอัตราการใช้งานจริงให้สูงขึ้น เราเรียบเรียงไว้ในบทความที่ว่าด้วยการทำให้ Generative AI ติดเป็นนิสัยและอัตราการใช้งานจริง
รอบของการทบทวนก็ให้เขียนลงในเนื้อหาของระเบียบไปด้วย ที่แนะนำคือ ตารางการจัดประเภททบทวนปีละ 1 ครั้ง รายการเส้นทางทบทวนทุกครึ่งปี ส่วนที่ขึ้นกับเขตอำนาจกฎหมายทบทวนเมื่อมีเหตุ เหตุผลที่ให้ส่วนที่ขึ้นกับเขตอำนาจกฎหมายทบทวนเมื่อมีเหตุ ก็เพราะร่างกฎหมาย AI ของไทยยังไม่มีผลบังคับใช้ เมื่อผ่านออกมาแล้วให้ตรวจสอบระยะเวลาเก็บขั้นต่ำและชื่อหน่วยงานรัฐที่ต้องแจ้ง แล้วเปลี่ยนเฉพาะจุดที่เกี่ยวข้อง บริษัทที่มีฐานปฏิบัติงานในเวียดนาม ควรตรึงเส้นตายของระยะผ่อนผันสำหรับระบบเดิมไว้ในแผนการทบทวนล่วงหน้า คือวันที่ 1 มีนาคม 2027 และวันที่ 1 กันยายน 2027 สำหรับสาขาการแพทย์ การศึกษา และการเงิน
คำถามที่พบบ่อย
ขอยก 5 คำถามที่พบมากเป็นพิเศษในการปรึกษาเรื่องการจัดทำระเบียบ
ระเบียบการใช้งาน Generative AI ควรเริ่มเขียนจากตรงไหน
อย่าเริ่มจากตัวข้อกำหนด สิ่งแรกที่ต้องทำคือแผ่นการจัดประเภทข้อมูล 4 ประเภท ถ้าการจัดประเภทยังไม่นิ่ง ในตัวข้อกำหนดก็จะต้องใช้คำที่ไม่ได้นิยาม เช่น ข้อมูลลับ ซึ่งจะสร้างการตีความที่แตกต่างกันทุกครั้งที่แปลหรือทุกครั้งที่ทำ audit ลำดับถัดจากการจัดประเภทคือ การค้นหาเส้นทางที่ข้อมูลออกไปนอกบริษัท สิ่งที่ต้องตรวจรับและความละเอียดของบันทึก แล้วจึงเป็น log กับโครงสร้างการกำกับดูแล เมื่อ 4 เรื่องนี้นิ่งแล้ว การเขียนตัวข้อกำหนดจะเหลือเพียงการคัดลอกลงมา พูดกลับกันคือ ต่อให้ไปหาแบบฟอร์มสำเร็จรูปมาก่อน ก็เติม 4 เรื่องนี้ไม่ได้ เพราะในแบบฟอร์มไม่ได้เขียนไว้ว่าบริษัทนั้นใช้ข้อมูลอะไร และบริษัทในไทยใช้เส้นทางใดอยู่
ควรห้ามใช้ Generative AI แบบไม่เสียค่าใช้จ่ายทั้งหมดหรือไม่
เราไม่แนะนำให้ห้ามทั้งหมด เหตุผลข้อแรกคือห้ามไปก็ไม่หยุด เส้นทางที่ข้อมูลออกไปนอกบริษัทไม่ได้มีแค่หน้าจอของ Generative AI แต่ยังเหลือเว็บแปลภาษา ฟังก์ชัน AI ในแอปแชท ส่วนขยายบนเบราว์เซอร์ และแอปทำรายงานการประชุม เหตุผลข้อที่สองคือ ถ้าห้ามไปจนถึงขอบเขตที่รักษาไม่ได้ ความน่าเชื่อถือของระเบียบทั้งฉบับจะตกลง ถ้าห้ามเหมารวมไปถึงการสรุปย่อข้อมูลสาธารณะประเภท L1 หน้างานจะมองว่าระเบียบเป็นเอกสารที่หลุดจากความเป็นจริง แล้วก็จะไม่ทำตามข้ออื่นด้วย สิ่งที่ควรห้ามไม่ใช่เครื่องมือ แต่คือการนำข้อมูลประเภท L3 ขึ้นไปออกไปทางเส้นทางที่ไม่ได้รับอนุญาต
แค่แปลแนวทาง Generative AI ของสำนักงานใหญ่เป็นภาษาไทย เพียงพอสำหรับการขยายผลภายในองค์กรหรือไม่
ไม่พอ ปัญหาไม่ได้อยู่ที่คุณภาพของการแปล แต่อยู่ที่วิธีเขียนของต้นฉบับ ถ้าเอาเอกสารที่เขียนเป็นรายการข้อห้ามมาแปลตรง ๆ ภาษาไทยก็จะกลายเป็นรายการข้อห้ามเช่นกัน สิ่งที่เหลืออยู่กับผู้อ่านคือ สิ่งที่ห้ามทำ เท่านั้น ส่วนคำถามว่างานชิ้นนี้ทำอะไรได้บ้างยังไม่มีคำตอบ ยิ่งไปกว่านั้น สำนวนกำกวมอย่างคำว่าตามความจำเป็น หรือคำว่าอย่างเหมาะสม เมื่อแปลออกมาจะกลายเป็นประโยคที่ตัดสินใจไม่ได้ คำตอบในทางปฏิบัติคือโครงสร้าง 2 ชั้น โดยคงเอกสารนโยบายไว้ให้ฉบับภาษาญี่ปุ่นเป็นฉบับหลัก และให้แนวปฏิบัติของบริษัทในไทยใช้ฉบับภาษาไทยเป็นฉบับหลัก
ในการป้องกันข้อมูลรั่วไหลจาก Generative AI ควรหยุดอะไรก่อน
ลำดับของการหยุดไม่ได้ตัดสินด้วยขนาดของความเสี่ยง แต่ตัดสินด้วยความง่ายในการหยุดและผลที่ได้ อันดับแรกคือการตั้งค่าการนำข้อมูลไปฝึกโมเดล เพราะการตั้งค่าเพียงจุดเดียวเปลี่ยนวิธีจัดการกับข้อมูลทั้งหมดที่ป้อนเข้าไป อันดับที่สองคือการใช้บัญชีส่วนตัวในงานของบริษัท ถ้าไม่เปลี่ยนไปใช้บัญชีที่บริษัทดูแล log ก็จะไม่เหลืออยู่ในมือ อันดับที่สามคือส่วนขยายบนเบราว์เซอร์ของเครื่องที่ใช้ทำงาน เพราะมีโครงสร้างที่ส่งเนื้อหาหน้าจอที่กำลังเปิดอยู่ออกไปข้างนอกตรง ๆ และผู้ใช้ไม่รู้ตัว อันดับที่สี่คือค่าเริ่มต้นของฟังก์ชันบันทึกเสียงและถอดเสียงในเครื่องมือประชุม ทั้ง 4 ข้อนี้หยุดได้ด้วยการตั้งค่า ไม่ใช่ด้วยตัวหนังสือในระเบียบ
สภาพแวดล้อม Generative AI ที่ปลอดภัย ควรเลือกเครื่องมือด้วยเกณฑ์ใด
อย่าเริ่มจากค่าใช้จ่าย ให้กำหนดข้อกำหนดก่อน แล้วค่อยเปรียบเทียบค่าใช้จ่ายในบรรดาตัวเลือกที่ตอบข้อกำหนดได้ ข้อกำหนดมีเพียง 3 ข้อก็พอ คือเก็บ log การใช้งานไว้ได้อย่างน้อย 6 เดือนหรือไม่ ยกเว้นการนำข้อมูลไปฝึกโมเดลได้ตามสัญญาหรือไม่ และเป็นเงื่อนไขสัญญาที่รองรับข้อมูลประเภท L3 ได้หรือไม่ โครงสร้างที่ตอบ 3 ข้อนี้ไม่ได้ ต่อให้ถูกแค่ไหนก็ตัดออกจากรายชื่อตัวเลือก การปล่อยผ่านบริการที่ไม่เสียค่าใช้จ่ายตกรอบเป็นอันดับแรก ไม่ใช่เพราะค่าใช้จ่ายสูง แต่เพราะไม่มีวิธีตอบข้อแรก
สรุป สิ่งที่ระเบียบปกป้องคือเส้นทางและความรับผิดชอบในการตรวจรับ
ข้อเสนอของบทความนี้มีเพียง 2 ข้อ ข้อแรก สิ่งที่ระเบียบการใช้งาน Generative AI ปกป้องไม่ใช่การอนุญาตหรือห้ามใช้เครื่องมือ แต่คือเส้นทางที่ข้อมูลไหลออกไปนอกบริษัท และความรับผิดชอบในการตรวจรับเมื่อผลลัพธ์ของ AI ถูกนำไปใช้ในงานจริง ข้อที่สอง หากยกระเบียบที่สำนักงานใหญ่ในญี่ปุ่นจัดทำขึ้นมาวางที่บริษัทในเครือที่ประเทศไทยแบบตรง ๆ จะเปิดช่องโหว่ 4 จุด คือ เขตอำนาจกฎหมาย ภาษา เส้นทาง และความรับผิดชอบ
วิธีอุดก็สอดคล้องกันทั้ง 4 จุด ให้กำหนดการจัดประเภทข้อมูล 4 ประเภทก่อน ออกแบบเส้นทางที่ออกนอกบริษัทให้เป็นระบบอนุญาต กำหนดการตรวจรับผลลัพธ์ของ AI และความละเอียดของบันทึก แล้ววางการเก็บ log กับผู้รับผิดชอบกำกับดูแล ทั้ง 4 บทนี้ตรงกับหน้าที่ที่ร่างกฎหมาย AI ของไทยกำลังจะกำหนดให้ผู้นำไปใช้งานต้องปฏิบัติ ดังนั้นต่อให้กฎหมายผ่านออกมาก็ไม่ต้องเขียนใหม่ กฎหมาย AI ของไทยยังไม่มีผลบังคับใช้ ณ วันที่ 7 สิงหาคม 2026 แต่กฎหมาย AI ของเวียดนามมีผลบังคับใช้ไปแล้ว โดยเส้นตายของระยะผ่อนผันสำหรับระบบเดิมคือวันที่ 1 มีนาคม 2027 และวันที่ 1 กันยายน 2027 สำหรับสาขาการแพทย์ การศึกษา และการเงิน เงื่อนไขที่ว่าสถานการณ์ต่างกันไปตามเขตอำนาจกฎหมาย ควรถูกยกไปไว้ที่โครงสร้างของระเบียบเอง
เหตุผลที่เราไม่แจกแบบฟอร์มตัวข้อกำหนด ก็เพราะส่วนที่แบบฟอร์มเติมให้ไม่ได้ คือส่วนที่ตัดสินข้อสรุป จะวางข้อมูลใดไว้ที่ประเภท L4 จะอนุญาตเส้นทางใด และใครเป็นผู้ตรวจรับ ทั้ง 3 เรื่องนี้ต่างกันไปในแต่ละบริษัท ถ้าตรงนั้นนิ่งแล้ว การเขียนตัวข้อกำหนดจะเหลือเป็นงานคัดลอก แต่ถ้ายังไม่นิ่ง แบบฟอร์มใดก็จะถูกถมด้วยคำกำกวมอยู่ดี การตัดสินใจเรื่องค่าใช้จ่ายก็เช่นกัน อย่าตัดสินด้วยขนาดของจำนวนเงิน แต่ให้ตัดสินด้วยข้อกำหนด 3 ข้อ ถ้าสลับลำดับกัน สิ่งที่จะเกิดขึ้นคือ โครงสร้างที่ดูถูกที่สุดกลับกลายเป็นโครงสร้างที่ตอบหน้าที่ตามกฎหมายได้น้อยที่สุด
อนึ่ง บทความนี้อ้างอิงจากผลสำรวจแนวโน้มของบริษัทเกี่ยวกับ Generative AI ของ Teikoku Databank เดือนมีนาคม 2026 สมุดปกขาวด้านสารสนเทศและการสื่อสาร ฉบับปี 2025 ของกระทรวงกิจการภายในและการสื่อสารของประเทศญี่ปุ่น คำอธิบายของสำนักงานกฎหมายเกี่ยวกับร่างกฎหมาย AI ที่ ETDA ของไทยเผยแพร่เมื่อวันที่ 2 กรกฎาคม 2026 และคำอธิบายเกี่ยวกับกฎหมาย AI ของเวียดนาม เลขที่ No.134/2025/QH15 เนื้อหาของร่างกฎหมายอาจเปลี่ยนแปลงได้จนกว่าจะผ่านออกมา ในการแก้ไขระเบียบจึงขอให้ตรวจสอบตัวบทฉบับล่าสุดด้วย
การจัดทำระเบียบตัดสินกันเกือบทั้งหมดที่การจัดระเบียบความคิดก่อนลงมือเขียนตัวข้อกำหนด แม้อยู่ในขั้นที่ยังไม่มีร่างการจัดประเภทข้อมูลแม้แต่แผ่นเดียว เราก็รับปรึกษาตั้งแต่การเรียงงานของบริษัทในไทยออกมาแล้วขีดเส้นแบ่งประเภท หากต้องการคุยให้เป็นรูปธรรมเรื่องการประกอบแนวปฏิบัติที่ตั้งอยู่บนการใช้งานจริงในประเทศไทย หรือการตรวจสอบข้อกำหนดของสภาพแวดล้อมทั้ง 3 ตัวเลือก ติดต่อเราได้ที่หน้าติดต่อสอบถาม หากมีระเบียบฉบับปัจจุบันอยู่แล้ว เราเริ่มจากการตรวจสอบว่าช่องโหว่จุดใดในทั้ง 4 จุดที่เปิดอยู่ได้เลย
แหล่งอ้างอิง
- ผลสำรวจแนวโน้มของบริษัทเกี่ยวกับ Generative AI เดือนมีนาคม 2026 (Teikoku Databank)
- สมุดปกขาวด้านสารสนเทศและการสื่อสาร ฉบับปี 2025 สถานการณ์การใช้ AI ในภาคธุรกิจ (กระทรวงกิจการภายในและการสื่อสาร ประเทศญี่ปุ่น)
- Thailand Releases New Draft Artificial Intelligence Act (Mondaq)
- Thailand AI Act (Lex Bangkok)
- Vietnam Enacts Its First Law on Artificial Intelligence (VILAF)
- Vietnam Law on Artificial Intelligence (One Asia Lawyers)
- ThaiLLM What You Need to Know About Thailand Homegrown AI Project (Thailand NOW)