Sơ đồ phòng ban & phân quyền khi triển khai AI nội bộ

Phân quyền theo phòng ban khi triển khai AI nội bộ nghĩa là: mỗi phòng ban (kế toán, nhân sự, kinh doanh…) chỉ được AI trả lời dựa trên tài liệu mà họ có quyền xem — không rò rỉ chéo. Cách làm chuẩn là RBAC (kiểm soát truy cập theo vai trò) cho ứng dụng, kết hợp lọc quyền ngay ở tầng RAG (AI chỉ truy hồi những đoạn tài liệu người dùng được phép). Bài này đưa ra hai sơ đồ: bản đồ phòng ban và ma trận vai trò × quyền, cùng cách triển khai cuốn chiếu.

Vì sao cần phân quyền theo phòng ban?

AI nội bộ chỉ hữu ích khi nó "đọc" được tài liệu thật của doanh nghiệp. Nhưng cùng một trợ lý AI phục vụ mọi phòng ban lại tạo ra một rủi ro mới: nếu ai cũng hỏi được mọi thứ, ranh giới thông tin giữa các phòng biến mất. Kế toán không nên hỏi được bảng lương chi tiết của nhân sự; nhân viên kinh doanh không nên moi được hợp đồng của khách hàng thuộc đội khác; và không phòng nào nên đọc được tài liệu chiến lược của ban giám đốc.

Đây không phải rủi ro giả định. Trong danh mục rủi ro cho ứng dụng LLM của OWASP, rò rỉ thông tin nhạy cảm (sensitive information disclosure) là một hạng mục riêng: mô hình có thể vô tình đưa dữ liệu người dùng không được phép xem vào câu trả lời. Với AI nội bộ, phân quyền theo phòng ban chính là hàng rào đầu tiên chặn kiểu rò rỉ đó — và nó phải được thiết kế ngay từ kiến trúc, không phải vá về sau.

Nguyên tắc nền tảng là đặc quyền tối thiểu (least privilege): mỗi người chỉ có đúng quyền cần cho công việc, không hơn. Phân quyền theo vai trò (RBAC) là cách phổ biến nhất để hiện thực hoá nguyên tắc này ở quy mô tổ chức.

Sơ đồ phòng ban dùng AI nội bộ

Sơ đồ dưới đây cho thấy một trợ lý AI nội bộ duy nhất ở trung tâm, nằm gọn trong ranh giới hạ tầng của bạn. Mỗi phòng ban kết nối tới AI, nhưng phạm vi tài liệu mà AI được phép truy hồi cho phòng đó là khác nhau — đó chính là "vùng nhìn thấy" riêng của từng phòng.

Điểm mấu chốt: dù mọi phòng dùng chung một hệ thống AI, "phạm vi tài liệu" của mỗi phòng phải được tách bạch. Người ở phòng Kế toán hỏi về lương của nhân viên phòng Nhân sự thì AI phải trả lời như thể tài liệu đó không tồn tại — chứ không phải "bạn không có quyền xem" (điều đó cũng đã tiết lộ sự tồn tại của tài liệu).

Ma trận phân quyền (RBAC)

RBAC gán quyền cho vai trò thay vì cho từng cá nhân, rồi gán người dùng vào vai trò. Nhờ đó khi một người chuyển bộ phận, bạn chỉ đổi vai trò của họ thay vì rà lại từng quyền. Mô hình RBAC được NIST chuẩn hoá và là nền tảng kiểm soát truy cập trong hầu hết hệ thống doanh nghiệp.

Bảng dưới minh hoạ bốn vai trò điển hình và quyền tương ứng. Vai trò cao hơn kế thừa quyền của vai trò thấp hơn — đúng theo tinh thần RBAC phân cấp.

Sơ đồ dưới đây thể hiện cùng ý tưởng dưới dạng ánh xạ vai trò → quyền: vai trò càng cao càng "gom" thêm quyền.

Phân quyền ở tầng RAG

