title: "AI Governance: Thiết lập khung quản trị cho LLM và AI Agents trong doanh nghiệp"
series: "TOGAF Mastery: Kiến trúc sư Doanh nghiệp Chuyên sâu"
part: "Phần 4 — Vận hành kiến trúc cấp chuyên gia (Expert Ops)"
order: 36
audience: "Enterprise Architect (EA) & Solutions Architect hướng EA"
reading_time: "13 phút"
tags:

• TOGAF
• AI Governance
• Architecture Governance
• LLM
• AI Agents
• Enterprise Architecture

AI Governance: Thiết lập khung quản trị cho LLM và AI Agents trong doanh nghiệp

Một Chief EA nhận được tin nhắn lúc 9 giờ tối từ Trưởng phòng Chăm sóc khách hàng: "Anh xem giúp em cái này, khách đang chụp màn hình đăng lên mạng xã hội." Ảnh chụp là đoạn hội thoại giữa một khách hàng và chatbot hỗ trợ — con bot, được xây trên nền một mô hình ngôn ngữ lớn (LLM) triển khai chưa đầy hai tháng, đã "cam kết" hoàn tiền 100% cho một đơn hàng ngoài chính sách, kèm một mã giảm giá không hề tồn tại trong hệ thống khuyến mãi. Khách hàng, đương nhiên, cầm đoạn chat đó làm bằng chứng và yêu cầu công ty thực hiện đúng lời "nhân viên" đã hứa.

Trớ trêu ở chỗ: dự án chatbot này không hề thiếu kiến trúc. Nó có API Gateway chuẩn, có logging đầy đủ, có load balancer, có cả một buổi review bảo mật trước khi go-live. Nhưng không tài liệu nào trả lời được câu hỏi cốt lõi: "Con AI Agent này được phép nói gì, hứa gì, làm gì thay mặt công ty — còn cái gì thì tuyệt đối không?" Đây là khoảng trống mà rất nhiều tổ chức đang rơi vào: họ áp trọn bộ kỷ luật kiến trúc truyền thống (uptime, security, scalability) lên một hệ thống AI, nhưng bỏ sót đúng loại rủi ro mà chỉ AI mới tạo ra — rủi ro về nội dung và hành vi tự trị của chính hệ thống đó.

TOGAF, ở phiên bản nền tảng, không có sẵn khung cho loại rủi ro này. Architecture Governance (giai đoạn G và các nguyên tắc quản trị xuyên suốt ADM — Architecture Development Method, phương pháp phát triển kiến trúc theo chu trình lặp của TOGAF) được thiết kế cho một thế giới nơi hệ thống làm đúng những gì được lập trình, không hơn không kém. LLM và AI Agents phá vỡ giả định đó: chúng tạo sinh nội dung không xác định trước (non-deterministic output), và ngày càng được trao quyền hành động thay vì chỉ trả lời. Một EA hiện đại không có lựa chọn nào khác ngoài tự mở rộng khung Architecture Governance để bao trùm rủi ro mới này — không đợi TOGAF ra phiên bản chính thức rồi mới hành động.

Bản chất

AI Governance, trong bối cảnh EA, không phải là một lĩnh vực tách biệt cần một hội đồng riêng, một quy trình riêng chạy song song với Architecture Governance hiện có. Cách tiếp cận đúng — và bền vững hơn về lâu dài — là coi AI Governance như một mở rộng của Architecture Governance: cùng cơ chế kiểm soát (Architecture Review Board, Compliance Review, Architecture Contract) nhưng bổ sung tiêu chí đánh giá đặc thù cho hệ thống có thành phần AI.

Lý do rất thực tế: nếu AI Governance là một quy trình riêng, nó nhanh chóng trở thành "cửa sau" — team dự án chỉ cần gắn nhãn "tính năng AI" là thoát khỏi quy trình Architecture Governance chuẩn, hoặc ngược lại rơi vào một ủy ban mới chậm chạp, không liên thông với governance hiện có. Một EA giỏi thiết kế để mọi hệ thống có thành phần AI — từ tính năng gợi ý sản phẩm đơn giản đến AI Agent xử lý giao dịch — đều đi qua đúng một cửa quản trị kiến trúc, chỉ khác là cửa đó có thêm trạm kiểm tra chuyên biệt.

