ทำไม AI Agents ถึงจำเป็นต้องมีระบบกำกับดูแลก่อนเริ่มลงมือทำ

AI agents กำลังเปลี่ยนจากการตอบคำถามไปสู่การลงมือทำ

การเปลี่ยนแปลงเพียงอย่างเดียวนี้เปลี่ยนโมเดลความเสี่ยงทั้งหมด

Chatbots สร้างข้อความ Agents ดำเนินการระบบ

พวกมันสามารถอ่านอีเมล, เรียก API, อัปเดตบันทึกลูกค้า, ปรับใช้โค้ด, สร้างติcket, อนุมัติขั้นตอนการทำงาน, ประสานงานกับ agents ตัวอื่น, และจัดเก็บความรู้ใหม่ในหน่วยความจำระยะยาว

นั่นหมายความว่าคำถามหลักไม่ใช่:

คำตอบนี้ถูกต้องหรือไม่?

อีกต่อไป แต่เป็น:

agent นี้ควรได้รับอนุญาตให้ดำเนินการตอนนี้หรือไม่?

นั่นคือคำถามที่ governance layer มีไว้เพื่อตอบ

1. หน่วยความจำมีประโยชน์ แต่มันไม่ใช่ governance

หน่วยความจำช่วยให้ agents รักษาบริบทระหว่างเซสชันต่างๆ

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

• ข้อเท็จจริงใดที่ได้รับอนุญาตให้เข้าสู่หน่วยความจำ
• หน่วยความจำใดที่ล้าสมัยหรือถูกปนเปื้อน
• การกระทำใดที่ต้องได้รับการอนุมัติ
• ขั้นตอนการทำงานใดที่ต้องเกิดขึ้นต่อไป
• หลักฐานใดที่จำเป็นก่อนการดำเนินการ
• agent ใดที่ได้รับอนุญาตให้ใช้ข้อมูลใด

ในระบบ agent ระดับ production ปัญหาที่ยากกว่ามักไม่ใช่การดึงข้อมูล แต่คือ อำนาจ (authority)

หน่วยความจำช่วยให้ agent จดจำ

Governance ช่วยให้มันเลือกสิ่งที่มันได้รับอนุญาตให้ทำ

ความแตกต่างนี้คือจุดที่ Marrow อยู่

Marrow ไม่ใช่แค่ชั้นหน่วยความจำ มันคือ ชั้นการตัดสิน (judgment layer) สำหรับฝูง AI agent

2. การสังเกตการณ์อธิบายอดีต Agents ต้องการการควบคุมก่อนอนาคต

การสังเกตการณ์ (Observability) เป็นสิ่งจำเป็น ทีมงานต้องการ traces, logs, evaluations, annotations, alerts, และ dashboards

แต่การมองเห็นหลังเหตุการณ์ไม่ได้หยุดการกระทำที่ไม่ดีก่อนที่จะเกิดขึ้น

หาก agent ปรับใช้โค้ดที่ไม่ปลอดภัย, ส่งอีเมลที่ละเอียดอ่อน, อนุมัติการชำระเงินที่ผิด, หรือข้ามขั้นตอนการทำงานที่จำเป็น dashboard อาจอธิบายเหตุการณ์ในภายหลัง แต่มันไม่ได้ป้องกันมันเสมอไป

สำหรับเวิร์กโฟลว์ที่มีผลกระทบสูง สัญญาณต้องไปถึง agent ก่อนการดำเนินการ:

• ระดับความเสี่ยง
• หลักฐานที่จำเป็น
• ข้อจำกัดนโยบาย
• การอนุมัติจากเจ้าของ
• แผนการย้อนกลับ
• ขั้นตอนถัดไปที่แน่นอน
• อนุญาต, เตือน, ทบทวน, หรือบล็อก

นี่คือช่องว่างระหว่าง observability และ governance

Dashboards แจ้งให้มนุษย์ทราบ

Governance แจ้ง agents ก่อนที่พวกมันจะลงมือทำ

3. การประเมินคือภาพรวม Production คือกระแสข้อมูลที่ต่อเนื่อง

การประเมินก่อนปรับใช้ (Pre-deployment evaluation) จับความล้มเหลวได้มากมาย แต่ agents ใน production อาศัยอยู่ในสภาพแวดล้อมที่เปลี่ยนแปลง

