ການເຮັດໃຫ້ AI Agents ເປັນປະຊາທິປະໄຕແມ່ນຫຍັງ? ຄູ່ມືການພັດທະນາໂດຍພົນລະເມືອງສຳລັບພະແນກທຸລະກິດເພື່ອສ້າງດ້ວຍຕົນເອງແບບ No-Code

ການເຮັດໃຫ້ AI agents ເປັນສິ່ງທີ່ທຸກຄົນເຂົ້າເຖິງໄດ້ (Democratization of AI agents) ໝາຍເຖິງການເຄື່ອນໄຫວທີ່ຊ່ວຍໃຫ້ພະນັກງານໃນພະແນກທຸລະກິດທີ່ບໍ່ແມ່ນສາຍງານ IT ສາມາດສ້າງ ແລະ ດຳເນີນການ AI agents ທີ່ເໝາະສົມກັບວຽກງານຂອງຕົນເອງໄດ້ ໂດຍການນຳໃຊ້ເຄື່ອງມືແບບ no-code/low-code.

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

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

ການເຮັດໃຫ້ເປັນປະຊາທິປະໄຕ (Democratization) ໝາຍເຖິງການເປີດຕົວ ຫຼື Launch ເທັກໂນໂລຊີ ແລະ ເຄື່ອງມືຕ່າງໆທີ່ເມື່ອກ່ອນສາມາດເຂົ້າເຖິງໄດ້ສະເພາະຜູ້ຊ່ຽວຊານເທົ່ານັ້ນ, ເຮັດໃຫ້ຄົນໃນວົງກວ້າງສາມາດເຂົ້າເຖິງໄດ້. ໃນບໍລິບົດຂອງ AI agents, ສິ່ງນີ້ໝາຍເຖິງການເຮັດໃຫ້ພະນັກງານໜ້າວຽກສາມາດປະກອບ AI agents—ເຊິ່ງເມື່ອກ່ອນຕ້ອງດຳເນີນການໂດຍວິສະວະກອນ—ໄດ້ໂດຍບໍ່ຕ້ອງຂຽນໂຄ້ດໃດໆ.

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

ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ແມ່ນຫົວຂໍ້ໃນທີ່ນີ້ບໍ່ແມ່ນ "ແອັບພລິເຄຊັນ" ແຕ່ເປັນ "agentic AI." ແທນທີ່ຈະເປັນພຽງແບບຟອມປ້ອນຂໍ້ມູນ ຫຼື ມາໂຄຣ (macros), ສິ່ງເຫຼົ່ານີ້ແມ່ນ agents ທີ່ເມື່ອໄດ້ຮັບຈຸດປະສົງແລ້ວ, ຈະກຳນົດຂັ້ນຕອນທີ່ຈຳເປັນ, ເອີ້ນໃຊ້ເຄື່ອງມືທີ່ເໝາະສົມ ແລະ ປະຕິບັດງານ—ແລະ ຄວາມຈິງທີ່ວ່າຜູ້ທີ່ບໍ່ແມ່ນວິສະວະກອນສາມາດກຳນົດ agents ເຫຼົ່ານີ້ໄດ້ໃນປັດຈຸບັນ ແມ່ນຄວາມແຕກຕ່າງທີ່ໃຫຍ່ທີ່ສຸດຈາກເຄື່ອງມື no-code ແບບດັ້ງເດີມ.

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

Citizen development ໄດ້ປ່ຽນແປງນະໂຍບາຍນີ້. ພະແນກທຸລະກິດ—ເຊິ່ງເປັນພາກສ່ວນທີ່ມີຄວາມຕ້ອງການຫຼາຍທີ່ສຸດ—ໃນປັດຈຸບັນໄດ້ກາຍມາເປັນຜູ້ສ້າງລະບົບດ້ວຍຕົນເອງ.

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

