
ในยุคที่ระบบ AI เข้ามามีบทบาทอย่างลึกซึ้งในการตัดสินใจทางธุรกิจ การขาดซึ่ง Governance ย่อมนำไปสู่ความเสี่ยงทางกฎหมายและการสูญเสียความน่าเชื่อถือโดยตรง EU AI Act ที่บังคับใช้อย่างเต็มรูปแบบแล้วนั้น ครอบคลุมการบังคับใช้นอกอาณาเขต (Extraterritorial Application) ด้วย จึงไม่ใช่เรื่องที่ไม่เกี่ยวข้องสำหรับองค์กรที่ดำเนินธุรกิจในไทยและภูมิภาคเอเชียตะวันออกเฉียงใต้ บทความนี้จะอธิบายตั้งแต่แนวคิดพื้นฐานของ AI Governance ไปจนถึงการปฏิบัติตาม EU AI Act ในเชิงปฏิบัติ และขั้นตอนที่เป็นรูปธรรมในการจัดทำกฎระเบียบภายในองค์กร โดยมุ่งหวังให้ผู้ปฏิบัติงานที่ "ไม่รู้ว่าจะเริ่มต้นจากตรงไหน" สามารถลงมือสร้างระบบ Governance ขององค์กรตนเองได้หลังจากอ่านบทความนี้จบ
ข้อจำกัดความรับผิดชอบ: บทความนี้จัดทำขึ้นเพื่อวัตถุประสงค์ในการให้ข้อมูลเท่านั้น และไม่ถือเป็นคำแนะนำทางกฎหมาย สำหรับการดำเนินการทางกฎหมายที่เฉพาะเจาะจง กรุณาปรึกษาทนายความผู้เชี่ยวชาญ

AI Governance คือกรอบการทำงานเชิงองค์กรสำหรับการจัดการความเสี่ยง และการรับประกันความเป็นธรรม ความโปร่งใส และความรับผิดชอบในการพัฒนา การนำไปใช้งาน และการดำเนินงานของระบบ AI ในขณะที่ IT Governance แบบดั้งเดิม (เช่น COBIT และ ITIL) มุ่งเน้นไปที่การจัดการโครงสร้างพื้นฐานและบริการ AI Governance แตกต่างอย่างเป็นพื้นฐานตรงที่ครอบคลุมกระบวนการตัดสินใจของโมเดลเองเป็นหนึ่งในสิ่งที่ต้องบริหารจัดการด้วย
| มุมมอง | IT Governance | AI Governance |
|---|---|---|
| สิ่งที่จัดการ | โครงสร้างพื้นฐาน เครือข่าย แอปพลิเคชัน | โมเดล ข้อมูลการเรียนรู้ ผลลัพธ์การอนุมาน |
| ลักษณะของความเสี่ยง | ความพร้อมใช้งาน ความลับ ความสมบูรณ์ | Bias การ Hallucination ความไม่สามารถอธิบายได้ |
| ความเร็วของการเปลี่ยนแปลง | วงจรการ Release ที่วางแผนไว้ | พฤติกรรมเปลี่ยนแปลงอย่างคาดเดาไม่ได้เมื่อโมเดลอัปเดต |
| ความรับผิดชอบ | ผู้พัฒนาและผู้ดำเนินการชัดเจน | กระจายระหว่างผู้ให้ข้อมูล ผู้พัฒนาโมเดล และผู้ใช้งาน |
| กรอบกฎระเบียบ | ISO 27001, SOC 2 | EU AI Act, NIST AI RMF, ISO 42001 |
หากพยายามจัดการ AI โดยต่อยอดจาก IT Governance จะมองข้ามความแตกต่างที่สำคัญ นั่นคือ ผลลัพธ์เชิงความน่าจะเป็นของโมเดล อัตราการทำงานของเซิร์ฟเวอร์สามารถกำหนดได้ว่า 99.9% แต่ "ความถูกต้อง" ของโมเดล AI นั้นขึ้นอยู่กับบริบท และผลลัพธ์อาจเปลี่ยนแปลงได้แม้จะใช้ Input เดียวกัน
การใช้ AI เชิงสร้างสรรค์ในองค์กรขยายตัวอย่างรวดเร็ว และความจำเป็นในการกำกับดูแลได้เปลี่ยนจากเรื่องทางทฤษฎีมาสู่ปัญหาเชิงปฏิบัติ ในการให้คำปรึกษาด้าน AI ของเราในประเทศไทย เราได้ยินกรณีตัวอย่างเพิ่มมากขึ้นเรื่อยๆ เช่น "พนักงานกรอกข้อมูลลูกค้าลงใน ChatGPT" หรือ "ส่งสัญญาที่ AI สร้างขึ้นออกไปโดยไม่ทันสังเกตเห็นข้อผิดพลาด"
ความเสี่ยงจากการขาดการกำกับดูแลสามารถแบ่งได้เป็น 3 ประเภทหลัก:

