Kiến thức / Tài chính – Ngân hàng – Bảo hiểm / Tài chính / NH / Bảo hiểm

AI Agent cho Tư vấn tín dụng: bản đồ use case

AI Agent cho Tư vấn tín dụng: bản đồ công việc, dữ liệu và giới hạn

Tình huống thật khi ý tưởng nhiều hơn use case tốt

Trong buổi rà soát công việc, nhóm Tư vấn tín dụng đưa ra nhiều ý tưởng: đọc tin Zalo, tóm tắt ghi chú cuộc gọi, đặt lại tên tệp, rà danh sách chứng từ, soạn câu hỏi bổ sung và nhắc hồ sơ đang chờ. Dữ liệu nằm ở CRM nội bộ, Google Sheets, email, Messenger và một số tài liệu kế toán trên MISA. Nếu chỉ nhìn số giờ thao tác, đội rất dễ chọn việc có nhiều dữ liệu nhạy cảm hoặc cần quyền vượt quá phạm vi thử nghiệm.

Bản đồ AI Agent cho Tư vấn tín dụng không xử lý hồ sơ cụ thể. Nó giúp nhóm tách nhiệm vụ, xác định nguồn, mức kiểm tra được, tác động khi sai, người duyệt và quyền tối thiểu. Kết quả là danh mục PILOT, CHỜ_CHUẨN_HÓA hoặc KHÔNG_GIAO_AI. Agent chỉ hỗ trợ chuẩn bị, đối chiếu sự hiện diện của tài liệu và tạo DRAFT/REVIEW. Mọi quyết định nghiệp vụ thuộc người có thẩm quyền theo quy trình của đơn vị.

Việc có thể giao cho AI và ranh giới công việc

Ứng viên phù hợp gồm chuẩn hóa tên tệp, tách trường từ biểu mẫu, nhóm tài liệu theo checklist, phát hiện trường trống, tóm tắt nội dung có dẫn nguồn, tạo danh sách câu hỏi và soạn tin nháp theo trạng thái đã được chuyên viên xác nhận. Đây là những việc có đầu vào nhận diện được, đầu ra so sánh với nguồn và lỗi có thể đưa về REVIEW. Bắt đầu từ một bước nhỏ giúp đội đo được phần người duyệt phải sửa.

Không giao Agent quyền thay đổi chính sách, xác minh tính thật giả của tài liệu, suy diễn thông tin tài chính, xếp hạng khách hàng, cập nhật trạng thái nghiệp vụ cuối hoặc gửi nội dung khi chưa duyệt. Một use case rộng như “xử lý hồ sơ” phải tách thành các phần hẹp: nhận tệp, đối chiếu checklist, tạo câu hỏi và lưu bản nháp. Permission boundary ghi rõ quyền READ, CREATE_DRAFT và SUGGEST; quyền ghi, gửi hoặc phê duyệt nằm ngoài pilot mặc định.

Dữ liệu cần chuẩn bị để đánh giá use case

Mỗi use case cần data card gồm tên nguồn, owner, schema, phiên bản checklist, thời điểm cập nhật, loại dữ liệu, mức nhạy cảm, quyền đọc, thời hạn lưu và cách kiểm tra. Bộ mẫu chỉ dùng mã DEMO, không dùng tên, số điện thoại, số giấy tờ hoặc tài khoản có hình thức giống dữ liệu thật. Tệp phải có source_id và trạng thái như RECEIVED, UNREADABLE hoặc NEEDS_REVIEW.

Độ sẵn sàng được đo bằng bằng chứng: tỷ lệ trường có schema, số tệp mở được, số bản ghi trùng, số nguồn mâu thuẫn và khả năng truy ngược. Có nhiều tệp không đồng nghĩa dữ liệu tốt. Nếu checklist chưa có phiên bản, owner chưa rõ hoặc đường dẫn mở công khai, use case chuyển CHỜ_CHUẨN_HÓA. Dữ liệu từ MISA chỉ được dùng theo phạm vi tổ chức cho phép; tin nhắn Zalo hay Messenger không thay thế hồ sơ nguồn chính.

Workflow sáu bước chọn use case và kiểm soát

