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

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

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

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

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

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

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

ລາຍການກວດສອບເພື່ອຕັດສິນວ່າຖືກນຳໃຊ້ຫຼືບໍ່:

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

ຫາກຕົກຢູ່ໃນເງື່ອນໄຂໃດໜຶ່ງຂ້າງເທິງ, ມີຄວາມເປັນໄປໄດ້ສູງທີ່ຈະຖືກນຳໃຊ້ PDPA.

ສະຫຼຸບບົດລົງໂທດ:

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

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

ລາຍການກວດສອບເພື່ອຕັດສິນວ່າຢູ່ໃນຂອບເຂດການນຳໃຊ້ ຫຼື ບໍ່:

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

ຖ້າຕອບວ່າ "ແມ່ນ" ໃນຂໍ້ໃດຂໍ້ໜຶ່ງຂ້າງເທິງ, ມີຄວາມເປັນໄປໄດ້ສູງທີ່ຈະຢູ່ພາຍໃຕ້ການນຳໃຊ້ຂອງ PDPA.

ສະຫຼຸບໂທດ:

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

ພັນທະພາຍໃຕ້ PDPA ທີ່ຕ້ອງໃຫ້ຄວາມສົນໃຈເປັນພິເສດໃນການດຳເນີນງານລະບົບ AI ມີທັງໝົດ 6 ຂໍ້ ດັ່ງນີ້:

1. ການຮັບປະກັນຖານທາງກົດໝາຍໃນການເກັບກຳຂໍ້ມູນ

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

2. ການລະບຸຈຸດປະສົງ ແລະ ການຈຳກັດການນຳໃຊ້

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

3. ພັນທະໃນການແຈ້ງໃຫ້ເຈົ້າຂອງຂໍ້ມູນຊາບ

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

4. ການຄຸ້ມຄອງຂໍ້ມູນລະອຽດອ່ອນຢ່າງເຂັ້ມງວດ

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

5. ພັນທະທາງສັນຍາກັບຜູ້ປະມວນຜົນຂໍ້ມູນ (ມາດຕາ 40)

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

6. ການຈັດຕັ້ງປະຕິບັດມາດຕະການຄວາມປອດໄພ

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

ພັນທະພາຍໃຕ້ PDPA ທີ່ຕ້ອງໃຫ້ຄວາມສົນໃຈເປັນພິເສດໃນການດຳເນີນງານລະບົບ AI ມີທັງໝົດ 6 ຂໍ້ ດັ່ງນີ້:

1. ການຮັບປະກັນຖານທາງກົດໝາຍໃນການເກັບກຳຂໍ້ມູນ

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

2. ການລະບຸຈຸດປະສົງ ແລະ ການຈຳກັດການນຳໃຊ້

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

3. ພັນທະໃນການແຈ້ງໃຫ້ເຈົ້າຂອງຂໍ້ມູນຊາບ

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

4. ການຄຸ້ມຄອງຂໍ້ມູນອ່ອນໄຫວຢ່າງເຂັ້ມງວດ

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

5. ພັນທະໃນການທຳສັນຍາກັບຜູ້ປະມວນຜົນຂໍ້ມູນ (ມາດຕາ 40)

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

6. ການຈັດຕັ້ງປະຕິບັດມາດຕະການຄວາມປອດໄພ

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

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

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

ລາຍການກວດສອບ:

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

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

ລາຍການທີ່ຕ້ອງລະບຸໃນນະໂຍບາຍຄວາມເປັນສ່ວນຕົວ:

ນະໂຍບາຍຄວາມເປັນສ່ວນຕົວຕ້ອງມີຢ່າງໜ້ອຍດັ່ງຕໍ່ໄປນີ້:

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

ລາຍການກວດສອບ:

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

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

ລາຍການທີ່ຕ້ອງລະບຸໃນນະໂຍບາຍຄວາມເປັນສ່ວນຕົວ:

ນະໂຍບາຍຄວາມເປັນສ່ວນຕົວຕ້ອງລວມມີຢ່າງໜ້ອຍດັ່ງຕໍ່ໄປນີ້:

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

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

ລາຍການກວດສອບ:

