Kiểm soát dữ liệu AI Agent trong vận hành hằng ngày: Doanh nghiệp cần làm gì?

Phần lớn thảo luận về bảo mật AI Agent diễn ra trước ngày nghiệm thu: phân quyền, mã hóa, hợp đồng với nhà cung cấp mô hình. Những yêu cầu đó được trình bày ở bài bảo mật dữ liệu AI Agent. Nhưng sau khi Agent chạy, dữ liệu vẫn tiếp tục đổ vào mỗi ngày: nhân viên dán nguyên hợp đồng vào khung chat, khách gửi ảnh giấy tờ, tài liệu mới được thêm vào kho kiến thức, nhật ký hội thoại dày lên theo thời gian.

Kiểm soát dữ liệu trong vận hành là trả lời được những câu hỏi rất đời thường: hôm nay dữ liệu gì đã đi vào hệ thống, có cần thiết không, nằm ở đâu, bao giờ bị xóa và ai đã xem.

Bài viết trình bày tám điểm cần kiểm soát, cách đưa chúng vào công việc hằng ngày và cách chia trách nhiệm giữa các bộ phận.

1. Kiểm soát dữ liệu AI Agent trong vận hành gồm những gì

Một AI Agent đang chạy chạm vào dữ liệu ở bốn chỗ: nội dung người dùng nhập, tài liệu trong kho kiến thức, dữ liệu lấy từ hệ thống qua API, và nhật ký ghi lại toàn bộ quá trình. Thiết kế ban đầu có thể đúng, nhưng chỗ nào cũng trôi dần theo thời gian: kho kiến thức được thêm tài liệu không qua rà soát, nhật ký giữ lâu hơn cần thiết, quyền được mở tạm rồi quên thu lại.

Ba mức năng lực kéo theo ba trọng tâm kiểm soát. Với hỏi đáp trên tài liệu, trọng tâm là tài liệu nào được đưa vào kho và ai được hỏi về nó. Với tra cứu thời gian thực, trọng tâm là Agent chỉ lấy đúng các trường cần cho câu trả lời, không kéo cả hồ sơ. Với hành động ghi, dữ liệu Agent ghi sang hệ thống khác phải được theo dõi như dữ liệu do người nhập, có dấu vết ai yêu cầu và vào lúc nào.

2. Tám điểm cần kiểm soát

1. Phân loại dữ liệu

Mỗi nguồn và mỗi loại nội dung Agent xử lý nên có nhãn: công khai, nội bộ hay hạn chế. Khi thêm tài liệu mới vào kho kiến thức, người thêm phải gán nhãn trước khi tài liệu có hiệu lực. Dấu hiệu làm sai là trong kho có tài liệu không rõ nguồn và không rõ ai đưa vào.

2. Mục đích sử dụng

Dữ liệu chỉ nên được dùng cho mục đích đã nêu khi thu thập. Hội thoại tư vấn thu để trả lời khách, không mặc nhiên được dùng làm dữ liệu tiếp thị hay để đánh giá nhân viên. Khi có đề xuất dùng lại dữ liệu cho mục đích mới, cần một bước xem xét và cập nhật chính sách quyền riêng tư nếu cần.

3. Mã hóa truyền và lưu

Trong vận hành, việc cần kiểm là không có đường nào bị bỏ ngỏ: kết nối tới nhà cung cấp mô hình, tới cơ sở dữ liệu nhật ký, tới kho tài liệu đều đi qua kênh mã hóa. Bản sao lưu và file xuất báo cáo cũng là dữ liệu nhưng thường bị quên. Một bản xuất nhật ký gửi qua email nội bộ để phân tích là lỗ hổng rất hay gặp.

4. Quyền truy cập tối thiểu

Quyền của tài khoản dịch vụ và của người vận hành nên được rà lại định kỳ, không chỉ xem xét lúc cấp. Quyền mở tạm để xử lý sự cố phải có hạn và được thu hồi. Người chuyển bộ phận hoặc nghỉ việc cần được gỡ quyền xem nhật ký và quản trị kho kiến thức trong cùng quy trình nghỉ việc chung của công ty.

5. Thời gian lưu dữ liệu

Nhật ký hội thoại, tệp người dùng tải lên và bản ghi truy vấn nên có thời hạn lưu riêng, dựa trên nhu cầu thật như điều tra sự cố, cải thiện chất lượng hay nghĩa vụ lưu trữ nếu có. Hết hạn thì xóa tự động, không dựa vào trí nhớ của ai đó. Nên kiểm tra định kỳ xem lệnh xóa có chạy thật và có xóa cả trong bản sao lưu cũ hay không.

6. Nhật ký và giám sát

