ข้อตกลงการประมวลผลข้อมูลส่วนบุคคล (Data Processing Agreement)

อ้างอิง TOR: ข้อ 14.1 (ผู้ควบคุมและผู้ประมวลผลข้อมูลส่วนบุคคล), ข้อ 14.2 (การเก็บข้อมูลเท่าที่จำเป็น), ข้อ 14.3 (การเข้ารหัส การควบคุมสิทธิ และการปิดบังข้อมูลส่วนบุคคล), ข้อ 14.4 (สิทธิของเจ้าของข้อมูล), ข้อ 4.11.3 (การลบทำลายข้อมูลและหนังสือรับรอง), ภาคผนวก ก ข้อ 1.1.3 (การปฏิบัติตาม PDPA) กฎหมายที่เกี่ยวข้อง: พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (ต่อไปเรียกว่า "PDPA")

สถานะเอกสาร: เอกสารนี้เป็น ร่างข้อตกลง ที่จัดทำเพื่อประกอบระบบสาธิต (Demo) ยังไม่มีการลงนามและไม่ใช่ความเห็นทางกฎหมาย มาตรการทางเทคนิคที่ระบุอ้างจากการออกแบบของระบบสาธิต ถ้อยคำที่มีผลผูกพัน ระยะเวลา และรายชื่อผู้ประมวลผลช่วง ให้เป็นไปตามข้อตกลงฉบับลงนามซึ่งผ่านการพิจารณาของเจ้าหน้าที่คุ้มครองข้อมูลส่วนบุคคลและฝ่ายกฎหมายของมหาวิทยาลัย ข้อมูลผู้ใช้ในระบบสาธิตเป็นข้อมูลจำลอง

1. คู่สัญญาและบทบาท (ข้อ 14.1)

บทบาท	คู่สัญญา	หน้าที่โดยสรุป
ผู้ควบคุมข้อมูลส่วนบุคคล (Data Controller)	มหาวิทยาลัยมหามกุฏราชวิทยาลัย (มมร.)	กำหนดวัตถุประสงค์และวิธีการประมวลผล แจ้งเจ้าของข้อมูล ขอความยินยอม ตัดสินใจเกี่ยวกับคำขอใช้สิทธิ และแจ้งเหตุละเมิดต่อหน่วยงานกำกับ
ผู้ประมวลผลข้อมูลส่วนบุคคล (Data Processor)	ผู้รับจ้าง (ระบุชื่อนิติบุคคลเมื่อทำสัญญา)	ประมวลผลข้อมูลตามคำสั่งที่เป็นลายลักษณ์อักษรของมหาวิทยาลัยเท่านั้น จัดให้มีมาตรการรักษาความมั่นคงปลอดภัย แจ้งเหตุละเมิด และจัดทำบันทึกรายการประมวลผล

บทบาทดังกล่าวระบุต่อผู้ใช้ในหน้านโยบายความเป็นส่วนตัวของระบบ (/privacy-policy)

2. ขอบเขต วัตถุประสงค์ และระยะเวลาการประมวลผล

รายการ	รายละเอียด
ลักษณะการประมวลผล	พัฒนา ติดตั้ง ทดสอบ บำรุงรักษา และสนับสนุนระบบแชตบอตปัญญาประดิษฐ์เฉพาะทางพระพุทธศาสนาและเว็บไซต์
วัตถุประสงค์	(1) ให้บริการถาม-ตอบและ Dhamma Talk แก่ผู้ใช้ (2) ยืนยันตัวตนและควบคุมสิทธิ์ (3) ควบคุมปริมาณการใช้โทเคนและค่าใช้จ่าย (4) ปรับปรุงคุณภาพคำตอบจากผลการให้คะแนน (5) รักษาความมั่นคงปลอดภัยและตรวจสอบย้อนหลัง (6) จัดทำสถิติการใช้งานสำหรับผู้บริหาร
ระยะเวลา	ตลอดอายุสัญญาและระยะเวลารับประกัน เท่าที่ผู้รับจ้างยังเข้าถึงระบบเพื่อปฏิบัติงาน
เจ้าของข้อมูล	ผู้ใช้ทั่วไป ผู้ใช้ที่ได้รับสิทธิ์ Dhamma Talk ผู้ดูแลระบบ และบุคคลที่ถูกกล่าวถึงในข้อความสนทนา
ข้อจำกัด	ผู้รับจ้างไม่ประมวลผลเพื่อวัตถุประสงค์ของตนเอง ไม่ขาย ไม่เปิดเผย และไม่นำข้อมูลไปฝึกสอนโมเดลปัญญาประดิษฐ์