• ຄວາມສອດຄ່ອງຂອງຈຸດປະສົງ: ຈຸດປະສົງທີ່ໄດ້ແຈ້ງໃຫ້ຊາບໃນເວລາເກັບກຳຂໍ້ມູນນັ້ນ ລວມເຖິງ "ການຝຶກສອນ ແລະ ປັບປຸງໂມເດລ AI" ດ້ວຍຫຼືບໍ່
• ການຍິນຍອມສຳລັບການໃຊ້ນອກຈຸດປະສົງ: ຫາກບໍ່ໄດ້ລວມຢູ່ໃນຈຸດປະສົງເດີມ ໄດ້ຂໍຄວາມຍິນຍອມເພີ່ມເຕີມແລ້ວຫຼືບໍ່
• ການພິຈາລະນາການເຮັດໃຫ້ບໍ່ລະບຸຕົວຕົນ: ຫາກເຮັດໃຫ້ຂໍ້ມູນການຝຶກສອນບໍ່ສາມາດລະບຸຕົວຕົນໄດ້ (Anonymization) ກໍ່ມີຄວາມເປັນໄປໄດ້ທີ່ຈະບໍ່ຢູ່ພາຍໃຕ້ການບັງຄັບໃຊ້ຂອງ PDPA. ໄດ້ພິຈາລະນາແລ້ວຫຼືບໍ່ວ່າການເຮັດໃຫ້ບໍ່ລະບຸຕົວຕົນຢ່າງສົມບູນນັ້ນເປັນໄປໄດ້ທາງດ້ານເຕັກນິກ
• ການກວດສອບຂໍ້ມູນສາທາລະນະ: ເຖິງແມ່ນວ່າຈະເປັນຂໍ້ມູນສາທາລະນະທີ່ເກັບກຳຜ່ານ Web Scraping ກໍ່ຕາມ ຫາກຈັດເປັນຂໍ້ມູນສ່ວນຕົວ ກໍ່ຍັງຢູ່ພາຍໃຕ້ການບັງຄັບໃຊ້ຂອງ PDPA
• ຄວາມຖືກຕ້ອງຕາມກົດໝາຍຂອງຂໍ້ມູນຈາກພາກສ່ວນທີສາມ: ໄດ້ກວດສອບຮາກຖານການເກັບກຳຂໍ້ມູນທີ່ໄດ້ຮັບຈາກ Data Broker ຫຼື ບໍລິສັດຄູ່ຮ່ວມງານແລ້ວຫຼືບໍ່

ຄວາມແຕກຕ່າງລະຫວ່າງ Anonymization ແລະ Pseudonymization:

ໃນບໍລິບົດຂອງ PDPA ຈຳເປັນຕ້ອງແຍກຄວາມແຕກຕ່າງລະຫວ່າງ "Anonymization" ແລະ "Pseudonymization" ຢ່າງຊັດເຈນ.

• Anonymization (ການເຮັດໃຫ້ບໍ່ລະບຸຕົວຕົນ): ສະຖານະທີ່ການລະບຸຕົວຕົນຂອງບຸກຄົນໄດ້ຖືກເຮັດໃຫ້ເປັນໄປບໍ່ໄດ້ຢ່າງຖາວອນ. ບໍ່ຢູ່ພາຍໃຕ້ການບັງຄັບໃຊ້ຂອງ PDPA
• Pseudonymization (ການໃຊ້ນາມແຝງ): ສະຖານະທີ່ສາມາດລະບຸຕົວຕົນຂອງບຸກຄົນໄດ້ເມື່ອລວມກັບຂໍ້ມູນເພີ່ມເຕີມ. ຍັງຢູ່ພາຍໃຕ້ການບັງຄັບໃຊ້ຂອງ PDPA

ໃນກໍລະນີທີ່ໃຊ້ຂໍ້ມູນ Pseudonymization ສຳລັບການຝຶກສອນ AI ຍັງຕ້ອງປະຕິບັດຕາມຂໍ້ກຳນົດຂອງ PDPA ຕໍ່ໄປ. ການຕັດສິນໃຈວ່າ "ໃຊ້ Hash ແລ້ວກໍ່ບໍ່ເປັນຫຍັງ" ນັ້ນເປັນສິ່ງທີ່ອັນຕະລາຍ. ເຖິງແມ່ນວ່າຈະບໍ່ສາມາດຟື້ນຟູຂໍ້ມູນຕົ້ນສະບັບຈາກຄ່າ Hash ໄດ້ກໍ່ຕາມ ກໍ່ມີກໍລະນີທີ່ບໍ່ໜ້ອຍທີ່ສາມາດລະບຸຕົວຕົນຄືນໄດ້ (Re-identification) ໂດຍການຈັບຄູ່ກັບຂໍ້ມູນອື່ນ. ຄວາມພຽງພໍຂອງ Anonymization ຄວນໄດ້ຮັບການປະເມີນຢ່າງລະມັດລະວັງ ໂດຍຄຳນຶງເຖິງເຕັກໂນໂລຊີທີ່ສາມາດໃຊ້ໄດ້ ແລະ ຄວາມສາມາດໃນການເຂົ້າເຖິງຂໍ້ມູນເພີ່ມເຕີມ.

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

ລາຍການກວດສອບ:

• ຄວາມສອດຄ່ອງຂອງຈຸດປະສົງ: ຈຸດປະສົງທີ່ໄດ້ແຈ້ງໄວ້ຕອນເກັບກຳຂໍ້ມູນລວມເຖິງ "ການຝຶກຝົນ ແລະ ປັບປຸງໂມເດລ AI" ຫຼືບໍ່
• ການຍິນຍອມສຳລັບການໃຊ້ນອກຈຸດປະສົງ: ຫາກບໍ່ໄດ້ລວມຢູ່ໃນຈຸດປະສົງເດີມ ໄດ້ຂໍຄວາມຍິນຍອມເພີ່ມເຕີມແລ້ວຫຼືບໍ່
• ການພິຈາລະນາ Anonymization: ຫາກ Anonymize ຂໍ້ມູນທີ່ໃຊ້ຝຶກຝົນ (ເຮັດໃຫ້ບໍ່ສາມາດລະບຸຕົວບຸກຄົນໄດ້) ອາດຈະບໍ່ຢູ່ພາຍໃຕ້ການບັງຄັບໃຊ້ຂອງ PDPA ໄດ້ ໄດ້ພິຈາລະນາແລ້ວຫຼືບໍ່ວ່າ Anonymization ຢ່າງສົມບູນນັ້ນເປັນໄປໄດ້ທາງດ້ານເຕັກນິກ
• ການກວດສອບຂໍ້ມູນສາທາລະນະ: ເຖິງແມ່ນວ່າຈະເປັນຂໍ້ມູນສາທາລະນະທີ່ເກັບກຳຜ່ານ Web Scraping ກໍຕາມ ຫາກຖືວ່າເປັນຂໍ້ມູນສ່ວນຕົວ ກໍຍັງຢູ່ພາຍໃຕ້ການບັງຄັບໃຊ້ຂອງ PDPA
• ຄວາມຖືກຕ້ອງຕາມກົດໝາຍຂອງຂໍ້ມູນຈາກພາກສ່ວນທີສາມ: ໄດ້ກວດສອບພື້ນຖານການເກັບກຳຂໍ້ມູນທີ່ໄດ້ຮັບມາຈາກ Data Broker ຫຼືບໍລິສັດຄູ່ຮ່ວມງານແລ້ວຫຼືບໍ່

ຄວາມແຕກຕ່າງລະຫວ່າງ Anonymization ແລະ Pseudonymization:

ໃນບໍລິບົດຂອງ PDPA ຈຳເປັນຕ້ອງແຍກຄວາມແຕກຕ່າງລະຫວ່າງ "Anonymization" ແລະ "Pseudonymization" ໃຫ້ຊັດເຈນ.

• Anonymization (ການເຮັດໃຫ້ບໍ່ລະບຸຕົວຕົນ): ສະຖານະທີ່ການລະບຸຕົວບຸກຄົນໄດ້ກາຍເປັນສິ່ງທີ່ເປັນໄປບໍ່ໄດ້ຢ່າງຖາວອນ ບໍ່ຢູ່ພາຍໃຕ້ການບັງຄັບໃຊ້ຂອງ PDPA
• Pseudonymization (ການໃຊ້ນາມແຝງ): ສະຖານະທີ່ສາມາດລະບຸຕົວບຸກຄົນໄດ້ເມື່ອລວມກັບຂໍ້ມູນເພີ່ມເຕີມ ຍັງຢູ່ພາຍໃຕ້ການບັງຄັບໃຊ້ຂອງ PDPA

ໃນກໍລະນີທີ່ໃຊ້ຂໍ້ມູນ Pseudonymization ໃນຂໍ້ມູນຝຶກຝົນ AI ຍັງຕ້ອງປະຕິບັດຕາມຂໍ້ກຳນົດຂອງ PDPA ຕໍ່ໄປ. ການຕັດສິນໃຈວ່າ "Hash ແລ້ວກໍໂອເຄ" ນັ້ນເປັນສິ່ງທີ່ອັນຕະລາຍ. ເຖິງແມ່ນວ່າຈະບໍ່ສາມາດກູ້ຄືນຂໍ້ມູນຕົ້ນສະບັບຈາກຄ່າ Hash ໄດ້ ກໍຍັງມີກໍລະນີທີ່ສາມາດລະບຸຕົວຕົນຄືນໄດ້ (Re-identification) ໂດຍການຈັບຄູ່ກັບຂໍ້ມູນອື່ນໆ ຊຶ່ງບໍ່ແມ່ນເລື່ອງໜ້ອຍ. ຄວາມພຽງພໍຂອງ Anonymization ຄວນໄດ້ຮັບການປະເມີນຢ່າງລະມັດລະວັງໂດຍຄຳນຶງເຖິງເຕັກໂນໂລຊີທີ່ສາມາດໃຊ້ໄດ້ ແລະ ຄວາມເປັນໄປໄດ້ໃນການເຂົ້າເຖິງຂໍ້ມູນເພີ່ມເຕີມ.

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

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

PDPA ບໍ່ມີບົດບັນຍັດທີ່ຊັດເຈນທີ່ທຽບເທົ່າກັບ "ສິດໃນການປະຕິເສດການຕັດສິນໃຈທີ່ອີງໃສ່ການປະມວນຜົນອັດຕະໂນມັດເທົ່ານັ້ນ" ຕາມມາດຕາ 22 ຂອງ GDPR ຂອງ EU ແຕ່ກໍ່ບໍ່ໄດ້ໝາຍຄວາມວ່າ Profiling ຈະຢູ່ນອກເໜືອການຄວບຄຸມໂດຍສິ້ນເຊີງ.

