Shadow AI Audit ແມ່ນຫຍັງ? ວິທີກວດສອບ ແລະ ຈັດການເຄື່ອງມື AI ທີ່ຖືກນຳໃຊ້ພາຍໃນອົງກອນໂດຍບໍ່ໄດ້ຮັບອະນຸຍາດ

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

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

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

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

ເບື້ອງຫຼັງການເພີ່ມທະວີຂຶ້ນເລື້ອຍໆຂອງ Shadow AI ແມ່ນເກີດຈາກຫຼາຍປັດໄຈລວມກັນ: ① Generative AI ໄດ້ຮັບຄວາມນິຍົມຢ່າງແຜ່ຫຼາຍ ເຮັດໃຫ້ພະນັກງານມີຄວາມຄຸ້ນເຄີຍກັບການໃຊ້ງານໃນຊີວິດປະຈຳວັນ. ② AI ທີ່ເປັນທາງການຂອງບໍລິສັດຍັງບໍ່ທັນມີຄວາມພ້ອມ ຫຼື ໃຊ້ງານຍາກ ຈຶ່ງເຮັດໃຫ້ພະນັກງານໃນພາກປະຕິບັດງານຫັນໄປໃຊ້ເຄື່ອງມືສ່ວນຕົວເພື່ອແກ້ໄຂບັນຫາດ້ວຍຕົນເອງ. ③ ສາມາດໃຊ້ງານໄດ້ຟຣີ, ທັນທີ ແລະ ເຮັດທຸກຢ່າງໃຫ້ສຳເລັດໄດ້ຜ່ານສະມາດໂຟນ ເຊິ່ງເຮັດໃຫ້ອຸປະສັກໃນການນຳມາໃຊ້ງານແທບຈະເປັນສູນ. ④ ມີຄວາມກົດດັນທີ່ຕ້ອງການເຫັນຜົນງານຢ່າງວ່ອງໄວ.

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

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

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

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

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

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

ກ່ອນອື່ນໝົດ, ໃຫ້ກວດສອບວ່າປັດຈຸບັນມີນະໂຍບາຍການນຳໃຊ້ AI ແລ້ວຫຼືບໍ່. ໃນຄວາມເປັນຈິງ, ມີຫຼາຍບໍລິສັດທີ່ຍັງບໍ່ທັນມີນະໂຍບາຍສະເພາະສຳລັບ AI. ກອບວຽກທີ່ສາມາດນຳມາອ້າງອີງໃນການສ້າງມາດຕະຖານ ຫຼື Specification ໄດ້ນັ້ນມີ NIST AI RMF (ເຊິ່ງປະກອບດ້ວຍ 4 ຟັງຊັນຄື: Govern, Map, Measure ແລະ Manage, ເປັນກອບວຽກແບບສະໝັກໃຈທີ່ມາຈາກສະຫະລັດອາເມຣິກາ) ແລະ ISO/IEC 42001 (ມາດຕະຖານ ຫຼື Specification ລະບົບການຈັດການ AI ສາກົນທີ່ສາມາດຂໍການຮັບຮອງໄດ້). ທັງສອງຢ່າງນີ້ມີລາຍການການຈັດການທີ່ຊ້ຳຊ້ອນກັນຫຼາຍ, ເຮັດໃຫ້ຫຼາຍອົງກອນເລືອກໃຊ້ NIST AI RMF ເປັນຮູບແບບການດຳເນີນງານ ແລະ ໃຊ້ ISO/IEC 42001 ເປັນເປົ້າໝາຍໃນການຂໍການຮັບຮອງຈາກພາຍນອກ.

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

ຂອບເຂດການກວດສອບຈະຖືກກຳນົດໂດຍ 3 ແກນຫຼັກ: ① ພະແນກທີ່ກ່ຽວຂ້ອງ: ເນື່ອງຈາກການດຳເນີນການພ້ອມກັນທົ່ວທັງບໍລິສັດມີພາລະໜັກເກີນໄປ, ຄວນເລີ່ມຈາກພະແນກທີ່ຈັດການກັບຂໍ້ມູນລັບ (ເຊັ່ນ: ຝ່າຍຂາຍ, ຝ່າຍພັດທະນາ, ຝ່າຍບຸກຄະລາກອນ, ຝ່າຍບັນຊີ ແລະ ອື່ນໆ). ② ເຄື່ອງມືທີ່ກ່ຽວຂ້ອງ: ບໍ່ພຽງແຕ່ AI ປະເພດແຊັດເທົ່ານັ້ນ, ແຕ່ໃຫ້ລວມເຖິງ SaaS ທີ່ມີຟັງຊັນ AI ໃນຕົວ, ສ່ວນເສີມຂອງບຣາວເຊີ (Browser extension) ແລະ ເຄື່ອງມືຊ່ວຍຂຽນໂຄດ. ③ ຂໍ້ມູນທີ່ກ່ຽວຂ້ອງ: ຕ້ອງກຳນົດໃຫ້ໄດ້ວ່າຂໍ້ມູນສ່ວນບຸກຄົນ, ຄວາມລັບທາງການຄ້າ ແລະ ຂໍ້ມູນທີ່ຢູ່ພາຍໃຕ້ການຄວບຄຸມນັ້ນຢູ່ບ່ອນໃດ.

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

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

