AI ກາເວີແນນ (AI Governance) ໃນອົງກອນ BPO ແບບປະສົມ (Hybrid) ແມ່ນໂຄງສ້າງການບໍລິຫານທີ່ກຳນົດສິດອຳນາດໃນການຕັດສິນໃຈ, ຄວາມຮັບຜິດຊອບ ແລະ ເສັ້ນທາງການກວດສອບກ່ຽວກັບການນຳໃຊ້ AI ຢ່າງຈະແຈ້ງ ໃນລະບົບ BPO ທີ່ພະນັກງານທີ່ເປັນມະນຸດ ແລະ AI ເຮັດວຽກຮ່ວມກັນ.

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

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

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

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

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

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

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

NIST AI Risk Management Framework (AI RMF 1.0, ເປີດຕົວ ຫຼື Launch ໃນວັນທີ 26 ມັງກອນ 2023) ໄດ້ແນະນຳໃຫ້ມີການກຳນົດບົດບາດຂອງ "ການກວດສອບໂດຍມະນຸດ (Human Oversight)" ໃຫ້ຊັດເຈນໃນການຮັບປະກັນຄວາມໜ້າເຊື່ອຖືຂອງລະບົບ AI. ຈາກທັດສະນະນີ້, ການບັນທຶກ "ຂອບເຂດທີ່ AI ຕັດສິນໃຈ" ແລະ "ຂອບເຂດທີ່ມະນຸດຕັດສິນໃຈ" ໄວ້ເປັນເອກະສານໃນຂັ້ນຕອນການອອກແບບຂະບວນການເຮັດວຽກ (Workflow) ຈຶ່ງເປັນສິ່ງທີ່ຂາດບໍ່ໄດ້.

ໃນລະບົບ Hybrid BPO, ຜູ້ວ່າຈ້າງ, ຜູ້ຮັບຈ້າງ ແລະ ຜູ້ສະໜອງ AI ທັງສາມຝ່າຍຈະມີສ່ວນຮ່ວມໃນຂະບວນການເຮັດວຽກດຽວກັນ ເຊິ່ງເຮັດໃຫ້ຄວາມຮັບຜິດຊອບມີໂອກາດກະຈັດກະຈາຍທາງໂຄງສ້າງໄດ້ງ່າຍ.

ຄວາມສ່ຽງຫຼັກທີ່ເກີດຈາກຄວາມສຳພັນຂອງທັງສາມຝ່າຍມີດັ່ງນີ້:

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

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

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

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

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

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

ບັນຫາຫຼັກໆມີດັ່ງນີ້:

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

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

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

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

ແກນຫຼັກຂອງການເຮັດ Mapping

ຈັດປະເພດວຽກງານໂດຍໃຊ້ 2 ແກນ ຄື: ລະດັບການເພິ່ງພາ AI ແລະ ລະດັບການມີສ່ວນຮ່ວມຂອງມະນຸດ.

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

ຂັ້ນຕອນການປະຕິບັດ Mapping

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

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

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

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

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

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

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

ມາດຕະຖານສາກົນ ແລະ ລະດັບໂລກ

• NIST AI RMF 1.0 (ເປີດຕົວ ຫຼື Launch ໃນວັນທີ 26 ມັງກອນ 2023): ເຟຣມເວີກທີ່ຈັດລະບົບການລະບຸ, ການປະເມີນ ແລະ ການຮັບມືກັບຄວາມສ່ຽງດ້ານ AI ເຊິ່ງສາມາດໃຊ້ເປັນມາດຕະຖານການຈັດການຄວາມສ່ຽງເມື່ອມີການນຳ AI ເຂົ້າໄປລວມ ຫຼື Merge ໃນວຽກງານ BPO.
• ISO/IEC 42001:2023 (ອອກໃນເດືອນທັນວາ 2023): ມາດຕະຖານສາກົນສຳລັບລະບົບການຈັດການ AI."

ສະຫຼຸບ: ຕາຕະລາງການແບ່ງແຍກຄວາມຮັບຜິດຊອບ (Responsibility Assignment Matrix) ແມ່ນມີຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ໃນການອອກແບບໂດຍການແຍກການຕັດສິນໃຈຂອງ AI ແລະ ການຕັດສິນໃຈຂອງມະນຸດອອກຈາກກັນໃນແຕ່ລະຂະບວນການເຮັດວຽກ, ພ້ອມທັງລະບຸບົດບາດຂອງທັງສາມຝ່າຍໃຫ້ຊັດເຈນຜ່ານຕາຕະລາງ RACI.

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

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

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

