หน่วย
1. ปัญญาประดิษฐ์สำหรับทีมซอฟต์แวร์: รูปแบบการทำงานและขีดจำกัด 2. การเขียนสคริปต์และการเติมข้อความอัตโนมัติ 3. การอ่านโค้ด คำอธิบาย และความเข้ากันได้กับฐานโค้ดใหม่ 4. การตรวจสอบโค้ดและการค้นหาข้อผิดพลาด 5. ทดสอบการผลิตและการประกันคุณภาพ 6. การดีบักและการวิเคราะห์สาเหตุที่แท้จริง 7. การวิเคราะห์บันทึกและการสังเกต 8. การปรับโครงสร้างหนี้ใหม่และการจัดการหนี้ทางเทคนิค 9. เอกสารประกอบ README และความคิดเห็นเกี่ยวกับโค้ด 10. การใช้งานที่ปลอดภัย: ปราศจากการรั่วไหลและการรักษาความลับ 11. การตรวจสอบรหัส ช่องโหว่ และความเสี่ยงของเอาท์พุต AI 12. เครื่องมือเข้ารหัส AI และการรวมเวิร์กโฟลว์
หน่วย 10 / 12

การใช้งานที่ปลอดภัย: ปราศจากการรั่วไหลและการรักษาความลับ

กำไร:

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

ทุกสิ่งที่คุณวางลงในผู้ช่วยเขียนโค้ดอาจไม่สามารถควบคุมได้ คีย์ API, ดัมพ์ฐานข้อมูลลูกค้า, ซอร์สโค้ดที่เป็นกรรมสิทธิ์ที่ยังไม่ได้ประกาศ หรือบันทึกผู้ป่วย สิ่งเหล่านี้อาจกลายเป็นการรั่วไหลที่แก้ไขไม่ได้เมื่อเข้าไปในเครื่องมือที่ไม่ได้รับการอนุมัติ ความเสี่ยงที่ใหญ่ที่สุดของ AI สำหรับทีมซอฟต์แวร์ไม่ได้มาจากข้อผิดพลาดในบรรทัด แต่มาจากการคัดลอกและวางอย่างไม่ระมัดระวัง หน่วยนี้เกี่ยวกับการทำให้การคัดลอกและวางนั้นปลอดภัย

ที่นี่เราแยกความแตกต่างสามสิ่ง: ข้อมูลใดที่ไม่ควรป้อนข้อมูล เครื่องมือใดที่สามารถใช้กับสิ่งที่ป้องกันได้ และวิธีการรักษาความปลอดภัยข้อมูลก่อนที่จะป้อนข้อมูล (การมาสก์ ข้อมูลสังเคราะห์ การทำงานในเครื่อง) นี่ไม่ใช่ทางเลือก "มันคงจะดี"; เป็นภาระผูกพันตามสัญญาและทางกฎหมายในสถาบันส่วนใหญ่

เหตุใดจึงสำคัญมาก?

ข้อมูลที่คุณส่งไปยังเครื่องมือ AI ประมวลผลบนเซิร์ฟเวอร์ของผู้ให้บริการ ซึ่งบางครั้งเก็บไว้เป็นระยะเวลาหนึ่ง สามารถใช้เพื่อปรับปรุงโมเดลในการตั้งค่าผลิตภัณฑ์บางอย่าง การพูดว่า "ฉันลบแชทแล้ว" มักจะไม่เพียงพอ ทันทีที่ข้อมูลออกจากเครือข่าย ความเสี่ยงก็เกิดขึ้น นอกจากนี้ ต้นทุนของการรั่วไหลยังสูง: คลาวด์คีย์ที่รั่วไหลสามารถนำมาใช้ในทางที่ผิดได้ภายในไม่กี่นาที ข้อมูลลูกค้าที่รั่วไหลอาจส่งผลให้เกิดการแจ้งเตือนและบทลงโทษภายใต้กฎระเบียบ เช่น KVKK/GDPR และซอร์สโค้ดส่วนตัวที่รั่วไหลสามารถทำลายความได้เปรียบทางการแข่งขันได้

ดังนั้นหลักการง่ายๆ ก็คือ ห้ามนำสิ่งของใดๆ เข้าไปในยานพาหนะที่ไม่ได้รับการรับรองซึ่งคุณไม่สามารถจะสูญเสียไปได้ หากมีข้อสงสัยอย่าเข้า

