Tự động che dữ liệu cá nhân trước khi gửi vào AI: cách làm và giới hạn

Khách nhắn cho chatbot: “Tôi tên Trần Thị Hồng, số CCCD của tôi là…, đơn giao về số 12 ngõ 45 phố Hoàng Văn Thái, gọi cho tôi số 09…”. Chỉ một tin nhắn đã có đủ họ tên, giấy tờ tùy thân, địa chỉ và số điện thoại. Nếu tin nhắn đó đi thẳng tới nhà cung cấp mô hình, được ghi nguyên văn vào nhật ký và được trích vào bộ đánh giá chất lượng, dữ liệu cá nhân của khách đã nằm ở ba bốn nơi mà phần lớn không cần nó. Với doanh nghiệp xử lý hàng nghìn tin nhắn mỗi ngày, đó là một kho dữ liệu cá nhân hình thành ngoài ý muốn.

PII redaction, tức tự động nhận diện và che thông tin định danh cá nhân, là lớp đặt ở chiều vào để giảm lượng dữ liệu cá nhân đi tới mô hình và vào nơi lưu trữ. Bài này đi qua cách nhận diện, những dạng dữ liệu đặc thù ở Việt Nam, chọn giữa thay bằng mã giữ chỗ hay xóa hẳn, nơi giữ bảng ánh xạ, che trong nhật ký và cách đo sai sót. Khung kiểm soát dữ liệu hằng ngày rộng hơn có ở bài kiểm soát dữ liệu AI Agent; chiều ra, tức chặn dữ liệu nhạy cảm bị agent gửi đi, có ở bài DLP cho AI Agent.

1. Che ở chiều vào là giảm thiểu, không phải bảo đảm tuyệt đối

Ý tưởng của PII redaction rất trực quan: những gì mô hình không thấy thì mô hình không thể làm lộ, và những gì không được ghi thì không thể bị đọc trộm. Nhưng ranh giới giữa dữ liệu cá nhân và dữ liệu thường trong hội thoại tự nhiên rất mờ. “Chị Hồng ở tầng ba phòng kế toán” không chứa con số nào nhưng đủ để định danh một người trong công ty. “Con tôi bị dị ứng hải sản” là thông tin sức khỏe dù không có tên. Không có bộ nhận diện nào bắt được hết.

Vì vậy nên coi redaction là biện pháp giảm thiểu: giảm mạnh lượng dữ liệu cá nhân rõ ràng đi ra khỏi hạ tầng của doanh nghiệp, kết hợp với các biện pháp khác như hợp đồng xử lý dữ liệu với nhà cung cấp mô hình, chính sách lưu trữ ngắn và phân quyền xem nhật ký. Thiết kế tốt là thiết kế biết rõ mình bỏ lọt loại gì, ở mức nào, và đã có lớp nào khác đỡ phía sau.

Cũng cần nhớ redaction có giá: mỗi lần che là một lần mô hình mất một phần ngữ cảnh. Che quá tay khiến agent không phân biệt được hai khách, không hiểu địa chỉ giao nằm ở tỉnh nào để báo phí vận chuyển, hoặc hỏi lại khách những gì khách vừa nói. Bài toán thiết kế là che đủ để bảo vệ mà vẫn giữ đủ để làm việc.

2. Các yếu tố cần thiết kế

1. Danh mục loại dữ liệu cần che theo từng luồng

Bắt đầu bằng danh mục: luồng này có thể gặp những loại dữ liệu cá nhân nào, loại nào mô hình thật sự cần để làm việc, loại nào không. Chatbot tư vấn sản phẩm gần như không cần số giấy tờ tùy thân hay số tài khoản ngân hàng, nên che hết. Agent hỗ trợ giao hàng cần biết khách ở quận, huyện nào để báo thời gian giao, nhưng không cần số nhà. Agent tiếp nhận yêu cầu bảo hiểm có thể cần mô tả triệu chứng, nhưng không cần số thẻ bảo hiểm y tế ở dạng đầy đủ.

Danh mục này nên chia ba mức: che hẳn, thay bằng mã giữ chỗ, và giữ nguyên vì cần cho nghiệp vụ. Mức giữ nguyên phải có lý do ghi rõ và được người phụ trách bảo vệ dữ liệu đồng ý, nếu không theo thời gian mọi thứ sẽ trôi về mức giữ nguyên cho tiện.

2. Nhận diện bằng mẫu cố định

