ຄູ່ມືການສ້າງກອບການຄຸ້ມຄອງ AI Agent — ການອອກແບບການກວດສອບເພື່ອປ້ອງກັນ Agent Drift

AI ເອເຈນກາເວີແນນສ໌ເຟຣມເວີກ (AI Agent Governance Framework) ແມ່ນລະບົບການກຳກັບດູແລ ແລະ ຄວບຄຸມເພື່ອປ້ອງກັນການເບ່ຽງເບນທີ່ບໍ່ໄດ້ຕັ້ງໃຈ (Agent Drift) ໃນສະພາບແວດລ້ອມທີ່ AI ເອເຈນປະຕິບັດງານຢ່າງອິດສະຫຼະ.

ໃນຂະນະທີ່ການນຳໃຊ້ລະບົບຫຼາຍເອເຈນ (Multi-agent system) ເຂົ້າສູ່ການປະຕິບັດງານຈິງມີຄວາມໄວເພີ່ມຂຶ້ນ, ການທີ່ເອເຈນປະຕິບັດງານເກີນຂອບເຂດອຳນາດທີ່ໄດ້ຮັບ ຫຼື ຄ່ອຍໆເບ່ຽງເບນອອກຈາກເປົ້າໝາຍ ຫຼື "Drift" ໄດ້ກາຍເປັນຄວາມສ່ຽງທາງທຸລະກິດທີ່ຮ້າຍແຮງ. ລະບຽບການຫຼັກໆເຊັ່ນ: EU AI Act (Regulation (EU) 2024/1689) ແລະ NIST AI RMF 1.0 ໄດ້ເລີ່ມລະບຸຢ່າງຊັດເຈນເຖິງພັນທະຂອງມະນຸດໃນການກຳກັບດູແລເອເຈນ.

ບົດຄວາມນີ້ມີຈຸດປະສົງເພື່ອແນະນຳພະແນກລະບົບຂໍ້ມູນຂ່າວສານ ແລະ ຜູ້ຮັບຜິດຊອບດ້ານການຂັບເຄື່ອນ AI ໂດຍສະເພາະ, ເຊິ່ງຈະອະທິບາຍກ່ຽວກັບການອອກແບບຈົນເຖິງການຈັດຕັ້ງປະຕິບັດກາເວີແນນສ໌ເຟຣມເວີກໃນ 4 ຂັ້ນຕອນ. ທ່ານສາມາດສ້າງພື້ນຖານການດຳເນີນງານຂອງເອເຈນທີ່ປອດໄພ ແລະ ສາມາດອະທິບາຍໄດ້ ໂດຍການອ່ານຕາມລຳດັບຕັ້ງແຕ່ການເລືອກຮູບແບບການກຳກັບດູແລ, ການຈັດຕັ້ງປະຕິບັດ Guardrail, ການກວດສອບ Drift, ແລະ ການເຊື່ອມໂຍງດ້ານຄວາມປອດໄພ.

ສະຫຼຸບ: ເມື່ອ AI Agent ມີຄວາມເປັນອິດສະຫຼະຫຼາຍຂຶ້ນ, ຄວາມສ່ຽງຕໍ່ການອອກນອກຂອບເຂດທີ່ບໍ່ໄດ້ຕັ້ງໃຈກໍຈະເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ, ແລະ ການດຳເນີນງານທີ່ປາສະຈາກການກຳກັບດູແລຈະສົ່ງຜົນໂດຍກົງຕໍ່ການຂັດຂ້ອງຂອງວຽກງານ ແລະ ຄວາມຮັບຜິດຊອບທາງກົດໝາຍ.

ໃນສະພາບແວດລ້ອມທີ່ Agent ສາມາດຮຽກໃຊ້ເຄື່ອງມືພາຍນອກໄດ້ຢ່າງອິດສະຫຼະ ແລະ ປະຕິບັດຫຼາຍວຽກງານຕໍ່ເນື່ອງກັນນັ້ນ, ໄດ້ເກີດມີຄວາມສ່ຽງໃໝ່ໆທີ່ວິທີການຕິດຕາມກວດກາ AI ແບບດັ້ງເດີມບໍ່ສາມາດຮັບມືໄດ້. ໃນພາກນີ້, ພວກເຮົາຈະມາເບິ່ງພາບລວມຂອງພື້ນຖານ ແລະ ທ່າອ່ຽງດ້ານການຄວບຄຸມດັ່ງກ່າວ.

Agent Drift ແມ່ນປະກົດການທີ່ AI Agent ຄ່ອຍໆເບ່ຽງເບນອອກຈາກເປົ້າໝາຍ, ຂັ້ນຕອນ ແລະ ຂໍ້ຈຳກັດທີ່ຕັ້ງໄວ້ໃນຕອນຕົ້ນ ແລະ ສືບຕໍ່ປະຕິບັດພຶດຕິກຳທີ່ບໍ່ໄດ້ຕັ້ງໃຈ. ໃນຕອນທຳອິດ, ຫຼາຍຄົນມັກຄິດວ່າ "ຖ້າ Agent ເຄື່ອນໄຫວໄດ້ຢ່າງອິດສະຫຼະ, ຄ່າໃຊ້ຈ່າຍໃນການກວດສອບຂອງມະນຸດຈະກາຍເປັນສູນ", ແຕ່ໃນຄວາມເປັນຈິງແລ້ວ, ການຂາດການກຳກັບດູແລນັ້ນເອງທີ່ເປັນຕົວເລັ່ງໃຫ້ເກີດ Drift ແລະ ມີລາຍງານຫຼາຍກໍລະນີທີ່ບໍ່ມີໃຜຮູ້ຕົວເລີຍຈົນກວ່າຄວາມເສຍຫາຍຈະປາກົດຂຶ້ນ.

ຄວາມສ່ຽງໃນການເຮັດວຽກຈະເກີດຂຶ້ນໃນ 3 ລະດັບຫຼັກໆ ດັ່ງນີ້:

• ຄວາມຜິດພາດທີ່ເຊື່ອມໂຍງກັນໃນການຕັດສິນໃຈ: ໃນລະບົບ Multi-agent, ຄວາມຜິດພາດເລັກນ້ອຍໃນການຕັດສິນໃຈຂອງ Agent ລະດັບຕົ້ນນ້ຳມີທ່າອ່ຽງທີ່ຈະສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ Agent ລະດັບປາຍນ້ຳ ເຊິ່ງຈະເຮັດໃຫ້ຜົນລວມສຸດທ້າຍບິດເບືອນໄປຢ່າງຫຼວງຫຼາຍ.
• ການຂະຫຍາຍສິດອຳນາດດ້ວຍຕົນເອງ: ມີຄວາມສ່ຽງທີ່ Agent ຈະເອີ້ນໃຊ້ Tool ຫຼື API ທີ່ບໍ່ໄດ້ຄາດຄິດໄວ້ເພື່ອບັນລຸເປົ້າໝາຍ ເຊິ່ງອາດນຳໄປສູ່ການຮົ່ວໄຫຼຂອງຂໍ້ມູນ ຫຼື ການດຳເນີນການທີ່ບໍ່ຖືກຕ້ອງ.
• ຊ່ອງວ່າງຂອງຄວາມຮັບຜິດຊອບ: ເມື່ອເກີດ Drift, ບໍ່ສາມາດຕິດຕາມໄດ້ວ່າການເບ່ຽງເບນເລີ່ມຕົ້ນຂຶ້ນທີ່ Agent ໃດ ຫຼື ຂັ້ນຕອນໃດ ເຮັດໃຫ້ການກວດສອບ (Audit) ເປັນໄປໄດ້ຍາກ.

ສິ່ງທີ່ຕ້ອງລະມັດລະວັງເປັນພິເສດຄື Drift ບໍ່ໄດ້ປາກົດອອກມາໃນຮູບແບບຂອງ "ການຫຼົງທາງຢ່າງກະທັນຫັນ" ແຕ່ເປັນ "ການສະສົມຂອງການເບ່ຽງເບນຢ່າງຊ້າໆ". ເຖິງແມ່ນວ່າແຕ່ລະຂັ້ນຕອນຈະເບິ່ງຄືວ່າປົກກະຕິ, ແຕ່ເມື່ອເບິ່ງຜ່ານ Task Graph ທັງໝົດແລ້ວ ກັບພົບວ່າເປົ້າໝາຍໄດ້ຜິດເພ້ຽນໄປຢ່າງຫຼວງຫຼາຍ—ກໍລະນີທີ່ຄວາມສ່ຽງທາງໂຄງສ້າງແບບນີ້ປາກົດຂຶ້ນຫຼັງຈາກການນຳໃຊ້ຈິງ (Production) ກຳລັງເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ.

