Ẩn dữ liệu trước khi gửi AI: băm mặc định có thể làm đứt khóa nối

Trước khi gửi văn bản tới AI, hãy phát hiện thông tin nhận dạng trong toàn bộ yêu cầu, rồi biến đổi từng trường theo việc có cần nối các bản ghi hoặc lấy lại giá trị gốc. Xóa trường không cần thiết, thay trường chỉ cần ngữ cảnh bằng nhãn, và dùng mã ổn định cho trường cần đối chiếu giữa các lần xử lý.

Theo tài liệu Presidio Anonymizer, từ phiên bản 2.2.361, toán tử hash dùng muối ngẫu nhiên mặc định cho từng thực thể. Cùng một giá trị vì thế có thể nhận các mã băm khác nhau và làm phép nối theo mã thất bại. Nếu cần giữ khóa nối, phải cấp muối nhất quán một cách tường minh.

Phát hiện dữ liệu trong yêu cầu sắp gửi

Đặt bước kiểm tra ngay trước lệnh gọi API, sau khi ứng dụng đã ghép lời nhắn, trích đoạn truy xuất, trường dữ liệu nội bộ và nội dung lấy từ tệp. Liệt kê các trường có thể nhận dạng người hoặc hồ sơ, như tên, email, số điện thoại, địa chỉ và mã khách hàng. Kiểm tra riêng các trường phụ và tên tệp, vì chúng cũng có thể đi vào yêu cầu dù không nằm trong phần văn bản chính.

Presidio Analyzer dùng bộ nhận diện dựng sẵn hoặc tùy chỉnh, kết hợp biểu thức chính quy, nhận diện thực thể và ngữ cảnh để phát hiện thông tin nhận dạng trong văn bản. Kết quả là các đoạn và loại thực thể cho bước biến đổi, không phải bảo đảm mọi giá trị đều đã được tìm thấy. Với văn bản tiếng Việt và mã riêng của doanh nghiệp, hãy thử trên dữ liệu giả có định dạng tương tự, bổ sung bộ nhận diện cần thiết và xem cả giá trị bị bỏ sót lẫn đoạn bị nhận nhầm.

Chọn phép biến đổi bằng ba câu hỏi

Có cần khôi phục giá trị gốc không? Nếu không, xóa trường mà mô hình không sử dụng. Thay tên bằng nhãn vai trò như [KHÁCH_HÀNG] khi mô hình cần hiểu ai đang nói nhưng không cần biết danh tính. Chỉ che một phần khi phần còn lại thực sự phục vụ tác vụ; các ký tự còn hiện vẫn có thể giúp nhận dạng người.

Cùng một người có cần giữ cùng mã giữa các bản ghi không? Một bản tóm tắt độc lập có thể chỉ cần nhãn chung, nhưng việc gom nhiều lượt liên hệ về cùng hồ sơ đòi hỏi mã ổn định. Hãy định nghĩa phạm vi nối: trong một yêu cầu, qua nhiều lần gọi API hay qua nhiều bộ dữ liệu. Mã chỉ nên ổn định trong phạm vi cần thiết, vì phạm vi rộng hơn cũng tạo thêm khả năng liên kết hoạt động của một người.

Muối hoặc khóa được quản lý ở đâu? Mã băm nhất quán cần tái sử dụng muối; token đảo ngược cần khóa giải mã. Giữ bí mật ở dịch vụ được cấp quyền, ngoài câu lệnh gửi mô hình và nhật ký có thể truy cập rộng. Cần xác định ai có quyền dùng bí mật và mã cũ sẽ được xử lý thế nào khi thay khóa hoặc ngừng dùng.

Vì sao muối ngẫu nhiên làm đứt khóa nối

Giả sử hai bản ghi mang cùng một mã khách hàng. Nếu mỗi lần băm dùng muối khác, kết quả có thể khác nhau và hệ thống ghép theo mã băm sẽ coi chúng là hai khóa. Cấp cùng muối giữ được tính toàn vẹn tham chiếu qua các bản ghi hoặc lần gọi, nhưng muối đó phải được lưu và bảo vệ ngoài yêu cầu AI; khả năng nối tăng cũng khiến các bản ghi dễ liên kết với nhau hơn.