Mẫu cố định, thường viết bằng biểu thức chính quy kèm kiểm tra bổ sung, phù hợp với dữ liệu có định dạng rõ: email, số điện thoại, số CCCD, số tài khoản, số thẻ, mã số thuế, biển số xe. Ưu điểm là nhanh, rẻ, dễ giải thích và kết quả ổn định. Nhược điểm là dễ bắt nhầm, ví dụ một mã đơn hàng dài trùng độ dài với số CCCD, hoặc bỏ lọt khi khách viết cách quãng, viết bằng chữ, chèn dấu chấm giữa các nhóm số.

Để giảm bắt nhầm, mẫu nên xét cả ngữ cảnh xung quanh, như từ khóa “CCCD”, “căn cước”, “số tài khoản”, “STK” đứng gần. Với số thẻ thanh toán có thể thêm bước kiểm tra tổng kiểm, giúp loại bớt dãy số ngẫu nhiên trùng độ dài.

3. Nhận diện bằng mô hình thực thể

Tên người, địa chỉ viết tự do, tên tổ chức, thông tin sức khỏe trong câu kể là những thứ mẫu cố định không bắt được. Ở đây cần mô hình nhận diện thực thể có tên, thường gọi là NER: mô hình đọc câu và gắn nhãn đoạn nào là tên người, đoạn nào là địa điểm. Có thể dùng mô hình chuyên dụng chạy trong hạ tầng của doanh nghiệp, tránh việc gửi nguyên văn ra ngoài chỉ để biết cần che gì.

Mô hình thực thể không chắc chắn như mẫu cố định. Nó cho ra điểm tin cậy, và doanh nghiệp phải chọn ngưỡng: ngưỡng thấp che nhiều hơn nhưng che nhầm nhiều hơn, ngưỡng cao ít che nhầm nhưng bỏ lọt nhiều hơn. Ngưỡng nên chọn theo luồng, dựa trên dữ liệu thử thật chứ không theo cảm tính.

4. Dữ liệu đặc thù ở Việt Nam

Bộ nhận diện dựng cho tiếng Anh thường hỏng ở dữ liệu Việt. Số CCCD có mười hai chữ số, chứng minh nhân dân cũ có chín số, và khách hay gõ lẫn cả hai. Số điện thoại di động có thể bắt đầu bằng số 0, bằng mã quốc gia có dấu cộng hoặc không, viết liền, cách bằng dấu chấm hay khoảng trắng theo nhóm ba bốn số. Địa chỉ có cấu trúc số nhà, ngõ, ngách, hẻm, đường, phường xã, quận huyện, tỉnh thành, và sau các đợt sắp xếp đơn vị hành chính, khách có thể dùng cả tên cũ lẫn tên mới.

Tên người là phần khó nhất. Tên tiếng Việt có dấu hoặc không dấu, viết hoa hoặc thường, và rất nhiều tên trùng với từ thông dụng: “Hồng”, “Bình”, “An”, “Phúc”. Câu “tôi muốn an toàn khi giao hàng” không chứa tên ai, nhưng một bộ nhận diện kém có thể che chữ “an”. Bộ ca thử phải có nhiều câu kiểu này, viết không dấu, viết tắt, xưng hô “chị Hồng”, “anh Bình bên kho”, để thấy bộ nhận diện chịu được tới đâu.

5. Mã giữ chỗ khôi phục được hay xóa hẳn

Có hai cách thay. Xóa hẳn là thay dữ liệu bằng nhãn chung như “số điện thoại đã che”; mô hình biết có một số điện thoại nhưng không biết là số nào, và không ai khôi phục lại được. Mã giữ chỗ khôi phục được là thay bằng mã nhất quán trong phiên như SDT_1, TEN_1, DIACHI_1; mô hình vẫn phân biệt được hai số điện thoại khác nhau, và khi agent soạn câu trả lời “chúng tôi sẽ gọi lại cho anh theo SDT_1”, lớp xử lý thay lại giá trị thật trước khi gửi khách.

Xóa hẳn an toàn hơn và nên là mặc định cho dữ liệu mà luồng không bao giờ cần trả lại, như số CCCD trong chatbot tư vấn. Mã giữ chỗ dùng cho những gì agent cần nhắc lại hoặc truyền vào công cụ, ví dụ số điện thoại để tạo phiếu gọi lại. Khi mã giữ chỗ được truyền vào công cụ, lớp thực thi thay giá trị thật vào tham số ngay trước khi gọi hệ thống đích, mô hình vẫn không thấy giá trị đó.

