เส้นทาง 03บทเรียน 1 / 6

กำหนดว่าข้อมูลไปที่ใดได้บ้าง

ติดตามข้อมูลผ่านเครื่องมือพัฒนา โมเดล log และบริการที่ deploy ตรวจสอบขอบเขตก่อนใช้ข้อมูลลับ

พื้นฐาน10 minตรวจทานแล้ว 5 ต.ค. 2569

ตรวจความเข้าใจต้นแบบใช้ฐานข้อมูลใน region ที่ได้รับอนุมัติ คุณวางระเบียนลูกค้าที่เป็นความลับลงในผู้ช่วยเขียนโค้ดได้หรือไม่ทำแบบฝึกหัด

แสดงคำตอบ

Hosting แอปพลิเคชันกับการประมวลผลระหว่างพัฒนาเป็นคนละขอบเขต การอนุมัติฐานข้อมูลไม่ได้แปลว่าอนุมัติเครื่องมือเขียนโค้ด

สิ่งที่จะได้เรียนรู้

แยกการไหลของข้อมูลระหว่างพัฒนาออกจากการไหลของข้อมูลแอปพลิเคชัน
ระบุหลักฐานที่ต้องมีก่อนส่งต่อข้อมูลลับ
ใช้ข้อมูลสมมติโดยไม่ซ่อนเงื่อนไขการทดสอบสำคัญ

แยกเส้นทางข้อมูลสองแบบ

Vibe coding มีประโยชน์สำหรับสำรวจ workflow ด้วยระเบียนสมมติ ความเสี่ยงเปลี่ยนเมื่อข้อมูลบริษัทจริงเข้าสู่เครื่องมือ เรื่องนี้เกิดได้ก่อนแอปพลิเคชันจะมีผู้ใช้เสียอีก

มีเส้นทางข้อมูลสองแบบที่ต้องตรวจดู เส้นทางระหว่างพัฒนารวม prompt บริบท repository ไฟล์แนบ output ของเครื่องมือ และ log วินิจฉัยปัญหา เส้นทางของแอปพลิเคชันรวมคำขอผู้ใช้ ฐานข้อมูล การเชื่อมต่อ telemetry และ backup แต่ละเส้นทางอาจมีผู้รับและมาตรการควบคุมต่างกัน

พิจารณาแอปค่าใช้จ่ายสมมติ ฐานข้อมูลทำงานในบัญชี cloud ที่อนุมัติแล้ว Developer วางคำขอเบิกเงินจริงลงในผู้ช่วยเพื่อแก้ parser คำขอนั้นมีชื่อพนักงาน ใบเสร็จ และรายละเอียดธนาคาร ตำแหน่งฐานข้อมูลที่อนุมัติไม่ได้ให้สิทธิ์เปิดเผยข้อมูลในเส้นทางแยกนี้

ตรวจดูเส้นทางทั้งหมด

วาดเส้นทางก่อนเพิ่มข้อมูลลับ ระบุบริการและบัญชีจริงในแต่ละขั้น ป้ายผลิตภัณฑ์ เช่น “enterprise” ไม่ใช่แผนภาพการไหลของข้อมูล

จุดในเส้นทาง	คำถามที่ต้องตอบ
Editor หรือ agent	อ่านไฟล์และไฟล์แนบใดได้บ้าง
บริการโมเดล	ใครได้รับ prompt และผลจากเครื่องมือ
Log และประวัติ	เก็บอะไร ที่ไหน และนานเท่าใด
สิทธิ์เข้าถึงของฝ่ายช่วยเหลือ	ใครตรวจดูเนื้อหาที่เก็บไว้ได้
เครื่องมือที่เชื่อมต่อ	ข้อมูลที่ดึงมาส่งต่อไปปลายทางอื่นได้หรือไม่
Hosting แอปพลิเคชัน	บัญชี region และเครือข่ายใดเก็บข้อมูลผู้ใช้

