AI Agent ที่ไว้ใจได้ ต้องมีวงจรทดสอบและคุมสิทธิ์

Microsoft เพิ่งประกาศเรื่องสำคัญในงาน Build 2026 ที่ผมคิดว่าควรถูกอ่านในมุม operator มากกว่ามุม developer tool

ประกาศนั้นคือ open trust stack สำหรับ AI agents โดยมี 2 แกนหลัก:

ASSERT สำหรับเปลี่ยน policy และ requirement ให้กลายเป็น eval ที่รันกับ agent ได้

Agent Control Specification หรือ ACS สำหรับวาง runtime control ในจุดเสี่ยงของ agent workflow

ถ้าสรุปให้สั้นที่สุด:

Microsoft กำลังบอกว่า agent ที่จะเข้า production ต้องมีวงจรปิดระหว่าง policy, evaluation, runtime control, observability และ business value

นี่เป็นคนละเรื่องกับการถามว่า model ไหนฉลาดกว่า

เพราะในงานจริง ปัญหาใหญ่ไม่ใช่แค่ agent ตอบถูกหรือผิด

แต่คือ agent ทำงานภายใต้ขอบเขตที่องค์กรยอมรับได้หรือไม่

1) เกิดอะไรขึ้น

วันที่ 2 มิถุนายน 2026 Microsoft Foundry Blog เผยแพร่บทความ “Build agents you can trust across any framework with open evals and a control standard”

Microsoft ระบุว่าช่องว่างใหญ่ของ enterprise agent คือ written policy ยังไม่กลายเป็น runtime controls, การประเมิน safety ของ agent ใน context ที่เปลี่ยนตลอดเวลาทำได้ยาก และ control หลายอย่างกระจัดกระจายอยู่ใน prompt, code, gateway และ framework คนละจุด

เพื่อปิดช่องว่างนี้ Microsoft ประกาศ 2 โครงการ open source:

ASSERT หรือ Adaptive Spec-driven Scoring for Evaluation and Regression Testing

ACS หรือ Agent Control Specification ซึ่งเป็นมาตรฐาน runtime control แบบพกพา และเป็นส่วนหนึ่งของ Agent Governance Toolkit

ASSERT ถูกออกแบบให้เอา policy ขององค์กรและ requirement ของ use case มาแปลงเป็น test case ที่วัดได้ ไม่ใช่ใช้ benchmark กลางที่ไม่รู้จักงานของเรา

ACS ถูกออกแบบให้วาง control ใน 5 checkpoint ของ agent lifecycle:

1. input
2. LLM
3. state
4. tool execution
5. output

Microsoft เปรียบ ACS ว่าเป็นเหมือน MCP หรือ A2A ของ agent safety

แปลว่า MCP ช่วยให้ agent ต่อเครื่องมือได้ A2A ช่วยให้ agent คุยกันได้ ส่วน ACS พยายามสร้างภาษาเดียวกันสำหรับ control ที่บอกว่า agent ควรผ่านหรือควรถูกหยุดตรงไหน

2) ทำไมเรื่องนี้สำคัญกว่าคำว่า guardrails

คำว่า guardrails ถูกใช้เยอะมากจนเริ่มกว้างเกินไป

บางทีมหมายถึง system prompt บางทีมหมายถึง content filter บางทีมหมายถึง human approval บางทีมหมายถึง sandbox บางทีมหมายถึง monitoring หลังบ้าน

แต่การทำ agent production ต้องละเอียดกว่านั้น

คำถามที่ควรถามคือ:

• policy อยู่ที่ไหน
• แปลง policy เป็น test ได้ไหม
• test นั้นเจอ failure case จริงหรือเปล่า
• control ถูกวางก่อน tool call หรือหลัง output
• control เป็น deterministic หรือปล่อยให้ model ตัดสินเอง
• ถ้า control block แล้วมี log, trace และ reason ให้ audit ไหม
• เมื่อ agent เปลี่ยน model, prompt, tool หรือ memory แล้ว eval ยังผ่านไหม

ASSERT และ ACS น่าสนใจเพราะมันแยกบทบาทชัด:

ASSERT คือเครื่องมือหา failure

ACS คือภาษาสำหรับวาง control เพื่อจัดการ failure

แล้วต้องรัน ASSERT ซ้ำเพื่อพิสูจน์ว่า control ที่เพิ่มเข้าไปแก้ปัญหาได้จริง

นี่คือ loop ที่ธุรกิจควรเข้าใจ:

policy → eval → control → re-eval → observe → improve

ถ้าไม่มี loop นี้ เราอาจมี agent ที่ demo ดี แต่พอเจอข้อมูลจริง ลูกค้าจริง permission จริง และ edge case จริง กลับหลุดขอบเขตที่องค์กรรับไม่ได้

3) บทเรียนสำหรับธุรกิจไทย

หลายองค์กรไทยเริ่มใช้ AI Agent จาก use case ที่ดูง่าย เช่น:

• สรุป lead จาก inbox
• ร่างอีเมล follow-up
• วิเคราะห์ sales pipeline
• ทำ dashboard จาก spreadsheet
• สรุปเอกสารลูกค้า
• เปิด issue ให้ทีม dev
• เตรียมโพสต์ marketing
• ตอบคำถามจาก knowledge base

งานเหล่านี้ดูไม่อันตรายเท่าระบบ core banking หรือ infrastructure

แต่พอ agent แตะข้อมูลลูกค้า, email, CRM, website, finance document หรือเครื่องมือหลังบ้าน ความเสี่ยงจะเปลี่ยนทันที

ตัวอย่าง policy ที่ควรเขียนให้ชัดก่อนเริ่ม:

“agent อ่านข้อมูลลูกค้าได้ แต่ห้ามส่งออกนอกระบบ”

“agent ร่างอีเมลได้ แต่ห้ามกดส่งเอง”

“agent สร้าง report ได้ แต่ต้องอ้าง source ทุกตัวเลข”

“agent เปิด issue ได้ แต่ห้ามแก้ production”

“agent ใช้ข้อมูลจาก knowledge base ได้ แต่ถ้า confidence ต่ำต้อง escalate”

“agent ห้ามรวม tool A กับ tool B ในลักษณะที่ดึงข้อมูลส่วนตัวออกนอกระบบ”

พอเขียน policy แบบนี้ได้ ค่อยถามต่อว่า:

เรามี eval ที่พิสูจน์หรือยังว่า agent จะไม่ละเมิด policy

เรามี control ตรงจุด tool execution หรือยัง

เรามี log ที่บอกได้หรือยังว่า agent ถูก block เพราะอะไร

เรามี approval path ที่ไม่ทำให้คนเหนื่อยจนกดผ่านหมดหรือยัง

เราวัด ROI จาก task completion, time saved และ cost efficiency ได้หรือยัง

ถ้ายังไม่มี ควรเริ่มใน shadow mode ก่อน ให้ agent แนะนำ คนตรวจ และระบบเก็บ trace

4) เรื่องนี้ต่างจาก sandbox อย่างไร

ก่อนหน้านี้เราพูดถึง sandbox, containment และ Microsoft Execution Containers หรือ MXC ไปแล้ว

sandbox ตอบคำถามว่า:

“agent ถูกขังอยู่ในพื้นที่ไหน”

แต่ governance loop ตอบคำถามอีกชุด:

“agent ควรทำพฤติกรรมแบบไหน”

“เรารู้ได้อย่างไรว่ามันผิด policy”

“ถ้าผิด จะหยุดตรง checkpoint ไหน”

“หลังหยุดแล้วมี evidence ให้ audit ไหม”

“พอแก้ control แล้วผลลัพธ์ดีขึ้นจริงหรือเปล่า”

พูดง่าย ๆ:

sandbox ลด blast radius

eval และ control ลดโอกาสที่ agent จะทำผิด workflow ตั้งแต่แรก

observability ทำให้เรารู้ว่าเกิดอะไรขึ้น

ROI ทำให้ผู้บริหารรู้ว่าควรขยายหรือหยุด

ระบบ production ต้องการทั้งหมด ไม่ใช่เลือกอย่างใดอย่างหนึ่ง

5) มุมมองของผม

ผมคิดว่าปี 2026 จะเป็นปีที่คำว่า AI Agent เริ่มถูกแยกชัดขึ้น

agent ที่ demo เก่งจะยังมีเยอะ

แต่ agent ที่เข้า production ได้ ต้องตอบคำถามแบบ operator ได้:

1. งานนี้มี policy อะไร
2. policy ถูกแปลงเป็น eval แล้วหรือยัง
3. control อยู่ตรง checkpoint ไหน
4. tool call ไหนต้อง block, approve หรือ allow
5. trace และ replay ดูย้อนหลังได้ไหม
6. sensitive data ถูกตรวจตรงไหน
7. ถ้า agent drift หลังเปลี่ยน prompt หรือ model จะรู้ได้อย่างไร
8. agent สร้างมูลค่าทางธุรกิจจริงหรือแค่ดูยุ่งน้อยลง

นี่คือเหตุผลที่ผมมองว่า ASSERT และ ACS สำคัญ แม้ทีมเล็กอาจยังไม่ได้ใช้ Microsoft Foundry ทันที

เพราะมันบอก pattern ที่ทุกทีมควรเอาไปใช้:

อย่าเริ่ม agent production จากความสามารถ

ให้เริ่มจาก policy ที่วัดได้

จากนั้นค่อยสร้าง eval, control, approval, trace และ ROI รอบ workflow ที่เล็กพอจะดูแลได้จริง

AI Agent ที่ดีในองค์กรไม่ใช่ตัวที่ทำได้ทุกอย่าง

แต่คือตัวที่ทำงานหนึ่งอย่างได้ซ้ำ มีหลักฐาน และไม่ข้ามเส้นที่เรากำหนดไว้ครับ