Thiết kế chính sách lưu trữ và xóa dữ liệu cho AI Agent

Hầu hết doanh nghiệp khi triển khai AI Agent đều hỏi dữ liệu có an toàn không, nhưng ít ai hỏi dữ liệu sẽ nằm lại bao lâu. Một cuộc hội thoại với khách không chỉ được lưu ở một chỗ: nó đi vào log, có thể được tóm tắt vào CRM, được cắt thành đoạn để tìm kiếm, được lưu tạm trong cache và nằm trong bản sao lưu đêm đó. Khi khách yêu cầu xóa, xóa ở giao diện quản trị là chưa đủ.

Bài kiểm soát dữ liệu AI Agent đã nêu nguyên tắc chung rằng mỗi loại dữ liệu cần có thời hạn và phải tự xóa khi hết hạn. Bài này đi sâu vào phần làm: lập bảng thời hạn theo từng loại dữ liệu, lan truyền lệnh xóa tới mọi bản sao, xử lý legal hold và kiểm tra xem việc xóa có thật sự diễn ra. Nội dung không phải tư vấn pháp lý; thời hạn cụ thể cần pháp chế đối chiếu với quy định bảo vệ dữ liệu cá nhân hiện hành.

1. Vì sao AI Agent làm việc lưu trữ phức tạp hơn

Một phần mềm truyền thống thường lưu dữ liệu ở vài bảng có cấu trúc rõ. AI Agent tạo ra dữ liệu ở nhiều dạng mà đội vận hành không quen gọi tên. Văn bản khách gõ vào trở thành đầu vào cho mô hình, được ghi vào log kèm câu trả lời, được chuyển thành vector để tìm lại sau, có khi được dùng làm ví dụ đánh giá chất lượng. Tệp khách gửi lên được trích chữ và lập chỉ mục. Mỗi bước tạo thêm một bản sao ở một nơi khác, có khi ở hệ thống của nhà cung cấp.

Vì vậy chính sách lưu trữ cho AI Agent không bắt đầu bằng câu “lưu bao lâu” mà bằng câu “dữ liệu này đang nằm ở những đâu”. Vị trí địa lý của dữ liệu là một câu hỏi khác, được bàn ở bài data residency; ở đây ta quan tâm đến số bản sao và vòng đời của từng bản.

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

1. Loại dữ liệu

Bước đầu tiên là liệt kê đủ các loại dữ liệu mà agent tạo ra hoặc giữ lại. Danh sách thường gồm: nội dung hội thoại; log kỹ thuật (yêu cầu, công cụ đã gọi, lỗi); chỉ mục vector hay embedding của tài liệu và của hội thoại; tệp người dùng tải lên cùng văn bản trích ra từ đó; cache câu trả lời hoặc kết quả tra cứu; bản ghi đã đẩy sang CRM, hệ thống ticket; bộ dữ liệu đánh giá chất lượng; bản sao lưu; và dữ liệu nằm ở nhà cung cấp mô hình. Loại nào bị bỏ sót khỏi danh sách sẽ không bao giờ bị xóa.

2. Mục đích lưu

Mỗi loại dữ liệu phải gắn với một mục đích cụ thể, vì mục đích quyết định thời hạn. Log lỗi dùng để điều tra sự cố; hội thoại gắn với một yêu cầu dịch vụ dùng để nhân viên tiếp tục xử lý; hội thoại mẫu dùng để kiểm thử hồi quy; tệp tải lên dùng để hoàn thành hồ sơ. Khi không nêu được mục đích nào ngoài “để sau này có thể cần”, đó là dấu hiệu dữ liệu không nên được giữ.

3. Thời hạn

Thời hạn được suy ra từ mục đích và nghĩa vụ. Cách thực tế là lập một bảng như dưới đây và để chủ dữ liệu, an toàn thông tin cùng pháp chế điền cột thời hạn:

Nguyên tắc đáng giữ: một bản sao phái sinh (embedding, cache, tóm tắt) không được sống lâu hơn bản gốc mà nó được tạo ra.

4. Log

