Trả lời ngắn: Một AI use case tốt bắt đầu từ business problem và outcome cần cải thiện, không bắt đầu từ model đang hot. Bạn cần viết rõ ai gặp vấn đề, input là gì, AI hỗ trợ bước nào, người duyệt ở đâu, kết quả đo bằng gì và khi nào phải quay về xử lý thủ công.

Đọc xong, bạn sẽ hiểu:

  • Cách phân biệt business problem, use case và solution.
  • Cách viết problem statement có baseline và non-goal.
  • Cách điền use case card từ input đến human decision và evidence.
  • Cách đặt acceptance criteria, fallback và stop gate trước khi thử tool.

Lưu ý giáo dục: Bài này dùng support ticket, content review và invoice giả. Không đưa PII, secrets, token, invoice thật, tiền thật hoặc production prompt vào bài tập. Một use case chưa có owner và acceptance criteria chưa phải kế hoạch production.

1. Problem khác solution và AI use case

Business problem là vấn đề ảnh hưởng một outcome cần cải thiện, không phải tên công nghệ. Use case là một tình huống AI hỗ trợ công việc có scope rõ. Solution là cách triển khai cụ thể. Ba khái niệm này hay bị trộn vào câu “cần một chatbot để xử lý support”.

Hãy đi ngược từ triệu chứng. Một team nói “support trả lời chậm”. Đây có thể là nhiều problem khác nhau: ticket đi sai nhóm, nhân viên phải tìm policy cũ, thiếu thông tin từ đầu hoặc hệ thống approval bị nghẽn. Chatbot chỉ là một solution có thể có, chưa phải kết luận.

Use case hẹp hơn có thể là: “Với ticket giả đã redact, AI đề xuất route billing, technical hoặc NEEDS_REVIEW, nêu lý do ngắn và để nhân viên duyệt trước khi gửi”. Use case này không tự hoàn tiền, không sửa CRM và không hứa rút ngắn thời gian nếu chưa có baseline.

Hình 1 — Đi từ problem và job tới use case có scope, outcome và ranh giới rõ.

Một câu hỏi đời thường hữu ích: nếu không dùng AI, nhân viên đang làm việc gì bằng tay? Giống như đo hàng đợi ở quầy trước khi mua máy mới, hãy hiểu điểm nghẽn trước khi chọn công nghệ.

2. Viết problem statement có thể kiểm

a. Năm mảnh ghép tối thiểu

Một problem statement tốt nói đủ:

  1. Who/when: ai gặp vấn đề và trong thời điểm nào?
  2. Job: họ đang cố hoàn thành công việc gì?
  3. Friction: bước nào chậm, sai, tốn công hoặc thiếu thông tin?
  4. Impact: ảnh hưởng tới outcome nào và đo bằng gì?
  5. Constraint: điều gì không được phép làm, dữ liệu nào bị giới hạn?

Ví dụ còn mơ hồ: “Dùng AI để nâng hiệu suất content”. Bản có thể kiểm hơn là: “Trong bước review bài VI, reviewer mất nhiều thời gian tìm thuật ngữ chưa giải thích. Với draft giả, hệ thống gợi ý các term cần kiểm và link tới đoạn xuất hiện; reviewer vẫn quyết định, không tự publish”.

b. Outcome, baseline và non-goal

Outcome là kết quả business muốn thay đổi; baseline là mức hiện tại để so sánh; non-goal là việc use case cố ý không nhận làm. Ví dụ, baseline là 12 phút review một draft giả, outcome là giảm thời gian tìm lỗi, còn non-goal là chấm chất lượng văn phong thay reviewer.

Đừng viết “nhanh hơn” hoặc “chính xác hơn” mà không có cách đo. Hãy ghi thời gian, tỷ lệ route đúng, tỷ lệ chuyển NEEDS_REVIEW, số lỗi lọt qua và điều kiện của phép đo. Nếu chưa có số thật, dùng baseline giả và đánh dấu cần đo, không biến số giả thành claim.

Microsoft nhấn mạnh prompt tốt cần nói rõ task, context và expected output; cùng logic đó áp dụng khi viết use case: system cần biết mục tiêu, dữ liệu được phép dùng và kết quả thế nào mới được xem là đạt. Microsoft prompt engineering

3. Use case card: input → decision → action