Checklist:

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

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

ນອກຈາກນີ້ PDPC ໄດ້ເຜີຍແຜ່ແນວທາງທີ່ກຳນົດໃຫ້ຜູ້ປະກອບການທີ່ດຳເນີນການປະມວນຜົນຂໍ້ມູນທີ່ກ່ຽວຂ້ອງກັບ Profiling ຕ້ອງຈັດຕັ້ງ DPO. ໃນກໍລະນີທີ່ດຳເນີນການ Profiling ດ້ວຍ AI ຄວນພິຈາລະນາການຈັດຕັ້ງ DPO ຢ່າງຈິງຈັງ.

PDPA ບໍ່ມີບົດບັນຍັດທີ່ຊັດເຈນທີ່ທຽບເທົ່າກັບ "ສິດໃນການປະຕິເສດການຕັດສິນໃຈທີ່ອີງໃສ່ການປະມວນຜົນອັດຕະໂນມັດເທົ່ານັ້ນ" ຕາມມາດຕາ 22 ຂອງ GDPR ຂອງ EU ແຕ່ນັ້ນກໍ່ບໍ່ໄດ້ໝາຍຄວາມວ່າ Profiling ຈະຢູ່ນອກການຄວບຄຸມທາງກົດໝາຍທັງໝົດ.

Checklist:

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

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

ນອກຈາກນີ້ PDPC ໄດ້ເຜີຍແຜ່ແນວທາງທີ່ກຳນົດໃຫ້ຜູ້ປະກອບການທີ່ດຳເນີນການປະມວນຜົນຂໍ້ມູນທີ່ກ່ຽວຂ້ອງກັບ Profiling ຕ້ອງແຕ່ງຕັ້ງ DPO. ໃນກໍລະນີທີ່ດຳເນີນການ Profiling ດ້ວຍ AI ຄວນພິຈາລະນາການແຕ່ງຕັ້ງ DPO ຢ່າງຈິງຈັງ.

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

ລາຍການກວດສອບ:

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

ວິທີການທີ່ສ້າງຄວາມສົມດຸນລະຫວ່າງການຫຼຸດຂໍ້ມູນໃຫ້ໜ້ອຍທີ່ສຸດ ແລະ ຄວາມຖືກຕ້ອງຂອງ AI:

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

• ການຄັດເລືອກຄຸນລັກສະນະ (Feature Selection): ຄັດເລືອກສະເພາະຄຸນລັກສະນະທີ່ສົ່ງຜົນຕໍ່ການທຳນາຍຂອງໂມເດລ ແລະ ຕັດຄຸນລັກສະນະທີ່ບໍ່ຈຳເປັນທີ່ມີຂໍ້ມູນສ່ວນຕົວອອກ
• ຄວາມເປັນສ່ວນຕົວແບບຄວາມແຕກຕ່າງ (Differential Privacy): ເພີ່ມ Noise ເຂົ້າໃນຂໍ້ມູນການຮຽນຮູ້ ເພື່ອຫຼຸດຄວາມສ່ຽງໃນການລະບຸຕົວຕົນ ໃນຂະນະທີ່ຮັກສາຄວາມເປັນປະໂຫຍດຂອງໂມເດລໄວ້
• ການຮຽນຮູ້ແບບສະຫະພັນ (Federated Learning): ດຳເນີນການຮຽນຮູ້ຢູ່ໃນເຄື່ອງແຕ່ລະເຄື່ອງຢ່າງ Local ໂດຍບໍ່ລວມຂໍ້ມູນໄວ້ທີ່ Server ກາງ. ສາມາດຫຼຸດການໂອນຍ້າຍຂໍ້ມູນສ່ວນຕົວໃຫ້ໜ້ອຍທີ່ສຸດ

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

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

ລາຍການກວດສອບ:

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

ວິທີການທີ່ສ້າງຄວາມສົມດຸນລະຫວ່າງການຫຼຸດຜ່ອນຂໍ້ມູນ ແລະ ຄວາມຖືກຕ້ອງຂອງ AI:

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

• ການຄັດເລືອກຄຸນລັກສະນະ (Feature Selection): ຄັດເລືອກສະເພາະຄຸນລັກສະນະທີ່ສົ່ງຜົນຕໍ່ການທຳນາຍຂອງໂມເດລ ແລະ ຕັດຄຸນລັກສະນະທີ່ບໍ່ຈຳເປັນທີ່ມີຂໍ້ມູນສ່ວນຕົວອອກ
• ຄວາມເປັນສ່ວນຕົວແບບຄວາມແຕກຕ່າງ (Differential Privacy): ເພີ່ມ Noise ເຂົ້າໃນຂໍ້ມູນການຮຽນຮູ້ ເພື່ອຫຼຸດຄວາມສ່ຽງໃນການລະບຸຕົວຕົນ ໃນຂະນະທີ່ຮັກສາຄວາມເປັນປະໂຫຍດຂອງໂມເດລໄວ້
• ການຮຽນຮູ້ແບບສະຫະພັນ (Federated Learning): ດຳເນີນການຮຽນຮູ້ຢູ່ໃນອຸປະກອນແຕ່ລະເຄື່ອງຢ່າງ Local ໂດຍບໍ່ຕ້ອງລວມສູນຂໍ້ມູນໄວ້ທີ່ Server ກາງ ເຊິ່ງຊ່ວຍຫຼຸດຜ່ອນການໂອນຍ້າຍຂໍ້ມູນສ່ວນຕົວໃຫ້ໜ້ອຍທີ່ສຸດ

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

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

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

