Từ chatbot sang AI Agent: khi nào doanh nghiệp nên nâng cấp?

Một chatbot trả lời câu hỏi. Một AI Agent nhận mục tiêu, chọn bước tiếp theo, gọi công cụ và theo dõi cho tới khi công việc đạt điều kiện hoàn tất hoặc phải bàn giao cho người. Khác biệt quan trọng không nằm ở giao diện chat, mà ở quyền thay đổi trạng thái trong CRM, ERP, ticketing, email hoặc hệ thống nội bộ.

Doanh nghiệp không nên “nâng cấp toàn bộ chatbot” trong một lần. Hãy chọn một quy trình có outcome rõ, giới hạn quyền, thêm approval cho hành động rủi ro và đo tỷ lệ hoàn tất. Nếu nhu cầu chỉ là tra cứu chính sách hay trả lời FAQ, chatbot hoặc retrieval workflow thường đơn giản, rẻ và dễ kiểm soát hơn.

Chatbot truyền thống thường nhận câu hỏi, tìm nội dung và tạo câu trả lời. Nó có thể gọi một API đơn lẻ nhưng không nhất thiết quản lý toàn bộ workflow. AI Agent dùng mô hình để điều phối nhiều bước, chọn tool theo trạng thái, kiểm tra kết quả, thử phương án an toàn khác và dừng khi đạt exit condition.

OpenAI mô tả agent là hệ thống có thể hoàn tất nhiệm vụ thay người dùng, dùng mô hình để quản lý việc thực thi workflow và dùng tool để lấy dữ liệu hoặc hành động trong hệ thống. Ứng dụng chỉ sinh câu trả lời nhưng không điều khiển workflow chưa phải agent theo định nghĩa này. Xem hướng dẫn xây AI Agent.

Vì vậy, hãy mô tả capability bằng động từ cụ thể: “tra cứu trạng thái đơn” khác “đổi địa chỉ giao hàng”; “soạn phản hồi” khác “gửi phản hồi”; “đề xuất hoàn tiền” khác “phê duyệt hoàn tiền”. Mỗi động từ cần scope quyền và bằng chứng hoàn tất riêng.

Bắt đầu bằng một agent đơn với ít tool có tên và schema rõ. Tool đọc và tool ghi phải tách biệt. Input cần validate; output phải có trạng thái thành công, thất bại, lỗi có thể retry và reference ID. Agent không nên coi một câu trả lời tự nhiên là bằng chứng rằng hệ thống đích đã cập nhật.

Thiết lập ba vùng hành động. Vùng xanh gồm tra cứu và tạo bản nháp. Vùng vàng gồm cập nhật có thể đảo ngược hoặc tác động hạn chế, yêu cầu rule kiểm tra. Vùng đỏ gồm thanh toán, xóa dữ liệu, thay đổi quyền hoặc cam kết pháp lý; agent chỉ chuẩn bị hồ sơ và chờ approval.

Agent theo sự kiện còn cần kiểm soát credential. Microsoft cảnh báo event trigger có thể chạy bằng credential của người tạo và yêu cầu kiểm thử trigger trước khi publish; activity page lưu từng bước phản ứng. Xem tài liệu event trigger. Nguyên tắc áp dụng rộng hơn một nền tảng: không dùng tài khoản quyền cao dùng chung cho mọi hành động.

Mức 1 là knowledge chatbot: trả lời từ nguồn đã duyệt và trích dẫn. Mức 2 là copilot: đề xuất bước tiếp theo, điền form hoặc soạn nháp nhưng người dùng bấm xác nhận. Mức 3 là bounded agent: tự thực hiện một workflow hẹp với tool được allowlist và approval theo rủi ro. Mức 4 mới là event-driven agent chạy nền, có queue, SLA, monitoring, kill switch và on-call owner.

Pilot trên dữ liệu thật đã khử nhạy cảm khi cần. Xây evaluation set gồm case bình thường, thiếu dữ liệu, tool timeout, quyền bị từ chối, nội dung độc hại và xung đột chính sách. Chấm cả quyết định chọn tool, tham số, outcome cuối, số bước, chi phí và chất lượng bàn giao.

NIST AI RMF tổ chức quản trị rủi ro theo Govern, Map, Measure và Manage. Với agent, điều đó tương ứng với owner và policy rõ; mô tả use case và tác động; đo lỗi theo outcome; sau đó quản lý incident, thay đổi model/tool và rollback. Xem NIST AI RMF Playbook.

Chatbot có gọi API thì đã là AI Agent chưa?

Chưa chắc. Nếu model không quản lý nhiều bước và không chịu trách nhiệm đưa workflow tới điều kiện hoàn tất, đó có thể chỉ là chatbot có integration.

Có cần multi-agent ngay từ đầu?

Không. Một agent với tool rõ thường dễ đánh giá và vận hành hơn. Chỉ tách khi logic hoặc tool overlap làm hiệu năng giảm.

Agent có nên tự gửi email cho khách?

Chỉ trong scope rủi ro thấp với template, policy check, identity rõ và audit. Trường hợp nhạy cảm nên tạo draft để duyệt.

Khi nào nên dừng pilot?

Khi không đạt threshold chất lượng, không có owner xử lý ngoại lệ, permission chưa đúng hoặc không chứng minh được outcome kinh doanh.