EU AI Act (กฎระเบียบปัญญาประดิษฐ์) คือกฎหมายกำกับดูแล AI แบบครอบคลุมฉบับแรกของโลก และเช่นเดียวกับ GDPR มีผลบังคับใช้นอกอาณาเขต (extraterritorial application) ด้วย บริษัทที่ให้บริการ AI แก่ผู้ใช้งานภายใน EU จะอยู่ภายใต้การกำกับดูแลของกฎหมายนี้ โดยไม่คำนึงถึงที่ตั้งของสำนักงานใหญ่
แก่นของ EU AI Act อยู่ที่การจำแนกระบบ AI ออกเป็น 4 ระดับตามความเสี่ยง และกำหนดภาระหน้าที่ที่แตกต่างกันในแต่ละระดับ
1. สิ่งต้องห้าม (Unacceptable Risk) การให้คะแนนความน่าเชื่อถือทางสังคม (Social Credit Scoring), การระบุตัวตนทางชีวมิติแบบเรียลไทม์ทางไกล (Real-time Remote Biometric Identification) (มีข้อยกเว้นสำหรับการบังคับใช้กฎหมาย), การรับรู้อารมณ์ (Emotion Recognition) ในสถานที่ทำงานและสถาบันการศึกษา, และเทคนิค Subliminal ที่มุ่งจัดการกับกลุ่มเปราะบาง โทษปรับสูงสุดกรณีฝ่าฝืนคือ 35 ล้านยูโร หรือ 7% ของยอดขายทั่วโลก
2. ความเสี่ยงสูง (High Risk) การสรรหาและประเมินบุคลากร, การให้คะแนนเครดิต (Credit Scoring), การพิจารณารับเข้าศึกษา, การบริหารจัดการความปลอดภัยของโครงสร้างพื้นฐานสำคัญ, การบังคับใช้กฎหมาย, การบริหารจัดการการเข้าเมือง และอื่นๆ จำเป็นต้องผ่านการประเมินความสอดคล้อง (Conformity Assessment), การติด CE Marking และการลงทะเบียนในฐานข้อมูล EU
3. ความเสี่ยงจำกัด (Limited Risk) Chatbot, การสร้าง Deepfake และอื่นๆ มีการกำหนดภาระหน้าที่ด้านความโปร่งใส (Transparency) (การเปิดเผยว่าเป็น AI)
4. ความเสี่ยงน้อยที่สุด (Minimal Risk) ตัวกรองสแปม (Spam Filter), AI ในเกม และอื่นๆ ไม่มีภาระหน้าที่พิเศษ
สิ่งที่ก่อให้เกิดความสับสนมากที่สุดในการพูดคุยกับบริษัทในเอเชียตะวันออกเฉียงใต้ คือการพิจารณาว่าระบบ AI ของตนเองจัดอยู่ในหมวดหมู่ใด ตัวอย่างเช่น เครื่องมือคัดกรองการสรรหาบุคลากรภายในองค์กรจัดอยู่ในประเภท "ความเสี่ยงสูง" ในขณะที่ Chatbot ภายในองค์กรจัดอยู่ในประเภท "ความเสี่ยงจำกัด" เท่านั้น สิ่งที่มักถูกมองข้ามคือแม้จะเป็น "เครื่องมือ AI" เหมือนกัน แต่ระดับการกำกับดูแลก็แตกต่างกันไปตามวัตถุประสงค์การใช้งาน
EU AI Act มีการบังคับใช้แบบเป็นขั้นตอน โดยระยะเวลาการบังคับใช้จะแตกต่างกันไปตามประเภทของระบบ AI ที่เกี่ยวข้อง
| ประเภท | เนื้อหา |
|---|---|
| AI ที่ต้องห้าม | บทบัญญัติห้ามใช้งาน เช่น การให้คะแนนความน่าเชื่อถือทางสังคม (Social Credit Scoring) |
| AI อเนกประสงค์ (GPAI) | ภาระผูกพันของผู้ให้บริการในการเปิดเผยเอกสารทางเทคนิคและนโยบายลิขสิทธิ์ |
| AI ความเสี่ยงสูง (ภาคผนวก III) | การประเมินความสอดคล้อง, การติด CE Marking และการลงทะเบียนในฐานข้อมูล EU |
| AI ที่ฝังในผลิตภัณฑ์ตามภาคผนวก I | ภาระผูกพันแบบบูรณาการร่วมกับกฎระเบียบความปลอดภัยของผลิตภัณฑ์ |
ผู้ให้บริการโมเดล AI อเนกประสงค์ (เช่น GPT, Claude, Gemini) มีหน้าที่จัดทำเอกสารทางเทคนิค เปิดเผยนโยบายลิขสิทธิ์ และเผยแพร่สรุปข้อมูลที่ใช้ในการฝึกอบรม นอกจากนี้ ฝั่งองค์กรที่นำโมเดลเหล่านี้ไปใช้งาน ก็มีภาระผูกพันเช่นกัน ได้แก่ หน้าที่เปิดเผยว่าเป็น AI (สำหรับความเสี่ยงระดับจำกัดขึ้นไป) และหน้าที่ให้ความร่วมมือในการประเมินความสอดคล้องสำหรับการใช้งานในกลุ่มความเสี่ยงสูง
"ไม่มีฐานที่ตั้งใน EU จึงไม่เกี่ยวข้อง" เป็นความเข้าใจที่ผิด การบังคับใช้นอกอาณาเขต (extraterritorial application) เกิดขึ้นในกรณีต่อไปนี้:
หากบริษัทส่งออกของไทยใช้ระบบตรวจสอบคุณภาพที่ขับเคลื่อนด้วย AI สำหรับผู้ซื้อใน EU ระบบดังกล่าวอาจอยู่ภายใต้ขอบเขตการบังคับใช้ของ EU AI Act ในกลุ่มลูกค้าของเราเอง ก็พบว่ามีบริษัทที่ดำเนินธุรกิจ EC มุ่งสู่ตลาดยุโรปเข้ามาปรึกษาเกี่ยวกับภาระผูกพันในการเปิดเผยข้อมูล (disclosure obligation) ด้าน AI recommendation เพิ่มมากขึ้นเรื่อยๆ
นอกจากนี้ รัฐบาลไทยเองก็กำลังพิจารณาออกกฎระเบียบ AI ของตนเองด้วย โดย MDES (กระทรวงดิจิทัลเพื่อเศรษฐกิจและสังคม) ของไทยได้เผยแพร่แนวปฏิบัติด้าน AI Governance และกำลังดำเนินการจัดทำกฎหมายโดยอ้างอิง EU AI Act เป็นแบบอย่าง หากเตรียมรับมือกับ EU AI Act ไว้ล่วงหน้า ก็จะสามารถรองรับกฎระเบียบภายในประเทศไทยที่จะตามมาในอนาคตได้อย่างราบรื่น

