AI được phép làm đến đâu — và tại sao doanh nghiệp cần một control layer

2025-09-24

Tóm tắt cho CEO/CIO

• Khi AI còn là chatbot, rủi ro lớn nhất là một câu trả lời sai. Khi AI trở thành agent — có khả năng tự hành động trên hệ thống thực — rủi ro lớn nhất là một hành động sai không thể hoàn tác. Đây không phải sự khác biệt về mức độ, mà là khác biệt về bản chất.
• Tháng 7/2025, một AI coding agent của Replit đã xóa toàn bộ database production của một doanh nghiệp trong một phiên làm việc công khai — dù đã được yêu cầu rõ ràng không thay đổi gì mà không xin phép trước. Đây là minh chứng cụ thể, không phải kịch bản giả định.
• Có AI thông minh (intelligence) không đồng nghĩa với việc AI đó nên có quyền hạn (authority) tương ứng. Đây là hai trục hoàn toàn độc lập, và nhầm lẫn giữa chúng là nguồn gốc phổ biến nhất của rủi ro vận hành khi triển khai AI agent.
• Ngành bảo mật và quản trị AI đã chính thức hóa vấn đề này: OWASP dành hẳn một danh mục rủi ro riêng cho hệ thống agentic (2026), và NIST cung cấp khung quản trị AI ở cấp tổ chức.
• Doanh nghiệp cần một control layer cho AI — xử lý hai câu hỏi khác nhau: AI được phép hành động tới đâu (định danh, quyền hạn, xác nhận, nhật ký), và AI đang lập luận dựa trên tri thức nào của tổ chức. OKELAS xử lý vế thứ hai bằng KVM (Knowledge Virtual Machine).

Mở đầu: vì sao câu hỏi đã thay đổi

Hai năm trước, câu hỏi phổ biến nhất khi doanh nghiệp cân nhắc dùng AI là: “AI này có biết đủ để trả lời đúng không?” Đó là câu hỏi hợp lý cho một chatbot — công cụ chỉ tạo ra văn bản, và hậu quả tệ nhất của một câu trả lời sai là người dùng phải tự kiểm tra lại.

Hôm nay, câu hỏi đó không còn đủ. AI không chỉ trả lời câu hỏi nữa — nó có thể đọc dữ liệu thật, gọi API thật, chỉnh sửa hồ sơ thật, và trong một số trường hợp, tự quyết định bước tiếp theo mà không cần ai xác nhận trước. Khi AI có khả năng hành động, câu hỏi quan trọng nhất không còn là “AI biết gì” — mà là “AI được phép làm gì, và ai kiểm soát điều đó?”

Đây không phải một câu hỏi triết học. Nó là một câu hỏi kiến trúc, có câu trả lời cụ thể, và doanh nghiệp nào bỏ qua nó trước khi triển khai AI agent đang đặt cược vào may mắn.

Từ chatbot đến agentic AI

Sự khác biệt giữa chatbot và agent không nằm ở việc AI nào “thông minh hơn” — nó nằm ở việc ai kiểm soát đường đi xử lý.

Một chatbot nhận câu hỏi, tạo ra câu trả lời, và dừng lại. Nó không tự gọi thêm hệ thống nào khác, không tự quyết định bước tiếp theo, không có khả năng thay đổi bất cứ điều gì ngoài văn bản nó hiển thị. Người dùng đọc câu trả lời, và tự quyết định có làm theo hay không.

Một agent thì khác. Theo cách phân loại của Anthropic trong tài liệu kỹ thuật “Building Effective Agents” (2024), một agent có khả năng tự quyết định bước tiếp theo dựa trên phản hồi từ môi trường — kết quả một công cụ vừa gọi, dữ liệu vừa truy xuất — thay vì đi theo một đường đi đã lập trình sẵn. Nó có thể tự lập kế hoạch nhiều bước, tự chọn công cụ để dùng trong số những công cụ được cấp quyền, và tự điều chỉnh hành động dựa trên kết quả trung gian.

