Thiết kế phân quyền cho AI Agent theo vai trò, phòng ban và chi nhánh

Khi AI Agent chỉ trả lời câu hỏi chung về sản phẩm, ai hỏi cũng nhận cùng một câu trả lời. Nhưng khi Agent được nối vào CRM, báo cáo doanh số hay hồ sơ nhân sự, câu hỏi “doanh thu tháng này bao nhiêu” phải có câu trả lời khác nhau tùy người hỏi là nhân viên cửa hàng, trưởng chi nhánh hay giám đốc vùng.

Nhiều doanh nghiệp xử lý chuyện này bằng một câu dặn trong prompt: “chỉ trả lời dữ liệu chi nhánh của người dùng”. Cách đó không an toàn. Prompt có thể bị lách, còn tài khoản kết nối phía sau vẫn đọc được toàn bộ dữ liệu. Phân quyền phải nằm ở hệ thống, không nằm ở lời dặn.

Bài viết trình bày các lớp quyền cần thiết kế cho một Agent dùng chung nhiều phòng ban và chi nhánh, quy trình triển khai, và cách kiểm thử để chắc rằng không ai nhìn thấy dữ liệu ngoài phạm vi của mình.

1. Bản chất của phân quyền AI Agent

Phân quyền cho AI Agent là trả lời ba câu hỏi ở mỗi yêu cầu: người đang hỏi là ai, họ được xem dữ liệu nào, và Agent được phép làm gì thay họ. Agent không nên có quyền riêng rộng hơn người dùng. Nếu Agent dùng một tài khoản dịch vụ có quyền đọc mọi thứ rồi tự lọc kết quả, mọi lỗ hổng ở bước lọc đều trở thành rò rỉ dữ liệu.

Ba mức sử dụng đòi hỏi cách áp quyền khác nhau. Hỏi đáp từ tài liệu nội bộ cần lọc tài liệu theo phòng ban trước khi truy xuất, để đoạn văn ngoài quyền không bao giờ tới được mô hình. Tra cứu thời gian thực trong CRM hay ERP cần truyền danh tính người dùng hoặc bộ lọc chi nhánh xuống tận truy vấn. Hành động ghi như sửa đơn, đổi giá, duyệt đề nghị cần quyền riêng, hẹp nhất có thể, và thường kèm bước xác nhận.

2. Các yếu tố cần thiết kế

1. Xác thực danh tính

Agent phải biết chắc người hỏi là ai qua đăng nhập của hệ thống nội bộ hoặc SSO, không dựa vào điều người dùng tự khai trong tin nhắn. Câu “tôi là trưởng phòng kế toán” trong khung chat không có giá trị gì với phân quyền. Với kênh như Zalo hay email, cần cơ chế liên kết tài khoản kênh với danh tính nội bộ; chưa liên kết được thì chỉ cho dùng phần thông tin công khai.

2. RBAC theo vai trò

Phân quyền theo vai trò gom người dùng vào các nhóm như nhân viên bán hàng, trưởng chi nhánh, kế toán, quản lý vùng, rồi gán quyền cho nhóm thay vì cho từng người. Nên dùng lại vai trò đã có trong hệ thống nhân sự hoặc thư mục người dùng, không dựng một bộ vai trò riêng cho Agent rồi đồng bộ tay. Dấu hiệu thiết kế sai là số vai trò cứ tăng theo từng ngoại lệ đến mức không ai giải thích được.

3. Phạm vi dữ liệu

Vai trò cho biết được làm loại việc gì; phạm vi dữ liệu cho biết được làm trên dữ liệu nào: chi nhánh nào, vùng nào, nhóm khách hàng nào. Hai trưởng chi nhánh cùng vai trò nhưng khác phạm vi. Bộ lọc phạm vi phải được áp ngay trong truy vấn gửi tới nguồn và trong bước tìm tài liệu, không phải sau khi dữ liệu đã về tới mô hình.

4. Quyền công cụ

Mỗi công cụ Agent có thể gọi, như tra công nợ, tạo phiếu, gửi email, cần danh sách vai trò được phép dùng. Nhân viên kho cần tra tồn kho nhưng không cần công cụ xem công nợ khách. Cách an toàn là chỉ nạp cho Agent những công cụ hợp với vai trò của người đang hỏi, thay vì nạp hết rồi dặn mô hình đừng dùng.

5. Phân tách đọc và ghi

Quyền đọc và quyền ghi nên là hai công cụ với hai thông tin xác thực khác nhau. Người được xem đơn hàng chưa chắc được sửa đơn. Tách như vậy cho phép giai đoạn đầu chỉ bật phần đọc, đo chất lượng, rồi mới mở dần thao tác ghi cho từng vai trò, mỗi thao tác đều có nhật ký và mã chống lặp.