• AI ຕັດສິນໃຈດ້ວຍຕົນເອງ (Human-out-of-the-loop): ຂະບວນການທີ່ມີກົດລະບຽບຊັດເຈນ ແລະ ຜົນກະທົບຈາກການຕັດສິນໃຈຜິດພາດມີໜ້ອຍ ເຊັ່ນ: ການກວດສອບຂໍ້ມູນຕາມແບບຟອມ ຫຼື ການກວດສອບຮູບແບບຂໍ້ມູນ.
• AI ຊ່ວຍເຫຼືອ ແລະ ມະນຸດເປັນຜູ້ຕັດສິນໃຈ (Human-in-the-loop): ຂະບວນການທີ່ AI ເຮັດໜ້າທີ່ໃຫ້ຄະແນນ ຫຼື ສະເໜີທາງເລືອກ ແລ້ວໃຫ້ພະນັກງານທີ່ຮັບຜິດຊອບເປັນຜູ້ຕັດສິນໃຈຂັ້ນສຸດທ້າຍ (ຕົວຢ່າງ: ການກວດສອບສິນເຊື່ອໃນຂັ້ນຕອນເລີ່ມຕົ້ນ).
• ມະນຸດຕັດສິນໃຈດ້ວຍຕົນເອງ (Human-only): ຂະບວນການທີ່ມີຜົນກະທົບສູງຫາກເກີດການຕັດສິນໃຈຜິດພາດ ເຊັ່ນ: ການອະນຸມັດທີ່ມີຜົນທາງກົດໝາຍ ຫຼື ການແຈ້ງເຕືອນທີ່ສຳຄັນຕໍ່ລູກຄ້າ.

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

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

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

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

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

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

ຈຸດສຳຄັນໃນການອອກແບບເສັ້ນທາງການແຈ້ງບັນຫາ (Escalation) ມີດັ່ງນີ້:

• ການກຳນົດເງື່ອນໄຂການກະຕຸ້ນ (Trigger conditions): ລະບຸເງື່ອນໄຂທີ່ຈະເລີ່ມຂະບວນການແຈ້ງບັນຫາໃຫ້ຊັດເຈນດ້ວຍຕົວເລກ ຫຼື ສະຖານະ ເຊັ່ນ: ເມື່ອຄະແນນຄວາມເຊື່ອໝັ້ນຂອງ AI ຫຼຸດຕ່ຳກວ່າເກນທີ່ກຳນົດໄວ້ ຫຼື ເມື່ອຈຳນວນການປະມວນຜົນປ່ຽນແປງຢ່າງກະທັນຫັນ.
• ລະດັບການແຈ້ງບັນຫາແບບເປັນຂັ້ນຕອນ: ກຳນົດຂັ້ນຕອນຕາມຄວາມຮຸນແຮງຂອງບັນຫາ ເຊັ່ນ: "ພະນັກງານໜ້າວຽກ → ຫົວໜ້າງານຂອງຜູ້ຮັບເໝົາ → ຜູ້ຮັບຜິດຊອບວຽກງານຂອງຝ່າຍມອບໝາຍ → ລະດັບຜູ້ບໍລິຫານ".
• ການກຳນົດກອບເວລາ (Time-box): ລະບຸໄລຍະເວລາໃນການຕອບໂຕ້ຂອງແຕ່ລະລະດັບໃຫ້ຊັດເຈນ (ຕົວຢ່າງ: ການແຈ້ງບັນຫາຂັ້ນທີ 1 ຕ້ອງດຳເນີນການພາຍໃນ 30 ນາທີຫຼັງຈາກກວດພົບ) ແລະ ກຳນົດກົດລະບຽບການຍົກລະດັບອັດຕະໂນມັດຫາກເກີນກຳນົດເວລາ.
• ຊ່ວງເວລາໃນການມີສ່ວນຮ່ວມຂອງຜູ້ໃຫ້ບໍລິການ AI (AI Vendor): ລະບຸຊ່ວງເວລາທີ່ຈະຕ້ອງຮຽກຕົວຜູ້ໃຫ້ບໍລິການໃນກໍລະນີທີ່ສົງໄສວ່າເກີດຈາກຄວາມຜິດພາດຂອງຕົວແບບ (Model) ເອງ ພ້ອມທັງລະບຸຜູ້ຮັບຜິດຊອບໃນການຕິດຕໍ່ປະສານງານໃຫ້ສອດຄ່ອງກັບສັນຍາ.

ສຳລັບການບັນທຶກຜູ້ຕັດສິນໃຈຂັ້ນສຸດທ້າຍໃຫ້ຊັດເຈນນັ້ນ, ຈຳເປັນຕ້ອງມີການລະບຸໃຫ້ແຈ້ງໃນແຕ່ລະປະເພດວຽກງານວ່າ ລະຫວ່າງຝ່າຍມອບໝາຍ ແລະ ຝ່າຍຮັບເໝົາ "ໃຜເປັນຜູ້ມີອຳນາດໃນການຕັດສິນໃຈຂັ້ນສຸດທ້າຍ (Go/No-go)".

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

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

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

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