6. Nơi giữ bảng ánh xạ

Bảng ánh xạ là nơi ghi SDT_1 tương ứng với số thật nào. Đây là thứ nhạy cảm nhất trong cả thiết kế, vì ai có bảng thì đảo ngược được mọi thứ đã che. Bảng nên nằm trong hạ tầng của doanh nghiệp, tách biệt với nhật ký hội thoại, gắn với từng phiên, chỉ lớp xử lý phản hồi và lớp thực thi công cụ được đọc, và tự xóa sau khi phiên kết thúc hoặc sau thời hạn ngắn nhất mà nghiệp vụ cần.

Sai lầm hay gặp là lưu bảng ánh xạ vào cùng bản ghi hội thoại “để tiện tra cứu sau”. Khi đó nhật ký chứa cả mã lẫn khóa giải mã, và việc che chỉ còn tác dụng với nhà cung cấp mô hình. Thời hạn lưu của bảng nên được đưa vào chính sách chung về lưu trữ, xem bài lưu trữ và xóa dữ liệu cho AI.

7. Che trong nhật ký và dữ liệu phân tích

Nhật ký hội thoại, nhật ký gọi công cụ, bản ghi lỗi, dữ liệu xuất cho bảng điều khiển và bộ dữ liệu đánh giá chất lượng đều cần được che, không chỉ phần gửi tới mô hình. Điểm hay bị quên là bản ghi lỗi: khi lớp xử lý gặp sự cố, nó có thể ghi nguyên văn tin nhắn gốc chưa che để phục vụ gỡ lỗi. Nhật ký cần có chính sách riêng về trường nào được ghi, trường nào phải che, chi tiết ở bài nhật ký AI Agent.

Bộ dữ liệu đánh giá là trường hợp đặc biệt: người chấm cần đọc hội thoại để chấm, nhưng không cần biết số điện thoại thật. Dùng bản đã che cho việc chấm là đủ, và nếu cần bản gốc để điều tra một khiếu nại cụ thể thì đi qua quy trình xin quyền riêng, có ghi lý do.

8. Bỏ lọt và che nhầm

Hai loại sai cần đo riêng. Bỏ lọt là dữ liệu cá nhân đi qua mà không bị che, hậu quả là lộ dữ liệu. Che nhầm là dữ liệu thường bị che, hậu quả là agent hiểu sai, ví dụ che mất mã đơn khiến agent không tra được đơn, hoặc che tên sản phẩm trùng với tên người. Hai loại sai kéo nhau theo hướng ngược lại: giảm cái này thường làm tăng cái kia.

Cách đo là duy trì một bộ hội thoại mẫu đã được người gắn nhãn đầy đủ, chạy bộ nhận diện trên đó sau mỗi lần thay đổi và so kết quả. Ngoài ra nên lấy mẫu ngẫu nhiên hội thoại thật đã che, cho người kiểm tra xem còn sót gì. Mỗi trường hợp bỏ lọt tìm được nên trở thành một ca thử mới trong bộ mẫu.

3. Quy trình triển khai thực tế

Bước 1: Lấy mẫu hội thoại thật và gắn nhãn

Lấy một tập hội thoại thật đại diện cho các luồng, đưa cho người được phép đọc dữ liệu gốc gắn nhãn mọi đoạn là dữ liệu cá nhân theo danh mục đã lập. Tập này nên có đủ kiểu viết: có dấu, không dấu, viết tắt, gõ sai, số viết bằng chữ, địa chỉ cũ và mới. Đây là nền để chọn công cụ và chọn ngưỡng, và về sau là bộ kiểm thử hồi quy.

Bước 2: Ghép lớp mẫu cố định với lớp mô hình và chọn chế độ theo luồng

Chạy mẫu cố định trước cho các loại có định dạng rõ, rồi chạy mô hình thực thể cho phần còn lại. Với mỗi luồng, chốt loại nào xóa hẳn, loại nào thay mã giữ chỗ, loại nào giữ nguyên. Chọn ngưỡng tin cậy của mô hình thực thể dựa trên kết quả trên tập mẫu, chấp nhận che nhầm nhiều hơn ở luồng nhạy cảm và ít hơn ở luồng mà che nhầm làm hỏng nghiệp vụ.

Bước 3: Đặt điểm che ở đúng chỗ trong luồng