EU AI Act เพียงอย่างเดียวไม่ใช่แนวทางเดียวสำหรับ AI Governance มีความจำเป็นต้องทำความเข้าใจ Framework หลายรูปแบบ และเลือกใช้สิ่งที่เหมาะสมกับสถานการณ์ของบริษัทตนเอง
| Framework | ผู้ออก | ลักษณะ | คุณสมบัติเด่น |
|---|---|---|---|
| EU AI Act | EU | มีผลผูกพันทางกฎหมาย | การจำแนกตามความเสี่ยง มีบทลงโทษทางการเงิน |
| NIST AI RMF | NIST สหรัฐอเมริกา | แนวปฏิบัติโดยสมัครใจ | 4 ฟังก์ชัน ได้แก่ Map-Measure-Manage-Govern |
| ISO/IEC 42001 | ISO | มาตรฐานการรับรอง | มาตรฐานสากลสำหรับระบบการจัดการ AI |
| Singapore IMDA AI Governance | รัฐบาลสิงคโปร์ | แนวปฏิบัติ | มีประโยชน์ใช้สอยสูงในกลุ่มประเทศ ASEAN |
| taai AI Ethics Guideline | MDES ไทย | แนวปฏิบัติ | มุ่งเน้นหลักจริยธรรม สำหรับองค์กรในประเทศไทย |
สำหรับธุรกิจขนาดกลางและขนาดย่อม (SMEs) การมุ่งขอรับรอง ISO 42001 ในทันทีนั้นไม่มีความเป็นไปได้ในทางปฏิบัติเมื่อพิจารณาด้านต้นทุน แนวทางที่สมเหตุสมผลคือการเริ่มต้นจัดระเบียบกระบวนการภายในองค์กรโดยใช้ NIST AI RMF เป็นฐาน จากนั้นจึงรับมือกับข้อกำหนดความเสี่ยงสูงของ EU AI Act ตามความจำเป็น
เกณฑ์การตัดสินใจในการเลือกมี 3 ข้อ:
ในความเป็นจริง กรอบการทำงานเหล่านี้ไม่ใช่สิ่งที่ต้อง "เลือก" แต่เป็นสิ่งที่ต้อง "ผสมผสาน" เข้าด้วยกัน แผนงานที่เป็นไปได้จริงคือการใช้การจำแนกความเสี่ยงของ EU AI Act เป็นฐาน นำกระบวนการจัดการของ NIST AI RMF มาประยุกต์ใช้ และในอนาคตทำให้เป็นรูปแบบทางการด้วย ISO 42001