3. ประเภทข้อมูลส่วนบุคคลที่ประมวลผล

ลำดับ	ประเภทข้อมูล	รายละเอียด	วัตถุประสงค์	การคุ้มครองเฉพาะ
1	อีเมล	อีเมลที่ใช้สมัครหรือได้รับจากผู้ให้บริการเข้าสู่ระบบ	ยืนยันตัวตน ติดต่อผู้ใช้	เข้ารหัสระดับคอลัมน์ AES-256-GCM และเก็บค่าแฮชสำหรับค้นหา
2	ชื่อที่แสดง (Display Name)	ชื่อที่ผู้ใช้กำหนดหรือได้รับจากผู้ให้บริการเข้าสู่ระบบ	แสดงผลในระบบ	เข้ารหัสระดับคอลัมน์ AES-256-GCM
3	รหัสประจำตัวจากผู้ให้บริการ OAuth	รหัสบัญชีจาก Google หรือ Facebook	เชื่อมบัญชีเมื่อเข้าสู่ระบบด้วย Gmail/Facebook	เก็บเฉพาะรหัสอ้างอิง ไม่เก็บรหัสผ่านหรือโทเคนของผู้ให้บริการเกินความจำเป็น
4	รหัสผ่าน	เฉพาะบัญชีที่สมัครด้วยอีเมล	ยืนยันตัวตน	เก็บเป็นค่าแฮช (bcrypt) ไม่เก็บรหัสผ่านจริง
5	บทสนทนา	คำถาม คำตอบ และร่าง Dhamma Talk ของผู้ใช้	ให้บริการ แสดงประวัติ	ลบอัตโนมัติตามระยะเก็บรักษา มีสำเนาที่ปิดบังข้อมูลส่วนบุคคล การเข้าดูโดยผู้ดูแลถูกบันทึก
6	ผลการให้คะแนนคำตอบ (Feedback)	การกดชอบ/ไม่ชอบต่อคำตอบ	ปรับปรุงคุณภาพ	ผูกกับข้อความ ไม่เปิดเผยต่อสาธารณะ
7	ข้อมูลการใช้โทเคน	จำนวนโทเคน Input/Thinking/Output ต่อคำขอและต่อบัญชี	ควบคุมเพดานและประมาณการค่าใช้จ่าย	เข้าถึงได้เฉพาะผู้ดูแล
8	บันทึกการตรวจสอบ (Audit Log) และที่อยู่ IP	เวลา ผู้กระทำ ที่อยู่ IP ประเภทเหตุการณ์ ค่าก่อน/หลัง ผลลัพธ์ รวมถึงบันทึกการพยายามเข้าสู่ระบบ	ความมั่นคงปลอดภัยและการตรวจสอบ	แก้ไขและลบไม่ได้ มี Hash Chain
9	บันทึกความยินยอม	เวอร์ชันนโยบายที่ยินยอมและเวลา	พิสูจน์ความยินยอม	เก็บคู่กับบัญชี
10	ข้อมูลการใช้งานเว็บไซต์	สถิติจาก Google Analytics หรือเทียบเท่า (ก.1.5.1)	วิเคราะห์การใช้งาน	โหลดหลังผู้ใช้ยินยอมคุกกี้เท่านั้น

ระบบไม่ได้ออกแบบให้เก็บข้อมูลส่วนบุคคลที่อ่อนไหวตามมาตรา 26 ของ PDPA อย่างไรก็ตาม ผู้ใช้อาจพิมพ์ข้อมูลดังกล่าว (เช่น ความเชื่อทางศาสนา หรือข้อมูลสุขภาพ) ลงในข้อความสนทนาเอง ระบบจึงมีข้อความเตือนใต้กล่องคำถาม ปฏิเสธการให้คำปรึกษาด้านสุขภาพจิต (ก.4.4.3) และปิดบังข้อมูลส่วนบุคคลในสำเนาบทสนทนา

4. การเก็บข้อมูลเท่าที่จำเป็น (ข้อ 14.2)

