ການຄຸ້ມຄອງ AI Agent (AIエージェントのガバナンス) ແມ່ນຄວາມພະຍາຍາມໃນການຄວບຄຸມການກະທຳຂອງ AI Agent ທີ່ວາງແຜນ ແລະ ປະຕິບັດໜ້າທີ່ຢ່າງອິດສະຫຼະ ໂດຍຜ່ານກົນໄກການຈັດການສິດທິ, Guardrails ແລະ ການກວດສອບຢ່າງເປັນລະບົບ. ແຕກຕ່າງຈາກ AI ແບບ Chat, Agent ສາມາດຈັດການກັບລະບົບພາຍນອກ ຫຼື ຂໍ້ມູນໄດ້ໂດຍກົງ, ດັ່ງນັ້ນການເຮັດວຽກຜິດພາດອາດສົ່ງຜົນໂດຍກົງຕໍ່ການທຳລາຍຂໍ້ມູນທາງທຸລະກິດ ຫຼື ເກີດຄວາມຜິດພາດທີ່ສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ກັນເປັນທອດໆ. ໃນບົດຄວາມນີ້, ສຳລັບພະແນກລະບົບຂໍ້ມູນຂ່າວສານ ແລະ ຜູ້ຮັບຜິດຊອບດ້ານການສົ່ງເສີມ AI ທີ່ຮັບຜິດຊອບການນຳໃຊ້ ແລະ ການດຳເນີນງານຂອງ AI Agent, ພວກເຮົາຈະອະທິບາຍເຖິງກອບການເຮັດວຽກຕົວຈິງເພື່ອຄວບຄຸມຄວາມສ່ຽງໃນການປະຕິບັດງານແບບອິດສະຫຼະຢ່າງເປັນຂັ້ນຕອນ, ເລີ່ມຕັ້ງແຕ່ການກຳນົດຂອບເຂດສິດທິ, ການອອກແບບ Guardrails, ບັນທຶກການກວດສອບ (Audit log), ຈົນເຖິງການຂະຫຍາຍໄປສູ່ສະພາບແວດລ້ອມແບບ Multi-agent. ເມື່ອອ່ານຈົບ, ທ່ານຈະມີຂໍ້ມູນທີ່ຈຳເປັນໃນການຕັດສິນໃຈວ່າ "ຄວນກຽມຫຍັງ ແລະ ຕາມລຳດັບໃດ" ສຳລັບແຜນການນຳໃຊ້ Agent ຂອງບໍລິສັດທ່ານ.

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

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

ຄວາມສ່ຽງທີ່ເປັນຕົວແທນສາມາດຈັດກຸ່ມໄດ້ 4 ປະເພດດັ່ງນີ້:

• ການບ່ຽງເບນຈາກເຈດຕະນາ (Intent Deviation): ການຕີຄວາມໝາຍເກີນຂອບເຂດຈາກຄຳສັ່ງທີ່ບໍ່ຊັດເຈນ. ກໍລະນີຕົວຢ່າງຄື ການຕີຄວາມຄຳສັ່ງ "ຈັດການຂໍ້ມູນເກົ່າ" ວ່າເປັນການລຶບຖິ້ມ ແທນທີ່ຈະເປັນການເກັບຮັກສາ (Archive).
• ການໃຊ້ສິດທິເກີນຂອບເຂດ (Excessive Agency): Agent ທີ່ມີສິດທິເກີນຄວາມຈຳເປັນສຳລັບວຽກງານນັ້ນໆ ໄດ້ເຂົ້າໄປປ່ຽນແປງຊັບພະຍາກອນທີ່ບໍ່ຄວນຈະເຂົ້າເຖິງ. ໃນລາຍການຄວາມສ່ຽງດ້ານຄວາມປອດໄພສຳລັບແອັບພລິເຄຊັນ LLM ຂອງ OWASP, ຫົວຂໍ້ນີ້ໄດ້ຖືກລະບຸໄວ້ເປັນຫົວຂໍ້ສະເພາະໃນນາມ "Excessive Agency".
• ການຖືກຍຶດຄອງຜ່ານ Prompt Injection: ການທີ່ Agent ຖືກສັ່ງໃຫ້ປະຕິບັດງານຕາມເຈດຕະນາຂອງຜູ້ໂຈມຕີ ໂດຍຜ່ານຄຳສັ່ງທີ່ຝັງຢູ່ໃນເນື້ອຫາພາຍນອກ (ອີເມວ, ໜ້າເວັບ, ເອກະສານ) ທີ່ Agent ໄດ້ອ່ານ.
• ຄວາມຜິດພາດແບບລູກໂສ້ (Cascading Failure): ການປະຕິບັດງານທີ່ຜິດພາດພຽງຄັ້ງດຽວ ໄປກະຕຸ້ນຂະບວນການອັດຕະໂນມັດໃນຂັ້ນຕໍ່ໄປ ຈົນເຮັດໃຫ້ຄວາມເສຍຫາຍຂະຫຍາຍຕົວ. ຕົວຢ່າງເຊັ່ນ: ການອັບເດດຂໍ້ມູນສິນຄ້າຄົງຄັງທີ່ຜິດພາດ ສົ່ງຜົນຕໍ່ເນື່ອງໄປເຖິງຂະບວນການສັ່ງຊື້ ແລະ ການອອກບິນອັດຕະໂນມັດ.

