ຄຳແນະນຳພາຍໃນອົງກອນສຳລັບ LLM ແມ່ນລະບົບກົດລະບຽບການນຳໃຊ້ ແລະ ຂັ້ນຕອນການດຳເນີນງານທີ່ອົງກອນກຳນົດຂຶ້ນ ເພື່ອໃຫ້ສາມາດນຳໃຊ້ AI ສ້າງສັນ (Generative AI) ໄດ້ຢ່າງປອດໄພ ແລະ ມີການຄວບຄຸມ.

"Shadow AI" ຫຼື ການນຳໃຊ້ Generative AI ໃນການເຮັດວຽກໂດຍບໍ່ໄດ້ຮັບການອະນຸມັດ ມີຄວາມສ່ຽງທີ່ຈະນຳໄປສູ່ການສົ່ງຂໍ້ມູນລັບ ຫຼື ຂໍ້ມູນສ່ວນຕົວໄປພາຍນອກໂດຍບໍ່ໄດ້ຕັ້ງໃຈ. ຄະນະກຳມະການຄຸ້ມຄອງຂໍ້ມູນສ່ວນຕົວ (Personal Information Protection Commission) ໄດ້ເປີດຕົວ ຫຼື Launch ການແຈ້ງເຕືອນກ່ຽວກັບການນຳໃຊ້ບໍລິການ Generative AI ໃນເດືອນມິຖຸນາ ປີ 2023 ແລະ ການຕອບສະໜອງໃນລະດັບອົງກອນໄດ້ກາຍເປັນສິ່ງຈຳເປັນດ່ວນ.

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

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

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

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

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

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

ໃນຄຳເຕືອນທີ່ຄະນະກຳມະການປົກປ້ອງຂໍ້ມູນສ່ວນບຸກຄົນໄດ້ເຜີຍແຜ່ໃນເດືອນມິຖຸນາ 2023 ກໍໄດ້ຊີ້ໃຫ້ເຫັນເຖິງຈຸດທີ່ວ່າ ການປ້ອນຂໍ້ມູນສ່ວນບຸກຄົນເຂົ້າໃນບໍລິການ Generative AI ອາດເຂົ້າຂ່າຍການໃຫ້ຂໍ້ມູນແກ່ບຸກຄົນທີສາມຕາມກົດໝາຍວ່າດ້ວຍການປົກປ້ອງຂໍ້ມູນສ່ວນບຸກຄົນ.

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

ການນຳໃຊ້ Generative AI ຢ່າງແຜ່ຫຼາຍໂດຍປາສະຈາກແນວທາງປະຕິບັດທີ່ຊັດເຈນ ຈະເຮັດໃຫ້ອົງກອນຕ້ອງປະເຊີນກັບ 3 ຄວາມສ່ຽງໃຫຍ່ດັ່ງນີ້:

① ການສົ່ງຂໍ້ມູນລັບອອກໄປພາຍນອກໂດຍບໍ່ໄດ້ຕັ້ງໃຈ ມີລາຍງານກໍລະນີທີ່ພະນັກງານນຳຂໍ້ມູນລັບທາງທຸລະກິດໄປວາງລົງໃນ Prompt ໂດຍກົງ. ບໍລິການ Cloud-based LLM ສ່ວນຫຼາຍມັກຕັ້ງຄ່າເລີ່ມຕົ້ນໃຫ້ໃຊ້ຂໍ້ມູນທີ່ປ້ອນເຂົ້າໄປໃນການປັບປຸງ Model, ເຊິ່ງອາດສົ່ງຜົນໃຫ້ຂໍ້ມູນລັບຖືກ ສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ ພາຍນອກໂດຍບໍ່ໄດ້ຕັ້ງໃຈ. ຫາກເປັນການປ້ອນຂໍ້ມູນທີ່ມີຂໍ້ມູນສ່ວນບຸກຄົນລວມຢູ່ດ້ວຍ, ອາດຈະນຳໄປສູ່ຄວາມຮັບຜິດຊອບທາງກົດໝາຍ ດັ່ງທີ່ລະບຸໄວ້ໃນ GDPR ຫຼື ຄຳເຕືອນທີ່ຄະນະກຳມະການປົກປ້ອງຂໍ້ມູນສ່ວນບຸກຄົນຂອງຍີ່ປຸ່ນໄດ້ເປີດເຜີຍໃນເດືອນມິຖຸນາ 2023.

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

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

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

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

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

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