ການເລັ່ງລັດປະຊາທິປະໄຕທາງດ້ານເຕັກໂນໂລຊີ (Democratization) ແມ່ນຖືກຂັບເຄື່ອນດ້ວຍຄວາມຈິງທີ່ວ່າ ການສະໜອງຂອງພະແນກ IT ບໍ່ສາມາດຕອບສະໜອງໄດ້ທັນກັບຄວາມຕ້ອງການ, ໃນຂະນະທີ່ແພລດຟອມແບບ no-code ແລະ ເຕັກໂນໂລຊີການເຊື່ອມຕໍ່ຕ່າງໆ ໄດ້ພັດທະນາໄປເຖິງລະດັບທີ່ "ແມ້ແຕ່ຜູ້ທີ່ບໍ່ແມ່ນວິສະວະກອນ ກໍສາມາດສ້າງຂຶ້ນມາໄດ້." ພວກເຮົາຈະພິຈາລະນາເລື່ອງນີ້ຈາກທັງຝັ່ງຄວາມຕ້ອງການ ແລະ ຝັ່ງການສະໜອງ.

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

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

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

ສິ່ງທີ່ຊ່ວຍສົ່ງເສີມການເຂົ້າເຖິງຢ່າງທົ່ວເຖິງໃນທາງເຕັກນິກ ຄືການພັດທະນາຢ່າງເຕັມທີ່ຂອງເຄື່ອງມືສ້າງ Agent ແບບ no-code/low-code ແລະ ກົນໄກມາດຕະຖານສຳລັບການເຊື່ອມຕໍ່ກັບລະບົບພາຍນອກ.

ຈົນເຖິງເມື່ອບໍ່ດົນມານີ້, ການເຮັດໃຫ້ AI agent ສາມາດ "ອ້າງອີງຂໍ້ມູນພາຍໃນ" ຫຼື "ປະຕິບັດງານໃນລະບົບຫຼັກ" ຈຳເປັນຕ້ອງມີການຈັດຕັ້ງປະຕິບັດແບບສະເພາະເຈາະຈົງ ເຊິ່ງເປັນວຽກງານຂອງວິສະວະກອນໂດຍສະເພາະ. ຢ່າງໃດກໍຕາມ, ເມື່ອໂປຣໂຕຄອນທີ່ກຳນົດມາດຕະຖານການເຊື່ອມຕໍ່ເຄື່ອງມື (ເຊັ່ນ: MCP (Model Context Protocol)) ໄດ້ແຜ່ຂະຫຍາຍອອກໄປ, ມັນຈຶ່ງເຮັດໃຫ້ສາມາດເລືອກໃຊ້ຕົວເຊື່ອມຕໍ່ທີ່ສ້າງໄວ້ແລ້ວ ແລະ ເຮັດໃຫ້ Agent ສາມາດເຊື່ອມຕໍ່ກັບ CRM, ເຄື່ອງມືສົນທະນາ ແລະ ຖານຂໍ້ມູນຄວາມຮູ້ພາຍໃນໄດ້ຢ່າງປອດໄພ.

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

Citizen development ບໍ່ສາມາດດຳເນີນການໄດ້ດ້ວຍພຽງ "ໜ່ວຍງານທຸລະກິດສ້າງສິ່ງຕ່າງໆຂຶ້ນມາເອງ" ເທົ່ານັ້ນ. ແບບຈຳລອງພື້ນຖານແມ່ນການແບ່ງແຍກສິ່ງທີ່ສ້າງຂຶ້ນພາຍໃນ, ສິ່ງທີ່ມອບໝາຍໃຫ້ເຮັດ, ແລະ ສິ່ງທີ່ພະແນກ IT ໃຫ້ການສະໜັບສະໜູນ—ຈາກນັ້ນຈຶ່ງດຳເນີນການທຸກຢ່າງບົນພື້ນຖານ (Platform) ດຽວກັນ. ພວກເຮົາຈະມາເບິ່ງການແບ່ງບົດບາດ ແລະ ວິທີການເຮັດວຽກຂອງເຄື່ອງມືສຳລັບຜູ້ສ້າງ (Builder tools).

