AI Governance คืออะไร องค์กรต้องกำหนดใครรับผิดชอบและควบคุมอะไร

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

1. 01โจทย์ธุรกิจ
2. 02ข้อมูล
3. 03สาเหตุ
4. 04สิ่งที่ทำต่อ

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

AI Governance ต่างจากนโยบายและความปลอดภัยอย่างไร

เรื่อง	ตอบคำถามอะไร	สิ่งที่ต้องมี
AI Governance	ใครมีสิทธิ์ตัดสินใจและรับผิดชอบ	บทบาท กระบวนการ เกณฑ์ หลักฐาน Monitoring
AI Policy	องค์กรอนุญาตหรือห้ามอะไร	กฎการใช้ข้อมูล เครื่องมือ และการตรวจ
AI Risk Management	ความเสี่ยงคืออะไรและควบคุมอย่างไร	การระบุ วัด จัดลำดับ และติดตามความเสี่ยง
AI Safety/Security	ระบบอาจก่ออันตรายหรือถูกโจมตีอย่างไร	การทดสอบ การควบคุมสิทธิ์ Incident response
Compliance	ต้องปฏิบัติตามข้อกำหนดใด	การตีความกฎหมาย/สัญญาตามบริบทจริง

เอกสารหนึ่งชุดอาจช่วยหลายเรื่อง แต่การมีนโยบายอย่างเดียวไม่เท่ากับมี Governance หากไม่มีผู้อนุมัติ หลักฐาน และการติดตามหลังใช้งาน

องค์กรต้องกำกับ AI เมื่อใด

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

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

ใช้กรอบ NIST AI RMF ให้เป็นงานจริง

NIST AI Risk Management Framework เป็นกรอบสมัครใจและไม่ผูกกับอุตสาหกรรมเดียว แบ่งงานเป็น Govern, Map, Measure และ Manage โดย Govern เชื่อมกับทุกส่วน

ส่วน	คำถามสำหรับองค์กร	หลักฐานที่ควรได้
Govern	ใครรับผิดชอบ กฎและวัฒนธรรมคืออะไร	บทบาท นโยบาย Approval path บันทึกการตัดสินใจ
Map	ระบบใช้ที่ไหน กับใคร และมีผลอย่างไร	Use case, Stakeholder, Data flow, Impact
Measure	จะทดสอบความถูกต้อง ความปลอดภัย และ Bias อย่างไร	Test set, Metric, Threshold, Known limitation
Manage	ยอมรับ ลด ส่งต่อ หรือหยุดความเสี่ยงเมื่อใด	Risk treatment, Owner, Due date, Monitoring

บทบาทที่ต้องชัดก่อนเริ่ม

บทบาท	การตัดสินใจหลัก	ไม่ควรผลักภาระให้
ผู้บริหาร/คณะกำกับ	ระดับความเสี่ยงที่ยอมรับ งบ และเรื่องที่ต้องรายงาน	ผู้ใช้ปลายทางคนเดียว
Business owner	เป้าหมาย กระบวนการ KPI และผลกระทบลูกค้า	ทีมไอทีตัดสินใจแทนธุรกิจ
Data/AI/IT	สถาปัตยกรรม ข้อมูล การทดสอบ การติดตาม	ผู้ขายเครื่องมือรับรองตัวเอง
Privacy/Security/Legal/Risk	ข้อกำหนด สิทธิ์ สัญญา และ Control	ตรวจหลังเปิดใช้แล้วเท่านั้น
Human reviewer	ตรวจผล ตัดสินใจ Override และ Escalate	รับผิดชอบโดยไม่มีเวลา/อำนาจ
ผู้ให้บริการ	ส่งข้อมูลข้อจำกัด Security และ Change	เป็นเจ้าของความเสี่ยงแทนองค์กร

ขั้นตอนกำกับ AI ตั้งแต่เสนอจนเลิกใช้

1. สร้างทะเบียน AI และแบบรับ Use case

บันทึกเจ้าของงาน ผู้ใช้ กลุ่มที่ได้รับผล ข้อมูลนำเข้า ผู้ให้บริการ ผลลัพธ์ การเชื่อมระบบ ความถี่ และวันที่ทบทวน รวมถึง AI ที่พนักงานเริ่มใช้เองเพื่อไม่ให้เกิด Shadow AI