ວິທີການສຳຫຼວດຫຼັກໃນການກວດສອບສິນຄ້າຄົງຄັງ

• ການກວດສອບ Network Log: ສະກັດປະຫວັດການເຂົ້າເຖິງບໍລິການ Generative AI ຈາກ Log ຂອງ Proxy ຫຼື Firewall. ການກຳນົດເປົ້າໝາຍໄປທີ່ Domain ຂອງບໍລິການຫຼັກໆ ເຊັ່ນ: ChatGPT, Copilot, Gemini ແລະ ອື່ນໆ ຈະມີປະສິດທິພາບຫຼາຍຂຶ້ນ.
• ການສຳຫຼວດດ້ວຍແບບສອບຖາມ: ໃຫ້ແຕ່ລະພະແນກຕອບກ່ຽວກັບ "ຊື່ເຄື່ອງມື AI, ຈຸດປະສົງການນຳໃຊ້ ແລະ ຄວາມຖີ່ທີ່ໃຊ້ໃນວຽກງານ". ການເຮັດແບບບໍ່ລະບຸຕົວຕົນມີແນວໂນ້ມທີ່ຈະເພີ່ມອັດຕາການລາຍງານການນຳໃຊ້ທີ່ບໍ່ເປັນທາງການໄດ້.
• ການນຳໃຊ້ເຄື່ອງມືຈັດການ SaaS: ຖ້າມີການນຳໃຊ້ໂຊລູຊັນການຈັດການ SaaS ຢູ່ແລ້ວ, ທ່ານສາມາດສະກັດໝວດໝູ່ AI ອອກຈາກລາຍການແອັບພລິເຄຊັນໄດ້.

ວິທີການຈັດລະບຽບຜົນການກວດສອບສິນຄ້າຄົງຄັງ

ຂໍ້ມູນທີ່ເກັບກຳໄດ້ຈາກການສຳຫຼວດ ຈະຖືກນຳມາຈັດລາຍການຕາມຫົວຂໍ້ດັ່ງລຸ່ມນີ້:

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

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

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

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

ການຈັດລະບຽບວ່າ "ໃຜເປັນຜູ້ຕັດສິນໃຈ, ໃຜເປັນຜູ້ປະຕິບັດ ແລະ ໃຜເປັນຜູ້ລາຍງານ" ໃນແຕ່ລະບົດບາດດ້ວຍ RACI matrix (Responsible / Accountable / Consulted / Informed) ຈະຊ່ວຍຫຼຸດຜ່ອນຄວາມເຂົ້າໃຈຜິດໃນຂະບວນການຕໍ່ໄປໄດ້.

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

"ເຄື່ອງມື AI ໃດທີ່ສາມາດນຳມາໃຊ້ງານໄດ້" — ການສ້າງສະພາວະທີ່ໜ້າວຽກສາມາດຕອບຄຳຖາມນີ້ໄດ້ດ້ວຍຕົນເອງ ຄືຈຸດເລີ່ມຕົ້ນຂອງການກຳນົດແນວທາງປະຕິບັດ (Guideline).

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

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

ດັ່ງນັ້ນ, ວິທີທີ່ມີປະສິດທິຜົນຄືການຈັດປະເພດເຄື່ອງມື AI ອອກເປັນ 3 ລະດັບ ເພື່ອບໍລິຫານຈັດການ:

① ເຄື່ອງມືທີ່ໄດ້ຮັບການອະນຸມັດ (Approved) ແມ່ນເຄື່ອງມືທີ່ພະແນກລະບົບຂໍ້ມູນຂ່າວສານໄດ້ປະເມີນຄວາມປອດໄພຮຽບຮ້ອຍແລ້ວ ແລະ ພະນັກງານທຸກຄົນສາມາດນຳໃຊ້ໄດ້ຕາມຂັ້ນຕອນທີ່ກຳນົດໄວ້. ເງື່ອນໄຂຄືຕ້ອງມີການເກັບບັນທຶກການນຳໃຊ້ (Log) ແລະ ຢືນຢັນພື້ນທີ່ໃນການປະມວນຜົນຂໍ້ມູນຮຽບຮ້ອຍແລ້ວ.

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