Log là nơi dữ liệu cá nhân hay rò rỉ nhất, vì lập trình viên thường ghi nguyên văn đầu vào và đầu ra để dễ gỡ lỗi. Nên tách log thành hai lớp: lớp kỹ thuật chỉ giữ mã yêu cầu, thời gian, công cụ đã gọi, mã lỗi, và lớp nội dung giữ văn bản đã được che bớt thông tin nhạy cảm, có thời hạn ngắn hơn và ít người được xem hơn. Thiết kế log chi tiết có ở bài nhật ký AI Agent; điều cần thêm ở đây là mỗi lớp log có thời hạn và lệnh xóa riêng.

5. Bản sao lưu

Bản sao lưu là chỗ lệnh xóa hay bị quên. Hầu hết hệ thống sao lưu không cho sửa từng bản ghi, nên cách hợp lý là: đặt vòng quay sao lưu có hạn, để bản cũ hết hạn nguyên bản; giữ một danh sách các yêu cầu xóa đã thực hiện; và khi phải khôi phục từ bản sao lưu cũ, chạy lại danh sách đó trước khi mở hệ thống cho người dùng. Chính sách cần ghi rõ cách làm này để trả lời được khi khách hỏi.

6. Yêu cầu xóa

Khi một khách yêu cầu xóa dữ liệu, lệnh xóa phải đi tới mọi nơi trong danh sách ở mục 1. Muốn làm được, mỗi bản ghi phái sinh phải mang theo mã nguồn gốc: vector nào được tạo từ hội thoại nào, tóm tắt CRM nào được viết từ phiên nào. Không có mã này thì không thể xóa đúng, chỉ có thể xóa theo từ khóa và hy vọng. Quy trình nên có một phiếu xóa liệt kê từng hệ thống, người thực hiện và thời điểm hoàn thành. Việc xác minh danh tính người yêu cầu và quyền rút lại sự đồng ý liên quan chặt tới phần quản lý consent.

7. Legal hold

Có những lúc dữ liệu đã đến hạn xóa nhưng không được xóa: đang có tranh chấp với khách, cơ quan chức năng yêu cầu cung cấp, hay đang điều tra nội bộ. Legal hold là lệnh tạm giữ đúng phạm vi dữ liệu liên quan. Quy trình xóa tự động phải đọc danh sách lệnh giữ trước khi chạy, bỏ qua dữ liệu bị giữ, ghi lại lý do, và tiếp tục xóa khi pháp chế gỡ lệnh. Nếu không có cơ chế này, đội kỹ thuật thường chọn cách an toàn cho mình là tắt hẳn việc xóa tự động, và dữ liệu nằm lại mãi.

8. Kiểm tra định kỳ

Chính sách chỉ có giá trị khi có bằng chứng nó đang chạy. Định kỳ, người phụ trách nên lấy mẫu vài mã phiên đã quá hạn và tìm chúng ở từng nơi: cơ sở dữ liệu hội thoại, kho log, chỉ mục vector, kho tệp, CRM. Kết quả tìm thấy bất kỳ thứ gì là một lỗi cần sửa. Tương tự, lấy mẫu các yêu cầu xóa đã đóng để xác nhận không còn dấu vết. Việc kiểm tra này nên do người không trực tiếp vận hành hệ thống thực hiện.

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

Bước 1: Vẽ đường đi của dữ liệu

Chọn một hội thoại mẫu và lần theo nó qua toàn bộ hệ thống: từ khung chat, qua máy chủ agent, tới mô hình, log, chỉ mục, CRM, kho tệp và bản sao lưu. Ghi lại từng nơi dữ liệu được sao chép, ai quản lý nơi đó và nơi đó có cho xóa theo bản ghi không. Bản đồ này là nền cho mọi bước sau.

Bước 2: Điền bảng thời hạn và chốt với pháp chế

Với mỗi loại dữ liệu, chủ nghiệp vụ nêu mục đích, an toàn thông tin đánh giá mức nhạy cảm, pháp chế xác nhận có nghĩa vụ lưu hay giới hạn lưu nào theo quy định hiện hành. Kết quả là bảng thời hạn có chữ ký, kèm ngoại lệ được phép.

Bước 3: Gắn mã nguồn gốc và dựng lệnh xóa

