Governance
AI Governance ด้วย approval, permission และ audit log
การใช้ AI ในงานจริงต้องอธิบายได้ว่า AI เข้าถึงข้อมูลใด ใครอนุมัติผลลัพธ์ และถูกใช้ที่ไหน AGTO ถูกออกแบบให้คนบริหาร AI ได้
สรุป — จุดสำคัญของ governance
Governance
ใช้งาน AI บนเงื่อนไขที่คนบริหารได้
โดยมีการอนุมัติของคน สิทธิ์ และ audit log เป็นพื้นฐาน ขยายการมอบหมายทีละขั้น
ควบคุมข้อมูลที่ AI เข้าถึง
AI ที่มีประโยชน์ยังต้องเคารพ data boundary AGTO ออกแบบการเข้าถึงตาม user, tenant และ workflow
ใช้ HITL กับงานที่มีความเสี่ยง
คำตอบ การแก้ Skill และผลลัพธ์ Routine สามารถส่งให้คนตรวจเมื่อมี business risk
ทำให้งานอธิบายได้ด้วย log
ทีมตรวจสอบได้ว่าใครแก้ Skill ใช้ที่ไหน และผ่าน approval ใดก่อนเข้ากระบวนงาน
Governance
ออกแบบความเข้มของการอนุมัติเป็นระดับ (Tier) ตามความเสี่ยง
รายละเอียดการออกแบบ
ตัวอย่าง permission matrix ตามบทบาท
governance ทำงานด้วยนโยบายอย่างเดียวไม่ได้ ใส่ว่าใครเห็นอะไร ทำได้แค่ไหน และใครอนุมัติ ลงในตารางตามบทบาท
| บทบาท | ขอบเขตอ้างอิง | action ที่ทำได้ | สิทธิ์อนุมัติ |
|---|---|---|---|
| member | ความรู้สาธารณะของทีม | ตั้งคำถาม / คำตอบที่เสนอ | ไม่มี |
| channel admin | เอกสารและ Skill ของ channel | อนุมัติ Skill ตั้ง Routine | ภายใน channel ตน |
| tenant admin | ความรู้ทั้งบริษัทและ audit log | ออกแบบสิทธิ์ ตั้งข้อมูลที่กันออก | ทั้งบริษัท |
| auditor | audit log (อ่านอย่างเดียว) | ดูและ export log | ไม่มี |
รายละเอียดการออกแบบ
การออกแบบ Tier ของ HITL (การอนุมัติของคน)
แทนที่จะหยุดทุกอย่าง ให้ปรับความเข้มของการอนุมัติตามความเสี่ยงของ action ช่วงเรียนรู้ยังตื้นให้อนุมัติเข้ม และขยายอัตโนมัติเมื่อประวัติอนุมัติสะสมขึ้น
| Tier | ตัวอย่าง action | การอนุมัติ |
|---|---|---|
| Tier 0 (อัตโนมัติ) | คำตอบครั้งแรกพร้อมแหล่งอ้างอิง สรุป | ไม่ต้องอนุมัติ เก็บ log เท่านั้น |
| Tier 1 (ควร review) | ทำคำตอบเป็น Skill ยกเป็นขั้นตอนมาตรฐาน | อนุมัติโดยผู้ตรวจ |
| Tier 2 (ต้องอนุมัติ) | เขียนระบบภายนอก แจ้งเตือนแบบกลุ่ม | การอนุมัติชัดเจนจากผู้อนุมัติและ log |
| Tier 3 (จำกัด) | action ความเสี่ยงสูง เข้าถึงข้อมูลที่กันออก | ห้ามโดยหลักการ ข้อยกเว้นจัดการด้วย allowlist |
รายละเอียดการออกแบบ
ตัวอย่างรายการที่เก็บใน audit log
เพื่อให้ log อธิบายได้ภายหลัง ปริมาณการใช้ไม่พอ เก็บรายละเอียดมากพอที่จะสร้างใหม่ได้ว่าใครเห็นอะไร ทำไมจึงเสนอ และทำไปถึงไหน
| รายการ | สิ่งที่บันทึก | สิ่งที่อธิบายได้ |
|---|---|---|
| ผู้ทำ / ผู้อนุมัติ | ผู้ขอ ผู้ตรวจ ผู้อนุมัติ | ขอบเขตความรับผิดชอบและเส้นทางอนุมัติ |
| ประเภท action | คำตอบ การแก้ Skill การรัน Routine การแจ้งเตือน การเขียนภายนอก | action งานใดเกิดขึ้น |
| เป้าหมาย | Skill ID, channel, เอกสาร, ระบบภายนอก | ขอบเขตผลกระทบ |
| ข้อมูลอ้างอิง / ส่วนต่าง | แหล่งอ้างอิง เหตุผลการสร้าง การแก้ก่อน/หลัง | ทำไมจึงเสนอแบบนั้น |
| ผล / ต้นทุน / เวลา | สำเร็จ/ล้มเหลว เหตุผลล้มเหลว ต้นทุน timestamp | ผลและภาระการดำเนินงาน |
ตัวชี้วัด
ตัวชี้วัด governance สำหรับ pilot
ก่อนใส่ค่าที่วัดจริง ให้ระบุเป้าหมายการวัดให้ชัด ติดตาม approval ค้าง อัตราอนุมัติ Skill เหตุผลตีกลับ action ที่สร้างใหม่ได้จาก audit log และจำนวนข้อยกเว้น เพื่อใช้ตัดสิน rollout
approval ค้าง
flow อนุมัติขัดขวางงานไหม
อัตราอนุมัติ Skill
สัดส่วนที่ผ่าน review
เหตุผลตีกลับ
บันทึกและจัดหมวดเหตุผลปฏิเสธได้ไหม
การสร้าง log ใหม่
ตามรอย action จาก log ได้ไหม
action ข้อยกเว้น
ความถี่ของ action ความเสี่ยงสูง
ขั้นตอน
ขั้นตอนออกแบบ governance
Policy
กำหนดข้อมูลที่ใช้ได้
จัดทำแผนที่ data source, team และ user permission
Approval
แยก action ที่เสี่ยง
จัดระดับคำตอบ การแก้ Skill notification และ report ตามความเสี่ยง
Audit
ใช้ log เพื่อปรับปรุง
ทบทวน exception คำตอบผิด และ approval ที่ค้าง เพื่ออัปเดตกฎ
FAQ
FAQ เกี่ยวกับ AI Governance
ทุกคำตอบต้องอนุมัติไหม?
ไม่จำเป็น สามารถกำหนด approval เฉพาะ output สำคัญหรือมีความเสี่ยง
audit log ควรมีอะไร?
usage, skill edit, approval และ outcome ที่ช่วยอธิบาย และ ปรับปรุงงาน
แยกสิทธิ์ตามแผนกได้ไหม?
ได้ สามารถแยก data scope และผู้ใช้ตามทีม หรือ workflow
จัดการข้อมูลที่ต้องกันออกหรือข้อมูลส่วนบุคคลอย่างไร?
ก่อน pilot ให้แยกข้อมูลเป้าหมาย ข้อมูลที่กันออก สิทธิ์อ้างอิง และกฎเก็บ/ลบ กำหนดสิ่งที่ AI ห้ามเห็นก่อน แล้วตรวจการทำงานผ่าน approval log
เขียนข้อมูลไปยังระบบภายนอกอัตโนมัติได้ไหม?
งานความเสี่ยงสูงถือเป็นงานที่ต้องอนุมัติ การแจ้งเตือนแบบกลุ่ม การอัปเดต CRM และการเขียนระบบภายนอก ตรวจทีละขั้นโดยมีผู้อนุมัติที่ระบุชื่อและฟิลด์ log
ตรวจข้อกำหนดเช่นการรับรองหรือ region ของข้อมูลได้ไหม?
ได้ การรับรอง region การจัดเก็บ และการจัดการข้อมูลตามสัญญา ตรวจเป็นรายกรณีก่อน rollout และเก็บรายการที่ยังไม่สรุปไว้นอกขอบเขต pilot
ขั้นตอนถัดไป
ออกแบบ governance สำหรับ AI ใช้งานจริง
เราช่วยแปลง data scope, approval rule และ audit requirement เป็นแผน pilot