Mã ổn định chỉ nối được đầu vào giống hệt nhau. Nếu một người dùng hai email hoặc mã hồ sơ đã thay đổi, phép băm không tự nhận ra quan hệ đó; ứng dụng phải chọn và chuẩn hóa định danh trước khi biến đổi. Với tập giá trị nhỏ, dễ đoán, không nên coi băm với muối cố định là lớp che chắn tuyệt đối: cần bảo vệ bí mật tạo mã và cân nhắc mã một chiều có khóa cho đối chiếu dài hạn.

Khi nào cần token có thể đảo ngược

Nếu một dịch vụ được cấp quyền phải gắn kết quả AI trở lại đúng hồ sơ gốc, có thể dùng token đảo ngược và chỉ giải mã trong dịch vụ ấy. Theo tài liệu giả danh hóa của Google Cloud, HMAC-SHA-256 tạo token một chiều có thể giữ khả năng nối khi dùng cùng khóa, còn AES-SIV tạo token có thể tái định danh bằng khóa gốc; khóa được bọc bằng Cloud KMS là một lựa chọn quản lý khóa. Khóa tạm thời chỉ giữ tính nhất quán trong một yêu cầu API nên không phù hợp cho việc nối giữa các yêu cầu hoặc tái định danh sau đó.

Với văn bản không có cấu trúc, việc tái định danh bằng mã hóa xác định còn cần nhãn nhận diện token để tìm đúng giá trị đã biến đổi. Khả năng khôi phục đồng nghĩa phải giới hạn quyền giải mã và giữ được khóa tương ứng; nếu mất khóa, đường khôi phục cũng mất. Nếu quy trình chỉ cần đối chiếu mà không bao giờ lấy lại giá trị gốc, token một chiều tránh phải duy trì đường giải mã.

Ví dụ chính sách cho luồng tóm tắt liên hệ

Giả sử ứng dụng dùng AI để tóm tắt các lần liên hệ rồi ghép bản tóm tắt về cùng khách hàng. Mô hình không cần tên, địa chỉ hay cách liên lạc thật. Các chuỗi trong ngoặc vuông dưới đây chỉ là ký hiệu cấu hình, không phải dữ liệu cá nhân hoặc khóa sử dụng được.

• Tên người → [KHÁCH_HÀNG], để giữ vai trò trong văn bản.
• Email, số điện thoại và địa chỉ → xóa nếu bản tóm tắt không cần chúng.
• Mã hồ sơ → mã ổn định tạo bằng bí mật lưu ngoài yêu cầu AI, để nối các bản tóm tắt mà không giải mã.
• Trường phải khôi phục → token đảo ngược; khóa và quyền giải mã nằm ở dịch vụ nội bộ được cấp quyền.

Trong cấu hình triển khai, [THAM_CHIẾU_BÍ_MẬT] chỉ nên trỏ tới nơi ứng dụng lấy bí mật, không chứa chính bí mật trong câu lệnh hoặc tệp mẫu. Trước khi gọi mô hình, kiểm tra yêu cầu cuối cùng để phát hiện giá trị gốc còn sót và thử bằng dữ liệu giả gồm hai bản ghi của cùng người cùng một bản ghi của người khác. Mã cần nối phải trùng trong phạm vi đã chọn, còn thông tin đã xóa không được xuất hiện lại ở phần văn bản chính, trường phụ hoặc nhật ký của bước biến đổi.

Đọc thêm:

• GitHub Actions sẽ xóa lịch sử theo mốc mặc định 90 ngày từ 1/10
• Substack, beehiiv hay Kit: khi nào phí 10% trở nên quá đắt?
• CV PDF hay DOCX: hãy để hệ thống tuyển dụng quyết định định dạng