AIエージェントのガバナンスとは、自律的にタスクを計画・実行するAIエージェントの行動を、権限管理・ガードレール・監査の仕組みで組織的に制御する取り組みである。

การกำกับดูแล AI เอเจนต์ (AI Agent Governance) คือความพยายามในการควบคุมพฤติกรรมของ AI เอเจนต์ที่วางแผนและดำเนินงานตามภารกิจอย่างอิสระ ด้วยกลไกการจัดการสิทธิ์ (Permission Management), การกำหนดขอบเขตป้องกัน (Guardrails) และการตรวจสอบ (Auditing) ภายในองค์กร ต่างจาก AI รูปแบบแชททั่วไปตรงที่เอเจนต์สามารถเข้าถึงและจัดการระบบหรือข้อมูลภายนอกได้โดยตรง ดังนั้นการทำงานที่ผิดพลาดอาจส่งผลโดยตรงต่อการทำลายข้อมูลทางธุรกิจหรือก่อให้เกิดความล้มเหลวแบบลูกโซ่ได้ ในบทความนี้ เราจะอธิบายกรอบการทำงานเชิงปฏิบัติเพื่อลดความเสี่ยงจากการทำงานแบบอัตโนมัติเป็นลำดับขั้น สำหรับแผนกสารสนเทศและผู้รับผิดชอบด้านการส่งเสริม AI ที่ดูแลการนำ AI เอเจนต์ไปใช้งาน ตั้งแต่การกำหนดขอบเขตอำนาจหน้าที่ การออกแบบ Guardrails บันทึกการตรวจสอบ (Audit Logs) ไปจนถึงการขยายขอบเขตสู่สภาพแวดล้อมแบบ Multi-agent โดยมีเป้าหมายเพื่อให้ผู้อ่านได้รับข้อมูลที่จำเป็นในการตัดสินใจว่า "ควรเตรียมการสิ่งใดและตามลำดับอย่างไร" สำหรับแผนการนำเอเจนต์ไปใช้งานในองค์กรของตนเอง

AIエージェントは「読む・答える」から「操作する・実行する」へとAIの役割を変えた。この変化が、従来のAIガバナンスではカバーしきれない新しいリスクを生んでいる。 なぜ今エージェント固有のガバナンスが必要なのかを、リスクの種類・従来型ガバナンスとの違い・規制動向の3つの観点から整理する。

AIエージェントは「読む・答える」から「操作する・実行する」へとAIの役割を変えた。この変化が、従来のAIガバナンスではカバーしきれない新しいリスクを生んでいる。 なぜ今エージェント固有のガバナンスが必要なのかを、リスクの種類・従来型ガバナンスとの違い・規制動向の3つの観点から整理する。

(หมายเหตุ: ข้อความต้นฉบับเป็นภาษาญี่ปุ่นและไม่มีการระบุให้แปลเป็นภาษาอื่นนอกเหนือจากที่ระบุไว้ในคำสั่ง แต่เนื่องจากคำสั่งระบุให้แปลเป็นภาษาไทย นี่คือฉบับแปลครับ)

AI Agent ได้เปลี่ยนบทบาทของ AI จากการ "อ่านและตอบคำถาม" ไปสู่การ "ควบคุมและลงมือทำ" การเปลี่ยนแปลงนี้ก่อให้เกิดความเสี่ยงใหม่ๆ ที่ธรรมาภิบาล AI (AI Governance) แบบเดิมไม่สามารถครอบคลุมได้ บทความนี้จะสรุปเหตุผลว่าทำไมเราจึงจำเป็นต้องมีธรรมาภิบาลเฉพาะสำหรับ Agent ในปัจจุบัน โดยแบ่งออกเป็น 3 มุมมอง ได้แก่ ประเภทของความเสี่ยง, ความแตกต่างจากธรรมาภิบาลแบบเดิม และแนวโน้มด้านกฎระเบียบ

ข้อผิดพลาดของ AI แบบแชทจะจบลงที่ "การแสดงข้อความที่ผิดพลาด" เท่านั้น การตัดสินใจว่าจะดำเนินการหรือไม่นั้นขึ้นอยู่กับมนุษย์ ดังนั้นด่านสุดท้ายในการป้องกันจึงอยู่ที่ฝั่งมนุษย์เสมอ แต่สำหรับ Agent นั้นจะทำลายด่านป้องกันนี้ทิ้งและเข้าไปควบคุม API, ฐานข้อมูล และ SaaS โดยตรง เราจึงต้องตระหนักว่าธรรมชาติของความเสี่ยงได้เปลี่ยนไปอย่างสิ้นเชิง

ความเสี่ยงที่เป็นตัวแทนหลักสามารถแบ่งออกได้เป็น 4 ประเภทดังนี้:

• การเบี่ยงเบนจากเจตนา (Intent Deviation): การตีความคำสั่งที่คลุมเครือเกินความจำเป็น ตัวอย่างเช่น คำสั่งที่ว่า "ช่วยจัดการข้อมูลเก่าให้หน่อย" อาจถูกตีความและดำเนินการเป็นการลบข้อมูลแทนที่จะเป็นการจัดเก็บเข้าคลัง (Archive)
• การใช้อำนาจเกินขอบเขต (Excessive Agency): Agent ที่ถือสิทธิ์เกินความจำเป็นสำหรับงานนั้นๆ อาจเข้าไปแก้ไขทรัพยากรที่ไม่ควรแตะต้อง ซึ่งในรายการความเสี่ยงด้านความปลอดภัยสำหรับแอปพลิเคชัน LLM ของ OWASP ก็ได้ระบุเรื่องนี้ไว้เป็นหัวข้อแยกต่างหากในชื่อ "Excessive Agency"
• การถูกยึดครองผ่าน Prompt Injection: การที่ Agent ถูกสั่งให้ดำเนินการตามเจตนาของผู้โจมตี ผ่านคำสั่งที่แฝงอยู่ในเนื้อหาภายนอกที่ Agent อ่าน (เช่น อีเมล, หน้าเว็บ, เอกสาร)
• ความล้มเหลวแบบลูกโซ่ (Cascading Failures): การดำเนินการที่ผิดพลาดเพียงครั้งเดียวไปกระตุ้นกระบวนการอัตโนมัติในขั้นตอนถัดไป ทำให้ความเสียหายขยายวงกว้าง เช่น การอัปเดตข้อมูลสต็อกสินค้าที่ผิดพลาด ส่งผลกระทบต่อเนื่องไปถึงระบบการสั่งซื้อและการออกใบแจ้งหนี้อัตโนมัติ