ທັງໝົດນີ້ບໍ່ແມ່ນບັນຫາເລື່ອງ "ຄຸນນະພາບຂອງຜົນລັພ" ແຕ່ເປັນບັນຫາເລື່ອງ "ຄວາມປອດໄພຂອງການກະທຳ" ເຊິ່ງການເພີ່ມຄວາມແມ່ນຍຳຂອງ Model ພຽງຢ່າງດຽວບໍ່ສາມາດແກ້ໄຂໄດ້.

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

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

ໃນດ້ານກົດລະບຽບ, ຄວາມຕ້ອງການສຳລັບ AI ທີ່ເຮັດວຽກແບບອັດຕະໂນມັດກຳລັງເພີ່ມທະວີຂຶ້ນເລື້ອຍໆຢ່າງຊັດເຈນ.

EU AI Act ໄດ້ນຳໃຊ້ວິທີການທີ່ອີງໃສ່ຄວາມສ່ຽງ ແລະ ບັງຄັບໃຫ້ລະບົບ AI ທີ່ຖືກຈັດປະເພດວ່າມີຄວາມສ່ຽງສູງ ຕ້ອງມີການບັນທຶກ Log, ການກຳກັບດູແລໂດຍມະນຸດ ແລະ ການສ້າງລະບົບການຈັດການຄວາມສ່ຽງ. ໃນກໍລະນີທີ່ Agent ມີສ່ວນກ່ຽວຂ້ອງກັບການປະເມີນຜົນພະນັກງານ, ການຕັດສິນໃຈດ້ານສິນເຊື່ອ, ຫຼື ການຄວບຄຸມ ໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ທີ່ສຳຄັນ, ລະບົບເຫຼົ່ານັ້ນອາດຈະຕົກຢູ່ພາຍໃຕ້ພັນທະເຫຼົ່ານີ້. AI Risk Management Framework (AI RMF) ຂອງ NIST ປະເທດສະຫະລັດອາເມຣິກາ ກໍໄດ້ກຳນົດໃຫ້ Govern (ການປົກຄອງ) ເປັນ ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ແລະ ຮຽກຮ້ອງໃຫ້ມີລະບົບການຈັດການດ້ານອົງກອນຕໍ່ກັບການກະທຳຂອງ AI. ໃນປະເທດຍີ່ປຸ່ນເອງ, ແນວທາງປະຕິບັດສຳລັບຜູ້ປະກອບການ AI ຂອງລັດຖະບານ ກໍໄດ້ຍົກເອົາການຮັບປະກັນຄວາມປອດໄພຂອງ AI ແລະ ການກຳກັບດູແລໂດຍມະນຸດເປັນຫຼັກການພື້ນຖານ.

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

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

ສິ່ງທີ່ຄວນເຮັດເປັນອັນດັບທຳອິດຄື ການກວດສອບການດຳເນີນງານຂອງ Agent ແລະ ການກຳນົດສິດໃຫ້ໜ້ອຍທີ່ສຸດ. ຫຼັກການພື້ນຖານແມ່ນ ຫຼັກການສິດທິຂັ້ນຕ່ຳ (Principle of Least Privilege) ເຊິ່ງເປັນຫຼັກການຄລາສສິກດ້ານຄວາມປອດໄພ ໂດຍມີໃຈຄວາມສຳຄັນຄື "ການໃຫ້ສິດທິພຽງເທົ່າທີ່ຈຳເປັນສຳລັບການປະຕິບັດວຽກງານເທົ່ານັ້ນ".

ການດຳເນີນງານສາມາດຈັດກຸ່ມໄດ້ງ່າຍຂຶ້ນໂດຍແບ່ງອອກເປັນ 4 ຂັ້ນຕອນດັ່ງນີ້:

1. ການອ່ານ (Read): ເບິ່ງຂໍ້ມູນໄດ້ພຽງຢ່າງດຽວ. ຜົນກະທົບຈະຈຳກັດຢູ່ທີ່ຄວາມສ່ຽງດ້ານຂໍ້ມູນຮົ່ວໄຫຼເທົ່ານັ້ນ.
2. ການຂຽນ/ອັບເດດ (Write/Update): ການປ່ຽນແປງຂໍ້ມູນທີ່ມີຢູ່ແລ້ວ. ຫາກເກີດການປະຕິບັດງານຜິດພາດ ຈະຕ້ອງມີການກູ້ຄືນຂໍ້ມູນ.
3. ການລຶບ (Delete): ໃນຫຼາຍກໍລະນີບໍ່ສາມາດກູ້ຄືນໄດ້. ໂດຍຫຼັກການແລ້ວ ຈະບໍ່ມອບສິດນີ້ໃຫ້ແກ່ Agent.
4. ການສົ່ງຂໍ້ມູນອອກພາຍນອກ (External Transmission): ເຊັ່ນ: ການສົ່ງອີເມວ, ການຮຽກໃຊ້ API ພາຍນອກ, ຫຼື ການຊຳລະເງິນ. ເນື່ອງຈາກສົ່ງຜົນກະທົບອອກໄປນອກອົງກອນ ຈຶ່ງຕ້ອງຈັດການດ້ວຍຄວາມລະມັດລະວັງທີ່ສຸດ.

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

