ລາຍການກວດສອບການປະຕິບັດຕາມກົດໝາຍ PDPA ຂອງໄທ ແລະ ການນຳໃຊ້ AI ຄຽງຄູ່ກັນ

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

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

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

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

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

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

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

ສະຫຼຸບໂທດ:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ໃນກໍລະນີທີ່ໃຊ້ຂໍ້ມູນສ່ວນຕົວໃນການຝຶກຝົນໂມເດລ 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. ໃນຂັ້ນຕອນນີ້, ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກຄືການກວດສອບວ່າຂອບເຂດຂອງການປະມວນຜົນບໍ່ໄດ້ເກີນເລີຍຈາກຈຸດປະສົງທີ່ກຳນົດໄວ້ໃນເວລາເກັບກຳຂໍ້ມູນ ແລະ ບໍ່ໄດ້ລະເມີດສິດຂອງເຈົ້າຂອງຂໍ້ມູນ.

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 ທາງເທັກນິກທີ່ຕ້ອງຄຳນຶງເຖິງ. ຄວາມສົມດຸນລະຫວ່າງຂໍ້ກຳນົດດ້ານຄວາມຖືກຕ້ອງ ແລະ ຂໍ້ກຳນົດດ້ານການປະຕິບັດຕາມກົດໝາຍ ຈຳເປັນຕ້ອງໄດ້ຮັບການພິຈາລະນາເປັນກໍລະນີໄປ ຕາມແຕ່ລະ Use Case.

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

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

• ການກຳນົດໄລຍະເວລາການເກັບຮັກສາ: ໄດ້ກຳນົດໄລຍະເວລາການເກັບຮັກສາສຳລັບແຕ່ລະໝວດໝູ່ຂໍ້ມູນໂດຍອ້າງອີງຈາກຈຸດປະສົງການນຳໃຊ້ແລ້ວຫຼືບໍ່
• ການລຶບຂໍ້ມູນທີ່ເກີນໄລຍະເວລາ: ມີກົນໄກລຶບ ຫຼື ເຮັດໃຫ້ຂໍ້ມູນທີ່ເກີນໄລຍະເວລາການເກັບຮັກສາກາຍເປັນນິລນາມຢ່າງສະໝ່ຳສະເໝີແລ້ວຫຼືບໍ່
• ຂໍ້ມູນພາຍໃນ 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 ທີ່ຝຶກສອນແລ້ວຢ່າງສົມບູນນັ້ນ, ຍັງເປັນສາຂາທີ່ກຳລັງພັດທະນາທາງດ້ານເຕັກນິກ. ມາດຕະການຮັບມືທີ່ເປັນຈິງທີ່ສາມາດພິຈາລະນາໄດ້ມີດັ່ງນີ້:

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

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

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

ໃນກໍລະນີທີ່ນຳ 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 ແລະໄດ້ເບິ່ງ ຫຼື ປະມວນຜົນຂໍ້ມູນໃດ ຫຼືບໍ່
• ການຈັດການເວີຊັນຂອງ 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 ການລາຍງານການຮົ່ວໄຫຼຂອງຂໍ້ມູນ.

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

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

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

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