การเข้าใจเพียงแค่ framework นั้นไม่เพียงพอ เพื่อให้ governance ทำงานได้จริงภายในองค์กร จำเป็นต้องจัดเตรียม 3 องค์ประกอบ ได้แก่ policy, process และ people ต่อไปนี้จะนำเสนอแนวทางแบบเป็นขั้นตอน
ขั้นตอนแรกคือการทำความเข้าใจว่าภายในองค์กรมี AI tools ใดบ้าง ใครเป็นผู้ใช้งาน และใช้เพื่อวัตถุประสงค์อะไร หลายบริษัทกำลังเผชิญปัญหา "Shadow AI" (การใช้งาน AI ที่ฝ่าย IT ไม่รับทราบ)
Checklist สำหรับการตรวจสอบ:
ในกรณีของลูกค้ารายหนึ่งในอุตสาหกรรมการผลิต ผลการตรวจสอบพบว่ามี AI tools ถูกใช้งานรวมทั้งสิ้น 42 รายการใน 17 แผนก โดยในจำนวนนั้น 28 tools ไม่เป็นที่รับทราบของฝ่าย IT นอกจากนี้ยังพบกรณีที่แผนกควบคุมคุณภาพนำ AI ตรวจสอบภาพมาใช้งานเองโดยอิสระ และ AI ดังกล่าวถูกนำไปใช้กับผลิตภัณฑ์ที่ส่งออกไปยัง EU ซึ่งหากไม่มีการตรวจสอบ แม้แต่การจำแนกความเสี่ยงตาม EU AI Act ก็ยังไม่สามารถเริ่มต้นได้เลย
ประเมินระดับความเสี่ยงของการใช้ AI แต่ละรายการโดยอิงจากผลการสำรวจสินค้าคงคลัง และจัดทำนโยบาย AI ภายในองค์กร
รายการที่ควรรวมอยู่ใน AI Policy:
| หมวดหมู่ | รายการที่เฉพาะเจาะจง |
|---|---|
| ขอบเขตการใช้งาน | เครื่องมือ AI ที่อนุญาต, การใช้งานที่ห้าม (เช่น การตัดสินใจรับสมัครงานแบบอัตโนมัติเต็มรูปแบบ) |
| การจัดการข้อมูล | เกณฑ์การจำแนกประเภทข้อมูลที่อนุญาตให้ป้อนเข้า AI, ข้อกำหนดการทำให้ข้อมูลส่วนบุคคลเป็นนิรนาม |
| การควบคุมคุณภาพ | เกณฑ์การตรวจสอบผลลัพธ์จาก AI โดยมนุษย์, ความถี่ในการติดตามความแม่นยำ |
| ความโปร่งใส | เกณฑ์และวิธีการเปิดเผยการใช้ AI ต่อลูกค้าและคู่ค้าทางธุรกิจ |
| โครงสร้างความรับผิดชอบ | ผู้มีอำนาจตัดสินใจที่เกี่ยวข้องกับ AI, ขั้นตอนการ escalation เมื่อเกิด incident |
| การอบรม | การฝึกอบรม AI literacy สำหรับพนักงานทุกคน, การฝึกอบรมเฉพาะทางตามแผนก |
นโยบายไม่จำเป็นต้องสมบูรณ์แบบตั้งแต่ต้น แนวทางที่ใช้ได้จริงคือเริ่มต้นด้วยการกำหนด "สิ่งที่ห้ามทำ" ให้ชัดเจน แล้วค่อยเพิ่มรายละเอียดทีละขั้นตอน เวอร์ชันแรกเพียงแค่กระชับ ประมาณ 2–3 หน้ากระดาษ A4 ก็เพียงพอแล้ว
โครงสร้างองค์กรที่รับผิดชอบอย่างชัดเจนเป็นสิ่งจำเป็นในการทำให้นโยบายมีผลบังคับใช้อย่างแท้จริง ต่อไปนี้คือ 3 โมเดลที่เหมาะสมตามขนาดขององค์กร
องค์กรขนาดเล็ก (~50 คน): ผู้รับผิดชอบด้าน IT ที่มีอยู่เดิมรับหน้าที่ดูแล AI Governance ควบคู่กัน พร้อมทบทวนสถานะการใช้งาน AI เป็นรายเดือน
องค์กรขนาดกลาง (50–500 คน): จัดตั้งคณะกรรมการ AI Governance โดยประกอบด้วยตัวแทนจากฝ่าย IT ฝ่ายกฎหมาย และหน่วยธุรกิจ พร้อมทบทวนนโยบายทุกไตรมาส
องค์กรขนาดใหญ่ (500 คนขึ้นไป): แต่งตั้ง AI Governance Officer เฉพาะทาง (Chief AI Officer) จัดตั้งคณะกรรมการจริยธรรม AI และกำหนดกระบวนการอนุมัติล่วงหน้าสำหรับการนำ AI ที่มีความเสี่ยงสูงมาใช้งานหรือเปลี่ยนแปลง
สิ่งสำคัญที่สุดในการออกแบบโครงสร้างองค์กรคือ AI Governance ต้องไม่ตกเป็นความรับผิดชอบของฝ่าย IT เพียงฝ่ายเดียว ผลกระทบของ AI ครอบคลุมหลายหน่วยงาน ไม่ว่าจะเป็นการตัดสินใจทางธุรกิจ กฎหมาย HR หรือการตลาด หากขาดการสนับสนุนจากผู้บริหารระดับสูง ระบบ Governance ก็จะกลายเป็นเพียงพิธีกรรมที่ไร้ความหมาย
โครงสร้างการกำกับดูแลไม่ใช่สิ่งที่สร้างเสร็จแล้วจบ AI model จะมีความแม่นยำที่เสื่อมถอยลงตามกาลเวลา (model drift) และสภาพแวดล้อมด้านกฎระเบียบก็เปลี่ยนแปลงอยู่เสมอ
องค์ประกอบของการติดตามตรวจสอบอย่างต่อเนื่อง:
ในการทบทวนการกำกับดูแลรายไตรมาส แนะนำให้ติดตาม KPI ดังต่อไปนี้:

จากประสบการณ์เชิงปฏิบัติ รวบรวมกับดักที่องค์กรมักตกหลุมพรางในการนำ AI Governance มาใช้งาน
การกำกับดูแล (Governance) ที่เข้มงวดเกินไปจนทำให้ทีมงานในพื้นที่ปฏิบัติการหลีกเลี่ยงการใช้ AI นั้นไม่ใช่เรื่องแปลก ในกรณีของลูกค้ารายหนึ่ง การนำเครื่องมือ AI มาใช้ต้องผ่านกระบวนการอนุมัติ 3 ขั้นตอน ส่งผลให้การอนุมัติใช้เวลาเฉลี่ยถึง 45 วัน จนในที่สุดหัวหน้าแผนกตัดสินใจยกเลิกการนำ AI มาใช้โดยให้เหตุผลว่า "Excel ก็เพียงพอแล้ว"
จุดประสงค์ของ Governance ไม่ใช่การห้ามใช้ AI แต่คือการส่งเสริมการใช้งานควบคู่ไปกับการบริหารความเสี่ยง แนวทางสำคัญคือการใช้ "Risk-based Approach" โดยการใช้ AI ที่มีความเสี่ยงต่ำ (เช่น การแปลภาษา การสรุปเนื้อหา การเติมโค้ด เป็นต้น) สามารถใช้งานได้โดยไม่ต้องขออนุมัติล่วงหน้า ในขณะที่การใช้งานที่มีความเสี่ยงสูงเท่านั้นที่จะต้องผ่านกระบวนการตรวจสอบ
รูปแบบที่พบบ่อยคือการสร้างเอกสาร AI Policy ที่ดูดีแต่ไม่ได้รับการเผยแพร่ภายในองค์กร และไม่มีใครอ่าน ประสิทธิผลของ Policy ขึ้นอยู่กับการให้ความรู้และการสร้างกลไก
AI Governance อยู่ที่จุดตัดระหว่างเทคโนโลยีและกฎหมาย หากทีมเทคนิคดำเนินการเพียงฝ่ายเดียว ก็มักมองข้ามความเสี่ยงทางกฎหมาย แต่หากฝ่ายกฎหมายดำเนินการเพียงฝ่ายเดียว ก็มักได้กฎเกณฑ์ที่ไม่สามารถนำไปปฏิบัติได้จริงในเชิงเทคนิค
แนวทางแก้ไขที่มีประสิทธิภาพคือการกำหนดบทบาท "AI Governance Translator" นั่นคือการมีบุคลากรที่เข้าใจทั้งด้านเทคนิคและด้านกฎหมาย และสามารถอธิบายในภาษาของทั้งสองฝ่ายได้ หากการมีผู้รับผิดชอบเฉพาะทางเป็นเรื่องยาก ก็สามารถจัดตั้ง AI Governance Task Force โดยจับคู่ตัวแทนจากฝ่ายเทคนิคและฝ่ายกฎหมายฝ่ายละหนึ่งคนได้เช่นกัน
ในการดำเนินโครงการสนับสนุน AI Governance ของบริษัทเรา Workshop ครั้งแรกจะต้องมีตัวแทนจาก 3 ฝ่ายเข้าร่วมเสมอ ได้แก่ IT ฝ่ายกฎหมาย และฝ่ายวางแผนธุรกิจ ช่องว่างด้านความเข้าใจระหว่างฝ่ายต่าง ๆ นั้นมีมากกว่าที่คาดไว้ และบ่อยครั้งที่ความกังวลของผู้บริหารระดับสูงที่ว่า "AI ตัดสินใจเองโดยอิสระ" กับความเข้าใจของทีมเทคนิคที่ว่า "ควบคุมด้วย Rule-based" นั้นสวนทางกันอย่างสิ้นเชิง