ข้อควรระวัง: ความคิด "เพียงครั้งเดียว อย่างรวดเร็ว" เป็นสาเหตุที่พบบ่อยที่สุดของการรั่วไหล การวางบันทึกการใช้งานจริงหรือไฟล์การกำหนดค่าในขณะที่แก้ไขจุดบกพร่องเร่งด่วนคือสิ่งที่เกิดขึ้นกับการตัดสินใจภายใต้ความกดดัน ความเร่งด่วนไม่ได้ระงับกฎการรักษาความลับ

สิ่งที่ไม่ควรกรอก (เส้นสีแดง)

  • ข้อมูลลับ: คีย์ API, รหัสผ่าน, คีย์การเข้าถึงระบบคลาวด์, ใบรับรองส่วนตัว, โทเค็น, สตริงการเชื่อมต่อ
  • ข้อมูลส่วนบุคคล (PII): ชื่อ-นามสกุล หมายเลข TR ID อีเมล โทรศัพท์ ที่อยู่ บันทึกสุขภาพ/การเงิน ข้อมูลลูกค้า
  • ทรัพย์สินทางธุรกิจที่เป็นความลับ: ซอร์สโค้ดที่ไม่เปิดเผย, อัลกอริธึมที่เป็นกรรมสิทธิ์, ความลับของสถาปัตยกรรมภายใน, รายละเอียดสัญญา
  • ข้อมูลที่ควบคุม: หมวดหมู่ที่ได้รับการคุ้มครองพิเศษ เช่น การดูแลสุขภาพ บัตรชำระเงิน (PCI) การเงินส่วนบุคคล

ทีละขั้นตอน: ขั้นตอนการใช้งานที่ปลอดภัย

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

มินิเคสสามอัน

กรณีที่ 1 — คีย์ที่วางถูกยกเลิก นักพัฒนาวางไฟล์การกำหนดค่าทั้งหมดลงใน AI ในขณะที่แก้ไขข้อบกพร่อง ไฟล์นี้มีคีย์ API ของบุคคลที่สามที่ใช้งานอยู่ เมื่อทีมงานสังเกตเห็น พวกเขาก็ยกเลิก (หมุน) คีย์ทันทีและสร้างคีย์ใหม่ขึ้นมา ไม่มีการละเมิด แต่เป็นเหตุการณ์ที่ 'ถูก' บทเรียน: ลอกสารเคลือบออกก่อนที่จะติดกาว—และหมุนกุญแจทันทีหากเกิดการรั่วไหล

กรณีที่ 2 — ข้อมูลสังเคราะห์ช่วยชีวิตธุรกิจได้ ทีมกำลังประสบกับข้อผิดพลาดในการแยกวิเคราะห์กับเรกคอร์ดลูกค้าจริง แทนที่จะป้อนข้อมูลจริง พวกเขาสร้างข้อมูลสังเคราะห์ 20 บรรทัดที่มีโครงสร้างเดียวกันแต่เป็นของปลอมโดยสิ้นเชิง สร้างข้อผิดพลาดขึ้นมาใหม่และแก้ไขด้วย AI PII ไม่รั่วไหลหรือการวินิจฉัยช้าลง ข้อมูลสังเคราะห์มีความปลอดภัยและเพียงพอ

กรณีที่ 3 — ความลับที่ซ่อนอยู่ในสิ่งพิมพ์ เมื่อสร้างการกำหนดค่าตัวอย่าง AI จะฝังคีย์ "ตัวอย่าง" ที่ดูสมจริงลงไปและใส่ลงในโค้ดโดยที่นักพัฒนาไม่สังเกตเห็น การสแกนฐานโค้ด (เครื่องสแกนลับ) จับสิ่งนี้ได้และเตือน ความลับที่ไม่เปลี่ยนรูปไม่ควรทำให้กลายเป็นโค้ด วิธีที่ถูกต้องคือการใช้ตัวแปรสภาพแวดล้อมหรือตัวจัดการข้อมูลลับ บทเรียน: สแกนผลลัพธ์เพื่อหาความลับด้วย

เทมเพลตที่คัดลอกได้สี่แบบ

รายการตรวจสอบการปิดบังก่อนเข้า (ด้วยตนเอง):