Bước 1 — Kiểm kê nhiệm vụ: ghi kích hoạt, đầu vào, đầu ra, tần suất và owner. Bước 2 — Đánh giá khả năng kiểm tra: chỉ ra schema, checklist, câu nguồn hoặc người xác nhận. Bước 3 — Lập data card: kiểm tra owner, phiên bản, độ đầy đủ, quyền và thời hạn lưu. Use case thiếu một trong các phần này chưa vào pilot.

Bước 4 — Lập ma trận kiểm soát: ghi sự cố có thể xảy ra, tác động, cách phát hiện, điểm dừng và owner xử lý. Bước 5 — Vẽ permission boundary: tách đọc, tạo nháp, đề xuất, ghi và gửi; chọn quyền thấp nhất. Bước 6 — Lập pilot charter: ghi bộ dữ liệu DEMO, số mẫu, người duyệt, tiêu chí đạt, ngưỡng dừng và rollback. Đây là workflow chọn use case, không phải luồng nhận và nhắc hồ sơ.

Quy trình chọn use case AI cho Tư vấn tín dụng theo dữ liệu kiểm soát và quyền — Quy trình minh họa dùng để chọn pilot; không xử lý hoặc thay đổi trạng thái hồ sơ.

Năm prompt mẫu cho workshop chọn use case

Prompt 1 tạo inventory nhiệm vụ. Prompt 2 đánh giá data readiness. Prompt 3 lập ma trận kiểm soát use case. Prompt 4 vẽ permission boundary. Prompt 5 tạo pilot charter và tiêu chí dừng. Năm prompt không tóm tắt hồ sơ, không lập danh sách chứng từ thiếu, không soạn tin chăm sóc và không tạo hàng đợi; các nhiệm vụ đó thuộc bài prompt-pack riêng.

Kết quả prompt là tài liệu workshop, không phải quyết định tự động. Mỗi dòng phải có nguồn và người xác nhận. Nếu Agent tự gán owner, tự xem một nguồn là hợp lệ hoặc điền trường chưa biết, người duyệt trả lại. Sử dụng ví dụ DEMO, không chép PII. Sau workshop, chủ quy trình, chủ dữ liệu, IT và tuân thủ cùng xác nhận trạng thái use case.

Công cụ phù hợp để lập bản đồ

Google Sheets đủ cho inventory use case; mỗi hàng có mã, mục tiêu, nguồn, owner, quyền, kiểm soát và quyết định. Base.vn có thể quản lý action item của workshop. MISA chỉ được liệt kê như một nguồn cần chủ dữ liệu xác nhận, chưa cần kết nối. Zalo và Messenger chỉ dùng để phối hợp lịch, không chứa nội dung mẫu nhạy cảm của pilot.

Nhóm có thể dùng whiteboard để vẽ data flow, RACI để phân vai và risk register vận hành để theo dõi kiểm soát. Không đưa ảnh chứng từ vào công cụ thiết kế. Link trong inventory chỉ trỏ tới kho nội bộ có quyền. Tên use case dùng động từ cùng đầu ra, như “gắn nhãn loại tài liệu theo checklist”, thay vì tên rộng “AI xét hồ sơ”.

Ma trận use case Tư vấn tín dụng theo dữ liệu khả năng kiểm tra và quyền — Ma trận minh họa sử dụng dữ liệu DEMO; không phải đánh giá khách hàng hay sản phẩm.

AI làm gì và người duyệt làm gì

AI chuẩn hóa mô tả nhiệm vụ, tổng hợp data card, chỉ ra trường thiếu và trình bày ma trận nhất quán. Agent có thể đề xuất câu hỏi workshop, nhưng không xác nhận quyền, không chọn use case thay nhóm và không tự mở kết nối. Mọi nhãn PILOT hoặc CHỜ chỉ là đề xuất DRAFT cho hội đồng nội bộ xem xét.

Chuyên viên mô tả công việc thật; chủ quy trình xác nhận đầu ra; chủ dữ liệu xác nhận nguồn; IT xác nhận quyền; tuân thủ rà dữ liệu; lãnh đạo bộ phận quyết định pilot. Người có thẩm quyền nghiệp vụ giữ toàn bộ quyết định liên quan hồ sơ. Nếu use case bị hoãn, nhóm ghi điều kiện cần hoàn thiện thay vì sửa điểm để đưa vào thử nghiệm.

Sai lầm và rủi ro cần tránh