ต่อไปนี้คือรายการตรวจสอบที่ควรยืนยันในระหว่างการนำระบบ AI ไปใช้งานและการดำเนินการ โดยบูรณาการข้อกำหนดความเสี่ยงสูงของ EU AI Act และแนวปฏิบัติที่ดีที่สุดของ NIST AI RMF เข้าด้วยกัน
checklist นี้ไม่ใช่สิ่งที่ครบถ้วนสมบูรณ์ และจำเป็นต้องปรับแต่งให้เหมาะสมตามประเภทธุรกิจ ขนาด และระดับการใช้งาน AI ขององค์กร สิ่งสำคัญยิ่งกว่าการมี checklist อยู่นั้น คือการปลูกฝังนิสัยการรีวิวอย่างสม่ำเสมอให้หยั่งรากลึกในองค์กร

ตอบคำถามที่พบบ่อยเกี่ยวกับ AI Governance
จำเป็นต้องดำเนินการ แต่แนวทางจะแตกต่างออกไป บริษัทที่มีพนักงานไม่เกิน 50 คนไม่จำเป็นต้องได้รับการรับรอง ISO 42001 อย่างน้อยที่สุด เพียงแค่กำหนดกฎเกณฑ์ใน 2 ประเด็น ได้แก่ "มาตรฐานข้อมูลที่ห้ามป้อนเข้า AI" และ "กระบวนการตรวจสอบเมื่อนำผลลัพธ์จาก AI มาใช้ในการตัดสินใจขั้นสุดท้าย" ก็สามารถลดความเสี่ยงได้อย่างมีนัยสำคัญ นอกจากนี้ EU AI Act ยังได้จัดเตรียมวิธีการปฏิบัติตามกฎระเบียบที่เรียบง่ายสำหรับ SME ไว้ด้วย ได้แก่ regulatory sandbox และเอกสารแนวทาง (guidance documents)
ขั้นแรกให้จัดทำแนวทางการใช้งาน โดยมีรายละเอียดดังนี้:
แนวทางที่เป็นรูปธรรมคือ รวบรวมสิ่งเหล่านี้ให้อยู่ในกระดาษ A4 หน้าเดียว แล้วเริ่มต้นด้วยการเผยแพร่ไปยังทั้งองค์กร
มีการกำหนดค่าปรับ 3 ระดับตามประเภทของการละเมิด:
สำหรับ SME และ Startup จะมีการใช้เพดานที่สัดส่วนต่ำกว่า อย่างไรก็ตาม ค่าปรับไม่ใช่ความเสี่ยงเพียงอย่างเดียว การถูกกีดกันออกจากตลาด EU การสูญเสียความไว้วางใจจากคู่ค้า และความเสียหายต่อชื่อเสียง (Reputation Damage) จากการรายงานข่าวของสื่อ อาจส่งผลกระทบต่อธุรกิจได้มากกว่าในบางกรณี