Human-in-the-loop là điểm người tham gia kiểm hoặc quyết định được thiết kế rõ trong workflow. Nó không phải câu “sẽ có người xem lại” đặt ở cuối cho yên tâm. Use case card nên có tám trường:

  • User và trigger: ai khởi động, khi nào?
  • Input và data boundary: nhận gì, cấm gì?
  • AI task: AI phân loại, trích xuất, tìm kiếm hay tóm tắt?
  • Output: format nào, confidence/evidence nào?
  • Human decision: người duyệt điều gì?
  • System action: hành động nào xảy ra sau duyệt?
  • Evidence: lưu run id, source, version hay expected result nào?
  • Fallback/owner: ai xử lý khi AI không chắc hoặc lỗi?

Ví dụ support: input là ticket giả; AI task là route và nêu lý do; output là JSON ba nhãn; human decision là duyệt nhãn; system action chỉ tạo draft route; evidence là run_id và policy version; fallback là queue thủ công; owner là support lead. Với content QA, output là danh sách term/claim cần reviewer kiểm, system action không có quyền publish.

Hình 2 — Card buộc use case nói rõ input, AI task, người quyết định và hành động sau đó.

Research assistant có card khác: AI gom nguồn và draft summary, nhưng không kết luận khi thiếu provenance. Invoice giả có thể dùng AI trích field, nhưng người vẫn duyệt trước khi ghi sổ. Cùng là “AI đọc tài liệu”, nhưng rủi ro và action khác nhau nên boundary cũng khác.

4. Acceptance criteria và ranh giới

Acceptance criteria là điều kiện cụ thể để nhận hoặc từ chối kết quả. Mỗi criteria nên có expected result, failure case, owner và stop action. Ví dụ cho support route:

Tiêu chí Expected Failure case Owner Stop action
Nhãn route Chọn đúng 1/3 route Ticket thiếu dữ liệu QA Chuyển NEEDS_REVIEW
Lý do Nêu field đã dùng Bịa policy Support lead Không gửi draft
Dữ liệu Chỉ đọc field cho phép Lẫn PII ngoài scope Security Redact và dừng
Handoff Có người duyệt Không có owner Operations Giữ queue thủ công
Evidence Có run_id/version Không dựng lại được Platform Không promote

Đây cũng là fallback, tức đường xử lý thay thế khi AI không đạt hoặc không chắc. Fallback không chỉ là thông báo lỗi; nó cần người/queue, dữ liệu bàn giao và điều kiện quay lại. Owner là người chịu trách nhiệm cho quyết định hoặc kiểm soát, không nhất thiết là người viết prompt.

Ranh giới cần viết bằng động từ cụ thể: “chỉ đọc”, “không gửi”, “không ghi”, “cần duyệt”, “dừng khi thiếu nguồn”. NIST AI RMF nhấn mạnh risk management và accountability theo vòng đời; một use case card nên để lộ ai chịu trách nhiệm và evidence nào sẽ được review. NIST AI Risk Management Framework

Hình 3 — Acceptance criteria tốt luôn có failure case, owner và hành động dừng.

5. Sai lầm, giới hạn và khi không nên dùng AI

Sai lầm đầu tiên là AI-washing: gọi mọi vấn đề là cơ hội AI. Nếu rule rõ, input ổn định và xử lý truyền thống rẻ hơn, một function bình thường có thể phù hợp hơn. AI không tự làm outcome tốt hơn chỉ vì output nghe tự nhiên.

Sai lầm thứ hai là automation-first: thiết kế quyền gọi tool trước khi biết người dùng cần quyết định gì. Sai lầm thứ ba là KPI mơ hồ: “tăng hiệu suất” nhưng không có baseline, failure case hoặc người đo. Sai lầm thứ tư là giấu side effect: card nói “tạo draft” nhưng tool thật lại gửi email hoặc ghi database.

Không nên mở AI rộng khi risk/impact chưa rõ, dữ liệu không có quyền sử dụng, expected behavior không viết được, hoặc chưa có owner/fallback. Giữ read-only khi đang học. Dùng NEEDS_REVIEW khi thiếu evidence, ngoài taxonomy hoặc không biết input đến từ đâu. Google Cloud mô tả production AI security cần nhìn application, data và infrastructure cùng các rủi ro như data leakage; use case card chỉ là bước đầu, không thay security review. Google Cloud production AI security

