ການກວດສອບຄວາມພ້ອມຂອງຂໍ້ມູນ AI ຄືຫຍັງ? ວິທີກວດສອບຂໍ້ມູນພາຍໃນອົງກອນກ່ອນນຳໃຊ້ Agent AI

ການກວດສອບຄວາມພ້ອມຂອງຂໍ້ມູນ AI (AI Data Readiness Audit) ແມ່ນຂະບວນການປະເມີນຄຸນນະພາບ, ການເຂົ້າເຖິງ, ແລະໂຄງສ້າງຂອງຂໍ້ມູນພາຍໃນອົງກອນຢ່າງເປັນລະບົບ ເພື່ອໃຫ້ສາມາດນຳໃຊ້ Agent AI ໄດ້ຢ່າງປອດໄພ ແລະ ໝັ້ນຄົງ.

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

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

• 4 ຂັ້ນຕອນຂອງການກວດສອບ (ການສຳຫຼວດຂໍ້ມູນ, ການປະເມີນຄຸນນະພາບ, ການກວດສອບຄວາມສອດຄ່ອງ (Compliance), ແລະ ການໃຫ້ຄະແນນ)
• ລາຍການກວດສອບສະເພາະທີ່ຄວນກວດສອບໃນແຕ່ລະຂັ້ນຕອນ
• ວິທີການນຳຜົນການກວດສອບໄປປັບໃຊ້ໃນແຜນງານການພັດທະນາ (Roadmap)

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

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

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

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

"AI ເລດີ (AI Ready)" ແລະ "ຄວາມພ້ອມຂອງຂໍ້ມູນ (Data Readiness)" ມັກຈະຖືກເຂົ້າໃຈຜິດກັນ ແຕ່ທັງສອງຢ່າງນີ້ມີຂອບເຂດທີ່ແຕກຕ່າງກັນ.

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

ໃນທາງກົງກັນຂ້າມ, ຄວາມພ້ອມຂອງຂໍ້ມູນ (Data Readiness) ແມ່ນອົງປະກອບໜຶ່ງທີ່ຢູ່ພາຍໃນນັ້ນ ເຊິ່ງເປັນການປະເມີນທີ່ເນັ້ນໃສ່ຄຸນນະພາບ, ການຈັດການ, ແລະ ການເຂົ້າເຖິງຂໍ້ມູນທີ່ຕົວແບບ AI ຈະນຳໄປໃຊ້ງານຕົວຈິງ.

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

ເມື່ອສະຫຼຸບຄວາມແຕກຕ່າງຂອງທັງສອງຢ່າງຈະໄດ້ດັ່ງນີ້:

• AI ເລດີ (AI Ready): ສະພາບແວດລ້ອມໂດຍລວມທີ່ສະໜັບສະໜູນການນຳໃຊ້ AI ເຊັ່ນ: ອົງກອນ, ບຸກຄະລາກອນ, ການບໍລິຫານຈັດການ, ແລະ ງົບປະມານ.
• ຄວາມພ້ອມຂອງຂໍ້ມູນ (Data Readiness): ສະພາວະຄວາມພ້ອມສະເພາະຂອງຂໍ້ມູນ ເຊັ່ນ: ຄຸນນະພາບ, ຄວາມສົມບູນ, ການເຂົ້າເຖິງໄດ້, ແລະ ການຈັດປະເພດຄວາມປອດໄພ.
• ຄວາມສຳພັນ: ຄວາມພ້ອມຂອງຂໍ້ມູນແມ່ນເງື່ອນໄຂຈຳເປັນຂອງ AI ເລດີ (ແນວຄວາມຄິດລະດັບສູງ ⊃ ແນວຄວາມຄິດລະດັບຍ່ອຍ).

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