1. แบบฟอร์มสมัครสมาชิก (/register) ขอข้อมูลเพียง 3 รายการ คือ อีเมล รหัสผ่าน และชื่อที่แสดง พร้อมช่องให้ความยินยอม ไม่ขอเลขประจำตัวประชาชน วันเกิด ที่อยู่ หมายเลขโทรศัพท์ หรือข้อมูลอื่น
2. การเข้าสู่ระบบด้วย Gmail หรือ Facebook ขอเฉพาะข้อมูลโปรไฟล์พื้นฐาน (อีเมล ชื่อ และรหัสประจำตัวจากผู้ให้บริการ)
3. ตามการออกแบบของระบบ ข้อมูลที่ส่งไปยัง LLM API จำกัดเฉพาะข้อความคำถาม บริบทบทสนทนาที่จำเป็น และข้อความคัมภีร์ที่สืบค้นได้ ไม่ส่งอีเมล ชื่อที่แสดง หรือรหัสบัญชีของผู้ใช้
4. Dashboard แสดงข้อมูลเชิงสถิติ รายการบัญชีที่ใช้โทเคนสูงสุดเข้าถึงได้เฉพาะผู้ดูแล
5. การเพิ่มประเภทข้อมูลที่เก็บต้องได้รับความเห็นชอบจากมหาวิทยาลัยและปรับปรุงนโยบายความเป็นส่วนตัวก่อน

5. มาตรการรักษาความมั่นคงปลอดภัย (ข้อ 14.3)

ด้าน	มาตรการ	รายละเอียดในระบบ
การเข้ารหัสขณะจัดเก็บ (At Rest)	เข้ารหัสระดับคอลัมน์ด้วย AES-256-GCM	อีเมลและชื่อที่แสดงถูกเข้ารหัสก่อนบันทึก กุญแจเก็บในตัวแปรสภาพแวดล้อม (DATA_ENCRYPTION_KEY) แยกจากฐานข้อมูล การค้นหาด้วยอีเมลใช้ค่าแฮช SHA-256
การเข้ารหัสระหว่างส่ง (In Transit)	TLS	ระบบ Production ใช้ใบรับรองที่ออกโดยผู้ให้บริการที่เชื่อถือได้ ระบบสาธิตใช้ใบรับรองแบบ Self-signed
การควบคุมสิทธิ	RBAC 3 บทบาท (Super Admin, Admin, ผู้ใช้ทั่วไป)	ตรวจสิทธิ์ฝั่งเซิร์ฟเวอร์ทุกคำขอ ผู้ใช้เข้าถึงได้เฉพาะบทสนทนาของตนเอง
การจำกัดการเข้าถึงของผู้ดูแล	IP Allowlist และรหัสผ่านซับซ้อน	หน้าและ API ของผู้ดูแลเข้าได้เฉพาะจาก IP ที่อนุญาต รหัสผ่านผู้ดูแลไม่น้อยกว่า 12 ตัวอักษร ผสมอักขระ 4 ชนิด
การปิดบังข้อมูลส่วนบุคคล (PII Masking)	สำเนาบทสนทนาที่ปิดบังแล้ว	ปิดบังเลขประจำตัวประชาชน หมายเลขโทรศัพท์ อีเมล และชื่อบุคคลที่มีคำนำหน้า ในสำเนาข้อความที่ใช้เพื่อการวิเคราะห์และตรวจสอบ
บันทึกการตรวจสอบ	Audit Log แบบ Append-only พร้อม Hash Chain	ฐานข้อมูลปฏิเสธการแก้ไขและลบแถว แต่ละแถวมีค่าแฮชเชื่อมกับแถวก่อนหน้า ตรวจความสมบูรณ์ได้จากหน้า /admin/audit-log การเปิดดูบทสนทนาของผู้ใช้โดยผู้ดูแลถูกบันทึกทุกครั้ง
การป้องกันการโจมตี	Input Validation ฝั่งเซิร์ฟเวอร์ CSRF Token การล็อกบัญชีเมื่อเข้าสู่ระบบผิดซ้ำ Rate Limit	ตามภาคผนวก ก ข้อ 2.1
การทดสอบความปลอดภัย	Vulnerability Scan และ Penetration Test	ไม่มีช่องโหว่ระดับ High/Critical ก่อนใช้งานจริง (4.8, ก.2.2.2)
การสำรองข้อมูล	สำเนาสำรองได้รับการคุ้มครองระดับเดียวกับข้อมูลหลัก	คู่มือ Backup/Restore และการทดสอบกู้คืน (ก.1.6.3)
มาตรการเชิงองค์กร	บุคลากรลงนามรักษาความลับ อบรมด้านการคุ้มครองข้อมูล เข้าถึงตามความจำเป็น	ดูเอกสาร confidentiality-statement