Prompts เปลี่ยน เครื่องมือเปลี่ยน APIs เปลี่ยน ข้อมูลเปลี่ยน นโยบายเปลี่ยน Agents อื่นๆ ในฝูงก็เปลี่ยน

การวัดประสิทธิภาพ (benchmark) อาจบอกว่า agent ทำงานได้ดีภายใต้เงื่อนไขชุดหนึ่ง แต่ production ถามคำถามที่แตกต่าง:

agent นี้จะยังคงตัดสินใจได้ถูกต้องหรือไม่เมื่อสภาพแวดล้อมเปลี่ยนไป?

งานวิจัยเกี่ยวกับ agents ที่ใช้เครื่องมือก็ชี้ไปในทิศทางเดียวกัน

ToolEmu ศึกษา language-model agents ที่ใช้เครื่องมือที่มีความเสี่ยงสูง และแสดงให้เห็นว่าความล้มเหลวของ agents สามารถสร้างผลกระทบในโลกแห่งความเป็นจริงที่รุนแรง AgentHarm และ CUAHarm มุ่งเน้นไปที่พฤติกรรมที่เป็นอันตรายเมื่อ agents สามารถใช้เครื่องมือหรือควบคุมคอมพิวเตอร์ได้ งานวิจัยอื่นๆ แสดงให้เห็นว่า agents อาจเข้าใจความเสี่ยงในเชิงนามธรรม แต่ยังคงล้มเหลวในการหลีกเลี่ยงการกระทำที่มีความเสี่ยงในวิถีทางที่เป็นรูปธรรม

บทเรียนนั้นใช้ได้จริง:

ความปลอดภัยไม่สามารถอยู่ในแต่โมเดลหรือในแต่ benchmark เท่านั้น

Agents ใน production จำเป็นต้องมีการควบคุมขณะรันไทม์

4. Governance กำลังกลายเป็นโครงสร้างพื้นฐานของ AI

กรอบงาน governance AI ที่สำคัญกำลังมาบรรจบกันที่แนวคิดเดียวกัน: AI ที่รับผิดชอบต้องกลายเป็นสิ่งที่ปฏิบัติการได้

ไม่ใช่แค่หลักการ

ไม่ใช่แค่ PDF นโยบาย

ไม่ใช่แค่ dashboards

การปฏิบัติการ governance ต้องการ:

1. การจัดการความเสี่ยงที่ได้รับการบันทึกไว้
2. การบันทึกอัตโนมัติ
3. การดูแลโดยมนุษย์สำหรับการตัดสินใจที่มีผลกระทบสูง
4. การจัดการคุณภาพตลอดวงจรชีวิต
5. ความสามารถในการตรวจสอบย้อนกลับของพฤติกรรมระบบ
6. การติดตามหลังการวางตลาด
7. ความรับผิดชอบต่อผลลัพธ์ที่ไม่พึงประสงค์

สิ่งนี้ปรากฏชัดใน NIST AI RMF, NIST's Generative AI Profile, ISO/IEC 42001, OECD AI Principles, EU AI Act, OWASP's agentic AI risk taxonomy, และแนวทาง Five Eyes ปี 2026 เกี่ยวกับบริการ AI แบบ agentic

ทิศทางนั้นชัดเจน

ระบบ AI ในองค์กรต้องการหลักฐาน, การควบคุม, ความสามารถในการตรวจสอบย้อนกลับ, และความรับผิดชอบตลอดอายุการดำเนินงาน

สำหรับ AI agents นั่นหมายถึง governance ต้องย้ายเข้าไปอยู่ในรันไทม์

5. สิ่งที่ชั้น governance ของ agent ควรทำ

Governance layer คือระนาบควบคุม (control plane) ระหว่างรันไทม์ของ agent และระบบที่ agent สามารถส่งผลกระทบถึง

มันรับการกระทำที่ intended ของ agent, ประเมินมันเทียบกับนโยบาย, สิทธิ์, ความเสี่ยง, หลักฐาน, และผลลัพธ์ก่อนหน้านี้, จากนั้นส่งคืนการตัดสินใจที่สามารถบังคับใช้ได้:

อนุญาต (allow)

เตือน (warn)

ต้องทบทวน (review required)

บล็อก (block)

Governance layer ที่จริงจังต้องการฟังก์ชัน 9 ประการ

1. Identity และขอบเขตอำนาจ (scoped authority)

agent ทุกตัวต้องการตัวตนที่ชัดเจน, สิทธิ์ที่จำกัด, และข้อมูลรับรองที่มีขอบเขต

