Bài 8 — Tình huống thực tế, vận hành & Quản trị rủi ro AI
Ghép tất cả vào một tình huống end-to-end
Hãy đi qua một tình huống thật để thấy 7 bài trước phối hợp thế nào.
Bối cảnh: Dự án ví điện tử, sprint 12. PO gửi CR-21: "Bổ sung hạn mức chuyển tiền 100 triệu/ngày cho tài khoản chưa định danh eKYC; tài khoản đã eKYC giữ nguyên 500 triệu/ngày."
Bạn làm gì với AI:
- Chuẩn hóa CR (Bài 1): AI diễn giải lại rõ ràng, lộ ra một câu hỏi ẩn — "reset hạn mức theo múi giờ nào, 00:00 VN?" → hỏi PO ngay.
- Impact analysis (Bài 3): AI dò RTM, chỉ ra ảnh hưởng: REQ hạn mức hiện tại, service kiểm tra giao dịch, test hạn mức, báo cáo đối soát, và ripple: cảnh báo chống rửa tiền (AML) có thể liên quan → [SUY ĐOÁN], cần xác minh compliance.
- Phát hiện mâu thuẫn (Bài 4): AI thấy REQ cũ ghi "mọi tài khoản tối đa 500 triệu/ngày" → mâu thuẫn với CR-21 (chưa eKYC chỉ 100 triệu). Phải sửa REQ cũ, không chỉ thêm mới.
- Cập nhật RTM (Bài 7): thêm REQ mới, sửa REQ mâu thuẫn, đánh dấu 3 test cần cập nhật, tăng version.
- Agent (Bài 6) tối hôm đó gửi cảnh báo: "REQ-mới chưa có test case" → nhắc bạn bổ sung trước khi dev bắt đầu.
Vận hành trong đời thực: những va chạm thường gặp
- Dữ liệu bẩn/không đồng nhất: ID lộn xộn, mô tả nửa Anh nửa Việt. Giải: chuẩn hóa trước, đừng bắt AI vừa dịch vừa map vừa đoán cùng lúc.
- Stakeholder không tin AI: đừng nói "AI làm", hãy trình "bản nháp tôi rà soát bằng công cụ hỗ trợ". Trách nhiệm vẫn là bạn.
- Áp lực nhanh: cám dỗ bỏ bước duyệt. Đây là lúc rủi ro cao nhất — càng gấp càng phải giữ điểm kiểm.
Ví dụ prompt "tổng rà soát trước UAT"
Bạn là trợ lý BA. Trước khi vào UAT, hãy kiểm tra sức khỏe traceability của module này.
Dựa trên RTM và danh sách test dưới đây, xuất BÁO CÁO SỨC KHỎE gồm:
- % yêu cầu đã có ít nhất 1 test (coverage).
- Danh sách REQ chưa có test (rủi ro cao).
- Test mồ côi.
- REQ độ ưu tiên cao mà chỉ có 1 test (nên tăng cường).
- Bất kỳ mâu thuẫn còn sót.
Gắn nhãn [CẦN BA XÁC NHẬN] cho mọi kết luận không chắc; không bịa ID.[RTM]
<dán>
[TEST]
<dán>
Các bước xây "thói quen vận hành" bền vững
- Đưa 6-bước SOP (Bài 5) thành mặc định của team, không phải "khi rảnh mới làm".
- Gắn cập nhật RTM vào Definition of Done của mọi CR.
- Duy trì thư viện prompt + danh sách công cụ được duyệt.
- Lịch "health check" traceability trước mỗi UAT/release.
- Theo dõi 2 chỉ số: coverage % và số lỗ hổng tồn đọng — báo cáo cho PO.
- Đánh giá sai số AI định kỳ để biết khi nào tin, khi nào cần siết.
Template Governance (tái dùng)
[AI-TRACEABILITY GOVERNANCE CHECKLIST]
An toàn dữ liệu:
[ ] Chỉ dùng công cụ được duyệt [ ] Ẩn danh PII trước khi dán
[ ] Không nối agent tới nguồn chứa dữ liệu khách chưa được phép
Chất lượng:
[ ] Mọi output AI được BA duyệt trước khi dùng
[ ] Có [SUY ĐOÁN]/[CẦN LÀM RÕ] để tách sự thật khỏi phỏng đoán
[ ] Đánh giá sai số định kỳ (mẫu ngẫu nhiên)
Trách nhiệm:
[ ] Có owner cho RTM [ ] Có decision log [ ] Có version/baseline
Chỉ số theo dõi: coverage=___% lỗ hổng tồn đọng=___
Sai lầm thường gặp (tổng kết cả khóa)
- Ảo giác: AI bịa REQ/ID/quan hệ. Phòng: ép trích nguồn, cấm bịa, tự kiểm mẫu, gắn nhãn suy đoán.
- Rò rỉ dữ liệu: dán tài liệu mật/PII lên tool public, hoặc agent gửi ra ngoài. Phòng: công cụ được duyệt, ẩn danh, khóa phạm vi kênh.
- Phụ thuộc quá mức: để AI "quyết" thay vì "hỗ trợ", bỏ đối thoại với stakeholder, bỏ bước duyệt. Phòng: human-in-the-loop bắt buộc, BA ký duyệt cuối.
- RTM chết: không đưa vào DoD, không quản version. Phòng: quy trình + owner + baseline.
- Trách nhiệm mờ: khi có sự cố, không rõ ai chịu. Phòng: mọi output AI đều có người duyệt đứng tên.