ໃນດ້ານການປະຕິບັດງານ, ສິ່ງສຳຄັນຄືການອອກ Service Account ສະເພາະສຳລັບ Agent ແລະ ບໍ່ຄວນນຳ ID ຂອງມະນຸດມາໃຊ້ຊ້ຳ. Agent ທີ່ເຮັດວຽກໂດຍໃຊ້ຂໍ້ມູນການຢືນຢັນຕົວຕົນດຽວກັນກັບມະນຸດ ຈະບໍ່ສາມາດແຍກອອກຈາກການດຳເນີນງານຂອງມະນຸດໄດ້ໃນ Log ເຮັດໃຫ້ການກວດສອບ (Audit) ແລະ ການສືບສວນເຫດການຜິດປົກກະຕິ (Incident Investigation) ບໍ່ສາມາດດຳເນີນການໄດ້.

ການນຳໃຊ້ການຄວບຄຸມດຽວກັນກັບທຸກການປະຕິບັດງານຈະເຮັດໃຫ້ການດຳເນີນງານລົ້ມເຫຼວ. ຕາຕະລາງປະເມີນຄວາມສ່ຽງ (Risk Assessment Matrix) ແມ່ນເຄື່ອງມືທີ່ໃຊ້ໃນການປະເມີນຄວາມສ່ຽງຂອງແຕ່ລະການປະຕິບັດງານ ແລະ ປັບປ່ຽນຄວາມເຂັ້ມງວດຂອງການຄວບຄຸມ. ຂໍແນະນຳໃຫ້ໃຊ້ 2 ແກນໃນການປະເມີນ ຄື: "ລະດັບຜົນກະທົບ" ແລະ "ຄວາມສາມາດໃນການກູ້ຄືນ (Reversibility)".

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

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

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

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

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

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

ພື້ນຖານຂອງ Guardrail ແມ່ນການວາງຊ້ອນກັນ 3 ຊັ້ນ ຄື: "ການປ້ອນຂໍ້ມູນ (Input)", "ການປະມວນຜົນ (Execution)" ແລະ "ການສະແດງຜົນ (Output)". ການປ້ອງກັນພຽງຊັ້ນດຽວ ຈະຖືກເຈາະຜ່ານດ້ວຍເສັ້ນທາງທີ່ບໍ່ຄາດຄິດໃນທີ່ສຸດ. ຕໍ່ໄປນີ້ຈະອະທິບາຍເຖິງຮູບແບບການຈັດຕັ້ງປະຕິບັດໃນແຕ່ລະຊັ້ນ ແລະ ແນວຄິດການແບ່ງລະດັບຄວາມເຂັ້ມງວດໃນການຄວບຄຸມ.

ການກັ່ນກອງຂໍ້ມູນຂາເຂົ້າທີ່ຕ້ອງໃຫ້ຄວາມສຳຄັນເປັນອັນດັບໜຶ່ງ ຄື ການເຮັດໃຫ້ເນື້ອຫາຈາກພາຍນອກທີ່ເອເຈນ (Agent) ດຶງເຂົ້າມາປອດໄພ. ອີເມວ, ໜ້າເວັບ ແລະ ໄຟລ໌ແນບ ອາດມີຂໍ້ຄວາມທີ່ປອມແປງເປັນຄຳສັ່ງສຳລັບເອເຈນ (Prompt Injection) ປົນຢູ່. ດັ່ງນັ້ນ, ຂໍ້ຄວາມທັງໝົດທີ່ມາຈາກພາຍນອກຕ້ອງຖືກຈັດເປັນ "ຂໍ້ມູນທີ່ບໍ່ໜ້າເຊື່ອຖື" ແລະ ຕ້ອງອອກແບບໃຫ້ແຍກອອກຈາກຄຳສັ່ງຂອງລະບົບຢ່າງຊັດເຈນໃນເວລາສົ່ງຂໍ້ມູນຕໍ່ໃຫ້. ນອກຈາກນີ້, ຄວນໃຊ້ການກວດສອບເບື້ອງຕົ້ນດ້ວຍຮູບແບບການກວດຫາ Injection ຄວບຄູ່ກັນໄປ.

