เมื่อ RedAccess ค้นหาแอปที่สร้างด้วยเครื่องมือเขียนโค้ด AI และเผยแพร่บนโดเมนของเครื่องมือเหล่านั้น พบกว่า 5,000 แอปที่แทบไม่มีการป้องกันหรือยืนยันตัวตน ภาพที่ส่งให้ Wired มีบันทึกสนทนาทั้งหมดระหว่างแชตบอตร้านค้ากับลูกค้า รวมชื่อเต็มและข้อมูลติดต่อ Wired ยืนยันไม่ได้ว่าข้อมูลที่ตรวจเป็นของจริง แต่แอปเหล่านั้นเปิดให้เข้าถึงอยู่จริง
เมื่อเชื่อม Salesforce, HubSpot, Pipedrive หรือ Zoho ข้อมูลลูกค้าอาจรั่วไกลกว่าหน้าจอที่ออกแบบไว้ เครื่องมือติดตามการขายแสดงบัญชีลูกค้าเพียงแผงเดียว แต่คีย์ที่เก็บไว้อาจเปิดได้มากกว่านั้น ตรวจขอบเขตคีย์ก่อนส่งลิงก์ให้ทีม
TL;DR (สรุปย่อ)
- ข้อมูลรับรอง CRM กำหนดขนาดความเสียหายของการรั่ว ให้เครื่องมือมีข้อมูลรับรองเฉพาะที่จำกัดสิทธิ์ ใช้ผู้ใช้แยกสิทธิ์ต่ำเมื่อ CRM ผูกการเข้าถึงกับผู้ใช้ เก็บในสภาพแวดล้อมเซิร์ฟเวอร์หรือคลังความลับ และให้เฉพาะโค้ดฝั่งเซิร์ฟเวอร์ใช้
- ข้อผิดพลาดที่ทำให้ข้อมูลลูกค้า กระบวนการขาย หรือราคารั่ว มีคำสั่งที่คัดลอกไปแก้ได้ ให้เครื่องมือ AI เดิมเปลี่ยนโค้ด แล้วทดสอบสั้น ๆ ด้วยตัวคุณเองเพื่อยืนยัน
- สถานที่รันขึ้นกับการทำงานกับ CRM เครื่องมืออ่านอย่างเดียวรันบนเซิร์ฟเวอร์ที่ทีมควบคุม ผ่านเครือข่ายส่วนตัวหรือการเข้าสู่ระบบบริษัทได้ เครื่องมือที่เขียนกลับต้องผ่านฝ่ายไอทีหรือผู้ดูแล CRM ก่อน
- เมื่อ GDPR และ CCPA ใช้บังคับ จะรวมสำเนาข้อมูลในเครื่องมือและทุกบริการที่รับข้อมูล เครื่องมือขายและสนับสนุนส่วนใหญ่ไม่ใช่ความเสี่ยงสูงตามกฎหมาย AI ของยุโรป ข้อยกเว้นหลักคือการตัดสินสินเชื่อบุคคล ความเสี่ยงหรือราคาประกันชีวิตและสุขภาพ และ AI ที่อนุมานอารมณ์จากใบหน้าหรือเสียง
คีย์ CRM ที่รั่วเข้าถึงอะไรได้บ้าง
คีย์ API CRM ที่เปิดเผยเข้าถึงทุกอย่างที่ผู้ใช้หรือแอปมีสิทธิ์ ไม่ใช่แค่แดชบอร์ด ใน Salesforce และ Pipedrive คีย์ผู้ดูแลอ่านและมักแก้ผู้ติดต่อ บัญชี และข้อตกลงทั้งหมดที่ผู้ดูแลเห็นได้ คีย์ HubSpot และ Zoho มีขอบเขตที่ได้รับ ส่วนขอบเขตกลุ่ม Zoho ครอบคลุมทุกสิ่งที่ผู้ใช้ทำได้
นี่คือวิธีให้และลดสิทธิ์ของทั้งสี่ระบบ ขอบเขตหรือ scope ในตารางคือรายการการกระทำที่ข้อมูลรับรองอนุญาต
| CRM | ข้อมูลรับรองและสิทธิ์ที่ติดมาด้วย | สิทธิ์กว้างเปิดอะไร | การตั้งค่าที่จำกัดกว่า |
|---|---|---|---|
| Salesforce | การเชื่อม OAuth ผ่าน connected app หรือ external client app ในนามผู้ใช้ Salesforce หนึ่งคน | full เข้าถึงข้อมูลทั้งหมดที่ผู้ใช้มีสิทธิ์ ส่วน api เข้าบัญชีผ่าน REST API และ Bulk API 2.0 |
ผู้ใช้เฉพาะที่มีสิทธิ์แค่วัตถุที่อ่าน ขอ api ไม่ใช่ full |
| HubSpot | Service Key สำหรับการเชื่อมภายในบัญชีใหม่ หรือโทเคนแอปส่วนตัวรุ่นเก่าที่มีอยู่ | ทุกสิ่งที่เลือก เช่น อ่านและเขียนผู้ติดต่อ บริษัท และข้อตกลง | ขอบเขตอ่านอย่างเดียว เช่น crm.objects.contacts.read เฉพาะวัตถุที่แสดง ปิด sensitive และ highly_sensitive |
| Pipedrive | โทเคน API ส่วนตัวที่ “ผูกกับผู้ใช้และบริษัทเฉพาะ ให้เข้าถึงข้อมูลทั้งหมดของผู้ใช้” | ทุกอย่างที่ผู้ใช้เห็น | โทเคนจากผู้ใช้ Pipedrive แยกที่เห็นเฉพาะข้อมูลจำเป็น |
| Zoho CRM | โทเคน OAuth ที่ใช้ขอบเขตตาม service_name.scope_name.operation_type |
ขอบเขตกลุ่มอย่าง ZohoCRM.modules.ALL ให้อ่าน สร้าง แก้ และลบลูกค้าเป้าหมาย ผู้ติดต่อ บัญชี ข้อตกลง ใบเสนอราคา ตารางราคา ใบสั่งขาย และใบแจ้งหนี้ |
ขอบเขตอ่านรายโมดูล เช่น ZohoCRM.modules.contacts.READ |
แต่ละแถวใช้คำของผู้ขาย เอกสารขอบเขต Salesforce ระบุว่า full “รวมขอบเขตอื่นทั้งหมด” HubSpot ถือแอปส่วนตัวเป็นวิธีเก่าและแนะนำ Service Keys สำหรับการเชื่อมระบบใหม่ แอปเก่าที่ยังอยู่ใช้เอกสารขอบเขตเดิม รวมข้อมูลอ่อนไหวของบัญชี Enterprise
คำอธิบาย Pipedrive มาจากเอกสารการยืนยันตัวตน ส่วนเอกสารขอบเขต Zoho กล่าวว่าขอบเขตกลุ่มให้ “เข้าถึงทุกฟังก์ชันที่ผู้ใช้ทำกับระเบียนได้เต็มที่” ตัวอย่างของเขาเองขอ ZohoCRM.modules.ALL
กฎร่วมคือข้อมูลรับรองมีสิทธิ์ของผู้ใช้หรือขอบเขตที่ได้รับ จึงควรสร้างของเฉพาะและจำกัดให้มากที่สุด หากสิทธิ์ตามผู้ใช้ ให้ใช้ผู้ใช้แยกสิทธิ์ต่ำแทนบัญชีผู้ดูแลส่วนตัว
ให้สิทธิ์เขียนเมื่อจำเป็นเท่านั้น และส่งให้ไอทีดูแล อย่าใช้การเข้าระบบผู้ดูแลหรือโทเคนส่วนตัวของคุณ
ข้อมูลรับรองเก่าที่ผูกบุคคลอาจพังเมื่อคนนั้นออก ภาพรวมแอปส่วนตัวเก่าของ HubSpot ระบุว่าลบผู้สร้างแล้ว API บางคำขอล้มเหลว Service Keys อยู่ระดับบัญชี ไม่ใช่พนักงาน จึงเลี่ยงปัญหา Pipedrive อนุญาตโทเคน API ใช้งานหนึ่งอันต่อผู้ใช้ การเปลี่ยนหยุดทุกการเชื่อมที่ใช้อยู่
สิทธิ์กว้างที่เปิดผู้ติดต่อมักเปิดข้อตกลงและคาดการณ์ รวมใบเสนอราคาและตารางราคาใน Zoho ใครถือคีย์ก็เข้าถึงโครงสร้างราคาและส่วนลด
สร้างและจำกัดสิทธิ์หรือขอบเขตในหน้าผู้ดูแล CRM หรือขอผู้ดูแลทำให้
ข้อผิดพลาดการนำระบบใช้ที่ทำข้อมูลรั่วและวิธีแก้
ค่าเริ่มต้นเจ็ดอย่างทำข้อมูลรั่ว ได้แก่ คีย์ในโค้ดหรือเบราว์เซอร์ ลิงก์สาธารณะ ทุกคนเห็นทุกบัญชี ฟิลด์เกิน ส่งข้อมูลออก ไม่มีบันทึกส่งออก และสำเนาหลังคำขอลบ ทั้งหมดทำเดโมง่ายขึ้น
| ความผิดพลาด | สิ่งที่รั่ว | แก้ไข |
|---|---|---|
| คีย์ CRM อยู่ในโค้ด เบราว์เซอร์ หรือแชต | ทุกอย่างในขอบเขตคีย์ หากสิทธิ์กว้างคือฐานลูกค้าทั้งหมด ผู้ติดต่อ ข้อตกลง และบันทึก มักแก้ไขได้ด้วย | ข้อมูลรับรองจำกัดเฉพาะเซิร์ฟเวอร์และปิดคีย์เก่า |
| เผยแพร่ผ่านลิงก์สาธารณะ | ข้อมูลติดต่อ อีเมล โทรศัพท์ ที่อยู่ ประวัติซื้อ และหน้าราคาส่วนลด เปิดให้ทุกคนที่รู้ที่อยู่รวมคู่แข่ง | วางเครือข่ายส่วนตัวหรือเข้าระบบบริษัทไว้หน้าเครื่องมือ |
| ผู้ขายทุกคนเห็นทุกบัญชี | กระบวนการขาย คาดการณ์ และมูลค่าทั้งหมด คนลาออกส่งออกพอร์ตลูกค้าทั้งหมดได้ | บทบาทตามเจ้าของ CRM ตรวจที่เซิร์ฟเวอร์สำหรับดู ค้น และส่งออก |
| ดึงทุกฟิลด์แทนไม่กี่ฟิลด์ | ประวัติซื้อ ชำระ มูลค่าบัญชี และรายละเอียดสนับสนุนในเครื่องมือวันต่ออายุ | ดึงเฉพาะฟิลด์ที่ระบุ |
| ข้อมูลไป API AI และบริการอื่น | ข้อมูล กลุ่ม และคะแนนลูกค้าเป้าหมายหรือสถานะลูกค้าอยู่กับผู้ให้บริการไร้สัญญา | ตรวจข้อมูลออก ลด และทำสัญญาส่วนที่เหลือ |
| ไม่บันทึกว่าใครส่งออกอะไร | รายการหรือกลุ่มออกไปโดยไม่รู้เวลาและคน | บันทึกส่งออกที่แอปแก้ไม่ได้ |
| เก็บสำเนาของตัวเอง | ลบใน CRM ไม่ถึงสำเนา ไฟล์ส่งออก และคะแนนอนุพันธ์ | เก็บน้อยและให้สำเนาตาม CRM |
AI ที่สร้างแอปแก้ส่วนใหญ่ได้เมื่อขอ ปรับคำสั่งตาม CRM วัตถุและบทบาทของคุณ
รายงาน AI ว่าแก้แล้วไม่ใช่หลักฐาน การทดสอบใต้คำสั่งต่างหากคือหลักฐาน ใช้คำสั่งกับโค้ด อย่าวางคีย์จริงหรือระเบียนลูกค้าจริงในแชต
นำคีย์ออกจากโค้ด เบราว์เซอร์ และแชต
คีย์ที่วางในโค้ดหรือแชตเปิดเผยแล้ว ตัวแปรสภาพแวดล้อมที่เซิร์ฟเวอร์ส่งตอนเริ่มให้โค้ดอ้างชื่อแทนค่าก็เหมือนกัน หากโค้ดใช้ในเบราว์เซอร์ ใครเปิดหน้าก็คัดลอกคีย์ที่เบราว์เซอร์อ่านได้
เอกสาร Vite บอกว่าตัวแปรขึ้นต้น VITE_ “จะเปิดในซอร์สโค้ดฝั่งลูกข่าย” เอกสารสภาพแวดล้อม Next.js อธิบายว่า NEXT_PUBLIC_ ก็รวมค่าในไฟล์ที่เบราว์เซอร์ดาวน์โหลด
คีย์ในไฟล์ที่ commit แล้วอยู่ในประวัติ เช่นความลับที่เขียนตายตัวใน Composeอยู่ยาวกว่าคอนเทนเนอร์ คลังส่วนตัวไม่ใช่ที่หลบ รายงาน GitGuardian ปี 2026 พบโอกาสมีความลับในคลังภายในราวหกเท่าคลังสาธารณะ ประมาณ 28% ของเหตุเริ่มนอกคลังทั้งหมด ใน Slack, Jira หรือ Confluence
ค้นทุกคีย์ API โทเคน รหัสผ่าน และสตริงเชื่อมต่อของ Salesforce, HubSpot, Pipedrive, Zoho หรือ CRM และเครื่องมือขายอื่น ตรวจโค้ด ไฟล์ .env ทุกไฟล์ และประวัติ commit
แต่ละรายการให้บอก:
- ไฟล์และบรรทัดที่พบ
- เขียนในโค้ดโดยตรงหรืออ่านจากตัวแปรสภาพแวดล้อม
- โค้ดใช้บนเซิร์ฟเวอร์หรือเบราว์เซอร์ ทำเครื่องหมายชื่อเริ่ม VITE_ หรือ NEXT_PUBLIC_
อย่าแสดงคีย์ครบ แสดงเพียงสี่อักขระแรก
จากนั้นย้ายการเรียก CRM ทั้งหมดไปโค้ดเซิร์ฟเวอร์ที่อ่านตัวแปรเฉพาะเซิร์ฟเวอร์ ลบคีย์จากโค้ด กันไฟล์ค่าจริงออกจากคลัง และรายงานการเปลี่ยนตรง ๆ ไม่แน่ใจให้บอก อย่าเดา
หมายเหตุ: ลบข้อความหรือ commit ไม่ทำให้คีย์ลับอีกครั้ง หลังวางหรือบันทึก ต้องปิดใน CRM เท่านั้น
การหมุนคีย์คือออกใหม่และปิดเก่า เป็นงานมนุษย์ สร้างข้อมูลจำกัดใน CRM ขอไอทีช่วยตั้งในเซิร์ฟเวอร์ แล้วปิดเก่า
สำหรับโทเคนแอปส่วนตัวที่รั่ว HubSpot มี Rotate and expire now ใน Pipedrive ให้ตรวจว่ามีการเชื่อมต่ออื่นใดใช้โทเคนเก่าอยู่ก่อนเปลี่ยน
สำเนารหัสผ่านผู้ดูแลที่คนใช้ควรอยู่ในตัวจัดการอย่าง Vaultwarden เซิร์ฟเวอร์เข้ากับ Bitwarden ใช้ให้คนเข้าสู่ระบบ ส่วนหมุนความลับแอปส่วนกลางพิจารณา HashiCorp Vault
ทดสอบ: เปิดเครื่องมือและเครื่องมือผู้พัฒนา ค้นแปดอักขระแรกคีย์ใหม่ในไฟล์ทั้งหมด (Ctrl+Shift+F หรือ Cmd+Option+F บน Mac) ต้องไม่พบ เรียก CRM แล้วดูแท็บเครือข่าย คีย์ห้ามอยู่ใน URL หัวหรือเนื้อหาคำขอ ขอผู้ดูแลยืนยันคีย์เก่าถูกปฏิเสธหรือดูสถานะการเชื่อม
ถอดลิงก์สาธารณะ
AI โฮสต์แอปแล้วเผยแพร่บนโดเมนผู้ขาย RedAccess พบผ่านค้น Google และ Bing ง่าย ๆ ราคาและส่วนลดอ่านได้เท่ากันสำหรับคู่แข่งและผู้ขาย
Lovable บอก Wired ว่าผู้สร้างรับผิดชอบการตั้งค่า ซึ่งมีเหตุผล แพลตฟอร์ม “ให้เครื่องมือสร้างอย่างปลอดภัย แต่การตั้งค่าเป็นความรับผิดชอบผู้สร้างสุดท้าย” คุณต้องเปลี่ยนการเผยแพร่
แสดงทุกหน้า เส้นทาง API ดาวน์โหลดและส่งออก แต่ละอย่างบอก:
- เปิดโดยไม่ล็อกอินได้ไหม
- คืนข้อมูลลูกค้า ข้อตกลง หรือราคาไหม
ทำเครื่องหมายเส้นทางคืนข้อมูลให้คำขอไม่ล็อกอิน อย่าเปลี่ยนก่อน ขอรายการก่อน
ทดสอบ: ใช้โทรศัพท์มือถืออยู่นอกเครือข่ายส่วนตัว เปิดหน้าต่างส่วนตัว ต้องไม่โหลดหรือหยุดที่เข้าระบบบริษัท ลองทุกเส้นทางข้อมูลแบบเดียวกัน ต้องไม่มีข้อมูล
แสดงเฉพาะบัญชีของแต่ละคน
ไม่มีบทบาท ทุกคนเห็นข้อมูลขาย มูลค่า ส่วนลดทั้งหมด และส่งออกก่อนออกงานได้ แก้ด้วยบทบาทตามเจ้าของ CRM ที่ตรวจในเซิร์ฟเวอร์ รวมค้นและส่งออก
เพิ่มสามบทบาทตรวจทุกคำขอที่เซิร์ฟเวอร์ ซ่อนปุ่ม เมนู หรือคอลัมน์ไม่ใช่ตรวจ
- ผู้ดูแล เจ้าของเครื่องมือและปฏิบัติการขาย: ทุกระเบียน
- ผู้จัดการ: ระเบียนของสมาชิกทีมตน
- ผู้ขายหรือผู้ดูแลลูกค้า: ที่ฟิลด์เจ้าของ CRM ระบุตนเท่านั้น
ใช้ตัวตนและบทบาทจากบัญชีที่ล็อกอิน ไม่ใช่ค่าที่แก้ในหน้า ใช้กฎเดียวกับค้น รายการ ส่งออก และ API ปฏิเสธอื่นด้วย “ไม่อนุญาตให้เข้าถึง” (403)
เสร็จแล้วรายงานการตรวจบทบาททุกหน้าและเส้นทาง พร้อมความไม่แน่ใจ
หมายเหตุ: ซ่อนเมนูหรือคอลัมน์ไม่ตรวจสิทธิ์ ไม่มีเซิร์ฟเวอร์ตรวจข้อมูลก็ห่างแค่คำขอเดียว
ปรับชื่อบทบาทและนิยามทีมได้ บางทีมให้ผู้จัดการดูทุกภูมิภาคระหว่างประชุมคาดการณ์
ทดสอบ: สร้างผู้ขายทดสอบ ค้นบัญชีต่างพื้นที่ต้องไม่พบ ส่งออกมีเฉพาะของตน ทำซ้ำด้วยผู้จัดการสำหรับบัญชีนอกทีม
ดึงเฉพาะฟิลด์จำเป็น
ติดตามต่ออายุใช้วัน เจ้าของ และชื่อบัญชี “ข้อมูลทั้งหมด” ได้ซื้อ ชำระ และข้อความสนับสนุนด้วย ฟิลด์น้อยทำรั่วน้อย จุดลบน้อย ส่งออกน้อย
แสดงฟิลด์ในฐาน โค้ด หน้าจอ ส่งออกและ API ที่มีข้อมูลส่วนตัวหรือการค้า: ชื่อ เมล โทรศัพท์ ที่อยู่ บริษัท ตำแหน่ง ซื้อ มูลค่าบัญชี ชำระ ยอด ส่วนลด คะแนนลูกค้าเป้าหมายหรือสถานะ เนื้อหาช่วยเหลือ และรหัสเฉพาะ
ระบุหน้าหรือฟังก์ชันและจำเป็นกับเป้าหมายหลักไหม ไม่แน่ใจให้ระบุ
เปลี่ยนคำขอ CRM เป็น [ฟิลด์ที่อนุมัติ] เท่านั้น ลบอื่นจากสำเนา หน้าจอ และส่งออก รายงานตรงตามที่เปลี่ยน
สิทธิ์เชื่อมเป็นกุญแจที่สอง ข้อมูลอ่านไม่ได้ไม่รั่วด้วยบั๊ก AI การเข้ารหัสเก็บต้องถามไอที ผู้ช่วยดูโค้ดรู้แน่ไม่ได้
ทดสอบ: ส่งออกด้วยผู้ดูแล เทียบรายการอนุมัติ ห้ามคอลัมน์เกิน ดูทุกหน้าว่าฟิลด์หาย เก็บรายการใช้การทดสอบถัดไป
ดูข้อมูลที่ออกจากเครื่องมือ
ตัวคำนวณเสียลูกค้าที่ส่งบันทึกไป API AI ฟิลด์ไปวิเคราะห์ หรือเรียก webhook กำลังคัดลอกออก GDPR กำหนดผู้ทำแทนบริษัทเป็นผู้ประมวลผลและต้องมีสัญญาตามด้านล่าง
ตรวจทุกการเรียก OpenAI, Anthropic หรือ AI API อื่น CRM เมล แชต วิเคราะห์และ webhook
ระบุฟิลด์ในเนื้อหาหรือที่อยู่ให้ตรง ทำเครื่องหมายบริการที่อาจเก็บ บันทึก หรือฝึกจากข้อมูล และบอกสิ่งที่ใช้ฟิลด์น้อยลงหรือไม่ใช้ข้อมูลลูกค้าได้
ทดสอบ: เปิดรายการฟิลด์รับในแต่ละบริการ เช่นคุณสมบัติผู้ใช้วิเคราะห์หรือแมป webhook เทียบอนุมัติ นอกนั้นยังออก ถ้าไม่มีรายการส่งชื่อและเงื่อนไขให้ DPO หรือฝ่ายความเป็นส่วนตัว
บันทึกทุกส่งออกและดาวน์โหลดจำนวนมาก
ปุ่มส่งออกส่งรายการลูกค้าหรือราคาในคลิกเดียว ไร้บันทึกไม่รู้ใครเอาอะไร จดทุกการดูหน้าจะกลบสัญญาณ ให้จดส่งออก ดูจำนวนมาก และลบ
เพิ่มบันทึกทุกส่งออก ดาวน์โหลด การดูเกิน [จำนวนที่เลือก] ระเบียน และลบ บันทึกผู้ใช้ การทำ ระเบียนหรือกลุ่ม จำนวนแถว และเวลา
บัญชีฐานข้อมูลแอปเพิ่มแถวได้ แต่แก้หรือลบไม่ได้ ผู้ดูแลอ่านได้เท่านั้น บอกสิทธิ์และสิ่งที่บังคับระดับฐานไม่ได้
แก้ไม่ได้ต้องมาจากสิทธิ์บัญชีฐานที่จำกัดได้เหมือนบัญชีอื่น ไม่ใช่แอปทำตัวดี บันทึกเองเป็นข้อมูลส่วนบุคคล บอกใครเอาข้อมูลใคร จึงอ่านเฉพาะผู้ดูแล
ทดสอบ: ผู้ขายทดสอบส่งออกรายการเล็ก ผู้ดูแลหาแถวจำนวนถูก ให้ไอทีหรือ AI ที่แสดงผลลองลบด้วยบัญชีแอป ต้องผิดพลาดสิทธิ์
ให้สำเนาตาม CRM เมื่อขอลบ
CRM เป็นหลักก็ลบที่นั่นก่อน แคช ไฟล์ส่งออก หรือคะแนนเป็นที่สองที่ CRM ลบไม่ถึง
ปุ่มลบทุกอย่างครั้งเดียวเสี่ยงถ้าใครก็กดได้ ฉันเห็นว่าควรเก็บน้อยที่สุดเพื่อให้ลบตามน้อยที่
ปรับแอปให้อ่าน CRM ตามต้องการและเก็บเพียง [ฟิลด์อนุมัติที่ต้องเก็บ]
บอกทุกที่ที่เหลือ: ตาราง แคช ไฟล์ส่งออก คะแนนอนุพันธ์ และบันทึก
เพิ่มเครื่องมือลบเฉพาะผู้ดูแล ใส่ CRM ID แล้วแสดงทุกที่ หลังยืนยันลบทั้งหมดรวมคะแนนและส่งออก เก็บเพียง ID เวลา ผู้ยืนยันและจุดล้าง คนอื่นได้ “ไม่อนุญาตให้เข้าถึง”
DPO หรือฝ่ายความเป็นส่วนตัวกำหนดข้อยกเว้นต้องเก็บ คำสั่งจึงไม่รวม
ทดสอบ: สร้างผู้ติดต่อทดสอบ ให้แอปรับรวมคะแนนหรือส่งออกถ้ามี ลบ CRM แล้วผู้ดูแลรันลบ ตรวจทุกที่ ผู้ขายเปิดแล้วต้องถูกปฏิเสธ
เครื่องมือเชื่อม CRM ควรรันที่ไหน
ที่รันขึ้นกับสิ่งที่ทำ อ่านอย่างเดียวบนเซิร์ฟเวอร์ทีมผ่านเครือข่ายส่วนตัวหรือบริษัทได้ เขียนต้องไอทีหรือผู้ดูแล CRM ตรวจให้ก่อนใช้
| สิ่งที่ทำกับ CRM | สถานที่รัน | ผู้อนุมัติก่อนเริ่ม |
|---|---|---|
| ใช้ตัวอย่างหรือข้อมูลสังเคราะห์ที่โครงสร้างเหมือนจริง | โฮสต์ AI สำหรับพัฒนาและเดโม | ยังไม่มี ไม่ใส่ข้อมูลจริง |
| อ่านจริงสำหรับทีมเล็กคงที่ | เซิร์ฟเวอร์ทีมผ่าน Tailscale หรือ WireGuard ส่วนตัวเท่านั้น | ผู้ดูแล CRM ที่ออกหรืออนุมัติข้อมูลอ่านอย่างเดียว |
| อ่านจริงสำหรับผู้ขายกระจายหรือเดินทาง | เซิร์ฟเวอร์เดิม โดยมีการเข้าสู่ระบบบริษัทผ่านผู้ให้บริการยืนยันตัวตน เช่น Authentik หรือ Keycloak อยู่ด้านหน้า | ผู้ดูแล CRM และไอทีเชื่อมล็อกอิน |
| เขียนขั้น เจ้าของ ฟิลด์และแก้จำนวนมาก | สร้างและทดสอบบน sandbox หรือบัญชีทดสอบ ตรวจล่วงหน้าก่อนระบบจริง | ไอทีหรือผู้ดูแล CRM ก่อนเริ่ม |
| ตัดสินสินเชื่อส่วนบุคคล ความเสี่ยงหรือราคาประกันชีวิต/สุขภาพ หรืออารมณ์จากหน้า/เสียง | ไม่รันที่ใดก่อนตรวจ | ไอทีและกฎหมาย DPO หรือผู้ดูแลความเป็นส่วนตัว |
ใช้ตัวอย่างสร้างและทดสอบจนรันบนเซิร์ฟเวอร์ทีม แพลตฟอร์มจัดการที่มีเข้าระบบ ความลับและบันทึกเหมาะกับทีมที่มีงบและประเมินผู้ขายอยู่แล้ว
เครือข่ายส่วนตัวไม่ตอบอินเทอร์เน็ตสาธารณะ เข้าระบบครั้งเดียวใช้บัญชีบริษัทเดิมผ่านผู้ให้บริการตัวตน หน้าเข้าสู่ระบบที่ AI เขียนยังเข้าถึงจากทุกที่และขึ้นกับโค้ด
Vibe Security Radar ของ Georgia Tech ตรวจฐานช่องโหว่สาธารณะและชี้ข้อผิดพลาดที่ตามรอย AI ได้ มี 35 กรณีในมีนาคม 2026 มากกว่าทั้ง 2025 รวมข้ามการยืนยันตัวตน ตัวเลขจากบทความเมษายน 2026
นักวิจัย Hanqing Zhao กล่าวว่า “เอเจนต์สร้างโดยไม่มีการยืนยันตัวตนไม่ใช่พิมพ์ผิด แต่ผิดออกแบบตั้งแต่แรก” ฉันเห็นว่ากุญแจควรอยู่หน้าเครื่องมือ นอกโค้ด AI
ให้ไอทีช่วยเซิร์ฟเวอร์ แอปรันบน VPS เซิร์ฟเวอร์เช่าที่ทีมควบคุมทั้งหมด ผ่าน Coolify หรือ Dokploy ซึ่งรันโค้ดและเก็บสภาพแวดล้อมรวมคีย์ CRM
Tailscale ตั้งเร็วแต่ใช้เซิร์ฟเวอร์ประสานงานตนเอง Headscale ทางเลือกโอเพนซอร์สให้โฮสต์เอง ส่วน WireGuard โฮสต์เองทั้งหมด
เข้าระบบบริษัทใช้Authentik ที่เหมาะกับระบบภายในเล็กส่วนใหญ่ Keycloak เหมาะเมื่อมีไดเรกทอรี Caddy หรือ Nginx Proxy Manager เพิ่ม HTTPS ให้เข้าจากเว็บ กำหนดคนมีชื่อรับผิดชอบเซิร์ฟเวอร์และข้อมูลรับรอง
ยังต้องมีเซิร์ฟเวอร์ Linux VPS ของเรามี root ส่วน Coolify, Tailscale, WireGuard, Authentik และ Keycloak ติดตั้งคลิกเดียว ให้ไอทีเน้นทดสอบ มีแฟรงก์เฟิร์ต อัมสเตอร์ดัมใน EU ลอนดอนและหลายเมืองสหรัฐ ให้ DPO หรือผู้ดูแลใช้ตำแหน่งเป็นปัจจัยพิจารณา
GDPR, CCPA และกฎหมาย AI EU สำหรับข้อมูลลูกค้า
ตำแหน่งเซิร์ฟเวอร์กำหนดที่สำเนาตน ไม่กำหนดที่บริการภายนอกเก็บและไม่ทำให้ปฏิบัติตามเอง อังกฤษใช้ UK GDPR กำกับโดย ICO
GDPR: ฐานกฎหมาย ผู้ประมวลผล และการลบ
ถ้า GDPR ครอบคลุมบริษัท สำเนาเครื่องมือเหมือนการประมวลผลส่วนบุคคลอื่นที่“อัตโนมัติทั้งหมดหรือบางส่วน”
ใช้ข้อมูลทุกครั้งต้องมีฐานที่ยอมรับ สัญญาอาจใช้เมื่อจำเป็นต่อสัญญากับเจ้าของข้อมูลหรือขั้นก่อนสัญญาที่เขาขอ CRM โดยเฉพาะ B2B อาจใช้ประโยชน์ชอบธรรมที่ชั่งสิทธิ์บุคคล ทั้งสองอยู่มาตรา 6
เครื่องมือใช้ข้อมูลเดิมใหม่ ถาม DPO ความเป็นส่วนตัวหรือกฎหมายว่าฐานเดิมรวมไหม
บริการภายนอกทำแทนบริษัทเป็นผู้ประมวลผล AI API วิเคราะห์และโฮสต์มักเป็นแต่ต้องยืนยันรายบริการ มาตรา 28 ต้อง “รับประกันเพียงพอ” และสัญญาทุกการประมวลผล นำรายการตรวจข้อมูลออกไปด้วย
เมื่อสิทธิ์ลบมาตรา 17 ใช้ จะรวมทุกสำเนาบริษัทรวมเครื่องมือ จึงต้องตาม CRM
CCPA: สิทธิ์ลบถึงสำเนาเครื่องมือ
ผู้บริโภคแคลิฟอร์เนียขอธุรกิจที่ครอบคลุมลบข้อมูลเก็บเกี่ยวกับตน รวมสำเนาและส่งออกได้ หน้า CCPA อัยการสูงสุดแคลิฟอร์เนียระบุข้อยกเว้น Civil Code 1798.105(d) และ 1798.145
CCPA ยังต้องสัญญาลายลักษณ์จำกัดการใช้ของผู้ให้บริการและผู้รับเหมา บริษัทจัดคำขอและพวกเขาช่วยเมื่อบังคับ เกณฑ์ FAQ กำหนดครอบคลุมไหม
กฎหมาย AI EU: ส่วนใหญ่ขายและสนับสนุนไม่เสี่ยงสูง
คะแนนลูกค้าเป้าหมาย คาดการณ์ สถานะลูกค้า แผงแคมเปญและอัตโนมัติ CRM ไม่ใช่รายการเสี่ยงสูงภาคผนวก III ข้อยกเว้นจำกัดที่สินเชื่อบุคคล ประกันชีวิต/สุขภาพ และอารมณ์ชีวมิติ
เสี่ยงสูงมีหน้าที่หนักสุด ณ ตุลาคม 2026 กฎภาคผนวก III มีกำหนด 2 ธันวาคม 2027 ความโปร่งใสมาตรา 50 ใช้แล้ว ข้อ 5(b) ภาคผนวก III กฎหมาย AI EU ระบุ “ประเมินความน่าเชื่อถือเครดิตหรือคะแนนบุคคลธรรมดา ยกเว้น AI ตรวจทุจริตการเงิน”
5(c) คือ “ประเมินเสี่ยงและราคาบุคคลธรรมดาในประกันชีวิตและสุขภาพ” อาจสูงและต้องไอทีกฎหมายก่อนเริ่ม ประเมินผู้ขายตนอาจอยู่การจ้างงาน 4(b) เป็นงานฝ่ายบุคคลและกฎหมายแยก
1(c) รวมอารมณ์ มาตรา 3 นิยาม “ระบุหรืออนุมานอารมณ์หรือเจตนาบุคคลธรรมดาจากชีวมิติ” เครื่องมือโทรหรือสนับสนุนอ่านอารมณ์จากเสียงหรือหน้าจึงอาจสูงและผ่านกระบวนการเดียวกัน
กฎหมายดูระบบ AI แผงโค้ดธรรมดาไม่เป็น AI แค่ AI เขียน ต้องดูตัวระบบที่ติดตั้งตรงนิยามไหม
ไม่เสี่ยงสูงไม่ใช่ไร้กฎ มาตรา 50 บอกระบบที่ “สื่อสารตรงกับบุคคลธรรมดา” ต้องแจ้ง AI เว้นแต่ชัด แชตบอตลูกค้าก็ต้องบอกตน
แยกต่างหาก มาตรา 4 บังคับผู้ให้และผู้ใช้ส่งเสริมความรู้ AI ของพนักงานและผู้ทำแทนอยู่แล้ว
คำถามที่พบบ่อย
สร้าง CRM ด้วย ChatGPT หรือ Claude ปลอดภัยไหม
ใช้ตัวอย่างเสี่ยงต่ำ เริ่มเสี่ยงเมื่อมีคีย์จริงหรือข้อมูลลูกค้าและเพิ่มเมื่อเปิดคนอื่น ก่อนนั้นใช้ข้อมูล CRM จำกัดในเซิร์ฟเวอร์หรือคลังลับ ให้เฉพาะโค้ดเซิร์ฟเวอร์ใช้ และเครือข่ายส่วนตัวหรือบริษัทกันภายนอก ครบสองอย่างก่อนจึงใช้จริง
GDPR รวมแผงภายในที่ลูกค้าไม่เห็นไหม
หาก GDPR ใช้กับบริษัท แดชบอร์ดภายในที่มีข้อมูลส่วนบุคคลของลูกค้าก็ไม่เป็นข้อยกเว้น กฎเกี่ยวกับการประมวลผล ไม่ใช่ผู้ที่เห็นหน้าจอ ข้อมูลส่วนบุคคลคือ “ข้อมูลใด ๆ ที่เกี่ยวข้องกับบุคคลธรรมดาที่ระบุตัวแล้วหรือสามารถระบุตัวได้” ตามมาตรา 4 ให้ DPO ผู้ดูแลความเป็นส่วนตัวหรือที่ปรึกษากฎหมายตรวจว่ากฎใช้บังคับและฐานกฎหมายเดิมครอบคลุมเครื่องมือใหม่หรือไม่
มูลค่าข้อตกลงและส่วนลดเป็นข้อมูลส่วนตัวไหม
มักไม่ ยอด คาดการณ์และราคาเป็นข้อมูลบริษัท ใช้บทบาทและบันทึกป้องกัน แต่โยงคนระบุได้เช่นซื้อผู้บริโภคหรือเจ้าของคนเดียวอาจเป็นส่วนตัวตามมาตรา 4
CCPA ใช้ธุรกิจใด
ธุรกิจแสวงกำไรในแคลิฟอร์เนียถึงอย่างน้อยเกณฑ์หนึ่ง California Privacy Protection Agency ให้รายได้ปรับเงินเฟ้อ 2025 ที่ 26,625,000 ดอลลาร์ อีกสองคือซื้อ ขายหรือแชร์ข้อมูลอย่างน้อย 100,000 คนหรือครัวเรือนรัฐ หรืออย่างน้อย 50% รายได้ปีจากขาย/แชร์ข้อมูลผู้บริโภค ให้ DPO หรือกฎหมายยืนยัน
การสนทนา
ความคิดเห็น
เข้าสู่ระบบเพื่อร่วมสนทนา