ฝูง agent ไม่สามารถถูกปกครองได้หาก agent ทุกตัวใช้คีย์ API เดียวกัน

1. นโยบายรันไทม์ (Runtime policy)

นโยบายต้องกลายเป็นเงื่อนไขรันไทม์ที่สามารถดำเนินการได้

ขั้นตอนไหนมาก่อน?

ต้องใช้หลักฐานอะไร?

การกระทำไหนที่ต้องทบทวนเสมอ?

การกระทำไหนที่ไม่ควรทำงานโดยอัตโนมัติ?

1. ประตูความเสี่ยง (Risk gates)

ระบบควรจำแนกการกระทำตามผลกระทบ, ความสามารถในการย้อนกลับ, ความอ่อนไหว, และบริบททางธุรกิจ

งานที่มีความเสี่ยงต่ำอาจทำงานอัตโนมัติ งานที่มีความเสี่ยงสูงอาจต้องการหลักฐาน, การอนุมัติ, หรือการบล็อก

1. ชุดหลักฐาน (Proof packs)

ก่อนการดำเนินการ agent ควรแนบหลักฐาน

ตัวอย่าง:

• ความครอบคลุมของการทดสอบ
• แผนการย้อนกลับ
• ข้อนโยบาย
• การยืนยันตัวตน
• การอนุมัติทางคลินิก
• การตรวจสอบบิล
• การลงนามโดยผู้บังคับบัญชา

1. การจัดเส้นทางการอนุมัติ (Approval routing)

การทบทวนโดยมนุษย์ไม่ควรเป็นคิวที่ต้องจัดการด้วยตนเองสำหรับทุกอย่าง

มันควรเป็นจุดตรวจสอบตามเงื่อนไขสำหรับการกระทำที่ต้นทุนของความผิดพลาดสูง

1. การตรวจสอบและการพิสูจน์แหล่งที่มา (Audit and provenance)

ทุกการตัดสินใจควรสามารถตรวจสอบย้อนกลับได้

ใครเป็นผู้ริเริ่ม?

ทำไมจึงอนุญาตหรือบล็อก?

นโยบายใดที่ใช้?

แนบหลักฐานอะไร?

ใครอนุมัติ?

เกิดอะไรขึ้นต่อไป?

1. การปิดผลลัพธ์ (Outcome closure)

Governance ไม่ได้จบลงที่อนุญาตหรือบล็อก

ระบบต้องปิดวงจร:

• การกระทำสำเร็จหรือไม่?
• มันล้มเหลวหรือไม่?
• ต้องย้อนกลับหรือไม่?
• ใครอนุมัติ?
• ควรเก็บบทเรียนอะไร?

1. Governance การเขียนหน่วยความจำ (Memory write governance)

ไม่ใช่ทุก log คือความรู้

ไม่ใช่ทุกชิ้นความรู้ควรมีอิทธิพลต่อ agent ทุกตัว

ผลลัพธ์ที่แท้จริงควรกลายเป็นหน่วยความจำผ่านการเขียนที่ควบคุมเท่านั้น

1. การเรียนรู้ระดับฝูง (Fleet-level learning)

Governance layer ควรติดตามพฤติกรรมทั่วทั้งฝูง:

• การเบี่ยงเบนจากเวิร์กโฟลว์พื้นฐาน
• การวนซ้ำลองใหม่
• ความล้มเหลวซ้ำๆ
• รูปแบบที่ควรเตือน agents ในอนาคต

นี่คือจุดที่ governance กลายเป็นมากกว่าข้อจำกัด มันกลายเป็นการเรียนรู้

6. Marrow ในฐานะกรณีศึกษา governance

Marrow ถูกออกแบบรอบวงรอบการทำงานที่เรียบง่าย:

orient -> think -> act -> check -> commit

แต่ละขั้นตอนมีฟังก์ชัน governance

Orient นำเสนอประวัติศาสตร์ที่เกี่ยวข้อง, คำเตือน, และข้อจำกัด

Think ประเมินการกระทำที่ตั้งใจก่อนที่จะเกิดขึ้น

Act ดำเนินการด้วยบริบทและการ์ดป้องกันที่แนบมา

Check ตรวจสอบว่าหลักฐานหรือการปิดผลลัพธ์ขาดหายไปหรือไม่

Commit บันทึกผลลัพธ์เพื่อให้การตัดสินใจครั้งต่อไปดีขึ้น