ເມື່ອປຽບທຽບກັບລະບົບອັດຕະໂນມັດແບບກົດເກນ (Rule-based) ແບບດັ້ງເດີມ, Agent AI ມີຄວາມລະອຽດອ່ອນຕໍ່ຂໍ້ມູນທີ່ຂາດຫາຍ ຫຼື ຂໍ້ມູນທີ່ຂັດແຍ່ງກັນຫຼາຍກວ່າຢ່າງເຫັນໄດ້ຊັດ. ເຫດຜົນກໍຄື Agent AI ບໍ່ໄດ້ປະຕິບັດພຽງຂັ້ນຕອນດຽວ, ແຕ່ຕັ້ງຢູ່ບົນພື້ນຖານຂອງການໃຫ້ເຫດຜົນແບບຫຼາຍຂັ້ນຕອນ (Multi-step reasoning) ເຊິ່ງເປັນການເຊື່ອມໂຍງຂະບວນການຕ່າງໆຢ່າງອິດສະຫຼະ.

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

ເຫດຜົນຫຼັກທີ່ Agent AI ມີຄວາມເຂັ້ມງວດຕໍ່ຄຸນນະພາບຂອງຂໍ້ມູນ ມີດັ່ງນີ້:

• ຂໍ້ຈຳກັດຂອງ Context Window: ເນື່ອງຈາກມີຂີດຈຳກັດຂອງປະລິມານຂໍ້ມູນທີ່ສາມາດອ້າງອີງໄດ້, ຖ້າມີຂໍ້ມູນທີ່ບໍ່ຈຳເປັນ, ຊ້ຳຊ້ອນ ຫຼື ຂັດແຍ່ງກັນປົນເຂົ້າມາ ມັນຈະເຮັດໃຫ້ຂໍ້ມູນທີ່ມີປະໂຫຍດຖືກບີບອອກໄປ.
• ຄວາມສອດຄ່ອງກັບ RAG: ໃນກໍລະນີທີ່ໃຊ້ RAG (Retrieval-Augmented Generation), ຄວາມຖືກຕ້ອງໃນການຄົ້ນຫາຈະເຊື່ອມໂຍງໂດຍກົງກັບການເຮັດໃຫ້ຂໍ້ມູນເປັນມາດຕະຖານ, ຄວາມສົດໃໝ່ ແລະ ຄວາມສອດຄ່ອງຂອງຂໍ້ມູນ. ຖ້າຂໍ້ມູນເກົ່າ ຫຼື ມີຮູບແບບການຂຽນທີ່ຫຼາກຫຼາຍເກີນໄປ, ຜົນການຄົ້ນຫາຂອງ Vector Database ມັກຈະບໍ່ກົງກັບຈຸດປະສົງ.
• ການເຊື່ອມໂຍງຂອງການເອີ້ນໃຊ້ເຄື່ອງມື (Tool calling): ໃນເວລາເອີ້ນໃຊ້ API ພາຍນອກ ຫຼື ຖານຂໍ້ມູນ, ຖ້າມີຄວາມບໍ່ສອດຄ່ອງຂອງ Schema ຫຼື ມີຄ່າ NULL ຫຼາຍເກີນໄປ ຈະເຮັດໃຫ້ການປະມວນຜົນຢຸດສະງັກຍ້ອນຂໍ້ຜິດພາດ ແລະ ສົ່ງຜົນໃຫ້ວຽກງານທັງໝົດລົ້ມເຫຼວ.

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

「ມີຂໍ້ມູນແລ້ວ ທີ່ເຫຼືອກໍພຽງແຕ່ເລືອກໂມເດວເທົ່ານັ້ນ」—— ຜົນຈາກການຕັດສິນໃຈແບບນີ້ໃນໜ້າວຽກຕົວຈິງ ເຮັດໃຫ້ຫຼາຍກໍລະນີທີ່ PoC (ການພິສູດແນວຄວາມຄິດ) ຕ້ອງຢຸດສະງັກ.

ຄວາມຜິດພາດທີ່ມັກເກີດຂຶ້ນເມື່ອລະເລີຍການກວດສອບ (Audit) ສາມາດສະຫຼຸບອອກເປັນ 3 ຮູບແບບຫຼັກໆ:

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

