AI không còn chỉ biết trả lời

Khoảng vài năm trước, khi nhắc đến ChatGPT hay các mô hình ngôn ngữ lớn (LLM), hầu hết chúng ta đều nghĩ đến một chatbot.

Bạn hỏi.

Nó trả lời.

Cuộc hội thoại kết thúc.

Mọi thứ dừng lại sau vài trăm token được sinh ra.

Nhưng chỉ trong một thời gian rất ngắn, AI đã thay đổi vai trò của mình.

Ngày nay, một AI Agent có thể đọc email, tìm kiếm tài liệu nội bộ, truy cập CRM, tạo Jira Ticket, gửi Slack, mở Pull Request, đặt lịch họp, kiểm tra tồn kho, tạo đơn hàng, thậm chí gọi thêm nhiều AI Agent khác để hoàn thành một công việc lớn hơn.

AI không còn chỉ trả lời.

AI bắt đầu hành động.

Và chính thời điểm đó, mình nhận ra một câu hỏi tưởng như rất nhỏ lại trở thành nền móng của toàn bộ hệ thống.

AI này… thực sự là ai?

Nghe có vẻ kỳ lạ.

Một mô hình AI thì cần gì danh tính?

Nhưng nếu suy nghĩ thêm vài phút, bạn sẽ thấy đây có lẽ là một trong những bài toán thú vị nhất của AI trong doanh nghiệp hiện nay.

Một nhân viên mới không có khuôn mặt

Hãy tưởng tượng công ty bạn tuyển một nhân viên mới.

Ngày đầu tiên đi làm, bạn sẽ cấp cho họ những gì?

• Email công ty
• Thẻ nhân viên
• Tài khoản đăng nhập
• Quyền truy cập hệ thống
• Máy tính
• Phòng ban
• Chức vụ

Không ai đưa ngay cho họ chìa khóa mở toàn bộ tòa nhà.

Không ai cấp quyền root vào hệ thống ERP.

Không ai phát tài khoản CEO để “cho tiện”.

Bởi vì doanh nghiệp luôn hoạt động dựa trên một nguyên tắc rất đơn giản.

Muốn làm việc thì trước hết phải có danh tính.

Điều thú vị là khi triển khai AI Agent, rất nhiều doanh nghiệp lại vô tình bỏ qua nguyên tắc đó.

Agent được cấu hình bằng một API Key dùng chung.

Hoặc Access Token của người lập trình.

Hoặc một Service Account có quyền Administrator.

Mọi thứ vẫn chạy.

Cho đến khi xảy ra sự cố.

Một ví dụ rất đời thường

Giả sử bạn xây dựng một Agent giúp bộ phận bán hàng.

Mỗi buổi sáng, Agent sẽ:

• đọc CRM
• kiểm tra doanh số
• xem tồn kho
• gửi báo cáo cho trưởng vùng

Một tháng sau, mọi người bắt đầu thấy Agent làm việc khá tốt.

Thế là yêu cầu tiếp tục được bổ sung.

Nếu tồn kho dưới 10 thì tạo Purchase Order.

Nếu khách VIP gọi thì tạo voucher.

Nếu doanh thu giảm thì gửi cảnh báo.

Nếu phát hiện đơn hàng bất thường thì khóa giao dịch.

Nếu hết hàng thì tạo Ticket cho kho.

Từng chút một, Agent bắt đầu có quyền ghi dữ liệu.

Có quyền thay đổi hệ thống.

Có quyền ra quyết định.

Lúc này, sếp bất ngờ hỏi một câu rất đơn giản.

Hôm qua ai gửi email cho hơn ba nghìn khách hàng?

Bạn mở log.

Kết quả hiện lên.

1
2phamduytung

Nhưng bạn không hề gửi.

Agent gửi.

Thế thì log đã nói dối.

Hay chính hệ thống không còn biết ai là người thực hiện hành động đó?

API Key là giải pháp của ngày hôm qua

Rất nhiều hệ thống AI hiện nay vẫn hoạt động theo cách khá quen thuộc.

1
2LLM
3↓
4API Key
5↓
6CRM

Đơn giản.

Nhanh.

Ít phải cấu hình.

Nhưng mô hình này chỉ phù hợp khi AI là một đoạn script nhỏ.

Khi Agent bắt đầu tương tác với hàng chục hệ thống khác nhau, một API Key dùng chung trở thành quả bom hẹn giờ.

Nếu Agent bị khai thác?

Nếu khóa API bị lộ?

Nếu có nhiều Agent cùng sử dụng một tài khoản?

Nếu một Agent chỉ nên xem dữ liệu nhưng lại có quyền xóa?

Nếu cần thu hồi quyền của một Agent?

Không có câu trả lời nào thật sự đẹp.

Đó không còn là vấn đề của AI.

Đó là bài toán của Identity.

Điều mình thích nhất khi tìm hiểu về AI Agent

Có một thay đổi rất nhỏ trong cách suy nghĩ nhưng lại làm mình nhớ rất lâu.

Trước đây mình luôn hình dung hệ thống chỉ có hai loại đối tượng.

1
2Human User
3
4Service Account

Sau này mình nhận ra còn một loại nữa.

 1
 2Human User
 3
 4Service
 5
 6Batch Job
 7
 8Cron Job
 9
10CI/CD
11
12AI Agent

AI Agent không phải là người.

Cũng không phải một service thông thường.

Nó là một thực thể mới.

Có khả năng tự lập kế hoạch.

Có khả năng đưa ra quyết định.

Có khả năng gọi công cụ.

Có khả năng thực hiện hành động.