6. Quyền tạm thời

Có lúc cần quyền vượt phạm vi thường ngày: người làm thay ở chi nhánh khác, kiểm toán viên xem dữ liệu trong một đợt, kỹ thuật cần xem log gốc để điều tra. Những quyền này phải có thời hạn, có người duyệt và tự hết hạn. Dấu hiệu làm sai là quyền “cấp tạm” vẫn còn rất lâu sau đó vì không ai nhớ thu lại.

7. Rà soát định kỳ

Định kỳ, mỗi trưởng bộ phận nhận danh sách người trong nhóm mình đang có quyền gì với Agent và xác nhận còn đúng hay không. Kèm theo là báo cáo các yêu cầu bị từ chối vì thiếu quyền: nếu một vai trò liên tục bị chặn ở cùng một việc, có thể quyền đang quá chặt so với nhu cầu thật. Kết quả rà soát được lưu lại làm bằng chứng cho kiểm soát nội bộ.

8. Thu hồi khi đổi vị trí

Khi nhân viên chuyển phòng, chuyển chi nhánh hay nghỉ việc, quyền với Agent phải đổi cùng lúc với hệ thống nhân sự, không chờ ai nhớ báo IT. Cách chắc chắn nhất là Agent đọc vai trò và phạm vi từ nguồn danh tính ở mỗi phiên, không giữ bản sao riêng. Cần kiểm thử cả phiên đang mở: người vừa chuyển đi không được tiếp tục hỏi dữ liệu chi nhánh cũ trong cuộc hội thoại cũ.

3. Quy trình triển khai thực tế

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

Liệt kê các nhóm người dùng, câu hỏi và thao tác chính của từng nhóm, cùng nguồn dữ liệu mà mỗi câu hỏi chạm tới. Đầu ra là bảng vai trò, việc và dữ liệu, kèm những câu hỏi mà mỗi vai trò tuyệt đối không được nhận câu trả lời. Chủ nghiệp vụ từng phòng ban xác nhận phần của mình.

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

Kiểm tra dữ liệu nguồn đã có trường để lọc hay chưa: bản ghi doanh số có mã chi nhánh, tài liệu có gắn phòng ban, hồ sơ khách có người phụ trách. Thiếu các trường này thì không thể phân quyền đúng, dù thiết kế tốt đến đâu. Đầu ra là ma trận quyền chính thức và danh sách dữ liệu cần gắn nhãn bổ sung trước khi nối vào Agent.

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

Quyết định danh tính người dùng được truyền xuống từng hệ thống bằng cách nào: dùng chính phiên đăng nhập của người dùng, hay tài khoản dịch vụ hẹp kèm bộ lọc bắt buộc. Thiết kế luồng xin quyền tạm thời, người duyệt và thời hạn, cùng câu trả lời chuẩn khi ai đó hỏi ngoài quyền. Đội kỹ thuật và an toàn thông tin cùng duyệt bản thiết kế này.

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

Chạy bộ ca thử cho từng vai trò: hỏi đúng phạm vi, hỏi chi nhánh khác, hỏi vòng vo để lấy số tổng, yêu cầu thao tác ghi không được phép. Kiểm tra cả câu trả lời lẫn truy vấn phía sau, vì Agent có thể không nói ra nhưng đã đọc dữ liệu ngoài quyền. Cách ghi và đọc các truy vấn này được trình bày ở bài nhật ký AI Agent.

4. Ví dụ giả định

Nhân viên chi nhánh A được hỏi doanh số toàn chuỗi. AI xác thực người dùng, áp bộ lọc quyền tại truy vấn và chỉ trả dữ liệu chi nhánh A. Quản lý vùng có vai trò khác mới được xem bảng tổng hợp.

Tình huống này cho ra một nhóm ca thử rõ ràng: nhân viên chi nhánh A hỏi thẳng doanh số chi nhánh B, hỏi tổng toàn chuỗi, hỏi so sánh A với mức trung bình của chuỗi, và hỏi lại sau khi vừa được điều sang chi nhánh B. Ca thứ ba hay bị bỏ sót, vì con số trung bình đã để lộ dữ liệu tổng hợp. Mỗi ca cần ghi rõ kết quả mong đợi: trả số của A, từ chối lịch sự, hay hướng dẫn xin quyền từ quản lý vùng.

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

• Không chỉ ẩn dữ liệu ở giao diện
• Kiểm tra quyền ở từng công cụ
• Tránh tài khoản dịch vụ dùng chung quá rộng
• Audit quyền định kỳ