③ ເຄື່ອງມືທີ່ຫ້າມໃຊ້ (Prohibited) ເຄື່ອງມືທີ່ມີຄວາມສ່ຽງວ່າຂໍ້ມູນຈະຖືກນຳໄປໃຊ້ໃນການຮຽນຮູ້ (Training) ຫຼື ເຄື່ອງມືທີ່ບໍ່ຮູ້ພື້ນທີ່ໃນການປະມວນຜົນຂໍ້ມູນ ຈະຖືກຈັດຢູ່ໃນໝວດຫ້າມໃຊ້. ການເປີດເຜີຍລາຍການເຫດຜົນທີ່ຫ້າມໃຊ້ຈະຊ່ວຍໃຫ້ພະນັກງານໜ້າວຽກເຂົ້າໃຈໄດ້ງ່າຍຂຶ້ນວ່າ "ເປັນຫຍັງຈຶ່ງໃຊ້ບໍ່ໄດ້".

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

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

ການຕັ້ງຄ່າລະດັບຄວາມລັບໂດຍແບ່ງອອກເປັນ 3 ລະດັບດັ່ງຕໍ່ໄປນີ້ ຈະຊ່ວຍໃຫ້ການນຳໄປໃຊ້ງານຈິງມີຄວາມສະດວກຫຼາຍຂຶ້ນ:

• ລະດັບ 1 (ຂໍ້ມູນສາທາລະນະ): ເນື້ອຫາດ້ານການຕະຫຼາດທີ່ເປີດເຜີຍຕໍ່ພາຍນອກແລ້ວ, ມາດຕະຖານ ຫຼື Specification ຂອງຜະລິດຕະພັນ ແລະ ອື່ນໆ. ອະນຸຍາດໃຫ້ປ້ອນຂໍ້ມູນເຂົ້າສູ່ LLM ແບບ Cloud ພາຍນອກໄດ້.
• ລະດັບ 2 (ຂໍ້ມູນສະເພາະພາຍໃນ): ຄູ່ມືພາຍໃນ, ບົດບັນທຶກການປະຊຸມ, ຂໍ້ມູນການເງິນທີ່ຍັງບໍ່ທັນເປີດຕົວ ຫຼື Launch ແລະ ອື່ນໆ. ສາມາດນຳໃຊ້ໄດ້ສະເພາະແຜນການສຳລັບອົງກອນທີ່ໄດ້ຮັບການອະນຸມັດ ຫຼື ສະພາບແວດລ້ອມແບບ On-premise ເທົ່ານັ້ນ.
• ລະດັບ 3 (ຂໍ້ມູນລັບ/ຂໍ້ມູນສ່ວນບຸກຄົນ): ຂໍ້ມູນສ່ວນບຸກຄົນຂອງລູກຄ້າ, ສັນຍາ, ຂໍ້ມູນການປະເມີນຜົນພະນັກງານ ແລະ ອື່ນໆ. ໂດຍຫຼັກການແລ້ວແມ່ນຫ້າມປ້ອນຂໍ້ມູນເຂົ້າສູ່ AI ແລະ ຕ້ອງມີການເຮັດໃຫ້ຂໍ້ມູນເປັນນາມມະທຳ (Anonymization) ຫຼື ການປິດບັງຂໍ້ມູນ (Masking) ຢ່າງຈຳເປັນ.

ໃນການແຈ້ງເຕືອນທີ່ຄະນະກຳມະການປົກປ້ອງຂໍ້ມູນສ່ວນບຸກຄົນໄດ້ເປີດຕົວ ຫຼື Launch ໃນເດືອນມິຖຸນາ 2023 ກໍໄດ້ຮຽກຮ້ອງໃຫ້ມີການຮັບມືຢ່າງລະມັດລະວັງກ່ຽວກັບການປ້ອນຂໍ້ມູນສ່ວນບຸກຄົນເຂົ້າສູ່ບໍລິການ Generative AI. ຖ້າຫາກມີການດຳເນີນທຸລະກິດກັບເອີຣົບທີ່ມີການນຳໃຊ້ GDPR, ຈຳເປັນຕ້ອງມີຂໍ້ຈຳກັດທີ່ເຂັ້ມງວດກວ່ານີ້.

ໃນການກຳນົດກົດລະບຽບການຈັດການຂໍ້ມູນ, ກະລຸນາລະບຸຈຸດຕ່າງໆດັ່ງນີ້ໃຫ້ຊັດເຈນ:

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

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

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

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