AI Governance ไม่ใช่ "เรื่องของบริษัทใหญ่" แต่เป็นรากฐานที่จำเป็นสำหรับทุกองค์กรที่นำ AI มาใช้ในการดำเนินงาน การบังคับใช้ EU AI Act อย่างเต็มรูปแบบทำให้ความเสี่ยงจากการขาด Governance มีความชัดเจนในเชิงกฎหมายมากยิ่งขึ้น
3 การดำเนินการที่เริ่มต้นได้ตั้งแต่วันนี้:
เพียงดำเนินการทั้ง 3 ข้อนี้ หลายองค์กรก็สามารถก้าวแรกสู่ AI Governance ได้แล้ว ไม่จำเป็นต้องมุ่งสร้างระบบที่สมบูรณ์แบบตั้งแต่เริ่มต้น แนวทางที่มีประสิทธิภาพสูงสุดภายใต้ทรัพยากรที่จำกัด คือการเริ่มต้นเล็ก ๆ แล้วค่อย ๆ ขยายตามเหตุการณ์ที่เกิดขึ้นและการเปลี่ยนแปลงของกฎระเบียบ
บริษัทของเราให้บริการสนับสนุนการสร้างระบบ AI Governance สำหรับองค์กรในประเทศไทยและภูมิภาคเอเชียตะวันออกเฉียงใต้ ตั้งแต่การสำรวจ การจัดทำ Policy ไปจนถึงการออกแบบโครงสร้างองค์กร หากท่านสนใจการจัดทำ Roadmap ที่เหมาะสมกับสถานการณ์ของบริษัท สามารถติดต่อปรึกษาได้อย่างสบายใจ
Yusuke Ishihara
13歳でMSXに触れプログラミングを開始。武蔵大学卒業後、航空会社の基幹システム開発や日本初のWindowsサーバホスティング・VPS基盤構築など、大規模システム開発に従事。 2008年にサイトエンジン株式会社を共同創業。2010年にユニモン株式会社、2025年にエニソン株式会社を設立し、業務システム・自然言語処理・プラットフォーム開発をリード。 現在は生成AI・大規模言語モデル(LLM)を活用したプロダクト開発およびAI・DX推進を手がける。