Đội kỹ thuật bổ sung mã phiên hoặc mã khách vào mọi bản ghi phái sinh, viết tác vụ xóa theo hạn cho từng kho, và viết lệnh xóa theo yêu cầu đi qua mọi kho trong một lần. Kiểm tra với nhà cung cấp mô hình xem họ giữ dữ liệu đầu vào bao lâu và tùy chọn nào tắt việc lưu, rồi ghi vào hồ sơ.

Bước 4: Thử xóa rồi đi tìm lại

Tạo dữ liệu thử có dấu hiệu dễ nhận, chạy lệnh xóa, rồi tìm dấu hiệu đó ở mọi kho, kể cả sau khi khôi phục thử một bản sao lưu. Ca thử cần có: xóa theo hạn, xóa theo yêu cầu, dữ liệu đang bị legal hold và khôi phục từ bản cũ. Mọi dấu vết còn sót được ghi thành lỗi và sửa trước khi chạy thật.

4. Ví dụ giả định

Một chuỗi phòng khám dùng AI Agent để trả lời câu hỏi về dịch vụ và nhận thông tin đặt lịch. Khách thỉnh thoảng gửi ảnh đơn thuốc hay kết quả xét nghiệm cũ để hỏi. Một khách sau đó yêu cầu xóa toàn bộ dữ liệu của mình.

Khi lần theo, đội vận hành thấy dữ liệu của khách nằm ở năm chỗ: kho hội thoại, log nội dung, chỉ mục vector dùng để agent nhớ ngữ cảnh lần trước, kho ảnh tải lên và ghi chú đặt lịch trong phần mềm quản lý phòng khám. Chỉ mục vector không có mã khách, nên không xóa chính xác được. Sau sự việc, phòng khám quyết định: ảnh tải lên chỉ giữ đến khi nhân viên đã xem và chuyển vào hồ sơ chính thức; vector phải mang mã phiên; log nội dung che số điện thoại và tên thuốc; ghi chú trong phần mềm quản lý do lễ tân xóa theo quy trình riêng vì có thể liên quan đến hồ sơ khám. Mọi thay đổi được thử lại bằng dữ liệu giả trước khi áp dụng.

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

• Bản sao phái sinh không có mã nguồn gốc nên không xóa đúng được
• Dữ liệu ở nhà cung cấp mô hình nằm ngoài tầm kiểm soát trực tiếp
• Xóa quá tay làm mất bằng chứng cần cho điều tra hoặc tranh chấp
• Tác vụ xóa tự động âm thầm dừng mà không ai phát hiện

Giới hạn lớn nhất là doanh nghiệp chỉ xóa được những gì mình kiểm soát. Với dữ liệu đã gửi cho nhà cung cấp mô hình, doanh nghiệp dựa vào cam kết hợp đồng và cấu hình dịch vụ, nên cần đọc kỹ điều khoản lưu dữ liệu và chọn chế độ không lưu nếu có. Chiều ngược lại cũng là rủi ro: xóa sớm hơn cần thiết có thể làm mất log cần cho một cuộc điều tra, vì vậy legal hold và thời hạn tối thiểu cho log sự cố phải được thiết kế cùng lúc với lệnh xóa. Cuối cùng, tác vụ xóa là loại việc chạy ngầm, hỏng không ai kêu; nó cần cảnh báo riêng khi không chạy hoặc chạy lỗi.

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

Chủ nghiệp vụ sở hữu mục đích lưu và đề xuất thời hạn cho dữ liệu của quy trình mình. Pháp chế xác nhận nghĩa vụ lưu, giới hạn lưu và quản lý lệnh legal hold. An toàn thông tin giữ bảng thời hạn, duyệt ngoại lệ và thực hiện kiểm tra định kỳ. Đội kỹ thuật chịu trách nhiệm mã nguồn gốc, tác vụ xóa, cảnh báo khi tác vụ lỗi và cấu hình phía nhà cung cấp. Bộ phận chăm sóc khách hàng tiếp nhận yêu cầu xóa, xác minh người yêu cầu và phản hồi khi hoàn tất.