Sai lầm đầu tiên là chọn use case theo số giờ mà bỏ qua dữ liệu và quyền. Sai lầm thứ hai là coi một file Sheet là nguồn chuẩn chỉ vì dễ truy cập. Sai lầm thứ ba là dùng PII thật trong demo hoặc đặt mã giả có cấu trúc giống số giấy tờ. Sai lầm thứ tư là trộn việc chuẩn bị tài liệu với quyết định nghiệp vụ trong cùng một use case.

Ma trận kiểm soát phải tập trung vào vận hành Agent: lẫn hồ sơ, lộ dữ liệu, dùng checklist cũ, gửi nhầm người, ghi trùng và thiếu log. Với mỗi sự cố, ghi cách phát hiện và owner. Không dùng Agent để suy diễn nội dung thiếu. Khi chưa có cách phục hồi hoặc thu hồi quyền, use case không vào pilot. Quyền gửi luôn tắt trong giai đoạn bản đồ.

Triển khai cá nhân, đội và tổ chức

Cá nhân kiểm kê mười việc, chọn ba ứng viên và thu thập bộ mẫu DEMO. Đội nhỏ tổ chức workshop với nghiệp vụ, IT và chủ dữ liệu, kết thúc bằng một pilot hẹp. Mỗi tiêu chí phải có bằng chứng, không dùng nhận xét chung như “dữ liệu khá sạch”.

Tổ chức duy trì registry use case có mã, owner, nguồn, quyền, trạng thái, phiên bản, kiểm soát và ngày rà lại. Pilot chạy trong môi trường tách biệt, chỉ READ/CREATE_DRAFT, có người duyệt mọi đầu ra. Theo dõi lỗi lẫn mã, thiếu nguồn, trường tự điền và thời gian kiểm tra. Chỉ thiết kế workflow tiếp nhận sau khi charter được duyệt.

Kết quả đầu ra mẫu và câu hỏi thường gặp

Kết quả minh họa: UC-TD-DEMO-04 “gắn nhãn tài liệu theo checklist”; dữ liệu: 18 bộ tệp DEMO; quyền READ và CREATE_DRAFT; kiểm soát: source_id, checklist version, reviewer; trạng thái PILOT_PROPOSED; dừng khi lẫn source_id hoặc xuất hiện dữ liệu ngoài nguồn.

Use case nào nên được xem trước?

Chọn việc hẹp, đầu ra kiểm tra được, ít quyền và chỉ tạo DRAFT/REVIEW.

Có thể dùng dữ liệu thật trong workshop không?

Không cần. Dùng dữ liệu DEMO hoặc đã ẩn theo chính sách và không tạo định danh giả giống thật.

Permission boundary nên bắt đầu ở đâu?

Bắt đầu với READ và CREATE_DRAFT; mọi quyền ghi, gửi hoặc phê duyệt để ngoài pilot mặc định.

Ai quyết định use case được thử?

Chủ quy trình, chủ dữ liệu, IT, tuân thủ và lãnh đạo bộ phận xác nhận theo vai trò của họ.

Nếu cần điều phối workshop, hãy liên hệ NganAds tại trang tư vấn hoặc số 0983543063.

Workflow

Bước 1: Kiểm kê nhiệm vụ — Tách việc theo kích hoạt, đầu vào, đầu ra, tần suất và owner.
Bước 2: Đánh giá khả năng kiểm tra — Xác định schema, checklist, câu nguồn hoặc reviewer dùng để đối chiếu.
Bước 3: Lập data card — Kiểm tra owner, phiên bản, độ đầy đủ, quyền, thời hạn lưu và bộ DEMO.
Bước 4: Lập ma trận kiểm soát — Ghi sự cố vận hành, dấu hiệu, tác động, điểm dừng, owner và phục hồi.
Bước 5: Vẽ ranh giới quyền — Tách đọc, tạo nháp, đề xuất, ghi và gửi; chọn quyền thấp nhất.
Bước 6: Lập và duyệt pilot charter — Ghi phạm vi, dữ liệu DEMO, reviewer, tiêu chí, stop condition và rollback.

Prompt mẫu

Lập inventory use case