ทั้งหมดนี้ไม่ใช่ปัญหาเรื่อง "คุณภาพของผลลัพธ์" แต่เป็นปัญหาเรื่อง "ความปลอดภัยในการปฏิบัติงาน" ซึ่งไม่สามารถแก้ไขได้ด้วยการเพิ่มความแม่นยำของโมเดลเพียงอย่างเดียว

従来のAIガバナンスは、モデルの出力品質——正確性・バイアス・説明可能性——を管理することが中心だった。エージェントガバナンスでは管理対象が「出力」から「行動」へ移る。両者の違いを整理すると次のようになる。

重要なのは、エージェントガバナンスが従来型を置き換えるのではなく上に積み重なることだ。出力品質の管理は引き続き必要で、そこに行動制御の層が加わる。既にAI利用ガイドラインを整備済みの組織でも、エージェント導入時には「行動」に関する規定を別途追加する必要がある。

ในด้านกฎระเบียบ ข้อกำหนดสำหรับ AI ที่ทำงานอย่างอิสระ (Autonomous AI) มีความเข้มงวดขึ้นอย่างชัดเจน

EU AI Act ได้นำแนวทางแบบอิงตามความเสี่ยง (Risk-based approach) มาใช้ โดยกำหนดให้ระบบ AI ที่ถูกจัดอยู่ในกลุ่มความเสี่ยงสูงต้องมีการบันทึก Log, การกำกับดูแลโดยมนุษย์ (Human oversight) และการจัดตั้งระบบบริหารจัดการความเสี่ยง หาก AI Agent เข้าไปมีส่วนเกี่ยวข้องกับการประเมินผลงานพนักงาน การตัดสินใจด้านสินเชื่อ หรือการควบคุมโครงสร้างพื้นฐานที่สำคัญ ก็อาจเข้าข่ายต้องปฏิบัติตามข้อกำหนดเหล่านี้เช่นกัน ในส่วนของ AI Risk Management Framework (AI RMF) จาก NIST ของสหรัฐอเมริกาก็ได้กำหนดให้ Govern (การกำกับดูแล) เป็นฟังก์ชันหลัก และเรียกร้องให้มีระบบการจัดการเชิงองค์กรต่อการกระทำของ AI สำหรับในญี่ปุ่น แนวทางปฏิบัติสำหรับผู้ประกอบการ AI ของรัฐบาลก็ได้ระบุให้การรับรองความปลอดภัยของ AI และการกำกับดูแลโดยมนุษย์เป็นหลักการพื้นฐาน

นอกเหนือจากการปฏิบัติตามกฎระเบียบแล้ว สิ่งที่มักถูกมองข้ามคือ การเชื่อมโยงกับระบบการควบคุมภายใน (Internal Control) หาก AI Agent เข้าไปจัดการข้อมูลทางบัญชีหรือบันทึกการทำธุรกรรม การกระทำเหล่านั้นย่อมตกเป็นเป้าหมายของการตรวจสอบภายใต้ระบบ IT Control ที่มีอยู่เดิม (เช่น การจัดการสิทธิ์เข้าถึง, การจัดการการเปลี่ยนแปลง, และการแบ่งแยกหน้าที่) ข้ออ้างที่ว่า "เป็น AI จึงเป็นข้อยกเว้น" นั้นใช้ไม่ได้ และในทางกลับกัน เนื่องจากเป็นการทำงานแบบอัตโนมัติ จึงยิ่งจำเป็นต้องมีหลักฐานการควบคุมที่เข้มงวดกว่าเดิม หากออกแบบระบบธรรมาภิบาล (Governance) ไว้ทีหลัง อาจมีความเสี่ยงที่การนำระบบมาใช้งานจริงจะต้องหยุดชะงักในขั้นตอนการตรวจสอบได้

ก่อนที่จะเริ่มติดตั้ง Guardrail สิ่งที่เป็นจุดเริ่มต้นคือการกำหนดให้ชัดเจนเป็นลายลักษณ์อักษรว่า "จะมอบหมายงานอะไรและมากน้อยแค่ไหนให้กับ Agent" สิ่งที่ต้องตัดสินใจในขั้นตอนการเตรียมการมี 3 ประการ ได้แก่ ขอบเขตอำนาจ (Authority Scope), การประเมินความเสี่ยง (Risk Assessment) และขั้นตอนการอนุมัติ (Approval Flow) หากเริ่มดำเนินการติดตั้งโดยที่ส่วนนี้ยังคลุมเครือ กระบวนการในขั้นตอนถัดไปทั้งหมดจะกลายเป็นการแก้ปัญหาเฉพาะหน้าไปเรื่อยๆ

สิ่งที่ควรทำเป็นอันดับแรกคือการสำรวจการดำเนินการทั้งหมดที่เอเจนต์ (Agent) จะต้องทำและจำกัดสิทธิ์ให้เหลือน้อยที่สุด หลักการพื้นฐานคือ หลักการให้สิทธิ์น้อยที่สุด (Principle of Least Privilege) ซึ่งเป็นหลักการคลาสสิกด้านความปลอดภัย โดยสรุปคือ "การให้สิทธิ์เพียงเท่าที่จำเป็นต่อการปฏิบัติงานเท่านั้น"

การดำเนินการสามารถจัดระเบียบได้ง่ายโดยแบ่งออกเป็น 4 ระดับ ดังนี้:

1. การอ่าน (Read): ดูข้อมูลได้เพียงอย่างเดียว ผลกระทบจำกัดอยู่แค่ความเสี่ยงในการรั่วไหลของข้อมูล
2. การเขียน/อัปเดต (Write/Update): การแก้ไขข้อมูลที่มีอยู่ หากเกิดความผิดพลาดจะต้องมีขั้นตอนการกู้คืนข้อมูล
3. การลบ (Delete): ในหลายกรณีไม่สามารถย้อนกลับได้ โดยหลักการแล้วไม่ควรให้สิทธิ์นี้แก่เอเจนต์
4. การส่งข้อมูลออกภายนอก (External Transmission): เช่น การส่งอีเมล การเรียกใช้ API ภายนอก หรือการชำระเงิน เนื่องจากส่งผลกระทบต่อภายนอกองค์กร จึงต้องจัดการด้วยความระมัดระวังสูงสุด

จากนั้นให้กำหนด ขอบเขตการทำงาน (Execution Boundaries) โดยระบุเป็นลายลักษณ์อักษรให้ชัดเจน ได้แก่ "รายการระบบที่อนุญาตให้เข้าถึงได้" "ขอบเขตของข้อมูลที่อนุญาตให้จัดการได้ (ตาราง, โฟลเดอร์, กลุ่มลูกค้า)" และ "ขีดจำกัดจำนวนครั้งหรือมูลค่าต่อครั้ง/ต่อวัน"

ในด้านการนำไปใช้งาน สิ่งสำคัญคือต้องออก Service Account แยกสำหรับเอเจนต์โดยเฉพาะ และห้ามใช้ ID ของมนุษย์ร่วมกัน เอเจนต์ที่ทำงานด้วยข้อมูลยืนยันตัวตนเดียวกับมนุษย์จะไม่สามารถแยกแยะออกจากกิจกรรมของมนุษย์ได้ในบันทึก (Log) ซึ่งจะทำให้การตรวจสอบ (Audit) และการสืบสวนเหตุการณ์ผิดปกติ (Incident Investigation) ไม่สามารถทำได้

การใช้มาตรการควบคุมเดียวกันกับทุกการปฏิบัติงานจะทำให้การดำเนินงานล้มเหลว เครื่องมือสำหรับประเมินความเสี่ยงและปรับเปลี่ยนระดับความเข้มงวดของมาตรการควบคุมสำหรับแต่ละการปฏิบัติงานคือ Risk Assessment Matrix (เมทริกซ์การประเมินความเสี่ยง) โดยแนะนำให้ใช้แกนประเมิน 2 แกน ได้แก่ "ระดับผลกระทบ" (Impact) และ "ความสามารถในการย้อนกลับ" (Reversibility)

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

ประเด็นสำคัญคือการนำเมทริกซ์นี้ไป ประยุกต์ใช้ในระดับเครื่องมือ (API) ไม่ใช่การตัดสินที่ระดับความละเอียดว่า "Agent นี้เชื่อถือได้หรือไม่" แต่ให้ตัดสินจาก "การปฏิบัติงานนี้อยู่ในช่องใด" ซึ่งจะช่วยให้สามารถปรับเปลี่ยนความเข้มงวดของมาตรการควบคุมได้แม้จะเป็น Agent ตัวเดียวกันก็ตาม

การกำกับดูแล Agent ไม่สามารถทำได้โดยแผนกไอทีเพียงฝ่ายเดียว อย่างน้อยที่สุดต้องมีการจัดสรรบทบาทของผู้ที่เกี่ยวข้องดังต่อไปนี้:

• หน่วยงานธุรกิจ (เจ้าของ Agent): รับผิดชอบในการตัดสินใจว่าจะมอบหมายงานใด และประเมินผลกระทบทางธุรกิจ
• แผนกไอที: จัดเตรียมการตั้งค่าสิทธิ์ สภาพแวดล้อมการทำงาน และระบบบันทึกข้อมูล (Log)
• แผนกความปลอดภัย: ตรวจสอบความเหมาะสมของระบบป้องกัน (Guardrails) และรับมือกับเหตุการณ์ไม่พึงประสงค์
• ฝ่ายกฎหมายและกำกับดูแล: ตรวจสอบข้อกำหนดทางกฎหมายและข้อจำกัดตามสัญญา

สิ่งที่สำคัญที่สุดคือ ต้องมีการกำหนดเจ้าของจากหน่วยงานธุรกิจให้กับ Agent ทุกตัว เพราะ Agent ที่ไม่มีเจ้าของจะไม่ได้รับการปรับปรุงตามความต้องการที่เปลี่ยนไป และจะถูกปล่อยทิ้งไว้จนกลายเป็นแหล่งสะสมของระบบป้องกันที่ไร้ประสิทธิภาพ

ขั้นตอนการอนุมัติจะนำไปปฏิบัติได้ง่ายกว่าหากรวมเข้ากับกระบวนการจัดการการเปลี่ยนแปลงด้านไอที (IT Change Management) ที่มีอยู่เดิม แทนที่จะสร้างขึ้นใหม่ โดยให้กำหนดเหตุการณ์ที่ต้องมีการจัดการการเปลี่ยนแปลง 3 ประการ ได้แก่ "การนำ Agent ใหม่มาใช้", "การเปลี่ยนแปลงขอบเขตสิทธิ์" และ "การเปลี่ยนแปลงการตั้งค่าระบบป้องกัน" แล้วดำเนินการผ่านวงจรการขออนุมัติ การอนุมัติ และการบันทึกข้อมูลเช่นเดียวกับการเปลี่ยนแปลงระบบทั่วไป

การวางแนวป้องกัน (Guardrails) โดยพื้นฐานแล้วควรแบ่งเป็น 3 ชั้น ได้แก่ "การป้อนข้อมูล (Input)", "การประมวลผล (Execution)" และ "การแสดงผล (Output)" การป้องกันเพียงชั้นเดียวจะถูกเจาะผ่านด้วยเส้นทางที่ไม่คาดคิดได้ในที่สุด บทความนี้จะอธิบายถึงรูปแบบการนำไปใช้งานในแต่ละชั้น และแนวคิดในการแบ่งระดับความเข้มงวดของการควบคุม

入力側のフィルタリングで最優先すべきは、エージェントが取り込む外部コンテンツの無害化だ。メール・Webページ・添付ファイルには、エージェントへの指示を装った文字列（プロンプトインジェクション）が含まれうる。外部由来のテキストはすべて「信頼できないデータ」として扱い、システム側の指示と明確に分離して渡す設計にする。インジェクション検知パターンによる事前スクリーニングも併用する。