ລາຍການກວດສອບໄລຍະເວລາການເກັບຮັກສາຂໍ້ມູນ:

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

ລາຍການກວດສອບການໂອນຂໍ້ມູນຂ້າມຊາຍແດນ:

ໃນກໍລະນີທີ່ໃຊ້ບໍລິການ AI ຕ່າງປະເທດ (Cloud API, ເຄື່ອງມື AI ປະເພດ SaaS ເປັນຕົ້ນ), ຂໍ້ມູນສ່ວນຕົວຈະຖືກໂອນໄປຍັງຕ່າງປະເທດ. ຈຶ່ງຈຳເປັນຕ້ອງດຳເນີນການຕາມມາດຕາ 28 ແລະ 29 ຂອງ PDPA.

• ການລະບຸປາຍທາງການໂອນຂໍ້ມູນ: ໄດ້ຮັບຮູ້ວ່າຂໍ້ມູນຖືກເກັບຮັກສາ ແລະ ປະມວນຜົນຢູ່ເຊີບເວີຂອງປະເທດໃດຫຼືບໍ່
• ການກວດສອບການຮັບຮອງຄວາມພຽງພໍ: ໄດ້ກວດສອບວ່າປາຍທາງການໂອນຂໍ້ມູນຢູ່ໃນລາຍຊື່ການຮັບຮອງຄວາມພຽງພໍຂອງ PDPC (Section 28) ຫຼືບໍ່
• ມາດຕະການປົກປ້ອງທີ່ເໝາະສົມ: ໃນກໍລະນີທີ່ບໍ່ມີການຮັບຮອງຄວາມພຽງພໍ, ໄດ້ດຳເນີນມາດຕະການປົກປ້ອງຕາມ Section 29 (ກົດລະບຽບວິສາຫະກິດທີ່ມີຜົນຜູກພັນ: BCR, ຫຼື ຂໍ້ກຳນົດສັນຍາມາດຕະຖານ: SCC) ຫຼືບໍ່
• ການຈັດການດ້ານສັນຍາ: ໄດ້ລວມຂໍ້ກຳນົດການປົກປ້ອງຂໍ້ມູນ (ຂອບເຂດການປະມວນຜົນ, ມາດຕະການຄວາມປອດໄພ, ພັນທະລາຍງານການຮົ່ວໄຫລຂໍ້ມູນພາຍໃນ 72 ຊົ່ວໂມງ ເປັນຕົ້ນ) ໄວ້ໃນສັນຍາກັບຜູ້ໃຫ້ບໍລິການ AI ຫຼືບໍ່
• ການໂອນຂໍ້ມູນໂດຍອາໄສຄວາມຍິນຍອມ: ໃນກໍລະນີທີ່ບໍ່ສາມາດໃຊ້ວິທີການຂ້າງເທິງໄດ້, ໄດ້ຂໍຄວາມຍິນຍອມຢ່າງຊັດເຈນຈາກເຈົ້າຂອງຂໍ້ມູນຫຼັງຈາກອະທິບາຍຄວາມສ່ຽງໃຫ້ຊາບຫຼືບໍ່

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

ລາຍການກວດສອບໄລຍະເວລາການເກັບຮັກສາຂໍ້ມູນ:

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

ລາຍການກວດສອບການໂອນຂໍ້ມູນຂ້າມຊາຍແດນ:

ໃນກໍລະນີທີ່ໃຊ້ບໍລິການ AI ຕ່າງປະເທດ (Cloud API, SaaS AI Tools ແລະອື່ນໆ), ຂໍ້ມູນສ່ວນຕົວຈະຖືກໂອນໄປຍັງຕ່າງປະເທດ. ຈຶ່ງຈຳເປັນຕ້ອງດຳເນີນການຕາມ PDPA ມາດຕາ 28 ແລະ 29.