ໃນໃບກວດສອບການປະເມີນ (Evaluation Check Sheet) ຄວນມີຫົວຂໍ້ຕ່າງໆຢ່າງໜ້ອຍດັ່ງນີ້:

ການຈັດການຂໍ້ມູນ (Data Handling)

• ຂໍ້ມູນທີ່ປ້ອນເຂົ້າຈະຖືກສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ເຊີບເວີຂອງຜູ້ໃຫ້ບໍລິການຫຼືບໍ່?
• ສາມາດເລືອກປະຕິເສດ (Opt-out) ການນຳຂໍ້ມູນໄປໃຊ້ໃນການຝຶກຝົນ (Training) ໄດ້ຫຼືບໍ່?
• ກົງກັບກໍລະນີການນຳໃຊ້ໃນວຽກງານທີ່ມີການປ້ອນຂໍ້ມູນສ່ວນຕົວ ຫຼື ຂໍ້ມູນລັບຫຼືບໍ່?

ຄວາມປອດໄພ ແລະ ການປະຕິບັດຕາມກົດລະບຽບ (Security & Compliance)

• ໄດ້ຮັບການຢັ້ງຢືນຈາກພາກສ່ວນທີສາມ ເຊັ່ນ: SOC 2 Type II ຫຼື ISO 27001 ແລ້ວຫຼືບໍ່?
• ຄວາມສອດຄ່ອງກັບ GDPR ຫຼື "ການແຈ້ງເຕືອນກ່ຽວກັບການນຳໃຊ້ບໍລິການ Generative AI (ມິຖຸນາ 2023)" ທີ່ກຳນົດໂດຍຄະນະກຳມະການປົກປ້ອງຂໍ້ມູນສ່ວນບຸກຄົນ.
• ສາມາດເຮັດສັນຍາຂໍ້ຕົກລົງການປະມວນຜົນຂໍ້ມູນ (DPA) ໄດ້ຫຼືບໍ່?

ຄວາມໜ້າເຊື່ອຖືຂອງຜູ້ໃຫ້ບໍລິການ (Vendor Reliability)

• ຄວາມສ່ຽງດ້ານຂະໜາດຂອງບໍລິສັດ ແລະ ຄວາມຕໍ່ເນື່ອງຂອງການບໍລິການ.
• ພັນທະໃນການແຈ້ງເຕືອນເມື່ອເກີດເຫດການບໍ່ຄາດຝັນ ແລະ ການມີຢູ່ຂອງ SLA.

ຄວາມເໝາະສົມກັບວຽກງານ (Operational Suitability)

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

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

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

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

ລາຍການທີ່ຄວນມີໃນແມ່ແບບ (Template) ມີດັ່ງນີ້:

• ຂໍ້ມູນຜູ້ຍື່ນຄຳຮ້ອງ: ຊື່-ນາມສະກຸນ, ພະແນກທີ່ສັງກັດ, ວັນທີຄາດວ່າຈະເລີ່ມນຳໃຊ້
• ພາບລວມຂອງເຄື່ອງມື: ຊື່ບໍລິການ, ຜູ້ໃຫ້ບໍລິການ, ຈຸດປະສົງການນຳໃຊ້, ວຽກງານທີ່ກ່ຽວຂ້ອງ
• ລະດັບຄວາມລັບຂອງຂໍ້ມູນທີ່ປ້ອນເຂົ້າ: ລະບຸການຈັດປະເພດທີ່ກຳນົດໄວ້ໃນພາກກ່ອນ (ເປີດເຜີຍຕໍ່ສາທາລະນະ / ພາຍໃນບໍລິສັດເທົ່ານັ້ນ / ເປັນຄວາມລັບ)
• ຜົນການປະເມີນຄວາມສ່ຽງ: ຄະແນນຈາກແບບຟອມກວດສອບ ແລະ ປະເພດການຕັດສິນ
• ຜູ້ອະນຸມັດ: ໂດຍພື້ນຖານແລ້ວ ຄວນມີ 2 ຂັ້ນຕອນ ຄື: ການອະນຸມັດຂັ້ນຕົ້ນ (ຫົວໜ້າໂດຍກົງ) → ການອະນຸມັດຂັ້ນສອງ (ພະແນກລະບົບຂໍ້ມູນຂ່າວສານ ຫຼື ຜູ້ຮັບຜິດຊອບດ້ານຄວາມປອດໄພ)