実行段階ではツール呼び出しの引数検証が要になる。LLMが生成したAPI引数をそのまま実行せず、スキーマ検証（型・範囲・形式）と許可リスト照合を挟む。「SQLを自由に生成して実行」ではなく「定義済みクエリのパラメータだけを埋める」形に制約するだけで、リスクは大きく下がる。

出力側では、エージェントの応答や生成物に対して、個人情報・認証情報・機密区分データのマスキングを行う。エージェントが社内データを読める以上、その内容が意図せず外部向けの出力に混ざる経路を常に想定しておく必要がある。

สิ่งที่ต้องให้ความสำคัญเป็นอันดับแรกในการกรองข้อมูลขาเข้าคือ การทำให้เนื้อหาภายนอก (External Content) ที่เอเจนต์ดึงเข้ามานั้นปลอดภัย อีเมล หน้าเว็บ และไฟล์แนบอาจมีข้อความที่แฝงคำสั่งถึงเอเจนต์ (Prompt Injection) อยู่ ข้อมูลที่เป็นข้อความจากภายนอกทั้งหมดควรได้รับการปฏิบัติเสมือนเป็น "ข้อมูลที่ไม่น่าเชื่อถือ" และต้องออกแบบให้แยกออกจากคำสั่งของระบบอย่างชัดเจนก่อนส่งต่อ นอกจากนี้ ควรใช้การคัดกรองล่วงหน้าด้วยรูปแบบการตรวจจับ Injection ควบคู่กันไปด้วย

ในขั้นตอนการดำเนินการ การตรวจสอบอาร์กิวเมนต์ของการเรียกใช้เครื่องมือ (Tool Call Argument Validation) ถือเป็นหัวใจสำคัญ ห้ามนำอาร์กิวเมนต์ API ที่ LLM สร้างขึ้นไปดำเนินการทันที แต่ต้องผ่านการตรวจสอบสกีมา (ประเภทข้อมูล, ช่วงข้อมูล, รูปแบบ) และการตรวจสอบกับรายการที่อนุญาต (Allowlist) การจำกัดรูปแบบให้เป็นเพียง "การเติมพารามิเตอร์ลงในคิวรีที่กำหนดไว้ล่วงหน้า" แทนที่จะเป็น "การสร้างและรัน SQL อย่างอิสระ" จะช่วยลดความเสี่ยงลงได้อย่างมาก

ในส่วนของขาออก ต้องมีการทำ Masking ข้อมูลส่วนบุคคล ข้อมูลรับรองความถูกต้อง (Credentials) และข้อมูลที่เป็นความลับในคำตอบหรือผลลัพธ์ที่เอเจนต์สร้างขึ้น เนื่องจากเอเจนต์สามารถอ่านข้อมูลภายในองค์กรได้ จึงจำเป็นต้องคาดการณ์ช่องทางที่เนื้อหาเหล่านั้นอาจหลุดรอดไปปะปนกับข้อมูลขาออกที่ส่งไปยังภายนอกโดยไม่ตั้งใจอยู่เสมอ

การ์ดเรล (Guardrails) แบ่งออกเป็น Hard Limit ที่ไม่สามารถละเมิดได้ และ Soft Limit ที่โดยหลักการแล้วต้องปฏิบัติตามแต่สามารถถูกละเมิดได้ หากไม่ตระหนักถึงความแตกต่างนี้ จะนำไปสู่ความเชื่อที่อันตรายว่า "ปลอดภัยแล้วเพราะเขียนคำสั่งห้ามไว้ใน Prompt"

หลักการในการเลือกใช้งานนั้นชัดเจน คือ ความเสี่ยงที่ร้ายแรงและไม่สามารถย้อนกลับได้ ต้องหยุดด้วย Hard Limit เท่านั้น การสั่งงานผ่าน Prompt เป็นเพียงส่วนเสริม และต้องตั้งอยู่บนสมมติฐานว่าอาจถูกละเมิดได้จากการทำ Prompt Injection หรือการตีความที่ผิดพลาด

ในทางกลับกัน Soft Limit เหมาะสำหรับการควบคุม "พฤติกรรมที่พึงประสงค์" เช่น รูปแบบการเขียน ลำดับความสำคัญ หรือเกณฑ์การตัดสินใจ การใช้ Hard Limit กับทุกอย่างจะทำให้ต้นทุนในการปรับเปลี่ยนสูงขึ้น ดังนั้นทางออกที่เป็นจริงคือการผสมผสานทั้งสองอย่างเข้าด้วยกันตามระดับความเสี่ยงในตารางประเมินความเสี่ยง (Risk Assessment Matrix)

Human-in-the-loop (HITL) คือการนำไปใช้งานที่สอดคล้องกับช่อง "การอนุมัติล่วงหน้า" (Pre-approval) ในเมทริกซ์การประเมินความเสี่ยง จุดสำคัญของการออกแบบอยู่ที่ว่าจะวางการอนุมัติไว้ที่ไหนและมากน้อยเพียงใด

ความผิดพลาดที่พบบ่อยที่สุดคือการใส่ขั้นตอนการอนุมัติไว้ในทุกการดำเนินการเพียงเพราะความกังวล การที่มนุษย์ต้องคอยตรวจสอบคำขออนุมัติหลายสิบรายการต่อวันอย่างต่อเนื่องนั้นเป็นไปไม่ได้ และภายในเวลาไม่กี่สัปดาห์ก็จะนำไปสู่สภาวะที่ "กดปุ่มอนุมัติโดยไม่ดูเนื้อหา" ซึ่งก็คือการที่การอนุมัติกลายเป็นเพียงพิธีกรรมที่ไร้ความหมาย (Formalism) ซึ่งในกรณีนี้อาจอันตรายยิ่งกว่าการไม่มีการอนุมัติเสียอีก เพราะมันทิ้งไว้เพียงความรู้สึกปลอดภัยที่ผิดๆ ว่ามีการตรวจสอบแล้ว

ประเด็นสำคัญในการออกแบบเพื่อป้องกันไม่ให้การอนุมัติกลายเป็นเพียงพิธีกรรมมี 3 ข้อดังนี้:

1. จำกัดขอบเขตสิ่งที่ต้องอนุมัติ: จำกัดเฉพาะการดำเนินการที่ไม่สามารถย้อนกลับได้หรือมีผลกระทบสูงเท่านั้น ส่วนที่เหลือให้ใช้วิธีการตรวจสอบย้อนหลัง (Post-review)
2. รวบรวมข้อมูลที่จำเป็นสำหรับการอนุมัติไว้ในหน้าเดียว: นำเสนอข้อมูลว่ากำลังจะทำอะไร ทำไม และทำกับข้อมูลชุดไหน ในรูปแบบที่สามารถตัดสินใจได้ทันทีโดยไม่ต้องไปสืบค้นเพิ่ม
3. กำหนดให้การหมดเวลา (Timeout) เป็นการปฏิเสธโดยค่าเริ่มต้น: หลีกเลี่ยงการออกแบบที่ "ดำเนินการอัตโนมัติ" หากปล่อยคำขออนุมัติทิ้งไว้โดยเด็ดขาด ตามหลักการ Fail-safe หากไม่มีการตอบสนอง ให้เลือกฝั่งที่หยุดการทำงานไว้ก่อน

นอกจากนี้ การกำหนดเส้นทางการยกระดับ (Escalation path) ว่าควรส่งต่อให้ใครในกรณีที่ผู้อนุมัติไม่อยู่หรือตัดสินใจไม่ได้ จะช่วยให้การดำเนินงานไม่หยุดชะงัก

ความสามารถในการย้อนกลับมาตรวจสอบได้ว่า "เอเจนต์ตัวไหน ทำอะไร โดยมีพื้นฐานมาจากอะไร" คือเกณฑ์มาตรฐานของบันทึกการตรวจสอบ (Audit Log) ทั้งการสอบสวนเหตุการณ์ การตอบสนองต่อการตรวจสอบ และการปรับปรุงระบบป้องกัน (Guardrails) ล้วนขึ้นอยู่กับคุณภาพของบันทึกข้อมูลทั้งสิ้น โดยต้องมีการออกแบบใน 3 ประเด็นหลัก ได้แก่ รายการที่ต้องบันทึก, การตรวจจับความผิดปกติ และการจัดเก็บข้อมูล

บันทึกการตรวจสอบ (Audit Log) ของเอเจนต์นั้นแตกต่างจากบันทึกของแอปพลิเคชันทั่วไป ตรงที่จำเป็นต้องบันทึกไปจนถึง "กระบวนการตัดสินใจ" โดยควรมีเหตุการณ์ขั้นต่ำดังต่อไปนี้:

• การรับคำสั่ง: ใครเป็นผู้ให้คำสั่ง และคำสั่ง (Prompt) คืออะไร
• การสร้างแผน: เอเจนต์วางแผนขั้นตอนการทำงานไว้อย่างไร
• การเรียกใช้เครื่องมือ: API ที่เรียกใช้, อาร์กิวเมนต์ และทรัพยากรเป้าหมาย
• ผลลัพธ์การดำเนินการ: ความสำเร็จ/ความล้มเหลว, ค่าก่อนและหลังการเปลี่ยนแปลง (ส่วนต่าง)
• การอนุมัติ/ปฏิเสธ: การตัดสินใจของมนุษย์ในกระบวนการ HITL (Human-in-the-loop) และผู้ที่ทำการตัดสินใจ
• การทำงานของ Guardrail: ข้อเท็จจริงและเหตุผลที่ระบบบล็อกหรือตัวกรองทำงาน

รายการที่จำเป็นสำหรับแต่ละบันทึก ได้แก่ การประทับเวลา (Timestamp), Agent ID, Session ID (ตัวระบุที่เชื่อมโยงงานทั้งชุดเข้าด้วยกัน), ทรัพยากรเป้าหมาย และประเภทของการดำเนินการ หากไม่มี Session ID จะไม่สามารถติดตามได้ว่า "การลบนี้เป็นส่วนหนึ่งของห่วงโซ่ที่เริ่มจากคำสั่งใด" ซึ่งจะทำให้การตรวจสอบหาสาเหตุหยุดชะงัก

ข้อควรระวังคือ หากมีการบันทึกข้อมูลนำเข้าและส่งออกของ LLM ทั้งหมด ข้อมูลส่วนบุคคลหรือข้อมูลลับอาจปะปนอยู่ในบันทึกได้ หากไม่มีการออกแบบกระบวนการปกปิดข้อมูล (Masking) ในตัวบันทึกควบคู่ไปกับการควบคุมการเข้าถึง (Access Control) ที่จะกล่าวถึงในภายหลัง ตัวฐานข้อมูลบันทึกเองอาจกลายเป็นจุดเสี่ยงใหม่ที่ทำให้ข้อมูลรั่วไหลได้

การเก็บล็อกเพียงอย่างเดียวไม่มีความหมาย การจะทำหน้าที่เป็น "การ์ดเรล" (Guardrail) ได้นั้น ต้องสามารถตรวจจับความผิดปกติได้แบบเรียลไทม์เสียก่อน พื้นฐานของการตรวจจับคือ การเบี่ยงเบนจากค่าพื้นฐาน (Baseline)

ตัวชี้วัดที่มีประสิทธิภาพสำหรับการเฝ้าระวังมีดังนี้:

• จำนวนการเรียกใช้เครื่องมือต่อหน่วยเวลาที่เพิ่มขึ้นอย่างรวดเร็ว (สัญญาณของการทำงานผิดปกติหรือการวนลูป)
• อัตราความล้มเหลวหรืออัตราการลองใหม่ (Retry rate) ของการดำเนินการที่สูงขึ้น (สัญญาณของการเปลี่ยนแปลงสภาพแวดล้อมหรือการโจมตี)
• การเข้าถึงทรัพยากรที่ไม่เคยเข้าถึงมาก่อนเป็นครั้งแรก
• การทำงานนอกช่วงเวลาปกติ