② ຄວາມຖືກຕ້ອງໃນການຄົ້ນຫາຂອງ RAG ຫຼຸດລົງ ໃນກໍລະນີທີ່ນຳໃຊ້ RAG (Retrieval-Augmented Generation), ຄຸນນະພາບຂອງເອກະສານທີ່ເກັບໄວ້ໃນ Vector Database ຈະສົ່ງຜົນໂດຍກົງຕໍ່ຄວາມຖືກຕ້ອງຂອງຄຳຕອບ. ຫາກມີຄູ່ມືເວີຊັນເກົ່າ ຫຼື ໄຟລ໌ທີ່ຊ້ຳຊ້ອນປົນຢູ່, Semantic Search ຈະສົ່ງຄືນເອກະສານທີ່ບໍ່ກ່ຽວຂ້ອງຂຶ້ນມາເປັນອັນດັບຕົ້ນໆ ເຮັດໃຫ້ການຕັດສິນໃຈຂອງ Agent ຜິດພາດ.

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

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

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

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

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

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

ບົດບາດທີ່ຕ້ອງມີການມອບໝາຍໃຫ້ຢ່າງແນ່ນອນ ມີ 4 ຢ່າງດັ່ງນີ້:

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

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

ລາຍການທີ່ຄວນກວດສອບໃນການກຳນົດຂອບເຂດ

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

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

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

ລາຍການຫຼັກທີ່ຄວນກວດສອບກ່ອນເລີ່ມການກວດສອບ ມີດັ່ງນີ້:

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

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

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

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

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

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

• ການຢືນຢັນການມີຢູ່: ມີເຄື່ອງມື Data Catalog ຢ່າງເປັນທາງການ (ເຊັ່ນ: Alation, Collibra, Apache Atlas ແລະ ອື່ນໆ) ຫຼື ມີການຈັດການແບບທົດແທນດ້ວຍສະເປຣດຊີດ (Spreadsheet) ຫຼືບໍ່
• ຄວາມຄົບຖ້ວນ: ມີການລົງທະບຽນແຫຼ່ງຂໍ້ມູນຫຼັກ ເຊິ່ງລວມເຖິງ ERP (Enterprise Resource Planning) ແລະ ລະບົບພື້ນຖານຕ່າງໆແລ້ວຫຼືບໍ່
• ຄວາມສົດໃໝ່: ວັນທີອັບເດດຫຼ້າສຸດແມ່ນພາຍໃນ 3-6 ເດືອນຫຼ້າສຸດຫຼືບໍ່. Catalog ທີ່ເກົ່າເກີນໄປອາດຈະສ້າງຄວາມສ່ຽງທີ່ເຮັດໃຫ້ເກີດຄວາມເຊື່ອໝັ້ນທີ່ຜິດພາດ
• ຄວາມເລິກຂອງ Metadata: ນອກຈາກຊື່ຕາຕະລາງ ແລະ ຄຳນິຍາມຂອງຄໍລຳແລ້ວ, ໄດ້ມີການລະບຸເຈົ້າຂອງຂໍ້ມູນ (Data Owner), ຄວາມຖີ່ໃນການອັບເດດ ແລະ ຂໍ້ຈຳກັດໃນການນຳໃຊ້ໄວ້ຫຼືບໍ່
• ບັນທຶກສິດການເຂົ້າເຖິງ: ມີການລະບຸຢ່າງຊັດເຈນຫຼືບໍ່ວ່າໃຜສາມາດເຂົ້າເຖິງຂໍ້ມູນໃດໄດ້

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

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

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

ຂັ້ນຕອນພື້ນຖານໃນການກວດສອບຂໍ້ມູນ

• ລາຍຊື່ລະບົບການເຮັດວຽກຕາມແຕ່ລະພະແນກ ເຊັ່ນ: ERP (Enterprise Resource Planning), CRM, ການຈັດການສິນຄ້າຄົງຄັງ, ແລະ ລະບົບບັນຊີ
• ບັນທຶກຂໍ້ມູນແຕ່ລະລະບົບລົງໃນ 1 ແຖວ ໂດຍປະກອບດ້ວຍ "ປະເພດຂໍ້ມູນ, ຄວາມຖີ່ໃນການອັບເດດ, ພະແນກທີ່ຮັບຜິດຊອບ ແລະ ຄວາມສາມາດໃນການເຊື່ອມຕໍ່ API"
• ໃນກໍລະນີທີ່ມີ Entity ດຽວກັນ (ຕົວຢ່າງ: ໄອດີລູກຄ້າ) ປາກົດຢູ່ໃນຫຼາຍລະບົບ ໃຫ້ລະບຸໃຫ້ຊັດເຈນວ່າລະບົບໃດເປັນລະບົບຫຼັກ (Master)