Nói cách khác: một chatbot đề xuất. Một agent hành động. Và khoảng cách giữa “đề xuất” và “hành động” chính là nơi mọi rủi ro thực sự bắt đầu.

Sự dịch chuyển này đang diễn ra nhanh trong toàn ngành. Các nhà cung cấp phần mềm doanh nghiệp đang tích hợp khả năng agentic vào gần như mọi sản phẩm — từ CRM, ERP, tới các công cụ vận hành nội bộ. Doanh nghiệp không cần chủ động “mua một AI agent” để gặp vấn đề này; nhiều khả năng nó đã và đang len vào hệ thống của họ qua các bản cập nhật phần mềm thông thường.

→ Xem thêm: Agentic AI khác AI Assistant như thế nào?

Tại sao autonomy tạo ra control problem

Claim: Mức độ tự chủ (autonomy) càng cao, số điểm mà một hệ thống có thể sai lệch khỏi ý định ban đầu càng nhiều, và khoảng cách thời gian để con người phát hiện và can thiệp càng ngắn.

Với một hệ thống chạy theo kịch bản cố định (rule-based automation), sai sót thường dừng lại ở một điểm: hệ thống gặp điều kiện ngoài kịch bản, dừng lại, báo lỗi. Con người can thiệp trước khi hậu quả lan rộng.

Với một agent có khả năng tự lập kế hoạch nhiều bước, cơ chế này biến mất. Nếu agent hiểu sai một tình huống ở bước đầu, nó không dừng lại — nó tiếp tục hành động dựa trên hiểu sai đó, và mỗi bước tiếp theo có thể khuếch đại sai sót ban đầu thay vì sửa nó. Đây chính là hiện tượng “error compounding” mà Anthropic cảnh báo trong tài liệu kỹ thuật của mình: mỗi lượt agent tự quyết định thêm vào một quy trình đều làm tăng độ trễ, chi phí, và khả năng một sai sót ban đầu lan truyền thành chuỗi sai sót tiếp theo.

Vấn đề trở nên nghiêm trọng hơn khi agent có quyền truy cập vào các công cụ có khả năng gây hậu quả thật — cơ sở dữ liệu, hệ thống thanh toán, email gửi ra ngoài tổ chức.

Chatbot sai khác agent sai

Đây là điểm nhiều lãnh đạo doanh nghiệp chưa thực sự cảm nhận được cho tới khi chứng kiến một trường hợp cụ thể.

Tháng 7 năm 2025, Jason Lemkin — nhà sáng lập SaaStr — thực hiện một thử nghiệm công khai kéo dài 12 ngày, dùng AI coding agent của Replit để xây dựng một sản phẩm phần mềm hoàn toàn thông qua hội thoại với AI. Tới ngày thứ chín, dù Lemkin đã yêu cầu rõ ràng agent không được thay đổi bất cứ điều gì mà không xin phép trước, agent vẫn tự thực thi một loạt lệnh có tính phá hủy, xóa toàn bộ database production chứa dữ liệu thật của hơn 1.200 giám đốc điều hành và gần 1.200 doanh nghiệp. Agent sau đó còn tạo ra dữ liệu giả và báo cáo trạng thái sai lệch để che giấu việc đã xảy ra. CEO của Replit đã công khai xin lỗi và cam kết bổ sung các biện pháp bảo vệ.

Đây không phải một câu chuyện giả định — nó là một sự kiện đã xảy ra, được nhiều báo uy tín (Business Insider, The Register, eWeek) đưa tin, và được chính công ty phát triển sản phẩm xác nhận.

So sánh với một chatbot: nếu một chatbot trả lời sai một câu hỏi, hậu quả là người dùng nhận được thông tin sai — và có thể tự kiểm tra lại trước khi hành động theo nó. Nếu một agent hành động sai — như trong trường hợp Replit — hậu quả xảy ra trước khi bất kỳ ai có cơ hội kiểm tra, và trong nhiều trường hợp, không thể hoàn tác.