ไม่จำเป็นต้องกำหนดค่าเกณฑ์ (Threshold) ให้ถูกต้องแม่นยำตั้งแต่แรก แต่ให้ใช้ค่าที่วัดได้จริงหลังการติดตั้งเป็นค่าพื้นฐานแล้วค่อยๆ ปรับจูนแบบเป็นขั้นตอน สำหรับการตอบสนองควรแบ่งเป็นระดับ ได้แก่ "แจ้งเตือนเท่านั้น → ระงับการทำงานของเอเจนต์ชั่วคราวโดยอัตโนมัติ → หยุดการทำงานของเอเจนต์ทั้งหมดฉุกเฉิน (Kill Switch)" โดยเฉพาะอย่างยิ่งสำหรับ Kill Switch ควรจัดเตรียมเอกสารขั้นตอนการหยุดทำงานและการฝึกซ้อมควบคู่กันไป เพื่อหลีกเลี่ยงสถานการณ์ที่ไม่มีใครรู้วิธีหยุดระบบเมื่อเกิดเหตุการณ์ไม่คาดฝันขึ้น

ระยะเวลาการจัดเก็บข้อมูลควรถูกกำหนดให้สอดคล้องกับกฎหมาย กฎระเบียบของอุตสาหกรรม และระเบียบการจัดการเอกสารภายในองค์กรที่เกี่ยวข้อง บันทึกการใช้งาน (Operation Log) ที่เกี่ยวข้องกับข้อมูลทางบัญชีและธุรกรรม มักจำเป็นต้องถูกเก็บรักษาไว้ตามระยะเวลาที่กำหนดไว้สำหรับสมุดบัญชีที่เกี่ยวข้อง การกำหนดให้ "เก็บรักษาถาวรทั้งหมดไว้ก่อน" โดยไม่มีการแยกแยะ จะทำให้ทั้งต้นทุนด้านพื้นที่จัดเก็บ (Storage cost) และความเสี่ยงในการเก็บรักษาข้อมูลส่วนบุคคลเพิ่มสูงขึ้น ดังนั้น การกำหนดระยะเวลาแยกตามประเภทของเหตุการณ์จึงเป็นแนวทางที่เหมาะสมในทางปฏิบัติ

ความสามารถในการป้องกันการแก้ไข (Tamper resistance) ของบันทึกข้อมูลถือเป็นข้อกำหนดสำคัญในการตรวจสอบ (Audit) หากโครงสร้างของระบบยอมให้ตัว Agent เองหรือผู้ดูแลระบบสามารถแก้ไขบันทึกข้อมูลได้ บันทึกนั้นจะไม่สามารถใช้เป็นหลักฐานที่น่าเชื่อถือได้ จึงควรนำกลไกที่สามารถตรวจจับการแก้ไขข้อมูลมาใช้ เช่น การใช้พื้นที่จัดเก็บแบบเขียนเพิ่มได้อย่างเดียว (Write-once storage) หรือการตรวจสอบความถูกต้องของข้อมูล (Integrity verification) ผ่านการลงลายมือชื่อดิจิทัล (Digital signature) หรือ Hash chain

หลักการสำคัญของการควบคุมการเข้าถึงคือการแยก "ผู้เขียนบันทึก" และ "ผู้อ่านบันทึก" ออกจากกัน สิทธิ์ในการเข้าถึงควรจำกัดไว้เฉพาะเจ้าหน้าที่ตรวจสอบและเจ้าหน้าที่ความปลอดภัยเท่านั้น เพื่อหลีกเลี่ยงสถานการณ์ที่นักพัฒนา Agent สามารถเข้าถึงหรือแก้ไขบันทึกข้อมูลในระบบจริง (Production log) ได้อย่างอิสระ และเนื่องจากบันทึกข้อมูลอาจมีข้อมูลที่เป็นความลับรวมอยู่ด้วย การจัดเตรียมระบบให้มีการบันทึกการเข้าถึงข้อมูลไว้ด้วย (Access log ของ Log) จะช่วยให้การรองรับการตรวจสอบมีความเสถียรมากยิ่งขึ้น

เมื่อเอเจนต์หลายตัวทำงานร่วมกัน ความเสี่ยงจะไม่ได้เพิ่มขึ้นแบบบวก แต่จะเพิ่มขึ้นแบบทวีคูณ นอกเหนือจากระบบป้องกัน (Guardrails) สำหรับเอเจนต์เดี่ยวแล้ว จำเป็นต้องมีการควบคุม "ระหว่าง" เอเจนต์ด้วย โดยมี Trust Model และ Rollback เป็นเสาหลักในการออกแบบ

หลักการของสภาพแวดล้อมแบบมัลติเอージェนต์ (Multi-agent environment) ก็เหมือนกับระบบของมนุษย์ นั่นคือ Zero Trust โดยจะไม่มีการตั้งสมมติฐานว่า "เพราะเป็นเอージェนต์ภายในบริษัทเหมือนกัน จึงเชื่อถือได้"

โดยเฉพาะอย่างยิ่ง จะต้องมีการนำหลักการ 3 ประการต่อไปนี้ไปใช้งาน:

1. การตรวจสอบสิทธิ์ซึ่งกันและกัน (Mutual Authentication): ในการสื่อสารระหว่างเอージェนต์ จะต้องมีการตรวจสอบสิทธิ์ของผู้เรียกใช้งานเพื่อป้องกันการปลอมแปลงตัวตน
2. การจำกัดสิทธิ์แบบจุดตัด (Intersection of Permissions): เมื่อเอージェนต์ A ร้องขอให้เอージェนต์ B ทำงาน สิทธิ์ที่ B สามารถใช้ได้จะถูกจำกัดไว้ที่ "ส่วนร่วมของสิทธิ์ของ A และสิทธิ์ของ B" เท่านั้น หากออกแบบให้สิทธิ์ขยายตัวผ่านการร้องขอ (Privilege Escalation) จะทำให้เมื่อเอージェนต์ที่อ่อนแอที่สุดถูกบุกรุก สิทธิ์ทั้งหมดจะถูกเปิดเผยทันที
3. การตรวจสอบผลลัพธ์ซ้ำ (Re-validation of Output): เอージェนต์หนึ่งจะไม่นำผลลัพธ์ของอีกเอージェนต์หนึ่งไปดำเนินการตามคำสั่งโดยไม่มีการตรวจสอบก่อน