ข้อจำกัดของระบบสาธิต: ระบบสาธิตไม่มีบริการจัดการกุญแจ (KMS) ของผู้ให้บริการ Cloud กุญแจเข้ารหัสอยู่ในไฟล์ .env บนเครื่องที่รัน สำหรับระบบจริงจะใช้บริการจัดการความลับของ Cloud ที่มหาวิทยาลัยจัดหา และกำหนดรอบการหมุนเวียนกุญแจ

6. ระยะเวลาการเก็บรักษาและการลบข้อมูล

ข้อมูล	ระยะเวลาเก็บรักษา	วิธีลบ	TOR
บทสนทนาและร่าง Dhamma Talk	90 วัน (ค่าตั้งต้น ผู้ดูแลปรับได้ในหน้า /admin/ai-config)	ลบอัตโนมัติตามรอบที่กำหนด ผู้ใช้ลบเองได้ก่อนกำหนดที่หน้า /chat/history	ก.3.5.1, ก.6.2.2
บัญชีผู้ใช้ (อีเมล ชื่อที่แสดง รหัสจากผู้ให้บริการ)	ตลอดเวลาที่บัญชียังใช้งาน	ลบเมื่อเจ้าของข้อมูลร้องขอ หรือผู้ดูแลลบบัญชี	14.4, ก.6.1.2
ผลการให้คะแนนคำตอบและข้อมูลการใช้โทเคน	ตามนโยบายที่มหาวิทยาลัยกำหนด	ลบพร้อมบัญชีหรือทำให้ไม่สามารถระบุตัวบุคคลได้	—
Audit Log	ไม่น้อยกว่า 90 วัน ไม่มีการลบอัตโนมัติ	ไม่ลบระหว่างอายุการใช้งาน มหาวิทยาลัยเป็นผู้กำหนดนโยบายจัดเก็บระยะยาว	ก.6.5.3
สำเนาสำรอง	ตามรอบการสำรองที่กำหนดในคู่มือ Backup/Restore	หมดอายุตามรอบ	ก.1.6.3

การลบอัตโนมัติแต่ละรอบบันทึกจำนวนรายการที่ลบไว้ใน Audit Log

7. การรองรับสิทธิของเจ้าของข้อมูล (ข้อ 14.4)

7.1 ช่องทางและขั้นตอน

flowchart LR
    A["เจ้าของข้อมูล<br/>หน้า /privacy"] -->|ยื่นคำขอ| B["ระบบบันทึกคำขอ<br/>และ Audit Log"]
    B --> C["ผู้ดูแลระบบ<br/>/admin/privacy-requests"]
    C -->|ตรวจสอบตัวตนและพิจารณา<br/>ตามคำสั่งของมหาวิทยาลัย| D{ผลการพิจารณา}
    D -->|อนุมัติ| E["ดำเนินการ: ส่งสำเนา / ลบ / ระงับ"]
    D -->|ปฏิเสธ| F["แจ้งเหตุผลแก่เจ้าของข้อมูล"]
    E --> G["แจ้งผลและปิดคำขอ"]
    F --> G

7.2 สิทธิและวิธีดำเนินการ

สิทธิ	วิธีใช้สิทธิของเจ้าของข้อมูล	การดำเนินการในระบบ
ขอเข้าถึงและขอรับสำเนาข้อมูล	กด "ดาวน์โหลดสำเนาข้อมูล" ที่หน้า /privacy	ระบบสร้างไฟล์ JSON ของข้อมูลที่ระบบเก็บเกี่ยวกับผู้ใช้นั้น เช่น ข้อมูลบัญชีและบทสนทนา
ขอลบข้อมูลหรือลบบัญชี	ยื่นคำขอที่หน้า /privacy	คำขอปรากฏที่ /admin/privacy-requests ผู้ดูแลดำเนินการลบและบันทึกผล
ถอนความยินยอม	ยื่นที่หน้า /privacy ซึ่งอธิบายผลของการถอน	บัญชีถูกระงับการใช้งาน เนื่องจากบริการต้องอาศัยความยินยอม
ขอแก้ไขข้อมูลให้ถูกต้อง	แจ้งผ่านผู้ดูแลหรือช่องทางที่มหาวิทยาลัยกำหนด	ผู้ดูแลแก้ไขที่หน้า /admin/users
คัดค้านหรือขอระงับการประมวลผล	แจ้งผ่านช่องทางที่มหาวิทยาลัยกำหนด	ผู้ดูแลระงับบัญชีและบันทึกคำขอ
ติดตามสถานะคำขอ	ดู "ประวัติคำขอ" ที่หน้า /privacy	แสดงสถานะคำขอแต่ละรายการ