Rủi ro lớn nhất là tin rằng phân quyền đã xong vì giao diện không hiện dữ liệu. Nếu tài khoản kết nối phía sau đọc được cả chuỗi, chỉ cần một câu hỏi khéo hoặc một lỗi ở bước lọc là dữ liệu lọt ra. Tài khoản dịch vụ dùng chung cho nhiều Agent cũng nguy hiểm: một Agent cần thêm quyền là tất cả được mở theo. Kho tài liệu đã lập chỉ mục cũng phải mang theo quyền của tài liệu gốc, nếu không một file chỉ ban giám đốc được xem có thể hiện trong kết quả tìm kiếm của mọi người. Nguyên tắc chung xem thêm ở bài bảo mật dữ liệu khi dùng AI Agent.

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

Bộ phận nhân sự giữ nguồn đúng về vai trò, phòng ban và chi nhánh của từng người, và cập nhật ngay khi có thay đổi. Trưởng các phòng ban quyết định vai trò nào được xem dữ liệu nào, được dùng công cụ nào, và ký xác nhận kết quả rà soát định kỳ. IT cấu hình ma trận quyền, tài khoản dịch vụ, bộ lọc truy vấn và cảnh báo khi có yêu cầu vượt quyền.

An toàn thông tin hoặc kiểm soát nội bộ duyệt quyền tạm thời, kiểm tra log truy cập và xử lý khi phát hiện dữ liệu lọt ngoài phạm vi. Mỗi thay đổi ma trận quyền nên đi qua yêu cầu có người duyệt và chạy lại bộ ca thử phân quyền, giống như thay đổi mã nguồn. Khi có sự cố, người có thẩm quyền phải khóa được riêng công cụ hoặc nguồn dữ liệu liên quan mà không cần tắt toàn bộ Agent.

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

• Tỷ lệ hoàn thành đúng theo tiêu chí đã duyệt
• Tỷ lệ từ chối đúng và chuyển người phụ trách
• Lỗi tích hợp, độ trễ và số thao tác phải sửa
• Chi phí cùng tác động kinh doanh của quy trình

Phân quyền tốt không đo bằng việc Agent trả lời nhiều hay ít. Cần theo dõi số yêu cầu bị từ chối đúng và từ chối nhầm, số quyền tạm thời đã quá hạn mà chưa thu, khoảng thời gian từ lúc nhân viên đổi vị trí đến lúc quyền trên Agent đổi theo, và số truy vấn ngoài phạm vi phát hiện trong log. Tách theo phòng ban và chi nhánh để thấy nơi ma trận quyền đang quá rộng hoặc quá chặt.

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

• 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ò
• Có phương án khi hệ thống lỗi hoặc thiếu dữ liệu
• Có log, phê duyệt và cơ chế chống thao tác trùng
• Có bộ kiểm thử hồi quy và người vận hành

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

Có thể phân quyền AI Agent ngay trên hệ thống hiện có không? Được, nếu hệ thống nguồn đã có vai trò người dùng và dữ liệu đã gắn chi nhánh, phòng ban. Nếu dữ liệu chưa có trường để lọc hoặc nhiều người đang dùng chung một tài khoản, cần xử lý phần đó trước khi nối Agent.

Nên bắt đầu phân quyền AI Agent từ đâu? Bắt đầu từ một phòng ban với vài vai trò rõ ràng và chỉ bật quyền đọc. Khi bộ ca thử vượt quyền đã chạy ổn, mới mở rộng sang chi nhánh khác hoặc bật thao tác ghi.

Khi nào thao tác của AI Agent cần người duyệt dù người dùng đủ quyền? Khi thao tác thay đổi tiền, giá, quyền truy cập, dữ liệu nhân sự hoặc khó hoàn tác. Việc cấp quyền tạm thời vượt phạm vi thường ngày cũng luôn cần người duyệt và có thời hạn.

Có thể phân quyền AI Agent chỉ bằng prompt không? Không nên. Prompt giúp Agent từ chối lịch sự, nhưng quyền phải được áp ở nguồn dữ liệu và ở từng công cụ, để dù mô hình hiểu sai thì dữ liệu ngoài quyền vẫn không tới được nó.

Kết luận

Phân quyền đúng cho AI Agent bắt đầu từ danh tính thật, đi qua vai trò và phạm vi dữ liệu, và kết thúc ở từng công cụ Agent được gọi. Hãy áp quyền ở hệ thống thay vì ở prompt, đọc vai trò từ nguồn nhân sự thay vì chép tay, và kiểm thử bằng chính những câu hỏi cố tình vượt quyền.

Trao đổi với Naventic để khảo sát hệ thống và thiết kế phân quyền cho AI Agent. Đọc thêm: AI Agent nội bộ.