Vì sao nhiều dự án AI chatbot không qua được khâu phê duyệt?
Dự án AI chatbot thường bị dừng vì người đề xuất không chứng minh được dữ liệu nội bộ sẽ đi đâu. Bộ phận tra cứu hay chăm sóc khách hàng muốn đưa tài liệu nội bộ vào AI để giảm việc trả lời lặp lại. Bộ phận pháp chế thì cần biết tài liệu đó có rời khỏi công ty hay không.
Với phần lớn doanh nghiệp, AI chatbot dạng SaaS có máy chủ tại Nhật, mã hoá đường truyền và cam kết không dùng dữ liệu để huấn luyện là đủ để duyệt. Năm câu hỏi nên hỏi nhà cung cấp SaaS đã có trong bài [5 câu hỏi bảo mật trước khi duyệt AI chatbot](/vi/blog/ai-chatbot-security-questions-enterprise).
Bài này dành cho trường hợp còn lại: quy định nội bộ, hợp đồng với khách hàng hoặc yêu cầu của cơ quan quản lý không cho dữ liệu đi ra internet. Thường gặp ở tài chính, y tế, cơ quan nhà nước và các SIer nhận dự án của những khách hàng này.
"Không gửi dữ liệu ra ngoài" nghĩa là những thành phần nào phải nằm bên trong?
Một chatbot RAG (Retrieval-Augmented Generation, tìm đoạn tài liệu liên quan rồi để AI viết câu trả lời dựa trên đó) chỉ thật sự không gửi dữ liệu ra ngoài khi cả 5 thành phần dưới đây đều chạy trong mạng nội bộ.
Có sản phẩm tự gọi là "on-premise" nhưng chỉ đặt thành phần 1 đến 3 trong mạng nội bộ, còn bước viết câu trả lời vẫn gọi API LLM bên ngoài. Khi đó câu hỏi của người dùng và đoạn tài liệu liên quan vẫn đi ra internet. Vì vậy, khi đánh giá, nên hỏi lần lượt từng thành phần thay vì chỉ hỏi "có on-premise không".
Làm sao kiểm chứng một hệ thống thật sự không gửi dữ liệu ra ngoài?
Cam kết trong tài liệu giới thiệu không thay được kiểm chứng. Doanh nghiệp nên yêu cầu nhà cung cấp làm đủ 3 bước sau trước khi nghiệm thu:
1. Liệt kê kết nối ra ngoài theo thiết kế. Mỗi kết nối phải có lý do, đích đến và loại dữ liệu đi qua. Danh sách càng ngắn càng dễ duyệt.
2. Quét mã nguồn và cấu hình. Tìm mọi biến môi trường, khoá API và địa chỉ của dịch vụ bên ngoài. Kết quả quét phải khớp với danh sách ở bước 1.
3. Chạy thử khi chặn toàn bộ kết nối ra ngoài ở tường lửa. Nếu hệ thống vẫn trả lời bình thường, nghĩa là không có thành phần nào ngầm phụ thuộc internet.
Bước 2 là việc VAON đã làm trên dự án của chính mình: hệ thống quản lý hoá đơn và hợp đồng on-premise mà VAON tự phát triển năm 2026. Khi quét toàn bộ mã nguồn tìm thông tin kết nối dịch vụ bên ngoài, đội ngũ chỉ tìm thấy 6 biến môi trường, tất cả liên quan đến gửi email qua SMTP (kết quả đo ngày 24/08/2026). Hệ thống này không phải chatbot, nhưng cách kiểm chứng giống hệt. Với chatbot RAG, danh sách ở bước 1 lý tưởng là trống, hoặc chỉ còn kết nối tới máy chủ email nội bộ.
Chạy LLM trên phần cứng nội bộ phải đánh đổi những gì?
Đánh đổi lớn nhất của chatbot RAG chạy trong mạng nội bộ nằm ở mô hình ngôn ngữ. Doanh nghiệp không dùng được các LLM thương mại lớn qua API, mà phải chạy một mô hình mở (open-weight) trên máy chủ của mình.
Kỹ thuật lượng tử hoá (quantization, giảm độ chính xác số của mô hình xuống 8 bit hoặc 4 bit) giúp mô hình nhỏ đi nhiều và có thể chạy trên CPU. Đổi lại, tốc độ trả lời chậm hơn, và mô hình nhỏ thường kém hơn ở câu hỏi nhiều bước hoặc tài liệu tiếng Nhật chuyên ngành. Muốn chất lượng gần với LLM thương mại thì thường cần GPU, và chi phí phần cứng tăng theo.
VAON không đưa ra một con số "tiết kiệm X%" cố định cho phương án này. Tổng chi phí phụ thuộc số người dùng, lượng câu hỏi, mô hình chọn được và phần cứng sẵn có, nên con số chung chung dễ sai với trường hợp cụ thể. Cách VAON đề xuất là làm PoC (thử nghiệm khái niệm) nhỏ để đo 3 thứ trên dữ liệu thật của doanh nghiệp:
1. Tỉ lệ trả lời đúng trên bộ khoảng 50 đến 100 câu hỏi thực tế, có đáp án do nhân viên nghiệp vụ chuẩn bị.
2. Thời gian phản hồi khi nhiều người hỏi cùng lúc, trên đúng cấu hình máy chủ dự định dùng.
3. Chi phí phần cứng và vận hành ước tính cho 3 năm, đặt cạnh báo giá SaaS tương đương.
Có 3 con số này, ban giám đốc so sánh được hai phương án trên cùng một mặt bằng.
Phân quyền tài liệu trong chatbot RAG nên đặt ở đâu?
Phân quyền trong chatbot RAG nên đặt ở bước tìm kiếm tài liệu, không đặt ở câu lệnh gửi cho LLM. Nếu hệ thống tìm cả tài liệu mật rồi dặn LLM "đừng nhắc đến tài liệu này", nội dung mật vẫn đã nằm trong dữ liệu gửi vào mô hình và có thể lọt ra câu trả lời.
Cách an toàn hơn là gắn thông tin quyền truy cập (phòng ban, chức danh, dự án) vào từng đoạn tài liệu khi đưa vào cơ sở dữ liệu vector. Khi một người hỏi, hệ thống chỉ tìm trong những đoạn người đó được xem. Đoạn không được phép không bao giờ đến được LLM.
Nguyên tắc này áp dụng cho cả hai phương án. ONEBOT, AI chatbot dạng SaaS của VAON, có phân quyền theo vai trò (RBAC) để giới hạn tài liệu mà từng nhóm người dùng nhận được câu trả lời. Với chatbot chạy trong mạng nội bộ, nên chốt phân quyền theo cơ cấu tổ chức thực tế ngay từ đầu, vì sửa phân quyền sau khi đã nạp hàng nghìn tài liệu tốn công hơn nhiều.
Khi nào không nên chọn chatbot RAG chạy trong mạng nội bộ?
Chatbot RAG chạy trong mạng nội bộ không phải lựa chọn mặc định. SaaS là lựa chọn hợp lý hơn trong 4 trường hợp sau:
1. Quy định cho phép dữ liệu ra internet nếu đã mã hoá và lưu tại Nhật. Khi đó SaaS rẻ hơn, nhanh hơn và chất lượng trả lời thường tốt hơn.
2. Doanh nghiệp không có người vận hành máy chủ. Hệ thống nội bộ cần người theo dõi, sao lưu và cập nhật. Thiếu người, rủi ro vận hành có thể lớn hơn rủi ro dữ liệu.
3. Cần trả lời khách qua LINE. LINE là dịch vụ chạy trên internet, nên không đi cùng yêu cầu "không ra internet".
4. Cần kết quả trong vài tuần. SaaS như ONEBOT triển khai trong 2 đến 4 tuần. Hệ thống nội bộ cần khảo sát hạ tầng, PoC và mua phần cứng.
Ngoài ra, chạy trong mạng nội bộ không tự động làm doanh nghiệp tuân thủ Luật Bảo vệ thông tin cá nhân của Nhật (APPI). Kiến trúc thu hẹp đường đi của dữ liệu, nhưng việc dữ liệu nào được đưa vào, ai được xem và giữ trong bao lâu vẫn cần rà soát pháp lý riêng.
Agency và SIer nên chọn phương án nào cho khách hàng của mình?
Agency và SIer nên chọn phương án theo quy định của khách hàng cuối, không theo phương án dễ bán. Khách hàng cuối sẽ hỏi đúng những câu ở mục 2 và mục 3, và đề xuất sẽ bị loại nếu không trả lời được.
VAON hỗ trợ đối tác theo hai cách. Với khách hàng chấp nhận SaaS, VAON có chương trình OEM để đối tác cung cấp ONEBOT dưới thương hiệu của mình. Với khách hàng yêu cầu không ra internet, VAON nhận xây chatbot RAG chạy trong mạng nội bộ như một dự án phát triển riêng thuộc dịch vụ AI và tự động hoá, bắt đầu bằng khảo sát hạ tầng và PoC.