Khi thêm một kênh mới, một kho mới hay đổi nhà cung cấp mô hình, bản đồ dữ liệu ở bước 1 phải được cập nhật trước khi đưa vào chạy. Đây là chỗ chính sách hay lỗi thời nhanh nhất: một tính năng mới lưu thêm một bản sao mà không ai thêm nó vào lệnh xóa.

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

• Tỷ lệ loại dữ liệu trong bản đồ đã có thời hạn và tác vụ xóa đang chạy
• Thời gian từ khi nhận yêu cầu xóa đến khi mọi hệ thống xác nhận xong
• Số dấu vết còn sót phát hiện qua lấy mẫu kiểm tra
• Số lần tác vụ xóa tự động lỗi hoặc không chạy, và thời gian phát hiện

Con số đáng lo nhất không phải là số yêu cầu xóa mà là số dấu vết còn sót sau khi đã báo khách “đã xóa xong”. Chỉ số này chỉ có được nếu việc lấy mẫu kiểm tra được làm đều, và nên được báo cáo cùng số loại dữ liệu chưa có tác vụ xóa.

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

• Bản đồ dữ liệu đã liệt kê mọi nơi lưu, kể cả nhà cung cấp mô hình
• Bảng thời hạn có mục đích và căn cứ cho từng loại, đã được pháp chế xác nhận
• Mọi bản ghi phái sinh mang mã phiên hoặc mã khách
• Lệnh xóa theo yêu cầu đi qua mọi kho và có phiếu xác nhận
• Danh sách legal hold được tác vụ xóa đọc trước khi chạy
• Có cảnh báo khi tác vụ xóa lỗi và lịch lấy mẫu kiểm tra

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

Xóa một đoạn hội thoại có đủ để xóa dữ liệu khỏi AI Agent không? Thường là không. Cùng một nội dung có thể đã nằm trong log, trong chỉ mục tìm kiếm dạng embedding, trong cache, trong CRM, trong bản sao lưu và ở phía nhà cung cấp mô hình. Chính sách phải liệt kê mọi nơi đó và mỗi nơi có cách xóa, người xác nhận riêng.

Thời hạn lưu dữ liệu của AI Agent nên đặt bao lâu? Không có một con số dùng chung. Thời hạn nên suy ra từ mục đích: log để điều tra sự cố cần đủ dài để phát hiện lỗi, hội thoại để cải thiện chất lượng chỉ cần đến khi đã rút xong bài học, còn dữ liệu có nghĩa vụ lưu theo luật thì theo quy định hiện hành mà pháp chế xác nhận.

Bản sao lưu có phải xóa ngay khi khách yêu cầu xóa dữ liệu không? Nhiều hệ thống không cho sửa từng bản ghi trong bản sao lưu. Cách thường dùng là để bản sao lưu tự hết hạn theo vòng quay, ghi lại danh sách yêu cầu xóa và áp lại khi phải khôi phục từ bản sao lưu cũ. Cách làm cụ thể nên được pháp chế xem trước.

Legal hold là gì và ảnh hưởng thế nào đến việc xóa dữ liệu AI? Legal hold là lệnh tạm giữ dữ liệu liên quan đến tranh chấp, thanh tra hoặc điều tra, kể cả khi đã đến hạn xóa. Khi có lệnh, quy trình xóa tự động phải bỏ qua đúng phạm vi dữ liệu bị giữ và ghi lại lý do, rồi tiếp tục xóa khi lệnh được gỡ.

Kết luận

Chính sách lưu trữ dữ liệu cho AI Agent bắt đầu từ bản đồ nơi dữ liệu nằm, không phải từ một con số thời hạn. Khi mỗi loại dữ liệu có mục đích, mỗi bản sao phái sinh mang mã nguồn gốc, lệnh xóa đi tới mọi kho và legal hold được tôn trọng, doanh nghiệp mới có thể trả lời khách một cách trung thực rằng dữ liệu đã được xóa. Kiểm tra định kỳ là bằng chứng để câu trả lời đó đứng vững.

Trao đổi với Naventic để rà đường đi dữ liệu của AI Agent đang vận hành. Đọc thêm: Dịch vụ.