6. Practice Bridge 15 phút

Bắt đầu từ đâu

Mở Google Sheets hoặc notes. Chọn content QA giả: reviewer cần tìm term chưa giải thích và claim chưa có nguồn trong một draft ngắn. Không dùng API key, PII, invoice thật hay production. Điền card: user, trigger, input, AI task, output, human decision, action, evidence, fallback và owner.

Mẫu đối chiếu đã điền

Trường Mẫu giả Điều kiện kiểm
Problem/outcome Tìm term thiếu giải thích trong 10 phút Có baseline 10 phút
Input/boundary Draft VI giả, không PII Chỉ đọc file draft
AI task/output Gợi ý term + đoạn xuất hiện Không tự sửa bài
Human decision Reviewer giữ/sửa/bỏ gợi ý Có owner cụ thể
Acceptance 8/10 gợi ý đúng vị trí Test 2 case sai
Fallback/evidence NEEDS_REVIEW + run_id giả Không có source thì dừng

Hình 4 — Practice card biến business problem thành use case có scope, test và điểm dừng.

Sau 15 phút, chọn một dòng có assumption lớn nhất và viết next test 10 phút. Ví dụ: lấy 3 đoạn giả, đánh dấu term bằng tay, so với gợi ý; nếu vị trí sai, không tăng quyền. Kết quả mong đợi là một card có scope và stop action, không phải tổng điểm AI cao.

7. Tổng kết: chọn đúng bài toán trước khi chọn model

a. Năm ý chính

  • Business problem nói về vấn đề và outcome; AI use case nói về một công việc có scope; solution là cách triển khai.
  • Problem statement cần who, job, friction, impact, constraint, baseline và non-goal.
  • Use case card phải nối input, AI task, output, human decision, action, evidence, fallback và owner.
  • Acceptance criteria cần expected result, failure case, stop action và người chịu trách nhiệm.
  • Khi dữ liệu, risk, owner hoặc evidence chưa rõ, giữ read-only/NEEDS_REVIEW hoặc không dùng AI.

b. Câu hỏi tự kiểm tra

  • “Dùng chatbot cho support” thiếu những mảnh ghép nào?
  • Vì sao output tốt chưa chứng minh outcome business đã cải thiện?
  • Một human-in-the-loop thực sự cần ghi rõ điều gì?
  • Khi nào một rule-based function có thể phù hợp hơn AI?

c. Gợi ý đáp án

Xem gợi ý câu 1

Cần user, trigger, job, input, output, human decision, boundary, owner, acceptance criteria và fallback. Xem lại mục 1 và mục 3.

Xem gợi ý câu 2

Output có thể nghe tốt nhưng chưa có baseline, metric, failure case hoặc evidence về thời gian/chi phí/rủi ro. Xem lại mục 2.

Xem gợi ý câu 3

Cần điểm người kiểm hoặc quyết định, dữ liệu bàn giao, owner và hành động khi AI không chắc; không chỉ một câu “có người xem lại”. Xem lại mục 3 và mục 4.

Xem gợi ý câu 4

Khi rule rõ, input ổn định, rủi ro AI cao hoặc cách truyền thống rẻ và dễ kiểm hơn. Xem lại mục 5.

d. Thuật ngữ cần nhớ

Thuật ngữ Giải thích ngắn
Business problem Vấn đề ảnh hưởng outcome cần cải thiện.
Use case Tình huống AI hỗ trợ một công việc có scope rõ.
Outcome Kết quả business muốn thay đổi.
Baseline Mức hiện tại để so sánh sau thay đổi.
Acceptance criteria Điều kiện nhận hoặc từ chối kết quả.
Human-in-the-loop Người kiểm hoặc quyết định ở điểm được thiết kế.
Fallback Đường xử lý thay thế khi AI không đạt.
Non-goal Việc use case cố ý không nhận làm.
Owner Người chịu trách nhiệm cho quyết định/kiểm soát.

e. Nguồn tham khảo

Bài trước là AI Professional Diagnostic Assessment #6. Bài tiếp theo là Chọn Workflow, Copilot hay Agent #8.

Lưu ý giáo dục: Use case card không thay thế security assessment, evaluation harness hoặc approval của owner. Hãy bắt đầu bằng scope nhỏ, dữ liệu giả, quyền read-only và acceptance criteria có thể kiểm.