
Shadow AI (Shadow AI) ໝາຍເຖິງການທີ່ພະນັກງານນຳໃຊ້ເຄື່ອງມື AI ຫຼື Generative AI ໃນການເຮັດວຽກ ໂດຍບໍ່ຜ່ານການອະນຸມັດ, ການກຳກັບດູແລ ຫຼື ການບໍລິຫານຈັດການຈາກພະແນກ IT ຫຼື ພະແນກຄວາມປອດໄພ. ບໍ່ວ່າຈະເປັນການຂຽນອີເມວ, ການສະຫຼຸບເນື້ອໃນການປະຊຸມ, ການວິເຄາະຂໍ້ມູນ, ການສ້າງເອກະສານ—ໃນຫຼາຍອົງກອນ, ການນຳໃຊ້ AI ບໍ່ໄດ້ເລີ່ມຕົ້ນຈາກແຜນການຂອງຝ່າຍບໍລິຫານ, ແຕ່ໄດ້ແຜ່ຂະຫຍາຍອອກໄປຈາກການທີ່ພະນັກງານໃນພາກສະໜາມເລີ່ມຕົ້ນນຳໃຊ້ "ດ້ວຍຕົນເອງ".
ບົດຄວາມນີ້ມີຈຸດປະສົງເພື່ອໃຫ້ຜູ້ຮັບຜິດຊອບດ້ານລະບົບຂໍ້ມູນຂ່າວສານ, ຄວາມປອດໄພ, ການປະຕິບັດຕາມກົດລະບຽບ ແລະ ຝ່າຍບໍລິຫານ ໄດ້ເຂົ້າໃຈວ່າ Shadow AI ແມ່ນຫຍັງ, ເປັນຫຍັງຈຶ່ງເກີດຂຶ້ນ, ມີຄວາມສ່ຽງຢູ່ບ່ອນໃດ ແລະ ຄວນຮັບມືກັບມັນແນວໃດ ໂດຍອີງຕາມແນວທາງຂອງ IBM, Microsoft, NIST ແລະ CISA. ເມື່ອອ່ານຈົບ, ເປົ້າໝາຍແມ່ນເພື່ອໃຫ້ທ່ານສາມາດປ່ຽນມຸມມອງຈາກຄຳຖາມທີ່ວ່າ "ຄວນສັ່ງຫ້າມໃຊ້ AI ທັງໝົດຫຼືບໍ່?" ໄປສູ່ຄຳຖາມທີ່ວ່າ "ຈະເຮັດແນວໃດໃຫ້ສາມາດນຳໃຊ້ AI ໄດ້ຢ່າງປອດໄພ?".
Shadow AI ແມ່ນການນຳໃຊ້ AI ທີ່ເກີດຂຶ້ນໂດຍທີ່ອົງກອນບໍ່ສາມາດຮັບຮູ້ ຫຼື ຄວບຄຸມໄດ້. ເຖິງວ່າຈະເບິ່ງຄືວ່າເປັນບັນຫາໃໝ່, ແຕ່ຄວາມຈິງແລ້ວມັນແມ່ນສ່ວນໜຶ່ງທີ່ສືບເນື່ອງມາຈາກ "Shadow IT" ທີ່ມີມາແຕ່ດົນນານ.
ກ່ອນອື່ນໝົດ, ພວກເຂົາຄວນເຂົ້າໃຈເຖິງຂອບເຂດທີ່ Shadow AI ກວມເອົາ ແລະ ຄວາມແຕກຕ່າງຈາກ Shadow IT ແບບດັ້ງເດີມ. ເມື່ອຂອບເຂດຂອງຄຳສັບມີຄວາມຊັດເຈນ, ໂຄງສ້າງຂອງຄວາມສ່ຽງທີ່ຈະອະທິບາຍໃນພາຍຫຼັງກໍຈະເຂົ້າໃຈໄດ້ງ່າຍຂຶ້ນ.
IBM ໄດ້ນິຍາມ Shadow AI ວ່າເປັນເຄື່ອງມື AI ແລະ Generative AI ທີ່ຖືກນຳໃຊ້ຢູ່ນອກການຄວບຄຸມຂອງອົງກອນ ໂດຍບໍ່ໄດ້ຮັບການອະນຸມັດ ຫຼື ການກວດສອບຈາກພະແນກ IT ແລະ ຄວາມປອດໄພ (IBM "What is shadow AI?"). ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ບໍ່ໄດ້ຢູ່ທີ່ "ການໃຊ້ AI" ແຕ່ຢູ່ທີ່ "ການໃຊ້ງານທີ່ອົງກອນບໍ່ສາມາດເບິ່ງເຫັນໄດ້".
ໂດຍສະເພາະ, ການນຳໃຊ້ດັ່ງຕໍ່ໄປນີ້ ລ້ວນແຕ່ຖືກຈັດຢູ່ໃນ Shadow AI:
ເນື່ອງຈາກທັງໝົດນີ້ບໍ່ແມ່ນ "ການນຳຊອບແວເຂົ້າມາໃຊ້ງານຢ່າງເປັນທາງການ", ມັນຈຶ່ງບໍ່ມີບັນທຶກຢູ່ໃນບັນຊີຄຸ້ມຄອງຊັບສິນ ແລະ ບໍ່ປາກົດຢູ່ໃນເຣດາຂອງພະແນກ IT. ຍ້ອນວ່າ AI ສາມາດເລີ່ມໃຊ້ງານໄດ້ພາຍໃນການຄລິກພຽງສອງສາມຄັ້ງ, ມັນຈຶ່ງເຮັດໃຫ້ເກີດຊ່ອງຫວ່າງອັນໃຫຍ່ຫຼວງລະຫວ່າງຄວາມຮັບຮູ້ຂອງອົງກອນ ແລະ ສະພາບຄວາມເປັນຈິງໃນພາກປະຕິບັດ.
Shadow AI ແມ່ນຮູບແບບໜຶ່ງຂອງ Shadow IT (ການນຳໃຊ້ຊອບແວ ຫຼື ບໍລິການໂດຍບໍ່ໄດ້ຮັບອະນຸຍາດ) ແຕ່ມີຄຸນນະພາບຂອງຄວາມສ່ຽງທີ່ແຕກຕ່າງກັນ. Shadow IT ແບບດັ້ງເດີມມີບັນຫາຫຼັກຢູ່ທີ່ "ການມີເຄື່ອງມືທີ່ບໍ່ໄດ້ຮັບການອະນຸມັດເຂົ້າມາໃຊ້ງານ". ໃນທາງກົງກັນຂ້າມ, Shadow AI ບໍ່ພຽງແຕ່ອ່ານຂໍ້ມູນເທົ່ານັ້ນ, ແຕ່ຍັງສາມາດຕັດສິນໃຈ, ສະຫຼຸບເນື້ອຫາ, ສ້າງຂໍ້ຄວາມ, ແລະບາງຄັ້ງຍັງສາມາດເຊື່ອມຕໍ່ກັບແຫຼ່ງຂໍ້ມູນພາຍນອກໄດ້ອີກດ້ວຍ.
ສິ່ງທີ່ເຮັດໃຫ້ Shadow AI ມີຄວາມຫຍຸ້ງຍາກກວ່າ Shadow IT ແມ່ນບໍ່ພຽງແຕ່ເລື່ອງປາຍທາງຂອງຂໍ້ມູນທີ່ປ້ອນເຂົ້າໄປເທົ່ານັ້ນ, ແຕ່ຍັງລວມເຖິງເນື້ອຫາທີ່ AI ສ້າງຂຶ້ນມາເຊິ່ງອາດຈະປົນເປື້ອນເຂົ້າໄປໃນການເຮັດວຽກຕົວຈິງ.
| ມຸມມອງ | Shadow IT ແບບດັ້ງເດີມ | Shadow AI |
|---|---|---|
| ເປົ້າໝາຍຫຼັກ | ແອັບຯ ຫຼື SaaS ທີ່ບໍ່ໄດ້ຮັບອະນຸມັດ | ເຄື່ອງມື AI ຫຼື AI Agent ທີ່ບໍ່ໄດ້ຮັບອະນຸມັດ |
| ຄວາມສ່ຽງຫຼັກ | ການຈັດເກັບຂໍ້ມູນ ແລະ ການຄວບຄຸມການເຂົ້າເຖິງ | ການປ້ອນຂໍ້ມູນ + ຜົນລວມຈາກ AI + ການເຊື່ອມຕໍ່ພາຍນອກ |
| ການຈັດການຂໍ້ມູນ | ເນັ້ນການຈັດເກັບ ແລະ ແບ່ງປັນ | ສາມາດນຳໄປໃຊ້ໃນການຮຽນຮູ້, ສ້າງໃໝ່ ແລະ ການຄາດຄະເນ |
| ຄວາມງ່າຍໃນການກວດພົບ | ງ່າຍກວ່າ | ເບິ່ງເຫັນໄດ້ຍາກຜ່ານ Browser Extension ຫຼື API |
| ຂອບເຂດຜົນກະທົບ | ຂໍ້ມູນຮົ່ວໄຫຼ ແລະ ຕົ້ນທຶນ | ການຮົ່ວໄຫຼ + ຂໍ້ມູນຜິດພາດປົນເປື້ອນໃນວຽກ + ການປະຕິບັດຕາມກົດລະບຽບ |
IBM ຍັງໄດ້ລະບຸວ່າ Shadow AI ເປັນ "ຊຸດຍ່ອຍ" ຂອງ Shadow IT, ແຕ່ໄດ້ຊີ້ໃຫ້ເຫັນວ່າຜົນກະທົບຕໍ່ຄວາມປອດໄພຂອງຂໍ້ມູນ, ການປະຕິບັດຕາມກົດລະບຽບ ແລະ ຊື່ສຽງນັ້ນມີຄວາມຮຸນແຮງກວ່າຫຼາຍ.
ເຫດຜົນສູງສຸດທີ່ເຮັດໃຫ້ Shadow AI ແຜ່ຂະຫຍາຍອອກໄປ ແມ່ນຍ້ອນວ່າ AI ມີຄວາມ "ວ່ອງໄວ, ງ່າຍດາຍ ແລະ ສ້າງຜົນລັດໄດ້". ຖ້າຫາກບໍ່ມີຊ່ອງທາງທີ່ເປັນທາງການກຽມໄວ້ໃຫ້, ພະນັກງານໃນພາກສະໜາມກໍຈະຊອກຫາເຄື່ອງມືດ້ວຍຕົນເອງ.
ໃນທີ່ນີ້, ພວກເຮົາຈະມາເບິ່ງໂຄງສ້າງທີ່ເຮັດໃຫ້ເກີດ Shadow AI ໂດຍພິຈາລະນາຈາກທັງແຮງຈູງໃຈຂອງພາກສະໜາມ ແລະ ຂໍ້ບົກຜ່ອງຂອງຝ່າຍອົງກອນ.
ສາເຫດທີ່ເຮັດໃຫ້ເກີດ Shadow AI ສາມາດແບ່ງອອກໄດ້ເປັນ 3 ປະການໃຫຍ່ໆ:
ປະການທຳອິດ, ຄວາມສະດວກສະບາຍ. ເຄື່ອງມື AI ຈຳນວນຫຼາຍສາມາດເລີ່ມໃຊ້ງານໄດ້ພາຍໃນເວລາບໍ່ເທົ່າໃດນາທີຜ່ານທາງບຣາວເຊີ ຫຼື ແອັບພລິເຄຊັນທີ່ມີຢູ່ແລ້ວ ໂດຍບໍ່ຈຳເປັນຕ້ອງຕິດຕັ້ງ ຫຼື ຍື່ນຄຳຮ້ອງຂໍໃດໆ.
ປະການທີສອງ, ຄວາມວ່ອງໄວໃນການເຫັນຜົນ. ເມື່ອພະນັກງານຮູ້ສຶກໄດ້ວ່າ AI ຊ່ວຍໃຫ້ການຂຽນອີເມວ, ການສະຫຼຸບກອງປະຊຸມ ຫຼື ການວິເຄາະຕາຕະລາງຄຳນວນໄວຂຶ້ນຢ່າງເຫັນໄດ້ຊັດ, ການຂໍອະນຸມັດ ຫຼື ການກວດສອບນະໂຍບາຍຕ່າງໆຈະກາຍເປັນ "ຂັ້ນຕອນທີ່ລໍຖ້າດົນ" ໃນສາຍຕາຂອງພວກເຂົາ.
ປະການທີສາມ, ການຂາດທາງເລືອກທີ່ເປັນທາງການ. ຖ້າອົງກອນບໍ່ໄດ້ກຽມທາງເລືອກໄວ້ວ່າ "ວຽກນີ້ສາມາດໃຊ້ເຄື່ອງມືນີ້ໄດ້", ພະນັກງານກໍຈະຊອກຫາວິທີການດ້ວຍຕົນເອງເພື່ອຈັດການກັບວຽກທີ່ຢູ່ຕໍ່ໜ້າ.
ໃນການສຶກສາຄັ້ງໜຶ່ງທີ່ IBM ໄດ້ອ້າງອີງ, ພະນັກງານອອຟຟິດໃນສະຫະລັດອາເມຣິກາປະມານ 80% ໃຊ້ AI ໃນການເຮັດວຽກ, ໃນຂະນະທີ່ມີພຽງ 22% ເທົ່ານັ້ນທີ່ໃຊ້ສະເພາະເຄື່ອງມືທີ່ບໍລິສັດກຳນົດໃຫ້ (IBM "Is rising AI adoption creating shadow AI risks?"). ເຊັ່ນດຽວກັນກັບການສຳຫຼວດຂອງ IDC ໃນປີ 2025 ທີ່ລາຍງານວ່າ ພະນັກງານ 56% ໃຊ້ເຄື່ອງມື AI ທີ່ບໍ່ໄດ້ຮັບການອະນຸມັດໃນບ່ອນເຮັດວຽກ, ໃນຂະນະທີ່ມີພຽງ 23% ເທົ່ານັ້ນທີ່ໃຊ້ເຄື່ອງມືທີ່ອົງກອນຈັດຫາໃຫ້ ແລະ ຄວບຄຸມ. ໂດຍບໍ່ຕ້ອງສົນໃຈລາຍລະອຽດຂອງຕົວເລກ, ແນວໂນ້ມແມ່ນຈະແຈ້ງວ່າ—ຕາບໃດທີ່ເສັ້ນທາງການໃຊ້ AI ຢ່າງເປັນທາງການຍັງບໍ່ພ້ອມ, ຜູ້ຄົນກໍຈະສ້າງເສັ້ນທາງຂອງຕົນເອງຂຶ້ນມາ.
ອີກໜຶ່ງຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ຂອງ Shadow AI ຄືມັນບໍ່ໄດ້ແຜ່ຂະຫຍາຍໃນຖານະ "ໂຄງການນຳໃຊ້" ຂອງພະແນກ IT, ແຕ່ເປັນການກະທຳຂອງພະນັກງານແຕ່ລະຄົນ. ການໃຫ້ AI ສະຫຼຸບເອກະສານນຳສະເໜີ, ການໃຫ້ AI ແກ້ໄຂໂຄ້ດ, ການໃຫ້ AI ຮ່າງສັນຍາ—ການກະທຳເຫຼົ່ານີ້ໄດ້ກາຍເປັນເລື່ອງປົກກະຕິໄປແລ້ວ ກ່ອນທີ່ຈະມີໃຜອະນຸຍາດເສຍອີກ.
Microsoft ໄດ້ກ່າວເຖິງສະຖານະການນີ້ວ່າ ຫຼາຍອົງກອນມັກຈະບໍ່ສາມາດຮັບຮູ້ໄດ້ເລີຍວ່າ "ແອັບ AI ໃດ, ໃຜເປັນຜູ້ໃຊ້ ແລະ ຖືກນຳໃຊ້ແນວໃດ", ດັ່ງນັ້ນຈຸດເລີ່ມຕົ້ນຂອງມາດຕະການຄວນຈະເປັນ "ການຄົ້ນພົບ (discover)" ບໍ່ແມ່ນ "ການຫ້າມ". ໃນຄວາມເປັນຈິງ, Microsoft ໄດ້ເພີ່ມຟັງຊັນ "Shadow AI" (ສະບັບພີວິວ) ເຂົ້າໃນສູນບໍລິຫານຈັດການ Microsoft 365 ເພື່ອໃຫ້ຜູ້ເບິ່ງແຍງລະບົບສາມາດຮັບຮູ້ເຖິງ AI Agent ທີ່ບໍ່ໄດ້ຮັບການຄວບຄຸມເຊິ່ງຖືກນຳໃຊ້ພາຍໃນອົງກອນໄດ້.
ຖ້າເບິ່ງອີກດ້ານໜຶ່ງ, ຫຼາຍອົງກອນເລີ່ມຕົ້ນຈາກສະພາວະທີ່ "ບໍ່ຮູ້ວ່າເກີດຫຍັງຂຶ້ນ". ເຊິ່ງການຄິດວ່າເປັນຜົນມາຈາກຄວາມໄວໃນການນຳໃຊ້ AI ທີ່ແລ່ນນຳໜ້າການວາງລະບົບທຳນຽມການປົກຄອງ (Governance) ຈະກົງກັບຄວາມເປັນຈິງຫຼາຍກວ່າການຄິດວ່າເປັນຍ້ອນການຂາດການບໍລິຫານຈັດການ.
ອັນຕະລາຍຂອງ Shadow AI ບໍ່ໄດ້ຢຸດຢູ່ພຽງແຕ່ "ການນຳໃຊ້ເຄື່ອງມືທີ່ບໍ່ໄດ້ຮັບອະນຸຍາດ" ເທົ່ານັ້ນ. ຄວາມສ່ຽງຈະເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ ໃນ 5 ຊັ້ນ ຄື: ການຮົ່ວໄຫຼຂອງຂໍ້ມູນ, ການຂາດການເບິ່ງເຫັນ, ການລະເມີດກົດລະບຽບ, ຜົນລັດຈາກ AI ທີ່ຍັງບໍ່ໄດ້ຜ່ານການກວດສອບ, ແລະ ການຂະຫຍາຍຕົວໄປສູ່ Shadow Data ແລະ Shadow Model.
ເຮົາມາເບິ່ງໄປພ້ອມກັນຕາມລຳດັບ.
ອັນຕະລາຍທີ່ກົງໄປກົງມາທີ່ສຸດຄືການຮົ່ວໄຫຼຂອງຂໍ້ມູນ. ເມື່ອພະນັກງານປ້ອນຂໍ້ມູນພາຍໃນບໍລິສັດເຂົ້າໄປໃນເຄື່ອງມື AI ສາທາລະນະ, ຂໍ້ມູນນັ້ນຈະຫຼຸດອອກຈາກຂອບເຂດການຄວບຄຸມຂອງອົງກອນ. IBM ຊີ້ໃຫ້ເຫັນວ່າ ຂໍ້ມູນທາງການເງິນ, ຄວາມລັບທາງການຄ້າ, ຊໍສ໌ໂຄດ (Source code) ທີ່ເປັນເອກະລັກ ແລະ ອີເມວທຸລະກິດທີ່ມີຄວາມລະອຽດອ່ອນ ອາດຖືກປ້ອນເຂົ້າໄປໃນ LLM ທີ່ເປີດຕົວ ຫຼື Launch ແລະ ອາດຖືກເກັບຮັກສາໄວ້ ຫຼື ນຳໄປໃຊ້ເພື່ອຈຸດປະສົງອື່ນ.
ສິ່ງທີ່ສຳຄັນໃນທີ່ນີ້ຄື ຄວາມສ່ຽງບໍ່ໄດ້ຢຸດຢູ່ພຽງແຕ່ລະດັບ "ຄົນໜຶ່ງຄົນໃຊ້ເຄື່ອງມືຜິດພາດ" ເທົ່ານັ້ນ. ຖ້າຂໍ້ມູນລູກຄ້າ, ຂໍ້ມູນທາງການເງິນ ແລະ ຊໍສ໌ໂຄດຮົ່ວໄຫຼຜ່ານແອັບ AI ທີ່ບໍ່ໄດ້ຮັບການອະນຸມັດ, ຜົນກະທົບຈະລາມໄປເຖິງເລື່ອງການປະຕິບັດຕາມກົດລະບຽບ (Compliance), ພັນທະຕາມສັນຍາ ແລະ ເຫດການລະເມີດຄວາມເປັນສ່ວນຕົວ.
ໃນຄວາມເປັນຈິງ, ການສຶກສາຂອງ IBM ລາຍງານວ່າ ການລະເມີດຂໍ້ມູນທີ່ກ່ຽວຂ້ອງກັບ Shadow AI ມີຕົ້ນທຶນສະເລ່ຍສູງກວ່າການລະເມີດໃນຮູບແບບອື່ນ ແລະ 1 ໃນ 5 ບໍລິສັດໄດ້ປະສົບກັບການລະເມີດທີ່ກ່ຽວຂ້ອງກັບ Shadow AI ແລ້ວ (IBM "2025 Cost of a Data Breach Report"). ການວາງຂໍ້ມູນພຽງຄັ້ງດຽວ ກາຍເປັນໂຄງສ້າງທີ່ສົ່ງຜົນໃຫ້ມີລາຄາທີ່ຕ້ອງຈ່າຍສູງໃນຈຸດທີ່ເຮົາເບິ່ງບໍ່ເຫັນ.
Shadow AI ທີ່ເປັນອັນຕະລາຍນັ້ນ ກໍຍ້ອນວ່າມັນຢູ່ "ນອກເໜືອຈາກການເບິ່ງເຫັນ". ຖ້າພະແນກ IT ບໍ່ຮູ້ວ່າພະນັກງານກຳລັງໃຊ້ແອັບ AI ຕົວໃດຢູ່, ກໍບໍ່ສາມາດອອກແບບການຈຳກັດການເຂົ້າເຖິງ, ການປ້ອງກັນການສູນເສຍຂໍ້ມູນ (DLP) ຫຼື ການກວດສອບໄດ້. ສິ່ງທີ່ຄວນປົກປ້ອງນັ້ນ ກຳລັງເຄື່ອນໄຫວຢູ່ໃນບ່ອນທີ່ເບິ່ງບໍ່ເຫັນ.
ໃນດ້ານການປະຕິບັດຕາມກົດລະບຽບ (Compliance) ກໍມີບັນຫາທີ່ເລິກເຊິ່ງ. ຫຼາຍອົງກອນມີນະໂຍບາຍກ່ຽວກັບບ່ອນຈັດເກັບຂໍ້ມູນ (Data Residency), ຄວາມເປັນສ່ວນຕົວ, ການຮັກສາບັນທຶກ, ການຮັກສາຄວາມລັບ ແລະ ລະບຽບການສະເພາະຂອງອຸດສາຫະກຳຢູ່ແລ້ວ. ແຕ່ເມື່ອ Shadow AI ເກີດຂຶ້ນ, ພະນັກງານຈະປະມວນຜົນຂໍ້ມູນຜ່ານຊ່ອງທາງທີ່ນະໂຍບາຍເຫຼົ່ານັ້ນບໍ່ສາມາດຄວບຄຸມໄດ້. ທັງ IBM ແລະ Microsoft ຕ່າງກໍຊີ້ໃຫ້ເຫັນວ່າ Shadow AI ເປັນບັນຫາທີ່ສົ່ງຜົນໂດຍກົງຕໍ່ການປະຕິບັດຕາມກົດລະບຽບ, ເພາະແອັບທີ່ອົງກອນບໍ່ເຄີຍປະເມີນມາກ່ອນຈະເຂົ້າມາຈັດການກັບຂໍ້ມູນທີ່ຢູ່ພາຍໃຕ້ການຄວບຄຸມ.
ເຖິງແມ່ນວ່າ SaaS ແລະ ຄລາວແອັບທີ່ມີຢູ່ຈະສາມາດຄວບຄຸມໄດ້, ແຕ່ AI ຮູບແບບໃໝ່ໆ ເຊັ່ນ: ສ່ວນເສີມຂອງບຣາວເຊີ (Browser Extension), ເອເຈນແບບ Standalone, ສະພາບແວດລ້ອມການເຮັດວຽກຂອງໂມເດວແບບທ້ອງຖິ່ນ ແລະ API Wrapper ຕ່າງກໍລັກລອບເຂົ້າມາຈາກຈຸດທີ່ນະໂຍບາຍແບບດັ້ງເດີມຄາດບໍ່ເຖິງ. ຖ້າບໍ່ຂະຫຍາຍການບໍລິຫານຈັດການໃຫ້ທັນກັບຄວາມໄວໃນການແຜ່ຫຼາຍຂອງ AI, ການລະເມີດນະໂຍບາຍກໍຈະເກີດຂຶ້ນໄດ້ງ່າຍຂຶ້ນ.
ຄວາມສ່ຽງຂອງ Shadow AI ບໍ່ໄດ້ມີພຽງແຕ່ "ການປ້ອນຂໍ້ມູນ" ເທົ່ານັ້ນ ແຕ່ຍັງລວມເຖິງ "ຜົນລັພ" ອີກດ້ວຍ. ຖ້າພະນັກງານໃຫ້ AI ສ້າງບົດລາຍງານ, ສະຫຼຸບສັນຍາ, ສະເໜີໂຄ້ດ, ຂໍ້ຄວາມຕອບໂຕ້ລູກຄ້າ, ຫຼື ຜົນການວິເຄາະ ແລ້ວນຳໄປໃຊ້ໂດຍບໍ່ຜ່ານຂະບວນການເຮັດວຽກທີ່ໄດ້ຮັບການອະນຸມັດ ຫຼື ການກວດສອບຈາກມະນຸດ, ຄວາມຜິດພາດຂອງ AI ກໍຈະປົນເຂົ້າໄປໃນຂະບວນການເຮັດວຽກໂດຍກົງ.
ສິ່ງທີ່ຫຍຸ້ງຍາກກໍຄື ຄວາມຜິດພາດເຫຼົ່ານັ້ນບໍ່ໄດ້ຖືກຮັບຮູ້ວ່າເປັນ "ຄວາມສ່ຽງຂອງ AI". ເນື່ອງຈາກຜູ້ກວດສອບບໍ່ມີບັນທຶກວ່າຜົນລັພຈາກ AI ຖືກນຳໄປໃຊ້ໃນຂັ້ນຕອນໃດ, ຄວາມຜິດພາດຂອງ AI ຈຶ່ງຖືກຈັດການວ່າເປັນ "ຄວາມຜິດພາດທົ່ວໄປຂອງມະນຸດ". ເຮັດໃຫ້ສາເຫດທີ່ມາຈາກການໃຊ້ AI ທີ່ບໍ່ໄດ້ຮັບການອະນຸມັດນັ້ນຖືກປົກປິດໄວ້.
ຍິ່ງໄປກວ່ານັ້ນ, IBM ໄດ້ຊີ້ໃຫ້ເຫັນວ່າ Shadow AI ບໍ່ໄດ້ເກີດຂຶ້ນຢ່າງໂດດດ່ຽວ, ແຕ່ມັນຈະເຕີບໂຕໄປພ້ອມກັບ "Shadow Data" ແລະ "Shadow Model". ຂໍ້ມູນທີ່ບໍ່ໄດ້ຜ່ານການກວດສອບ, ຊຸດຂໍ້ມູນຈາກພາກສ່ວນທີສາມທີ່ບໍ່ຮູ້ທີ່ມາ, ແລະ ໂມເດວທີ່ບໍ່ມີໃຜຮູ້ຈັກຕົ້ນກຳເນີດ ສາມາດມາຢູ່ລວມກັນໃນຂະບວນການເຮັດວຽກດຽວກັນໄດ້. ເມື່ອເປັນແບບນີ້, ຄວາມສ່ຽງຈະຂະຫຍາຍຕົວຈາກລະດັບແອັບພລິເຄຊັນ ໄປສູ່ລະດັບຕ່ອງໂສ້ການສະໜອງຂໍ້ມູນ (Data Supply Chain) ແລະ ຕ່ອງໂສ້ການສະໜອງໂມເດວ (Model Supply Chain). ມັນຈະກາຍເປັນຄວາມສ່ຽງທາງລະບົບ ທີ່ບໍ່ໄດ້ຖາມພຽງແຕ່ວ່າ "ໃຜໃຊ້ແອັບໃດ" ແຕ່ຍັງຖາມເຖິງ "ຂໍ້ມູນໃດ, ຖືກນຳໄປໃຊ້ຢູ່ໃສ, ແລະ ໃຊ້ກັບໂມເດວໃດ".
ວິທີການຮັບມືກັບ Shadow AI ທີ່ຖືກຕ້ອງ ບໍ່ແມ່ນການ "ສັ່ງຫ້າມໃຊ້ AI ຢ່າງເດັດຂາດ". ແຕ່ແມ່ນການຈັດຫາຊ່ອງທາງທີ່ເປັນທາງການໃຫ້ພະນັກງານສາມາດໃຊ້ AI ໄດ້ຢ່າງປອດໄພ, ພ້ອມທັງຈັດລະບຽບການເບິ່ງເຫັນພາບລວມ, ການຄວບຄຸມ ແລະ ການບໍລິຫານຈັດການເປັນຂັ້ນເປັນຕອນ.
ໃນທີ່ນີ້, ພວກເຮົາຈະມາສະຫຼຸບວ່າໃນທາງປະຕິບັດນັ້ນ ຄວນເລີ່ມຕົ້ນຈາກບ່ອນໃດ.
Microsoft ແນະນຳໃຫ້ດຳເນີນການຮັບມືກັບ Shadow AI ດ້ວຍວິທີການແບບເປັນຂັ້ນຕອນ. ໃນຄຳແນະນຳ "Prevent data leak to shadow AI" ໄດ້ລະບຸໄວ້ 4 ໄລຍະ ດັ່ງນີ້:
| ໄລຍະ | ເນື້ອຫາ |
|---|---|
| 1. ຄົ້ນຫາ (Discover) | ເຂົ້າໃຈວ່າພາຍໃນອົງກອນມີແອັບ AI ໃດແດ່, ໃຜເປັນຜູ້ໃຊ້ ແລະ ໃຊ້ງານແນວໃດ |
| 2. ສະກັດກັ້ນ (Block) | ຈຳກັດການເຂົ້າເຖິງແອັບ AI ທີ່ບໍ່ໄດ້ຮັບການອະນຸມັດ |
| 3. ການປົກປ້ອງຂໍ້ມູນ | ປ້ອງກັນບໍ່ໃຫ້ຂໍ້ມູນລະອຽດອ່ອນຮົ່ວໄຫຼໄປຍັງແອັບທີ່ໄດ້ຮັບການອະນຸມັດ ໂດຍໃຊ້ DLP ແລະ ການຕິດປ້າຍກຳກັບຄວາມລັບ |
| 4. ການກຳກັບດູແລ (Govern) | ຄວບຄຸມຂໍ້ມູນທີ່ຖືກສົ່ງໄປຍັງ AI ຢ່າງຕໍ່ເນື່ອງ |
ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ຄືການບໍ່ເລີ່ມຕົ້ນດ້ວຍການ "ສະກັດກັ້ນ" ທັນທີ. ຖ້າຫາກສັ່ງຫ້າມໂດຍທີ່ບໍ່ຮູ້ວ່າກຳລັງມີການໃຊ້ງານຫຍັງຢູ່, ການໃຊ້ງານນັ້ນກໍຈະຍ້າຍໄປຜ່ານຊ່ອງທາງອື່ນແທນ. ການເລີ່ມຕົ້ນຈາກການຄົ້ນຫາ, ຈາກນັ້ນຈຶ່ງແຍກປະເພດ "ແອັບທີ່ໃຊ້ໄດ້ / ແອັບທີ່ໃຊ້ບໍ່ໄດ້", ຈັດໝວດໝູ່ຂໍ້ມູນລະອຽດອ່ອນເພື່ອຄວບຄຸມ, ແລະ ສຸດທ້າຍແມ່ນສ້າງການກຳກັບດູແລເພື່ອໃຫ້ການດຳເນີນງານໄປຕໍ່ໄດ້—ລຳດັບນີ້ຖືວ່າເປັນຄວາມເປັນຈິງທີ່ສຸດ.
NIST AI Risk Management Framework (AI RMF) ແລະ ຄຳແນະນຳດ້ານຄວາມປອດໄພ AI ຂອງ CISA ກໍໄດ້ກະຕຸ້ນໃຫ້ເບິ່ງ AI ບໍ່ແມ່ນ "ບັນຫາຂອງແອັບໃດແອັບໜຶ່ງ" ແຕ່ເປັນ "ຄວາມສ່ຽງຂອງລະບົບທັງໝົດ". ເປັນແນວຄິດທີ່ບໍລິຫານຈັດການຄວາມໜ້າເຊື່ອຖື, ຄວາມປອດໄພ, ຄວາມເປັນສ່ວນຕົວ, ຄວາມໂປ່ງໃສ ແລະ ຄວາມຮັບຜິດຊອບໄປພ້ອມໆກັນ. ເມື່ອນຳໄປປະຕິບັດຕົວຈິງ, ຈະຕ້ອງມີການຈັດຕັ້ງການກຳກັບດູແລຂໍ້ມູນ, ການຄວບຄຸມການເຂົ້າເຖິງ, ການຕິດຕາມກວດກາ, ການກວດສອບໂດຍມະນຸດ ແລະ ການແບ່ງຄວາມຮັບຜິດຊອບທີ່ຊັດເຈນໃຫ້ຄົບຊຸດ. Shadow AI ບໍ່ສາມາດແກ້ໄຂໄດ້ດ້ວຍເຄື່ອງມືຄວາມປອດໄພພຽງຢ່າງດຽວ, ແຕ່ຈະແກ້ໄຂໄດ້ກໍຕໍ່ເມື່ອມີການດຳເນີນນະໂຍບາຍ, ຂະບວນການເຮັດວຽກ (Workflow) ແລະ ການບໍລິຫານຈັດການການປ່ຽນແປງ (Change Management) ໄປພ້ອມໆກັນເທົ່ານັ້ນ.
ຫຼາຍອົງກອນມັກເບິ່ງຂ້າມຈຸດທີ່ວ່າ ການ "ຫ້າມ" ພຽງຢ່າງດຽວບໍ່ສາມາດເຮັດໃຫ້ Shadow AI ໝົດໄປໄດ້. ຖ້າເຄື່ອງມືທີ່ໄດ້ຮັບການອະນຸມັດບໍ່ສາມາດຊ່ວຍວຽກໜ້າງານໄດ້, ພະນັກງານກໍຍັງຈະໃຊ້ເຄື່ອງມືພາຍນອກຢູ່ດີ. ດັ່ງນັ້ນ, ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ຂອງການແກ້ໄຂບັນຫາຈຶ່ງຢູ່ທີ່ການກຽມ "ເສັ້ນທາງທີ່ປອດໄພ ແລະ ຖືກຕ້ອງ (sanctioned path)" ໃຫ້ພະນັກງານໄດ້ນຳໃຊ້.
ໃນທາງປະຕິບັດ, ອົງກອນຄວນດຳເນີນການຢ່າງໜ້ອຍ 4 ຢ່າງດັ່ງນີ້:
ສິ່ງທີ່ຢາກເນັ້ນຢ້ຳໃນທີ່ນີ້ແມ່ນ Shadow AI ບໍ່ໄດ້ເກີດຈາກ "ຄວາມຜິດຂອງໜ້າງານ". ມັນເປັນສັນຍານຈາກອົງກອນທີ່ບົ່ງບອກວ່າ ຄວາມໄວໃນການນຳ AI ມາໃຊ້ໄດ້ແລ່ນນຳໜ້າການກຳກັບດູແລ (Governance) ໄປແລ້ວ. ສິ່ງທີ່ຖືກຕັ້ງຄຳຖາມຄື ອົງກອນຈະສາມາດກຽມເສັ້ນທາງທີ່ຖືກຕ້ອງເພື່ອໃຫ້ໜ້າງານບໍ່ຈຳເປັນຕ້ອງເພິ່ງພາເຄື່ອງມືພາຍນອກໄດ້ໄວສ່ຳໃດ.
Q. Shadow AI ແລະ Shadow IT ແຕກຕ່າງກັນແນວໃດ?
Shadow AI ແມ່ນຮູບແບບໜຶ່ງຂອງ Shadow IT, ແຕ່ເຄື່ອງມື AI ບໍ່ພຽງແຕ່ເກັບຮັກສາຂໍ້ມູນເທົ່ານັ້ນ, ຫາກຍັງເຮັດໜ້າທີ່ສະຫຼຸບ, ວິເຄາະ, ສ້າງຂໍ້ຄວາມ ແລະ ເຊື່ອມຕໍ່ກັບພາຍນອກອີກດ້ວຍ. ດ້ວຍເຫດນີ້, ຜົນກະທົບຕໍ່ຄວາມປອດໄພຂອງຂໍ້ມູນ, ການປະຕິບັດຕາມກົດລະບຽບ (Compliance) ແລະ ຊື່ສຽງຂອງອົງກອນ ຈຶ່ງມີຄວາມຮຸນແຮງກວ່າການໃຊ້ຊອບແວທົ່ວໄປ. IBM ກໍໄດ້ຊີ້ໃຫ້ເຫັນວ່າ Shadow AI ເປັນສ່ວນໜຶ່ງຂອງ Shadow IT, ແຕ່ສ້າງຄວາມເສຍຫາຍໄດ້ໜັກໜ່ວງກວ່າ.
Q. ເມື່ອອົງກອນຕ້ອງການຄວບຄຸມ Shadow AI, ຄວນເລີ່ມຕົ້ນຈາກຫຍັງກ່ອນ?
ສິ່ງທີ່ຄວນເຮັດອັນດັບທຳອິດຄື "ການຄົ້ນຫາ (Discover)". ຕ້ອງກວດສອບໃຫ້ຮູ້ວ່າແອັບ AI ໃດທີ່ຖືກນຳມາໃຊ້ງານຕົວຈິງ, ຈາກນັ້ນຈຶ່ງແຍກປະເພດວ່າໄດ້ຮັບການອະນຸມັດ ຫຼື ບໍ່, ຄວບຄຸມຂໍ້ມູນດ້ວຍ DLP ແລະ ຈັດຕັ້ງຂະບວນການເຮັດວຽກທີ່ເປັນທາງການໃຫ້ພະນັກງານສາມາດນຳໃຊ້ໄດ້. ແນວທາງການດຳເນີນງານເປັນຂັ້ນຕອນທີ່ Microsoft ແນະນຳກໍມີລຳດັບແບບນີ້ເຊັ່ນກັນ. ຖ້າຫາກເລີ່ມຕົ້ນດ້ວຍການປິດກັ້ນທັນທີ, ຜູ້ໃຊ້ງານມັກຈະຍ້າຍໄປໃຊ້ຊ່ອງທາງອື່ນທີ່ບໍ່ສາມາດກວດສອບໄດ້.
Q. ການສັ່ງຫ້າມໃຊ້ AI ທັງໝົດຈະຊ່ວຍແກ້ໄຂບັນຫາໄດ້ບໍ?
ໂດຍພື້ນຖານແລ້ວ, ມັນບໍ່ແມ່ນວິທີແກ້ໄຂທີ່ມີປະສິດທິຜົນ. ຖ້າເຄື່ອງມືທີ່ໄດ້ຮັບການອະນຸມັດບໍ່ຕອບໂຈດການເຮັດວຽກຕົວຈິງ, ພະນັກງານກໍຈະຍັງຄົງໃຊ້ເຄື່ອງມືຈາກພາຍນອກຕໍ່ໄປ. ສິ່ງທີ່ມີປະສິດທິຜົນກວ່າຄື ການກຽມທາງເລືອກທີ່ປອດໄພ (Sanctioned alternatives) ແລະ ການວາງລະບົບການບໍລິຫານຈັດການ (Governance) ທີ່ສອດຄ່ອງກັບການເຮັດວຽກຕົວຈິງ.