ຄວາມພະຍາຍາມໃນການເຮັດໃຫ້ທຸກຄົນເຂົ້າເຖິງໄດ້ (Democratization) ທີ່ປະສົບຜົນສຳເລັດ ໂດຍທົ່ວໄປແລ້ວຈະມີຮູບແບບປະສົມປະສານ ໂດຍມີການດຸ່ນດ່ຽງລະຫວ່າງ "ການຄວບຄຸມຈາກສູນກາງ" ກັບ "ການແບ່ງປັນຄວາມເປັນເຈົ້າຂອງໃນລະດັບທຸລະກິດ". ມັນເປັນໂຄງສ້າງສອງລະດັບທີ່ສູນກາງ (ພະແນກ IT ຫຼື CoE: Center of Excellence) ເປັນຜູ້ສະໜອງພື້ນຖານ ແລະ ກົດລະບຽບຕ່າງໆ, ໃນຂະນະທີ່ໜ່ວຍງານທຸລະກິດຈະສ້າງຕົວແທນ (Agents) ຂອງຕົນເອງຂຶ້ນມາເທິງພື້ນຖານນັ້ນ.

• ຂອບເຂດທີ່ໜ່ວຍງານທຸລະກິດ (Citizen developers) ເປັນຜູ້ຈັດການ: ການເຮັດວຽກອັດຕະໂນມັດຂະໜາດນ້ອຍທີ່ຈຳກັດຢູ່ພາຍໃນການດຳເນີນງານຂອງພະແນກຕົນເອງ ເຊັ່ນ: ການຈັດປະເພດຄຳຖາມ, ການຮ່າງເອກະສານ, ການສ້າງບົດລາຍງານປະຈຳ, ການປ້ອນຂໍ້ມູນ ແລະ ຂະບວນການອື່ນໆທີ່ສາມາດແກ້ໄຂຂໍ້ຜິດພາດໄດ້.
• ຂອບເຂດທີ່ພະແນກ IT / CoE ເປັນຜູ້ຈັດການ: ການສະໜອງອາແດັບເຕີ ຫຼື ສ່ວນເສີມ (Adapter) ຂອງເຄື່ອງມື ແລະ ເທມເພລດທີ່ໄດ້ຮັບການອະນຸມັດ, ການຈັດການສິດທິໃນການເຂົ້າເຖິງຂໍ້ມູນ, ການຮັກສາບັນທຶກການກວດສອບ (Audit logs), ການກວດສອບ ແລະ ອະນຸມັດການເປີດຕົວ ຫຼື Launch, ລວມເຖິງການໃຫ້ການຝຶກອົບຮົມ ແລະ ສະໜັບສະໜູນ.

ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກຂອງການແບ່ງງານນີ້ຄື "ພະແນກ IT ຍັງຄົງຮັກສາການຄວບຄຸມຂໍ້ມູນ ແລະ ສິດທິຕ່າງໆໄວ້, ໃນຂະນະທີ່ຝ່າຍທຸລະກິດໄດ້ຮັບອິດສະຫຼະໃນການປະກອບເຫດຜົນ (Logic) ເຂົ້າດ້ວຍກັນ". ສິ່ງທີ່ມອບໃຫ້ຝ່າຍທຸລະກິດນັ້ນ, ຖ້າເວົ້າກັນຢ່າງເຄັ່ງຄັດແລ້ວ, ແມ່ນອົງປະກອບທີ່ມີຄວາມປອດໄພ; ຝ່າຍທຸລະກິດຈະເປັນຜູ້ຕັດສິນໃຈວ່າຈະໃຊ້ອົງປະກອບໃດ ແລະ ຈະລວມ ຫຼື Merge ພວກມັນເຂົ້າກັນແນວໃດ. ປັດຊະຍາການອອກແບບທີ່ຢູ່ເບື້ອງຫຼັງພື້ນຖານດັ່ງກ່າວຍັງສອດຄ່ອງກັບ harness engineering ເຊິ່ງປ້ອງກັນຂໍ້ຜິດພາດຜ່ານໂຄງສ້າງ ໂດຍບໍ່ຕ້ອງອາໄສຄວາມລະມັດລະວັງຂອງບຸກຄົນ.

ຜູ້ທີ່ບໍ່ແມ່ນວິສະວະກອນສາມາດສ້າງ Agent ໄດ້ ເນື່ອງຈາກເຄື່ອງມືສ້າງ (builder tools) ຊ່ວຍປິດບັງ "ສ່ວນທີ່ຍາກ". ໂດຍທົ່ວໄປແລ້ວ, ເຄື່ອງມືສ້າງ Agent ຈະອະນຸຍາດໃຫ້ຜູ້ໃຊ້ສາມາດລວມອົງປະກອບຕ່າງໆເທິງໜ້າຈໍໄດ້ດັ່ງນີ້:

• Trigger: ເວລາທີ່ມັນເຮັດວຽກ (ເມື່ອໄດ້ຮັບອີເມວ, ກົດປຸ່ມ, ຕາມເວລາທີ່ກຳນົດໄວ້, ແລະ ອື່ນໆ)
• Instructions (prompt): ສິ່ງທີ່ມັນຄວນຈະເຮັດໃຫ້ສຳເລັດ
• Available tools: ຂໍ້ມູນທີ່ມັນສາມາດອ້າງອີງໄດ້ ແລະ ການກະທຳທີ່ມັນສາມາດຮຽກໃຊ້ໄດ້ (ສະເພາະສິ່ງທີ່ໄດ້ຮັບການອະນຸມັດລ່ວງໜ້າຈາກພະແນກ IT ເທົ່ານັ້ນທີ່ຈະຖືກສະແດງໄວ້)
• Output destination: ບ່ອນທີ່ສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ (ແຊັດ, ສະເປຣດຊີດ, ປີ້, ແລະ ອື່ນໆ)

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

ເມື່ອຜູ້ໃຊ້ຕ້ອງການເຊື່ອມຕໍ່ຫຼາຍຂັ້ນຕອນ ຫຼື ຫຼາຍ Agent ເຂົ້າດ້ວຍກັນ, ການອອກແບບນັ້ນຈະເຂົ້າສູ່ຂອບເຂດຂອງ AI agent orchestration. ວິທີການທີ່ປອດໄພແມ່ນເລີ່ມຕົ້ນຈາກຟັງຊັນດຽວກ່ອນ ແລ້ວຈຶ່ງຂະຫຍາຍໄປສູ່ຂະບວນການເຮັດວຽກແບບຫຼາຍ Agent (multi-agent workflows) ເມື່ອມີຄວາມຊຳນານແລ້ວ.

ກັບດັກທີ່ໃຫຍ່ທີ່ສຸດຂອງການເຮັດໃຫ້ທຸກຄົນເຂົ້າເຖິງໄດ້ (democratization) ແມ່ນເມື່ອ "ໃຜກໍສາມາດສ້າງໄດ້" ກາຍເປັນ "ໃຜກໍສາມາດສ້າງຫຍັງກໍໄດ້ຕາມໃຈມັກ". ໃຫ້ໃຊ້ຫຼັກການສິດທິຕ່ຳສຸດ (least privilege) ແລະ ຂະບວນການອະນຸມັດເພື່ອສະກັດກັ້ນ shadow AI ແລະ ການໃຫ້ສິດທິເກີນຄວາມຈຳເປັນໃນທາງໂຄງສ້າງ. ຄວນອອກແບບຄວາມສ່ຽງ ແລະ ມາດຕະການປ້ອງກັນໄປພ້ອມໆກັນ.

ເມື່ອການເຮັດໃຫ້ເຂົ້າເຖິງໄດ້ງ່າຍ (Democratization) ກ້າວໜ້າໄປໂດຍປາດສະຈາກຄວາມເປັນລະບຽບ, ຕົວແທນ (Agents) ທີ່ພະແນກ IT ບໍ່ສາມາດເບິ່ງເຫັນໄດ້ກໍຈະແຜ່ຂະຫຍາຍອອກໄປໃນພາກປະຕິບັດຕົວຈິງ. ນີ້ຄື "Shadow AI". ຄວາມສ່ຽງທີ່ເປັນຕົວແທນມີດັ່ງນີ້:

• ການຮົ່ວໄຫຼຂອງຂໍ້ມູນ (Data leakage): ຂໍ້ມູນລັບຖືກສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ບໍລິການ Generative AI ພາຍນອກໂດຍບໍ່ໄດ້ຕັ້ງໃຈ.
• ການໃຫ້ສິດທິເກີນຄວາມຈຳເປັນ (Excessive permissions): ຍ້ອນຜູ້ຄົນຕ້ອງການ "ພຽງແຕ່ໃຫ້ມັນເຮັດວຽກໄດ້", ຈຶ່ງມີການໃຫ້ສິດທິໃນວົງກວ້າງ ເຮັດໃຫ້ຕົວແທນສາມາດເຂົ້າເຖິງຂໍ້ມູນ ແລະ ການດຳເນີນງານທີ່ບໍ່ຄວນຈະໄປແຕະຕ້ອງໄດ້.
• ຄຸນນະພາບບໍ່ສະໝ່ຳສະເໝີ (Quality inconsistency): ຕົວແທນຖືກຝັງເຂົ້າໄປໃນຂະບວນການເຮັດວຽກໂດຍບໍ່ມີການກວດສອບ, ແລະ ຜົນລັອບທີ່ບໍ່ຖືກຕ້ອງກໍຫຼຸດເຂົ້າໄປໃນການຕັດສິນໃຈ.
• ການແຍກຕົວເປັນເອກະລາດ ແລະ ການປິດບັງການເຮັດວຽກ (Siloing and black-boxing): ມີພຽງຜູ້ທີ່ສ້າງຕົວແທນນັ້ນເທົ່ານັ້ນທີ່ຮູ້ວິທີການເຮັດວຽກຂອງມັນ, ແລະ ເມື່ອພວກເຂົາລາອອກ ຫຼື ຍົກຍ້າຍ, ກໍບໍ່ມີໃຜສາມາດຮັກສາລະບົບນັ້ນໄດ້.

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

ພື້ນຖານໃນການສະກັດກັ້ນ Shadow AI ແລະ ການໃຫ້ສິດທິເກີນຄວາມຈຳເປັນ ຄື "ການເພີ່ມອິດສະຫຼະໃນການເຮັດວຽກຕົວຈິງ ໂດຍມີການສະກັດກັ້ນສະເພາະການດຳເນີນງານທີ່ເປັນອັນຕະລາຍໃນລະດັບໂຄງສ້າງເທົ່ານັ້ນ."

• ຫຼັກການ Least Privilege ທີ່ເຂັ້ມງວດ: ໃຫ້ສິດທິແກ່ Agent ພຽງແຕ່ການເຂົ້າເຖິງຂໍ້ມູນ ແລະ ການດຳເນີນງານທີ່ຈຳເປັນສຳລັບວຽກນັ້ນໆເທົ່ານັ້ນ. ຢ່າຕັ້ງຄ່າການອະນຸຍາດແບບກວ້າງໆເປັນຄ່າເລີ່ມຕົ້ນ. ຫຼັກການອອກແບບນີ້ໄດ້ອະທິບາຍໄວ້ຢ່າງລະອຽດໃນ AI Agent Permission Design (Least Privilege).
• ຂະບວນການອະນຸມັດ (Publication gates): ເມື່ອມີການຍົກລະດັບ Agent ຈາກ "ການທົດລອງສ່ວນບຸກຄົນ" ໄປສູ່ "ການດຳເນີນງານໃນລະດັບພະແນກ", ຕ້ອງມີການກວດສອບໂດຍພະແນກ IT ຫຼື CoE. ຕ້ອງກວດສອບສະເໝີວ່າຂໍ້ມູນໃດທີ່ຖືກເຂົ້າເຖິງ ແລະ ມີການສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ພາຍນອກຫຼືບໍ່.
• Human-in-the-loop (HITL): ສຳລັບການດຳເນີນງານທີ່ຍາກຈະແກ້ໄຂຄືນໄດ້ — ເຊັ່ນ: ການສົ່ງຂໍ້ມູນ, ການເຮັດໃຫ້ສຳເລັດ ຫຼື ການຊຳລະເງິນ — ຕ້ອງມີການອະນຸມັດຈາກມະນຸດ ແທນທີ່ຈະປ່ອຍໃຫ້ເປັນການປະຕິບັດງານແບບອັດຕະໂນມັດ. Human-in-the-loop (HITL) ເປັນເອກະສານອ້າງອີງທີ່ເປັນປະໂຫຍດສຳລັບການພິຈາລະນາວ່າຄວນກຳນົດຂອບເຂດໄວ້ບ່ອນໃດ.
• ການເບິ່ງເຫັນ ແລະ ບັນທຶກການກວດສອບ (Audit logs): ເຮັດໃຫ້ສາມາດເບິ່ງເຫັນໄດ້ໃນທັນທີວ່າໃຜເປັນຜູ້ສ້າງ Agent ໃດ ແລະ ພວກເຂົາກຳລັງເຂົ້າເຖິງຂໍ້ມູນໃດແດ່.

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

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

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

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

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