• ການລະບຸປາຍທາງການໂອນຂໍ້ມູນ: ໄດ້ກວດສອບແລ້ວຫຼືບໍ່ວ່າຂໍ້ມູນຖືກເກັບຮັກສາ ແລະ ປະມວນຜົນຢູ່ Server ຂອງປະເທດໃດ
• ການກວດສອບການຮັບຮອງຄວາມພຽງພໍ: ໄດ້ກວດສອບແລ້ວຫຼືບໍ່ວ່າປາຍທາງການໂອນຂໍ້ມູນຢູ່ໃນລາຍຊື່ການຮັບຮອງຄວາມພຽງພໍຂອງ PDPC (Section 28)
• ມາດຕະການປົກປ້ອງທີ່ເໝາະສົມ: ຫາກບໍ່ໄດ້ຮັບການຮັບຮອງຄວາມພຽງພໍ, ໄດ້ດຳເນີນມາດຕະການປົກປ້ອງຕາມ Section 29 (ກົດລະບຽບວິສາຫະກິດທີ່ມີຜົນຜູກພັນ: BCR, ຫຼື ຂໍ້ກຳນົດສັນຍາມາດຕະຖານ: SCC) ແລ້ວຫຼືບໍ່
• ການຈັດການດ້ານສັນຍາ: ສັນຍາກັບຜູ້ໃຫ້ບໍລິການ AI ໄດ້ລວມເອົາຂໍ້ກຳນົດການປົກປ້ອງຂໍ້ມູນ (ຂອບເຂດການປະມວນຜົນ, ມາດຕະການຄວາມປອດໄພ, ພັນທະການລາຍງານການຮົ່ວໄຫຼຂໍ້ມູນພາຍໃນ 72 ຊົ່ວໂມງ ແລະອື່ນໆ) ແລ້ວຫຼືບໍ່
• ການໂອນຂໍ້ມູນໂດຍອາໄສຄວາມຍິນຍອມ: ຫາກບໍ່ສາມາດໃຊ້ວິທີການຂ້າງເທິງໄດ້, ໄດ້ຂໍຄວາມຍິນຍອມຢ່າງຊັດເຈນຈາກເຈົ້າຂອງຂໍ້ມູນຫຼັງຈາກອະທິບາຍຄວາມສ່ຽງໃຫ້ຊາບແລ້ວຫຼືບໍ່

PDPC ຍັງບໍ່ທັນໄດ້ເປີດຕົວ ຫຼື Launch ລາຍຊື່ການຮັບຮອງຄວາມພຽງພໍ (ນັບຕາມເວລາທີ່ຂຽນບົດຄວາມນີ້). ດ້ວຍເຫດນີ້, ໃນຂັ້ນຕອນປະຈຸບັນ, ການຈັດຕັ້ງ SCC ຫຼື BCR ຈຶ່ງເປັນການດຳເນີນການມາດຕະຖານໃນທາງປະຕິບັດ. ສຳລັບ SCC ນັ້ນ, ຮູບແບບທີ່ນິຍົມໃຊ້ຄືການອ້າງອີງ ASEAN Model Contractual Clauses ຫຼື EU Standard Contractual Clauses ເປັນພື້ນຖານ ແລ້ວເພີ່ມເຕີມຂໍ້ກຳນົດສະເພາະຂອງໄທ (ເຊັ່ນ: ການລາຍງານການຮົ່ວໄຫຼຂໍ້ມູນພາຍໃນ 72 ຊົ່ວໂມງ ແລະອື່ນໆ) ເຂົ້າໄປ.

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

ລາຍການກວດສອບ:

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

ສິ່ງທ້າທາຍສະເພາະຂອງ AI — ສິດທິການລຶບ ແລະ ໂມເດລທີ່ຝຶກສອນແລ້ວ:

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

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

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

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

ລາຍການກວດສອບ:

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

ສິ່ງທ້າທາຍສະເພາະຂອງ AI — ສິດໃນການລຶບ ແລະ ໂມເດລທີ່ຝຶກສອນແລ້ວ:

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

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

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

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

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

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

ລາຍການກວດສອບ:

• ການກຳນົດບົດບາດໃຫ້ຊັດເຈນ: ໄດ້ກຳນົດບົດບາດຂອງຜູ້ຄວບຄຸມຂໍ້ມູນ ແລະ ຜູ້ປະມວນຜົນຂໍ້ມູນລະຫວ່າງອົງກອນຂອງຕົນເອງ ແລະ ຜູ້ໃຫ້ບໍລິການຢ່າງຊັດເຈນແລ້ວຫຼືບໍ່
• ສັນຍາການປະມວນຜົນຂໍ້ມູນ (DPA): ໄດ້ທຳສັນຍາເປັນລາຍລັກອັກສອນທີ່ສອດຄ່ອງກັບມາດຕາ 40 ຂອງ PDPA ແລ້ວຫຼືບໍ່
• ການຈຳກັດຂອບເຂດການປະມວນຜົນ: ໄດ້ຕັ້ງຄ່າໃຫ້ຜູ້ໃຫ້ບໍລິການບໍ່ສາມາດນຳໃຊ້ຂໍ້ມູນເພື່ອຝຶກສອນ Model ຂອງຕົນເອງແລ້ວຫຼືບໍ່ (ເຊັ່ນ: ການ Opt-out ເປັນຕົ້ນ)
• ການຕິດຕາມ Sub-processor: ໃນກໍລະນີທີ່ຜູ້ໃຫ້ບໍລິການໃຊ້ຜູ້ຮັບເໝົາຊ່ວງ (Sub-processor), ໄດ້ຮັບຊາບລາຍຊື່ດັ່ງກ່າວແລ້ວຫຼືບໍ່
• ສະຖານທີ່ຈັດເກັບຂໍ້ມູນ: ໄດ້ກວດສອບແລ້ວຫຼືບໍ່ວ່າຜູ້ໃຫ້ບໍລິການປະມວນຜົນ ແລະ ຈັດເກັບຂໍ້ມູນຢູ່ປະເທດໃດ
• ການລາຍງານເຫດການ: ໄດ້ຕົກລົງໃນສັນຍາກ່ຽວກັບຂະບວນການ ຫຼື Pipeline ການລາຍງານເມື່ອເກີດການຮົ່ວໄຫຼຂອງຂໍ້ມູນ (ພັນທະການລາຍງານຕໍ່ PDPC ພາຍໃນ 72 ຊົ່ວໂມງ) ແລ້ວຫຼືບໍ່

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

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