ເຫດຜົນທີ່ຄວນເລີ່ມຕົ້ນຈາກ ERP

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

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

ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກທີ່ຄວນຕິດຕາມມີດັ່ງນີ້:

• ລະບົບຕົ້ນທາງ (Generation Source System): ລະບຸລະບົບທີ່ບັນທຶກຂໍ້ມູນໃນຄັ້ງທຳອິດ ເຊັ່ນ: ERP (Enterprise Resource Planning), CRM, ຫຼື ບັນທຶກຈາກເຊັນເຊີ (Sensor log) ເປັນຕົ້ນ.
• ຂັ້ນຕອນການປ່ຽນແປງ (Transformation Step): ລາຍຊື່ຈຸດທີ່ມີການປ່ຽນແປງຮູບແບບຂໍ້ມູນ ເຊັ່ນ: ການປະມວນຜົນ ETL, ການເຊື່ອມຕໍ່ API, ຫຼື ການປັບແຕ່ງດ້ວຍຕົນເອງ.
• ຈຸດປາຍທາງການນຳໃຊ້ (Consumer): ບັນທຶກຈຸດທີ່ຂໍ້ມູນຖືກນຳໄປອ່ານ ເຊັ່ນ: Dashboard, ຂະບວນການ ຫຼື Pipeline ຂອງ ML, ຫຼື Vector Database ຂອງ RAG (Retrieval-Augmented Generation).

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

ໃນເວລາທີ່ເຮັດໃຫ້ເຫັນພາບລວມ, ຂໍແນະນຳໃຫ້ດຳເນີນການກວດສອບ "ຈຸດທີ່ອາດເຮັດໃຫ້ລະບົບລົ້ມເຫຼວທັງໝົດ (Single Point of Failure)" ໄປພ້ອມກັນ. ເນື່ອງຈາກມີຫຼາຍກໍລະນີທີ່ການຢຸດເຮັດວຽກຂອງ Batch Processing ໃດໜຶ່ງ ສົ່ງຜົນໃຫ້ວຽກງານຂອງ AI ຫຼາຍຢ່າງຕ້ອງຢຸດສະງັກລົງຕາມໄປດ້ວຍ.

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

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

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

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

ສຳລັບແຫຼ່ງຂໍ້ມູນທີ່ໄດ້ກວດສອບໃນການກວດນັບ (Inventory) ນັ້ນ, ຈະມີການປະເມີນຄຸນນະພາບໃນຫຼາຍມິຕິ. ໂດຍພື້ນຖານແລ້ວຈະມີ 4 ແກນຫຼັກຄື: ຄວາມຄົບຖ້ວນ, ຄວາມຖືກຕ້ອງ, ຄວາມສອດຄ່ອງ ແລະ ຄວາມທັນສະໄໝ, ເຊິ່ງຫຼັງຈາກກວດສອບຕາມລຳດັບເຫຼົ່ານີ້ແລ້ວ, ຈະມີການພິຈາລະນາເຖິງຄວາມເໝາະສົມກັບ RAG ຫຼື Vector Database, ລວມໄປເຖິງຄວາມເປັນໄປໄດ້ໃນການນຳໃຊ້ຂໍ້ມູນສັງເຄາະ (Synthetic Data) ອີກດ້ວຍ.

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

ຄວາມຄົບຖ້ວນ (Completeness) ວັດແທກອັດຕາການຂາດຫາຍຂອງຟີລ (Field) ທີ່ຈຳເປັນ.

• ກໍລະນີທີ່ "ລະຫັດປະເພດທຸລະກິດ" ຫຼື "ID ຜູ້ຮັບຜິດຊອບ" ໃນຖານຂໍ້ມູນລູກຄ້າຖືກປ່ອຍປະລະເລີຍໃຫ້ຫວ່າງໄວ້ນັ້ນ ບໍ່ແມ່ນເລື່ອງແປກ
• ຟີລທີ່ມີອັດຕາການຂາດຫາຍສູງ ຈຳເປັນຕ້ອງໄດ້ຮັບການຕື່ມຂໍ້ມູນໃຫ້ຄົບຖ້ວນເປັນອັນດັບຕົ້ນໆ ເພາະສົ່ງຜົນໂດຍກົງຕໍ່ຄວາມຖືກຕ້ອງໃນການຄົ້ນຫາຂອງ RAG (Retrieval-Augmented Generation)