ก่อนที่จะส่งข้อความนี้ให้กับ AI โปรดแน่ใจว่าฉันได้ลบข้อมูลต่อไปนี้ออกแล้วแทนที่สิ่งที่คุณพบด้วย [MASKED]: คีย์ API, รหัสผ่าน, โทเค็น, สตริงการเชื่อมต่อ, ชื่อ-นามสกุล, อีเมล, โทรศัพท์, หมายเลข ID, ข้อมูลลูกค้า ข้อความ:{{ข้อความ}}

การสร้างข้อมูลการทดสอบสังเคราะห์:

สร้างข้อมูลการทดสอบแถว {{N}} ที่สร้างขึ้นอย่างสมบูรณ์ (ไม่เกี่ยวข้องกับบุคคล/สถาบันจริง) ตามรูปแบบด้านล่าง ทำให้ดูสมจริง แต่อย่าใช้ PII จริงใดๆ สคีมา: {{fields and types}}รวมตัวพิมพ์ขอบ (ว่างเปล่า ขอบเขต รูปแบบไม่ถูกต้อง)

แก้ไขการล่าความลับ (ในรหัส):

ค้นหาความลับแบบฮาร์ดโค้ดในโค้ด/การกำหนดค่านี้: คีย์ รหัสผ่าน โทเค็น URL ที่กำหนดเอง หากคุณพบ ให้ระบุตำแหน่งของมันและแนะนำวิธีการที่ถูกต้อง (ตัวแปรสภาพแวดล้อม / ตัวจัดการความลับ) รหัส:{{รหัส}}

การประเมินความสอดคล้องของยานพาหนะ (ตามระดับข้อมูล):

ฉันมีข้อมูลประเภทต่อไปนี้: {{คลาส: สาธารณะ / ภายใน / ความลับ / ควบคุม}} เครื่องมือที่ฉันตั้งใจจะใช้คือ: {{tool}} ฉันควรยืนยันมาตรการป้องกันใดบ้าง (พื้นที่เก็บข้อมูล การไม่ใช้ในการศึกษา ภูมิภาค การเข้าถึง) ก่อนประมวลผลข้อมูลนี้ในเครื่องมือนี้ ให้รายการตรวจสอบ การตัดสินใจเป็นของฉัน คุณชี้แจงเกณฑ์

พรอมต์อ่อน / พรอมต์แข็งแกร่ง

จุดอ่อน: (วางแถวผู้ใช้จริง 200 แถวที่ดึงมาจากฐานข้อมูลที่ใช้งานจริง) "เหตุใดจึงมีข้อผิดพลาดในการแยกวิเคราะห์ในข้อมูลนี้"
แข็งแกร่ง: "ด้านล่างคือ 15 แถวที่มีโครงสร้างเหมือนกับข้อมูลจริง แต่สังเคราะห์โดยสมบูรณ์ (ไม่มี PII) parse_user() ส่ง ValueError ไปที่ 3, 8 และ 12 แถวเหล่านี้ รูปแบบทั่วไปอาจเป็นอะไร ฉันจะแก้ไขได้อย่างไร"

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

คลาสข้อมูล

สามารถประมวลผลเป็น AI ได้หรือไม่?

ข้อกำหนดเบื้องต้น

สาธารณะ

ใช่

การใช้งานภายใน (ไม่แม่นยำ)

โดยทั่วไปแล้ว

ปฏิบัติตามนโยบายองค์กร

เป็นความลับ (ซอร์สโค้ด ความลับทางธุรกิจ)

รถที่ได้รับอนุมัติเท่านั้น

การประกันองค์กร + การย่อขนาด

PII / ได้รับการควบคุม

ตามกฎหมายเลข

ปิดบัง/ไม่ระบุชื่อ หรือใช้การสังเคราะห์

การปฏิบัติตามนโยบายและการติดตาม

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

เคล็ดลับ: กำหนดรายการ "ละเว้น" เฉพาะโปรเจ็กต์ (เช่น .env, โฟลเดอร์ที่ซ่อน, ไฟล์ข้อมูลระบุตัวตน) ในเครื่องมือ Editor/CLI ของคุณ เพื่อให้ไฟล์เหล่านี้ไม่ถูกรวมไว้ในบริบทของผู้ช่วยโดยไม่ได้ตั้งใจ การป้องกันมีราคาถูกกว่าการทำความสะอาดเสมอ