ລາຍການກວດສອບ:

• ການກຳນົດບົດບາດໃຫ້ຊັດເຈນ: ໄດ້ກຳນົດບົດບາດຂອງຜູ້ຄວບຄຸມຂໍ້ມູນ ແລະ ຜູ້ປະມວນຜົນຂໍ້ມູນລະຫວ່າງອົງກອນຂອງຕົນ ແລະ ຜູ້ໃຫ້ບໍລິການໄວ້ຢ່າງຊັດເຈນແລ້ວຫຼືບໍ່
• ສັນຍາການປະມວນຜົນຂໍ້ມູນ (DPA): ໄດ້ທຳສັນຍາເປັນລາຍລັກອັກສອນຕາມມາດຕາ 40 ຂອງ PDPA ແລ້ວຫຼືບໍ່
• ການຈຳກັດຂອບເຂດການປະມວນຜົນ: ໄດ້ຕັ້ງຄ່າໃຫ້ຜູ້ໃຫ້ບໍລິການບໍ່ສາມາດນຳຂໍ້ມູນໄປໃຊ້ຝຶກສອນໂມເດລຂອງຕົນໄດ້ (ເຊັ່ນ: ການ Opt-out) ແລ້ວຫຼືບໍ່
• ການຕິດຕາມ Sub-processor: ໃນກໍລະນີທີ່ຜູ້ໃຫ້ບໍລິການໃຊ້ຜູ້ຮັບຈ້າງຕໍ່ (Sub-processor) ໄດ້ຮັບຮູ້ລາຍຊື່ດັ່ງກ່າວແລ້ວຫຼືບໍ່
• ສະຖານທີ່ເກັບຂໍ້ມູນ: ໄດ້ກວດສອບແລ້ວຫຼືບໍ່ວ່າຜູ້ໃຫ້ບໍລິການປະມວນຜົນ ແລະ ເກັບຮັກສາຂໍ້ມູນຢູ່ໃນປະເທດໃດ
• ການລາຍງານເຫດການ: ໄດ້ຕົກລົງໃນສັນຍາກ່ຽວກັບຂະບວນການ ຫຼື Pipeline ການລາຍງານເມື່ອເກີດການຮົ່ວໄຫຼຂອງຂໍ້ມູນ (ພັນທະລາຍງານຕໍ່ PDPC ພາຍໃນ 72 ຊົ່ວໂມງ) ແລ້ວຫຼືບໍ່

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

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

ລາຍການກວດສອບ:

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

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

ໃນທາງປະຕິບັດ, ການຈັດການ Log ການນຳໃຊ້ເຄື່ອງມື AI ທັງໝົດດ້ວຍຕົນເອງນັ້ນບໍ່ແມ່ນສິ່ງທີ່ເປັນໄປໄດ້ໃນຄວາມເປັນຈິງ. ຈຶ່ງແນະນຳໃຫ້ຝັງກົນໄກບັນທຶກ Metadata ຂອງ Request/Response (ເຊັ່ນ: Timestamp, User ID, ຈຸດປະສົງການປະມວນຜົນ) ໂດຍອັດຕະໂນມັດຜ່ານ API Gateway ຫຼື ຊັ້ນ Proxy.

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

ລາຍການກວດສອບ:

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

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

ໃນທາງປະຕິບັດ, ການຈັດການ Log ການນຳໃຊ້ເຄື່ອງມື AI ທັງໝົດດ້ວຍມືນັ້ນບໍ່ແມ່ນສິ່ງທີ່ເປັນໄປໄດ້ຕາມຄວາມເປັນຈິງ. ຈຶ່ງແນະນຳໃຫ້ຝັງກົນໄກບັນທຶກ Metadata ຂອງ Request/Response (Timestamp, User ID, ຈຸດປະສົງການປະມວນຜົນ) ໂດຍອັດຕະໂນມັດຜ່ານ API Gateway ຫຼື ຊັ້ນ Proxy.

ຄຳຖາມທີ 1: PDPA ແລະ GDPR ແຕກຕ່າງກັນແນວໃດ? ມີຈຸດໃດທີ່ຕ້ອງລະວັງໃນດ້ານການນຳໃຊ້ AI?

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