7.3 หน้าที่ของแต่ละฝ่าย

1. มหาวิทยาลัยในฐานะผู้ควบคุมข้อมูลเป็นผู้พิจารณาและตอบคำขอ ภายในระยะเวลาที่ PDPA กำหนด (คำขอเข้าถึงและขอรับสำเนาต้องดำเนินการภายใน 30 วันนับแต่วันที่ได้รับคำขอ)
2. ผู้รับจ้างในฐานะผู้ประมวลผลข้อมูลจัดให้มีเครื่องมือในระบบ ให้ความช่วยเหลือทางเทคนิค และส่งต่อคำขอที่ได้รับโดยตรงให้มหาวิทยาลัยโดยไม่ชักช้า ผู้รับจ้างไม่ตอบคำขอแทนมหาวิทยาลัยเว้นแต่ได้รับมอบหมาย
3. ผู้ดูแลสามารถสร้างคำขอแทนเจ้าของข้อมูลที่ติดต่อผ่านช่องทางอื่นได้ที่หน้ารายละเอียดผู้ใช้
4. Audit Log ที่เกี่ยวข้องกับบัญชีที่ถูกลบยังคงอยู่เพื่อการตรวจสอบ โดยเก็บเฉพาะรหัสอ้างอิงและรายละเอียดเหตุการณ์

8. ผู้ประมวลผลช่วงและผู้รับข้อมูล (Sub-processors)

ผู้รับข้อมูล	ข้อมูลที่ได้รับ	วัตถุประสงค์	ผู้จัดหา	หมายเหตุ
ผู้ให้บริการ LLM API	ข้อความสนทนา (คำถามของผู้ใช้ บริบทบทสนทนา ร่าง Dhamma Talk) และข้อความคัมภีร์ที่สืบค้นได้	สร้างคำตอบและประเมินคำตอบ	มหาวิทยาลัย (ข้อ 4.6.1)	ไม่ส่งอีเมล ชื่อ หรือรหัสบัญชี แต่ข้อความที่ผู้ใช้พิมพ์อาจมีข้อมูลส่วนบุคคลปะปน ในระบบสาธิตผู้ให้บริการคือ SCB 10X (โมเดล Typhoon)
ผู้ให้บริการ Cloud	ข้อมูลทั้งหมดของระบบในรูปแบบที่จัดเก็บ	โฮสต์ระบบ ฐานข้อมูล และสำเนาสำรอง	มหาวิทยาลัย (ข้อ 4.6.1)	ระบบสาธิตรันในเครื่องเดียว ไม่มีผู้ให้บริการ Cloud
ผู้ให้บริการเข้าสู่ระบบ (Google, Facebook)	ข้อมูลการยืนยันตัวตนของผู้ใช้ที่เลือกช่องทางนี้	เข้าสู่ระบบตาม ก.3.3.2	มหาวิทยาลัยเป็นเจ้าของบัญชีนักพัฒนา	ระบบสาธิตใช้ผู้ให้บริการจำลองภายในระบบ
ผู้ให้บริการวิเคราะห์เว็บไซต์ (Google Analytics หรือเทียบเท่า)	ข้อมูลการใช้งานเว็บไซต์	สถิติการใช้งาน (ก.1.5.1)	มหาวิทยาลัย	ทำงานหลังผู้ใช้ยินยอมคุกกี้เท่านั้น
ผู้ให้บริการอีเมล (SMTP)	อีเมลแจ้งเตือนถึงผู้ดูแลระบบ	แจ้งเตือนความผิดปกติ (ก.4.10.2)	มหาวิทยาลัย	ไม่มีข้อมูลของผู้ใช้ทั่วไป

ข้อตกลงเกี่ยวกับผู้ประมวลผลช่วง