ຂໍ້ຄວນລະວັງໃນການດຳເນີນງານ 3 ຢ່າງຕໍ່ໄປນີ້ແມ່ນມີຄວາມສຳຄັນເປັນພິເສດ:

1. ກຳນົດເວລາໃນການອະນຸມັດ: ການລະບຸເວລາໃຫ້ຊັດເຈນ ເຊັ່ນ: ຕ້ອງອະນຸມັດຂັ້ນຕົ້ນພາຍໃນ 5 ວັນເຮັດວຽກ ແລະ ອະນຸມັດຂັ້ນສຸດທ້າຍພາຍໃນ 10 ວັນເຮັດວຽກນັບຈາກມື້ຍື່ນຄຳຮ້ອງ ຈະຊ່ວຍປ້ອງກັນສະຖານະການທີ່ "ໜ້າວຽກຕ້ອງເລີ່ມນຳໃຊ້ແບບບໍ່ເປັນທາງການໃນລະຫວ່າງທີ່ລໍຖ້າການອະນຸມັດ".
2. ການກວດສອບການນຳໃຊ້ຢ່າງຕໍ່ເນື່ອງເປັນໄລຍະ: ເຄື່ອງມືທີ່ເຄີຍໄດ້ຮັບການອະນຸມັດແລ້ວ ຄວນມີການປະເມີນຄືນໃໝ່ທຸກໆ 6 ເດືອນ ຫາ 1 ປີ ເພື່ອກວດສອບການປ່ຽນແປງມາດຕະຖານ ຫຼື Specification ຂອງບໍລິການ ແລະ ສະຖານະການເກີດເຫດການດ້ານຄວາມປອດໄພ.
3. ປິດຊ່ອງວ່າງການນຳໃຊ້ແບບສຸກເສີນ: ເພື່ອປ້ອງກັນການ "ທົດລອງນຳໃຊ້", ຄວນມີກົດລະບຽບຫ້າມນຳໃຊ້ກ່ອນການອະນຸມັດຢ່າງເປັນທາງການ. ໃນກໍລະນີທີ່ຈຳເປັນຕ້ອງມີການກວດສອບ, ຄວນຈຳກັດໃຫ້ໃຊ້ສະເພາະໃນສະພາບແວດລ້ອມ Sandbox ທີ່ຢູ່ພາຍໃຕ້ການຄວບຄຸມຂອງພະແນກລະບົບຂໍ້ມູນຂ່າວສານເທົ່ານັ້ນ.

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

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

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

ຂໍແນະນຳໃຫ້ດຳເນີນການຕອບໂຕ້ເບື້ອງຕົ້ນຕາມ 4 ຂັ້ນຕອນດັ່ງນີ້:

• ການກວດພົບ ແລະ ການກວດສອບເບື້ອງຕົ້ນ (0-30 ນາທີ): ກວດສອບຜົນລັບທີ່ໜ້າສົງໄສ, ບັນທຶກການສົ່ງຂໍ້ມູນ ແລະ ຄວາມຜິດປົກກະຕິຂອງການເຂົ້າເຖິງ, ພ້ອມທັງຢຸດການເຂົ້າເຖິງເຄື່ອງມື AI ທີ່ກ່ຽວຂ້ອງໄວ້ຊົ່ວຄາວ. ຜູ້ຮັບຜິດຊອບບໍ່ຄວນຕັດສິນໃຈດ້ວຍຕົນເອງ ແຕ່ໃຫ້ຕິດຕໍ່ຫາຫົວໜ້າໂດຍກົງ ແລະ ພະແນກຮັກສາຄວາມປອດໄພທັນທີ.
• ການລະບຸຂອບເຂດຜົນກະທົບ (30 ນາທີ - 2 ຊົ່ວໂມງ): ບັນທຶກວ່າຂໍ້ມູນໃດ, ເວລາໃດ ແລະ ຖືກປ້ອນເຂົ້າໃນເຄື່ອງມືໃດ. ເຖິງແມ່ນວ່າໃນ "ການແຈ້ງເຕືອນກ່ຽວກັບການນຳໃຊ້ບໍລິການ Generative AI" (ເດືອນມິຖຸນາ 2023) ທີ່ເຜີຍແຜ່ໂດຍຄະນະກຳມະການປົກປ້ອງຂໍ້ມູນສ່ວນບຸກຄົນ ກໍໄດ້ແນະນຳໃຫ້ມີການຕິດຕາມສະຖານະການປ້ອນຂໍ້ມູນສ່ວນບຸກຄົນເຊັ່ນກັນ.
• ການຄວບຄຸມສະຖານະການ ແລະ ການຮັກສາຫຼັກຖານ (2-4 ຊົ່ວໂມງ): ຮັກສາບັນທຶກ (Log) ຂອງເຊສຊັນ (Session) ທີ່ກ່ຽວຂ້ອງ, ຍົກເລີກການເຊື່ອມຕໍ່ API ຫຼື ປິດການໃຊ້ງານບັນຊີຂອງເຄື່ອງມືນັ້ນ. ບັນທຶກທີ່ເປັນຫຼັກຖານຄວນຖືກບັນທຶກໄວ້ໃນສື່ບັນທຶກຂໍ້ມູນອື່ນເພື່ອບໍ່ໃຫ້ຖືກລຶບ ຫຼື ຖືກຂຽນທັບ.
• ການລາຍງານ ແລະ ແຈ້ງເຕືອນ (4 ຊົ່ວໂມງເປັນຕົ້ນໄປ): ລາຍງານຕໍ່ຄະນະຜູ້ບໍລິຫານ, ພະແນກກົດໝາຍ ແລະ ໜ່ວຍງານກຳກັບດູແລຕາມຄວາມຈຳເປັນ ໂດຍປະຕິບັດຕາມກົດລະບຽບຂອງບໍລິສັດ. ຄວນລະວັງໃນກໍລະນີທີ່ GDPR ມີຜົນບັງຄັບໃຊ້ ເຊິ່ງມີຂໍ້ກຳນົດໃຫ້ຕ້ອງແຈ້ງຕໍ່ເຈົ້າໜ້າທີ່ພາຍໃນ 72 ຊົ່ວໂມງ.

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

ການອອກແບບ Audit Log ສາມາດຈັດລະບຽບໄດ້ງ່າຍໂດຍການພິຈາລະນາຈາກ 3 ແກນຫຼັກ ຄື: "ຈະເກັບຫຍັງ", "ເກັບໄວ້ໃສ", ແລະ "ເກັບໄວ້ດົນເທົ່າໃດ".

ອົງປະກອບຂັ້ນຕໍ່າຂອງ Log ທີ່ຄວນເກັບກຳມີດັ່ງນີ້:

• Log ການໃຊ້ງານ: ຊື່ເຄື່ອງມື, ID ຜູ້ໃຊ້, ວັນເວລາທີ່ໃຊ້ງານ, Session ID
• Log ການປ້ອນຂໍ້ມູນ: ການຈັດປະເພດຂອງ Prompt (ພ້ອມແທັກລະດັບຄວາມລັບ)
• Log ການສະແດງຜົນ: ຄ່າ Hash ຫຼື ບົດສະຫຼຸບຂອງຂໍ້ຄວາມທີ່ສ້າງຂຶ້ນ (ການເກັບຂໍ້ຄວາມເຕັມໃຫ້ພິຈາລະນາຕາມປະລິມານຂໍ້ມູນ)
• Log ການກວດຈັບຄວາມຜິດປົກກະຕິ: ລາຍລະອຽດຂອງການໃຊ້ງານທີ່ມີການຕັ້ງທຸງລະເມີດນະໂຍບາຍ

ໄລຍະເວລາໃນການເກັບຮັກສາຈະປ່ຽນແປງໄປຕາມລະດັບຄວາມລັບຂອງຂໍ້ມູນທີ່ຈັດການ. Log ການໃຊ້ງານທີ່ກ່ຽວຂ້ອງກັບຂໍ້ມູນສ່ວນບຸກຄົນ ຫຼື ຄວາມລັບທາງການຄ້າ ແນະນຳໃຫ້ເກັບຮັກສາໄວ້ຢ່າງໜ້ອຍ 1 ປີຂຶ້ນໄປ, ໃນຂະນະທີ່ Log ການໃຊ້ງານສຳລັບວຽກງານທົ່ວໄປມັກຈະພຽງພໍແລ້ວໃນໄລຍະ 3-6 ເດືອນ. ໃນກໍລະນີທີ່ມີການນຳໃຊ້ GDPR ຫຼື ກົດໝາຍວ່າດ້ວຍການປົກປ້ອງຂໍ້ມູນສ່ວນບຸກຄົນ, ຕ້ອງລະມັດລະວັງກ່ຽວກັບຂີດຈຳກັດສູງສຸດຂອງໄລຍະເວລາການເກັບຮັກສາຂໍ້ມູນນຳ.