Nhật ký cần cho điều tra, nhưng chính nó lại chứa dữ liệu nhạy cảm. Có thể che các trường như số điện thoại, số tài khoản, số giấy tờ trước khi ghi, hoặc ghi mã tham chiếu thay cho giá trị gốc. Quyền xem nhật ký đầy đủ nên hẹp hơn quyền xem thống kê, và mỗi lần mở nhật ký đầy đủ cũng nên để lại dấu vết.

7. Nhà cung cấp phụ

Nhà cung cấp mô hình, dịch vụ lưu trữ, dịch vụ nhận diện giọng nói đều là nơi dữ liệu đi qua. Trong vận hành, cần theo dõi khi họ đổi điều khoản xử lý dữ liệu, đổi vị trí lưu trữ hoặc bật tính năng lưu lịch sử mặc định. Danh sách nhà cung cấp phụ nên có người phụ trách cập nhật và được đối chiếu với chính sách quyền riêng tư của doanh nghiệp.

8. Quy trình xử lý sự cố

Khi phát hiện dữ liệu đi sai chỗ, như Agent trả lời bằng thông tin của khách khác hoặc tài liệu hạn chế lọt vào kho công khai, phải biết ngay ai được tạm dừng, ai điều tra và ai thông báo. Quy trình nên gồm gỡ nguồn gây lỗi, xác định phạm vi ảnh hưởng qua nhật ký và kiểm thử lại trước khi mở. Diễn tập trên giấy một lần trước khi phải dùng thật sẽ lộ ra nhiều chỗ còn thiếu.

3. Đưa kiểm soát vào vận hành

Bước 1: Xác định phạm vi và kết quả cần đo

Lập bản đồ dữ liệu: Agent nhận gì từ người dùng, đọc gì từ kho và hệ thống, ghi gì ra ngoài, lưu gì trong nhật ký. Đầu ra là bảng liệt kê từng loại dữ liệu kèm nhãn, mục đích, nơi lưu và thời hạn. Bộ phận phụ trách quyền riêng tư hoặc pháp chế xác nhận bảng này.

Bước 2: Chuẩn hóa dữ liệu cùng quyền truy cập

Áp nhãn vào nguồn, thu hẹp quyền tài khoản dịch vụ theo bảng, bật che dữ liệu trong nhật ký và cài lịch xóa tự động. Đầu ra là cấu hình đã áp dụng cùng biên bản kiểm tra từng mục. IT xác nhận phần kỹ thuật, còn chủ sở hữu nghiệp vụ xác nhận Agent vẫn đủ dữ liệu để làm việc.

Bước 3: Thiết kế tích hợp, ngoại lệ và phê duyệt

Xác định những thay đổi phải duyệt: thêm nguồn dữ liệu vào kho, mở rộng trường lấy qua API, cấp quyền xem nhật ký đầy đủ, xuất dữ liệu ra ngoài hệ thống. Đầu ra là quy trình duyệt ngắn cho từng loại thay đổi và danh sách người duyệt. Không có bước này, các thay đổi nhỏ cộng dồn sẽ làm lệch hẳn thiết kế ban đầu.

Bước 4: Kiểm thử vận hành rồi cải thiện theo log

Định kỳ lấy mẫu nhật ký để xem dữ liệu nhạy cảm có lọt qua lớp che không, kho kiến thức có tài liệu chưa gán nhãn không, lệnh xóa có chạy không. Đầu ra là một báo cáo rà soát ngắn kèm danh sách việc cần sửa. Người phụ trách an toàn thông tin ký nhận và theo dõi đến khi đóng từng việc.

4. Ví dụ giả định

Một trợ lý nội bộ chỉ cần tài liệu quy trình nhưng được cấp cả thư mục hồ sơ nhân sự. Doanh nghiệp tách nguồn, thu hẹp tài khoản dịch vụ và kiểm thử truy cập vượt quyền trước khi mở lại.

Sau sự cố này, bộ kiểm thử định kỳ được thêm một nhóm câu hỏi cố tình chạm tới dữ liệu nhân sự: hỏi lương của đồng nghiệp, hỏi lý do một người nghỉ việc, hỏi địa chỉ nhà riêng. Kết quả đúng là Agent không tìm thấy thông tin, vì nguồn đó đã nằm ngoài phạm vi đọc. Nhật ký giai đoạn trước cũng được rà lại để biết đã có câu trả lời nào lộ dữ liệu nhân sự chưa và ai cần được thông báo.

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

• Không dùng prompt làm lớp bảo mật duy nhất
• Không thu dữ liệu vượt mục đích
• Log có thể chứa dữ liệu nhạy cảm
• Cần rà soát hợp đồng và vị trí lưu trữ

Một câu dặn trong prompt như “không tiết lộ thông tin nhân sự” không ngăn được Agent đọc tài liệu nếu tài khoản dịch vụ vẫn có quyền. Kiểm soát thật nằm ở nguồn và quyền. Trong vận hành, rủi ro lớn thường không đến từ tấn công mà từ việc dữ liệu tích lũy dần: nhật ký giữ mãi, tệp tải lên không xóa, tài liệu nhạy cảm được thêm vào kho cho tiện. Hợp đồng với nhà cung cấp phụ cũng cần đọc lại mỗi lần họ cập nhật điều khoản.

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