ข้อผิดพลาดทั่วไป

  • การวางข้อมูลที่ละเอียดอ่อน "เพียงครั้งเดียว" ความเร่งด่วนไม่ได้ระงับเส้นสีแดง การรั่วไหลที่พบบ่อยที่สุดเกิดขึ้นที่นี่
  • กำลังคิดว่า "ฉันจะลบการสนทนา" ทันทีที่ข้อมูลออกจากเครือข่าย ความเสี่ยงก็เกิดขึ้น การลบไม่ใช่การเลิกทำ
  • การเลือกรถโดยไม่ดูระดับ การประมวลผลข้อมูลองค์กรที่เป็นความลับด้วยบัญชีส่วนบุคคลถือเป็นการละเมิดอย่างร้ายแรง
  • ไม่สแกนเอาท์พุต AI สามารถฝังความลับที่ไม่เปลี่ยนรูปลงในโค้ดได้ ตรวจสอบการผลิตด้วยเครื่องสแกนลับ
  • ไม่หมุนเมื่อความลับรั่วไหล การไม่เพิกถอนคีย์ที่รั่วไหลจะทำให้การรั่วไหลกลายเป็นการหาประโยชน์แบบเรียลไทม์

โดยสรุป

ความเสี่ยงที่ใหญ่ที่สุดของ AI ในซอฟต์แวร์คือการรั่วไหลของความเป็นส่วนตัว และส่วนใหญ่เกิดจากการตัดสินใจคัดลอกและวางภายใต้การข่มขู่ กฎมีความชัดเจน: ความลับ ข้อมูลส่วนบุคคล ทรัพย์สินทางธุรกิจที่เป็นความลับ และข้อมูลควบคุมจะไม่ถูกป้อนเข้าไปในเครื่องมือที่ไม่ได้รับการอนุมัติ จำแนกข้อมูลก่อนอินพุต เลือกเอเจนต์ตามคลาส แยกข้อมูลลับ ปิดบัง PII หรือใช้ข้อมูลสังเคราะห์ ลดบริบท และสแกนเอาต์พุตเพื่อหาข้อมูลลับด้วย หากมีการรั่วไหล สิ่งแรก: คืนข้อมูลรับรองและรายงาน

งานสมัคร

นำโค้ด/บันทึก/ข้อมูลที่คุณให้เมื่อเร็วๆ นี้ (หรือกำลังพิจารณาที่จะให้) ให้กับ AI ขั้นแรก ระบุผู้สมัครที่เป็นความลับและ PII ภายในด้วยเทมเพลต "รายการตรวจสอบการปกปิด" จากนั้น หากมีข้อมูลจริง ให้สร้างเวอร์ชันที่เหมือนกับเทมเพลต "การสร้างข้อมูลการทดสอบสังเคราะห์" แต่สร้างขึ้นใหม่ทั้งหมด และทำให้ปัญหาของคุณเกิดขึ้นซ้ำได้ สุดท้าย ค้นหาและอ่านรายการเครื่องมือที่สถาบันของคุณอนุมัติและนโยบายการจำแนกประเภทข้อมูล มิฉะนั้น ให้สังเกตการละเว้นนี้

รายการตรวจสอบ

  • [ ] ฉันจัดประเภทข้อมูลก่อนที่จะป้อน (เปิด/ภายใน/เป็นความลับ/อยู่ภายใต้กฎระเบียบ)
  • [ ] ฉันไม่เคยใส่ความลับ PII และทรัพย์สินทางธุรกิจที่เป็นความลับลงในเครื่องมือที่ไม่ได้รับการอนุมัติ
  • [ ] ฉันใช้ข้อมูลมาสก์หรือข้อมูลสังเคราะห์ทุกครั้งที่เป็นไปได้แทนที่จะเป็นข้อมูลจริง
  • [ ] ฉันลดบริบทให้เหลือเพียงตัวอย่างเล็กๆ น้อยๆ ที่ไม่มีส่วนที่ละเอียดอ่อน
  • [ ] ฉันสแกนเอาต์พุต AI เพื่อค้นหาความลับที่ฝังแน่น
  • [ ] ฉันรู้ว่าหากความลับรั่วไหล ฉันจะส่งคืนข้อมูลประจำตัวทันทีและรายงานเหตุการณ์