ພື້ນຖານຂອງການກວດສອບທາງດ້ານເຕັກນິກແມ່ນການລວບລວມຂໍ້ມູນການເຂົ້າເຖິງໂດເມນຂອງບໍລິການ AI ທີ່ຮູ້ຈັກຈາກບັນທຶກຂອງ Proxy, Firewall ແລະ SWG (Secure Web Gateway). ຖ້າມີການນຳໃຊ້ CASB ຫຼື SASE ກໍຈະສາມາດເຫັນພາບລວມການນຳໃຊ້ SaaS ໄດ້ກວ້າງຂວາງຍິ່ງຂຶ້ນ. ນອກຈາກນີ້, ບັນທຶກ DNS ແລະ ການກວດສອບແອັບພລິເຄຊັນເທິງ Endpoint ກໍສາມາດນຳມາໃຊ້ເປັນສ່ວນເສີມໄດ້ເຊັ່ນກັນ.

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

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

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

ການໃຊ້ເຄື່ອງມືຈັດການ SaaS (ເຊັ່ນ: SSPM ຫຼື CASB) ຊ່ວຍໃຫ້ສາມາດກວດສອບບໍລິການ AI ທີ່ກຳລັງໃຊ້ງານຢູ່ໄດ້ໂດຍອັດຕະໂນມັດ ໂດຍອີງໃສ່ຂໍ້ມູນຕ່າງໆ ເຊັ່ນ: ສັນຍາ, ການເກັບເງິນ, ການເຊື່ອມຕໍ່ ຫຼື ຊິງຄ໌ຂໍ້ມູນຜ່ານ OAuth, ແລະ ສ່ວນເສີມຂອງບຣາວເຊີ. ສິ່ງທີ່ສຳຄັນໂດຍສະເພາະແມ່ນການກວດສອບແອັບ AI ພາຍນອກທີ່ເຊື່ອມຕໍ່ກັບບັນຊີບໍລິສັດຜ່ານ OAuth, ເຊິ່ງສິ່ງເຫຼົ່ານີ້ອາດກາຍເປັນຊ່ອງທາງໃນການເຂົ້າເຖິງຂໍ້ມູນພາຍໃນໂດຍບໍ່ໄດ້ຮັບອະນຸຍາດ. ນອກຈາກນີ້, ຍັງຕ້ອງມີການກວດສອບສະຖານະການຈັດການສ່ວນເສີມຂອງບຣາວເຊີ ແລະ ປະຫວັດການເຂົ້າສູ່ລະບົບຂອງ IdP (ລະບົບພື້ນຖານດ້ານ ID) ຄວບຄູ່ກັນໄປ.

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

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

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

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

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

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

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

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

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

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

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

ມັນເປັນສິ່ງສຳຄັນທີ່ຈະບໍ່ເພິ່ງພຽງແຕ່ກົດລະບຽບເທົ່ານັ້ນ ແຕ່ຕ້ອງມີເຕັກໂນໂລຊີມາສະໜັບສະໜູນ. ໂດຍສະເພາະແມ່ນ: ① ຄວບຄຸມການເຂົ້າເຖິງບໍລິການ AI ທີ່ບໍ່ໄດ້ຮັບອະນຸມັດດ້ວຍ CASB ຫຼື SWG (ບລັອກ ຫຼື ແຈ້ງເຕືອນ). ② ກວດຈັບ ແລະ ສະກັດກັ້ນການສົ່ງຂໍ້ມູນລັບໄປຍັງ AI ພາຍນອກດ້ວຍ DLP (Data Loss Prevention). ③ ໃຫ້ບໍລິການ AI ສຳລັບອົງກອນໂດຍມີ SSO ແລະ MFA ເພື່ອເຮັດໃຫ້ການໃຊ້ງານຜ່ານຊ່ອງທາງທີ່ຖືກຕ້ອງສະດວກຍິ່ງຂຶ້ນ. ④ ບັນທຶກ Prompt ແລະ ຜົນລັອກ (Output) ໄວ້ໃນໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ຂອງ AI ພາຍໃນບໍລິສັດ ເພື່ອໃຫ້ສາມາດຕິດຕາມກວດກາໄດ້.

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

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

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

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

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

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

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

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