Ba trục rủi ro cốt lõi mà Architecture Governance truyền thống không có sẵn cơ chế xử lý, và bắt buộc phải bổ sung:

Trục 1 — Kiểm soát dữ liệu đưa ra ngoài (Data Exfiltration Control). Khi một LLM bên thứ ba (API của nhà cung cấp mô hình bên ngoài) được tích hợp vào quy trình nghiệp vụ, mọi prompt gửi đi tiềm ẩn khả năng mang dữ liệu doanh nghiệp — thông tin khách hàng, số liệu tài chính, mã nguồn, bí mật kinh doanh — ra khỏi ranh giới kiểm soát của tổ chức. Đây là rủi ro mà kiến trúc tích hợp truyền thống (gọi API nội bộ qua VPC, qua mạng riêng) không có tiền lệ xử lý, vì bản chất gọi LLM là gửi ngữ cảnh ra một hệ thống mà tổ chức không kiểm soát hạ tầng.

Trục 2 — Đánh giá độ tin cậy và rủi ro "ảo giác" (Hallucination & Reliability Risk). LLM có thể tạo ra nội dung nghe hợp lý nhưng sai sự thật — hiện tượng gọi là "ảo giác" (hallucination). Với tính năng tóm tắt tài liệu nội bộ, hậu quả có thể chỉ là một đoạn văn cần kiểm tra lại. Nhưng với AI Agent được trao quyền hành động thay mặt công ty — trả lời khách hàng, phê duyệt yêu cầu, thực hiện giao dịch — một lần ảo giác có thể thành một cam kết sai lệch mang tính pháp lý hoặc tài chính, không thể thu hồi ngay khi đã phát ra.

Trục 3 — Phân quyền hành động rõ ràng (Action Authorization Boundary). Trục bị bỏ sót nhiều nhất và cũng nguy hiểm nhất: khi AI Agent chuyển từ "trả lời câu hỏi" sang "thực hiện hành động" (gửi email, tạo đơn hàng, hoàn tiền, đổi cấu hình), tổ chức bắt buộc định nghĩa tường minh ranh giới quyền hạn — Agent được làm gì tự động hoàn toàn, việc gì cần con người xác nhận trước (human-in-the-loop), và việc gì tuyệt đối nằm ngoài phạm vi dù người dùng cuối yêu cầu thế nào.

Khung & Kỹ thuật áp dụng

Mở rộng Architecture Governance: thêm cổng kiểm soát AI vào chu trình sẵn có

Thay vì dựng quy trình mới, cách hiệu quả là chèn các tiêu chí AI vào đúng những điểm kiểm soát đã có trong ADM:

Ba lớp kiểm soát dữ liệu đưa vào model bên ngoài

Khung đánh giá độ tin cậy trước khi cho AI Agent tự động hành động

Câu hỏi không phải là "model này có tốt không" mà là "hậu quả nếu model sai ở tình huống này lớn đến đâu". Một ma trận đơn giản, hiệu quả trong thực tế:

Nguyên tắc quan trọng: không Agent nào mặc định ở L2 hay L3 ngay ngày đầu go-live. Mọi Agent bắt đầu ở L0/L1, chỉ nâng mức tự chủ sau khi có dữ liệu vận hành đủ dài để đo tỷ lệ lỗi, không dựa trên cảm giác "model này thông minh".

Bảng phân quyền hành động

Mọi AI Agent trước go-live cần một bảng phân quyền tường minh — không phải mô tả chung chung trong tài liệu thiết kế — liệt kê ba nhóm: được làm tự động, được làm sau xác nhận, và tuyệt đối không được làm dù bị yêu cầu bằng bất kỳ cách diễn đạt nào (kể cả "prompt injection" — cố tình lách chỉ dẫn hệ thống bằng yêu cầu ẩn trong nội dung nhập vào).

Case thực tế minh hoạ

Đây là tình huống minh hoạ điển hình tổng hợp từ các pattern rủi ro AI phổ biến trong triển khai doanh nghiệp, không phải case của một công ty cụ thể, không phản ánh số liệu thật của bất kỳ tổ chức nào.