1. บริการ Cloud และ LLM API เป็นบริการที่มหาวิทยาลัยจัดหาและทำสัญญาโดยตรง สถานะทางกฎหมายของผู้ให้บริการดังกล่าว (เป็นผู้ประมวลผลของมหาวิทยาลัยโดยตรง หรือผู้ประมวลผลช่วง) ให้ระบุในข้อตกลงฉบับลงนาม ตารางข้างต้นจัดทำเพื่อความโปร่งใสว่าข้อมูลใดไปที่ใด
2. ผู้รับจ้างจะไม่ว่าจ้างหรือส่งข้อมูลให้ผู้ประมวลผลช่วงรายอื่นโดยไม่ได้รับความยินยอมเป็นลายลักษณ์อักษรจากมหาวิทยาลัย (สอดคล้องกับข้อ 16.1)
3. ก่อนเลือกผู้ให้บริการ LLM มหาวิทยาลัยควรพิจารณาเงื่อนไขเรื่องการเก็บรักษาข้อมูล การนำข้อมูลไปฝึกสอนโมเดล และที่ตั้งของเครื่องแม่ข่าย หากมีการส่งข้อมูลไปต่างประเทศต้องเป็นไปตามหลักเกณฑ์ของ PDPA ว่าด้วยการส่งหรือโอนข้อมูลไปต่างประเทศ
4. การเปลี่ยนผู้ให้บริการ LLM ทำได้ในหน้า /admin/ai-config โดยไม่แก้โค้ด และต้องปรับปรุงตารางนี้และนโยบายความเป็นส่วนตัวให้สอดคล้อง

9. การแจ้งเหตุละเมิดข้อมูลส่วนบุคคล

ขั้นตอน	การดำเนินการ	ผู้รับผิดชอบ	กรอบเวลา
1. ตรวจพบ	พบหรือสงสัยว่ามีการเข้าถึง เปิดเผย แก้ไข สูญหาย หรือทำลายข้อมูลโดยมิชอบ จากการแจ้งเตือนของระบบ Audit Log หรือรายงานจากผู้ใช้	ผู้รับจ้าง / ผู้ดูแลระบบ	ทันที
2. ควบคุมเหตุ	ระงับบัญชีหรือการเข้าถึงที่เกี่ยวข้อง เปลี่ยนข้อมูลรับรอง เปิดโหมดไม่พร้อมให้บริการหากจำเป็น	ผู้รับจ้าง	ทันที
3. แจ้งมหาวิทยาลัย	แจ้งผู้ประสานงานและเจ้าหน้าที่คุ้มครองข้อมูลส่วนบุคคลของมหาวิทยาลัยผ่านช่องทางเร่งด่วน	ผู้รับจ้าง	โดยไม่ชักช้า และไม่เกิน 24 ชั่วโมงนับแต่ทราบเหตุ (ข้อเสนอของผู้รับจ้าง)
4. รายงานข้อเท็จจริง	ลักษณะเหตุ ประเภทและจำนวนข้อมูลและเจ้าของข้อมูลที่ได้รับผลกระทบโดยประมาณ ผลกระทบที่อาจเกิด และมาตรการที่ดำเนินการแล้ว	ผู้รับจ้าง	ภายใน 48 ชั่วโมง และปรับปรุงเมื่อมีข้อมูลเพิ่ม
5. แจ้งหน่วยงานกำกับและเจ้าของข้อมูล	พิจารณาและแจ้งสำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคลภายใน 72 ชั่วโมงนับแต่ทราบเหตุ และแจ้งเจ้าของข้อมูลกรณีมีความเสี่ยงสูง ตามที่ PDPA กำหนด	มหาวิทยาลัย (ผู้รับจ้างสนับสนุนข้อมูล)	ตามกฎหมาย
6. แก้ไขและป้องกันซ้ำ	วิเคราะห์สาเหตุ แก้ไข ทดสอบซ้ำ และบันทึกเป็นข้อบกพร่องระดับสูงใน Defect Log พร้อมมาตรการป้องกัน	ผู้รับจ้าง	ตามกรอบเวลา SLA ข้อ 12.3

10. การตรวจสอบและความร่วมมือ