ໃນຂັ້ນຕອນການປະຕິບັດງານ, ການກວດສອບອາກິວເມັນ (Argument) ຂອງການຮຽກໃຊ້ເຄື່ອງມື ແມ່ນຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ. ຢ່າປະຕິບັດຕາມອາກິວເມັນຂອງ API ທີ່ LLM ສ້າງຂຶ້ນໂດຍກົງ, ແຕ່ໃຫ້ຜ່ານການກວດສອບສະຄີມາ (ປະເພດ, ຂອບເຂດ, ຮູບແບບ) ແລະ ການກວດສອບກັບລາຍການທີ່ອະນຸຍາດ (Allowlist). ພຽງແຕ່ປ່ຽນຈາກ "ການສ້າງ ແລະ ປະຕິບັດ SQL ຢ່າງອິດສະຫຼະ" ມາເປັນ "ການຕື່ມຂໍ້ມູນສະເພາະພາຣາມິເຕີໃນ Query ທີ່ກຳນົດໄວ້ແລ້ວ" ກໍຈະຊ່ວຍຫຼຸດຜ່ອນຄວາມສ່ຽງລົງໄດ້ຢ່າງຫຼວງຫຼາຍ.

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

ガードレールには、破られないハードリミットと、原則として守られるが破られうるソフトリミットがある。この区別を意識しないと、「プロンプトに禁止と書いたから安全」という危険な思い込みが生まれる。

使い分けの原則は明快で、重大・不可逆なリスクは必ずハードリミットで止める。プロンプトでの指示はあくまで補助であり、プロンプトインジェクションや解釈ミスで破られる前提に立つ。

一方、文体・優先順位・判断基準のような「望ましい振る舞い」の制御はソフトリミットが適している。すべてをハードリミットにすると変更コストが膨らむため、リスク評価マトリクスの象限に応じて両者を組み合わせるのが現実解だ。

Human-in-the-loop (HITL) ແມ່ນການຈັດຕັ້ງປະຕິບັດທີ່ສອດຄ່ອງກັບ Quadrant ຂອງ "ການອະນຸມັດລ່ວງໜ້າ" ໃນຕາຕະລາງການປະເມີນຄວາມສ່ຽງ. ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ຂອງການອອກແບບແມ່ນການກຳນົດວ່າຈະວາງການອະນຸມັດໄວ້ ບ່ອນໃດ ແລະ ຫຼາຍໜ້ອຍພຽງໃດ.

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

ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ໃນການອອກແບບເພື່ອປ້ອງກັນບໍ່ໃຫ້ການອະນຸມັດກາຍເປັນພຽງຮູບແບບມີ 3 ຢ່າງດັ່ງນີ້:

1. ຈຳກັດຂອບເຂດການອະນຸມັດ: ຈຳກັດສະເພາະການດຳເນີນການທີ່ບໍ່ສາມາດຍົກເລີກໄດ້ ຫຼື ມີຜົນກະທົບສູງເທົ່ານັ້ນ, ສ່ວນລາຍການອື່ນໃຫ້ປ່ຽນໄປເປັນການກວດສອບພາຍຫຼັງ (Post-review).
2. ລວມຂໍ້ມູນທີ່ຈຳເປັນສຳລັບການອະນຸມັດໄວ້ໃນໜ້າຈໍດຽວ: ນຳສະເໜີຂໍ້ມູນວ່າກຳລັງຈະເຮັດຫຍັງ, ເປັນຫຍັງຕ້ອງເຮັດ ແລະ ເຮັດກັບຂໍ້ມູນໃດ ໃນຮູບແບບທີ່ສາມາດຕັດສິນໃຈໄດ້ທັນທີໂດຍບໍ່ຕ້ອງໄປຄົ້ນຫາເພີ່ມ.
3. ກຳນົດໃຫ້ການໝົດເວລາ (Timeout) ເປັນການປະຕິເສດໂດຍຄ່າເລີ່ມຕົ້ນ: ຫຼີກເວັ້ນການອອກແບບທີ່ "ອະນຸມັດໂດຍອັດຕະໂນມັດ" ເມື່ອບໍ່ມີການຕອບສະໜອງຢ່າງເດັດຂາດ. ຕາມຫຼັກການ Fail-safe, ຖ້າບໍ່ມີການຕອບຮັບ ຕ້ອງຕັ້ງຄ່າໃຫ້ລະບົບຢຸດການເຮັດວຽກໄວ້.

ນອກຈາກນີ້, ການກຳນົດເສັ້ນທາງການສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ (Escalation path) ໃນກໍລະນີທີ່ຜູ້ອະນຸມັດບໍ່ຢູ່ ຫຼື ບໍ່ສາມາດຕັດສິນໃຈໄດ້ ຈະຊ່ວຍໃຫ້ການດຳເນີນງານບໍ່ຢຸດສະງັກ.

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

ບັນທຶກການກວດສອບ (Audit log) ຂອງ Agent ແຕກຕ່າງຈາກບັນທຶກຂອງແອັບພລິເຄຊັນທົ່ວໄປ ເນື່ອງຈາກຈຳເປັນຕ້ອງບັນທຶກເຖິງ "ຂະບວນການຕັດສິນໃຈ" ດ້ວຍ. ຢ່າງໜ້ອຍຄວນມີເຫດການຕໍ່ໄປນີ້:

• ການຮັບຄຳສັ່ງ: ໃຜເປັນຜູ້ໃຫ້ຄຳສັ່ງ (Prompt) ແລະ ຄຳສັ່ງນັ້ນແມ່ນຫຍັງ
• ການສ້າງແຜນການ: Agent ໄດ້ວາງແຜນຂັ້ນຕອນໄວ້ແນວໃດ
• ການຮຽກໃຊ້ເຄື່ອງມື: API ທີ່ຖືກຮຽກໃຊ້, ອາຄິວເມັນ (Arguments) ແລະ ຊັບພະຍາກອນທີ່ກ່ຽວຂ້ອງ
• ຜົນການປະຕິບັດງານ: ສຳເລັດ/ລົ້ມເຫຼວ, ຄ່າກ່ອນ ແລະ ຫຼັງການປ່ຽນແປງ (ສ່ວນຕ່າງ)
• ການອະນຸມັດ/ປະຕິເສດ: ການຕັດສິນໃຈຂອງມະນຸດໃນ HITL ແລະ ຜູ້ຕັດສິນໃຈ
• ການເຮັດວຽກຂອງ Guardrail: ຂໍ້ເທັດຈິງ ແລະ ເຫດຜົນທີ່ລະບົບ Block ຫຼື Filter ເຮັດວຽກ

ລາຍການທີ່ຈຳເປັນສຳລັບແຕ່ລະ Record ປະກອບມີ: Timestamp, Agent ID, Session ID (ຕົວລະບຸທີ່ໃຊ້ໃນການຕິດຕາມວຽກງານທັງໝົດ), ຊັບພະຍາກອນທີ່ກ່ຽວຂ້ອງ ແລະ ປະເພດຂອງການປະຕິບັດງານ. ຖ້າບໍ່ມີ Session ID, ຈະບໍ່ສາມາດຕິດຕາມໄດ້ວ່າ "ການລຶບຂໍ້ມູນນີ້ເປັນສ່ວນໜຶ່ງຂອງຕ່ອງໂສ້ທີ່ເລີ່ມຕົ້ນມາຈາກຄຳສັ່ງໃດ" ເຊິ່ງຈະເຮັດໃຫ້ການສືບຫາສາເຫດປະສົບກັບຄວາມຫຍຸ້ງຍາກ.

ຂໍ້ຄວນລະວັງຄື: ໃນກໍລະນີທີ່ບັນທຶກເນື້ອຫາການປ້ອນຂໍ້ມູນ ແລະ ການສະແດງຜົນທັງໝົດຂອງ LLM, ຂໍ້ມູນສ່ວນບຸກຄົນ ຫຼື ຂໍ້ມູນລັບອາດຈະປົນຢູ່ໃນບັນທຶກໄດ້. ຖ້າບໍ່ມີການອອກແບບການປິດບັງຂໍ້ມູນ (Masking) ໃນຕົວບັນທຶກເອງ ຄວບຄູ່ໄປກັບການຄວບຄຸມການເຂົ້າເຖິງ (Access Control) ທີ່ຈະກ່າວເຖິງໃນພາຍຫຼັງ, ພື້ນຖານໂຄງສ້າງ ຫຼື Infrastructure ຂອງບັນທຶກອາດກາຍເປັນຈຸດສ່ຽງໃໝ່ຂອງການຮົ່ວໄຫຼຂອງຂໍ້ມູນ.

ການເກັບບັນທຶກ (Log) ພຽງຢ່າງດຽວບໍ່ມີຄວາມໝາຍ, ມັນຈະເຮັດໜ້າທີ່ເປັນຮາວປ້ອງກັນ (Guardrail) ໄດ້ກໍຕໍ່ເມື່ອມີການກວດຫາຄວາມຜິດປົກກະຕິແບບ Real-time ເທົ່ານັ້ນ. ພື້ນຖານຂອງການກວດຫາແມ່ນ ການບ່ຽງເບນຈາກເສັ້ນຖານ (Baseline).

ຕົວຊີ້ວັດທີ່ມີປະສິດທິພາບສຳລັບການຕິດຕາມກວດກາມີດັ່ງນີ້:

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

