Trong bài viết này
Một ý chính
Dữ liệu phải được bảo vệ bằng kiến trúc và quyền truy cập, không phải bằng lời dặn trong prompt. Chỉ cung cấp phần thông tin cần thiết cho đúng tác vụ, đúng người và đúng thời điểm.
Một câu hỏi rất chính đáng khi doanh nghiệp bắt đầu dùng AI là: “Mình có đang đưa hết bí quyết và dữ liệu khách hàng cho một bên khác không?”
Mình nghĩ không nên trả lời bằng một lời trấn an đơn giản. Cũng không nên coi mọi cách dùng AI đều có mức rủi ro như nhau. Điều cần làm là vẽ được đường đi của dữ liệu: từ nơi lưu trữ, qua ứng dụng, đến mô hình, công cụ và cả hệ thống ghi log.
Bài viết này là một khung suy nghĩ kỹ thuật, không thay thế việc đánh giá bảo mật cho từng hệ thống cụ thể.
Biết dữ liệu nào đang được đưa đi đâu
Trước khi chọn mô hình, hãy phân loại thông tin: nội dung công khai, dữ liệu nội bộ, thông tin khách hàng, bí mật kinh doanh và thông tin xác thực. Không phải tất cả đều cần đi vào ngữ cảnh của mô hình.
Một trợ lý tóm tắt tiến độ có thể chỉ cần trạng thái công việc và những điểm đang vướng, thay vì toàn bộ hồ sơ khách hàng. Một tác vụ phân loại yêu cầu có thể dùng mã định danh thay cho tên, số điện thoại hoặc địa chỉ.
OWASP xem việc lộ thông tin nhạy cảm là một nhóm rủi ro quan trọng của ứng dụng LLM.1 Từ đó, mình chọn nguyên tắc thực dụng: dữ liệu nào không cần cho tác vụ thì không gửi, kể cả khi hệ thống đủ dung lượng để nhận.
Phân biệt chuyện huấn luyện với chuyện xử lý dữ liệu
Một dịch vụ cam kết không dùng dữ liệu để huấn luyện không đồng nghĩa dữ liệu không được truyền đi, không được lưu tạm hoặc không đi qua các hệ thống hỗ trợ. Doanh nghiệp cần kiểm tra điều khoản của đúng sản phẩm và đúng cấu hình đang sử dụng, thay vì suy từ một lời quảng cáo chung.3
Những câu hỏi cần được làm rõ gồm thời gian lưu giữ, phạm vi ghi log, quyền truy cập hỗ trợ, vị trí xử lý, nhà thầu phụ, khả năng xóa dữ liệu và cách xử lý sự cố. Các lựa chọn này có thể khác nhau giữa gói cá nhân, dịch vụ API và hợp đồng doanh nghiệp.
Không có một nhãn “an toàn” đủ dùng cho mọi tình huống. Ranh giới chấp nhận được phải gắn với dữ liệu, nghiệp vụ và nghĩa vụ của chính doanh nghiệp.
RAG không tự động giải quyết bài toán bảo mật
Dùng RAG để tìm thông tin trong kho tài liệu riêng có thể giúp giới hạn phần nội dung được đưa vào câu hỏi. Nhưng khi dùng mô hình bên ngoài, những đoạn được truy xuất vẫn có thể được gửi tới nhà cung cấp để xử lý.4
Cần áp dụng quyền truy cập trước khi truy xuất hoặc trước khi đưa nội dung vào ngữ cảnh. Một người không được xem hồ sơ nhân sự thì trợ lý của họ cũng không được đọc hồ sơ ấy. Không nên dựa vào câu lệnh “đừng tiết lộ” để bù cho một hệ thống phân quyền sai.
Kho dữ liệu tìm kiếm, bộ nhớ hội thoại, cache và log cũng cần được bảo vệ. Chỉ giữ cơ sở dữ liệu gốc trong mạng nội bộ chưa đủ nếu các bản sao của thông tin lại xuất hiện ở nhiều nơi khác.
Agent cần quyền hạn nhỏ hơn sự nhiệt tình của nó
Khi AI được kết nối với email, hệ thống bán hàng hoặc kho tệp, câu hỏi không còn chỉ là “nó biết gì?” mà còn là “nó được phép làm gì?”. Một tài liệu hoặc tin nhắn không đáng tin cậy có thể chứa chỉ dẫn nhằm làm lệch hành vi của mô hình; đây là dạng rủi ro prompt injection mà OWASP mô tả.2
Một thiết kế thận trọng sẽ kiểm tra quyền ở lớp công cụ, dùng tài khoản có phạm vi hẹp và yêu cầu xác nhận cho hành động nhạy cảm. Nội dung AI sinh ra không được mặc nhiên xem là lệnh hợp lệ để thực thi.
Ví dụ, agent chăm sóc khách hàng có thể được đọc trạng thái đơn nhưng không tự thay đổi tài khoản nhận tiền. Việc tách quyền này cần được thực hiện bằng mã và cấu hình, không chỉ bằng một đoạn system prompt.
Cloud, nội bộ hay kết hợp?
Chạy mô hình trong hạ tầng riêng có thể phù hợp khi doanh nghiệp cần kiểm soát đường đi của dữ liệu. Đổi lại, đội ngũ phải đảm nhiệm vận hành, cập nhật, kiểm soát truy cập và giám sát. “Chạy nội bộ” không tự làm hệ thống miễn nhiễm với lộ dữ liệu hay cấu hình sai.
Một hướng kết hợp là xử lý phần nhạy cảm trong vùng kiểm soát, chỉ gửi thông tin đã được giảm thiểu cho tác vụ phù hợp ở bên ngoài. Nhưng cách này vẫn cần kiểm tra khả năng tái nhận diện và dữ liệu còn sót lại, thay vì coi bước che tên là bảo đảm tuyệt đối.
Mình sẽ đánh giá bằng các tình huống cụ thể: người dùng trái quyền, tài liệu chứa chỉ dẫn độc hại, công cụ bị lỗi, log bị truy cập và yêu cầu xóa thông tin. Hệ thống cần chứng minh được cách phản ứng, không chỉ có sơ đồ đẹp.
Điều mình muốn giữ lại là: doanh nghiệp không phải chọn giữa “không dùng AI” và “giao hết dữ liệu”. Có nhiều mức triển khai ở giữa, miễn là quyền kiểm soát được thiết kế ngay từ đầu.
Câu hỏi thường gặp
Làm sao dùng AI mà vẫn kiểm soát dữ liệu doanh nghiệp?
Phân loại dữ liệu, chỉ cung cấp thông tin cần cho tác vụ và kiểm tra quyền ở lớp truy xuất, ứng dụng cùng công cụ. Cần kiểm tra điều khoản lưu giữ, ghi log và xử lý dữ liệu của đúng dịch vụ đang sử dụng.
RAG hoặc chạy mô hình nội bộ có tự bảo đảm an toàn không?
Không. RAG vẫn cần phân quyền trước khi đưa nội dung vào ngữ cảnh; các đoạn truy xuất có thể được gửi cho nhà cung cấp mô hình. Chạy nội bộ vẫn đòi hỏi vận hành, cập nhật, giám sát và bảo vệ cache, log cùng bộ nhớ hội thoại.
Đọc thêm & nguồn tham khảo
- OWASP — LLM02:2025 Sensitive Information Disclosure ↗
- OWASP — LLM01:2025 Prompt Injection ↗
- Google Cloud — Data retention and training restrictions ↗
- Microsoft Learn — Retrieval augmented generation and indexes ↗
Các tình huống minh họa trong bài không phải báo cáo về một dự án cụ thể. Những đề xuất triển khai là góc nhìn của người viết, cần được kiểm chứng trong bối cảnh thực tế.
Cảm ơn bạn đã đọc đến đây.
Khám phá thêm một góc nhìn