Nếu đã có khả năng hành động, Agent cũng cần được quản lý giống như mọi thực thể khác trong doanh nghiệp.

Đó là lúc Identity xuất hiện.

Identity khác Authentication như thế nào?

Nhiều người thường nhầm lẫn hai khái niệm này.

Identity trả lời câu hỏi:

Bạn là ai?

Authentication trả lời:

Bạn chứng minh điều đó bằng cách nào?

Authorization lại trả lời:

Bạn được phép làm gì?

Ba khái niệm này tồn tại từ rất lâu trước khi AI xuất hiện.

Điều AI làm chỉ là khiến mọi thứ trở nên khó hơn.

Bởi vì giờ đây không chỉ có hàng nghìn nhân viên.

Mà còn có hàng nghìn Agent cùng hoạt động.

AI không cần quyền lớn

Có một sai lầm mình thấy khá phổ biến.

Vì muốn triển khai nhanh.

Người ta thường cấp cho Agent quyền Administrator.

Lý do rất đơn giản.

“Khỏi lỗi.”

Nhưng trong bảo mật, câu này cực kỳ nguy hiểm.

Một Agent chỉ đọc báo cáo thì không nên có quyền ghi dữ liệu.

Một Agent gửi email thì không nên truy cập hệ thống thanh toán.

Một Agent phân tích log thì không nên sửa cấu hình Kubernetes.

Nguyên tắc Least Privilege vẫn đúng.

Dù người dùng là con người hay AI.

Từ chatbot đến một công ty AI

Có lẽ hình ảnh dưới đây mô tả đúng nhất tương lai của AI Agent.

         User
           │
           ▼
  Planning Agent
   /     |      \
  /      |       \

 1
 2Search Agent  Finance  Email
 3│           │        │
 4▼           ▼        ▼
 5Vector DB       ERP     Exchange
 6│           │        │
 7└───────────┴────────┘
 8│
 9▼
10Approval Agent
11│
12▼
13Payment

Lúc này, hệ thống không còn có một AI.

Mà có cả một tổ chức.

Mỗi Agent giống một nhân viên.

Có nhiệm vụ.

Có phòng ban.

Có quyền hạn.

Có trách nhiệm.

Điều thú vị là kiến trúc của AI bắt đầu giống… kiến trúc của doanh nghiệp.

MCP khiến bài toán này trở nên cấp bách

Model Context Protocol (MCP) mở ra một cách chuẩn hóa để AI gọi công cụ.

Điều này rất tuyệt.

Một Agent có thể kết nối tới hàng chục dịch vụ chỉ bằng cùng một giao thức.

Nhưng càng nhiều công cụ, câu hỏi về danh tính càng trở nên quan trọng.

Nếu tất cả MCP Server đều tin vào cùng một API Key.

Thì toàn bộ hệ thống chỉ còn một lớp bảo vệ duy nhất.

Giống như phát cho mọi nhân viên trong công ty cùng một chiếc chìa khóa.

Đó không phải kiến trúc có thể mở rộng.

Một MCP Gateway tốt không chỉ chuyển tiếp request.

Nó còn phải biết Agent nào đang gọi.

Được phép gọi công cụ nào.

Trong điều kiện nào.

Và toàn bộ hành động đó cần được ghi nhận để có thể kiểm toán sau này.

Điều mình học được

Trước đây mình luôn nghĩ AI sẽ thay đổi doanh nghiệp nhờ mô hình mạnh hơn.

Nhiều tham số hơn.

Reasoning tốt hơn.

Sau một thời gian đọc khá nhiều bài chia sẻ về kiến trúc hệ thống, mình lại có cảm giác khác.

Model chỉ là phần nổi.

Phần chìm của tảng băng mới là thứ quyết định AI có thể đi vào doanh nghiệp hay không.

Đó là:

• Identity
• OAuth
• OIDC
• RBAC
• ABAC
• Vault
• KMS
• Audit Log
• Policy Engine
• Observability
• Compliance

Có khi hàng trăm nghìn dòng code không nhằm làm AI thông minh hơn.

Chúng chỉ để đảm bảo AI không làm sai.

Tổng kết

Có một câu hỏi mình rất thích.

Nếu AI vừa xóa một cơ sở dữ liệu sản xuất, chúng ta có biết chính xác Agent nào đã làm, vì sao nó có quyền làm việc đó và làm thế nào để ngăn điều tương tự xảy ra lần nữa?

Nếu câu trả lời là “không”, thì vấn đề không nằm ở mô hình ngôn ngữ.

Vấn đề nằm ở kiến trúc.

Theo mình, vài năm tới, khả năng cạnh tranh của các hệ thống AI trong doanh nghiệp sẽ không chỉ đến từ mô hình mạnh nhất hay reasoning tốt nhất. Thứ tạo nên khác biệt sẽ là cách chúng ta quản lý hàng nghìn AI Agent giống như quản lý hàng nghìn nhân viên: mỗi Agent có một danh tính riêng, quyền hạn riêng và chịu trách nhiệm cho mọi hành động của mình.

Đó cũng là điều khiến mình tâm đắc nhất khi tìm hiểu về chủ đề này. AI càng tiến gần đến vai trò của một đồng nghiệp, câu hỏi quan trọng nhất sẽ không còn là “AI biết gì?”, mà sẽ là “AI là ai?”.

Tham khảo

• Uber Engineering – Solving the Identity Crisis for AI Agents
• OAuth 2.1 Draft Specification
• OpenID Connect Core 1.0
• Model Context Protocol (MCP) Specification
• NIST SP 800-207 – Zero Trust Architecture