ຮອບວຽນການກວດສອບ (Review Cycle) ທີ່ງ່າຍຕໍ່ການດຳເນີນງານແມ່ນໂຄງສ້າງສອງຊັ້ນ ຄື: ການກວດສອບແບບປົກກະຕິ (ລາຍເດືອນ) ແລະ ການກວດສອບແບບມີເຫດການກະຕຸ້ນ (ເມື່ອເກີດອຸປະຕິເຫດ). ໃນການກວດສອບລາຍເດືອນ ໃຫ້ກວດສອບແນວໂນ້ມຈຳນວນຂອງທຸງກວດຈັບຄວາມຜິດປົກກະຕິ, ຖ້າມີການເກີນຄ່າ Threshold ໃຫ້ລະບຸສາເຫດ. ເມື່ອເກີດອຸປະຕິເຫດ, ການກຳນົດຂັ້ນຕອນການຮັກສາ ແລະ ວິເຄາະ Log ຂອງ Session ທີ່ກ່ຽວຂ້ອງພາຍໃນ 72 ຊົ່ວໂມງໄວ້ລ່ວງໜ້າ ຈະຊ່ວຍປ້ອງກັນການຕົກຫຼົ່ນໃນການແກ້ໄຂບັນຫາໄດ້.

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

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

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

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

ຈຸດທີ່ຄວນອອກແບບໃຫ້ສອດຄ່ອງກັບແຕ່ລະຕຳແໜ່ງ ແລະ ສາຍງານ ມີດັ່ງນີ້:

ສຳລັບພະນັກງານທົ່ວໄປ (End-user)

• ການແຈ້ງໃຫ້ຊາບກ່ຽວກັບພາບລວມຂອງແນວທາງປະຕິບັດ ແລະ ຂໍ້ຫ້າມຕ່າງໆ (ເຊັ່ນ: ຫ້າມປ້ອນຂໍ້ມູນລັບເຂົ້າໃນລະບົບ)
• ວິທີການໃຊ້ງານເຄື່ອງມືທີ່ໄດ້ຮັບການອະນຸມັດ ແລະ ຊ່ອງທາງການລາຍງານເມື່ອເກີດບັນຫາ
• ການໃຊ້ຮູບແບບ Role-play ໂດຍອີງໃສ່ສະຖານະການເຮັດວຽກຕົວຈິງຈະມີປະສິດທິຜົນຫຼາຍ

ສຳລັບຜູ້ບໍລິຫານ ແລະ ຫົວໜ້າທີມ

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

ສຳລັບພະນັກງານ IT ແລະ ພະນັກງານຮັກສາຄວາມປອດໄພຂອງຂໍ້ມູນ

• ການປະເມີນ ມາດຕະຖານ ຫຼື Specification ທາງເຕັກນິກຂອງເຄື່ອງມື ແລະ ການກວດສອບການໄຫຼວຽນຂອງຂໍ້ມູນເມື່ອມີການ ເຊື່ອມຕໍ່ ຫຼື ຊິງຄ໌ຂໍ້ມູນ ຜ່ານ API
• ຂັ້ນຕອນການປະຕິບັດງານຕົວຈິງສຳລັບການເກັບ Log ແລະ ການກວດສອບ
• ວິທີການນຳໃຊ້ Checklist ສຳລັບການຕອບໂຕ້ເບື້ອງຕົ້ນເມື່ອເກີດເຫດການບໍ່ຄາດຝັນ (Incident)

ສຳລັບຜູ້ບໍລິຫານລະດັບສູງ ແລະ ຜູ້ຕັດສິນໃຈ

• ຂອບເຂດຜົນກະທົບຂອງຄວາມສ່ຽງດ້ານ AI ຕໍ່ອົງກອນ ແລະ ຄວາມຮັບຜິດຊອບໃນການບໍລິຫານ
• ພາບລວມຂອງການບໍລິຫານຈັດການ (Governance) ໂດຍອີງຕາມກອບມາດຕະຖານສາກົນ ເຊັ່ນ: NIST AI RMF 1.0
• ບົດບາດໃນຂະບວນການອະນຸມັດການປັບປຸງແນວທາງປະຕິບັດ

