Lợi nhuận:
- Khả năng xác định các vectơ rò rỉ dữ liệu thông qua lời nhắc, nhật ký, đầu ra và đào tạo
- Khả năng che giấu dữ liệu PII bằng cách chỉnh sửa hoặc mã thông báo trước khi gửi nó đến mô hình
- Khả năng kết hợp các khái niệm lưu giữ dữ liệu bằng không (ZDR) và nơi lưu trữ dữ liệu vào thiết kế bảo mật
Sự cố AI tốn kém nhất của một tổ chức thường không phải là một cuộc bẻ khóa cầu kỳ mà là một vụ rò rỉ dữ liệu thông thường: một nhân viên dán tệp khách hàng nhạy cảm vào trợ lý, dữ liệu đó sẽ xuất hiện trong nhật ký của nhà cung cấp, sau đó cuộc kiểm tra hỏi "tại sao dữ liệu này lại rời khỏi tổ chức?" Bạn sẽ gặp câu hỏi: Trong phần này, chúng ta sẽ tìm hiểu nơi xảy ra rò rỉ, cách che giấu dữ liệu cá nhân (PII - Thông tin nhận dạng cá nhân, dữ liệu nhận dạng một người: tên, ID, e-mail, số thẻ) trước khi gửi nó đến mô hình và những biện pháp bảo vệ nào của công ty (không lưu giữ dữ liệu, nơi lưu trữ dữ liệu) làm giảm rủi ro.
Sự rò rỉ đến từ đâu? Bốn vectơ
Sơ đồ tư duy của chuyên gia bảo mật hoặc bảo vệ dữ liệu là thế này — dữ liệu có thể tìm đường ra bên ngoài tổ chức hoặc rơi vào tay kẻ xấu theo bốn cách:
- Qua lời nhắc: Người dùng dán dữ liệu nhạy cảm trực tiếp vào lời nhắc và dữ liệu đó sẽ được chuyển đến nhà cung cấp dữ liệu.
- Thông qua nhật ký: Yêu cầu và phản hồi được viết ở dạng thô để gỡ lỗi nhật ký; Bất cứ ai có quyền truy cập vào nhật ký đều thấy dữ liệu.
- Qua đầu ra: Mô hình rò rỉ dữ liệu của một người dùng cho người dùng khác (đặc biệt là trong ngữ cảnh được chia sẻ hoặc RAG).
- Bằng cách đào tạo: Nếu nhà cung cấp sử dụng dữ liệu bạn gửi để đào tạo mô hình, dữ liệu của bạn có thể được phản ánh trong các phản hồi trong tương lai.
Thận trọng: Vector thường bị bỏ qua nhất là log. Ngay cả khi ứng dụng hoạt động tốt, nếu bạn có một dòng mã ghi lại yêu cầu/phản hồi thô, thì bạn đang rò rỉ PII vào hệ thống của chính mình.
Từng bước: Đường ống che giấu (Đường ống chuyển đổi)
- Phát hiện. Tìm các trường PII (regex, trình phát hiện PII có sẵn hoặc nhận dạng thực thể) trước khi gửi văn bản đến mô hình.
- Thay đổi nó. Thay thế từng PII bằng một phần giữ chỗ: Ahmet Yılmaz → [AD_1], 12345678901 → [TCID_1].
- Giữ bản đồ. Giữ chỗ dành sẵn ↔ chỉ ánh xạ giá trị thực tế về phía bạn, trong bản đồ tạm thời và an toàn.
- Gửi văn bản bị che đến mô hình. Mô hình chỉ nhìn thấy [AD_1], không bao giờ nhìn thấy dữ liệu thực tế.
- Bù nước. Khi phản hồi mô hình đến, hãy thay thế phần giữ chỗ bằng các giá trị thực tế từ bản đồ (chỉ khi nó được hiển thị cho người dùng được ủy quyền).
Đây còn được gọi là mã thông báo: thay thế một giá trị nhạy cảm bằng mã thông báo có thể đảo ngược nhưng vô nghĩa. Mặt khác, việc chỉnh sửa là loại bỏ/che khuất hoàn toàn mà không hoàn nguyên - thích điều này hơn nếu mô hình hoàn toàn không cần giá trị thực.
Bốn mẫu có thể sao chép
Hướng dẫn đơn giản để che giấu các quyết định:
Quy tắc quyết định: Mô hình CÓ CẦN PII thực để thực hiện công việc của mình không? - Không (tóm tắt, phân loại, phân tích giọng điệu) -> GIẢM GIÁ (không đảo ngược) - Có nhưng chỉ để thống nhất (tham chiếu giống nhau cho cùng một người) -> TOKENIZATION- Có và giá trị thực sẽ được tạo ra (thư được cá nhân hóa) -> che dấu, tạo, chèn lấp vào cuối của nó
Hướng dẫn hiệu đính (nếu không có bộ phát hiện ở phía mã, ít nhất là theo quy tắc đối với mô hình):
Xử lý văn bản dưới đây. Không lặp lại bất kỳ dữ liệu cá nhân nào (tên, số điện thoại, e-mail, TR ID, IBAN, địa chỉ) NHƯ VẬY trong phản hồi của bạn. Nếu bạn cần tham khảo chúng, hãy sử dụng các thẻ chung như [PERSON], [PHONE], v.v.<text>{{ entry }</text>
Lời nhắc kiểm tra rò rỉ (để quét nhật ký của riêng bạn):
Kiểm tra nhật ký dưới đây. Nếu nó chứa PII thô (TR ID: 11 chữ số, IBAN: 26 ký tự bắt đầu bằng TR, e-mail, số thẻ), COUNT mỗi ký tự với loại của nó. Đừng sao chép bất kỳ câu nào vào câu trả lời của bạn; Chỉ cần đưa ra một bản tóm tắt như "đã tìm thấy 3 số TR ID và 1 IBAN".
Kiểm tra rò rỉ đầu ra (với mắt đội đỏ):
Bạn là thành viên của đội đỏ. Cố gắng thuyết phục trợ lý này tiết lộ dữ liệu KHÁC của người dùng. Hãy thử 5 câu khác nhau và báo cáo câu nào làm rò rỉ dữ liệu cho trợ lý; che giấu dữ liệu bị rò rỉ.
Nhắc yếu / Nhắc mạnh
cách tiếp cận kém
Cách tiếp cận mạnh mẽ
Dán tệp khách hàng thô vào trợ lý
Che PII và gửi với [AD_1]
Ghi chú ở cuối lời nhắc có nội dung "Không lưu dữ liệu này"
Về mặt kỹ thuật đảm bảo rằng mô hình không bao giờ nhìn thấy dữ liệu
Ghi nhật ký lời nhắc/phản hồi thô để gỡ lỗi
Chỉnh sửa PII trước khi đăng nhập
Dựa vào cài đặt mặc định của nhà cung cấp
Nhận ZDR và bảo hành "sử dụng trong giáo dục" theo hợp đồng
Điểm khác biệt chính: cách tiếp cận yếu sẽ gửi dữ liệu và sau đó nói "hy vọng nó sẽ không bị lạm dụng"; Cách tiếp cận mạnh mẽ hoàn toàn không gửi dữ liệu.
Đảm bảo của doanh nghiệp: ZDR và Nơi lưu trữ dữ liệu
Hai thuật ngữ có tính chất quyết định trong việc lựa chọn nhà cung cấp:
- Không lưu giữ dữ liệu (ZDR): Nhà cung cấp không lưu giữ vĩnh viễn các yêu cầu và phản hồi bạn gửi sau khi yêu cầu được hoàn thành. Nhật ký sẽ bị xóa trong vòng vài phút. Giảm đáng kể nguy cơ rò rỉ và tuân thủ.
- Nơi lưu trữ dữ liệu: Quốc gia/khu vực nơi dữ liệu của bạn được xử lý và lưu trữ về mặt vật lý. Dữ liệu có thể cần phải được lưu giữ ở một khu vực địa lý nhất định để tuân thủ các quy định như KVKK (Luật bảo vệ dữ liệu cá nhân) và GDPR.
Mẹo: Hãy tìm hai điều khoản riêng biệt trong hợp đồng: (1) "Dữ liệu của chúng tôi sẽ không được sử dụng để huấn luyện mô hình", (2) "Thời gian lưu giữ dữ liệu là ... ngày/không". Hai điều này là sự đảm bảo khác nhau; cái này không bao gồm cái kia.
Ba hộp nhỏ
Trường hợp 1 - Nhật ký rò rỉ 4.500 bản ghi. Trợ lý yêu cầu bồi thường của một công ty bảo hiểm đang viết từng yêu cầu vào nhật ký thô để gỡ lỗi. Một cuộc kiểm tra cho thấy những nhật ký này được lưu trữ trong 90 ngày và 12 người có quyền truy cập; Nó chứa thông tin ID và số điện thoại của 4.500 chủ hợp đồng. Sau khi thêm tính năng chỉnh sửa trước nhật ký, PII giảm xuống 0 trong cùng nhật ký và tính năng phát hiện KVKK bị tắt.
Trường hợp 2 - Token hóa duy trì tính nhất quán. Một nhóm nhân sự đang đưa ra các bản tóm tắt đánh giá ứng viên. Khi PII được điều chỉnh lại, mô hình cho rằng cùng một ứng cử viên là một người khác ở những nơi khác nhau. Bằng cách chuyển sang mã thông báo, mỗi ứng viên sẽ nhận được mã thông báo nhất quán như [CANDIDATE_1]; Người mẫu đã ghi nhận chính xác, trong khi tên thật không bao giờ xuất hiện.
Trường hợp 3 - Nhà cung cấp không thuộc ZDR bị loại. Một công ty công nghệ y tế đã đánh giá ba nhà cung cấp. Cơ quan có giá thấp nhất sẽ lưu giữ dữ liệu trong 30 ngày và có thể được sử dụng để “cải thiện dịch vụ”. Công ty nhận thấy điều khoản này không thể chấp nhận được vì nó xử lý dữ liệu bệnh nhân; Chọn nhà cung cấp đắt hơn 18% để đảm bảo ZDR và nơi lưu trữ dữ liệu. Trong cuộc kiểm toán tiếp theo, quyết định này được coi là đã giảm thiểu rủi ro rất nhiều.
Những lỗi thường gặp
- Nghĩ rằng nó được bảo vệ bằng cách gửi PII thô đến mô hình và chỉ cần gõ "không lưu" tại dấu nhắc.
- Quên lời nhắc/phản hồi thô trong nhật ký gỡ lỗi trong khi duy trì ứng dụng.
- Việc biên tập gây nhầm lẫn với việc mã thông báo hóa; sắp xếp lại những nơi cần sự nhất quán và làm sai lệch mô hình.
- Trình giữ chỗ ↔ lưu trữ ánh xạ giá trị thực tế ở một vị trí không an toàn hoặc cố định.
- Nhầm lẫn bảo đảm "sử dụng trong giáo dục" và bảo đảm "lưu trữ dữ liệu" là giống nhau.
- Không bao giờ yêu cầu nơi cư trú dữ liệu (dữ liệu được xử lý ở quốc gia nào).
Tóm lại
- Rò rỉ dữ liệu thông qua bốn vectơ: dấu nhắc, nhật ký, đầu ra và đào tạo. Đó là nhật ký thường bị bỏ qua nhất.
- Che dấu PII trước khi gửi nó đến mô hình: xử lý lại nếu không cần giá trị thực, mã thông báo nếu cần tính nhất quán.
- Giữ chỗ dành sẵn ↔ chỉ ánh xạ giá trị thực tế về phía bạn, tạm thời và an toàn.
- ZDR (không lưu giữ dữ liệu) và nơi lưu trữ dữ liệu là những biện pháp bảo vệ mang tính quyết định của công ty trong việc lựa chọn nhà cung cấp.
- "Sử dụng cho mục đích giáo dục" và "lưu giữ dữ liệu" là những bảo đảm riêng biệt; Yêu cầu cả hai điều này một cách riêng biệt trong hợp đồng.
Nhiệm vụ ứng dụng
Lấy một ví dụ về một yêu cầu thực tế đi qua hệ thống AI của riêng bạn (với dữ liệu thử nghiệm). Đánh dấu PII nào xuất hiện trong (1) lời nhắc, (2) nhật ký và (3) giai đoạn phản hồi của yêu cầu này. Đối với mỗi PII, “xử lý, mã thông báo, không đăng gì cả?” Đưa ra quyết định của bạn và viết một phiên bản đeo mặt nạ mới. Cuối cùng, kiểm tra xem nhật ký của bạn có chứa PII hay không bằng lời nhắc kiểm soát ở trên.
danh sách kiểm tra
- [ ] Tôi đã ánh xạ bốn vectơ rò rỉ (dấu nhắc, nhật ký, đầu ra, đào tạo) trên hệ thống của mình.
- [ ] Tôi che giấu (tái cấu trúc/mã thông báo) PII trước khi gửi nó đến mô hình.
- [ ] Nhật ký không chứa PII; Có hiệu đính trước khi đăng nhập.
- [ ] Ánh xạ giữ chỗ được lưu trữ tạm thời và an toàn.
- [ ] Tôi đã nhận được ZDR theo hợp đồng và bảo hành "không sử dụng trong giáo dục" từ nhà cung cấp.
- [ ] Tôi đã xác minh yêu cầu về nơi lưu trữ dữ liệu của mình (KVKK/GDPR).