Điểm che phải nằm trước mọi nơi dữ liệu có thể đi tới: trước lời gọi mô hình, trước khi ghi nhật ký, trước khi đẩy vào hàng đợi phân tích. Một lỗi thiết kế phổ biến là che ngay trước lời gọi mô hình nhưng ghi nhật ký từ bước trước đó. Vẽ sơ đồ luồng dữ liệu, đánh dấu mọi điểm ghi và gửi, rồi xác nhận điểm che đứng trước tất cả. Tệp đính kèm như ảnh chụp giấy tờ cần xử lý riêng, vì nhận diện chữ trong ảnh có độ chính xác thấp hơn văn bản gõ.

Bước 4: Đo trên bộ kiểm thử rồi theo dõi trong vận hành

Trước khi bật, chạy toàn bộ tập mẫu, đo tỷ lệ bỏ lọt và che nhầm theo từng loại dữ liệu, cho người phụ trách bảo vệ dữ liệu và chủ nghiệp vụ cùng xem. Sau khi bật, định kỳ lấy mẫu hội thoại đã che để kiểm tra bằng mắt, theo dõi các phàn nàn kiểu agent hỏi lại thông tin khách đã cung cấp, và thêm ca thử mỗi khi phát hiện kiểu dữ liệu mới.

4. Ví dụ giả định

Một công ty bán đồ gia dụng trực tuyến dùng agent chăm sóc khách hàng trên website và mạng xã hội, gọi mô hình của một nhà cung cấp bên ngoài. Khi rà nhật ký, đội vận hành thấy khách thường gửi ảnh hóa đơn, số điện thoại, địa chỉ đầy đủ và đôi khi cả số tài khoản ngân hàng để nhận tiền hoàn. Tất cả đi thẳng tới mô hình và nằm nguyên trong nhật ký.

Công ty dựng lớp che chạy trong hạ tầng của mình: số tài khoản và số giấy tờ bị xóa hẳn, agent được hướng dẫn nói với khách rằng thông tin hoàn tiền sẽ được nhân viên xác nhận qua kênh riêng. Số điện thoại và tên được thay bằng mã giữ chỗ để agent vẫn tạo được phiếu gọi lại. Địa chỉ được rút gọn còn quận, tỉnh để agent báo phí giao hàng, số nhà và tên đường bị che. Bảng ánh xạ nằm trong một kho riêng, tự xóa khi phiên đóng. Đợt kiểm tra đầu tiên phát hiện bộ nhận diện che nhầm tên một dòng nồi cơm vì trùng tên người, và ca đó được thêm vào bộ kiểm thử. Ví dụ này là giả định để minh họa cách làm.

5. Rủi ro và giới hạn

• Bỏ lọt dữ liệu cá nhân viết tự do, viết không dấu hoặc nằm trong ảnh, tệp đính kèm
• Che nhầm mã đơn, tên sản phẩm hay từ thông dụng, làm agent hiểu sai và hỏi lại khách
• Bảng ánh xạ lưu cạnh nhật ký hoặc giữ quá lâu, khiến việc che mất tác dụng
• Điểm che đặt sau một điểm ghi nhật ký hay hàng đợi, nên dữ liệu gốc vẫn bị lưu

Redaction không thay thế sự đồng ý của khách hay nghĩa vụ thông báo mục đích xử lý dữ liệu theo quy định hiện hành về bảo vệ dữ liệu cá nhân; phần đó có ở bài quản lý consent. Nó cũng không giúp gì nếu chính hệ thống nội bộ mà agent tra cứu trả về quá nhiều dữ liệu; lúc đó cần thu hẹp kết quả công cụ ngay từ nguồn.

6. Phân chia trách nhiệm vận hành

Người phụ trách bảo vệ dữ liệu cá nhân sở hữu danh mục loại dữ liệu, quyết định mức xử lý cho từng loại theo từng luồng, và duyệt ngưỡng chấp nhận bỏ lọt. Đội phát triển agent dựng lớp nhận diện, đặt điểm che, quản lý bảng ánh xạ và duy trì bộ kiểm thử. Chủ nghiệp vụ của từng luồng, như trưởng bộ phận chăm sóc khách hàng, xác nhận loại dữ liệu nào thực sự cần cho công việc và báo khi che nhầm làm hỏng trải nghiệm. Đội vận hành lấy mẫu kiểm tra định kỳ và xử lý báo cáo bỏ lọt như một sự cố bảo mật, có ghi nhận và khắc phục.

7. Chỉ số nên theo dõi