Một doanh nghiệp dịch vụ triển khai AI Agent để tự động xử lý yêu cầu hỗ trợ khách hàng qua kênh chat, mục tiêu giảm tải cho đội CSKH đang quá tải mùa cao điểm. Dự án được duyệt nhanh vì áp lực kinh doanh: KPI giảm thời gian phản hồi là ưu tiên số một, bài toán được nhìn nhận thuần tuý ở góc độ kỹ thuật tích hợp — nối API nhà cung cấp LLM vào hệ thống ticket hiện có, có logging, có rate limit, đúng chuẩn tích hợp của tổ chức.

Điều không có trong phạm vi thiết kế: một bảng phân quyền hành động rõ ràng cho Agent. Agent được cấu hình với system prompt mô tả chung chung "hỗ trợ khách hàng thân thiện, ưu tiên sự hài lòng" — không có ranh giới cứng nào về việc Agent được và không được cam kết gì thay mặt công ty.

Sự cố xảy ra khi một khách hàng, qua nhiều lượt hội thoại khéo léo, dẫn dắt Agent "xác nhận" một chính sách hoàn tiền 100% không tồn tại, kèm một mã giảm giá bịa ra nghe hợp lý về cú pháp. Agent không "cố tình" nói dối — nó tạo sinh câu trả lời hợp lý nhất dựa trên ngữ cảnh hội thoại, đúng bản chất hiện tượng ảo giác ở LLM. Khách hàng lưu đoạn chat làm bằng chứng, vấn đề leo thang thành tranh chấp công khai trên mạng xã hội, buộc công ty xử lý khủng hoảng truyền thông trong khi vẫn tranh luận nội bộ xem "lời hứa của bot" có ràng buộc pháp lý hay không.

Sau sự cố, tổ chức không gỡ bỏ Agent — bài toán giảm tải CSKH vẫn còn nguyên giá trị — mà thiết lập lại khung AI Governance theo đúng ba trục đã nêu: (1) thông tin đơn hàng/khách hàng gửi vào prompt được lọc qua lớp phân loại dữ liệu, chỉ giữ phần cần thiết; (2) Agent hạ về mức tự chủ L1 — mọi cam kết tài chính (hoàn tiền, giảm giá, đổi trả) phải qua xác nhận của nhân viên trước khi gửi khách, thay vì Agent tự phát ngôn trực tiếp; (3) một bảng phân quyền tường minh được đưa vào system prompt và kiểm thử định kỳ bằng kịch bản cố tình "lách" (adversarial testing). Chi phí khắc phục: một đợt re-design luồng xác nhận và vài tuần kiểm thử bổ sung — thấp hơn nhiều so với chi phí uy tín và rủi ro pháp lý nếu vấn đề lặp lại ở quy mô lớn hơn.

📐 Template/Artifact áp dụng ngay

AI System Governance Checklist — áp dụng cho mọi hệ thống có thành phần LLM/AI Agent trước khi trình Architecture Review Board phê duyệt go-live:

Kết luận đánh giá: ☐ Đạt điều kiện go-live ☐ Đạt có điều kiện (yêu cầu bổ sung, ghi rõ hạng mục) ☐ Chưa đạt — không phê duyệt

🎯 Góc nhìn Chief EA

• Nếu một AI Agent trong tổ chức tôi phát ngôn sai hoặc hành động sai vào lúc 2 giờ sáng, ai là người phải chịu trách nhiệm giải trình — và họ có biết trước điều đó không?
• Tôi có đang áp dụng đúng một cửa Architecture Governance cho hệ thống AI như mọi hệ thống khác, hay đang để nó đi "đường tắt" vì gắn mác đổi mới sáng tạo?
• Mức độ tự chủ hiện tại của từng AI Agent trong tổ chức tôi có được quyết định dựa trên dữ liệu vận hành thực tế, hay dựa trên mức độ "ấn tượng" của demo?
• Nếu phải tắt khẩn cấp một AI Agent ngay bây giờ, tổ chức tôi có cơ chế đó sẵn sàng, hay sẽ phải viết code xử lý sự cố ngay tại chỗ?

🔗 Bài viết liên quan

• Giai đoạn G (Governance): Quy trình kiểm soát kiến trúc tại chỗ — nền tảng Architecture Compliance Review mà AI Governance mở rộng thêm các tiêu chí chuyên biệt.
• Tương lai của EA — bức tranh rộng hơn về cách AI đang định hình lại vai trò của Enterprise Architect trong thập kỷ tới.

Bài trước: DevOps & Architecture · Bài tiếp theo: Vendor Management