ຄວາມຖືກຕ້ອງ (Accuracy) ກວດສອບວ່າຂໍ້ມູນທີ່ບັນທຶກໄວ້ກົງກັບຄວາມເປັນຈິງຫຼືບໍ່.

• ໃນກໍລະນີທີ່ຈຳນວນສິນຄ້າຄົງຄັງໃນ ERP (Enterprise Resource Planning) ບໍ່ກົງກັບສິນຄ້າຕົວຈິງໃນສາງ ຈະກາຍເປັນສາເຫດທີ່ເຮັດໃຫ້ AI ພະຍາກອນຄວາມຕ້ອງການສິນຄ້າສະເໜີຄຳສັ່ງຊື້ທີ່ຜິດພາດ
• ສາມາດກວດພົບໄດ້ໂດຍການປຽບທຽບກັບຖານຂໍ້ມູນພາຍນອກ ຫຼື ຂໍ້ມູນອ້າງອີງ

ຄວາມສອດຄ່ອງ (Consistency) ກວດສອບວ່າ Entity ດຽວກັນໃນຫຼາຍລະບົບມີຄ່າດຽວກັນຫຼືບໍ່.

• ຖ້າກົດລະບຽບການຕັ້ງຊື່ລະຫັດລູກຄ້າໃນລະບົບການຈັດການການຂາຍ ແລະ ລະບົບບັນຊີແຕກຕ່າງກັນ, Agent ຈະຖືວ່າລູກຄ້າຄົນດຽວກັນເປັນຄົນລະ Entity ເຊິ່ງຈະເຮັດໃຫ້ເກີດຄວາມຄາດເຄື່ອນໃນຜົນການລວມຍອດຂໍ້ມູນ
• ການຕິດຕາມ Data Lineage ແລະ ການກວດສອບຄວາມແຕກຕ່າງຂອງກົດລະບຽບການແປງຂໍ້ມູນ (Transformation rules) ແມ່ນວິທີທີ່ມີປະສິດທິຜົນ

ຄວາມທັນສະໄໝ (Timeliness) ປະເມີນວ່າຂໍ້ມູນໄດ້ຮັບການອັບເດດໃນເວລາທີ່ສາມາດນຳໄປໃຊ້ໃນການຕັດສິນໃຈໄດ້ຫຼືບໍ່.

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

ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ທີ່ຄວນກວດສອບ

• ຄວາມເໝາະສົມຂອງ Chunk Size: ຫາກໜ່ວຍໃນການແບ່ງເອກະສານຍາວເກີນໄປ ຈະເຮັດໃຫ້ Context Window ແໜ້ນເກີນໄປ, ແລະ ຫາກສັ້ນເກີນໄປກໍຈະເຮັດໃຫ້ຄວາມໝາຍຂາດຕອນ. ຄວນກຳນົດໃຫ້ຢູ່ປະມານ 500-1,000 Token ໂດຍປະມານ ແລະ ຕ້ອງປັບປ່ຽນຕາມປະເພດຂອງເອກະສານ.
• ຄວາມສອດຄ່ອງຂອງ Embedding: ຫາກມີການໃຊ້ຄຳທີ່ແຕກຕ່າງກັນສຳລັບແນວຄວາມຄິດດຽວກັນ (ເຊັ່ນ: "ID ລູກຄ້າ", "ເລກທີລູກຄ້າ") ຈະເຮັດໃຫ້ຄວາມແມ່ນຍຳຂອງ Semantic Search ຫຼຸດລົງ. ຄວນກວດສອບສະຖານະການກຳນົດຄຳສັບໃຫ້ເປັນເອກະພາບກັນລ່ວງໜ້າ.
• ສະຖານະການເພີ່ມ Metadata: ຫາກຂາດ Metadata ເຊັ່ນ: ວັນທີສ້າງເອກະສານ, ພະແນກ, ຫຼື ເວີຊັນ, ຈະເຮັດໃຫ້ເກີດຄວາມຜິດພາດໃນການອ້າງອີງຂໍ້ມູນເກົ່າວ່າເປັນຂໍ້ມູນລ່າສຸດໄດ້ງ່າຍ.
• ອັດຕາສ່ວນຂອງເອກະສານທີ່ຊ້ຳຊ້ອນ ຫຼື ຂັດແຍ່ງກັນ: ໃນກໍລະນີທີ່ມີເອກະສານເນື້ອຫາຄືກັນແຕ່ມີຫຼາຍເວີຊັນ, ຄະແນນຄວາມຄ້າຍຄືກັນ (Similarity Score) ພາຍໃນ Vector Database ຈະກະຈັດກະຈາຍ ເຮັດໃຫ້ລຳດັບຄວາມສຳຄັນຂອງເອກະສານທີ່ຖືກຕ້ອງຫຼຸດລົງ.