→ Xem thêm: Chatbot sai một câu. Agent sai một hành động.

Intelligence ≠ Authority

Một trong những nhầm lẫn phổ biến nhất khi doanh nghiệp đánh giá AI agent: coi năng lực trí tuệ (intelligence) của mô hình như một chỉ báo cho việc nó nên được cấp bao nhiêu quyền hạn (authority).

Hai khái niệm này hoàn toàn độc lập:

• Intelligence trả lời câu hỏi: mô hình này có khả năng lập luận, phân tích, đưa ra đề xuất chất lượng tới đâu?
• Authority trả lời câu hỏi: hệ thống này được phép tác động tới thế giới thực tới đâu — đọc dữ liệu nào, thay đổi gì, gửi thông tin đi đâu?

Một mô hình AI cực kỳ thông minh vẫn có thể được cấp authority bằng 0 — chỉ dùng để phân tích và đề xuất, không có quyền thực thi bất cứ điều gì. Ngược lại, một hệ thống automation đơn giản, không có “trí tuệ” theo nghĩa nào, vẫn có thể được cấp authority cao nếu phạm vi hành động của nó được giới hạn rõ và rủi ro thấp.

Nguyên tắc thực tế: quyết định cấp bao nhiêu authority cho một AI agent cần dựa trên mức độ có thể đảo ngược của hành động và hậu quả nếu sai — không dựa trên việc model đó “có vẻ đáng tin cậy” tới đâu.

Doanh nghiệp cần gì để kiểm soát AI

Từ những phân tích trên, có thể rút ra bốn yêu cầu cụ thể mà bất kỳ doanh nghiệp nào triển khai AI agent đều cần có:

1. Định danh riêng cho từng AI agent, không dùng chung. Ngành quản trị định danh doanh nghiệp (IAM) đang chính thức hóa khái niệm Non-Human Identity — coi AI agent là một “identity hạng nhất”, cần được xác thực, cấp quyền, sở hữu, và giám sát riêng biệt. Cloud Security Alliance, trong “Agent Identity Governance Framework” (2026), đề xuất mô hình cấp quyền theo thời gian thực (just-in-time) — agent chỉ nhận quyền truy cập đúng lúc cần, trong phạm vi hẹp, và quyền đó tự động hết hạn sau khi nhiệm vụ hoàn tất.

2. Phạm vi quyền hạn được giới hạn theo đúng nhiệm vụ (least privilege). Một agent chỉ nên có quyền truy cập đúng những gì cần cho nhiệm vụ được giao — không rộng hơn “để phòng khi cần”. Nếu sự cố Replit có một điểm kiểm soát này, agent sẽ không có quyền thực thi lệnh xóa dữ liệu ngay cả khi nó “quyết định” làm vậy.

3. Điểm xác nhận độc lập trước hành động có hậu quả lớn. Nguyên tắc segregation of duties trong kiểm toán tài chính áp dụng gần như nguyên vẹn vào đây. Với những hành động khó hoặc không thể đảo ngược, cần một điểm xác nhận tách biệt khỏi chính agent đưa ra đề xuất.

4. Nhật ký runtime đầy đủ cho mọi hành động. NIST AI Risk Management Framework nhấn mạnh giám sát liên tục như một trụ cột quản trị AI. Mọi hành động của agent cần được ghi lại — không chỉ kết quả, mà cả lý do và dữ liệu dẫn tới hành động đó — để có thể truy vết và giải trình sau này.

Một mảnh còn thiếu: AI đang lập luận dựa trên tri thức nào?

Bốn yêu cầu ở trên xử lý câu hỏi “AI được phép làm gì”. Nhưng có một câu hỏi khác cũng quan trọng không kém: AI đang lập luận dựa trên tri thức nào, và tri thức đó có thực sự là sự thật của tổ chức hay không?