2. จัดระดับความเสี่ยง

ระดับ	ตัวอย่าง	Gate
ต่ำ	ระดมไอเดียจากข้อมูลสาธารณะ	แนวทางใช้และสุ่มตรวจ
กลาง	ร่างเนื้อหา/รายงานที่คนตรวจ	Test set, Reviewer, Source check
สูง	ข้อเสนอที่มีผลต่อบุคคล สิทธิ์ หรือเงิน	ผู้เชี่ยวชาญหลายฝ่าย อนุมัติ และติดตามเข้ม
ห้ามใช้	งานที่ขัดนโยบาย กฎหมาย หรือควบคุมไม่ได้	ปิดการเข้าถึงและบันทึกเหตุผล

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

3. จำแนกข้อมูลและสิทธิ์

• ข้อมูลใดใช้ได้ ใช้ไม่ได้ หรือต้องปกปิด
• ผู้ให้บริการเก็บข้อมูลนานเท่าไรและนำไปฝึกหรือไม่
• ใครเปิดดู Prompt, Output, Log และตั้งค่าได้
• ส่งข้อมูลข้ามระบบหรือประเทศอย่างไร
• ลบ ส่งออก และรับมือคำขอเจ้าของข้อมูลอย่างไร

4. ตรวจผู้ให้บริการและสัญญา

ตรวจการใช้ข้อมูล การควบคุมสิทธิ์ Security incident, Subprocessor, Logging, Model change, Service availability, Exit plan และค่าใช้จ่ายจริง อย่าตัดสินจาก Demo หรือคำว่า Enterprise เพียงอย่างเดียว

5. กำหนดเกณฑ์ทดสอบก่อนเปิดใช้

• Test set จากงานจริงที่ลบข้อมูลอ่อนไหวแล้ว
• Expected result และตัวอย่างคำตอบที่ยอมรับไม่ได้
• Metric เช่น Accuracy, Completeness, Harm, Time saved, Cost
• Threshold ผ่าน/ไม่ผ่านและผู้ลงนาม
• กรณีข้อมูลขาด การโจมตี Prompt และระบบภายนอกล้ม

6. ออกแบบ Human oversight ให้มีอำนาจจริง

ระบุว่าคนต้องตรวจจุดใด ตรวจจากหลักฐานอะไร มีเวลาพอหรือไม่ และกดหยุด/ย้อนกลับได้อย่างไร การใส่คำว่า Human-in-the-loop โดยไม่มีเกณฑ์และอำนาจไม่ได้ลดความเสี่ยง

7. เปิดใช้แบบจำกัดขอบเขต

เริ่มจากผู้ใช้หรือกระบวนการจำกัด ตั้ง Budget/Rate limit, Logging และช่องทางแจ้งปัญหา เปรียบเทียบกับ Baseline ก่อนขยาย ไม่เปิดอัตโนมัติทั้งองค์กรจากผล Pilot ขนาดเล็ก

8. ติดตามการเปลี่ยนแปลงและเหตุผิดปกติ

เฝ้าดูคุณภาพ ต้นทุน Drift, Model/version, Vendor policy, Complaint, Override และ Incident กำหนด Trigger ให้ทดสอบใหม่เมื่อ Input, Model, Prompt, Data source หรือ Workflow เปลี่ยน

9. เลิกใช้และส่งมอบอย่างควบคุม

มีเกณฑ์หยุด Export/ลบข้อมูล ปิด Token/API ย้ายงานกลับสู่กระบวนการเดิม และเก็บหลักฐานตามระยะเวลาที่เหมาะสม

ตารางตัดสินใจ Go / Pilot / Stop

คำถาม	Go/Pilot เมื่อ	Stop เมื่อ
เป้าหมาย	วัดผลและมีเจ้าของ	ใช้เพราะกระแส ไม่มีงานชัด
ข้อมูล	จำแนกและมีสิทธิ์ใช้	ไม่รู้ที่มา/ข้อจำกัดการส่งต่อ
คุณภาพ	มี Test/Threshold	ดูตัวอย่างดีไม่กี่ครั้ง
ผลกระทบ	คนตรวจและแก้คืนได้	ผลสูงแต่ไม่มี Appeal/Override
ผู้ขาย	ข้อกำหนดและ Exit plan ชัด	ตรวจการใช้ข้อมูลไม่ได้
ปฏิบัติการ	Log/Monitor/Incident owner พร้อม	ไม่มีคนดูหลังเปิดใช้