ແທນທີ່ຈະເປີດຕົວ ຫຼື Launch ໃນວົງກວ້າງ, ໃຫ້ເລີ່ມຕົ້ນດ້ວຍການທົດສອບແນວຄວາມຄິດ (Proof of Concept) ຂະໜາດນ້ອຍ. ໃຫ້ສຸມໃສ່ພຽງໜຶ່ງພະແນກ ແລະ ໜຶ່ງວຽກເທົ່ານັ້ນ, ພ້ອມທັງບັນທຶກອັດຕາຄວາມສຳເລັດ, ຊົ່ວໂມງທີ່ປະຢັດໄດ້, ແລະ ຈຳນວນຄັ້ງທີ່ມະນຸດຕ້ອງເຂົ້າໄປແຊກແຊງ. ສິ່ງທີ່ສຳຄັນໃນທີ່ນີ້ບໍ່ແມ່ນ "ເຮັດສຳເລັດຈັກຄັ້ງ" ແຕ່ແມ່ນ "ຄວາມຜິດພາດເກີດຂຶ້ນແນວໃດ". ໃຫ້ລະບຸວ່າຂັ້ນຕອນໃດທີ່ກໍ່ໃຫ້ເກີດບັນຫາ ແລະ ມີຂໍ້ຍົກເວັ້ນປະເພດໃດແດ່ທີ່ເຮັດໃຫ້ຂະບວນການ ຫຼື Pipeline ຕ້ອງຢຸດສະງັກ, ຈາກນັ້ນຈຶ່ງກຽມຄວາມພ້ອມສຳລັບສິ່ງເຫຼົ່ານັ້ນໃນລະບົບການຜະລິດຈິງ.

ຄຽງຄູ່ກັບການເລີ່ມຕົ້ນຂະໜາດນ້ອຍ, ໃຫ້ວາງຮາກຖານທີ່ສາມາດຮອງຮັບການຂະຫຍາຍຕົວແບບ ແນວນອນ ຫຼື Horizontal. ການເປີດກວ້າງໃຫ້ພາກສະໜາມໂດຍປາດສະຈາກຮາກຖານດັ່ງກ່າວ ຈະເຮັດໃຫ້ເກີດບັນຫາ Shadow AI ທີ່ໄດ້ກ່າວມາກ່ອນໜ້ານີ້ ເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ.

• ການຮັກສາເຄື່ອງມື ແລະ ແມ່ແບບທີ່ໄດ້ຮັບການອະນຸມັດ: ກຽມ ອາແດັບເຕີ ຫຼື ສ່ວນເສີມ ທີ່ທີມງານພາກສະໜາມສາມາດນຳໃຊ້ໄດ້ຢ່າງປອດໄພ, ພ້ອມກັບແມ່ແບບທີ່ສາມາດກັອບປີ້ໄປໃຊ້ໄດ້ທັນທີ.
• ການຈັດການສິດທິ ແລະ ການເຂົ້າເຖິງຂໍ້ມູນແບບລວມສູນ: ໃຫ້ພະແນກ IT ເປັນຜູ້ຄວບຄຸມວ່າໃຜສາມາດເຂົ້າເຖິງຂໍ້ມູນໃດໄດ້บ้าง ແລະ ມອບໃຫ້ທີມງານພາກສະໜາມສະເພາະອົງປະກອບທີ່ພວກເຂົາຕ້ອງການເທົ່ານັ້ນ.
• ການຝຶກອົບຮົມ: ສອນບໍ່ພຽງແຕ່ວິທີການໃຊ້ເຄື່ອງມື, ແຕ່ລວມເຖິງແນວທາງປະຕິບັດທີ່ຕ້ອງປະຕິບັດຕາມ ເຊັ່ນ: "ຫ້າມແບ່ງປັນຂໍ້ມູນລັບ", "ຫ້າມໃຫ້ສິດທິໃນວົງກວ້າງ", ແລະ "ຕ້ອງຜ່ານການກວດສອບກ່ອນການເຜີຍແຜ່". ການແບ່ງປັນແນວທາງປະຕິບັດທີ່ເໝາະສົມມີປະສິດທິຜົນຫຼາຍກວ່າການຝຶກອົບຮົມການໃຊ້ເຄື່ອງມືພຽງຢ່າງດຽວ.
• ໜ່ວຍງານສະໜັບສະໜູນ (Support desk): ຈັດຫາບ່ອນທີ່ຜູ້ຄົນສາມາດສອບຖາມໄດ້ເມື່ອພວກເຂົາພົບກັບບັນຫາ ແລະ ປ້ອງກັນບໍ່ໃຫ້ທີມງານພາກສະໜາມຕ້ອງປະເຊີນກັບບັນຫາໂດຍລຳພັງ.

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

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