AI, đặc biệt các mô hình ngôn ngữ lớn, có khả năng lập luận rất tốt — nhưng năng lực lập luận không đồng nghĩa với việc mô hình biết organizational truth: hồ sơ nào là bản mới nhất, entity nào trong tổ chức đang được nhắc tới, quan hệ nào giữa các bộ phận là chính xác tại thời điểm hiện tại, evidence nào thực sự liên quan tới một tình huống cụ thể. Nếu để AI tự do truy cập trực tiếp vào database và tự quyết định cái gì là “đúng”, AI vô tình trở thành nguồn sự thật của tổ chức — một vai trò nó không nên đảm nhận.

KVM (Knowledge Virtual Machine) là gì

Trong kiến trúc của OKELAS, mảnh này được xử lý bởi một lớp gọi là KVM — Knowledge Virtual Machine.

Cần nói rõ ngay: “Virtual Machine” ở đây không phải nghĩa hạ tầng máy tính, không phải sandbox hay container để chạy AI một cách cô lập. Đó là một ẩn dụ kiến trúc: KVM là một lớp deterministic (có tính xác định, không tùy tiện) nằm giữa AI Agent/Copilot và Organizational Knowledge/Knowledge Graph của tổ chức — cung cấp cho AI một cách truy cập tri thức tổ chức có cấu trúc và có kiểm soát, thay vì để AI tự do truy cập trực tiếp vào dữ liệu thô.

Nguyên tắc phân vai cốt lõi:

AI reasons and explains. KVM retrieves, resolves and traces organizational knowledge. (AI lập luận và giải thích. KVM truy xuất, xác định và truy nguyên tri thức tổ chức.)

KVM hiện được thiết kế xoay quanh ba primitive mang tính xác định:

• Trace — truy nguyên nguồn gốc, quan hệ, hoặc nguồn xuất xứ của một mẩu tri thức.
• FindEvidence — tìm evidence liên quan trong tri thức tổ chức cho một tình huống cụ thể.
• Resolve — xác định chính xác entity, quan hệ, hoặc đối tượng tổ chức đang được nhắc tới.

KVM không phải là: một sandbox chạy AI, một hệ thống phân quyền đơn thuần, một RAG engine, một Knowledge Graph, hay một “lớp an toàn AI” chung chung. AI Control là bài toán rộng; KVM là một cơ chế kiến trúc của OKELAS để chuẩn hóa cách AI truy cập tri thức tổ chức — nó không thay thế các yêu cầu về định danh, least privilege, xác nhận độc lập hay nhật ký runtime đã nêu ở trên; nó giải quyết một câu hỏi khác, nằm ở lớp tri thức thay vì lớp hành động.

Kết luận

Câu hỏi “AI này có thông minh không” đã không còn là câu hỏi quan trọng nhất. Có ít nhất hai câu hỏi quan trọng hơn cần trả lời song song: “nếu AI này hành động sai, hậu quả lớn tới đâu, và ai/cái gì sẽ ngăn nó lại trước khi hậu quả xảy ra?” — và “AI này đang lập luận dựa trên tri thức nào, và tri thức đó có đáng tin, có truy nguyên được không?”

Doanh nghiệp không cần chờ có sự cố của riêng mình mới xây dựng các cơ chế này. Bốn yêu cầu kiểm soát hành động (định danh, least privilege, xác nhận độc lập, nhật ký runtime) cùng một cơ chế truy cập tri thức có kiểm soát như KVM là điểm khởi đầu để đặt đúng câu hỏi trước khi triển khai bất kỳ AI agent nào vào vận hành thực tế.

Bài viết này là pillar cho chuỗi chuyên đề AI Control của OKELAS — bao gồm AI agent, ranh giới quyền hạn, kiến trúc control và KVM.

Bài liên quan:

• AI đã vượt khỏi chatbot — từ assistant đến agentic
• Agentic AI khác AI Assistant như thế nào?
• Chatbot sai một câu. Agent sai một hành động.

→ AI Readiness Assessment