ສຳລັບຄ່າຂີດຈຳກັດ (Threshold), ບໍ່ຄວນຕັ້ງເປົ້າໝາຍຫາຄ່າທີ່ຖືກຕ້ອງຕັ້ງແຕ່ຕົ້ນ ແຕ່ໃຫ້ໃຊ້ຄ່າທີ່ວັດແທກໄດ້ຈິງຫຼັງຈາກການນຳໃຊ້ເປັນເສັ້ນຖານ ແລະ ປັບປ່ຽນໄປຕາມຂັ້ນຕອນ. ການຕອບສະໜອງກໍຄວນແບ່ງເປັນຂັ້ນຕອນເຊັ່ນກັນ ໂດຍກຽມໄວ້ 3 ລະດັບຄື: "ແຈ້ງເຕືອນເທົ່ານັ້ນ → ຢຸດການເຮັດວຽກຂອງ Agent ຊົ່ວຄາວໂດຍອັດຕະໂນມັດ → ຢຸດການເຮັດວຽກຂອງ Agent ທັງໝົດສຸກເສີນ (Kill Switch)". ໂດຍສະເພາະ Kill Switch, ເພື່ອຫຼີກເວັ້ນສະຖານະການທີ່ບໍ່ມີໃຜຮູ້ວ່າ "ຈະຢຸດການເຮັດວຽກແນວໃດ" ເມື່ອເກີດເຫດການຂຶ້ນ, ຄວນຈັດກຽມຂັ້ນຕອນການຢຸດການເຮັດວຽກເປັນເອກະສານ ແລະ ຝຶກຊ້ອມໄປພ້ອມກັນ.

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

ຄວາມທົນທານຕໍ່ການປອມແປງ (Tamper resistance) ຂອງບັນທຶກຂໍ້ມູນ ກໍເປັນຂໍ້ກຳນົດທີ່ສຳຄັນໃນການກວດສອບ. ໂຄງສ້າງທີ່ຕົວ Agent ເອງ ຫຼື ຜູ້ດຳເນີນງານສາມາດແກ້ໄຂບັນທຶກຂໍ້ມູນໄດ້ນັ້ນ ຈະບໍ່ສາມາດໃຊ້ເປັນຫຼັກຖານໄດ້. ດັ່ງນັ້ນ, ຄວນນຳໃຊ້ກົນໄກທີ່ສາມາດກວດພົບການແກ້ໄຂຂໍ້ມູນໄດ້ ເຊັ່ນ: ການນຳໃຊ້ບ່ອນຈັດເກັບຂໍ້ມູນທີ່ອະນຸຍາດໃຫ້ພຽງແຕ່ເພີ່ມຂໍ້ມູນໃໝ່ (Append-only storage), ການລົງລາຍເຊັນດິຈິຕອນໃນບັນທຶກ, ຫຼື ການກວດສອບຄວາມສົມບູນຂອງຂໍ້ມູນດ້ວຍ Hash chain.

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

ເມື່ອເອເຈນຫຼາຍຕົວເຮັດວຽກຮ່ວມກັນ, ຄວາມສ່ຽງຈະບໍ່ໄດ້ເພີ່ມຂຶ້ນແບບບວກ ແຕ່ຈະເພີ່ມທະວີຂຶ້ນເລື້ອຍໆແບບຄູນ. ນອກຈາກການວາງລະບົບປ້ອງກັນ (Guardrails) ສຳລັບເອເຈນແຕ່ລະຕົວແລ້ວ, ຍັງຈຳເປັນຕ້ອງມີການຄວບຄຸມ "ລະຫວ່າງ" ເອເຈນນຳອີກ. ໂດຍມີ Trust Model ແລະ Rollback ເປັນຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ໃນການອອກແບບ.

ຫຼັກການຂອງສະພາບແວດລ້ອມແບບ Multi-agent ກໍຄື Zero Trust ເຊັ່ນດຽວກັບລະບົບຂອງມະນຸດ ເຮົາຈະບໍ່ຕັ້ງສົມມຸດຕິຖານວ່າ "ເພາະເປັນ Agent ພາຍໃນບໍລິສັດຄືກັນ ຈຶ່ງສາມາດເຊື່ອຖືໄດ້".

ໂດຍສະເພາະແລ້ວ ຈະຕ້ອງມີການຈັດຕັ້ງປະຕິບັດ 3 ຂໍ້ດັ່ງນີ້:

1. ການຢືນຢັນຕົວຕົນເຊິ່ງກັນແລະກັນ (Mutual Authentication): ແມ່ນແຕ່ໃນການສື່ສານລະຫວ່າງ Agent ກໍຕ້ອງມີການຢືນຢັນຕົວຕົນຂອງຜູ້ຮ້ອງຂໍ ເພື່ອປ້ອງກັນການປອມແປງ.
2. ການກຳນົດສິດແບບຕັດກັນ (Intersection of Permissions): ເມື່ອ Agent A ຮ້ອງຂໍໃຫ້ Agent B ເຮັດວຽກ, ສິດທີ່ B ສາມາດນຳໃຊ້ໄດ້ຈະຖືກຈຳກັດໄວ້ຢູ່ທີ່ "ສ່ວນທີ່ຊ້ອນກັນລະຫວ່າງສິດຂອງ A ແລະ ສິດຂອງ B". ຖ້າປ່ອຍໃຫ້ມີການອອກແບບທີ່ເຮັດໃຫ້ສິດຂະຫຍາຍຕົວຜ່ານການຮ້ອງຂໍ (Privilege Escalation), ເມື່ອ Agent ທີ່ອ່ອນແອທີ່ສຸດຖືກບຸກລຸກ ກໍຈະເຮັດໃຫ້ສິດທັງໝົດຖືກເປີດເຜີຍ.
3. ການກວດສອບຜົນລັອກຄືນໃໝ່ (Re-validation of Output): Agent ອື່ນຈະບໍ່ນຳເອົາຜົນລັອກຂອງ Agent ໜຶ່ງມາປະຕິບັດຕາມຄຳສັ່ງໂດຍບໍ່ມີການກວດສອບ.