นี่คือความแตกต่างหลักระหว่างหน่วยความจำและการตัดสิน

หน่วยความจำถาม:

agent รู้ือะไร?

Marrow ถาม:

agent ควรลงมือทำ และภายใต้เงื่อนไขใด?

พื้นผิวผลิตภัณฑ์ (product surfaces) ของมันสอดคล้องกับ governance ขณะรันไทม์โดยตรง:

• decisionBrief() ให้บริบทก่อนการกระทำแก่ agent
• workflowGate() ส่งคืน อนุญาต, เตือน, ต้องทบทวน, หรือ บล็อก
• runGuarded() ห่อหุ้มงานเสี่ยงด้วยคำแนะนำก่อนการกระทำและการปิดผลลัพธ์
• agentRuntime() สอดแทรกบทเรียนและข้อกำหนดหลักฐานเข้าไปในบริบทของ agent
• agentStatus() แสดงว่า Marrow ทำงานอยู่และกำลังเก็บสัญญาณที่เป็นประโยชน์หรือไม่
• valueReport() เปลี่ยน governance ให้เป็นหลักฐานที่เจ้าของเห็นได้

กล่าวอีกนัยหนึ่ง:

Marrow เปลี่ยนผลลัพธ์ในอดีตให้เป็นการตัดสินก่อนการกระทำ

7. ตัวอย่างที่เป็นรูปธรรม: การปรับใช้ที่แย่

ลองนึกภาพ CI/CD agent ที่กำลังจะปรับใช้การเปลี่ยนแปลง webhook การชำระเงิน

Build ผ่าน

Branch พร้อมแล้ว

Agent กำลังจะ push ไปยัง production

แต่ pull request ขาดสามสิ่ง:

1. ความครอบคลุมของการทดสอบ
2. แผนการย้อนกลับ
3. การทดสอบเบื้องต้น (smoke test)

หากไม่มี governance การปรับใช้อาจผ่านไปได้

ความล้มเหลวในการชำระเงินปรากฏขึ้นในอีกไม่กี่ชั่วโมงต่อมา ลูกค้าได้รับผลกระทบ วิศวกรที่อยู่เวทย้อนกลับด้วยตนเอง เหตุการณ์กลายเป็น postmortem อีกครั้ง

หากมี governance, workflow gate จะทำงานก่อนปรับใช้

มันส่งคืน:

ระดับความเสี่ยง: สูง

ชุดหลักฐานขาดหาย

การปรับใช้ถูกบล็อก

Agent ไม่ได้แค่บันทึกมากขึ้นอีกต่อไป มันถูกบังคับให้หยุดที่จุดที่ถูกต้อง

นั่นคือคุณค่าของ governance ก่อนการกระทำ

8. ตัวชี้วัดที่เหมาะสมสำหรับ governance ของ agent

Governance layer ไม่ควรนับแค่ logs

มันควรวัดว่าฝูง agent ปลอดภัยขึ้น, สม่ำเสมอขึ้น, และตรวจสอบได้ง่ายขึ้นหรือไม่

ตัวชี้วัดที่มีประโยชน์ได้แก่:

• ความครอบคลุมการกระทำ (Action coverage): การกระทำที่มีผลกระทบสูงกี่รายการที่ผ่าน gate
• อัตราการทำชุดหลักฐานครบ (Proof completion rate): การกระทำกี่รายการที่รวมหลักฐานที่จำเป็นก่อนดำเนินการ
• อัตราการปิดผลลัพธ์ (Outcome closure rate): การตัดสินใจกี่รายการที่ปิดด้วยผลลัพธ์จริง
• การป้องกันความล้มเหลวซ้ำ (Prevented repeat failures): บ่อยแค่ไหนที่รูปแบบความล้มเหลวที่รู้จักถูกหลีกเลี่ยง
• ความรุนแรงของการเบี่ยงเบน (Drift severity): agents เคลื่อนห่างจากเวิร์กโฟลว์ที่อนุมัติไปไกลแค่ไหน
• อัตราผลบวกปลอม (False positive rate): gate บล็อกมากเกินไปบ่อยแค่ไหน
• อัตราผลลบปลอม (False negative rate): การกระทำที่เป็นอันตรายหลุดรอดไปบ่อยแค่ไหน
• ระยะเวลาในการสร้างบันทึกการตรวจสอบใหม่ (Audit reconstruction time): ใช้เวลานานเท่าใดในการอธิบายการตัดสินใจ
• ความแม่นยำของการทบทวนโดยมนุษย์ (Human review precision): การอนุมัติของมนุษย์ถูกใช้สำหรับการกระทำที่ถูกต้องหรือไม่