ແກນການຕັດສິນໃຈໂດຍການແບ່ງເງື່ອນໄຂ

ຫາກເອກະສານພາຍໃນເປັນຄູ່ມືທີ່ມີໂຄງສ້າງ, ການໃຊ້ Hybrid Search ທີ່ປະສົມປະສານລະຫວ່າງການແບ່ງ Chunk ແລະ BM25 ມັກຈະມີຄວາມເໝາະສົມຫຼາຍກວ່າ.

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

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

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

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

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

ພວກເຮົາຈະກວດສອບຄວາມປອດໄພຂອງຂໍ້ມູນພາຍໃນອົງກອນຢ່າງເປັນລະບົບ ໂດຍຜ່ານ 3 ມຸມມອງຄື: ການຈັດປະເພດຂໍ້ມູນສ່ວນບຸກຄົນ, ການປະເມີນຄວາມສ່ຽງດ້ານຂໍ້ມູນປົນເປື້ອນ (Data Contamination), ແລະ ການກວດສອບຄວາມສອດຄ່ອງກັບນະໂຍບາຍການກຳກັບດູແລ AI (AI Governance Policy).

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

ກ່ອນທີ່ຈະອະນຸຍາດໃຫ້ AI Agent ເຂົ້າເຖິງຂໍ້ມູນ ຈະຕ້ອງດຳເນີນການຈັດປະເພດຂໍ້ມູນດັ່ງຕໍ່ໄປນີ້ໃຫ້ສຳເລັດກ່ອນ:

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

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

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

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

ໃນການປະເມີນຜົນ, ໃຫ້ກວດສອບແຕ່ລະຫົວຂໍ້ຕາມລຳດັບດັ່ງນີ້:

• ການກຳນົດເສັ້ນທາງການປ້ອນຂໍ້ມູນ (Data Input Path): ລວບລວມເສັ້ນທາງທີ່ຂໍ້ມູນທີ່ບໍ່ໄດ້ຮັບການຄວບຄຸມ (ເຊັ່ນ: ຈາກ API ພາຍນອກ, ການປ້ອນຂໍ້ມູນຈາກຜູ້ໃຊ້, ຫຼື ການ Scraping) ປົນເປື້ອນເຂົ້າໄປໃນ Vector Database ຫຼື Feature Store ພາຍໃນອົງກອນ
• ການກວດສອບສິດໃນການອັບເດດ ແລະ ຂຽນຂໍ້ມູນ (Update/Write Permissions): ກວດສອບວ່າໃຜ ຫຼື ລະບົບໃດສາມາດອັບເດດຂໍ້ມູນການຮຽນຮູ້ ຫຼື RAG Index ໄດ້ ແລະ ສິດທິເຫຼົ່ານັ້ນຖືກຈຳກັດໃຫ້ໜ້ອຍທີ່ສຸດແລ້ວຫຼືບໍ່
• ການຕິດຕາມ Data Lineage: ຕິດຕາມປະຫວັດການປ່ຽນແປງຈາກແຫຼ່ງກຳເນີດຂອງຂໍ້ມູນຈົນເຖິງບ່ອນຈັດເກັບໃນປັດຈຸບັນ ເພື່ອກວດສອບວ່າໄດ້ມີການບັນທຶກການປ່ຽນແປງທີ່ບໍ່ໄດ້ຮັບອະນຸຍາດໄວ້ຫຼືບໍ່
• ການກວດຫາຄ່າຜິດປົກກະຕິ ຫຼື ຄວາມຜິດພ້ຽນທາງສະຖິຕິ: ໃຫ້ຄະແນນຮູບແບບທີ່ມັກຈະເປັນຮ່ອງຮອຍຂອງການ Poisoning ເຊັ່ນ: ຄວາມບໍ່ສົມດຸນຂອງ Label ສະເພາະ, ການປ່ຽນແປງຂອງການກະຈາຍຕົວຢ່າງກະທັນຫັນ, ຫຼື ການກະຈຸກຕົວຂອງບັນທຶກທີ່ຊ້ຳຊ້ອນ

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

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