ສິ່ງທີ່ຄວນລະບຸໄວ້ໃນສັນຍາຢ່າງຊັດເຈນໃນຖານະພັນທະການແຈ້ງໃຫ້ຊາບ ມີດັ່ງນີ້:

• ປະເພດຂອງການປ່ຽນແປງ: ແບ່ງປະເພດເປັນ Minor Patch (ແກ້ໄຂບັກ) / Minor Version (ປັບປຸງປະສິດທິພາບ) / Major Version (ປ່ຽນແປງໂຄງສ້າງ) ແລະ ກຳນົດໄລຍະເວລາໃນການແຈ້ງລ່ວງໜ້າ (Lead time) ຂອງແຕ່ລະປະເພດ
• ຜູ້ຮັບແຈ້ງ ແລະ ວິທີການ: ໃຫ້ລວມເອົາຜູ້ຮັບຜິດຊອບວຽກງານ ແລະ ຜູ້ຮັບຜິດຊອບດ້ານຄວາມປອດໄພຂອງຜູ້ວ່າຈ້າງເຂົ້າໃນລາຍຊື່ຜູ້ຮັບແຈ້ງ, ໂດຍມີຫຼັກການຄືການແຈ້ງຜ່ານທາງອີເມວ ແລະ ການສ້າງ Ticket
• ເນື້ອໃນການແຈ້ງ: ກຳນົດໃຫ້ມີຫົວຂໍ້ທີ່ຈຳເປັນ ເຊັ່ນ: ພາບລວມຂອງການປ່ຽນແປງ, ຂອບເຂດຜົນກະທົບ, ຄວາມສາມາດໃນການ Rollback, ແລະ ບົດສະຫຼຸບຜົນການທົດສອບ

ຈຸດສຳຄັນໃນການອອກແບບຂັ້ນຕອນການອະນຸມັດ ມີດັ່ງນີ້:

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

ໃນຟັງຊັນ "ການກຳກັບດູແລ (GOVERN)" ທີ່ NIST AI RMF 1.0 ໄດ້ລະບຸໄວ້ ກໍໄດ້ແນະນຳໃຫ້ມີການນຳເອົາການຈັດການການປ່ຽນແປງຂອງລະບົບ AI ເຂົ້າໄປໃນຂະບວນການຕິດຕາມກວດກາຢ່າງຕໍ່ເນື່ອງເຊັ່ນກັນ.

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

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

"ທ່ານໄດ້ກວດສອບແລ້ວຫຼືບໍ່ວ່າຂໍ້ມູນທີ່ມອບໃຫ້ຜູ້ໃຫ້ບໍລິການ BPO ໄດ້ຖືກນຳໄປໃຊ້ໃນການຝຶກຝົນ AI ຫຼືບໍ່?" — ຜູ້ຮັບຜິດຊອບຫຼາຍຄົນບໍ່ສາມາດຕອບຄຳຖາມນີ້ໄດ້ໃນທັນທີ.

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

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

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

ນອກຈາກນີ້, ໃນ Regulation (EU) 2024/1689 (AI Act) ຍັງໄດ້ກຳນົດຂໍ້ກຳນົດດ້ານການຄຸ້ມຄອງຂໍ້ມູນ (Data Governance) ສຳລັບລະບົບ AI ທີ່ມີຄວາມສ່ຽງສູງ, ດັ່ງນັ້ນ ຫາກມີແຜນການຂະຫຍາຍທຸລະກິດໃນລະດັບໂລກ ຈຳເປັນຕ້ອງກວດສອບຄວາມສອດຄ່ອງບໍ່ພຽງແຕ່ກົດລະບຽບພາຍໃນປະເທດເທົ່ານັ້ນ ແຕ່ຍັງຕ້ອງລວມເຖິງກົດລະບຽບຕ່າງປະເທດນຳອີກ.

ນອກຈາກສັນຍາແລ້ວ, ການແນບແຜນຜັງການໄຫຼວຽນຂອງຂໍ້ມູນ (Data Flow Diagram) (ຂໍ້ມູນໃດຜ່ານລະບົບໃດ) ເປັນເອກະສານຊ້ອນທ້າຍ ຈະຊ່ວຍເຮັດໜ້າທີ່ເປັນຫຼັກຖານໃນການກວດສອບໄດ້.

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

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

ລາຍການຂັ້ນຕໍ່າທີ່ຄວນບັນທຶກໄວ້ ມີດັ່ງນີ້:

• ຂໍ້ມູນນຳເຂົ້າ (Input data): ເນື້ອໃນຄຳຮ້ອງຂໍທີ່ສົ່ງໃຫ້ AI (ຂໍ້ມູນສ່ວນບຸກຄົນຕ້ອງຜ່ານການປິດບັງຂໍ້ມູນ ຫຼື Masking ແລ້ວ)
• ຜົນລັພທີ່ໄດ້ຮັບ (Output result): ການຕັດສິນໃຈ, ຄ່າທີ່ແນະນຳ, ຫຼື ຄະແນນທີ່ AI ສົ່ງກັບຄືນມາ
• ຂໍ້ມູນປະກອບຂອງເຫດຜົນໃນການຕັດສິນໃຈ: ຊື່ໂມເດວທີ່ໃຊ້, ເວີຊັນ, ເວລາໃນການປະມວນຜົນ (Inference time), ແລະ ຄະແນນຄວາມເຊື່ອໝັ້ນ (Confidence score)
• ບັນທຶກການແຊກແຊງຂອງມະນຸດ: ການມີຢູ່ຂອງການ Override, ID ຂອງຜູ້ແຊກແຊງ, ເນື້ອໃນທີ່ປ່ຽນແປງ ແລະ ເຫດຜົນໃນການປ່ຽນແປງ
• ການດຳເນີນການຂັ້ນສຸດທ້າຍ: ເນື້ອໃນທີ່ສະທ້ອນໄປຍັງລະບົບວຽກງານ ແລະ ຜູ້ຮັບຜິດຊອບ

ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ທີ່ຄວນຍຶດຖືໃນການອອກແບບການເກັບຮັກສາ Log ມີ 3 ປະການດັ່ງນີ້:

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

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

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

ຮອບວຽນພື້ນຖານຂອງການທົບທວນປະສິດທິພາບແບບຈຳລອງ

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

ຕົວຢ່າງຕົວຊີ້ວັດທີ່ຄວນກວດສອບໃນເວລາທົບທວນມີດັ່ງນີ້:

• ຄວາມຖືກຕ້ອງ (Accuracy) · ຄວາມແມ່ນຍຳ (Precision) · ການລະນຶກໄດ້ (Recall): ຖ້າຄວາມແຕກຕ່າງຈາກການທົບທວນຄັ້ງກ່ອນເກີນຄ່າຂີດຈຳກັດທີ່ກຳນົດໄວ້ ໃຫ້ດຳເນີນການແຈ້ງເຕືອນທັນທີ
• ອັດຕາການແກ້ໄຂໂດຍມະນຸດ (Human Override Rate): ຖ້າອັດຕາສ່ວນທີ່ຜູ້ຮັບຜິດຊອບໄດ້ປ່ຽນແປງການຕັດສິນໃຈຂອງ AI ເພີ່ມຂຶ້ນຢ່າງກະທັນຫັນ ໃຫ້ຖືວ່າເປັນສັນຍານໃນການປະເມີນແບບຈຳລອງໃໝ່
• ການປ່ຽນແປງໃນການຈັດປະເພດຂໍ້ຜິດພາດ: ຖ້າຮູບແບບການຕັດສິນໃຈທີ່ຜິດພາດເລີ່ມເອນອຽງໄປໃນໝວດໝູ່ໃດໜຶ່ງໂດຍສະເພາະ ໃຫ້ສົງໄສວ່າຂໍ້ມູນທີ່ໃຊ້ໃນການຮຽນຮູ້ອາດມີຄວາມເອນອຽງ

ການອອກແບບຂັ້ນຕອນການແກ້ໄຂໂດຍມະນຸດ (Human Override)

ການແກ້ໄຂ (Override) ບໍ່ແມ່ນ "ການປະຕິເສດການຕັດສິນໃຈຂອງ AI" ແຕ່ເປັນສິ່ງສຳຄັນທີ່ຕ້ອງວາງຕຳແໜ່ງໃຫ້ເປັນການເຮັດວຽກທີ່ປົກກະຕິຂອງລະບົບການກຳກັບດູແລ (Governance). ໂຄງຮ່າງຂອງຂັ້ນຕອນມີດັ່ງນີ້:

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

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

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

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

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

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

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

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

ເພື່ອປ້ອງກັນສະຖານະການນີ້, ຂັ້ນຕອນທີ່ມີປະສິດທິຜົນມີດັ່ງນີ້:

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

ແນວທາງປະຕິບັດສຳລັບຜູ້ປະກອບການ AI ຂອງກະຊວງພາຍໃນ ແລະ ການສື່ສານ ແລະ ກະຊວງເສດຖະກິດ, ການຄ້າ ແລະ ອຸດສາຫະກຳ (ສະບັບທີ 1.

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

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

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

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