Ngày 19/8/2026, OpenAI công bố mở rộng khả năng Zero Data Retention cho các khách hàng API đủ điều kiện sử dụng mô hình frontier, đồng thời giới thiệu Private Safety Processing. Thông tin kỹ thuật quan trọng ở đây là nội dung prompt và phản hồi không được OpenAI lưu giữ sau khi yêu cầu được xử lý, còn các cơ chế an toàn vẫn cần vận hành theo cách tương thích với cam kết đó. Với doanh nghiệp, đây không chỉ là một tính năng mới. Nó cho thấy yêu cầu về dữ liệu đang dịch chuyển từ lời hứa chính sách sang những điều khoản có thể thiết kế trong kiến trúc vận hành.
Cần đọc thông báo này một cách thận trọng. Zero Data Retention không có nghĩa mọi rủi ro dữ liệu tự động biến mất, cũng không phải mọi khách hàng hay mọi cách triển khai đều có cùng điều kiện. Dữ liệu vẫn có thể xuất hiện ở hệ thống của doanh nghiệp, trong application log (bản ghi để theo dõi và kiểm tra lại hoạt động hoặc thay đổi tương ứng), ở nhà cung cấp tích hợp, trong các tệp người dùng đưa vào hoặc ở các bước kiểm soát truy cập nội bộ. Điều đáng chú ý là các nhà quản lý giờ có thêm lý do để chuyển cuộc trao đổi từ câu hỏi chung “nhà cung cấp có bảo mật không?” sang câu hỏi cụ thể hơn: ở mỗi điểm của luồng công việc, dữ liệu được giữ ở đâu, trong bao lâu, ai có quyền xem và vì mục đích nào?
Từ chính sách bảo mật đến bản đồ luồng dữ liệu
Nhiều tổ chức có một chính sách AI hoặc một điều khoản bảo mật trong hợp đồng, nhưng thiếu bản đồ cho từng quy trình sử dụng. Khi nhân viên dùng AI để tóm tắt tài liệu, hỗ trợ chăm sóc khách hàng hay phân tích lỗi vận hành, dữ liệu không đi theo một đường thẳng. Nó có thể được trích xuất từ hệ thống nguồn, đi qua một lớp tích hợp, được biến đổi trước khi gửi tới mô hình, rồi quay lại một ứng dụng nội bộ. Mỗi điểm đó tạo ra một câu hỏi quản trị riêng.
Vì vậy, điểm khởi đầu hợp lý không phải là danh sách dài các công cụ được phép hoặc bị cấm. Doanh nghiệp nên chọn vài luồng công việc có giá trị và có độ nhạy dữ liệu khác nhau, rồi mô tả chúng đủ chi tiết để kiểm tra. Một quy trình soạn trả lời cho khách hàng, chẳng hạn, cần phân biệt dữ liệu định danh, nội dung hợp đồng, lịch sử trao đổi và phần tri thức nội bộ được đưa vào ngữ cảnh. Sau đó, đội ngũ mới có thể quyết định loại dữ liệu nào được gửi, dữ liệu nào phải che đi, và dữ liệu nào chỉ được xử lý trong một môi trường có điều kiện lưu giữ cụ thể.
| Điểm kiểm soát | Câu hỏi quản trị | Việc cần làm |
|---|---|---|
| Dữ liệu đầu vào | Thông tin nào thực sự cần cho nhiệm vụ, và phần nào có thể ẩn hoặc thay thế? | Tối thiểu hóa dữ liệu trước khi gửi vào luồng AI. |
| Nhà cung cấp và tích hợp | Điều kiện lưu giữ, truy cập và xử lý an toàn áp dụng cho cấu hình nào? | Đối chiếu hợp đồng, cấu hình kỹ thuật và các dịch vụ trung gian. |
| Đầu ra và log | Kết quả, bản nháp và log được lưu ở đâu; ai có thể truy cập? | Thiết kế thời hạn lưu, phân quyền và cơ chế kiểm tra định kỳ. |
Ý nghĩa quản trị: quyền kiểm soát nằm ở cấu hình và quy trình
Một sai lầm phổ biến là xem lựa chọn nhà cung cấp là quyết định duy nhất về bảo mật AI. Thực tế, cùng một nền tảng có thể được dùng an toàn hoặc rủi ro tùy cách doanh nghiệp cấu hình quyền truy cập, kết nối dữ liệu, lưu log và phê duyệt use case. Một tính năng về không lưu giữ dữ liệu có thể giảm một lớp rủi ro trong quan hệ với nhà cung cấp, nhưng nó không thay thế việc phân loại dữ liệu, kiểm soát đầu vào, giám sát người dùng hay rà soát đầu ra.
Điều này cũng thay đổi vai trò của các bộ phận. CNTT không thể đơn độc quyết định loại dữ liệu nào được phép dùng; pháp chế không thể chỉ dừng ở việc đọc điều khoản; còn các đơn vị nghiệp vụ không nên tự đánh giá rủi ro chỉ bằng cảm giác công cụ “có vẻ an toàn”. Một cơ chế thực dụng hơn là để người sở hữu quy trình mô tả giá trị và luồng công việc, đội công nghệ xác định điểm tích hợp và kiểm soát, còn an ninh–pháp chế kiểm tra điều kiện dữ liệu, lưu giữ và trách nhiệm.
Ví dụ: trợ lý hỗ trợ khách hàng nội bộ
Một doanh nghiệp muốn dùng AI để gợi ý câu trả lời cho nhân viên chăm sóc khách hàng. Họ không cần đưa toàn bộ hồ sơ khách hàng vào ngữ cảnh của mọi câu hỏi. Có thể tách nhiệm vụ thành ba phần: dùng kho tri thức đã kiểm duyệt để tạo khung trả lời; chỉ lấy các trường dữ liệu cần thiết cho từng trường hợp; và để nhân viên kiểm tra trước khi gửi. Nếu use case cần dùng dữ liệu nhạy cảm, nhóm triển khai phải xác nhận điều kiện lưu giữ của cấu hình đang dùng, cách các log được tạo và người nào được truy cập. Nhờ vậy, cuộc thảo luận không dừng ở một nhãn “an toàn”, mà đi vào thiết kế công việc cụ thể.
Ba việc doanh nghiệp nên làm trong quý tới
Thứ nhất, lập danh mục các use case AI đang được dùng thật, không chỉ các dự án đã được phê duyệt. Hỏi các bộ phận họ đang đưa loại dữ liệu nào vào công cụ nào và đầu ra đi về đâu. Mục tiêu không phải truy tìm để xử phạt; mục tiêu là nhìn thấy khoảng cách giữa quy định trên giấy và hành vi vận hành.
Thứ hai, chọn ba use case ưu tiên để lập bản đồ dữ liệu và kiểm tra điều kiện của từng nhà cung cấp, mô hình, tài khoản và tích hợp. Những câu hỏi này cần được ghi thành bằng chứng có thể rà soát khi thay đổi công cụ hoặc mở rộng quy mô, thay vì chỉ tồn tại trong một cuộc họp.
Thứ ba, thiết lập điểm phê duyệt rõ cho các use case có dữ liệu nhạy cảm hoặc ảnh hưởng trực tiếp tới khách hàng. Điểm phê duyệt không nhằm làm chậm mọi thử nghiệm; nó giúp phân biệt thử nghiệm có thể tiến hành trong vùng an toàn với triển khai cần thêm kiểm soát trước khi mở rộng.
Kết luận
Thông báo về Zero Data Retention cho thấy thị trường AI doanh nghiệp đang tiến gần hơn tới các cam kết dữ liệu có thể cấu hình và kiểm tra. Giá trị quản trị của chuyển động này không nằm ở việc gắn thêm một nhãn bảo mật lên công cụ. Nó nằm ở chỗ doanh nghiệp dùng cơ hội đó để làm rõ quyền kiểm soát dữ liệu trong từng luồng công việc: dữ liệu nào thực sự cần, được xử lý ở đâu, được giữ bao lâu và ai chịu trách nhiệm khi điều kiện thay đổi.
Nguồn tham khảo
OpenAI. (2026, August 19). Offering Zero Data Retention for frontier models. https://openai.com/index/offering-zero-data-retention-for-frontier-models/
