บริษัทความปลอดภัย RedAccess ค้นหาแอปที่สร้างด้วยเครื่องมือเขียนโค้ด AI และเผยแพร่บนโฮสติ้งของเครื่องมือเหล่านั้นเอง พบมากกว่า 5,000 แอปที่แทบไม่มีมาตรการความปลอดภัยหรือการยืนยันตัวตนใด ๆ ในภาพหน้าจอที่ส่งให้ Wired มีภาพหนึ่งที่ดูเหมือนตารางมอบหมายงานของโรงพยาบาล พร้อมข้อมูลส่วนบุคคลของแพทย์
เครื่องมือเขียนโค้ด AI ทำให้ขั้นตอนสร้างแอปง่ายขึ้น การเปิดเผยข้อมูลในแอปที่สร้างด้วย AI สำหรับทีม HR เกิดภายหลัง เมื่อเครื่องมือติดตามวันลาหรือแบบให้คะแนนสัมภาษณ์เปิดใช้งานจริงในสภาพเดียวกับตอนสาธิต คือมีลิงก์สาธารณะ บัญชีผู้ดูแลหนึ่งบัญชี และตารางพนักงานทั้งหมดอยู่ด้านหลัง
TL;DR (สรุปย่อ)
- เครื่องมือที่ช่วยตัดสินว่าใครจะได้รับการจ้างงานหรือเลื่อนตำแหน่ง หรือบุคคลจะได้รับคะแนนอย่างไร อาจเป็นระบบความเสี่ยงสูงตาม EU AI Act ต้องส่งให้ IT และฝ่ายกฎหมายหรือ DPO ตรวจสอบก่อนให้คะแนนใคร
- ห้ามเก็บระเบียนพนักงานบนโฮสติ้งของเครื่องมือเขียนโค้ด AI เอง ทางเลือกเริ่มต้นคือเซิร์ฟเวอร์ที่ทีมควบคุม เข้าถึงได้ผ่านเครือข่ายส่วนตัวเท่านั้น และเพิ่มการลงชื่อเข้าใช้ด้วยบัญชีบริษัทที่ทางเข้าเมื่อผู้จัดการหรือพนักงานทั้งหมดต้องเข้าถึง
- ให้เครื่องมือ AI ตัวเดียวกับที่สร้างแอปทำการแก้ไข: ลดฟิลด์ที่อ่าน แยกมุมมองของผู้ดูแล HR ผู้จัดการ และพนักงาน นำข้อมูลรับรองออกจากโค้ด ลดข้อมูลที่ส่งออกภายนอก บันทึกว่าใครเปิดระเบียนใด และจัดการคำขอลบโดยคำนึงถึงข้อกำหนดการเก็บรักษา การตรวจสอบที่คุณทำเองเป็นสิ่งยืนยันแต่ละข้อ ไม่ใช่รายงานของ AI เอง
- สิทธิ์เข้าถึงเครื่องมือต้องสิ้นสุดในวันที่การจ้างงานสิ้นสุด มีบุคคลที่ระบุชื่อชัดเจนหนึ่งคนรับผิดชอบ และการเลือกที่ตั้งเซิร์ฟเวอร์ไม่ได้ทำให้ปฏิบัติตามข้อกำหนดโดยอัตโนมัติ
ข้อผิดพลาดในการติดตั้งที่ทำให้ข้อมูลพนักงานเปิดเผย
เครื่องมือ HR ที่สร้างด้วย AI อาจเปิดเผยข้อมูลพนักงานต่อใครก็ตามที่พบลิงก์ ผู้มีข้อมูลรับรองที่ถูกวางในแชตหรือโค้ด เพื่อนร่วมงานที่เปิดระเบียนของผู้อื่น บริการภายนอกที่ได้รับข้อมูล และผู้ที่ลาออกแล้ว โดยไม่มีบันทึกว่าใครดูข้อมูล การอ่านตารางพนักงานทั้งตารางทำให้ทุกช่องทางมีขอบเขตการเปิดเผยกว้างขึ้น
| ความผิดพลาด | สิ่งที่เปิดเผย | วิธีแก้ | จุดที่แก้ไข |
|---|---|---|---|
| เผยแพร่บนโฮสติ้งของเครื่องมือ AI เองด้วยลิงก์สาธารณะ | บันทึกการจัดสิ่งอำนวยความสะดวกที่เหมาะสมและการลาทางการแพทย์ในเครื่องมือติดตามวันลา ซึ่งทุกคนที่มี URL อ่านได้ | ย้ายไปเซิร์ฟเวอร์ที่ทีมควบคุมบนเครือข่ายส่วนตัว | ที่ที่เครื่องมือทำงาน |
| วางรหัสผ่านฐานข้อมูลหรือโทเค็น API ของ HRIS หรือระบบเงินเดือนลงในแชตหรือโค้ด | ทุกคนที่มีประวัติแชตหรือคลังโค้ดเข้าถึงระบบ HR ได้ รวมถึง SSN และเลขประจำตัวประชาชน | เปลี่ยนข้อมูลรับรองและเก็บไว้นอกโค้ด | ข้อมูลรับรอง |
| อ่านตารางพนักงานทั้งหมด ทั้งที่ต้องการเพียงสามคอลัมน์ | SSN เงินเดือน สถานะการย้ายถิ่นฐานและสิทธิ์ทำงาน อยู่ในเครื่องมือที่มีหน้าที่แสดงวันลาคงเหลือ | บัญชีฐานข้อมูลที่เข้าถึงเฉพาะฟิลด์ที่เครื่องมือต้องใช้ | ฟิลด์ |
| ทุกคนที่ลงชื่อเข้าใช้เห็นทุกระเบียน | ผู้จัดการเห็นเงินเดือนผู้จัดการคนอื่น และคะแนนประเมินผลงานปรากฏให้ทั้งบริษัทเห็น | สามบทบาทที่ตรวจสอบบนเซิร์ฟเวอร์ | บทบาท |
| ส่งข้อมูลผู้สมัครไปยังบริการภายนอก | ข้อมูลระบุตัวบุคคล (PII) ในกระบวนการสรรหา เช่น ประวัติย่อและบันทึกสัมภาษณ์ ถูกคัดลอกไปยัง AI API หรือสคริปต์วิเคราะห์ | ตรวจสอบข้อมูลที่ออกจากเครื่องมือและลดปริมาณ | ข้อมูลขาออก |
| สิทธิ์เข้าถึงยังคงอยู่หลังสิ้นสุดการจ้างงาน | บัญชีผู้ลาออกหรือบัญชีผู้ดูแลของผู้สร้างยังเปิดระเบียนของทุกคนได้ | การลงชื่อเข้าใช้ด้วยบัญชีบริษัทพร้อมเพิกถอนเซสชัน เพื่อให้ขั้นตอนออกจากงานปิดสิทธิ์เข้าถึง | การจัดการเมื่อออกจากงาน |
| ไม่มีบันทึกว่าใครเปิดหรือลบอะไร | ไม่มีใครบอกได้ว่าใครดูแฟ้มการจัดสิ่งอำนวยความสะดวก และตอบคำขอลบอย่างปลอดภัยไม่ได้ | บันทึกตรวจสอบที่เพิ่มได้อย่างเดียว และเครื่องมือลบที่เคารพข้อกำหนดการเก็บรักษา | บันทึกตรวจสอบและการลบ |
แถวแรกคือปัญหาที่ RedAccess พบเป็นจำนวนมาก ในรายงานของ Wired เกี่ยวกับผลการสำรวจของ RedAccess บริษัทเครื่องมือเขียนโค้ด AI สามแห่งจากสี่แห่งโต้แย้งข้อกล่าวอ้างของนักวิจัย ส่วนอีกแห่งไม่ตอบ แต่ไม่ได้ปฏิเสธว่าแอปที่สร้างด้วยไวบ์โค้ดดิ้งซึ่ง RedAccess พบถูกปล่อยให้เปิดเผยอยู่ ผมมองว่าเป็นปัญหาการตั้งค่าและการข้ามขั้นตอนตรวจทาน
ตรวจสอบว่าเครื่องมือช่วยตัดสินเรื่องการจ้างงาน เลื่อนตำแหน่ง หรือให้คะแนนหรือไม่
การสร้างด้วยเครื่องมือเขียนโค้ด AI เพียงอย่างเดียวไม่ได้ทำให้เครื่องมือ HR เป็นระบบความเสี่ยงสูงตาม EU AI Act สิ่งที่กำหนดคือหน้าที่ของเครื่องมือ ภาคผนวก III ของ EU AI Act ระบุระบบ AI ที่ใช้สรรหาหรือคัดเลือกบุคคล และตัดสินเรื่องเลื่อนตำแหน่ง เลิกจ้าง มอบหมายงาน หรือติดตามและประเมินผลงาน
ก่อนเลือกที่ที่เครื่องมือทำงาน จึงควรถามคำถามเดียว: เครื่องมือตัดสินหรือมีอิทธิพลต่อการตัดสินว่าใครจะได้รับการจ้างงาน เลื่อนตำแหน่ง เลิกจ้าง มอบหมายงาน หรือประเมินผลงานหรือไม่?
เครื่องมือติดตามวันลา เช็กลิสต์รับพนักงานใหม่ หรือทำเนียบองค์กร เก็บระเบียนและแสดงกลับ จึงอยู่ฝั่ง ‘ไม่’ แบบให้คะแนนสัมภาษณ์ที่จัดอันดับผู้สมัคร หรือเครื่องมือผลงานที่ให้คะแนนคน โดยเฉพาะเมื่อใช้โมเดล AI ให้คะแนน อาจอยู่ฝั่ง ‘ใช่’ เมื่อแยกไม่ออก ผมจะถือว่าใช่ก่อนและให้ IT กับฝ่ายกฎหมายพิจารณาว่าไม่ใช่หรือไม่
กฎหมายนี้ไม่ได้จำกัดอยู่ที่บริษัท EU: มาตรา 2 ครอบคลุมผู้ให้บริการและผู้นำระบบไปใช้ที่อยู่นอก EU เมื่อผลลัพธ์ของระบบ AI ถูกใช้ใน EU ตามมาตรา 113 ฉบับแก้ไข ภาระหน้าที่สำหรับระบบความเสี่ยงสูงตามภาคผนวก III ใช้ตั้งแต่วันที่ 2 ธันวาคม 2027 รวมถึงระบบจัดการความเสี่ยง ธรรมาภิบาลข้อมูล เอกสารทางเทคนิค การเก็บบันทึก ความโปร่งใสต่อผู้นำไปใช้ และการกำกับดูแลโดยมนุษย์ (มาตรา 9 ถึง 14) การประเมินเรื่องเหล่านี้ควรเป็นหน้าที่ IT และฝ่ายกฎหมาย
หากคำตอบคือใช่ ให้หยุดก่อนที่เครื่องมือจะให้คะแนนผู้สมัครหรือพนักงานจริงแม้แต่คนเดียว ส่งให้ IT และผู้รับผิดชอบกฎหมายหรือการคุ้มครองข้อมูล ถ้ามี DPO ให้ส่ง DPO การตรวจสอบนี้ไม่ได้ตัดสินว่าเครื่องมือใดอยู่ในขอบเขต แต่บอกว่าใครต้องตัดสิน บางรัฐในสหรัฐฯ ก็กำกับการตัดสินใจจ้างงานอัตโนมัติ กฎเหล่านั้นอยู่ในตารางด้านล่าง
คุณเตรียมงานตรวจทานล่วงหน้าได้ ผมจะขอให้เครื่องมือ AI โต้แย้งการให้คะแนนของตัวเองแทนการปกป้อง:
แอปนี้ให้คะแนนหรือจัดอันดับผู้สมัครงานหรือพนักงาน ระบุทุกฟิลด์ข้อมูลและทุกขั้นตอนคำนวณที่มีผลต่อคะแนนหรืออันดับ สำหรับแต่ละรายการ อธิบายว่าอาจสะท้อนลักษณะที่กฎหมายคุ้มครองโดยตรงหรือโดยอ้อมหรือไม่: อายุ เชื้อชาติ เพศ สัญชาติ ชาติพันธุ์ ความพิการ การตั้งครรภ์ ศาสนา หรือรสนิยมทางเพศ ถ้าไม่แน่ใจให้บอก อย่าเดา จากนั้นชี้ประเด็นความเป็นธรรมของการให้คะแนนที่ผมยังไม่ได้ถามแต่ควรถาม
ตรวจสอบ: ถือคำตอบเป็นรายการเริ่มต้นสำหรับผู้ตรวจทาน ไม่ใช่คำตัดสิน และส่งพร้อมตัวเครื่องมือ การใช้พรอมป์นี้ไม่ใช่การตรวจสอบอคติ และไม่ทำให้ผ่านข้อกำหนดทางกฎหมายใด ๆ
เครื่องมือ HR ควรทำงานที่ไหน
อย่าเก็บระเบียนพนักงานบนโฮสติ้งของเครื่องมือ AI เอง สำหรับเครื่องมือที่ทีม HR ใช้เท่านั้น ค่าเริ่มต้นคือเซิร์ฟเวอร์ที่ทีมควบคุม เข้าถึงได้ผ่านเครือข่ายส่วนตัวเท่านั้น และเพิ่มการลงชื่อเข้าใช้ด้วยบัญชีบริษัทที่ทางเข้าเมื่อผู้จัดการหรือพนักงานต้องใช้ เครื่องมือที่ไม่ผ่านการตรวจสอบเรื่องการตัดสินใจจ้างงาน หรือไม่มีผู้รับผิดชอบเซิร์ฟเวอร์ ให้ส่ง IT
การเผยแพร่บนโฮสติ้งของเครื่องมือเขียนโค้ด AI ทำให้แอปมีที่อยู่บนโดเมนผู้ขาย ถ้าไม่ได้ตั้งการมองเห็นเป็นส่วนตัว ใครพบที่อยู่ก็เข้าถึงได้ RedAccess พบแอปแบบนี้หลายพันแอปผ่านการค้นหา Google และ Bing ตามปกติ สำหรับโดเมนเหล่านั้น เครือข่ายส่วนตัวทำงานตรงกันข้าม เพราะเครื่องมือตอบเฉพาะอุปกรณ์ที่เข้าร่วมเครือข่าย การลงชื่อเข้าใช้ด้วยบัญชีบริษัท (single sign-on) หมายถึงเพื่อนร่วมงานเปิดเครื่องมือด้วยบัญชีบริษัทที่ใช้อยู่ โดยผู้ให้บริการยืนยันตัวตนซึ่งจัดการบัญชีเหล่านั้นตรวจสอบ
| ที่ที่เครื่องมือทำงาน | เหมาะเมื่อ | ไม่เหมาะเมื่อ |
|---|---|---|
| โฮสติ้งของเครื่องมือ AI เอง | สร้างและทดสอบด้วยระเบียนพนักงานสมมติ | ใส่ระเบียนจริงแม้แต่รายการเดียว |
| เซิร์ฟเวอร์ที่ทีมควบคุมและเข้าถึงได้ผ่านเครือข่ายส่วนตัวเท่านั้น | เครื่องมือเฉพาะทีม HR: จัดการวันลา ติดตามการรับพนักงานใหม่ วางแผนจำนวนคน | ไม่มีใครรับผิดชอบเซิร์ฟเวอร์ได้ |
| เซิร์ฟเวอร์เดียวกันพร้อมการลงชื่อเข้าใช้ด้วยบัญชีบริษัทที่ทางเข้า | ผู้จัดการหรือพนักงานทั้งหมดต้องเข้าถึง | ไม่มีผู้รับผิดชอบเซิร์ฟเวอร์ หรือไม่มีระบบตัวตนของบริษัทให้เชื่อมต่อ |
| แพลตฟอร์มติดตั้งแบบมีผู้ดูแล | องค์กรขนาดใหญ่ที่จัดงบสำหรับผู้ขายแพลตฟอร์มและการตรวจสอบผู้ขายอยู่แล้ว | ทีม HR ขนาดเล็กที่ไม่มีงบรายการนี้ |
| IT หรือทีมวิศวกรรมภายใน | เครื่องมือไม่ผ่านการตรวจสอบการตัดสินใจจ้างงาน IT มีทรัพยากร หรือไม่มีใครรับผิดชอบเซิร์ฟเวอร์ได้ | เหมาะเสมอ เพียงแต่อาจไม่พร้อมให้บริการในบางครั้ง |
จนกว่าเครื่องมือจะทำงานบนเซิร์ฟเวอร์ของทีม ให้สร้างและทดสอบด้วยข้อมูลสังเคราะห์ ได้แก่ชื่อ เงินเดือน และวันที่ลาสมมติที่มีรูปแบบเหมือนของจริง อุโมงค์ฟรีจากแล็ปท็อปไปยังที่อยู่สาธารณะ เปิดสู่สาธารณะเหมือนโฮสติ้งของผู้ขาย จึงควรใช้ในขั้นสาธิตเช่นกัน
ทำไมต้องใช้เครือข่ายส่วนตัวแทนหน้าล็อกอินที่แอปมีอยู่? เครือข่ายส่วนตัวทำให้เครื่องมือไม่ตอบจากภายนอกเลย คนภายนอกจึงโหลด สำรวจ หรือเดารหัสผ่านไม่ได้ หน้าล็อกอินที่ AI เขียนเพียงอย่างเดียวไม่พอ ใครก็เข้าถึงได้ และความแข็งแรงขึ้นอยู่กับโค้ดที่สร้างอยู่เบื้องหลัง รายงานความปลอดภัยโค้ด GenAI ปี 2025 ของ Veracode พบว่า 45% ของตัวอย่างโค้ดจากโมเดลกว่า 100 ตัวไม่ผ่านการทดสอบ เพราะมีช่องโหว่ OWASP Top 10 ซึ่งเป็นรายการความเสี่ยงความปลอดภัยเว็บแอปที่สำคัญที่สุดและใช้กันแพร่หลาย ผมจึงเลือกเพิ่มล็อกหน้าแอปแทนการพึ่งล็อกที่ AI เขียน
เมื่อส่งมอบ ให้เครื่องมือทำงานบน VPS ซึ่งเป็นเซิร์ฟเวอร์เช่าที่ทีมควบคุมทั้งหมด ใช้เครื่องมือติดตั้งอย่าง Coolify หรือ Dokku รันแอปจากโค้ด Coolify ยังย้อนการอัปเดตที่มีปัญหาไปเวอร์ชันก่อนหน้าจากแดชบอร์ดได้ การเลือกระหว่าง Coolify กับ Dokku ขึ้นกับจำนวนแอปที่จะรันและว่า IT ชอบแดชบอร์ดหรือไม่เป็นหลัก เครือข่ายส่วนตัวใช้ Tailscale หรือ WireGuard โดย Tailscale ตั้งค่าได้เร็วกว่า แต่บริการประสานงานดำเนินการโดย Tailscale ส่วน WireGuard โฮสต์เองทั้งหมด การลงชื่อเข้าใช้ด้วยบัญชีบริษัทมาจากผู้ให้บริการยืนยันตัวตน เช่น Authentik หรือ Keycloak รีเวิร์สพร็อกซี เช่น Caddy หรือ Nginx Proxy Manager เพิ่ม HTTPS ตรงที่การลงชื่อเข้าใช้เปิดสู่เว็บ ส่วนนี้ควรส่งให้ผู้ช่วยด้าน IT พร้อมเช็กลิสต์ท้ายบทความ
วิธีแก้ในรูปพรอมป์สำหรับเครื่องมือ AI ของคุณ
งานส่วนใหญ่ในการนำแอป HR ที่สร้างด้วย AI มาใช้ให้ปลอดภัยทำผ่านเครื่องมือที่สร้างแอปได้ แต่ต้องสั่งก่อน ตามที่นักวิจัยความปลอดภัย Joel Margolis บอก Wired เครื่องมือเขียนโค้ด AI ‘ทำสิ่งที่คุณขอ และถ้าไม่ขอให้ทำอย่างปลอดภัย มันจะไม่พยายามทำเพิ่มเอง’
ใช้แต่ละพรอมป์ด้านล่างเป็นจุดเริ่มต้น และแก้ชื่อฟิลด์กับบทบาทให้ตรงเครื่องมือ ผมมอง AI เป็นวิศวกรและตัวเองเป็นผู้ตรวจทาน ดังนั้นรายงานว่าแก้เสร็จเป็นเพียงร่าง การตรวจสอบใต้พรอมป์คือหลักฐาน และไม่ต้องอ่านโค้ดในการตรวจสอบใดเลย ถ้าไม่ผ่าน ให้ส่งกลับ AI เพื่อแก้และเขียนบทเรียนลงไฟล์กฎของเครื่องมือ AI เพื่อเริ่มเซสชันถัดไปจากจุดนั้น แต่ละพรอมป์ยังให้ระบุเรื่องที่ไม่แน่ใจ ผู้ช่วยที่ยอมรับช่องว่างมีประโยชน์กว่าผู้ช่วยที่มั่นใจตลอด ใช้กับโค้ดและระเบียนสมมติ ห้ามวางระเบียนจริงหรือรหัสผ่านในแชต
หาฟิลด์พนักงานที่เครื่องมือใช้ แล้วปิดกั้นส่วนที่เหลือ
คุณปิดกั้นฟิลด์ที่ไม่รู้ว่าเครื่องมือเก็บไว้ไม่ได้ พรอมป์แรกจึงเป็นการตรวจสอบ:
ตรวจฐานข้อมูล โค้ด หน้าจอ และข้อมูลส่งออกของแอปนี้ ระบุทุกฟิลด์ที่อาจเก็บข้อมูลส่วนบุคคลของพนักงานหรือผู้สมัคร: ชื่อ รหัสพนักงาน SSN หรือเลขประจำตัวประชาชน เลขภาษี วันเกิด ที่อยู่บ้าน ข้อมูลสุขภาพ สถานะความพิการ บันทึกการจัดสิ่งอำนวยความสะดวก เอกสารการย้ายถิ่นฐานหรืออนุญาตทำงาน เงินเดือน โบนัส หุ้น คะแนนผลงาน และบันทึกวินัย บอกแต่ละฟิลด์ว่าหน้าจอหรือฟังก์ชันไหนใช้ และหน้าที่หลักของแอปต้องใช้หรือไม่ ถ้าบอกไม่ได้ให้ระบุว่าไม่แน่ใจ อย่าเดา
ตรวจสอบ: เปิดหน้าจอหลักและข้อมูลส่งออก แล้วให้แน่ใจว่าทุกฟิลด์ส่วนบุคคลที่มองเห็นอยู่ในรายการ ถ้าเห็นแต่ไม่มีในรายการ แสดงว่าตรวจตกหล่น ให้ถามอีกครั้ง
พรอมป์ที่สองนำสิ่งที่ไม่จำเป็นออก โดยใช้บัญชีฐานข้อมูล ซึ่งเป็นบัญชีที่แอปใช้สื่อสารกับฐานข้อมูล และจำกัดให้ใช้เฉพาะฟิลด์ได้
แก้แอปให้อ่านเฉพาะฟิลด์เหล่านี้: [ระบุฟิลด์ที่ต้องใช้] ลบฟิลด์ส่วนบุคคลอื่นทั้งหมดจากสำเนาข้อมูลของแอป โค้ด ทุกหน้าจอ และทุกการส่งออก จากนั้นสร้างบัญชีฐานข้อมูลแยกสำหรับแอป ให้อ่านได้เฉพาะฟิลด์เหล่านี้และแก้ได้เฉพาะข้อมูลที่เครื่องมือเขียนเอง เช่น คำขอลา เปลี่ยนแอปมาใช้บัญชีนี้ รายงานว่าแก้อะไรอย่างชัดเจนทีละไฟล์ และบอกทุกสิ่งที่ทำไม่ได้
แก้หน้าจออย่างเดียวไม่พอ ถ้าบัญชีฐานข้อมูลของแอปอ่านคอลัมน์เงินเดือนไม่ได้ บั๊กที่อื่นในโค้ด AI ก็แสดงไม่ได้เช่นกัน เรื่องเข้ารหัสข้อมูลขณะจัดเก็บต้องถาม IT เพราะอยู่ในการตั้งค่าเซิร์ฟเวอร์และดิสก์ ซึ่งผู้ช่วยที่อ่านโค้ดดูอย่างน่าเชื่อถือไม่ได้
ตรวจสอบ: ลงชื่อเข้าใช้เป็นผู้ใช้ทั่วไป เปิดทุกหน้าจอและทุกการส่งออก ต้องไม่มีฟิลด์ที่ลบแล้วปรากฏ จากนั้นให้ IT ผู้ดูแลเซิร์ฟเวอร์ หรือ AI ที่แสดงผลลัพธ์ให้คุณดู ใช้บัญชีฐานข้อมูลของแอปขออ่านฟิลด์ที่ลบแล้ว ข้อผิดพลาดปฏิเสธสิทธิ์หรือฟิลด์ไม่มีอยู่ถือว่าผ่าน ข้อผิดพลาดการเชื่อมต่อ ไวยากรณ์ หรือเรื่องไม่เกี่ยวข้องไม่ถือว่าผ่าน คอลัมน์ว่างหรือค่าจริงถือว่าไม่ผ่าน เก็บรายการตรวจสอบไว้เพราะเครื่องมือลบจะใช้
แยกมุมมองของผู้ดูแล HR ผู้จัดการ และพนักงาน
นี่คือจุดที่ข้อมูลพนักงานรั่วภายใน ไปสู่เพื่อนร่วมงานที่เปิดเงินเดือนของอีกคนหรือบันทึกการจัดสิ่งอำนวยความสะดวกของสมาชิกทีม การควบคุมการเข้าถึงตามบทบาทแก้ได้ และพรอมป์ต่อไปนี้ระบุว่าต้องตรวจสอบตรงไหน:
เพิ่มการควบคุมการเข้าถึงตามบทบาทสามแบบ ตรวจบนเซิร์ฟเวอร์ทุกคำขอ ไม่ใช่แค่ซ่อนปุ่มหรือลิงก์บนหน้า
- ผู้ดูแล HR: อ่านและแก้ระเบียนพนักงานทั้งหมดได้
- ผู้จัดการบุคลากร: อ่านได้เฉพาะระเบียนผู้ใต้บังคับบัญชาโดยตรง และไม่เห็นฟิลด์เงินเดือน การแพทย์ การจัดสิ่งอำนวยความสะดวก วินัย หรือการย้ายถิ่นฐานเลย
- พนักงาน: อ่านเฉพาะระเบียนตนเอง
ปฏิเสธทุกอย่างนอกเหนือจากนี้ด้วยคำตอบ ‘ปฏิเสธการเข้าถึง’ (403) รับบทบาทจากบัญชีที่ลงชื่อเข้าใช้ ห้ามรับจากสิ่งที่ผู้ใช้พิมพ์หรือแก้ในหน้าหรือแถบที่อยู่ ระบุทุกจุดที่เพิ่มการตรวจ และทำเครื่องหมายหน้าหรือการส่งออกที่ไม่แน่ใจว่าครอบคลุม
บางบริษัทให้ผู้จัดการเห็นเงินเดือนขณะทบทวนค่าตอบแทน ถ้าบริษัทคุณทำเช่นนั้น ให้แก้บรรทัดผู้จัดการ
ตรวจสอบ: สร้างผู้จัดการและพนักงานทดสอบ ลงชื่อเป็นผู้จัดการ เปิดระเบียนผู้ใต้บังคับบัญชาโดยตรง คัดลอกที่อยู่ เปลี่ยนหมายเลขเป็นคนนอกทีม แล้วโหลด: ต้องได้ ‘ปฏิเสธการเข้าถึง’ ทำซ้ำเป็นพนักงานด้วยหมายเลขของเพื่อนร่วมงาน แล้วตรวจว่ามุมมองผู้จัดการไม่แสดงฟิลด์เงินเดือน การจัดสิ่งอำนวยความสะดวก หรือการย้ายถิ่นฐานเลย
นำข้อมูลรับรองออกจากโค้ดและแชต
รหัสผ่านฐานข้อมูลหรือโทเค็น API ของ HRIS หรือเงินเดือน ซึ่งเป็นคีย์ยาวที่ระบบหนึ่งใช้เข้าอีกระบบ อาจถูกนำออกจากโค้ดวันนี้แต่ยังอยู่ในเวอร์ชันที่บันทึกก่อนหน้า จึงต้องถามเรื่องประวัติด้วย ตัวแปรสภาพแวดล้อมแก้ฝั่งโค้ด เป็นค่าที่เซิร์ฟเวอร์ส่งให้แอปตอนเริ่ม โค้ดจึงอ้างด้วยชื่อโดยไม่เก็บค่า
หาทุกรหัสผ่าน คีย์ API โทเค็นเข้าถึง และสตริงเชื่อมต่อฐานข้อมูลในโครงการ รวม HRIS เงินเดือน และอีเมล แทนแต่ละค่าในโค้ดด้วยตัวแปรสภาพแวดล้อมและส่งรายการชื่อ ตรวจว่าไฟล์เก็บค่าจริง เช่น .env ถูกยกเว้นจากคลังโค้ด จากนั้นระบุทุกจุดที่ค่าเก่ายังคงอยู่ในประวัติโครงการ เพื่อรู้ว่าต้องเปลี่ยนข้อมูลรับรองใด
พรอมป์ทำขั้นสำคัญที่สุดไม่ได้ ในคอนโซลผู้ดูแล HRIS หรือฐานข้อมูล ให้ออกข้อมูลรับรองใหม่สำหรับทุกรายการที่เคยอยู่ในแชตหรือคลังโค้ด แล้วปิดรายการเก่า
สำเนารหัสผ่านของทีมควรอยู่ในตัวจัดการรหัสผ่าน เช่น เซิร์ฟเวอร์ Vaultwarden ที่โฮสต์เอง โดยตัวเลือกใดเหมาะกับทีมเป็นการตัดสินใจแยกต่างหาก มันเก็บข้อมูลรับรองให้คน ไม่ได้ป้อนแอปที่กำลังทำงาน ซึ่งรับค่าจากเครื่องมือติดตั้ง สำหรับความลับที่แอปอ่านเองขณะทำงาน HashiCorp Vault เป็นตัวเลือกที่หนักกว่า มีนโยบายรวมศูนย์และการหมุนเวียนให้ทีมที่ต้องการ
ตรวจสอบ: ให้ AI ค้นค่าเก่าในไฟล์ปัจจุบัน แล้วอ่านผลที่แสดง ไม่ใช่สรุป ต้องไม่พบรายการตรงกันในไฟล์ปัจจุบัน การพบในประวัติเป็นเรื่องคาดหมายและไม่ต้องล้าง เพราะเป็นรายการที่ต้องเปลี่ยน หลักฐานว่าแต่ละรายการใช้ไม่ได้แล้วอยู่ในคอนโซล HRIS หรือฐานข้อมูล: ค่าเก่าทั้งหมดแสดงว่าเพิกถอนแล้ว หรือ IT ยืนยันว่าระบบปฏิเสธ
ดูว่าข้อมูลพนักงานใดออกจากเครื่องมือ
เมื่อการเรียกส่งบันทึกสัมภาษณ์ผู้สมัครไปภายนอกแล้ว การลบในเครื่องมือคุณไม่ได้ไปถึงสำเนาที่บริการนั้นอาจเก็บ ดังนั้นแก้โดยส่งให้น้อยลงตั้งแต่ต้น
ตรวจทุกการเรียกภายนอกของแอป: OpenAI, Anthropic หรือ AI API อื่น ระบบ HR อย่าง HRIS หรือ ATS เครื่องมือวิเคราะห์หรือจับข้อผิดพลาด และทุก webhook ระบุฟิลด์พนักงานหรือผู้สมัครที่ส่งอย่างชัดเจนสำหรับแต่ละการเรียก ทำเครื่องหมายบริการที่อาจเก็บหรือบันทึกสิ่งที่รับ และบอกการเรียกที่ใช้ข้อมูลน้อยลงได้ ทำเครื่องหมายสิ่งที่ไม่แน่ใจ
ตรวจสอบ: สร้างพนักงานหรือผู้สมัครสมมติที่มีชื่อแต่งขึ้นไม่เหมือนใคร ใช้ทุกฟังก์ชันที่เรียกภายนอก เช่น สร้างสรุปสัมภาษณ์ เรียก webhook เปิดหน้าที่โหลดสคริปต์วิเคราะห์ เปิดแดชบอร์ดของแต่ละบริการ เช่น เครื่องมือวิเคราะห์ ตัวจับข้อผิดพลาด บันทึก webhook ที่ ATS รับ หรือบันทึกการใช้ AI ที่แสดงคำขอ แล้วค้นชื่อนั้น ต้องพบเฉพาะที่การเรียกจำเป็นต้องใช้ ถ้าพบที่อื่น ให้ AI ลดข้อมูลในการเรียกนั้นและตรวจอีกครั้ง บางแดชบอร์ดไม่แสดงสิ่งที่รับ สำหรับบริการเหล่านี้และบริการที่ต้องรับข้อมูลพนักงานต่อเนื่อง ให้ส่งเงื่อนไขเก็บรักษาข้อมูลแก่คนที่ลงนามสัญญาผู้ขายในบริษัท
บันทึกว่าใครเปิดระเบียนพนักงานใด
พนักงานถามว่าใครส่งออกตารางเงินเดือนในไตรมาสก่อน หากไม่มีบันทึกตรวจสอบ ซึ่งเก็บว่าใครทำอะไรกับระเบียนใดอย่างต่อเนื่อง ก็ไม่มีใครตอบได้
เพิ่มบันทึกตรวจสอบ เมื่อผู้ใช้ดู แก้ ส่งออก หรือลบระเบียนพนักงาน ให้เพิ่มแถวที่มี ID ผู้ใช้ ID ระเบียนพนักงาน การกระทำ ฟิลด์ที่เปลี่ยน และเวลา ตั้งฐานข้อมูลให้บัญชีของแอปเพิ่มแถวในบันทึกได้แต่แก้หรือลบไม่ได้ ในแอปให้ผู้ดูแล HR เท่านั้นอ่านได้ บอกว่าบังคับกฎห้ามแก้ห้ามลบอย่างไรและที่ไหน
‘เพิ่มได้อย่างเดียว’ ต้องมาจากสิทธิ์บัญชีฐานข้อมูล ไม่ใช่คำสัญญาว่าแอปจะทำถูก บันทึกเองก็เป็นข้อมูลส่วนบุคคลเพราะบอกว่าใครดูระเบียนใคร จึงให้ผู้ดูแล HR อ่านเท่านั้น
ตรวจสอบ: ในฐานะผู้ดูแล HR เปิดระเบียนแล้วดูบันทึกเพื่อยืนยันว่ามีรายการ ให้ IT หรือ AI ที่แสดงผลลัพธ์ให้คุณดูลองลบแถวโดยใช้บัญชีฐานข้อมูลของแอป คุณต้องเห็นข้อผิดพลาดด้านสิทธิ์จริง
จัดการคำขอลบโดยไม่ละเมิดกฎการเก็บรักษา
ถ้าพนักงานขอให้ลบ แต่บางระเบียนเป็นแฟ้มเงินเดือนที่บริษัทต้องเก็บ จะเกิดอะไรขึ้น? พรอมป์ตรง ๆ (‘ลบข้อมูลส่วนบุคคลทั้งหมดของพนักงานนี้ในทุกตาราง’) ลบแฟ้มเหล่านั้นด้วยและทำให้มีสองปัญหา นายจ้างมักต้องเก็บบางระเบียน เช่น เงินเดือน ภาษี และเอกสารอนุญาตทำงาน และสิทธิ์ในการลบของ GDPRไม่ใช้ในส่วนที่การประมวลผลจำเป็นเพื่อทำตามหน้าที่กฎหมายหรือเพื่อข้อเรียกร้องทางกฎหมาย (มาตรา 17(3)(b) และ (e)) ปุ่มลบทุกอย่างที่วางไว้ก็อันตราย แบบที่ปลอดภัยกว่าแยก ‘ลบเมื่อร้องขอ’ จากระเบียนที่มีข้อกำหนดเก็บรักษา ซึ่งบริษัทต้องเก็บไม่ว่าจะมีคำขอหรือไม่ และแสดงแผนก่อนลบ:
สร้างเครื่องมือคำขอลบที่ผู้ดูแล HR เท่านั้นเปิดได้ เมื่อรับ ID พนักงาน ให้แสดงทุกตารางและฟิลด์ที่มีข้อมูลของคนนั้นก่อน โดยจัดหมวดตามการตรวจฟิลด์ แต่ละหมวดมีการตั้งค่าที่ผู้ดูแล HR กำหนด: ‘ลบเมื่อร้องขอ’ หรือ ‘เก็บ: ต้องเก็บตามข้อกำหนด’ หลังผู้ดูแลยืนยัน ลบเฉพาะหมวด ‘ลบเมื่อร้องขอ’ บันทึกแค่ ID พนักงาน เวลา ผู้ยืนยัน และหมวดที่ลบหรือเก็บ ไม่เก็บข้อมูลอื่นของคนนั้น ผู้ที่ไม่ใช่ผู้ดูแล HR ได้ ‘ปฏิเสธการเข้าถึง’
การตั้งค่าเก็บรักษามาจากผู้รับผิดชอบการปฏิบัติตามข้อกำหนดหรือ DPO ไม่ใช่ AI หรือการเดาของผู้สร้าง บอกว่าบันทึกยังมี ID พนักงานหลังลบ เพื่อให้ตัดสินว่าเก็บตัวระบุนานเท่าใด สำรองข้อมูลและสำเนาที่บริการภายนอกเก็บต้องมีขั้นตอนเก็บหรือลบของตนเอง
ตรวจสอบ: สร้างพนักงานทดสอบที่มีระเบียนสองหมวด ตั้งหมวดหนึ่งเป็น ‘ลบเมื่อร้องขอ’ อีกหมวดเป็นต้องเก็บ ใช้เครื่องมือเป็นผู้ดูแล HR และยืนยันว่าหายเฉพาะหมวดแรก จากนั้นเปิดด้วยบัญชีผู้จัดการ ต้องได้ ‘ปฏิเสธการเข้าถึง’
กฎการจ้างงานที่ควรหารือกับ DPO หรือผู้รับผิดชอบการปฏิบัติตามข้อกำหนด
กฎการจ้างงานที่เกี่ยวข้องกับเครื่องมือ HR ขึ้นกับหน้าที่และข้อมูลของใครที่เก็บ ไม่ใช่วิธีสร้าง นี่คือรายการกฎเพื่อหารือกับ DPO หรือผู้รับผิดชอบการปฏิบัติตามข้อกำหนด ไม่ใช่คำปรึกษากฎหมาย และไม่ได้ตัดสินว่ากฎใดใช้กับคุณ
เครื่องมือวันลาที่เก็บบันทึกการจัดสิ่งอำนวยความสะดวกของพนักงานในเยอรมนีและแคลิฟอร์เนียเกี่ยวข้องกับกฎต่างจากเครื่องมือวางแผนคนที่เก็บเฉพาะชื่อตำแหน่ง ประเด็น EU AI Act อยู่ในการตรวจสอบการตัดสินใจจ้างงาน
| หากเครื่องมือ… | กฎที่ควรหารือ | แหล่งข้อมูลทางการ |
|---|---|---|
| ใช้คะแนนหรืออันดับอัตโนมัติในการตัดสินใจจ้างงานหรือเลื่อนตำแหน่งของคนในโคโลราโด | Colorado SB 26-189 ครอบคลุมเทคโนโลยีตัดสินใจอัตโนมัติในเรื่องสำคัญรวมการจ้างงาน โดยภาระหน้าที่เริ่มวันที่ 1 มกราคม 2027 | Colorado SB 26-189 |
| ใช้คะแนนหรืออันดับอัตโนมัติในการตัดสินใจจ้างงานหรือเลื่อนตำแหน่งของคนในแคลิฟอร์เนีย | กฎเทคโนโลยีตัดสินใจอัตโนมัติ (ADMT) ของแคลิฟอร์เนียมีผลวันที่ 1 มกราคม 2026 แต่ธุรกิจที่ใช้ ADMT ตัดสินเรื่องสำคัญต้องทำตามข้อกำหนดเฉพาะ ADMT ตั้งแต่ 1 มกราคม 2027 | กฎ ADMT ของ CPPA |
| ใช้ AI ในการสรรหา การจ้างงาน การเลื่อนตำแหน่ง การลงโทษทางวินัย การเลิกจ้าง หรือการตัดสินใจด้านการจ้างงานอื่นๆ ในอิลลินอยส์ | Illinois HB 3773 แก้ไขกฎหมายสิทธิมนุษยชนของรัฐอิลลินอยส์ตั้งแต่วันที่ 1 มกราคม 2026: นายจ้างห้ามใช้ AI ในลักษณะที่เลือกปฏิบัติต่อกลุ่มที่ได้รับความคุ้มครอง หรือใช้รหัสไปรษณีย์เป็นตัวแทนของกลุ่มเหล่านั้น และต้องแจ้งพนักงานเมื่อใช้ AI ในการตัดสินใจเหล่านี้ | Illinois Public Act 103-0804 |
| เก็บระเบียนสุขภาพ ความพิการ หรือการจัดสิ่งอำนวยความสะดวกของคนใน EU | GDPR มาตรา 9: ข้อมูลสุขภาพเป็นประเภทพิเศษ ห้ามประมวลผลเว้นแต่เข้าเงื่อนไขยกเว้น รวมถึงการประมวลผลที่จำเป็นตามหน้าที่กฎหมายการจ้างงาน (มาตรา 9(2)(b)) | GDPR มาตรา 9 |
| เก็บข้อมูลส่วนบุคคลใด ๆ ของพนักงานหรือผู้สมัครใน EU | GDPR มาตรา 6: แต่ละการใช้ต้องมีฐานที่ชอบด้วยกฎหมาย เช่น สัญญาหรือหน้าที่ตามกฎหมาย | GDPR มาตรา 6 |
| เก็บข้อมูลพนักงานสหราชอาณาจักร | UK GDPR พร้อมคำแนะนำของ ICO เกี่ยวกับข้อมูลการจ้างงาน | คำแนะนำการจ้างงานของ ICO |
| เก็บข้อมูลพนักงานหรือผู้สมัครในแคลิฟอร์เนีย | CCPA/CPRA: หากองค์กรเป็นธุรกิจที่อยู่ภายใต้ CCPA ข้อยกเว้นข้อมูลพนักงานและผู้สมัครหมดอายุวันที่ 1 มกราคม 2023 ดังนั้นข้อมูลส่วนบุคคลเกี่ยวกับการจ้างงานจึงอยู่ในขอบเขตโดยทั่วไป | หน้า CCPA ของกระทรวงยุติธรรมแคลิฟอร์เนีย |
ที่ตั้งเซิร์ฟเวอร์กำหนดว่าระเบียนอยู่ที่ไหนทางกายภาพ ไม่ได้ทำให้ผ่านกฎข้างต้นด้วยตัวเอง สำหรับพนักงานนอกพื้นที่เหล่านี้ เริ่มจากหน่วยงานกำกับความเป็นส่วนตัวหรือการจ้างงานระดับประเทศ รัฐ หรือท้องถิ่นที่เกี่ยวข้อง หรือฝ่ายกฎหมายและผู้รับผิดชอบการปฏิบัติตามข้อกำหนด
สิทธิ์เข้าถึงสิ้นสุดเมื่อการจ้างงานสิ้นสุด
เมื่อปิดบัญชีบริษัทของผู้ลาออกในวันสุดท้าย อีเมล ปฏิทิน และไฟล์ปิดพร้อมกัน เครื่องมือ HR ควรปิดขั้นเดียวกัน และทำได้เมื่ออยู่หลังการลงชื่อเข้าใช้บริษัท ถ้าขั้นตอนออกจากงานเพิกถอนเซสชันที่ยังทำงานด้วย เครื่องมือที่ไม่ได้อยู่หลังการลงชื่อเข้าใช้ต้องมีรายการแยกในเช็กลิสต์ออกจากงาน เพื่อให้คนลบบัญชีด้วยมือ
ผู้สร้างก็อาจลาออกในวันหนึ่ง เมื่อคนที่สร้างเครื่องมือลาออกหรือเปลี่ยนหน้าที่ ให้ส่งความรับผิดชอบแก่ผู้สืบทอดที่ระบุชื่อ สามารถลงชื่อเป็นผู้ดูแลและรู้ว่าเซิร์ฟเวอร์อยู่ไหน แล้วปิดบัญชีผู้ดูแลของผู้สร้าง ผมจะระบุผู้สืบทอดก่อนเริ่มใช้งาน เพราะช่วงแจ้งลาออกไม่เหมาะกับการหาคน
ทบทวนตามกำหนดว่าใครถือแต่ละบทบาทและเครื่องมือยังใช้อยู่หรือไม่ เมื่อขยายสิทธิ์ ให้ขยายทีละขั้น จาก HR ไปผู้จัดการ แล้วทุกคน และทดสอบแถบที่อยู่อีกครั้งทุกขั้น เมื่อไม่ใช้แล้วให้เลิกใช้งาน: ปิดบัญชีฐานข้อมูลและข้อมูลรับรอง ลบข้อมูลตามค่าการเก็บรักษาของเครื่องมือลบ หยุดแอป และนำออกจากเครือข่ายส่วนตัวหรือระบบลงชื่อเข้าใช้
ผู้สืบทอดที่ระบุชื่อได้รับเซิร์ฟเวอร์ที่มีคนต้องตั้งขึ้น พร้อมเครื่องมือติดตั้ง เครือข่ายส่วนตัว และการลงชื่อเข้าใช้บริษัทเมื่อขยายสิทธิ์ Linux VPS ของเราให้สิทธิ์ root และ Coolify, Tailscale, Authentik ติดตั้งเป็นแอปคลิกเดียวได้ ทำให้ IT ใช้เวลาไปกับการตรวจสอบ ที่ตั้งมีแฟรงก์เฟิร์ตและอัมสเตอร์ดัมใน EU ลอนดอนในสหราชอาณาจักร และหลายเมืองในสหรัฐฯ นี่กำหนดประเทศที่ตั้งเซิร์ฟเวอร์ เป็นข้อมูลสำหรับคุยกับ DPO ไม่ใช่สิ่งแทนการหารือ
เช็กลิสต์ก่อนเปิดใช้งานจริง
แต่ละข้อต้องระบุว่าทำแล้วหรือยังไม่ทำก่อนใส่ระเบียนพนักงาน และส่งรายการนี้ให้ผู้ตั้งเซิร์ฟเวอร์
- ตอบคำถามการตัดสินใจจ้างงานแล้ว และทุกคำตอบ ‘ใช่’ ส่ง IT และฝ่ายกฎหมายแล้ว
- เครื่องมือทำงานบนเซิร์ฟเวอร์ที่ทีมควบคุม ไม่ใช่โฮสติ้งของเครื่องมือ AI
- เข้าถึงผ่านเครือข่ายส่วนตัวหรือการลงชื่อเข้าใช้บริษัทเท่านั้น
- บัญชีฐานข้อมูลของแอปอ่านเฉพาะฟิลด์ที่ระบุ
- ผู้จัดการและพนักงานทดสอบต่างได้ ‘ปฏิเสธการเข้าถึง’ ในการทดสอบแถบที่อยู่
- เปลี่ยนข้อมูลรับรองทุกตัวที่เคยอยู่ในแชตหรือโค้ด และเพิกถอนตัวเก่าแล้ว
- ตรวจข้อมูลขาออกแล้วและตัดฟิลด์ที่ไม่ต้องใช้ออก
- บันทึกตรวจสอบเก็บการดูข้อมูล และบัญชีแอปแก้หรือลบไม่ได้
- DPO หรือผู้รับผิดชอบการปฏิบัติตามข้อกำหนดตรวจค่าการเก็บรักษาและกฎการจ้างงานแล้ว
- มีผู้รับผิดชอบและผู้สำรองที่ระบุชื่อชัดเจน
คำถามที่พบบ่อย
Shadow AI ใน HR คืออะไร?
Shadow AI ใน HR คือการใช้เครื่องมือ AI หรือแอปที่สร้างด้วยมันกับข้อมูล HR โดย IT ไม่รู้หรือไม่อนุมัติ การสำรวจระบบ HR ประจำปี 2026 ของ Sapient Insights ตามที่ Cornerstone OnDemand รายงาน พบว่าผู้ทำงาน HR มากกว่า 80% ใช้ AI ส่วนตัวทุกวัน ขณะที่ 3% ใช้ AI ที่ฝังในระบบ HR
ใช้ระเบียนพนักงานจริงขณะสร้างเครื่องมือได้ไหม?
ไม่ได้ อย่าใส่ระเบียนจริงในแชตขณะสร้างเครื่องมือ HR ด้วยไวบ์โค้ดดิ้ง การวางในผู้ช่วยแชตเป็นความเสี่ยงแยกจากการติดตั้ง และเกิดทันทีที่วางไม่ว่าเครื่องมือจะเปิดใช้งานจริงหรือไม่ ใช้ระเบียนสมมติจนเครื่องมืออยู่บนเซิร์ฟเวอร์ที่ทีมควบคุม
พนักงานต้องยินยอมให้เครื่องมือ HR ใช้ข้อมูลหรือไม่?
โดยทั่วไปความยินยอมไม่ใช่ฐานที่เหมาะสม แนวทางเรื่องความยินยอมของ EDPB ระบุว่า ‘เห็นว่าเป็นปัญหาที่นายจ้างประมวลผลข้อมูลส่วนบุคคลของพนักงานปัจจุบันหรือในอนาคตด้วยฐานความยินยอม เพราะไม่น่าจะให้ได้อย่างอิสระ’ ฐานที่ชอบด้วยกฎหมายใดตาม GDPR มาตรา 6 ใช้ได้ ต้องถาม DPO
HIPAA ครอบคลุมบันทึกทางการแพทย์ในเครื่องมือ HR ไหม?
โดยทั่วไปไม่ครอบคลุม นิยามข้อมูลสุขภาพที่ได้รับความคุ้มครองของ HIPAA ยกเว้นข้อมูลในระเบียนการจ้างงานที่หน่วยงานภายใต้กฎหมายถือไว้ในฐานะนายจ้าง (45 CFR 160.103) ไม่ได้แปลว่าบันทึกเหล่านั้นไม่ถูกกำกับ จึงต้องถามผู้รับผิดชอบการปฏิบัติตามข้อกำหนดว่ากฎใดครอบคลุม
การสนทนา
ความคิดเห็น
เข้าสู่ระบบเพื่อร่วมสนทนา