Governance มีประโยชน์เมื่อมันลดการย้อนกลับ, ป้องกันเหตุการณ์ซ้ำ, ทำให้การทบทวนที่ไม่จำเป็นแคบลง, และทำให้พฤติกรรมของ agent พิสูจน์ได้ง่ายขึ้น

ไม่อย่างนั้นมันจะกลายเป็น compliance theater (การแสดงเพื่อให้ผ่านข้อกำหนด)

9. Governance layer ก็มีความเสี่ยงเช่นกัน

Governance layer ก็สามารถล้มเหลวได้เช่นกัน

มันสามารถถูกตั้งค่าผิดได้ นโยบายสามารถล้าสมัย หลักฐานสามารถไม่สมบูรณ์ Gates สามารถบล็อกมากเกินไป ผู้โจมตีสามารถกำหนดเป้าหมายไปที่ control plane หากมันจัดเก็บข้อมูลที่ละเอียดอ่อนมากเกินไป มันจะกลายเป็นจุดรวมความเสี่ยง

ดังนั้น governance layer เองก็ต้องมีวินัย:

1. สิทธิพิเศษน้อยที่สุดโดยค่าเริ่มต้น Agents ควรได้รับสิทธิ์ที่จำเป็นเท่านั้น ในช่วงเวลาที่จำเป็นเท่านั้น
2. ปิดเมื่อล้มเหลวสำหรับการกระทำที่มีผลกระทบสูง หากการกระทำสามารถก่อให้เกิดอันตรายร้ายแรง หลักฐานที่ขาดหายควรหยุดการดำเนินการ
3. ล้มเหลวแบบนุ่มนวลสำหรับระบบอัตโนมัติที่มีความเสี่ยงต่ำ ไม่ใช่ทุกการกระทำที่สมควรได้รับแรงเสียดทานในระดับเดียวกัน
4. หลักฐานที่มนุษย์อ่านได้, นโยบายที่เครื่องอ่านได้ ผู้ปฏิบัติงานต้องเข้าใจการตัดสินใจ ระบบต้องบังคับใช้มัน
5. การเรียนรู้จากผลลัพธ์จริง หากไม่มีการปิดผลลัพธ์ ระบบจะสะสม logs ไม่ใช่การตัดสิน

10. บทสรุป

AI agents ผลักดันซอฟต์แวร์ไปสู่โมเดลการดำเนินงานใหม่

พวกมันสามารถเลือกเครื่องมือ, ประสานงานกับ agents อื่น, ปรับเปลี่ยนระบบ, และสร้างผลกระทบ

ในโมเดลนั้น governance ไม่ใช่ layer ที่เพิ่มหลังการปรับใช้ มันอยู่ภายในรันไทม์

หน่วยความจำ, การสังเกตการณ์, การประเมิน, และการทบทวนโดยมนุษย์ล้วนมีความสำคัญ แต่แต่ละอย่างแก้ปัญหาได้เพียงบางส่วน

Governance layer เชื่อมโยง它们ให้เป็นวงรอบการกระทำที่รับผิดชอบ:

นโยบายก่อนการกระทำ หลักฐานก่อนการดำเนินการ อำนาจระหว่างการกระทำ ผลลัพธ์หลังการกระทำ การเรียนรู้ทั่วทั้งฝูง

นั่นคือแนวคิดหลักเบื้องหลัง Marrow

ฝูง AI agent ไม่ได้เพียงแค่ต้องการจดจำมากขึ้น

พวกมันต้องการการตัดสินที่ดีขึ้นก่อนที่จะลงมือทำ

อ้างอิง

1. NIST. AI Risk Management Framework
2. NIST. Generative AI Profile, NIST AI 600-1
3. OECD. หลักการ AI ของ OECD
4. European Commission AI Act Service Desk. ข้อ 9: ระบบการจัดการความเสี่ยง
5. European Commission AI Act Service Desk. ข้อ 12: การบันทึกข้อมูล
6. European Commission AI Act Service Desk. ข้อ 14: การดูแลโดยมนุษย์
7. European Commission AI Act Service Desk. ข้อ 17: ระบบการจัดการคุณภาพ