ຂໍ້ທີ 3 ນີ້ມັກຈະຖືກມອງຂ້າມໄດ້ງ່າຍ. ຕົວຢ່າງເຊັ່ນ: Agent A ອ່ານໜ້າເວັບໄຊພາຍນອກ ແລ້ວນຳເນື້ອຫານັ້ນມາຮ້ອງຂໍໃຫ້ Agent B ເຮັດວຽກ—ໃນເສັ້ນທາງນີ້, ການໂຈມຕີແບບ Injection ທີ່ຝັງຢູ່ໃນໜ້າເວັບຈະຖືກສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ B ຜ່ານທາງ A. ນີ້ຄື ການເຊື່ອມໂຍງຂອງການໂຈມຕີແບບ Indirect Prompt Injection; ເຖິງແມ່ນວ່າຈະເປັນຂອບເຂດລະຫວ່າງ Agent ກໍຕາມ, ຫ້າມລະເລີຍການເຮັດ Sanitization ຂໍ້ມູນຈາກພາຍນອກ ແລະ ການກວດສອບ Arguments ຢ່າງເດັດຂາດ.

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

ຮູບແບບການອອກແບບ (Design Pattern) ສາມາດນຳໃຊ້ຄວາມຮູ້ກ່ຽວກັບລະບົບກະຈາຍ (Distributed Systems) ມາປັບໃຊ້ໄດ້ໂດຍກົງ.

• ການປະມວນຜົນຊົດເຊີຍ (Saga Pattern): ກຳນົດ "ການປະຕິບັດງານຍົກເລີກ" ໃຫ້ເປັນຄູ່ກັບແຕ່ລະຂັ້ນຕອນ, ເມື່ອເກີດຄວາມຜິດພາດໃຫ້ຍົກເລີກຂັ້ນຕອນທີ່ສຳເລັດໄປແລ້ວໃນລຳດັບປີ້ນກັບ.
• Dry Run: ທົດລອງຜ່ານທຸກຂັ້ນຕອນໃນໂໝດທົດສອບກ່ອນການປະຕິບັດງານຈິງ ເພື່ອກວດສອບຄວາມເປັນໄປໄດ້ກ່ອນທີ່ຈະດຳເນີນການຈິງ.
• Staging Execution: ສະສົມການປ່ຽນແປງໄວ້ໃນພື້ນທີ່ຊົ່ວຄາວ ແລະ ຈະນຳໄປອັບເດດລວມກັນຫຼັງຈາກຢືນຢັນໄດ້ວ່າທຸກຂັ້ນຕອນສຳເລັດແລ້ວ.

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

ຄວາມລົ້ມເຫຼວຂອງການກຳກັບດູແລ (Governance) ມັກຈະເກີດຂຶ້ນໃນຮູບແບບຂອງ "ການອອກແບບ ແລະ ການປະຕິບັດງານທີ່ບໍ່ສອດຄ່ອງກັນ" ຫຼາຍກວ່າ "ການຄວບຄຸມທີ່ຫ່າງເຫີນເກີນໄປ". ຫາກເຮົາເຂົ້າໃຈຮູບແບບຄວາມລົ້ມເຫຼວ 2 ຢ່າງທີ່ຢູ່ກົງກັນຂ້າມກັນ ຄື: ການເປັນພຽງຮູບແບບ (形骸化) ແລະ ການຄວບຄຸມທີ່ຫຼາຍເກີນໄປ (過剰制御), ເຮົາກໍຈະສາມາດກວດສອບໄດ້ວ່າການດຳເນີນງານຂອງບໍລິສັດເຮົາກຳລັງເອນອຽງໄປທາງໃດ.

ການກາຍເປັນພຽງຮູບແບບທີ່ບໍ່ມີເນື້ອໃນ (形骸化) ຈະດຳເນີນໄປຢ່າງງຽບໆ. ໂດຍປົກກະຕິແລ້ວ, ມາດຕະການປ້ອງກັນ (Guardrail) ທີ່ເຄີຍໃຊ້ງານໄດ້ດີໃນຊ່ວງຫຼັງຈາກການນຳໃຊ້, ຫຼັງຈາກຜ່ານໄປສອງສາມເດືອນກໍຈະຕົກຢູ່ໃນສະພາບດັ່ງຕໍ່ໄປນີ້:

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

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

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

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

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

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

Q1: ທີມຂະໜາດນ້ອຍຈຳເປັນຕ້ອງມີລະບົບການຄຸ້ມຄອງ (Governance) ລະດັບນີ້ບໍ?