ตัวชี้วัดที่ไม่ควรมีแค่ความแม่นยำ

• Business: เวลา ต้นทุน คุณภาพ Cycle time และผลลัพธ์ลูกค้า
• Quality: Error rate, Hallucination, Completeness, Consistency
• Human control: Review rate, Override, Escalation, Appeal
• Risk: Incident, Data exposure, Harm, Complaint
• Operations: Availability, Latency, Cost per task, Drift
• Governance: Use case ที่มีเจ้าของ Review ตรงเวลา และ Action ปิดครบ

ตัวชี้วัดต้องมี Baseline, Target, Threshold และเจ้าของการตัดสินใจ มิฉะนั้น Dashboard จะบอกสถานะโดยไม่ทำให้เกิดการควบคุม

แผนเริ่มต้น 90 วัน

1. วัน 1–30: ตั้งผู้รับผิดชอบ สำรวจ Use case/เครื่องมือ ทำ Data rule และคัด 2–3 Pilot
2. วัน 31–60: Risk tier, Vendor review, Test set, Approval, Incident/Stop procedure
3. วัน 61–90: เปิด Pilot วัด Baseline ติดตามปัญหา ทบทวน และตัดสินใจขยาย/แก้/หยุด

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

ข้อผิดพลาดที่ทำให้ Governance ไม่เกิดผล

• สร้างคณะกรรมการแต่ไม่มีสิทธิ์หยุดระบบ
• อนุมัติเครื่องมือโดยไม่อนุมัติ Use case
• ให้ทุกงานใช้แบบประเมินยาวเท่ากัน
• ถือว่าผู้ขายรับผิดชอบผลกระทบแทน
• วัด Demo accuracy แต่ไม่วัดงานจริงและกลุ่มย่อย
• มี Human review แต่ไม่มีเวลา หลักฐาน หรือ Training
• ไม่ติดตาม Model/Prompt/Data change
• ไม่มี Exit plan เมื่อราคา คุณภาพ หรือนโยบายเปลี่ยน

Checklist ก่อนเปิดใช้ AI

• Use case, Owner, User และผู้ได้รับผลชัด
• Risk tier และ Approval level เหมาะสม
• Data classification/permission/retention ชัด
• Vendor/contract/security reviewed
• Test set, Metric, Threshold และ Limitation ครบ
• Human review/override/escalation ใช้งานได้จริง
• Log, Monitoring, Incident และ Stop procedure พร้อม
• Training/Communication ถึงผู้ใช้
• Review due date และ Change trigger กำหนดแล้ว
• Exit plan และการลบ/ส่งออกข้อมูลพร้อม

คำถามที่พบบ่อย

ธุรกิจขนาดเล็กต้องมีคณะกรรมการ AI หรือไม่

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

AI Governance เป็นหน้าที่ของ IT หรือไม่

ไม่ใช่ IT ดูระบบได้ แต่ Business owner ต้องรับผิดชอบเป้าหมายและผลกระทบ ส่วน Privacy, Security, Legal และ Risk เข้ามาตาม Use case

ใช้ NIST AI RMF แล้วถือว่าปฏิบัติตามกฎหมายหรือไม่

ไม่ กรอบ NIST เป็นแนวทางบริหารความเสี่ยงแบบสมัครใจ การปฏิบัติตามกฎหมายต้องประเมินตามประเทศ อุตสาหกรรม สัญญา และสถานการณ์จริง

แหล่งอ้างอิง

• NIST: AI Risk Management Framework 1.0
• NIST AI RMF Core: Govern, Map, Measure, Manage
• NIST AI RMF Playbook

อ่านต่อ: เริ่มจาก เริ่มใช้ AI ในองค์กร, ทำ นโยบายการใช้ AI และออกแบบ Workflow, Automation และ AI Workflow

ผู้เขียน: อาจารย์หลิง ณิชชา ทัตพงษ์พฤธา ผู้ก่อตั้ง AJLinkOfficial และบริษัท อินดิจิทัล จำกัด เรียบเรียงเรื่อง AI และ Digital Marketing ให้เชื่อมกับการตัดสินใจและการทำงานของธุรกิจ