ໃນການກວດສອບຄວາມສອດຄ່ອງກັບນະໂຍບາຍການກຳກັບດູແລ AI ຈະຕ້ອງກວດສອບຕາມມຸມມອງດັ່ງຕໍ່ໄປນີ້:

• ການລະບຸຈຸດປະສົງການນຳໃຊ້: ແຕ່ລະຊຸດຂໍ້ມູນຖືກນຳໃຊ້ໃນກໍລະນີການນຳໃຊ້ AI (AI use case) ໃດ ແລະ ໄດ້ຮັບການອະນຸມັດຕາມນະໂຍບາຍແລ້ວຫຼືບໍ່
• ການປະຕິບັດຕາມກົດລະບຽບການເກັບຮັກສາ ແລະ ການລຶບຂໍ້ມູນ: ຂໍ້ມູນທີ່ເກີນໄລຍະເວລາການເກັບຮັກສາທີ່ກຳນົດໄວ້ໃນນະໂຍບາຍ ໄດ້ຖືກປົນເຂົ້າໄປໃນການຮຽນຮູ້ ຫຼື ການອ້າງອີງຂອງ Agent ແລ້ວຫຼືບໍ່
• ການອະນຸຍາດໃຫ້ໃຊ້ຂໍ້ມູນຂອງບຸກຄົນທີສາມ: ຂໍ້ມູນທີ່ຈັດຊື້ຈາກພາຍນອກ ມີເງື່ອນໄຂໃບອະນຸຍາດທີ່ຫ້າມນຳໄປໃຊ້ກັບ AI ຫຼືບໍ່
• ການຈຳກັດການປ້ອນຂໍ້ມູນເຂົ້າສູ່ໂມເດວ: ໄດ້ມີການອອກແບບທີ່ປ້ອງກັນບໍ່ໃຫ້ຂໍ້ມູນທີ່ມີລະດັບຄວາມລັບສູງໄຫຼເຂົ້າສູ່ Context Window ຂອງ Agent ໂດຍບໍ່ມີການຈຳກັດຫຼືບໍ່

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

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

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

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

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

ຂັ້ນຕອນການຄິດໄລ່ຄະແນນ

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

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

ມາດຕະຖານຂອງເສັ້ນຜ່ານ/ບໍ່ຜ່ານ

ໃນຕອນເລີ່ມຕົ້ນ, ມັກຈະມີການຕັ້ງມາດຕະຖານແບບດຽວກັນເຊັ່ນ "ຖ້າຄະແນນລວມ 70 ຄະແນນຂຶ້ນໄປສາມາດນຳໃຊ້ໄດ້", ແຕ່ໃນຄວາມເປັນຈິງແລ້ວ ການປ່ຽນແປງມາດຕະຖານຕາມຄວາມຊັບຊ້ອນຂອງກໍລະນີການນຳໃຊ້ (Use Case) ຈະມີປະສິດທິຜົນຫຼາຍກວ່າ. ຖ້າເປັນ Chatbot ທີ່ໃຊ້ຕອບຄຳຖາມ FAQ ແບບງ່າຍໆ, ການເລີ່ມ PoC ດ້ວຍຄະແນນໃນລະດັບ 60 ກໍສາມາດເຮັດໄດ້, ແຕ່ໃນສະຖານະການທີ່ Agent AI ຕ້ອງຕັດສິນໃຈດ້ວຍຕົນເອງໂດຍຂ້າມຜ່ານຫຼາຍລະບົບ, ຄວນຕັ້ງເປົ້າໝາຍໄວ້ທີ່ 80 ຄະແນນຂຶ້ນໄປ.