Chủ sở hữu nghiệp vụ quyết định dữ liệu nào thật sự cần cho công việc của Agent và duyệt khi thêm nguồn mới. Bộ phận IT quản lý tài khoản dịch vụ, cấu hình che dữ liệu, lịch xóa và sao lưu. Người vận hành Agent đọc nhật ký để cải thiện chất lượng trong đúng phạm vi quyền được cấp, và báo ngay khi thấy dữ liệu không nên có mặt. Bộ phận pháp chế hoặc phụ trách quyền riêng tư giữ bảng dữ liệu, thời hạn lưu và đối chiếu với chính sách đã công bố cho khách hàng và nhân viên.

Mỗi thay đổi về nguồn dữ liệu, trường lấy qua API hay thời hạn lưu cần được ghi lại cùng tên người duyệt. Khi khách hàng hoặc nhân viên yêu cầu xem hay xóa dữ liệu của mình, doanh nghiệp phải biết dữ liệu đó nằm ở những đâu trong hệ thống Agent, kể cả nhật ký và bản sao lưu. Nếu không trả lời được câu hỏi này trong thời gian hợp lý, bản đồ dữ liệu cần được làm lại.

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

• Tỷ lệ yêu cầu xử lý đúng mà không dùng dữ liệu ngoài phạm vi
• Tỷ lệ từ chối đúng các yêu cầu chạm tới dữ liệu hạn chế
• Số lần dữ liệu nhạy cảm lọt qua lớp che trong mẫu nhật ký
• Số quyền tạm chưa thu hồi và bản ghi quá hạn chưa xóa

Không ghi nhận sự cố nào chưa chắc là tốt, có khi chỉ là chưa ai kiểm. Chỉ số có ý nghĩa đến từ rà soát chủ động: lấy mẫu nhật ký, đếm tài liệu chưa gán nhãn, kiểm tra lệnh xóa. Theo dõi xu hướng qua các kỳ để biết kiểm soát đang chặt lên hay đang trôi dần.

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

• Bản đồ dữ liệu đã có nhãn, mục đích, nơi lưu và thời hạn
• Nguồn dữ liệu và chủ sở hữu đã xác nhận
• Quyền đọc ghi đã thử với nhiều vai trò
• Nhật ký đã che các trường nhạy cảm và giới hạn người xem
• Lịch xóa tự động đã chạy thử và được kiểm tra kết quả
• Có quy trình xử lý sự cố và người được quyền tạm dừng

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

Có thể siết kiểm soát dữ liệu khi AI Agent đã chạy không? Có. Bắt đầu bằng việc lập bản đồ dữ liệu hiện có, rà quyền tài khoản dịch vụ và đặt thời hạn lưu cho nhật ký. Những việc này không cần dừng Agent, nhưng nên làm xong trước khi mở thêm người dùng hoặc nguồn dữ liệu.

Nên bắt đầu kiểm soát dữ liệu AI Agent từ đâu? Từ nhật ký hội thoại, vì đây là nơi dữ liệu tích lũy nhanh nhất và thường có nhiều người xem nhất. Tiếp theo là kho kiến thức: rà các tài liệu chưa rõ nguồn và chưa gán nhãn.

Thay đổi nào về dữ liệu cần người duyệt? Thêm nguồn dữ liệu mới, mở rộng trường lấy từ hệ thống, cấp quyền xem nhật ký đầy đủ, kéo dài thời hạn lưu hoặc xuất dữ liệu ra ngoài. Người duyệt nên là chủ sở hữu nghiệp vụ cùng người phụ trách quyền riêng tư.

Có nên giữ toàn bộ nhật ký hội thoại để cải thiện Agent không? Chỉ nên giữ phần cần thiết, trong thời hạn đã định và sau khi che các trường nhạy cảm. Để cải thiện chất lượng, thường chỉ cần các hội thoại lỗi hoặc bị chuyển người, không cần giữ mọi hội thoại vô thời hạn.

Kết luận

Kiểm soát dữ liệu không kết thúc ở ngày nghiệm thu. Doanh nghiệp giữ được kiểm soát khi biết dữ liệu nào đang đi vào Agent, ai được xem, lưu đến bao giờ, và có người rà lại định kỳ thay vì chờ sự cố mới xem. Với rủi ro đến từ nội dung độc hại giấu trong tài liệu, xem thêm bài prompt injection và cách bảo vệ AI Agent.

Trao đổi với Naventic để rà soát cách AI Agent đang xử lý dữ liệu. Đọc thêm: AI Agent nội bộ.