ຂະໜາດຂອງລະບົບແມ່ນຂຶ້ນຢູ່ກັບສິດອຳນາດຂອງ Agent ບໍ່ແມ່ນຂຶ້ນກັບຂະໜາດຂອງອົງກອນ. ຖ້າເປັນ Agent ປະເພດອ່ານຢ່າງດຽວ (Read-only), ການເຮັດເອກະສານກຳນົດຂອບເຂດສິດອຳນາດ ແລະ ການເກັບ Log ກໍພຽງພໍທີ່ຈະເລີ່ມຕົ້ນໄດ້. ໃນທາງກົງກັນຂ້າມ, ຖ້າຫາກມອບໝາຍໜ້າທີ່ໃນການຂຽນ, ລຶບ, ຫຼື ສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ພາຍນອກ, ເຖິງແມ່ນວ່າທີມຈະມີຂະໜາດນ້ອຍ ກໍບໍ່ສາມາດລະເລີຍການແຍກສິດອຳນາດ (Separation of Duties), ການກຳນົດ Hard limit, ແລະ ຂັ້ນຕອນການອະນຸມັດໄດ້.

Q2: ມີຄວາມກ່ຽວຂ້ອງແນວໃດກັບມາດຕະການຄວາມປອດໄພທີ່ມີຢູ່ແລ້ວ (IAM, SIEM)?

ບໍ່ແມ່ນການທົດແທນ ແຕ່ເປັນການຂະຫຍາຍຄວາມສາມາດ. ຖ້າລົງທະບຽນ Agent ເປັນ Service Account ສະເພາະໃນ IAM ທີ່ມີຢູ່ ແລະ ລວມສູນ Audit log ໄວ້ໃນ SIEM ທີ່ມີຢູ່ແລ້ວ, ທ່ານກໍສາມາດນຳໃຊ້ກອບການຕິດຕາມ ແລະ ຄວບຄຸມທີ່ດຳເນີນການຢູ່ແລ້ວໄດ້ທັນທີ ໂດຍບໍ່ຈຳເປັນຕ້ອງສ້າງພື້ນຖານການຈັດການສະເພາະສຳລັບ Agent ຂຶ້ນມາໃໝ່ແຕ່ຕົ້ນ.

Q3: ຄວນຕິດຕັ້ງ Guardrail ໄວ້ທີ່ຝັ່ງ Model ຫຼື ຝັ່ງ Application?

ການຄວບຄຸມທີ່ຕ້ອງການຄວາມໝັ້ນໃຈສູງ ຄວນຕິດຕັ້ງໄວ້ໃນຊັ້ນ Application ແລະ ໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure. ຄຳສັ່ງໃນ System prompt ເປັນພຽງ Soft limit ເທົ່ານັ້ນ ແລະ ຄວນຕັ້ງສົມມຸດຕິຖານວ່າອາດຈະຖືກທຳລາຍໄດ້ດ້ວຍ Prompt injection. ການຄວບຄຸມຜ່ານ Prompt ຄວນຈຳກັດໄວ້ພຽງແຕ່ການປັບ "ພຶດຕິກຳທີ່ຕ້ອງການ" ເຊັ່ນ: ຮູບແບບການຂຽນ ຫຼື ເກນການຕັດສິນໃຈເທົ່ານັ້ນ.

Q4: ຄວນເລີ່ມຕົ້ນຈາກບ່ອນໃດ?

ລຳດັບທີ່ແນະນຳຄື: "ການກວດສອບສິດອຳນາດ (Inventory) → ຕາຕະລາງປະເມີນຄວາມສ່ຽງ → ການຕິດຕັ້ງ Hard limit → Audit log → HITL (Human-in-the-loop)". ການເລີ່ມນຳໃຊ້ Agent ຕົວທຳອິດໃນວຽກງານທີ່ຈຳກັດ ແລະ ມີສິດອຳນາດທີ່ແຄບ, ພ້ອມທັງສ້າງຮູບແບບການຄຸ້ມຄອງໄປພ້ອມກັບການດຳເນີນງານຕົວຈິງ ແລ້ວຈຶ່ງຂະຫຍາຍຜົນອອກໄປນັ້ນ ເປັນວິທີທີ່ໄວທີ່ສຸດ. ບໍລິສັດຂອງພວກເຮົາກໍມີການໃຫ້ບໍລິການຊ່ວຍເຫຼືອດ້ານການອອກແບບ Governance ເມື່ອນຳໃຊ້ AI Agent ເຊັ່ນກັນ, ດັ່ງນັ້ນ ຖ້າຫາກການຈັດຕັ້ງປະຕິບັດດ້ວຍຕົນເອງເປັນເລື່ອງຍາກ, ຂໍໃຫ້ພິຈາລະນາການມີຜູ້ຊ່ຽວຊານຮ່ວມດຳເນີນງານເປັນທາງເລືອກໜຶ່ງ.