AI Knowledge Base: Quản Trị Cấp Toàn Tổ Chức

Level: L9 — AI Business Operating System (Bài 5/12, bài 93 Blueprint V1)

1. Mục tiêu học tập

Sau bài này, bạn có thể:

• Giải thích vì sao quản trị cấp workspace (bài 28) không đủ khi tổ chức mở rộng lên hàng trăm người, nhiều phòng ban.
• Mô tả mô hình “custom roles” — vùng chứa quyền hạn gán theo nhóm, thay vì gán từng người.
• Áp dụng mô hình quyền cộng dồn (additive) khi 1 người thuộc nhiều nhóm.
• Thiết kế 1 cấu trúc phân quyền sơ bộ cho tổ chức nhiều phòng ban (chuẩn bị trực tiếp cho bài 94-97).

2. Khái niệm cốt lõi

AI Knowledge Base Governance cấp tổ chức là hệ thống kiểm soát ai được truy cập tri thức/công cụ AI nào, áp dụng xuyên suốt nhiều team, không phải từng Project riêng lẻ. Đơn vị quản trị cơ bản không còn là “1 Project” (bài 28) mà là “vai trò” (role) — 1 vùng chứa quyền hạn được gán cho nhóm người, không phải từng cá nhân [S117].

Theo Anthropic, thành viên được gán vai trò “Custom” không tự động kế thừa năng lực đã bật ở cấp tổ chức — “mọi năng lực 1 thành viên có vai trò Custom cần dùng phải được cấp tường minh qua 1 custom role gán cho ít nhất 1 nhóm của họ” [S117]. Đây là khác biệt cốt lõi so với quản trị thủ công từng Project ở bài 28: mặc định không có quyền, chỉ có quyền khi được cấp tường minh qua vai trò.

3. Tại sao nội dung này quan trọng

Khi tổ chức chỉ có vài chục người, quản trị từng Project (bài 28) vẫn khả thi. Nhưng khi tổ chức có hàng trăm người, chia thành nhiều phòng ban (Sales, Marketing, Customer Success…) mỗi phòng cần truy cập công cụ/connector khác nhau — quản trị thủ công từng người trở nên bất khả thi và dễ sai sót (cấp thừa quyền, quên thu hồi khi đổi vai trò). Đây chính là hạ tầng governance mà bài 94-97 (4 “OS” theo phòng ban) cần có sẵn trước khi triển khai — nếu không có tầng này, mỗi phòng ban sẽ tự phát minh cách quản trị riêng, không nhất quán.

4. Cơ chế hoạt động — 4 thành phần của mô hình RBAC [S117]

4.1 Custom Roles — vùng chứa quyền hạn

Role không gán trực tiếp cho người — gán cho nhóm (group). 1 người thuộc 1 hoặc nhiều nhóm, mỗi nhóm có thể có 1 role khác nhau.

4.2 Các thành phần kiểm soát được

Loại	Ví dụ cụ thể
Tính năng/năng lực	Chat, Cowork, Claude Code, Web Search, Memory, Projects, Code Execution
Connector — 4 mức	“Always allow” (luôn dùng được) / “Needs approval” (cần xác nhận mỗi lần) / “Blocked” (ẩn hoàn toàn) / “Custom” (kiểm soát từng tool riêng lẻ)
Quyền admin (uỷ quyền không cần cấp Owner)	Identity & Access, Billing, Analytics, Privacy, User Management, Libraries
Model	Giới hạn model được dùng, giới hạn mức “effort” theo từng role

4.3 Mô hình quyền cộng dồn (additive)

Nếu 1 người thuộc nhiều nhóm với role khác nhau, quyền là hợp của tất cả role trong chuỗi — “nếu bất kỳ role nào trong chuỗi cấp 1 tính năng, người đó có tính năng đó; không thể dùng 1 role để gỡ quyền đã được role khác cấp” [S117]. Khi có xung đột, thiết lập cho phép nhiều hơn luôn thắng.

4.4 Đồng bộ danh tính (SCIM)

Cho phép tự động đồng bộ nhóm từ nhà cung cấp danh tính (Okta, Entra ID) qua 2 cơ chế: (1) ánh xạ nhóm IdP → role tự động, (2) đồng bộ nhóm IdP vào hệ thống để gán role thủ công sau. Tổ chức có thể kết hợp nhóm tạo thủ công và nhóm đồng bộ SCIM cùng lúc.

5. Diagram

Sơ đồ đề xuất: Lưới ma trận Role × Phòng ban (Sales/Marketing/ Customer Success/Operations) × Tính năng — mỗi ô thể hiện mức quyền (Always allow/Needs approval/Blocked), minh hoạ tính cộng dồn khi 1 người thuộc 2 nhóm.

6. Hướng dẫn từng bước

1. Xác định các nhóm cần có theo cấu trúc tổ chức (thường theo phòng ban — chuẩn bị trực tiếp cho bài 94-97).
2. Với mỗi nhóm, xác định custom role: tính năng nào được phép, mức quyền connector nào (mục 4.2).
3. Xác định quyền admin cần uỷ quyền — không cấp Owner cho tất cả người cần quản lý 1 phần (ví dụ chỉ cần quyền Billing, không cần toàn quyền).
4. Kiểm tra xung đột cộng dồn — nếu 1 người thuộc nhiều nhóm, xác nhận kết quả cộng dồn có đúng ý định không (mục 4.3).
5. Thiết lập đồng bộ SCIM nếu tổ chức đã có identity provider (mục 4.4) — tránh quản lý nhóm thủ công khi quy mô lớn.