ຄຳຖາມທີ 2: ຖ້າພະນັກງານປ້ອນຂໍ້ມູນສ່ວນຕົວລົງໃນ Generative AI ໃນລະຫວ່າງການເຮັດວຽກ, ຈະຖືວ່າລະເມີດ PDPA ບໍ?

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

ຄຳຖາມທີ 3: ຖ້າເຮັດ Anonymization ແລ້ວ ຈະຢູ່ນອກຂອບເຂດການບັງຄັບໃຊ້ PDPA ບໍ?

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

ຄຳຖາມທີ 4: ໃນກໍລະນີທີ່ໃຊ້ບໍລິການ Cloud AI ທີ່ຢູ່ນອກປະເທດໄທ, ຕ້ອງດຳເນີນການແນວໃດ?

ຈຳເປັນຕ້ອງດຳເນີນການຕາມມາດຕາ 28 (ການຮັບຮອງຄວາມພຽງພໍ) ຫຼື ມາດຕາ 29 (ມາດຕະການປົກປ້ອງທີ່ເໝາະສົມ) ຂອງ PDPA. ໃນຂະນະນີ້, ເນື່ອງຈາກ PDPC ຍັງບໍ່ທັນເປີດຕົວ ຫຼື Launch ລາຍຊື່ການຮັບຮອງຄວາມພຽງພໍ, ໃນທາງປະຕິບັດຈຶ່ງແນະນຳໃຫ້ຈັດຕຽມ Standard Contractual Clauses (SCC) ຫຼື Binding Corporate Rules (BCR). ສິ່ງສຳຄັນຄືການລວມເອົາຂໍ້ກຳນົດການປົກປ້ອງຂໍ້ມູນໃສ່ໃນສັນຍາກັບຜູ້ໃຫ້ບໍລິການ AI ແລະ ກຳນົດໃຫ້ຊັດເຈນກ່ຽວກັບສະຖານທີ່ປະມວນຜົນຂໍ້ມູນ, ມາດຕະການຄວາມປອດໄພ, ແລະ ຂະບວນການ ຫຼື Pipeline ການລາຍງານການຮົ່ວໄຫຼຂອງຂໍ້ມູນ.

Q1: PDPA ແລະ GDPR ແຕກຕ່າງກັນແນວໃດ? ມີຈຸດໃດທີ່ຕ້ອງລະວັງໃນແງ່ການນຳໃຊ້ AI?

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

Q2: ຫາກພະນັກງານປ້ອນຂໍ້ມູນສ່ວນຕົວລົງໃນ Generative AI ໃນລະຫວ່າງການປະຕິບັດໜ້າທີ່ ຈະຖືວ່າລະເມີດ PDPA ຫຼືບໍ່?

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

Q3: ຫາກທຳການ Anonymization ແລ້ວ ຈະພົ້ນຈາກຂອບເຂດການບັງຄັບໃຊ້ PDPA ຫຼືບໍ່?

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

Q4: ໃນກໍລະນີທີ່ໃຊ້ Cloud AI Service ຈາກຕ່າງປະເທດ ຕ້ອງດຳເນີນການໃດແດ່?

ຕ້ອງດຳເນີນການຕາມມາດຕາ 28 (ການຮັບຮອງຄວາມພຽງພໍ) ຫຼື ມາດຕາ 29 (ມາດຕະການປົກປ້ອງທີ່ເໝາະສົມ) ຂອງ PDPA. ໃນຂະນະນີ້ ເນື່ອງຈາກ PDPC ຍັງບໍ່ທັນເຜີຍແຜ່ລາຍຊື່ການຮັບຮອງຄວາມພຽງພໍ ໃນທາງປະຕິບັດຈຶ່ງແນະນຳໃຫ້ຈັດຕຽມ Standard Contractual Clauses (SCC) ຫຼື Binding Corporate Rules (BCR). ສິ່ງສຳຄັນຄືການລວມເອົາຂໍ້ກຳນົດການປົກປ້ອງຂໍ້ມູນໃສ່ໃນສັນຍາກັບຜູ້ໃຫ້ບໍລິການ AI ແລະ ກຳນົດໃຫ້ຊັດເຈນກ່ຽວກັບສະຖານທີ່ປະມວນຜົນຂໍ້ມູນ, ມາດຕະການຄວາມປອດໄພ ແລະ ຂະບວນການ ຫຼື Pipeline ການລາຍງານການຮົ່ວໄຫຼຂອງຂໍ້ມູນ.

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

ຂໍສະຫຼຸບຈຸດສຳຄັນຂອງ Checklist ທີ່ນຳສະເໜີໃນບົດຄວາມນີ້ອີກຄັ້ງ.

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

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

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

ຂໍສະຫຼຸບຈຸດສຳຄັນຂອງ Checklist ທີ່ນຳສະເໜີໃນບົດຄວາມນີ້ອີກຄັ້ງ.

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

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