ประเด็นที่ 3 มักถูกมองข้ามได้ง่ายที่สุด ตัวอย่างเช่น เอージェนต์ A อ่านหน้าเว็บภายนอกแล้วนำเนื้อหานั้นไปร้องขอต่อเอージェนต์ B ในเส้นทางนี้ การฉีดคำสั่ง (Injection) ที่ฝังอยู่ในหน้าเว็บจะถูกส่งผ่าน A ไปยัง B นี่คือ การเชื่อมโยงของการฉีดคำสั่งผ่านพรอมต์ทางอ้อม (Indirect Prompt Injection Chain) ดังนั้น แม้จะเป็นขอบเขตระหว่างเอージェนต์ ก็ห้ามละเลยการทำ Sanitization ข้อมูลที่มาจากภายนอกและการตรวจสอบอาร์กิวเมนต์ (Argument validation) โดยเด็ดขาด

ในการทำงานแบบต่อเนื่องโดยใช้เอเจนต์หลายตัว (Multi-agent) จำเป็นต้องมีการออกแบบวิธีรับมือกับสถานะที่ "สำเร็จเพียงบางส่วนและล้มเหลวในระหว่างทาง" ไว้ล่วงหน้า หากเป็นงานที่ทำด้วยมือ มนุษย์สามารถตรวจสอบสถานการณ์และย้อนกลับ (Rollback) ได้ แต่ในการทำงานแบบอัตโนมัติที่ต่อเนื่องกัน สถานะที่ค้างคาจะถูกปล่อยทิ้งไว้และสะสมจนกลายเป็นความไม่สอดคล้องของข้อมูล (Data Inconsistency)

รูปแบบการออกแบบ (Design Pattern) สามารถนำความรู้จากระบบแบบกระจาย (Distributed Systems) มาประยุกต์ใช้ได้ดังนี้:

• การประมวลผลชดเชย (Saga Pattern): กำหนด "การดำเนินการยกเลิก" คู่กับแต่ละขั้นตอน เมื่อเกิดความล้มเหลวให้ทำการยกเลิกขั้นตอนที่เสร็จสิ้นไปแล้วย้อนกลับตามลำดับ
• การทดสอบการทำงาน (Dry Run): ทดลองรันทุกขั้นตอนในโหมดจำลองก่อน เพื่อตรวจสอบความเป็นไปได้ก่อนที่จะดำเนินการจริง
• การดำเนินการแบบ Staging: สะสมการเปลี่ยนแปลงไว้ในพื้นที่ชั่วคราว และทำการอัปเดตพร้อมกันหลังจากยืนยันว่าทุกขั้นตอนสำเร็จแล้ว

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

ความล้มเหลวของธรรมาภิบาลมักไม่ได้เกิดจาก "การควบคุมที่หละหลวมเกินไป" แต่เกิดจาก "ความไม่สอดคล้องกันระหว่างการออกแบบและการปฏิบัติจริง" การทำความเข้าใจรูปแบบความล้มเหลวที่อยู่ตรงข้ามกัน 2 ประการ ได้แก่ การเป็นเพียงรูปแบบ (形骸化) และการควบคุมที่มากเกินไป (過剰制御) จะช่วยให้คุณสามารถตรวจสอบได้ว่าการดำเนินงานของบริษัทตนเองกำลังเอนเอียงไปในทิศทางใด

การกลายเป็นเพียงรูปแบบที่ไร้เนื้อหา (形骸化) ดำเนินไปอย่างเงียบเชียบ สิ่งที่มักเกิดขึ้นเป็นปกติคือ หลังจากติดตั้งระบบไปได้ไม่กี่เดือน มาตรการป้องกัน (Guardrails) ที่เคยใช้งานได้ดีในช่วงแรกกลับกลายเป็นสภาพดังต่อไปนี้:

• มีคำขออนุมัติเข้ามามากเกินไป จนผู้อนุมัติกดอนุมัติทันทีโดยไม่ได้ตรวจสอบเนื้อหา
• การขอข้อยกเว้นโดยอ้างว่า "เป็นเรื่องเร่งด่วน" กลายเป็นเรื่องปกติ จนกลายเป็นกรณีส่วนใหญ่ไปแล้ว
• มีการจัดเก็บ Audit log ไว้ แต่ไม่มีผู้รับผิดชอบคอยตรวจสอบเป็นประจำ
• ขอบเขตอำนาจ (Permission scope) ของ Agent ไม่ได้รับการปรับปรุงให้สอดคล้องกับการเปลี่ยนแปลงของงานและถูกปล่อยทิ้งไว้

สิ่งที่น่ากลัวคือ แม้จะอยู่ในสภาพที่ไร้เนื้อหา แต่ในทางเอกสารกลับดูเหมือนว่า "มีระบบธรรมาภิบาลรองรับอยู่" กว่าจะรู้ว่าการควบคุมไม่ได้ผลจริงก็ต่อเมื่อเกิดเหตุการณ์ไม่พึงประสงค์ (Incident) ขึ้นแล้วเท่านั้น

วิธีรับมือคือ การเฝ้าติดตามตัวธรรมาภิบาลด้วยเมทริกซ์ (Metrics) เพียงอย่างเดียวเท่านั้น โดยต้องวางแผนการดำเนินงานตั้งแต่ช่วงติดตั้งระบบว่าจะมีการทบทวนสิ่งเหล่านี้เป็นรายไตรมาส ได้แก่ เวลาเฉลี่ยในการตัดสินใจอนุมัติ (หากสั้นเกินไปแสดงว่าไม่ได้ตรวจสอบอย่างละเอียด), สัดส่วนการขอข้อยกเว้น, จำนวนครั้งที่มาตรการป้องกันทำงานและอัตราการตอบสนองหลังจากนั้น, และวันที่ล่าสุดที่มีการทบทวนขอบเขตอำนาจ การทำให้มาตรการป้องกัน "ทำงานได้อย่างต่อเนื่อง" นั้นยากกว่าการ "สร้าง" ขึ้นมาเสียอีก

