AI use case canvas: Cách chọn bài toán AI đáng làm

Mục lục bài viết

AI use case canvas: Cách chọn bài toán AI đáng làm

Vì sao cần canvas trước khi làm AI?

Một sai lầm phổ biến là bắt đầu bằng công cụ. Hôm nay thấy chatbot hay thì muốn làm chatbot. Ngày mai thấy agent gọi API thì muốn làm agent. Tuần sau thấy một demo phân tích Excel thì muốn đưa AI vào toàn bộ báo cáo. Cách bắt đầu này tạo cảm giác nhanh, nhưng rất dễ rơi vào tình trạng demo đẹp mà không ai dùng.

Trong doanh nghiệp, AI không sống một mình. Nó chạm vào dữ liệu, quy trình, quyền truy cập, thói quen người dùng, hệ thống hiện hữu, chính sách bảo mật và cách đo hiệu quả. Vì vậy, triển khai AI không chỉ là chọn model tốt. Nó là bài toán quản trị thay đổi ở quy mô nhỏ hoặc lớn tùy use case.

Cách thực tế hơn là đi từ vấn đề kinh doanh. Việc nào đang tốn thời gian? Việc nào lặp lại? Việc nào có nhiều văn bản, nhiều quyết định nhỏ hoặc nhiều bước kiểm tra? Việc nào nếu AI làm nháp thì con người có thể kiểm soát được? Những câu hỏi này giúp bạn chọn điểm bắt đầu an toàn hơn.

AI use case canvas là một mẫu suy nghĩ có cấu trúc. Nó giúp team không nhảy thẳng từ ý tưởng sang demo. Trước khi hỏi dùng model nào, canvas buộc bạn hỏi: vấn đề là gì, người dùng là ai, dữ liệu ở đâu, rủi ro nào, đo hiệu quả bằng gì và ai chịu trách nhiệm vận hành.

Ô 1: Vấn đề kinh doanh

Hãy mô tả vấn đề bằng ngôn ngữ nghiệp vụ, không phải ngôn ngữ công nghệ. Sai: “Cần dùng LLM để làm chatbot”. Đúng hơn: “Nhân viên mất nhiều thời gian tìm câu trả lời trong SOP và thường hỏi lại IT/BE các câu lặp lại”.

Vấn đề càng cụ thể, giải pháp càng dễ thiết kế. Nếu vấn đề là “năng suất thấp”, quá rộng. Nếu vấn đề là “mỗi tuần team mất 6 giờ tổng hợp phản hồi khách hàng thủ công”, đó là điểm bắt đầu tốt hơn.

Một câu hỏi hữu ích: nếu không dùng AI, chúng ta đang giải quyết vấn đề này bằng cách nào? Nếu hiện tại chưa có quy trình, AI có thể không phải bước đầu tiên.

Ô 2: Người dùng và hành vi hiện tại

AI project thất bại nhiều khi không phải vì model yếu, mà vì người dùng không đổi hành vi. Canvas cần ghi rõ ai dùng hệ thống, họ dùng khi nào, trong công cụ nào, và họ có động lực gì để dùng.

Ví dụ, chatbot tài liệu chỉ hữu ích nếu nhân viên thật sự tìm đến nó trước khi hỏi người khác. Nếu chatbot nằm ở một trang khó nhớ, không tích hợp vào Teams hoặc portal nội bộ, người dùng sẽ quay lại thói quen cũ.

Hãy quan sát hành vi hiện tại: người dùng hỏi qua email, chat, điện thoại, ticket hay gặp trực tiếp? AI nên xuất hiện gần nơi họ đã làm việc, thay vì bắt họ học thêm một cổng mới không cần thiết.

Ô 3: Dữ liệu và nguồn tri thức

Canvas phải ghi rõ dữ liệu nằm ở đâu: SharePoint, file server, database, ticket system, email, Power BI, ERP hoặc tài liệu giấy. Cũng cần biết ai là owner và tần suất cập nhật.

Với LLM và RAG, chất lượng tài liệu quan trọng hơn số lượng. Một bộ SOP 50 trang nhưng mới, rõ owner và có cấu trúc tốt có giá trị hơn 5.000 file cũ không ai quản. Nếu tài liệu mâu thuẫn, AI có thể trả lời mâu thuẫn.

Hãy thêm câu hỏi: dữ liệu này có được phép dùng cho AI không? Có chứa thông tin nhạy cảm không? Có cần ẩn danh không? Có phân quyền theo phòng ban không?

Ô 4: Hành động sau đầu ra AI

Một use case tốt phải có hành động sau khi AI trả lời. Nếu AI dự đoán khách hàng rủi ro cao, ai sẽ gọi khách? Nếu AI phân loại ticket, team nào nhận? Nếu AI tóm tắt họp, ai xác nhận action item?

Nếu không có hành động, AI chỉ tạo thêm thông tin. Doanh nghiệp đã có quá nhiều thông tin rồi. Giá trị nằm ở việc biến thông tin thành quyết định hoặc thao tác cụ thể.

Hãy ghi rõ: đầu ra của AI đi đâu tiếp? Người nào review? Hệ thống nào nhận kết quả? Khi nào xem là hoàn tất?

Ô 5: Rủi ro và guardrail

Canvas cần một phần riêng cho rủi ro: dữ liệu nhạy cảm, hallucination, prompt injection, phân quyền, output handling, chi phí, phụ thuộc vendor, và khả năng người dùng hiểu sai câu trả lời.

Không phải rủi ro nào cũng làm dự án dừng lại. Nhưng rủi ro nào cũng cần biện pháp. Ví dụ: yêu cầu AI trích nguồn, giới hạn phạm vi trả lời, human approval trước khi gửi email, logging, hoặc chỉ cho phép đọc dữ liệu thay vì ghi.

Một use case có giá trị cao nhưng rủi ro cao có thể làm sau. Use case đầu tiên nên có rủi ro vừa phải để team học cách vận hành.

Ô 6: Tiêu chí thành công

Hãy đo bằng chỉ số gần với công việc thật: thời gian tiết kiệm, tỷ lệ câu trả lời đúng nguồn, số ticket giảm, số lần hỏi lại giảm, chất lượng bản nháp, mức hài lòng người dùng, tỷ lệ sử dụng lại.

Tránh chỉ đo số lượt dùng. Một chatbot được hỏi nhiều chưa chắc tốt; có thể vì nó trả lời chưa rõ nên người dùng phải hỏi lại. Hãy đo cả chất lượng và hành động sau đó.

Canvas nên có baseline hiện tại. Nếu không biết trước đây mất bao lâu, rất khó chứng minh AI giúp được gì.

Kết luận

AI use case canvas giúp doanh nghiệp nói chuyện với nhau rõ hơn trước khi đầu tư. Business nhìn được giá trị. IT nhìn được dữ liệu và hệ thống. Security nhìn được rủi ro. Quản lý nhìn được tiêu chí đo.

Một canvas tốt không đảm bảo dự án thành công, nhưng giúp bạn tránh nhiều dự án sai ngay từ đầu. Trong AI, chọn đúng bài toán thường quan trọng hơn chọn đúng model.

Đăng nhận xét