7. Ví dụ thực tế

Áp dụng cho công ty B2B SaaS giả định (~40 người, case study xuyên suốt Level 9): thiết kế 3 nhóm — Sales (được phép connector CRM ở mức “Always allow”, Claude Code ở mức “Blocked”), Marketing (được phép Web Search + connector mạng xã hội, Claude Code “Blocked”), Engineering (Claude Code “Always allow”, connector CRM “Blocked” — không cần truy cập dữ liệu khách hàng). 1 Trưởng phòng Sales kiêm quản lý Marketing sẽ thuộc cả 2 nhóm — theo mô hình cộng dồn, người này có quyền của cả 2 role, không phải chỉ 1 trong 2.

8. Prompt/Template

Nhóm: ___________
Tính năng được phép: ___________
Mức quyền connector: [ ] Always allow [ ] Needs approval [ ] Blocked [ ] Custom
Quyền admin uỷ quyền (nếu có): ___________
Model/effort giới hạn: ___________

9. Bài tập thực hành

Hình 9.5 — AI Knowledge Base Governance: ma trận Role × Phòng ban × Tính năng, quyền cộng dồn.

10. Checklist

• Giải thích được vì sao quản trị cấp workspace (bài 28) không đủ ở quy mô tổ chức.
• Mô tả được 4 thành phần kiểm soát được qua custom role.
• Áp dụng được mô hình quyền cộng dồn cho 1 người thuộc nhiều nhóm.
• Phân biệt rõ bài này với bài 28 — không nhầm lẫn 2 cấp độ.

11. Lỗi thường gặp

Đặt lại checklist

• Tôi đã hiểu khái niệm cốt lõi của bài học AI Knowledge Base: Quản Trị Cấp Toàn Tổ Chức.

12. Giới hạn & khi nào KHÔNG áp dụng

• Bài này mô tả cơ chế RBAC của Claude Enterprise cụ thể làm ví dụ minh hoạ cho 1 nguyên tắc phổ quát hơn: bất kỳ hệ thống AI cấp tổ chức nào cũng cần kiểm soát truy cập theo nhóm, không theo từng cá nhân, khi vượt quá vài chục người. Nếu tổ chức bạn dùng công cụ AI khác, tên gọi cụ thể (role/group/connector) có thể khác, nhưng nguyên tắc cộng dồn/phân quyền theo nhóm vẫn áp dụng được.
• Không dạy lại cơ chế Public/Private/archive của bài 28 — chỉ dẫn chiếu.
• Không đi sâu kỹ thuật triển khai SSO/SCIM (thuộc phạm vi đội IT/bảo mật, không phải phạm vi giáo trình này).

13. An toàn & quản trị (Safety/Governance)

Nguyên tắc quan trọng nhất: quyền admin (Identity & Access) nên “chỉ dành cho quản trị viên bảo mật/IT đáng tin cậy” [S117] — đây là quyền mạnh nhất (có thể tạo/sửa role khác), không nên uỷ quyền tràn lan. Ngoài ra, thay đổi role có thể mất tới 15 phút để có hiệu lực — không giả định thay đổi có tác dụng ngay lập tức khi xử lý tình huống khẩn cấp (ví dụ thu hồi quyền của 1 người vừa nghỉ việc).

14. Best practices

1. Thiết kế nhóm theo cấu trúc tổ chức thật (phòng ban), không theo cá nhân.
2. Luôn kiểm tra “hiệu lực thực tế” khi 1 người thuộc nhiều nhóm (mục 11).
3. Dùng quyền admin uỷ quyền cụ thể thay vì cấp Owner tràn lan (mục 13).
4. Kết hợp SCIM nếu tổ chức đã có identity provider — giảm quản lý thủ công khi quy mô lớn (mục 4.4).

15. Nội dung nâng cao

Cấu trúc role thiết kế ở bài này là hạ tầng governance bắt buộc trước khi triển khai bài 94-97 — mỗi “OS” theo phòng ban (Sales/ Marketing/Customer Success/Operations) sẽ áp dụng đúng mô hình role/ connector-permission đã học ở đây cho công cụ/dữ liệu riêng của phòng ban đó, không thiết kế lại từ đầu.

16. Nguồn tham khảo (không bắt buộc)

[S117] Set up role-based permissions on Enterprise plans, Claude Help Center (Anthropic) — nguồn mới, Tier 1, cập nhật “hơn 1 tuần trước” tại thời điểm truy cập. Dẫn chiếu (không trích dẫn mới): bài 28 (S71, S72 — quản trị cấp workspace), bài 94-97 (áp dụng mô hình role cho từng phòng ban).

17. Ngày kiểm chứng

2026-07-13. Cơ chế RBAC (custom role, mô hình cộng dồn, SCIM) đã kiểm chứng qua nguồn Tier 1. Chi tiết UI/tên gọi cụ thể có thể đổi theo phiên bản sản phẩm — nguyên tắc cộng dồn/phân quyền theo nhóm bền vững hơn chi tiết implementation.