ຮູບແບບການຝຶກອົບຮົມທີ່ເໝາະສົມຄື: ການຮຽນຜ່ານ e-learning ໄລຍະສັ້ນ (ປະມານ 15-20 ນາທີ) ສຳລັບພະນັກງານທົ່ວໄປ ແລະ ການຝຶກອົບຮົມແບບລົງມືປະຕິບັດຈິງ (Hands-on workshop) ສຳລັບພະນັກງານ IT.

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

ເມື່ອອອກແບບການກວດສອບຄວາມເຂົ້າໃຈ ຄວນຍຶດຖື 3 ມຸມມອງຕໍ່ໄປນີ້ເປັນ ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ:

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

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

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

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

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

ລາຍລະອຽດເພີ່ມເຕີມຈະອະທິບາຍໄວ້ໃນແຕ່ລະ H3.

ຫຼາຍຄົນມັກຄິດວ່າ "ການເພີ່ມຄວາມເຂັ້ມງວດຂອງນະໂຍບາຍຈະເຮັດໃຫ້ເກີດຄວາມປອດໄພ" ແຕ່ໃນຄວາມເປັນຈິງແລ້ວ ສະພາບການໜ້າວຽກອາດຈະກົງກັນຂ້າມ.

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

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

ຮູບແບບທົ່ວໄປທີ່ນະໂຍບາຍເຂັ້ມງວດເກີນໄປສົ່ງຜົນກົງກັນຂ້າມ ມີດັ່ງນີ້:

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

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

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

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

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

ຈຸດສຳຄັນໃນການອອກແບບຮອບວຽນການປັບປຸງມີດັ່ງນີ້:

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

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

Q1. ວິສາຫະກິດຂະໜາດກາງ ແລະ ຂະໜາດນ້ອຍ (SME) ຈຳເປັນຕ້ອງມີແນວທາງປະຕິບັດ (Guideline) ដែរຫຼືບໍ່?

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

Q2. ຄວນລວມ ຫຼື Merge ເຂົ້າກັບນະໂຍບາຍຄວາມປອດໄພຂໍ້ມູນທີ່ມີຢູ່ແລ້ວແນວໃດ?

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

Q3. ຄວນຈັດການແນວໃດຫາກມີການໃຊ້ເຄື່ອງມື AI ແບບຟຣີໃນອຸປະກອນສ່ວນຕົວ?

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

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

ການເລີ່ມຕົ້ນຈາກການເຂົ້າໃຈສະຖານະການປັດຈຸບັນ ແລະ ການສ້າງລະບົບ, ໄປຈົນເຖິງ 5 ຂັ້ນຕອນ ຄື: ການຈັດປະເພດເຄື່ອງມື 3 ລະດັບ, ການອອກແບບຂະບວນການອະນຸມັດ, ການຮັບມືກັບເຫດການບໍ່ຄາດຝັນ ແລະ ການຈັດການບັນທຶກຂໍ້ມູນ (Log), ລວມເຖິງການຝຶກອົບຮົມຄວາມຮູ້ດ້ານ AI; ທັງໝົດນີ້ບໍ່ແມ່ນມາດຕະການທີ່ແຍກອອກຈາກກັນ ແຕ່ເຮັດວຽກເປັນຂະບວນການດຽວກັນ. ຖ້າຂາດສ່ວນໃດສ່ວນໜຶ່ງໄປ, ເຊັ່ນ: ຖ້າຈັດລະບຽບການຈັດປະເພດໄວ້ແຕ່ບໍ່ມີຂະບວນການເຮັດວຽກກໍຈະກາຍເປັນພຽງຮູບແບບທີ່ບໍ່ມີປະໂຫຍດ, ຫຼື ຖ້າຈັດພຽງການຝຶກອົບຮົມແຕ່ບໍ່ມີການກຽມພ້ອມດ້ານການຮັບມືກັບເຫດການບໍ່ຄາດຝັນ ກໍຈະບໍ່ສາມາດໃຊ້ງານໄດ້ຈິງໃນເວລາເກີດເຫດ.

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

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