Lợi nhuận:
- Khả năng phân loại dữ liệu chứa bí mật, dữ liệu cá nhân và tài sản kinh doanh bí mật và nhận biết các ranh giới màu đỏ
- Che giấu, ẩn danh và bảo mật bằng dữ liệu tổng hợp trước khi nhập dữ liệu
- Lựa chọn công cụ đã được phê duyệt, giảm thiểu ngữ cảnh và khả năng áp dụng phản xạ xoay phím trong trường hợp rò rỉ
Bất cứ điều gì bạn dán vào trợ lý mã hóa đều có khả năng nằm ngoài tầm kiểm soát của bạn. Khóa API, kết xuất cơ sở dữ liệu khách hàng, mã nguồn độc quyền chưa được công bố hoặc hồ sơ bệnh nhân — những thứ này có thể trở thành rò rỉ không thể khắc phục được khi chúng xâm nhập vào một công cụ không được phê duyệt. Rủi ro lớn nhất của AI đối với các nhóm phần mềm không đến từ lỗi dòng mà đến từ việc sao chép-dán bất cẩn. Bài học này nhằm mục đích đảm bảo việc sao chép-dán đó được an toàn.
Ở đây, chúng tôi phân biệt ba điều: dữ liệu nào không bao giờ được nhập, công cụ nào có thể được sử dụng với những biện pháp bảo vệ nào và cách bảo mật dữ liệu trước khi nhập (che giấu, dữ liệu tổng hợp, hoạt động cục bộ). Đây không phải là một tùy chọn "nó sẽ tốt đẹp"; Đó là một nghĩa vụ theo hợp đồng và pháp lý ở hầu hết các tổ chức.
Tại sao nó rất quan trọng?
Dữ liệu bạn gửi tới công cụ AI; được xử lý trên máy chủ của nhà cung cấp, đôi khi được lưu trữ trong một khoảng thời gian, có thể được sử dụng để cải thiện mô hình trong một số cài đặt sản phẩm. Nói "Tôi đã xóa cuộc trò chuyện" thường là không đủ; Thời điểm dữ liệu rời khỏi mạng, rủi ro sẽ phát sinh. Hơn nữa, chi phí rò rỉ rất cao: khóa đám mây bị rò rỉ có thể bị lạm dụng trong vòng vài phút, dữ liệu khách hàng bị rò rỉ có thể dẫn đến thông báo và hình phạt theo các quy định như KVKK/GDPR và mã nguồn riêng bị rò rỉ có thể phá hủy lợi thế cạnh tranh.
Vì vậy, nguyên tắc chung rất đơn giản: Không nhập bất cứ thứ gì vào một chiếc xe không được phê duyệt mà bạn không đủ khả năng để mất. Nếu nghi ngờ, đừng vào.
Thận trọng: Tâm lý “chỉ một lần, nhanh chóng” là nguyên nhân phổ biến nhất dẫn đến rò rỉ. Dán nhật ký sản xuất hoặc tệp cấu hình như khi giải quyết một lỗi khẩn cấp chính xác là điều xảy ra với những quyết định được đưa ra dưới áp lực. Sự khẩn cấp không đình chỉ quy tắc bảo mật.
Những gì không bao giờ nên nhập (đường màu đỏ)
- Bí mật: Khóa API, mật khẩu, khóa truy cập đám mây, chứng chỉ riêng, mã thông báo, chuỗi kết nối.
- Dữ liệu cá nhân (PII): Tên-họ, số ID TR, e-mail, điện thoại, địa chỉ, hồ sơ sức khỏe/tài chính, dữ liệu khách hàng.
- Tài sản kinh doanh bí mật: Mã nguồn không được tiết lộ, thuật toán độc quyền, bí mật kiến trúc nội bộ, chi tiết hợp đồng.
- Dữ liệu được quản lý: Các danh mục được bảo vệ đặc biệt như chăm sóc sức khỏe, thẻ thanh toán (PCI), tài chính cá nhân.
Từng bước: Quy trình sử dụng an toàn
- Phân loại dữ liệu. Những gì bạn có là gì - công khai, nội bộ, bí mật, được quản lý?
- Chọn xe theo hạng. Dữ liệu bí mật/được quản lý chỉ được xử lý trong các công cụ được tổ chức phê duyệt nhằm đảm bảo dữ liệu (không sử dụng trong giáo dục, giới hạn lưu giữ, xử lý theo khu vực).
- Đảm bảo an toàn trước khi vào. Loại bỏ bí mật, che giấu/ẩn danh PII, sử dụng dữ liệu tổng hợp (bịa đặt nhưng thực tế) thay vì dữ liệu thực nếu có thể.
- Giảm thiểu bối cảnh. Giảm vấn đề của bạn thành ví dụ có thể tái tạo nhỏ nhất không bao gồm các phần nhạy cảm.
- Đồng thời kiểm tra đầu ra. Kiểm tra để đảm bảo không có bí mật được mã hóa cứng hoặc dữ liệu còn sót lại của bạn trong mã do AI tạo ra.
Ba hộp nhỏ
Trường hợp 1 - Khóa dán đã bị hủy. Một nhà phát triển đã dán toàn bộ file cấu hình vào AI đồng thời sửa lỗi; Tệp chứa khóa API trực tiếp của bên thứ ba. Khi nhóm nhận thấy, họ lập tức hủy (xoay) chìa khóa và tạo ra một chiếc chìa khóa mới; Không có sự lạm dụng nào cả nhưng đó là một sự việc 'rẻ tiền'. Bài học: loại bỏ lớp men trước khi dán – và vặn chìa khóa ngay lập tức nếu nó bị rỉ.
Trường hợp 2 - Dữ liệu tổng hợp đã cứu doanh nghiệp. Một nhóm đã gặp phải lỗi phân tích cú pháp với hồ sơ khách hàng thực tế. Thay vì nhập dữ liệu thật, họ tạo ra 20 dòng dữ liệu tổng hợp có cấu trúc giống nhau nhưng hoàn toàn giả mạo, tái tạo lỗi với nó và giải quyết bằng AI. PII không bị rò rỉ cũng như quá trình chẩn đoán không bị chậm lại; dữ liệu tổng hợp vừa an toàn vừa đầy đủ.
Trường hợp 3 - Bí mật ẩn trong bản in. Khi tạo cấu hình mẫu, AI đã nhúng một khóa "mẫu" trông giống như thật vào đó và đưa vào mã mà nhà phát triển không hề hay biết; Quá trình quét cơ sở mã (máy quét bí mật) đã phát hiện ra điều này và cảnh báo. Bí mật bất biến lẽ ra không bao giờ được đưa vào mật mã; Cách chính xác là sử dụng biến môi trường hoặc trình quản lý bí mật. Bài học: quét đầu ra để tìm bí mật.
Bốn mẫu có thể sao chép
Danh sách kiểm tra mặt nạ trước khi vào (tự):
Trước khi đưa văn bản này cho AI, hãy đảm bảo tôi xóa những nội dung sau và thay thế những gì bạn tìm thấy bằng [MASKED]: Khóa API, mật khẩu, mã thông báo, chuỗi kết nối, họ-tên, email, điện thoại, số ID, dữ liệu khách hàng. Văn bản:{{văn bản}}
Tạo dữ liệu thử nghiệm tổng hợp:
Tạo dữ liệu kiểm tra hàng HOÀN TOÀN bịa đặt (không liên quan đến cá nhân/tổ chức) {{N}}theo sơ đồ bên dưới. Làm cho nó trông thực tế nhưng không sử dụng bất kỳ PII thực nào. Lược đồ: {{trường và loại}}Bao gồm các trường hợp cạnh (trống, ranh giới, định dạng sai).
Đã sửa lỗi tìm kiếm bí mật (bằng mã):
Tìm bí mật được mã hóa cứng trong mã/cấu hình này: khóa, mật khẩu, mã thông báo, URL tùy chỉnh. Nếu bạn tìm thấy nó, hãy chỉ định vị trí của nó và đề xuất phương pháp đúng (biến môi trường/trình quản lý bí mật). Mã:{{mã}}
Đánh giá sự phù hợp của phương tiện (theo loại dữ liệu):
Tôi có loại dữ liệu sau: {{class: public / nội bộ / bí mật / được quản lý}}. Công cụ tôi định sử dụng là: {{tool}}. Tôi nên xác nhận những biện pháp bảo vệ nào (lưu trữ, không sử dụng trong giáo dục, khu vực, quyền truy cập) trước khi xử lý dữ liệu này trong công cụ này? Đưa ra một danh sách kiểm tra. Quyết định là của tôi; Bạn làm rõ các tiêu chí.
Dấu nhắc yếu / Dấu nhắc mạnh
Yếu: (Dán 200 hàng người dùng thực được lấy từ cơ sở dữ liệu sản xuất) "Tại sao có lỗi phân tích cú pháp trong dữ liệu này?"
Strong: "Dưới đây là 15 hàng có cấu trúc giống như dữ liệu thực nhưng hoàn toàn tổng hợp (không có PII). Parse_user() ném ValueError vào 3, 8 và 12 hàng trong số này. Mẫu chung có thể là gì, tôi làm cách nào để khắc phục nó?"
Phiên bản mạnh không chứa dữ liệu cá nhân thực sự trong khi vẫn giữ nguyên cấu trúc cần thiết để tái tạo lỗi. Chẩn đoán vẫn giữ nguyên, rủi ro được đặt lại.
Lớp dữ liệu
Nó có thể được xử lý trong AI không?
Điều kiện tiên quyết
công cộng
Có
—
Sử dụng nội bộ (không chính xác)
Nói chung
Tuân thủ chính sách của công ty
Bảo mật (mã nguồn, bí mật kinh doanh)
Chỉ xe được phê duyệt
Đảm bảo doanh nghiệp + giảm thiểu
PII / quy định
Theo nguyên tắc không
Mặt nạ/ẩn danh hoặc sử dụng tổng hợp
Tuân thủ chính sách và theo dõi
Sử dụng an toàn không chỉ là thói quen cá nhân mà còn là hệ thống của công ty: công cụ nào được phê duyệt, lớp dữ liệu nào có thể đi đâu và phải làm gì trong trường hợp vi phạm phải được xác định trong chính sách bằng văn bản. Nếu một bí mật bị rò rỉ, bước đầu tiên quan trọng nhất không phải là hoảng sợ mà là ngay lập tức hoàn nguyên (hủy và tạo một thông tin mới) thông tin xác thực bị rò rỉ và báo cáo sự việc. Nếu bạn không biết danh sách các công cụ được phê duyệt và quy tắc phân loại dữ liệu của tổ chức mình thì nhiệm vụ đầu tiên của bạn là tìm hiểu chúng.
Mẹo: Xác định danh sách "bỏ qua" dành riêng cho dự án (ví dụ: .env, thư mục ẩn, tệp nhận dạng) trong công cụ Editor/CLI của bạn để những tệp này không vô tình được đưa vào ngữ cảnh của trợ lý. Phòng bệnh luôn rẻ hơn việc dọn dẹp.
Những lỗi thường gặp
- Dán dữ liệu nhạy cảm "chỉ một lần". Sự khẩn cấp không làm dừng lại lằn ranh đỏ; Sự rò rỉ phổ biến nhất xảy ra ở đây.
- Suy nghĩ "Tôi sẽ xóa cuộc trò chuyện". Thời điểm dữ liệu rời khỏi mạng, rủi ro sẽ phát sinh; Việc xóa không hoàn tác nó.
- Chọn xe mà không cần nhìn vào đẳng cấp của nó. Xử lý dữ liệu bí mật của công ty bằng tài khoản cá nhân là vi phạm nghiêm trọng.
- Không quét đầu ra. AI có thể nhúng một bí mật bất biến vào mã; Đồng thời kiểm tra quá trình sản xuất bằng máy quét bí mật.
- Không xoay nó khi bí mật bị rò rỉ. Việc không thu hồi khóa bị rò rỉ sẽ biến việc rò rỉ thành một hành vi khai thác trực tiếp.
Tóm lại
Rủi ro lớn nhất của AI trong phần mềm là rò rỉ quyền riêng tư và phần lớn rủi ro này phát sinh từ quyết định sao chép-dán được thực hiện dưới sự ép buộc. Quy tắc rất rõ ràng: bí mật, dữ liệu cá nhân, tài sản kinh doanh bí mật và dữ liệu được quản lý không được nhập vào các công cụ chưa được phê duyệt. Phân loại dữ liệu trước khi nhập, chọn tác nhân theo lớp, trích xuất bí mật, che giấu PII hoặc sử dụng dữ liệu tổng hợp, giảm thiểu ngữ cảnh và quét đầu ra để tìm bí mật. Nếu có rò rỉ, điều đầu tiên: trả lại thông tin xác thực và báo cáo.
Nhiệm vụ ứng dụng
Lấy một đoạn mã/nhật ký/dữ liệu mà bạn đã cung cấp gần đây (hoặc đang cân nhắc cung cấp) cho AI. Đầu tiên, xác định các ứng cử viên bí mật và PII bên trong bằng mẫu “danh sách kiểm tra mặt nạ”. Sau đó, nếu nó chứa dữ liệu thực, hãy tạo một phiên bản giống hệt với mẫu "tạo dữ liệu thử nghiệm tổng hợp" nhưng hoàn toàn được tạo thành và làm cho vấn đề của bạn có thể tái tạo được với nó. Cuối cùng, tìm và đọc danh sách công cụ đã được phê duyệt và chính sách phân loại dữ liệu của tổ chức bạn; Nếu không, hãy lưu ý thiếu sót này.
danh sách kiểm tra
- [ ] Tôi phân loại dữ liệu trước khi nhập vào (mở/nội bộ/bí mật/tuân theo quy định).
- [ ] Tôi không bao giờ nhập bí mật, PII và tài sản kinh doanh bí mật vào các công cụ không được phê duyệt.
- [ ] Tôi sử dụng dữ liệu che giấu hoặc tổng hợp bất cứ khi nào có thể thay vì dữ liệu thực.
- [ ] Tôi rút gọn bối cảnh thành ví dụ nhỏ nhất không bao gồm các phần nhạy cảm.
- [ ] Tôi quét đầu ra AI để tìm bí mật bị chôn vùi.
- [ ] Tôi biết nếu bí mật bị lộ, tôi sẽ ngay lập tức trả lại thông tin nhận dạng và báo cáo sự việc.