RBAC ở tầng ứng dụng (ai được bấm nút nào, mở màn hình nào) là chưa đủ. Với AI nội bộ, chốt chặn quan trọng nhất nằm ở tầng RAG — nơi AI đi tìm tài liệu để trả lời. Nếu bước truy hồi (retrieval) không lọc theo quyền, thì dù giao diện có khoá nút "xem lương" đến đâu, người dùng vẫn có thể hỏi và AI sẽ ghép nội dung lương vào câu trả lời. Quyền đã "rò rỉ" qua chính câu trả lời.

Cách làm đúng: lọc quyền ngay khi truy hồi. Mỗi đoạn tài liệu (chunk) được gắn metadata về phòng ban / mức nhạy cảm; khi người dùng đặt câu hỏi, hệ thống chỉ tìm trong những chunk mà nhóm của họ được phép. AI không bao giờ "nhìn thấy" tài liệu ngoài phạm vi, nên không thể vô tình tiết lộ. Đây cũng là biện pháp trực tiếp cho hạng mục rò rỉ thông tin nhạy cảm trong OWASP Top 10 cho ứng dụng LLM.

Chi tiết cách xây tầng RAG có ở bài RAG cho tài liệu nội bộ; các lớp phòng thủ tổng thể (chặn kết nối ra ngoài, kiểm soát truy cập, nhật ký) có ở Hệ thống bảo mật AI nội bộ.

# nhóm phòng ban lấy từ token SSO của người dùng (KHÔNG lấy từ client)
groups = user.sso_groups          # vd: ["ke-toan"]

results = vectordb.search(
    query_embedding = embed(question),
    top_k = 6,
    filter = {                    # lọc TRƯỚC khi xếp hạng độ tương đồng
        "department": {"in": groups},
        "sensitivity": {"lte": user.clearance},
    },
)
# AI chỉ nhận các chunk đã được lọc → không thể lộ tài liệu ngoài phạm vi
answer = llm.generate(question, context=results)

Triển khai theo phòng ban

Không nên bật quyền cho toàn tổ chức cùng lúc. Cách an toàn là cuốn chiếu từng phòng:

• Chọn một phòng thí điểm có tài liệu rõ ràng (ví dụ: quy trình nội bộ của một phòng), nạp tài liệu kèm metadata, kiểm thử phạm vi truy hồi.
• Dùng SSO + nhóm làm nguồn danh tính duy nhất: người dùng đăng nhập một lần, nhóm phòng ban quyết định phạm vi tài liệu — không quản lý tài khoản rời rạc.
• Bật nhật ký kiểm toán từ đầu: lưu ai hỏi gì, tài liệu nào được truy hồi — để rà soát khi nghi ngờ rò rỉ và để chứng minh tuân thủ.
• Rà quyền định kỳ: khi nhân sự đổi phòng, khoá/đổi vai trò ngay; định kỳ soát lại ai đang có quyền gì (least privilege).
• Mở rộng dần sang phòng tiếp theo sau khi phòng thí điểm chạy ổn.

Góc nhìn Namtech

Với nền tảng AI nội bộ Namtech triển khai (chạy 100% tại chỗ trên Apple Silicon, mô hình mã nguồn mở), phân quyền theo phòng ban được đặt ở hai tầng: RBAC cho ứng dụng và lọc tài liệu ngay trong RAG theo nhóm SSO. Chúng tôi bật nhật ký kiểm toán mặc định và triển khai cuốn chiếu từng phòng để bạn thấy rõ ranh giới thông tin trước khi mở rộng. Mục tiêu là: AI dùng chung, nhưng mỗi phòng chỉ "nhìn thấy" đúng phần của mình — dữ liệu vẫn không rời tổ chức.

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

Lưu ý: Bài viết mang tính hướng dẫn về mô hình phân quyền, cập nhật 02/07/2026; hãy điều chỉnh vai trò và phạm vi theo cơ cấu tổ chức thực tế của bạn.