• ຕ່ຳກວ່າ 60 ຄະແນນ: ເລື່ອນການນຳໃຊ້. ໃຫ້ບຸລິມະສິດກັບການປັບປຸງໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ຂອງຂໍ້ມູນຄືນໃໝ່
• 60-79 ຄະແນນ: ເລີ່ມຕົ້ນ PoC ໃນຂອບເຂດທີ່ຈຳກັດ ແລະ ດຳເນີນການປັບປຸງຂໍ້ມູນໄປພ້ອມໆກັນ
• 80 ຄະແນນຂຶ້ນໄປ: ສາມາດຍ້າຍໄປສູ່ໄລຍະການນຳໃຊ້ຢ່າງເຕັມຮູບແບບ

ຂໍ້ຄວນລະວັງ

ຄະແນນເປັນພຽງດັດຊະນີຊີ້ວັດແບບສຳພັດເທົ່ານັ້ນ.

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

ໃນຕາຕະລາງການຈັດລຳດັບຄວາມສຳຄັນ (Priority Matrix), ພວກເຮົາຈະພັອດ (Plot) ແຕ່ລະບັນຫາໂດຍໃຊ້ 2 ແກນ ຄື: ລະດັບຜົນກະທົບ (ການປະກອບສ່ວນຕໍ່ຄວາມຖືກຕ້ອງ ແລະ ສະຖຽນລະພາບຂອງ AI) ແລະ ຕົ້ນທຶນໃນການຈັດການ (ຊົ່ວໂມງການເຮັດວຽກ, ຄ່າໃຊ້ຈ່າຍ, ແລະ ຄວາມຍາກທາງເຕັກນິກ).

• ຜົນກະທົບສູງ・ຕົ້ນທຶນຕ່ຳ (ຈັດການທັນທີ): ການຕື່ມຂໍ້ມູນທີ່ຂາດຫາຍໄປ, ການລຶບຂໍ້ມູນທີ່ຊ້ຳຊ້ອນ ແລະ ອື່ນໆ. ໃຫ້ເລີ່ມດຳເນີນການພາຍໃນ 1-2 ອາທິດຂອງ Sprint.
• ຜົນກະທົບສູງ・ຕົ້ນທຶນສູງ (ຈັດການຕາມແຜນ): ການປັບປຸງການເຊື່ອມໂຍງກັບ ERP (Enterprise Resource Planning), ການປັບປຸງ Data Lineage ແລະ ອື່ນໆ. ຕັ້ງເປົ້າໝາຍໃຫ້ສຳເລັດກ່ອນເລີ່ມ PoC (Proof of Concept).
• ຜົນກະທົບຕ່ຳ・ຕົ້ນທຶນຕ່ຳ (ຈັດການເມື່ອມີເວລາ): ການແກ້ໄຂຄວາມບໍ່ສອດຄ່ອງຂອງ Metadata ແລະ ອື່ນໆ.
• ຜົນກະທົບຕ່ຳ・ຕົ້ນທຶນສູງ (ພັກໄວ້ ຫຼື ຕັດອອກ): ການປ່ຽນແປງລະບົບ Legacy ທັງໝົດ ແລະ ອື່ນໆ.

ໃນກໍລະນີທີ່ມີບັນຫາທີ່ຕົ້ນທຶນຕ່ຳຫຼາຍຢ່າງ, ສາມາດແກ້ໄຂໄດ້ເທື່ອລະຢ່າງພາຍໃນ Sprint 2-4 ອາທິດ, ແຕ່ຖ້າຫາກກ່ຽວຂ້ອງກັບການປ່ຽນແປງໂຄງສ້າງຂອງລະບົບຫຼັກ, ການກຳນົດໄລຍະເວລາ 3-6 ເດືອນເພື່ອດຳເນີນການເປັນຂັ້ນຕອນຖືເປັນເລື່ອງທີ່ເປັນໄປໄດ້ຫຼາຍກວ່າ.

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

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