Shadow AI ບໍ່ແມ່ນພຽງແຕ່ເລື່ອງຂອງ "ພະນັກງານລັກໃຊ້ AI Chat" ເທົ່ານັ້ນ. ມັນເປັນສັນຍານທີ່ສະແດງໃຫ້ເຫັນວ່າການນຳໃຊ້ AI ພວມກ້າວໜ້າໄປໄວກວ່າການບໍລິຫານຈັດການຂອງອົງກອນ. ຄວາມສ່ຽງຫຼັກສາມາດສະຫຼຸບໄດ້ 5 ປະການຄື: ການຮົ່ວໄຫຼຂອງຂໍ້ມູນ, ການຂາດການເບິ່ງເຫັນ, ການລະເມີດກົດລະບຽບ, ຜົນລັດຈາກ AI ທີ່ຍັງບໍ່ໄດ້ຜ່ານການກວດສອບ, ແລະການຂະຫຍາຍຕົວໄປສູ່ Shadow Data ແລະ Shadow Model.
IBM, Microsoft, NIST, ແລະ CISA ລ້ວນແຕ່ຊີ້ໄປໃນທິດທາງດຽວກັນ ຄືທາງອອກບໍ່ແມ່ນ "ການຫ້າມທຸກຢ່າງ" ແຕ່ແມ່ນການສ້າງການເບິ່ງເຫັນ, ນະໂຍບາຍ, ທາງເລືອກທີ່ປອດໄພ, ແລະການສ້າງການບໍລິຫານຈັດການທີ່ສາມາດນຳໃຊ້ໄດ້ຈິງ.
ຄຳຖາມທີ່ຖືກຕ້ອງສຳລັບອົງກອນບໍ່ແມ່ນ "ຈະຫ້າມ AI ໄດ້ຫຼືບໍ່" ແຕ່ແມ່ນ "ຈະເຮັດແນວໃດໃຫ້ພະນັກງານສາມາດໃຊ້ AI ໄດ້ໂດຍບໍ່ເຮັດໃຫ້ຂໍ້ມູນ ແລະ ຄວາມສ່ຽງຫຼຸດອອກໄປນອກອົງກອນ". ເມື່ອສາມາດຕອບຄຳຖາມນີ້ໄດ້ຢ່າງຊັດເຈນ, Shadow AI ຈະປ່ຽນຈາກຄວາມສ່ຽງ ໄປສູ່ການນຳໃຊ້ AI ທີ່ຖືກຄວບຄຸມ.
ເອກະສານອ້າງອີງ
(ບົດຄວາມນີ້ມີຈຸດປະສົງເພື່ອໃຫ້ຂໍ້ມູນທົ່ວໄປເທົ່ານັ້ນ, ກະລຸນາກວດສອບມາດຕະຖານ ຫຼື Specification ຂອງຜະລິດຕະພັນ, ສະຖິຕິ, ແລະ ທິດທາງການກຳກັບດູແລຫຼ້າສຸດໄດ້ຈາກແຫຼ່ງຂໍ້ມູນຕົ້ນສະບັບ. ຕົວເລກການສຳຫຼວດທີ່ລະບຸໄວ້ແມ່ນອີງຕາມຄ່າທີ່ປະກາດໂດຍແຫຼ່ງອ້າງອີງ.)
Chi
ສຳເລັດການສຶກສາສາຂາວິທະຍາສາດຄອມພິວເຕີ (Information Science) ຈາກມະຫາວິທະຍາໄລແຫ່ງຊາດລາວ ໂດຍໃນລະຫວ່າງການສຶກສາມີສ່ວນຮ່ວມໃນການພັດທະນາຊອບແວສະຖິຕິ (Statistical Software) ຈາກປະສົບການຕົວຈິງ ຈຶ່ງໄດ້ສ້າງພື້ນຖານດ້ານການວິເຄາະຂໍ້ມູນ (Data Analysis) ແລະ ການໂປຣແກຣມມິງ (Programming) ຢ່າງເຂັ້ມແຂງ. ຕັ້ງແຕ່ປີ 2021 ໄດ້ກ້າວເຂົ້າສູ່ເສັ້ນທາງການພັດທະນາ Web ແລະ ແອັບພລິເຄຊັນ (Application) ແລະ ຕັ້ງແຕ່ປີ 2023 ເປັນຕົ້ນມາ ໄດ້ສັ່ງສົມປະສົບການພັດທະນາຢ່າງເຕັມຮູບແບບທັງໃນດ້ານ Frontend ແລະ Backend. ໃນບໍລິສັດ ຮັບຜິດຊອບການອອກແບບ ແລະ ພັດທະນາ Web Service ທີ່ນຳໃຊ້ AI ພ້ອມທັງມີສ່ວນຮ່ວມໃນໂຄງການທີ່ປະສົມປະສານ ການປະມວນຜົນພາສາທຳມະຊາດ (NLP: Natural Language Processing), ການຮຽນຮູ້ຂອງເຄື່ອງ (Machine Learning), Generative AI ແລະ ໂມເດນພາສາຂະໜາດໃຫຍ່ (LLM: Large Language Model) ເຂົ້າກັບລະບົບທຸລະກິດ. ມີຄວາມກະຕືລືລົ້ນໃນການຕິດຕາມເທັກໂນໂລຊີໃໝ່ລ່າສຸດຢູ່ສະເໝີ ແລະ ໃຫ້ຄວາມສຳຄັນກັບຄວາມວ່ອງໄວໃນທຸກຂັ້ນຕອນ ຕັ້ງແຕ່ການທົດສອບດ້ານເທັກນິກ ຈົນເຖິງການນຳໄປໃຊ້ງານຈິງໃນລະບົບ Production.