MỤC TIÊU: Chuyển danh sách việc Tư vấn tín dụng thành inventory use case có phạm vi rõ.
[ĐẦU VÀO]: Việc, kích hoạt, tần suất, đầu vào, đầu ra, owner, reviewer và lỗi thường gặp.
ĐỊNH DẠNG ĐẦU RA: Bảng mã, động từ–đầu ra, nguồn, tiêu chí kiểm tra, owner, quyền dự kiến và câu hỏi thiếu; không trộn quyết định nghiệp vụ vào tác vụ hỗ trợ.
VÍ DỤ ĐIỀN SẴN: Gắn nhãn loại tệp theo checklist; 40 bộ DEMO/tháng; nguồn thư mục nội bộ; chuyên viên duyệt.

Đánh giá data readiness

MỤC TIÊU: Kiểm tra mức sẵn sàng dữ liệu cho một use case nội bộ.
[ĐẦU VÀO]: Nguồn, owner, schema, checklist version, số mẫu DEMO, trường trống, tệp lỗi, bản ghi trùng, quyền và thời hạn lưu.
ĐỊNH DẠNG ĐẦU RA: Data card gồm READY/NEEDS_WORK, bằng chứng, khoảng trống, việc chuẩn hóa, người xác nhận và ngày rà lại; không tự xác nhận nguồn.
VÍ DỤ ĐIỀN SẴN: 18 bộ DEMO; 16 tệp mở được; 2 tệp thiếu source_id; checklist TD-DOC-v3.

Lập ma trận kiểm soát use case

MỤC TIÊU: Xác định sự cố vận hành và kiểm soát cho use case AI.
[ĐẦU VÀO]: Mục tiêu, dữ liệu, đầu ra, hệ thống, tác động khi sai, kiểm soát hiện có, owner và cách phục hồi.
ĐỊNH DẠNG ĐẦU RA: Bảng sự cố, dấu hiệu, tác động, kiểm soát phòng ngừa, kiểm soát phát hiện, điểm dừng, owner và residual note; thiếu owner chuyển REVIEW.
VÍ DỤ ĐIỀN SẴN: Lẫn source_id giữa hai bộ DEMO; phát hiện bằng đối chiếu manifest; dừng lô và thu hồi bản nháp.

Vẽ permission boundary

MỤC TIÊU: Xác định quyền tối thiểu cho use case theo vai trò.
[ĐẦU VÀO]: Nguồn, hệ thống, vai trò, hành động đọc/tạo nháp/đề xuất/ghi/gửi, dữ liệu nhạy cảm và người phê duyệt quyền.
ĐỊNH DẠNG ĐẦU RA: Ma trận role–resource–action, quyền cho phép, quyền cấm, thời hạn, log, cách thu hồi và reviewer.
VÍ DỤ ĐIỀN SẴN: Agent chỉ READ thư mục DEMO và CREATE_DRAFT trong vùng staging; không ghi CRM, không gửi tin.

Tạo pilot charter

MỤC TIÊU: Soạn charter thử nghiệm sau khi use case, dữ liệu và quyền đã được review.
[ĐẦU VÀO]: Use case, bộ DEMO, phạm vi, owner, reviewer, quyền, tiêu chí đạt, ngưỡng dừng, log, lịch review và rollback.
ĐỊNH DẠNG ĐẦU RA: Mục tiêu, ngoài phạm vi, dữ liệu, vai trò, checklist chạy, tiêu chí, stop condition, rollback và chữ ký cần có.
VÍ DỤ ĐIỀN SẴN: UC-TD-DEMO-04; 18 bộ; chỉ tạo nhãn DRAFT; dừng khi lẫn mã nguồn hoặc tự điền trường.

Câu hỏi thường gặp

Use case nào nên được xem trước?

Chọn việc hẹp, đầu ra kiểm tra được, ít quyền và chỉ tạo DRAFT/REVIEW.

Có thể dùng dữ liệu thật trong workshop không?

Không cần; dùng dữ liệu DEMO hoặc đã ẩn theo chính sách, không tạo định danh giả giống thật.

Permission boundary nên bắt đầu ở đâu?

Bắt đầu với READ và CREATE_DRAFT; quyền ghi, gửi hoặc phê duyệt nằm ngoài pilot mặc định.

Ai quyết định use case được thử?

Chủ quy trình, chủ dữ liệu, IT, tuân thủ và lãnh đạo xác nhận theo vai trò.

Bài liên quan

Muốn cài AI Agent cá nhân 499K (support 7 ngày)? Inbox / Zalo 0983543063.