1. ผู้รับจ้างจัดทำและเก็บรักษาบันทึกรายการกิจกรรมการประมวลผลในส่วนของผู้ประมวลผลข้อมูล และส่งให้มหาวิทยาลัยเมื่อร้องขอ
2. มหาวิทยาลัยหรือผู้ที่มหาวิทยาลัยมอบหมายมีสิทธิตรวจสอบการปฏิบัติตามข้อตกลงนี้ โดยแจ้งล่วงหน้าตามสมควร ผู้รับจ้างให้ความร่วมมือและจัดเตรียมหลักฐาน เช่น Audit Log รายงานทดสอบความปลอดภัย และรายการสิทธิ์ของบุคลากร
3. ผู้รับจ้างให้ความช่วยเหลือมหาวิทยาลัยในการประเมินผลกระทบด้านการคุ้มครองข้อมูลส่วนบุคคลเมื่อมีการเปลี่ยนแปลงสำคัญ เช่น เปลี่ยนผู้ให้บริการ LLM หรือเพิ่มประเภทข้อมูล
4. ผู้รับจ้างแจ้งมหาวิทยาลัยทันทีหากเห็นว่าคำสั่งของมหาวิทยาลัยอาจขัดต่อ PDPA

11. การส่งคืนและการลบทำลายข้อมูลเมื่อสิ้นสุดสัญญา (ข้อ 4.11.3)

1. เมื่อสัญญาสิ้นสุด ผู้รับจ้างส่งมอบระบบและข้อมูลทั้งหมดให้มหาวิทยาลัยตาม Transition Plan และยุติสิทธิ์การเข้าถึงของบุคลากรผู้รับจ้าง
2. ผู้รับจ้างลบหรือทำลายข้อมูลส่วนบุคคลและข้อมูลของมหาวิทยาลัยทั้งหมดที่อยู่ในความครอบครองของผู้รับจ้าง รวมถึงสภาพแวดล้อมพัฒนา/ทดสอบ สำเนาสำรอง และอุปกรณ์ของบุคลากร เว้นแต่กฎหมายกำหนดให้เก็บรักษา
3. ผู้รับจ้างออกหนังสือรับรองการลบทำลายข้อมูลให้มหาวิทยาลัย โดยระบุขอบเขต รายการ วิธีการ วันเวลา และผู้ดำเนินการ
4. ระบบมีหน้า /admin/data-destruction (เฉพาะ Super Admin) สำหรับลบข้อมูลตามขอบเขตที่เลือก ได้แก่ ไฟล์ที่อัปโหลด บทสนทนา ข้อมูลการใช้โทเคน ผลการประเมิน และบัญชีผู้ใช้ที่ไม่ใช่ผู้ดูแล โดยต้องพิมพ์ข้อความยืนยันก่อนลบ แล้วระบบออกใบรับรองที่มีรายการ จำนวน ค่าแฮช SHA-256 ของรายการก่อนลบ วันเวลา และผู้สั่ง พร้อมบันทึกเหตุการณ์ใน Audit Log
5. Audit Log ไม่ถูกลบโดยกระบวนการนี้ และส่งมอบให้มหาวิทยาลัยพร้อมระบบ

12. ความรับผิด

1. ผู้รับจ้างรับผิดต่อความเสียหายที่เกิดจากการประมวลผลที่ฝ่าฝืนข้อตกลงนี้ ฝ่าฝืนคำสั่งของมหาวิทยาลัย หรือไม่ปฏิบัติตามหน้าที่ของผู้ประมวลผลข้อมูลตาม PDPA
2. หากผู้รับจ้างประมวลผลนอกเหนือคำสั่งของมหาวิทยาลัย ให้ถือว่าผู้รับจ้างเป็นผู้ควบคุมข้อมูลสำหรับการประมวลผลนั้นตามที่ PDPA บัญญัติ
3. ข้อตกลงนี้เป็นส่วนหนึ่งของสัญญาจ้าง กรณีขัดแย้งกับเอกสารอื่นให้เป็นไปตามลำดับในข้อ 16.3 ของ TOR

13. การลงนาม

ผู้ควบคุมข้อมูลส่วนบุคคล	ผู้ประมวลผลข้อมูลส่วนบุคคล
มหาวิทยาลัยมหามกุฏราชวิทยาลัย	(ชื่อนิติบุคคลของผู้รับจ้าง — ระบุเมื่อทำสัญญา)
ลงชื่อ ........................................	ลงชื่อ ........................................
(ผู้มีอำนาจลงนาม)	(ผู้มีอำนาจลงนาม)
วันที่ ........................................	วันที่ ........................................