• Tỷ lệ bỏ lọt trên bộ kiểm thử theo từng loại dữ liệu, sau mỗi lần thay đổi
• Tỷ lệ che nhầm trên bộ kiểm thử và số hội thoại thật mà agent hỏi lại thông tin khách đã cung cấp
• Số trường hợp bỏ lọt phát hiện qua lấy mẫu kiểm tra trong vận hành
• Số bảng ánh xạ còn tồn tại quá thời hạn tự xóa

Chỉ số tổng hợp dễ đánh lừa. Bỏ lọt thấp ở số điện thoại không bù được bỏ lọt cao ở số giấy tờ tùy thân, vì mức nghiêm trọng khác nhau. Nên đọc chỉ số theo từng loại dữ liệu và đặt ngưỡng chấp nhận riêng cho loại nhạy cảm nhất.

8. Checklist trước khi vận hành

• Danh mục loại dữ liệu cá nhân và mức xử lý cho từng luồng đã được người phụ trách bảo vệ dữ liệu duyệt
• Bộ nhận diện đã chạy trên tập mẫu có đủ kiểu viết tiếng Việt, có kết quả bỏ lọt và che nhầm
• Điểm che đứng trước mọi điểm gọi mô hình, ghi nhật ký và đẩy dữ liệu phân tích
• Bảng ánh xạ tách khỏi nhật ký, có quyền đọc hẹp và thời hạn tự xóa
• Tệp đính kèm và ảnh có cách xử lý riêng đã được kiểm thử
• Quy trình xử lý khi phát hiện bỏ lọt đã viết rõ người nhận và bước khắc phục

9. Câu hỏi thường gặp

Che dữ liệu cá nhân rồi thì AI còn trả lời đúng cho khách được không? Được, nếu chọn đúng cách che. Với luồng cần cá nhân hóa, dữ liệu được thay bằng mã giữ chỗ như KHACH_1 hay SDT_1, mô hình làm việc trên mã đó và lớp xử lý thay lại giá trị thật trước khi gửi cho khách. Mô hình hiểu được cấu trúc câu chuyện mà không cần biết số điện thoại thật là gì.

Dùng biểu thức chính quy là đủ để che dữ liệu cá nhân không? Không đủ. Mẫu cố định bắt tốt số CCCD, số điện thoại, email hay số tài khoản có định dạng rõ, nhưng gần như bó tay với tên người, địa chỉ viết tự do hay thông tin sức khỏe nằm trong câu kể. Cách thực tế là kết hợp mẫu cố định với mô hình nhận diện thực thể, và chấp nhận vẫn còn tỷ lệ bỏ lọt cần theo dõi.

Bảng ánh xạ giữa mã giữ chỗ và dữ liệu thật nên lưu ở đâu? Ở trong hạ tầng của doanh nghiệp, tách khỏi nhật ký hội thoại và không bao giờ gửi cho nhà cung cấp mô hình. Bảng nên gắn với từng phiên, có thời hạn tự xóa ngắn nhất mà nghiệp vụ cho phép, và chỉ lớp xử lý phản hồi được đọc. Nếu bảng ánh xạ nằm cạnh nhật ký thì việc che gần như mất tác dụng.

PII redaction khác gì DLP? PII redaction làm ở chiều vào: che dữ liệu cá nhân trước khi nội dung đi tới mô hình hoặc được lưu. DLP làm ở chiều ra: kiểm tra những gì agent sắp gửi ra ngoài qua chat, email, webhook hay tệp đính kèm và chặn khi vi phạm chính sách. Hai lớp bổ sung cho nhau, không lớp nào thay được lớp kia.

Kết luận

Tự động che dữ liệu cá nhân trước khi gửi vào AI là cách hiệu quả để thu hẹp lượng dữ liệu nhạy cảm rời khỏi hạ tầng doanh nghiệp, với điều kiện thiết kế trung thực về giới hạn của nó. Kết hợp mẫu cố định với mô hình thực thể, dựng bộ ca thử sát cách người Việt viết, chọn xóa hẳn làm mặc định và chỉ dùng mã giữ chỗ khi agent thật sự cần, giữ bảng ánh xạ ở nơi riêng có thời hạn, che cả nhật ký, và đo bỏ lọt cùng che nhầm như hai chỉ số song song.

Trao đổi với Naventic để thiết kế lớp che dữ liệu cá nhân cho agent chăm sóc khách hàng. Đọc thêm: AI Customer Support.