• ຕົວຊີ້ວັດດ້ານມູນຄ່າ (Value metrics): ຈຳນວນຊົ່ວໂມງທີ່ປະຢັດໄດ້, ການຫຼຸດຜ່ອນເວລາໃນການປະມວນຜົນ, ຈຳນວນກໍລະນີທີ່ຈັດການໄດ້, ຄວາມເພິ່ງພໍໃຈຂອງທີມງານພາກສະໜາມ.
• ຕົວຊີ້ວັດດ້ານສຸຂະພາບ (Health metrics): ຈຳນວນຕົວແທນ (Agents) ທີ່ເຄື່ອນໄຫວ, ອັດຕາການຜ່ານການກວດສອບ, ເຫດການທີ່ເກືອບຈະເກີດຄວາມຜິດພາດ (ການໃຫ້ສິດທິເກີນຄວາມຈຳເປັນ, ຜົນລັພທີ່ບໍ່ຖືກຕ້ອງ).

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

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

ຄວາມເຊື່ອທີ່ວ່າ "no-code ມີຄວາມປອດໄພເພາະທ່ານບໍ່ໄດ້ຂຽນໂຄ້ດ" ເປັນຄວາມເຊື່ອທີ່ອັນຕະລາຍ. ສິ່ງທີ່ no-code ລຶບອອກໄປແມ່ນຄວາມຫຍຸ້ງຍາກໃນການປະຕິບັດງານ ບໍ່ແມ່ນຄວາມຫຍຸ້ງຍາກໃນການຕັດສິນໃຈ.

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

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

ຖາມ: ການເຮັດໃຫ້ AI agent ເຂົ້າເຖິງໄດ້ງ່າຍ (Democratization) ແຕກຕ່າງຈາກ RPA ຫຼື ເຄື່ອງມືແບບ No-code ແນວໃດ?

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

ຖາມ: ຈຳເປັນຕ້ອງໄດ້ຮັບການອະນຸມັດຈາກພະແນກ IT ເພື່ອເລີ່ມຕົ້ນການພັດທະນາໂດຍຜູ້ໃຊ້ທົ່ວໄປ (Citizen Development) ຫຼືບໍ່?

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

ຖາມ: ພະແນກໃດທີ່ເໝາະສົມທີ່ສຸດໃນການເລີ່ມຕົ້ນ?

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

ການເຮັດໃຫ້ AI agents ເຂົ້າເຖິງໄດ້ງ່າຍ (Democratization of AI agents) ໝາຍເຖິງການເຄື່ອນໄຫວທີ່ຊ່ວຍໃຫ້ໜ່ວຍງານທຸລະກິດຕ່າງໆສາມາດສ້າງ ແລະ ດຳເນີນການ agents ໄດ້ດ້ວຍຕົນເອງ ໂດຍໃຊ້ເຄື່ອງມືແບບ no-code/low-code. ແນວໂນ້ມນີ້ກຳລັງຖືກຂັບເຄື່ອນດ້ວຍສອງປັດໄຈຄື: ພະແນກ IT ບໍ່ສາມາດຕອບສະໜອງຄວາມຕ້ອງການໄດ້ທັນ, ໃນຂະນະທີ່ໂປຣໂຕຄໍການເຊື່ອມຕໍ່ແບບມາດຕະຖານ ແລະ ເຄື່ອງມືສ້າງ agents ໄດ້ພັດທະນາໄປເຖິງລະດັບທີ່ "ແມ້ແຕ່ຜູ້ທີ່ບໍ່ແມ່ນວິສະວະກອນກໍສາມາດສ້າງມັນຂຶ້ນມາໄດ້."

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

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