ໃນການສ້າງ Governance Framework, ແນວຄິດແບບ "Shift-left" ທີ່ເນັ້ນການຝັງຈຸດຄວບຄຸມໄວ້ຕັ້ງແຕ່ຂັ້ນຕອນການອອກແບບ ຈະມີປະສິດທິຜົນຫຼາຍກວ່າການແກ້ໄຂບັນຫາຫຼັງຈາກເກີດເຫດ (Reactive) ເມື່ອ Drift ເກີດຂຶ້ນແລ້ວ. [Multi-agent AI ແມ່ນຫຍັງ?

ຄຳຖາມທີ່ວ່າ "ພວກເຮົາກຳລັງມອບໝາຍວຽກໃຫ້ Agent ຫຼາຍເກີນໄປຫຼືບໍ່?" ເປັນສິ່ງທີ່ເກີດຂຶ້ນຊ້ຳໆໃນໜ້າວຽກການອອກແບບລະບົບ Multi-agent. ພາວະການໃຫ້ສິດທິແກ່ Agent ຫຼາຍເກີນໄປ (Excessive Agency) ໝາຍເຖິງສະພາວະທີ່ AI Agent ມີສິດທິ, ຟັງຊັນ, ຫຼື ຄວາມເປັນອິດສະຫຼະ ເກີນກວ່າຂອບເຂດທີ່ຈຳເປັນໃນການບັນລຸເປົ້າໝາຍຂອງວຽກງານ.

ບັນຫາຄື ການໃຫ້ສິດທິເກີນຄວາມຈຳເປັນມັກຈະເກີດຂຶ້ນຍ້ອນ "ຄວາມສະດວກ" ຫຼາຍກວ່າຄວາມຕັ້ງໃຈ. ການໃຫ້ສິດທິໃນວົງກວ້າງເພື່ອຄວາມສະດວກໃນການ Debug ໃນຊ່ວງເລີ່ມຕົ້ນຂອງການພັດທະນາແລ້ວປ່ອຍໃຫ້ຄົງຢູ່ເມື່ອເປີດຕົວ ຫຼື Launch ລະບົບ, ຫຼື ການບໍ່ທົບທວນຂອບເຂດສິດທິທຸກຄັ້ງທີ່ມີການເພີ່ມທັກສະໃໝ່ໃຫ້ Agent, ເຮັດໃຫ້ການປະຕິບັດງານສະສົມຈົນເຮັດໃຫ້ເສັ້ນແບ່ງຂອງການປະຕິບັດງານແບບອິດສະຫຼະມົວໄປໂດຍບໍ່ຮູ້ຕົວ.

ຫຼັກການໃນການຕັດສິນໃຈສາມາດຈັດລຽງໄດ້ດັ່ງນີ້:

• ໃນກໍລະນີທີ່ Agent ຮັບຜິດຊອບວຽກງານເກັບກຳຂໍ້ມູນແບບ "ອ່ານຢ່າງດຽວ (Read-only)" ຫຼັກການພື້ນຖານຄື ຫ້າມໃຫ້ສິດທິໃນການຂຽນ, ລຶບ, ຫຼື ສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ ພາຍນອກ.
• ໃນກໍລະນີທີ່ Agent ຕ້ອງປະມວນຜົນໃຫ້ສຳເລັດໂດຍກ່ຽວຂ້ອງກັບຫຼາຍລະບົບ ຄວນກຳນົດປະຕູການອະນຸມັດ (Approval gate) ໃນແຕ່ລະຂັ້ນຕອນ ແລະ ກຳນົດຈຸດຄວບຄຸມທີ່ມະນຸດສາມາດເຂົ້າໄປແຊກແຊງໄດ້ຢ່າງຊັດເຈນ.
• ໃນກໍລະນີທີ່ຂອບເຂດຜົນກະທົບຂອງວຽກງານບໍ່ສາມາດຍົກເລີກໄດ້ (ເຊັ່ນ: ການລຶບຂໍ້ມູນ, ການສັ່ງຊື້ພາຍນອກ, ການເຮັດສັນຍາ ແລະ ອື່ນໆ) ໃຫ້ກຳນົດກົດລະບຽບຫ້າມປະຕິບັດງານແບບອິດສະຫຼະ ແລະ ບັງຄັບໃຫ້ໃຊ້ HITL (Human-in-the-Loop).

ໃນຄູ່ມືຄວາມປອດໄພ LLM ຂອງ OWASP ກໍໄດ້ລະບຸວ່າ ການໃຫ້ສິດທິແກ່ Agent ຫຼາຍເກີນໄປ ເປັນໜຶ່ງໃນຄວາມສ່ຽງສູງສຸດ ແລະ ໄດ້ແນະນຳໃຫ້ມີການນຳໃຊ້ຫຼັກການໃຫ້ສິດທິໜ້ອຍທີ່ສຸດ (Principle of Least Privilege).

"ຕົວແທນ (Agent) ຂອງບໍລິສັດເຮົາຈັດຢູ່ໃນປະເພດຄວາມສ່ຽງໃດ?" — ຫາກດຳເນີນການໃຊ້ງານຈິງໂດຍບໍ່ສາມາດຕອບຄຳຖາມນີ້ໄດ້ ອາດສົ່ງຜົນໃຫ້ຕົ້ນທຶນໃນການປະຕິບັດຕາມກົດລະບຽບເພີ່ມທະວີຂຶ້ນເລື້ອຍໆໃນພາຍຫຼັງ.

ເມື່ອຈັດລະບຽບທິດທາງຂອງກົດລະບຽບສາກົນແລ້ວ, ພັນທະໃນການກຳກັບດູແລຫຼັກໆຈະຖືກລວມເຂົ້າເປັນ 2 ແກນຫຼັກ ຫຼື ຈຸດສຳຄັນ ດັ່ງນີ້:

ຂໍ້ກຳນົດຂອງ EU AI Act (Regulation (EU) 2024/1689)

EU AI Act ເຊິ່ງໄດ້ຮັບການຮັບຮອງໃນວັນທີ 13 ມິຖຸນາ 2024 ແລະ ປະກາດໃນວາລະສານທາງການຂອງສະຫະພາບເອີຣົບໃນວັນທີ 12 ກໍລະກົດ ປີດຽວກັນນັ້ນ ໄດ້ກຳນົດໃຫ້ລະບົບ AI ທີ່ມີຄວາມສ່ຽງສູງຕ້ອງມີການກຳກັບດູແລໂດຍມະນຸດ (Human Oversight). ຂໍ້ກຳນົດສະເພາະມີດັ່ງນີ້:

• ການຈັດຕັ້ງປະຕິບັດກົນໄກທີ່ມະນຸດສາມາດແຊກແຊງ ຫຼື ຢຸດການເຮັດວຽກໄດ້ແບບ Real-time ໃນຂະນະທີ່ຕົວແທນ (Agent) ເຄື່ອນໄຫວຢ່າງອິດສະຫຼະ
• ການຮັກສາບັນທຶກ (Log) ແລະ ການຮັບປະກັນຄວາມສາມາດໃນການອະທິບາຍ (Explainability) ເພື່ອຕິດຕາມກວດກາຄວາມໜ້າເຊື່ອຖືຂອງຜົນລັອກຢ່າງຕໍ່ເນື່ອງ
• ການດຳເນີນການປະເມີນຄວາມສອດຄ່ອງ (Conformity Assessment) ສຳລັບການນຳໃຊ້ທີ່ມີຄວາມສ່ຽງສູງ

ຂໍ້ກຳນົດຂອງ NIST AI RMF 1.0

NIST AI RMF 1.0 ເຊິ່ງອອກໃນວັນທີ 26 ມັງກອນ 2023 (Playbook ສະບັບຫຼ້າສຸດອັບເດດວັນທີ 27 ມີນາ 2026) ໄດ້ຮຽກຮ້ອງໃຫ້ມີລະບົບໃນການປະເມີນ ແລະ ຈັດການຄວາມສ່ຽງຂອງຕົວແທນ (Agent) ຢ່າງຕໍ່ເນື່ອງ ຜ່ານ 4 ຟັງຊັນຫຼັກ ຄື: GOVERN, MAP, MEASURE ແລະ MANAGE.

ສະຫຼຸບ: ກ່ອນທີ່ຈະເລີ່ມຕົ້ນການອອກແບບການບໍລິຫານຈັດການ (Governance), ມັນເປັນສິ່ງຈຳເປັນທີ່ຈະຕ້ອງກຽມພື້ນຖານສາມຢ່າງໃຫ້ພ້ອມ ຄື: ສິດອຳນາດ, ບັນທຶກການໃຊ້ງານ (Log), ແລະ ໂຄງສ້າງການຈັດຕັ້ງ.

ກ່ອນການອອກແບບ, ໃຫ້ດຳເນີນການກວດສອບສາມຈຸດສຳຄັນ ຄື: ຂອບເຂດສິດອຳນາດຂອງ Agent, ພື້ນຖານດ້ານການສັງເກດການ (Observability), ແລະ ເຈົ້າຂອງການບໍລິຫານຈັດການ (Governance Owner). ຫາກຂາດເງື່ອນໄຂເບື້ອງຕົ້ນເຫຼົ່ານີ້, ຂັ້ນຕອນຕໍ່ໄປກໍຈະກາຍເປັນພຽງຮູບແບບທີ່ບໍ່ມີປະສິດທິຜົນ.

ເມື່ອເລີ່ມຕົ້ນສ້າງໂຄງຮ່າງການກຳກັບດູແລ (Governance Framework), ຫຼາຍທີມມັກຈະຄິດວ່າ "ເຮົາຄວນເລີ່ມຈາກການຮ່າງເອກະສານນະໂຍບາຍກ່ອນ". ແຕ່ໃນຄວາມເປັນຈິງແລ້ວ, ການສຳຫຼວດເບິ່ງວ່າປັດຈຸບັນ Agent ມີສິດອຳນາດແນວໃດ ແລະ ສາມາດເຮັດຫຍັງໄດ້ແດ່ກ່ອນນັ້ນ ຈະຊ່ວຍເພີ່ມຄວາມຊັດເຈນໃນການອອກແບບໄດ້ຫຼາຍກວ່າ.

ການສຳຫຼວດຂອບເຂດສິດອຳນາດ (Authority Scope) ຄືການເຮັດລາຍການສະແດງສິດການເຂົ້າເຖິງ, ສິດໃນການຈັດການ ແລະ ຂອບເຂດການເຊື່ອມຕໍ່ API ພາຍນອກທີ່ Agent ແຕ່ລະຕົວມີ. ໂດຍສະເພາະແມ່ນການກວດສອບລາຍການດັ່ງຕໍ່ໄປນີ້:

• ສິດການເຂົ້າເຖິງຂໍ້ມູນ: ເປັນພຽງການອ່ານເທົ່ານັ້ນ (Read-only) ຫຼື ສາມາດຂຽນ ແລະ ລຶບຂໍ້ມູນໄດ້ນຳ
• ການເຊື່ອມຕໍ່ລະບົບພາຍນອກ: ປະເພດຂອງ API, ເຄື່ອງມື ແລະ ຖານຂໍ້ມູນທີ່ສາມາດເອີ້ນໃຊ້ໄດ້ ລວມເຖິງຂອບເຂດການຈັດການ
• ລາຍການ Agent Skills: ການກະທຳທີ່ແຕ່ລະ Skill ສາມາດປະຕິບັດໄດ້ ແລະ ຂອບເຂດຜົນກະທົບ (ຈຳກັດພຽງແຕ່ພາຍໃນ ຫຼື ສົ່ງຜົນກະທົບໄປຍັງບໍລິການພາຍນອກ)
• ຄວາມສຳພັນໃນການມອບໝາຍລະຫວ່າງ Agent: ໃນລະບົບ Multi-agent, Agent ຕົວໃດສາມາດມອບໝາຍວຽກໃຫ້ Agent ຕົວອື່ນໄດ້

ຜົນຈາກການສຳຫຼວດມັກຈະພົບເຫັນການໃຫ້ສິດອຳນາດແກ່ Agent ຫຼາຍເກີນຄວາມຈຳເປັນ (Excessive Agency). ການສະສົມວິທີການດຳເນີນງານແບບ "ໃຫ້ສິດກວ້າງໆໄວ້ກ່ອນເພື່ອຄວາມສະດວກ" ຈະເຮັດໃຫ້ຂອບເຂດຄວາມເສຍຫາຍຂະຫຍາຍຕົວຂຶ້ນເມື່ອເກີດເຫດການ Agent Drift. ດັ່ງນັ້ນ, ຈຶ່ງມີຄວາມສຳຄັນຫຼາຍທີ່ຈະຕ້ອງອອກແບບໃໝ່ໂດຍຍຶດຖືຫຼັກການໃຫ້ສິດຂັ້ນຕໍ່າສຸດ (Principle of Least Privilege) ເພື່ອໃຫ້ສິດສະເພາະທີ່ຈຳເປັນຕໍ່ແຕ່ລະ Skill ເທົ່ານັ້ນ.

ຄວນບັນທຶກຜົນການສຳຫຼວດໄວ້ເປັນສ່ວນໜຶ່ງຂອງບັນຊີລາຍການສ່ວນປະກອບ AI (AI-BOM) ແລະ ສ້າງລະບົບການດຳເນີນງານເພື່ອອັບເດດທຸກຄັ້ງທີ່ມີການປ່ຽນແປງ ເພື່ອໃຫ້ສາມາດນຳໄປໃຊ້ປະໂຫຍດໃນການກວດສອບຄວາມປອດໄພ (Security Review) ຫຼື ການເຮັດ Red Teaming ໃນພາຍຫຼັງໄດ້.

ຄວາມສຳເລັດຂອງກອບການບໍລິຫານຈັດການ (Governance Framework) ແມ່ນຂຶ້ນຢູ່ກັບວ່າສາມາດເຮັດໃຫ້ພຶດຕິກຳຂອງ Agent "ເຫັນພາບໄດ້" ຫຼືບໍ່. ຖ້າກຳນົດພຽງແຕ່ກົດລະບຽບໃນການກຳກັບດູແລໂດຍບໍ່ມີການກຽມພ້ອມ ໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ດ້ານ AI Observability, ການກວດຫາ Drift ແລະ ການຕິດຕາມຄວາມຮັບຜິດຊອບກໍຈະເຮັດໄດ້ຍາກ.

ປະເພດຂອງ Log ທີ່ຄວນກຽມພ້ອມຈະແຕກຕ່າງກັນໄປຕາມລະດັບຄວາມເປັນອິດສະຫຼະຂອງ Agent. ຖ້າເປັນໂຄງສ້າງທີ່ Agent ດຽວປະຕິບັດໜ້າທີ່ຕາມຮູບແບບທີ່ກຳນົດໄວ້, ການເກັບຂໍ້ມູນ 3 ຢ່າງຄື: System Prompt, Input/Output, ແລະ ປະຫວັດການເອີ້ນໃຊ້ Tool ກໍພຽງພໍແລ້ວ. ແຕ່ສຳລັບລະບົບ Multi-agent ທີ່ມີຫຼາຍ Agent ເຮັດວຽກຕໍ່ເນື່ອງກັນ, ຈຳເປັນຕ້ອງຂະຫຍາຍຂອບເຂດການບັນທຶກຂໍ້ມູນໃຫ້ກວມເອົາເຖິງ Log ການສື່ສານລະຫວ່າງ Agent, ປະຫວັດການເຮັດວຽກຂອງ Task Graph, ແລະ ເຫດຜົນໃນການຕັດສິນໃຈຂອງແຕ່ລະຂັ້ນຕອນ.

ລາຍການເກັບຂໍ້ມູນຂັ້ນຕ່ຳທີ່ຄວນມີມີດັ່ງນີ້:

• Log ການນຳເຂົ້າ ແລະ ສົ່ງອອກ (Input/Output Log): ບັນທຶກຄູ່ຂອງ Prompt ແລະ Response ພ້ອມກັບ Timestamp.
• Log ການເອີ້ນໃຊ້ Tool: ບັນທຶກການເຂົ້າເຖິງ External API, ຖານຂໍ້ມູນ ແລະ ຄ່າທີ່ສົ່ງກັບຄືນມາ.
• Log ຂໍ້ຜິດພາດ ແລະ ຂໍ້ຍົກເວັ້ນ (Error/Exception Log): ການກະທຳທີ່ລົ້ມເຫຼວ, ຈຳນວນຄັ້ງທີ່ Retry, ແລະ ເຫດຜົນທີ່ຢຸດການເຮັດວຽກ.
• ອັດຕາການໃຊ້ງານ Context Window: ການປ່ຽນແປງຂອງປະລິມານ Token ທີ່ໃຊ້ (ມີປະໂຫຍດໃນການກວດຫາສັນຍານເຕືອນກ່ອນການໃຊ້ຊັບພະຍາກອນແບບບໍ່ຈຳກັດ).

ການອອກແບບບ່ອນຈັດເກັບ Log ຕ້ອງສອດຄ່ອງກັບຂໍ້ກຳນົດດ້ານການປະຕິບັດຕາມກົດລະບຽບ (Compliance). ໃນວຽກງານທີ່ມີໂອກາດເກີດຜົນລັອບທີ່ມີຂໍ້ມູນສ່ວນບຸກຄົນ, ຈຳເປັນຕ້ອງມີການອອກແບບເພື່ອເຮັດ Masking ຂໍ້ມູນໃນ Log ກ່ອນນຳໄປຈັດເກັບ.

ນອກຈາກນີ້, ເພື່ອໃຫ້ສາມາດນຳ Log ທີ່ເກັບມາໃຊ້ປະໂຫຍດໃນການກວດສອບດ້ານ Governance ໄດ້, ສິ່ງສຳຄັນຄືການຈັດເກັບໃນຮູບແບບທີ່ສາມາດຕິດຕາມ Data Lineage ໄດ້.

ເມື່ອມີຄຳສັ່ງວ່າ "ມາສ້າງ Governance Framework ກັນເຖີດ" ມັກຈະມີຫຼາຍກໍລະນີທີ່ການດຳເນີນງານຍັງສືບຕໍ່ໄປໂດຍທີ່ຍັງບໍ່ມີຄວາມຊັດເຈນວ່າໃຜຈະເປັນຜູ້ຮັບຜິດຊອບສູງສຸດ.

ຖ້າຫາກຂາດ Governance Owner, ການຕັດສິນໃຈກ່ຽວກັບການປ່ຽນແປງສິດອຳນາດຂອງ Agent ຫຼື ການຮັບມືກັບອຸບັດຕິເຫດ (Incident) ຈະບໍ່ມີຄວາມຊັດເຈນ ເຊິ່ງເປັນສາເຫດທີ່ເຮັດໃຫ້ການແກ້ໄຂບັນຫາລ່າຊ້າ. ກ່ອນທີ່ຈະສ້າງ Framework, ຈຳເປັນຕ້ອງມີການຈັດລະບຽບ Stakeholder ທີ່ກ່ຽວຂ້ອງ ແລະ ກຳນົດແກນຫຼັກໃນການຕັດສິນໃຈໃຫ້ຈະແຈ້ງ.

Stakeholder ຫຼັກທີ່ຕ້ອງລະບຸ

• Governance Owner (Executive Sponsor): ຮັບຜິດຊອບຕໍ່ການອະທິບາຍການດຳເນີນງານຂອງ Agent ທັງໝົດ. ໂດຍສ່ວນໃຫຍ່ແລ້ວ ຫົວໜ້າພະແນກລະບົບຂໍ້ມູນຂ່າວສານ ຫຼື ລະດັບ CIO ຈະເປັນຜູ້ຮັບຜິດຊອບໃນສ່ວນນີ້.
• ຜູ້ຮັບຜິດຊອບດ້ານການສົ່ງເສີມ AI (AI Lead): ເຮັດໜ້າທີ່ເປັນຕົວເຊື່ອມຕໍ່ລະຫວ່າງມາດຕະຖານ ຫຼື Specification ດ້ານເຕັກນິກ ແລະ ຄວາມຕ້ອງການທາງທຸລະກິດ. ເປັນຜູ້ນຳໃນການປະເມີນຄວາມສ່ຽງຂອງແຕ່ລະ Use case.
• ຜູ້ຮັບຜິດຊອບດ້ານກົດໝາຍ ແລະ ການປະຕິບັດຕາມກົດລະບຽບ (Compliance): ຮັບຜິດຊອບການກວດສອບຄວາມສອດຄ່ອງກັບ EU AI Act ຫຼື NIST AI RMF ແລະ ຈັດການຂອບເຂດຄວາມຮັບຜິດຊອບຕາມສັນຍາ.
• ເຈົ້າຂອງພາກສ່ວນທຸລະກິດ (Business Owner): ຜູ້ຮັບຜິດຊອບຕົວຈິງຂອງຂະບວນການທີ່ Agent ເຮັດວຽກຢູ່. ເປັນຕຳແໜ່ງທີ່ຮັບຮູ້ເຖິງຜົນກະທົບຕໍ່ການເຮັດວຽກກ່ອນໝູ່ ເມື່ອເກີດບັນຫາ Drift.
• ຜູ້ຮັບຜິດຊອບດ້ານຄວາມປອດໄພ (Security): ຮັບຜິດຊອບການກວດສອບຄວາມຖືກຕ້ອງຂອງຂອບເຂດສິດອຳນາດ ແລະ ການຈັດຕຽມຂັ້ນຕອນການຮັບມືກັບອຸບັດຕິເຫດ.

ການກຳນົດບົດບາດດ້ວຍ RACI Matrix

ການລະບຸພຽງແຕ່ລາຍຊື່ Stakeholder ຢ່າງດຽວນັ້ນຍັງບໍ່ພຽງພໍ. ສຳລັບກິດຈະກຳດ້ານ Governance ແຕ່ລະຢ່າງ (ການອະນຸມັດປ່ຽນແປງສິດອຳນາດ, ການກວດສອບ Log, ການຮັບມືກັບອຸບັດຕິເຫດ ແລະ ອື່ນໆ) ຕ້ອງມີການລະບຸໃຫ້ຊັດເຈນໃນ RACI Matrix ວ່າໃຜເປັນຜູ້ຮັບຜິດຊອບໃນສ່ວນຂອງ R (Responsible - ຜູ້ປະຕິບັດ), A (Accountable - ຜູ້ຮັບຜິດຊອບສູງສຸດ), C (Consulted - ຜູ້ທີ່ຕ້ອງປຶກສາຫາລື), ແລະ I (Informed - ຜູ້ທີ່ຕ້ອງໄດ້ຮັບແຈ້ງ).

ໃນການອອກແບບແບບຈຳລອງການກຳກັບດູແລ (Supervisory model), ສິ່ງທຳອິດທີ່ຄວນຖາມຄື "ເອເຈນ (Agent) ນີ້ຄວນມີຄວາມເປັນອິດສະຫຼະໃນການເຮັດວຽກໄດ້ຫຼາຍປານໃດ". ຖ້າເພີ່ມລະດັບຄວາມເປັນອິດສະຫຼະໃຫ້ສູງຂຶ້ນ ການປະມວນຜົນກໍຈະໄວຂຶ້ນ ແຕ່ໃນຂະນະດຽວກັນກໍຈະມີຄວາມສ່ຽງທີ່ພຶດຕິກຳທີ່ບໍ່ໄດ້ຄາດຄິດໄວ້ຈະສົ່ງຜົນກະທົບໂດຍກົງຕໍ່ວຽກງານ. ຖ້າຫາກດຳເນີນການຈັດຕັ້ງປະຕິບັດໂດຍປ່ອຍໃຫ້ ການແລກປ່ຽນ ຫຼື Trade-off ນີ້ບໍ່ຊັດເຈນ, ຈະເຮັດໃຫ້ຕ້ອງກັບມາເພີ່ມລະບົບການກຳກັບດູແລ (Governance) ໃນພາຍຫຼັງ.

ການຄິດໂດຍລຽງລຳດັບຄື: ກຳນົດລະດັບການມີສ່ວນຮ່ວມຂອງມະນຸດກ່ອນ, ຈາກນັ້ນອອກແບບວ່າຈະຄວບຄຸມໃນຈຸດໃດຂອງ Task graph, ແລະ ສຸດທ້າຍແມ່ນເຮັດໃຫ້ເປັນຮູບປະທຳໃນຮູບແບບຂອງຂະບວນການອະນຸມັດ (Approval flow) — ວິທີນີ້ຈະຊ່ວຍຫຼຸດຜ່ອນຄວາມຜິດພາດໃນການອອກແບບໄດ້.

ໃນເບື້ອງຕົ້ນ ເຮົາມັກຈະຄິດວ່າ "ການໃຫ້ມະນຸດມີສ່ວນຮ່ວມໃນທຸກຂັ້ນຕອນການອະນຸມັດຈະມີຄວາມປອດໄພ", ແຕ່ໃນຄວາມເປັນຈິງແລ້ວ ການເລືອກໃຊ້ຮູບແບບການກຳກັບດູແລ (Supervision Model) ໃຫ້ເໝາະສົມກັບລັກສະນະຂອງວຽກງານ ຈະມີປະສິດທິຜົນຫຼາຍກວ່າໃນການຫຼຸດຜ່ອນຄວາມສ່ຽງ ແລະ ເພີ່ມປະສິດທິພາບໃນການເຮັດວຽກ.

ຮູບແບບການກຳກັບດູແລທັງ 3 ແບບ ມີນິຍາມດັ່ງນີ້:

• HITL (Human-in-the-Loop): ມະນຸດຈະຕ້ອງເປັນຜູ້ອະນຸມັດຢ່າງຈະແຈ້ງ ກ່ອນທີ່ Agent ຈະດຳເນີນການໃດໆ. ໃຊ້ກັບວຽກທີ່ມີຄວາມສ່ຽງສູງ ແລະ ບໍ່ສາມາດຍົກເລີກໄດ້ (ເຊັ່ນ: ການສົ່ງສັນຍາ, ການຂຽນຂໍ້ມູນລົງໃນ API ພາຍນອກ ແລະ ອື່ນໆ)
• On the Loop: Agent ຈະເຮັດວຽກແບບອັດຕະໂນມັດ ໃນຂະນະທີ່ມະນຸດຍັງສາມາດຕິດຕາມ ແລະ ເຂົ້າແຊກແຊງໄດ້ແບບ Real-time. ເໝາະກັບວຽກທີ່ມີຄວາມສ່ຽງປານກາງ ແລະ ເປັນວຽກທີ່ເຮັດຊ້ຳໆ (ເຊັ່ນ: ການແປງຂໍ້ມູນ, ການສົ່ງແຈ້ງເຕືອນພາຍໃນອົງກອນໂດຍອັດຕະໂນມັດ ແລະ ອື່ນໆ)
• Outside the Loop: Agent ເຮັດວຽກແບບອັດຕະໂນມັດຢ່າງສົມບູນ ໂດຍມະນຸດພຽງແຕ່ກວດສອບບັນທຶກການເຮັດວຽກ (Log) ພາຍຫຼັງເທົ່ານັ້ນ. ຈຳກັດສະເພາະວຽກທີ່ມີຄວາມສ່ຽງຕ່ຳ ແລະ ສາມາດຍົກເລີກໄດ້ຢ່າງສົມບູນ (ເຊັ່ນ: ການສະຫຼຸບຂໍ້ມູນແບບອ່ານຢ່າງດຽວ ແລະ ອື່ນໆ)

ປັດໄຈໃນການຕັດສິນໃຈເລືອກໃຊ້ແມ່ນອີງໃສ່ 2 ແກນຫຼັກ ຄື "ຄວາມບໍ່ສາມາດຍົກເລີກໄດ້ (Irreversibility)" ແລະ "ຂອບເຂດຜົນກະທົບ (Impact Scope)".

"Model AI Governance Framework for Agentic AI" ຂອງ Singapore (Version 1.

Task Graph ແມ່ນການສະແດງຄວາມສຳພັນແບບເພິ່ງພາອາໄສກັນຂອງວຽກງານທີ່ Agent ປະຕິບັດ ໃນຮູບແບບຂອງ Directed Acyclic Graph (DAG). ການອອກແບບຈຸດຄວບຄຸມ (Control Points) ໄວ້ໃນ Node ໃດໜຶ່ງເທິງ Graph ນີ້ລ່ວງໜ້າ ຄື ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ຂອງການກຳກັບດູແລ (Governance) ໃນການຈັດການ Agent.

ໃນການອອກແບບຈຸດຄວບຄຸມ, ການໃຊ້ "ຄວາມສາມາດໃນການຍ້ອນກັບໄດ້" (Reversibility) ແລະ "ຂອບເຂດຂອງຜົນກະທົບ" (Impact Scope) ເປັນແກນໃນການຕັດສິນໃຈຈະມີປະສິດທິພາບ. ສຳລັບຂະບວນການທີ່ມີຄວາມສາມາດໃນການຍ້ອນກັບໄດ້ສູງ ແລະ ມີຂອບເຂດຜົນກະທົບຈຳກັດ ເຊັ່ນ: ການອ່ານຂໍ້ມູນ ຫຼື ການຄົ້ນຫາ, ຄວນອະນຸຍາດໃຫ້ Agent ປະຕິບັດງານໄດ້ດ້ວຍຕົນເອງ; ສ່ວນຂະບວນການທີ່ບໍ່ສາມາດຍ້ອນກັບໄດ້ ແລະ ມີຂອບເຂດຜົນກະທົບກວ້າງ ເຊັ່ນ: ການຮຽກໃຊ້ External API, ການດຳເນີນການຊຳລະເງິນ ຫຼື ການລຶບໄຟລ໌, ຄວນມີການໃສ່ລະບົບການອະນຸມັດຈາກມະນຸດ ຫຼື ປະຕູຢຸດພັກຊົ່ວຄາວ (Pause Gate).

ຈຸດຫຼັກທີ່ຄວນອອກແບບເປັນຈຸດຄວບຄຸມມີດັ່ງນີ້:

• ປະຕູທາງເຂົ້າ (Entrance Gate): ໃນຂະນະທີ່ເລີ່ມຕົ້ນ Task Graph, ໃຫ້ກວດສອບວ່າ Input Parameter ຢູ່ໃນຂອບເຂດສິດທິທີ່ກຳນົດໄວ້ຫຼືບໍ່
• Node ແຍກ (Branch Node): ວາງການກວດສອບໄວ້ໃນຈຸດທີ່ເສັ້ນທາງການປະຕິບັດງານປ່ຽນແປງຕາມເງື່ອນໄຂ ເພື່ອກວດສອບວ່າບໍ່ມີການຫຼົງທາງໄປສູ່ Path ທີ່ບໍ່ໄດ້ຕັ້ງໃຈ
• Node ເຊື່ອມຕໍ່ລະບົບພາຍນອກ (External System Integration Node): ເພື່ອປ້ອງກັນການໃຫ້ສິດ Agent ຫຼາຍເກີນໄປ (Excessive Agency), ໃຫ້ຈຳກັດ API ແລະ ເຄື່ອງມືທີ່ສາມາດຮຽກໃຊ້ໄດ້ດ້ວຍ Whitelist
• ປະຕູທາງອອກ (Exit Gate): ເມື່ອວຽກງານສຳເລັດ, ໃຫ້ກວດສອບດ້ວຍ Grounding Check ວ່າຜົນລັພທີ່ໄດ້ຮັບນັ້ນຢູ່ໃນຂອບເຂດຂອງ ມາດຕະຖານ ຫຼື Specification ທີ່ຄາດຫວັງໄວ້ຫຼືບໍ່

ໃນລະບົບ Multi-agent, ຈະເກີດການເຊື່ອມໂຍງທີ່ Sub-agent ຮຽກໃຊ້ Sub-agent ອື່ນຕໍ່ໆກັນໄປ.

"ຕົວແທນ (Agent) ໄດ້ໂທຫາ API ພາຍນອກເພື່ອຢືນຢັນການສັ່ງຊື້ໂດຍບໍ່ໄດ້ຮັບອະນຸຍາດ" — ເພື່ອປ້ອງກັນສະຖານະການດັ່ງກ່າວ, ການກຳນົດຂັ້ນຕອນການອະນຸມັດ ແລະ ເງື່ອນໄຂການສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ (Escalation) ລ່ວງໜ້າແມ່ນສິ່ງທີ່ຂາດບໍ່ໄດ້.

ຂັ້ນຕອນການອະນຸມັດຄວນຖືກອອກແບບໂດຍອີງໃສ່ຂອບເຂດຜົນກະທົບ ແລະ ຄວາມສາມາດໃນການຍົກເລີກຂອງວຽກງານ. ໂດຍສະເພາະ, ສາມຂັ້ນຕອນຕໍ່ໄປນີ້ແມ່ນມີປະສິດທິພາບ:

• ການປະຕິບັດງານອັດຕະໂນມັດ (ບໍ່ຕ້ອງມີການອະນຸມັດ): ການປະຕິບັດງານແບບອ່ານຢ່າງດຽວ (Read-only) ຫຼື ການອ້າງອີງ, ວຽກງານທີ່ມີຜົນກະທົບໃນວົງຈຳກັດ ແລະ ສາມາດຍົກເລີກ (Rollback) ໄດ້ທັນທີ.
• ການອະນຸມັດແບບບໍ່ປະສານເວລາ (On the Loop): ການຂຽນຂໍ້ມູນໃສ່ບໍລິການພາຍນອກ, ການປະມວນຜົນທີ່ຈຳນວນເງິນ ຫຼື ປະລິມານເກີນຂີດຈຳກັດທີ່ກຳນົດໄວ້. ຜູ້ຮັບຜິດຊອບຈະກວດສອບພາຍຫຼັງ ແລະ ສົ່ງກັບຄືນຫາກມີບັນຫາ.
• ການອະນຸມັດແບບປະສານເວລາ (In the Loop): ການປະຕິບັດງານທີ່ມີຄວາມສ່ຽງສູງ ແລະ ບໍ່ສາມາດຍົກເລີກໄດ້ ເຊັ່ນ: ການເຊັນສັນຍາ, ການສົ່ງຂໍ້ມູນສ່ວນຕົວໄປພາຍນອກ, ຫຼື ການປ່ຽນແປງໃນສະພາບແວດລ້ອມຈິງ (Production). ຕົວແທນຈະຢຸດການປະມວນຜົນຈົນກວ່າຈະໄດ້ຮັບການອະນຸມັດ.

ເງື່ອນໄຂການສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ (Escalation) ຈະມີຄວາມຄົບຖ້ວນຫຼາຍຂຶ້ນຫາກກຳນົດໂດຍໃຊ້ຕົວກະຕຸ້ນ (Trigger) ດັ່ງຕໍ່ໄປນີ້:

• ເມື່ອຄະແນນຄວາມເຊື່ອໝັ້ນ (Confidence Score) ຫຼຸດລົງຕໍ່າກວ່າຂີດຈຳກັດ (ຄວາມສ່ຽງຕໍ່ການເກີດ Hallucination ເພີ່ມຂຶ້ນ)
• ເມື່ອຈຳນວນຂັ້ນຕອນທີ່ຄາດໄວ້ໃນ Task Graph ເກີນກຳນົດ
• ເມື່ອເກີດຂໍ້ຜິດພາດໃນການເອີ້ນໃຊ້ເຄື່ອງມືພາຍນອກຢ່າງຕໍ່ເນື່ອງ
• ເມື່ອຂໍ້ມູນທີ່ໃຊ້ໃນການປະມວນຜົນຖືກຕັດສິນວ່າເປັນຂໍ້ມູນລັບ

ການເຮັດໃຫ້ປາຍທາງຂອງການສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ເປັນອັດຕະໂນມັດຕາມລຳດັບ "ຢຸດການເຮັດວຽກທັນທີ → ແຈ້ງເຕືອນຜູ້ຮັບຜິດຊອບ → ສ້າງປີ້ (Ticket) ໃນເຄື່ອງມືຈັດການເຫດການ (Incident Management)" ຈະຊ່ວຍປ້ອງກັນການຕົກຫຼົ່ນໃນການແກ້ໄຂບັນຫາ.

ຂັ້ນຕອນການອະນຸມັດບໍ່ແມ່ນສິ່ງທີ່ອອກແບບຄັ້ງດຽວແລ້ວຈົບ. ການລວມເອົາວົງຈອນການດຳເນີນງານທີ່ຕ້ອງມີການທົບທວນຄືນ ແລະ ອັບເດດເງື່ອນໄຂທຸກຄັ້ງທີ່ມີການປ່ຽນແປງຂອບເຂດສິດອຳນາດຂອງຕົວແທນ ຫຼື ຂະບວນການເຮັດວຽກ ແມ່ນກຸນແຈສຳຄັນໃນການຄວບຄຸມ Agent Drift ຢ່າງຕໍ່ເນື່ອງ.

ເຖິງວ່າຈະມີການກຳນົດຈຸດຄວບຄຸມໄວ້ໃນການອອກແບບການກຳກັບດູແລ (Supervised Design) ແຕ່ຖ້າຫາກບໍ່ມີ "ກົນໄກການຢຸດ" ທີ່ໃຊ້ງານໄດ້ຈິງໃນລະດັບການປ້ອນຂໍ້ມູນ ແລະ ການສະແດງຜົນ ກໍຈະເປັນພຽງແຕ່ທິດສະດີທີ່ບໍ່ສາມາດນຳໃຊ້ໄດ້ຈິງ. ບັນຫາ Prompt Injection, ການແຜ່ກະຈາຍຂອງຜົນລັພທີ່ບໍ່ໄດ້ຕັ້ງໃຈ, ແລະ ການສູນເສຍຄວາມຖືກຕ້ອງຂອງຂໍ້ມູນ (Grounding) — ສິ່ງເຫຼົ່ານີ້ບໍ່ສາມາດປ້ອງກັນໄດ້ດ້ວຍເອກະສານນະໂຍບາຍພຽງຢ່າງດຽວ. ໃນທີ່ນີ້, ພວກເຮົາຈະອະທິບາຍຂັ້ນຕອນການຈັດຕັ້ງປະຕິບັດຢ່າງລະອຽດ ເພື່ອເຮັດໃຫ້ຈຸດຄວບຄຸມມີປະສິດທິຜົນ, ລວມເຖິງການນຳໃຊ້ NeMo Guardrails ແລະ ການກວດສອບຄວາມຖືກຕ້ອງຂອງຂໍ້ມູນ (Grounding check).

ໃນການອອກແບບ Guardrail, ຫຼາຍຄົນມັກຄິດວ່າ "ການກວດສອບສະເພາະຝັ່ງ Output ກໍພຽງພໍແລ້ວ" ແຕ່ໃນຄວາມເປັນຈິງ ການຄວບຄຸມໃນຂັ້ນຕອນ Input ນັ້ນເອງທີ່ເຮັດໜ້າທີ່ເປັນປ້ອມປ້ອງກັນດ່ານທຳອິດ. Output filter ເປັນພຽງຕາໜ່າງຄວາມປອດໄພຂັ້ນສຸດທ້າຍເທົ່ານັ້ນ ແລະ ຫຼັງຈາກທີ່ຄຳສັ່ງທີ່ບໍ່ຫວັງດີໄດ້ຫຼຸດເຂົ້າໄປໃນຂະບວນການ Inference ຂອງ Model ແລ້ວ, ຄວາມຍາກໃນການຄວບຄຸມຈະເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ.

ໃນໂຄງສ້າງທີ່ AI Agent ເຊື່ອມຕໍ່ກັບເຄື່ອງມືພາຍນອກ ຫຼື ແຫຼ່ງຂໍ້ມູນ, ຕ້ອງລະວັງຈຸດທີ່ວ່າເສັ້ນທາງຂອງ Prompt Injection ຈະເພີ່ມຂຶ້ນຢ່າງຫຼວງຫຼາຍ. Direct Injection ເປັນວິທີການຝັງຄຳສັ່ງທີ່ບໍ່ຫວັງດີລົງໃນ Input ຂອງຜູ້ໃຊ້, ໃນຂະນະທີ່ Indirect Injection ເປັນວິທີການຝັງຄຳສັ່ງໂຈມຕີລົງໃນ Content ພາຍນອກທີ່ Agent ດຶງຂໍ້ມູນມາ (ເຊັ່ນ: ໜ້າເວັບ, ເອກະສານ, API response ແລະ ອື່ນໆ) ເຊິ່ງມີແນວໂນ້ມທີ່ຈະກວດຈັບໄດ້ຍາກກວ່າ.

ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ໃນການຈັດຕັ້ງປະຕິບັດການຄວບຄຸມ Input ແລະ Output ມີດັ່ງນີ້:

NeMo Guardrails ແມ່ນໂຄງຮ່າງການປ້ອງກັນ (Guardrail framework) ແບບເປີດທີ່ຊ່ວຍໃຫ້ທ່ານສາມາດກຳນົດນະໂຍບາຍສຳລັບການປ້ອນຂໍ້ມູນ ແລະ ການສະແດງຜົນຂອງ LLM ໄດ້ຢ່າງຊັດເຈນ. ໂດຍການນຳໃຊ້ໄຟລ໌ການຕັ້ງຄ່າທີ່ອີງໃສ່ YAML ຮ່ວມກັບ DSL ສະເພາະທີ່ເອີ້ນວ່າ Colang, ທ່ານສາມາດຄວບຄຸມພຶດຕິກຳຂອງ Agent ໄດ້ໂດຍບໍ່ຈຳເປັນຕ້ອງປ່ຽນແປງໂຄ້ດ.

ວິທີການນຳໃຊ້ນະໂຍບາຍຈະມີແກນຫຼັກ ຫຼື ຈຸດສຳຄັນໃນການຕັດສິນໃຈທີ່ແຕກຕ່າງກັນໄປຕາມລະດັບຄວາມເປັນອິດສະຫຼະຂອງ Agent. ສຳລັບໂຄງສ້າງແບບ On the Loop ທີ່ມີຂັ້ນຕອນການອະນຸມັດ, ໂດຍທົ່ວໄປແລ້ວຈະໃຊ້ການປະສົມປະສານລະຫວ່າງ "ການບລັອກການຕອບໂຕ້ໃນຫົວຂໍ້ທີ່ຫ້າມ" ແລະ "ການແຈ້ງເຕືອນການຍົກລະດັບ", ສ່ວນໃນກໍລະນີທີ່ເປັນການເຮັດວຽກອັດຕະໂນມັດຢ່າງສົມບູນແບບ Outside the Loop, ຈະໃຫ້ຄວາມສຳຄັນກັບ "ການແກ້ໄຂຜົນລັດອັດຕະໂນມັດ (Rewrite)" ແລະ "ການຢຸດການເຮັດວຽກອັດຕະໂນມັດພ້ອມກຳນົດຂີດຈຳກັດການລອງໃໝ່".

ຂັ້ນຕອນການຈັດຕັ້ງປະຕິບັດຕົວຈິງມີດັ່ງນີ້:

ມີຫຼາຍສະຖານະການທີ່ພະນັກງານໜ້າວຽກມັກຈະເກີດຄວາມລັງເລໃຈວ່າ ຄວນຈະສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ລະບົບປາຍທາງໂດຍກົງເລີຍຫຼືບໍ່ ຫຼັງຈາກທີ່ Agent ໄດ້ສ້າງຜົນລັດອອກມາ.

Grounding Check ຄືກົນໄກໃນການກວດສອບໂດຍອັດຕະໂນມັດວ່າ ຜົນລັດຂອງ Agent ມີພື້ນຖານມາຈາກບໍລິບົດອ້າງອີງ (ເອກະສານທີ່ດຶງມາຈາກ RAG, System Prompt, ຜົນລັດຈາກການເອີ້ນໃຊ້ Tool) ຫຼືບໍ່. ມັນເຮັດໜ້າທີ່ເປັນແນວປ້ອງກັນສຸດທ້າຍເພື່ອປ້ອງກັນການຈັດການຜົນລັດທີ່ບໍ່ເໝາະສົມ (Improper Output Handling).

ໃນດ້ານການປະຕິບັດງານ, ມີ 3 ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ທີ່ຄວນກວດສອບ:

• ການກວດສອບຄວາມສອດຄ່ອງຂອງພື້ນຖານຂໍ້ມູນ (Grounding Consistency Check): ໃຫ້ຄະແນນວ່າຂໍ້ສະເໜີແນະໃນຜົນລັດນັ້ນກົງກັບສ່ວນໃດຂອງເອກະສານທີ່ດຶງມາ, ຖ້າຄະແນນຕ່ຳກວ່າເກນທີ່ກຳນົດໄວ້ ໃຫ້ລະງັບຜົນລັດນັ້ນໄວ້ ຫຼື ສ້າງໃໝ່.
• ການກວດສອບການອອກນອກຂອບເຂດ (Scope Deviation Detection): ກວດສອບທາງໂຄງສ້າງວ່າຜົນລັດນັ້ນໄດ້ສະແດງເຖິງການກະທຳທີ່ຢູ່ນອກຂອບເຂດສິດທີ່ Agent ໄດ້ຮັບຫຼືບໍ່ (ຕົວຢ່າງ: ການຮ້ອງຂໍຂຽນຂໍ້ມູນໂດຍ Agent ທີ່ມີສິດອ່ານຢ່າງດຽວ).
• ການຍັບຍັ້ງການເກີດ Hallucination: ຕັ້ງຄ່າ Flag ຖ້າຫາກຊື່ສະເພາະ ຫຼື ຕົວເລກທີ່ປາກົດໃນຜົນລັດ ບໍ່ມີຢູ່ໃນຂໍ້ມູນພາຍໃນ Context Window.

ສຳລັບຮູບແບບການປະຕິບັດງານ, ວິທີການທີ່ນິຍົມໃຊ້ກັນຢ່າງແຜ່ຫຼາຍຄືການວາງ output rails ຂອງ NeMo Guardrails ໄວ້ທີ່ທ້າຍຂອງຂະບວນການ ຫຼື Pipeline ເພື່ອປະເມີນຜົນລັດໂດຍອັດຕະໂນມັດກ່ອນທີ່ຈະສົ່ງໄປຍັງລະບົບການຜະລິດ. ຜົນການປະເມີນຈະຖືກບັນທຶກໄວ້ໃນ Log ແລະສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ພື້ນຖານໂຄງສ້າງ ຫຼື Infrastructure ດ້ານ AI Observability ເພື່ອເຊື່ອມຕໍ່ກັບການກວດສອບ Drift ທີ່ຈະອະທິບາຍໃນຂັ້ນຕອນຕໍ່ໄປ.

ສະຫຼຸບ: ຫາກປ່ອຍປະລະເລີຍ Agent Drift ຈະສົ່ງຜົນໂດຍກົງຕໍ່ຄວາມເສຍຫາຍທາງທຸລະກິດ, ສະນັ້ນ ຈຶ່ງຈຳເປັນຕ້ອງອອກແບບກົນໄກການກວດສອບ ແລະ ແກ້ໄຂໃຫ້ສຳເລັດກ່ອນເລີ່ມການເຮັດວຽກ.

ສ້າງມາດຕະການປ້ອງກັນດ້ວຍ 3 ຊັ້ນ ຄື: ການຕິດຕາມແບບ Real-time ດ້ວຍ AI Observability, ການອອກແບບຕົວຊີ້ວັດການຕິດຕາມ, ແລະ ຂັ້ນຕອນການຢຸດການເຮັດວຽກອັດຕະໂນມັດ ຫຼື ການ Rollback ຫຼັງຈາກກວດພົບຄວາມຜິດປົກກະຕິ.

ການກວດຫາ Agent Drift ມັກຈະຖືກຄິດວ່າວິທີການ "ກວດສອບບັນທຶກຍ້ອນຫຼັງ" ແມ່ນພຽງພໍແລ້ວ, ແຕ່ໃນຄວາມເປັນຈິງແລ້ວ ການຕິດຕາມແບບ Batch ແບບບໍ່ປະສານເວລາມັກຈະເຮັດໃຫ້ຮູ້ສຶກຕົວເມື່ອການບ່ຽງເບນຂະຫຍາຍຕົວຂຶ້ນແລ້ວ, ດັ່ງນັ້ນການສັງເກດການ ແບບ Real-time ຈຶ່ງສາມາດຫຼຸດຜ່ອນຄວາມເສຍຫາຍໄດ້ດີທີ່ສຸດ.

AI Observability ແມ່ນກົນໄກໃນການວັດແທກ ແລະ ເຮັດໃຫ້ເຫັນພາບຂະບວນການຄາດຄະເນ (Inference), ການຮຽກໃຊ້ Tool ແລະ ຜົນລັພລະຫວ່າງທາງຂອງ Agent ຢ່າງຕໍ່ເນື່ອງ. ແຕກຕ່າງຈາກ APM (Application Performance Monitoring) ແບບດັ້ງເດີມ, ຈຸດເດັ່ນຂອງມັນຄືການລວມເອົາ ການບ່ຽງເບນທາງຄວາມໝາຍ (ຄວາມຜິດພາດຂອງເຈດຕະນາໃນຜົນລັພ ຫຼື ການກະທຳທີ່ນອກເໜືອຈາກຂອບເຂດ) ເຂົ້າເປັນເປົ້າໝາຍໃນການກວດຫາອີກດ້ວຍ.

ຈຸດສັງເກດການຫຼັກຂອງການກວດຫາຄວາມຜິດປົກກະຕິ ແບບ Real-time ມີດັ່ງນີ້:

• ການເພີ່ມຂຶ້ນຢ່າງກະທັນຫັນຂອງຄວາມຖີ່ໃນການຮຽກໃຊ້ Tool: ເມື່ອເກີນຈຳນວນການ Call ທີ່ຄາດໄວ້ ໃຫ້ສົ່ງສັນຍານເຕືອນເພື່ອຄວບຄຸມການບໍລິໂພກຊັບພະຍາກອນແບບບໍ່ຈຳກັດ (Unbounded Consumption)
• ອັດຕາການໃຊ້ງານ Context Window: ເນື່ອງຈາກຄວາມຖືກຕ້ອງໃນການຄາດຄະເນມັກຈະຫຼຸດລົງເມື່ອໃກ້ຮອດຂີດຈຳກັດ, ຈຶ່ງຄວນກຳນົດຄ່າ Threshold ເພື່ອແຈ້ງເຕືອນໂດຍອັດຕະໂນມັດ
• ຄະແນນຄວາມເຊື່ອໝັ້ນຂອງຜົນລັພຫຼຸດລົງ: ນຳໄປປະສົມປະສານກັບ Grounding Check, ຖ້າຄະແນນຕໍ່າກວ່າເກນທີ່ກຳນົດໄວ້ ໃຫ້ສົ່ງຜົນລັພນັ້ນໄປຍັງຄິວແຍກ (Isolation Queue)
• ຮູບແບບຄວາມຜິດປົກກະຕິໃນການສື່ສານລະຫວ່າງ Agent (A2A): ກວດຫາການຮ້ອງຂໍໄປຍັງ Agent ທີ່ບໍ່ໄດ້ຄາດຄິດໄວ້ ຫຼື ການຕອບສະໜອງທີ່ລົ້ມເຫຼວຊ້ຳໆ

ໃນດ້ານການຈັດຕັ້ງປະຕິບັດ, ສະຖາປັດຕະຍະກຳທີ່ມີປະສິດທິພາບຄືການເກັບຮວບລວມ Trace ໃນຮູບແບບ Structured Log ແລະ ບັນທຶກພຶດຕິກຳຂອງ Agent ໃນລະດັບ Span.

ການອອກແບບຕົວຊີ້ວັດການຕິດຕາມ (Monitoring Metrics) ຕ້ອງຕັດສິນໃຈກ່ອນວ່າ "ຈະວັດແທກຫຍັງ", ຖ້າບໍ່ດັ່ງນັ້ນ ບັນທຶກຂໍ້ມູນ (Logs) ມະຫາສານຈະສະສົມຢູ່ໂດຍທີ່ເຮົາອາດຈະພາດການກວດຈັບຄວາມຜິດປົກກະຕິໄດ້ງ່າຍ.

ເນື່ອງຈາກ Hallucination ແລະ ການບ່ຽງເບນຈາກເປົ້າໝາຍ (Goal Deviation) ມີລັກສະນະທີ່ແຕກຕ່າງກັນ, ການອອກແບບກຸ່ມຕົວຊີ້ວັດທີ່ເປັນອິດສະຫຼະຕໍ່ກັນຈຶ່ງມີຄວາມສຳຄັນຫຼາຍ.

ຕົວຊີ້ວັດຫຼັກໃນການຕິດຕາມ Hallucination

• Grounding Score: ໃນກໍລະນີທີ່ໃຊ້ RAG, ໃຫ້ປະລິມານອັດຕາການກົງກັນລະຫວ່າງຜົນລັອບກັບເອກະສານອ້າງອີງ ໂດຍໃຊ້ Cosine Similarity ຫຼື ອື່ນໆ.
• ອັດຕາຄວາມສອດຄ່ອງຂອງຂໍ້ເທັດຈິງ (Fact Consistency Rate): ກວດສອບອັດຕະໂນມັດວ່າ ຕົວເລກ ຫຼື ຄຳນາມສະເພາະໃນຜົນລັອບສຸດທ້າຍ ກົງກັບຜົນທີ່ໄດ້ຈາກການສອບຖາມຜ່ານ API ພາຍນອກ ຫຼື ຖານຂໍ້ມູນຫຼືບໍ່.
• ອັດຕາການກວດພົບຄວາມຂັດແຍ່ງໃນຕົວເອງ (Self-Contradiction Detection Rate): ນັບຈຳນວນຄັ້ງທີ່ Agent ມີການໂຕ້ຖຽງກັນເອງໃນເນື້ອຫາທີ່ກ່າວມາກ່ອນໜ້າ ແລະ ຫຼັງໃນ Session ດຽວກັນ.

ຕົວຊີ້ວັດຫຼັກໃນການຕິດຕາມການບ່ຽງເບນຈາກເປົ້າໝາຍ (Agent Drift)

• ອັດຕາການບ່ຽງເບນຈາກຂອບເຂດວຽກ (Task Scope Deviation Rate): ສັດສ່ວນຂອງການປະຕິບັດງານທີ່ Agent ເຮັດຢູ່ນອກຂອບເຂດທີ່ກຳນົດໄວ້ໃນ Task Graph.
• ຄວາມຖີ່ຂອງການຮຽກໃຊ້ເຄື່ອງມືຜິດປົກກະຕິ (Tool Call Anomaly Frequency): ຈຳນວນຄັ້ງທີ່ເກີດການຮຽກໃຊ້ເຄື່ອງມືຊ້ຳໆ ຫຼື ການໃຊ້ງານເຄື່ອງມືຮ່ວມກັນໃນຮູບແບບທີ່ບໍ່ໄດ້ຄາດຄິດໄວ້.
• ທ່າອ່ຽງອັດຕາການບັນລຸເປົ້າໝາຍ (Goal Achievement Rate Trend): ຖ້າອັດຕາການບັນລຸເປົ້າໝາຍຫຼຸດລົງຢ່າງກະທັນຫັນໃນໄລຍະສັ້ນ, ອາດສະແດງເຖິງຄວາມເປັນໄປໄດ້ຂອງການເສື່ອມສະພາບຂອງ Prompt ຫຼື ການປົນເປື້ອນຂອງຂໍ້ມູນພາຍນອກ.

ການຕັ້ງຄ່າ Threshold ຂອງຕົວຊີ້ວັດຈະປ່ຽນແປງໄປຕາມ Use Case. ໃນກໍລະນີວຽກງານດ້ານການປະຕິບັດຕາມກົດລະບຽບ (Compliance) ທີ່ຕ້ອງການຄວາມຜິດພາດຈາກ Hallucination ຕ່ຳ, ການຕັ້ງຄ່າ Threshold ຂອງ Grounding Score ໃຫ້ເຂັ້ມງວດແມ່ນມີປະສິດທິຜົນ, ໃນຂະນະທີ່ວຽກງານການສຳຫຼວດຂໍ້ມູນ (Exploratory Research) ຄວນເປີດກວ້າງຂອບເຂດການຍອມຮັບອັດຕາການບ່ຽງເບນຈາກເປົ້າໝາຍໃຫ້ຫຼາຍຂຶ້ນ.

ຫຼັງຈາກກວດພົບ Drift ແລ້ວ, ຫຼາຍໜ້າວຽກມັກຈະເກີດຄວາມລັງເລໃນການຕັດສິນໃຈວ່າ "ຄວນຢຸດທັນທີ ຫຼື ຄວນສັງເກດການຕໍ່ໄປ". ຄວາມລັງເລນີ້ເປັນຮູບແບບປົກກະຕິທີ່ເຮັດໃຫ້ການຕອບໂຕ້ຊັກຊ້າ ແລະ ເຮັດໃຫ້ຄວາມເສຍຫາຍຂະຫຍາຍຕົວ. ມາດຕະການແກ້ໄຂຄືການເຮັດໃຫ້ "ການກວດພົບ → ການຢຸດ → ການ Rollback" ເປັນແບບອັດຕະໂນມັດ ແລະ ຈຳກັດຈຸດທີ່ມະນຸດຕ້ອງເຂົ້າມາຕັດສິນໃຈໄວ້ລ່ວງໜ້າ.

ການອອກແບບ Trigger ສຳລັບການຢຸດອັດຕະໂນມັດ

ກຳນົດເງື່ອນໄຂຕໍ່ໄປນີ້ໄວ້ລ່ວງໜ້າ ແລະ ສັ່ງຢຸດທັນທີເມື່ອຄ່າເກີນ Threshold:

• ເມື່ອຄະແນນຄວາມຜິດປົກກະຕິ (Anomaly score) ເກີນ Threshold ທີ່ຕັ້ງໄວ້ຕິດຕໍ່ກັນ N ຄັ້ງ
• ເມື່ອການໂທຫາ API ພາຍນອກມຸ່ງໜ້າໄປຍັງ Endpoint ທີ່ບໍ່ໄດ້ຢູ່ໃນລາຍການອະນຸຍາດ (Allowlist)
• ເມື່ອເສັ້ນທາງການປະມວນຜົນຂອງ Task graph ເບ່ຽງເບນໄປຈາກ Path ທີ່ໄດ້ຮັບການອະນຸມັດ

ແນະນຳໃຫ້ໃຊ້ວິທີການຢຸດ 2 ຮູບແບບຄື "Hard stop (ການຢຸດແບບບັງຄັບທັນທີ)" ແລະ "Soft stop (ການຢຸດຮັບ Task ໃໝ່ ແລະ ສືບຕໍ່ Task ທີ່ກຳລັງປະມວນຜົນຢູ່ຈົນເຖິງຈຸດທີ່ປອດໄພ)". Hard stop ເໝາະສຳລັບການປະຕິບັດງານທີ່ມີຄວາມສ່ຽງຕໍ່ຂໍ້ມູນເສຍຫາຍສູງ, ສ່ວນ Soft stop ເໝາະສຳລັບການປະມວນຜົນແບບ Stateless.

ຂັ້ນຕອນການ Rollback

1. ຍ້ອນສະຖານະ Snapshot ຂອງ Agent ກັບຄືນໄປຫາ "Check point ທີ່ຢືນຢັນແລ້ວວ່າປົກກະຕິ" ລ່າສຸດ
2. ອອກ Compensating transaction ສຳລັບ Action ພາຍນອກທີ່ປະຕິບັດໄປແລ້ວ (ການຂຽນຂໍ້ມູນລົງ DB, ການສົ່ງ API, ແລະ ອື່ນໆ)
3. ສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ Agent ຫຼື ລະບົບ Downstream ທີ່ໄດ້ຮັບຜົນກະທົບເພື່ອແຈ້ງການຢຸດເຮັດວຽກ
4. ຫຼັງຈາກ Rollback ສຳເລັດ, ໃຫ້ລະງັບການ Restart ໄວ້ຈົນກວ່າການວິເຄາະຫາສາເຫດຮາກເຫງົ້າ (RCA) ຈະສິ້ນສຸດລົງ

ເງື່ອນໄຂ Gate ກ່ອນການ Restart

ການເປີດໃຊ້ງານຄືນໃໝ່ຈະຕ້ອງຜ່ານການອະນຸມັດຫຼັງຈາກ "ການລະບຸສາເຫດຂອງ Drift → ການແກ້ໄຂ System prompt ຫຼື Guardrail → ການກວດສອບຄືນໃນສະພາບແວດລ້ອມ Staging".

ເຖິງແມ່ນວ່າຈະມີການກຽມ Guardrail ແລະ ແບບຈຳລອງການກຳກັບດູແລໄວ້ແລ້ວ, ແຕ່ສິ່ງເຫຼົ່ານັ້ນກໍຍັງມີຊ່ອງໂຫວ່. ຖ້າມອງຈາກມຸມມອງຂອງຜູ້ໂຈມຕີ, "ຊ່ອງວ່າງ" ຂອງການບໍລິຫານຈັດການ (Governance) ຄືຈຸດທີ່ງ່າຍຕໍ່ການຖືກໂຈມຕີຫຼາຍທີ່ສຸດ.

ດັ່ງນັ້ນ, ສິ່ງທີ່ຈຳເປັນຄືແນວຄິດທີ່ຕ້ອງນຳເອົາຄວາມປອດໄພເຂົ້າໄປເປັນສ່ວນໜຶ່ງຂອງໂຄງສ້າງໂດຍກົງ, ບໍ່ແມ່ນພຽງແຕ່ເປັນທາງເລືອກເສີມທີ່ຢູ່ພາຍນອກຂອງ Framework. ໂດຍສະເພາະ, ຕ້ອງມີການປະເມີນຄວາມສ່ຽງຢ່າງຕໍ່ເນື່ອງໂດຍໃຫ້ສອດຄ່ອງກັບ AI TRiSM ແລະ ການສ້າງລະບົບທີ່ສາມາດເບິ່ງເຫັນ ແລະ ຕິດຕາມອົງປະກອບຂອງ Agent ໄດ້ຜ່ານ AI-BOM ເພື່ອບໍ່ໃຫ້ພາດການປ່ຽນແປງ ຫຼື ການປ່ຽນແປງຂອງຄວາມສຳພັນທີ່ເພິ່ງພາອາໄສກັນ. ນອກຈາກນີ້, ຄວນມີການເຮັດ Red Teaming ເປັນປະຈຳ ເພື່ອຊອກຫາພຶດຕິກຳທີ່ບໍ່ຄາດຄິດ ຫຼື ເສັ້ນທາງທີ່ມີຄວາມສ່ຽງໄວ້ລ່ວງໜ້າ.

ສິ່ງເຫຼົ່ານີ້ບໍ່ແມ່ນມາດຕະການທີ່ແຍກອອກຈາກກັນ, ແຕ່ຕ້ອງເຮັດວຽກຮ່ວມກັນເປັນໂຄງສ້າງຫຼາຍຊັ້ນທີ່ເສີມເຊິ່ງກັນແລະກັນ ຈຶ່ງຈະສາມາດຮັບປະກັນຄວາມໜ້າເຊື່ອຖືຂອງ Agent ໃນລະດັບການນຳໃຊ້ງານຈິງໄດ້.

ຫຼາຍຄົນມັກຄິດວ່າການເພີ່ມມາດຕະການຄວາມປອດໄພໃນພາຍຫຼັງນັ້ນພຽງພໍແລ້ວ, ແຕ່ໃນສະພາບແວດລ້ອມຂອງ AI agent, ການນຳໃຊ້ແນວທາງ AI TRiSM (ການບໍລິຫານຈັດການຄວາມເຊື່ອໝັ້ນ, ຄວາມສ່ຽງ ແລະ ຄວາມປອດໄພຂອງ AI) ເຊິ່ງເປັນການລວມເອົາຄວາມເຊື່ອໝັ້ນ, ຄວາມສ່ຽງ ແລະ ຄວາມປອດໄພເຂົ້າໃນຂັ້ນຕອນການອອກແບບນັ້ນ ຖືວ່າມີປະສິດທິຜົນຢ່າງແທ້ຈິງ.

AI TRiSM ຈະບໍລິຫານຈັດການຄວາມສ່ຽງຂອງ agent ຢ່າງເປັນລະບົບໂດຍຜ່ານ 4 ແກນຫຼັກ ດັ່ງນີ້:

• Trust (ຄວາມເຊື່ອໝັ້ນ): ເຮັດໃຫ້ເຫດຜົນໃນການຕັດສິນໃຈຂອງ agent ສາມາດເບິ່ງເຫັນໄດ້ດ້ວຍ AI Explainability (XAI) ເພື່ອຮັບປະກັນຄວາມຮັບຜິດຊອບຕໍ່ຜູ້ມີສ່ວນກ່ຽວຂ້ອງ
• Risk (ຄວາມສ່ຽງ): ປະເມີນຄວາມສ່ຽງຢ່າງຕໍ່ເນື່ອງ ເຊັ່ນ: ການມີສິດອຳນາດຂອງ agent ຫຼາຍເກີນໄປ (Excessive Agency) ຫຼື ບັນຫາຕົວແທນທີ່ສັບສົນ (Confused Deputy Problem)
• Security (ຄວາມປອດໄພ): ຝັງມາດຕະການປ້ອງກັນການເຮັດ Prompt Injection ແລະ Memory Poisoning ເຂົ້າໄປໃນວົງຈອນການດຳເນີນງານ
• Management (ການບໍລິຫານຈັດການ): ຮັກສາກົນໄກການປະເມີນຄວາມສ່ຽງຄືນໃໝ່ທຸກຄັ້ງທີ່ມີການປ່ຽນແປງນະໂຍບາຍ ຫຼື ການອັບເດດໂມເດວ

ເພື່ອໃຫ້ວົງຈອນການບໍລິຫານຈັດການນີ້ສາມາດເຮັດວຽກໄດ້, ການຈັດຕຽມ AI Bill of Materials (AI-BOM) ຈຶ່ງເປັນສິ່ງທີ່ຂາດບໍ່ໄດ້. ໂດຍ AI-BOM ຈະບັນທຶກຂໍ້ມູນດັ່ງຕໍ່ໄປນີ້:

ກອບວຽກດ້ານການກຳກັບດູແລ (Governance Framework) ບໍ່ພຽງແຕ່ຕ້ອງການ "ຄວາມຖືກຕ້ອງໃນຂະນະອອກແບບ" ເທົ່ານັ້ນ ແຕ່ຈະມີປະສິດທິຜົນກໍຕໍ່ເມື່ອໄດ້ຜ່ານການກວດສອບຄວາມທົນທານໃນສະຖານະການໂຈມຕີຕົວຈິງເທົ່ານັ້ນ. AI Red Teaming ແມ່ນວິທີການກວດສອບພາກປະຕິບັດທີ່ໃຊ້ທັດສະນະແບບເປັນສັດຕູເພື່ອທຳລາຍພຶດຕິກຳຂອງ Agent ໂດຍເຈດຕະນາ ເພື່ອກວດຫາຊ່ອງໂຫວ່ໃນການຍົກລະດັບສິດທິ (Privilege Escalation) ທີ່ບໍ່ໄດ້ຄາດຄິດ ຫຼື ການເຮັດ Prompt Injection.

ລາຍການກວດສອບຫຼັກມີດັ່ງນີ້:

• Direct/Indirect Injection: ກວດສອບວ່າສາມາດຂຽນ System Prompt ທັບຜ່ານແຫຼ່ງຂໍ້ມູນພາຍນອກໄດ້ຫຼືບໍ່
• Excessive Agency: ທົດສອບວ່າສາມາດຫຼີກລ່ຽງຈຸດຄວບຄຸມຂອງ Task Graph ເພື່ອເອີ້ນໃຊ້ External API ທີ່ບໍ່ໄດ້ຕັ້ງໃຈໄດ້ຫຼືບໍ່
• Memory Poisoning: ສັກຂໍ້ມູນທີ່ຜິດພາດເຂົ້າໄປໃນໜ່ວຍຄວາມຈຳໄລຍະຍາວຂອງ Agent ແລະວັດແທກຜົນກະທົບຕໍ່ວຽກງານທີ່ຕາມມາ
• Confused Deputy Problem: ທົດລອງຍົກລະດັບສິດທິໂດຍການໃຊ້ປະໂຫຍດຈາກ Flow ການມອບໝາຍວຽກໃຫ້ Agent ອື່ນ

ການເລືອກຄວາມເລິກໃນການກວດສອບໃຫ້ເໝາະສົມກັບລະດັບຄວາມພ້ອມຂອງອົງກອນແມ່ນມີປະສິດທິຜົນ. ໃນຂັ້ນຕອນທີ່ທີມງານພາຍໃນຍັງບໍ່ທັນມີການຈັດຕັ້ງ Red Teaming ທີ່ພ້ອມ, ການເລີ່ມຕົ້ນຈາກ Boundary Testing ຕາມມາດຕະຖານ OWASP LLM Top 10 ແລະ ນຳໃຊ້ໂຄງການ Bug Bounty ຈາກພາຍນອກຮ່ວມດ້ວຍເມື່ອລະບົບມີຄວາມພ້ອມແລ້ວ ຖືເປັນວິທີການທີ່ເປັນຈິງທີ່ສຸດ.