บันทึกสัญญาและ configuration ที่ใช้ ตรวจสอบผู้ประมวลผลช่วงต่อ พฤติกรรมการลบ เงื่อนไขการใช้ข้อมูลฝึกโมเดล และการโอนข้อมูลระหว่างประเทศตามความเกี่ยวข้อง ขอให้ผู้รับผิดชอบความเป็นส่วนตัวและความปลอดภัยหาคำตอบสำหรับสิ่งที่ยังไม่แน่ใจ

ข้อกำหนด GDPR ขึ้นอยู่กับบริบทการประมวลผล บทบัญญัติที่เกี่ยวข้องรวมการใช้ข้อมูลเท่าที่จำเป็น ข้อตกลงกับผู้ประมวลผล ความปลอดภัย และการประเมินผลกระทบ ความลับของบริษัทยังครอบคลุมข้อมูลที่ไม่ใช่ข้อมูลส่วนบุคคล เช่น source code หรือแผนธุรกิจ อ่านข้อบังคับ

เริ่มจาก fixture สมมติที่มีประโยชน์

ตัวอย่างที่ปลอดภัยยังต้องมีโครงสร้างสมจริง เปลี่ยนชื่อ ตัวระบุ และเลขบัญชี รักษาเงื่อนไขที่ทำให้เกิดข้อบกพร่อง เช่น field ที่ขาด วันที่ผิดปกติ หรือคำอธิบายยาว

อย่าติดป้ายระเบียนที่คัดลอกจาก production ว่า “ข้อมูลสังเคราะห์” หลังเปลี่ยนชื่อเพียงชื่อเดียว Field ที่เหลืออาจระบุตัวบุคคลหรือเปิดเผยธุรกรรมได้ สร้างระเบียนใหม่จาก schema และเงื่อนไขที่ทำให้ผิดพลาด

กันข้อมูลรับรองออกจาก prompt และ fixture หากงานต้องใช้ secret ให้ใช้กลไก secret ที่ได้รับอนุมัติและมีสิทธิ์จำกัด คำสั่งว่า “เก็บเรื่องนี้เป็นความลับ” ไม่ได้บังคับใช้ขอบเขตทางเทคนิค

ตรวจสอบก่อนขยายการใช้งาน

เขียนการตัดสินใจเรื่องการใช้งานที่อนุญาตแบบสั้น ๆ ระบุประเภทข้อมูล configuration บริการที่อนุมัติ การดำเนินการที่อนุญาต และผู้รับผิดชอบ รวมวันหมดอายุหรือเงื่อนไขให้ทบทวน Connector ใหม่ เส้นทางโมเดลใหม่ หรือ configuration log ใหม่อาจเปลี่ยนการตัดสินใจได้

หากข้อมูลไปถึงผู้รับที่ไม่ได้รับอนุมัติ ให้หยุดการเปิดเผยเพิ่มและทำตามกระบวนการ incident บันทึกว่าส่งอะไรไปที่ไหน หลีกเลี่ยงการคัดลอกเนื้อหาอ่อนไหวลง ticket หรือ chat เพิ่ม

เป้าหมายเชิงปฏิบัติคือการใช้งานที่ควบคุมได้ ข้อมูลสมมติช่วยให้สำรวจได้เร็ว ขอบเขตการประมวลผลที่ตรวจสอบแล้วรองรับขั้นต่อไปเข้าสู่ workflow บริษัท ทั้ง demo ที่ดูดีและ cloud region ไม่ได้ตอบทุกคำถามที่จำเป็น

ทำแบบฝึกหัด

วาดเส้นทางข้อมูลสองแบบสำหรับแอปค่าใช้จ่ายสมมติ ได้แก่ ระหว่างพัฒนาและใน production รวม editor, agent, ผู้ให้บริการโมเดล, log, ฐานข้อมูล และสิทธิ์เข้าถึงของฝ่ายช่วยเหลือ ทำเครื่องหมายผู้รับที่ยังไม่ทราบ แทนระเบียนค่าใช้จ่ายจริงหนึ่งรายการด้วย fixture สมมติที่รักษาเงื่อนไขทดสอบเดิม

ดาวน์โหลดใบงาน (Markdown)

ตรวจความเข้าใจ ↑