ในทางกลับกัน ความล้มเหลวที่เกิดจากการควบคุมที่เข้มงวดเกินไปก็มีเช่นกัน การกำหนดให้ต้องมีการอนุมัติล่วงหน้าสำหรับทุกการดำเนินการและการจำกัดสิทธิ์อย่างสุดโต่ง ส่งผลให้แม้จะใช้ Agent แล้ว แต่ภาระงานของมนุษย์กลับไม่ลดลง—ซ้ำร้ายยังกลายเป็นการเพิ่มงานอนุมัติจนทำให้กระบวนการล่าช้า ซึ่งถือเป็นการแก้ปัญหาที่ผิดจุด

ความน่ากลัวที่แท้จริงของการควบคุมที่มากเกินไปไม่ใช่การที่มูลค่าของ Agent หายไป แต่เป็นสิ่งที่ตามมาหลังจากนั้น เมื่อ Agent ที่เป็นทางการใช้งานไม่ได้จริง พนักงานในหน้างานจะเริ่มนำข้อมูลทางธุรกิจไปป้อนให้กับบริการ AI ภายนอกที่ไม่ได้รับอนุญาต "Agent เถื่อน" (Shadow Agents) ที่ทำงานอยู่นอกเหนือการมองเห็นของการควบคุม คือความเสี่ยงสูงสุดที่เกิดจากการควบคุมที่มากเกินไป และอันตรายกว่าการควบคุมที่หละหลวมเสียอีก

แนวทางในการสร้างสมดุลมี 2 ประการ ประการแรก คือการยึดมั่นตามตารางประเมินความเสี่ยง (Risk Assessment Matrix) โดยไม่นำการดำเนินการที่สามารถแก้ไขได้และมีผลกระทบต่ำมารวมไว้ในการอนุมัติล่วงหน้า ประการที่สอง คือการออกแบบให้มี การขยายสิทธิ์แบบค่อยเป็นค่อยไปตามผลงานที่เกิดขึ้นจริง ในช่วงเริ่มต้นของการนำมาใช้งาน ให้เริ่มจากสิทธิ์ที่จำกัดและการตรวจสอบที่ถี่ จากนั้นจึงขยายขอบเขตการทำงานอัตโนมัติโดยมีเงื่อนไขว่าต้องมีการทำงานที่เสถียรและการตรวจสอบบันทึกการใช้งาน (Log Review) ในระยะเวลาหนึ่ง การควบคุมไม่ควรถูกมองว่าเป็นค่าคงที่ แต่ควรเป็นพารามิเตอร์ที่ปรับเปลี่ยนได้ตามการสั่งสมของความเชื่อมั่น ซึ่งเป็นแนวทางที่เหมาะสมกว่า

Q1: สำหรับทีมขนาดเล็ก จำเป็นต้องมีระบบธรรมาภิบาล (Governance) ถึงระดับนี้หรือไม่?

ขนาดของระบบขึ้นอยู่กับอำนาจหน้าที่ของ Agent ไม่ใช่ขนาดขององค์กร หากเป็น Agent แบบอ่านได้อย่างเดียว (Read-only) การจัดทำเอกสารขอบเขตอำนาจหน้าที่และการเก็บ Log ก็เพียงพอที่จะเริ่มต้นได้ แต่ในทางกลับกัน หากต้องมอบหมายงานที่เกี่ยวข้องกับการเขียน ลบ หรือส่งข้อมูลออกภายนอก แม้จะเป็นทีมขนาดเล็ก ก็ไม่สามารถละเว้นการแบ่งแยกอำนาจหน้าที่ (Separation of Duties), การกำหนดขีดจำกัดสูงสุด (Hard limits) และขั้นตอนการอนุมัติ (Approval flow) ได้

Q2: มีความเกี่ยวข้องอย่างไรกับมาตรการรักษาความปลอดภัยที่มีอยู่เดิม (IAM, SIEM)?

ไม่ใช่การทดแทน แต่เป็นการขยายขอบเขต คุณสามารถลงทะเบียน Agent ในฐานะ Service Account เฉพาะใน IAM ที่มีอยู่เดิม และรวบรวม Audit log เข้าสู่ SIEM ที่ใช้งานอยู่ได้ ซึ่งจะช่วยให้คุณสามารถใช้กรอบการตรวจสอบและควบคุมที่มีอยู่เดิมได้ทันที โดยไม่จำเป็นต้องสร้างโครงสร้างพื้นฐานการจัดการสำหรับ Agent ขึ้นมาใหม่ตั้งแต่ต้น

Q3: ควรติดตั้ง Guardrails ไว้ที่ฝั่งโมเดลหรือฝั่งแอปพลิเคชัน?

การควบคุมที่ต้องการให้มีผลอย่างแน่นอนควรติดตั้งไว้ที่ชั้นแอปพลิเคชันและโครงสร้างพื้นฐาน (Application/Infrastructure layer) การสั่งการผ่าน System prompt เป็นเพียง Soft limit และควรตั้งสมมติฐานว่าอาจถูกทำลายได้ด้วย Prompt injection ดังนั้น การควบคุมผ่าน Prompt ควรจำกัดไว้เพียงการปรับ "พฤติกรรมที่พึงประสงค์" เช่น รูปแบบภาษาหรือเกณฑ์การตัดสินใจเท่านั้น

Q4: ควรเริ่มต้นจากตรงไหน?

ลำดับที่แนะนำคือ "การสำรวจอำนาจหน้าที่ (Inventory of permissions) → เมทริกซ์การประเมินความเสี่ยง (Risk assessment matrix) → การติดตั้ง Hard limits → Audit log → HITL (Human-in-the-loop)" การเริ่มต้นด้วย Agent ตัวแรกในงานที่จำกัดและขอบเขตอำนาจที่แคบ เพื่อสร้างรูปแบบธรรมาภิบาลระหว่างการใช้งานจริงแล้วค่อยขยายผลออกไป จะเป็นวิธีที่รวดเร็วที่สุด ทั้งนี้ บริษัทของเรามีบริการให้คำปรึกษาด้านการออกแบบธรรมาภิบาลเมื่อมีการนำ AI Agent มาใช้งาน หากการเตรียมความพร้อมด้วยตนเองเป็นเรื่องยาก การให้ผู้เชี่ยวชาญเข้ามาช่วยดูแลก็เป็นทางเลือกหนึ่งที่ควรพิจารณา