BA/Tester dùng AI viết production code: rủi ro thực sự nằm ở đâu?
AI giúp BA và Tester tạo ứng dụng nhanh hơn, nhưng chạy đúng trên môi trường test chưa đồng nghĩa sẵn sàng cho production. Rủi ro nằm ở năng lực kiểm soát, bảo mật, xử lý sự cố và bảo trì dài hạn.
Một BA có thể mô tả luồng nghỉ phép bằng ngôn ngữ tự nhiên để AI tạo giao diện, API và cơ sở dữ liệu. Một Tester cũng có thể dùng AI để dựng nhanh chức năng phục vụ kiểm thử tích hợp.
Sau vài vòng trao đổi, ứng dụng chạy đúng trên môi trường test.
Nhưng khi người dùng phản ánh: đơn đã được phê duyệt, thông báo đã gửi, nhưng số ngày phép chưa cập nhật — câu hỏi quan trọng không còn là “AI có viết được code không?”.
Mà là: ai biết cần kiểm tra bằng chứng nào để tìm nguyên nhân và khôi phục hệ thống an toàn?
Đó mới là ranh giới thực sự giữa việc tạo ra một phần mềm và chịu trách nhiệm với một phần mềm chạy production.
“Chạy được” chưa chắc đã “vận hành được”
Một chức năng chạy đúng ở môi trường development hoặc test chỉ cho thấy nó đã vượt qua các điều kiện đã được kiểm tra.
Production khác ở chỗ có:
Dữ liệu thật;
Người dùng thật;
Tích hợp với các hệ thống khác;
Tải thực tế;
Những tình huống hiếm khi xuất hiện trong demo hoặc kiểm thử thông thường.
Trong ví dụ đơn nghỉ phép, việc số ngày phép không cập nhật có thể xuất phát từ nhiều tầng khác nhau.
Tầng ứng dụng và nghiệp vụ
API phê duyệt có thực sự hoàn tất thành công không?
Logic cập nhật ngày phép có bị bỏ qua ở một nhánh điều kiện không?
Có lỗi phát sinh nhưng log không đủ để nhận biết không?
Tầng dữ liệu
Transaction có bị rollback không?
Có dữ liệu bị một tiến trình khác ghi đè không?
Có xảy ra cập nhật đồng thời gây sai lệch dữ liệu không?
Tầng tích hợp
Sự kiện phê duyệt có được gửi sang thành phần xử lý tiếp theo không?
Thành phần nhận sự kiện có xử lý thành công không?
Có tình huống xử lý trùng hoặc xử lý dở dang không?
Tầng hạ tầng
Service có bị restart trong lúc xử lý không?
Kết nối cơ sở dữ liệu có bị cạn không?
Có timeout giữa các thành phần hay không?
Người có năng lực kỹ thuật không nhất thiết biết ngay nguyên nhân. Nhưng họ biết cần đặt giả thuyết nào, cần xem log nào và cần đối chiếu dữ liệu ở đâu.
Ngược lại, nếu chỉ hỏi AI: “Hãy sửa lỗi này”, trong khi không có log, dữ liệu liên quan và bối cảnh kiến trúc, bản sửa AI đưa ra vẫn chỉ là một giả thuyết.
> Rủi ro lớn nhất không phải là AI viết sai code. Rủi ro là người triển khai không đủ khả năng đánh giá liệu bản sửa có xử lý nguyên nhân gốc hay chỉ che đi triệu chứng.
BA và Tester nên thay đổi gì khi dùng AI Coding?
BA và Tester không nhất thiết phải trở thành người thay Developer chịu toàn bộ trách nhiệm kỹ thuật.
Vai trò có giá trị hơn là biến các rủi ro mơ hồ thành:
Yêu cầu rõ ràng;
Acceptance criteria có thể kiểm thử;
Câu hỏi đúng cho đội kỹ thuật;
Điều kiện vận hành được xác nhận trước khi triển khai.
Thay vì chỉ hỏi: “Chức năng có chạy không?”, hãy bổ sung câu hỏi: “Nếu chức năng chạy không hoàn tất, hệ thống sẽ thể hiện trạng thái gì và đội ngũ sẽ điều tra bằng cách nào?”
Đưa yêu cầu vận hành vào backlog từ đầu
Một user story chỉ có happy path thường chưa đủ cho production.
Ví dụ, yêu cầu ban đầu là:
> Nhân viên tạo đơn nghỉ phép, quản lý phê duyệt, hệ thống cập nhật số ngày phép và gửi thông báo.
Một đặc tả đầy đủ hơn cần bao gồm các điểm sau.
Luồng nghiệp vụ chính
Nhân viên tạo đơn nghỉ phép.
Quản lý có quyền phê duyệt đơn.
Khi phê duyệt thành công, trạng thái đơn được cập nhật.
Số ngày phép được cập nhật theo quy tắc nghiệp vụ đã xác nhận.
Nhân viên nhận được thông báo phù hợp.
Ngoại lệ cần làm rõ
Nếu trạng thái đơn đã đổi nhưng cập nhật ngày phép thất bại thì hệ thống hiển thị trạng thái nào?
Có cho phép người dùng hoặc quản lý phê duyệt lại không?
Nếu yêu cầu được xử lý trùng thì số ngày phép có bị trừ nhiều lần không?
Nếu gửi thông báo thất bại thì có ảnh hưởng tới kết quả phê duyệt không?
Tiêu chí truy vết và vận hành
Có thể đối chiếu quá trình xử lý theo mã đơn nghỉ phép không?
Lỗi cập nhật ngày phép có được ghi nhận đủ thông tin để điều tra không?
Ai nhận biết khi một bước xử lý thất bại?
Có quy trình khắc phục hoặc xử lý lại phù hợp không?
Tiêu chí phân quyền
Nhân viên chỉ xem được đơn thuộc phạm vi quyền của mình.
Quản lý chỉ thao tác với đơn của nhân viên trong phạm vi được cấp quyền.
Các thao tác phê duyệt, từ chối và xem thông tin đều được kiểm soát quyền ở phía hệ thống.
BA không cần tự quyết định dùng công nghệ nào để xử lý các yêu cầu này. Nhưng BA cần làm rõ điều gì phải đúng khi quy trình không diễn ra trọn vẹn.
Rủi ro bảo mật thường không nằm ở màn hình demo
Một API có thể trả dữ liệu đúng và vẫn không đủ an toàn.
Ví dụ, hệ thống có API xem đơn nghỉ phép theo mã định danh:
GET /api/leave-requests/123
Nhân viên A truy cập đơn của mình thành công. Nhưng nếu họ đổi 123 thành mã đơn của nhân viên B, họ có thể xem được dữ liệu không?
Nếu hệ thống chỉ kiểm tra người dùng đã đăng nhập mà không kiểm tra quyền truy cập trên từng bản ghi, đây có thể là rủi ro Broken Object Level Authorization (BOLA). OWASP API Security Top 10 có đề cập nhóm rủi ro này.
Đây là lý do kiểm thử chức năng thông thường có thể chưa đủ. “API trả dữ liệu đúng” chưa trả lời được câu hỏi quan trọng hơn: API có chỉ trả dữ liệu cho đúng người có quyền hay không?
Ngoài lỗi phân quyền, các nhóm rủi ro cần được xem xét còn gồm:
Lộ API key hoặc thông tin kết nối cơ sở dữ liệu;
Thiếu kiểm soát quyền ở backend;
Upload tệp không được kiểm soát phù hợp;
Thiếu giới hạn request;
Ghi log chứa dữ liệu nhạy cảm;
Xử lý đầu vào không an toàn.
GitHub cũng lưu ý trong tài liệu về sử dụng Copilot rằng nội dung do AI tạo có thể không chính xác hoặc có lỗ hổng, vì vậy vẫn cần được con người kiểm tra và kiểm thử phù hợp.
> Chạy đúng chức năng không đồng nghĩa với đủ an toàn để đưa lên production.
Đừng để AI “vá triệu chứng” thay cho điều tra nguyên nhân gốc
Hãy xét một tình huống minh họa: API hoạt động bình thường khi ít người dùng, nhưng bắt đầu timeout khi lượng truy cập tăng.
Nguyên nhân có thể liên quan đến:
Truy vấn cơ sở dữ liệu chậm;
Thiếu index;
Connection pool không phù hợp;
Tác vụ mất thời gian đang được xử lý đồng bộ;
Rò rỉ bộ nhớ;
Giới hạn tài nguyên của môi trường chạy.
Nếu chỉ đưa thông báo timeout cho AI, một gợi ý dễ xuất hiện là tăng thời gian timeout.
Đó có thể là giải pháp tạm thời trong một số bối cảnh. Nhưng nếu nguyên nhân thật sự là truy vấn chậm hoặc kết nối cơ sở dữ liệu bị cạn, tăng timeout không giải quyết được gốc rễ. Thậm chí, nó có thể giữ tài nguyên lâu hơn.
Khi có sự cố, BA và Tester có thể đóng góp hiệu quả bằng cách chuẩn hóa thông tin đầu vào cho quá trình điều tra:
Triệu chứng người dùng gặp phải là gì?
Ai bị ảnh hưởng?
Sự cố bắt đầu từ thời điểm nào?
Có thay đổi nào gần thời điểm xảy ra lỗi không?
Mã giao dịch, trạng thái xử lý hoặc dữ liệu đối chiếu là gì?
Luồng nghiệp vụ nào bị gián đoạn?
Nếu xử lý sai, tác động đến khách hàng hoặc dữ liệu ra sao?
Nghiên cứu Debugging Incidents in Google's Distributed Systems cho thấy điều tra sự cố trong hệ thống phân tán cần kết hợp công cụ, chiến lược điều tra và kinh nghiệm kỹ thuật. Debugging production vì vậy là một năng lực riêng, không thể đánh đồng với khả năng tạo code.
Phân vai theo mức rủi ro, không theo chức danh
Rủi ro không tự động xuất hiện vì người viết là BA, Tester hay Developer.
Một Developer sử dụng AI nhưng không hiểu code, không kiểm tra bảo mật và không thể điều tra sự cố vẫn có thể tạo ra rủi ro tương tự.
Ngược lại, BA hoặc Tester có nền tảng kỹ thuật, hiểu kiến trúc, đọc được log, phân tích được dữ liệu và phối hợp xử lý incident có thể tham gia sâu hơn vào quá trình phát triển.
Một cách phân vai thực tế hơn là dựa trên mức độ rủi ro.
| Loại công việc | BA/Tester dùng AI | Kiểm soát cần có |
|---|---|---|
| Prototype, PoC, báo cáo | Có thể chủ động thực hiện | Đánh giá trước khi mở rộng phạm vi sử dụng |
| Giao diện, CRUD đơn giản | Có thể tham gia thực hiện | Review phù hợp với mức độ rủi ro |
| Logic nghiệp vụ | Có thể tham gia xây dựng | Review quy tắc nghiệp vụ, transaction và tác động dữ liệu |
| Authentication, authorization | Không nên tự triển khai độc lập nếu thiếu chuyên môn | Security review bắt buộc |
| Tích hợp hệ thống | Có thể tham gia phân tích và xây dựng | Review kiến trúc, timeout, retry và xử lý trùng |
| Triển khai production | Thực hiện theo phân quyền | Kiểm thử, phê duyệt và cơ chế triển khai phù hợp |
| Xử lý sự cố production | Phối hợp phân tích tác động nghiệp vụ | Có người đủ năng lực kỹ thuật chịu trách nhiệm |
Đây là mô hình gợi ý, không phải quy định áp dụng chung cho mọi tổ chức.
DORA 2025 ghi nhận AI có liên hệ tích cực với tốc độ phân phối phần mềm, đồng thời ghi nhận mối liên hệ tiêu cực với độ ổn định khi phân phối. Điểm cần lưu ý không phải là “không nên dùng AI”, mà là: tốc độ tạo code và thay đổi tăng lên thì năng lực kiểm soát thay đổi cũng phải theo kịp.
Checklist trước khi đưa sản phẩm AI-generated lên production
Trước khi triển khai, BA/PO nên cùng người chịu trách nhiệm kỹ thuật trả lời rõ các câu hỏi sau:
Ai chịu trách nhiệm kỹ thuật khi hệ thống xảy ra sự cố?
Ai hiểu kiến trúc, luồng dữ liệu và các thành phần phụ thuộc?
Có log, metrics hoặc cơ chế truy vết phù hợp để điều tra không?
Các luồng nghiệp vụ quan trọng đã có kiểm thử hồi quy tự động hay chưa?
Authentication, authorization và quyền truy cập theo từng bản ghi đã được kiểm tra chưa?
Có phương án rollback khi triển khai lỗi không?
Có backup và đã kiểm tra khả năng khôi phục dữ liệu chưa?
Nếu sự cố xảy ra ngoài giờ, ai có khả năng xử lý?
Có tài liệu cập nhật về luồng nghiệp vụ, tích hợp và trách nhiệm vận hành không?
Ai phê duyệt thay đổi trước khi đưa vào môi trường production?
Nếu chưa trả lời được các câu hỏi này, việc ứng dụng chạy đúng ở môi trường test chưa đủ để khẳng định nó đã sẵn sàng cho production.
Rủi ro dài hạn: bảo trì và technical debt
Một ứng dụng AI-generated có thể chạy tốt trong giai đoạn đầu.
Nhưng sau vài tháng hoặc vài năm, hệ thống thường cần thêm chức năng, thay đổi quy tắc nghiệp vụ, bổ sung tích hợp hoặc mở rộng lượng người dùng.
Nếu mỗi lần thay đổi đều chỉ yêu cầu AI “thêm chức năng” mà thiếu kiểm soát, hệ thống có thể dần gặp các vấn đề như:
Logic nghiệp vụ bị lặp ở nhiều nơi;
Các thành phần phụ thuộc chặt chẽ vào nhau;
Cấu trúc dữ liệu ngày càng khó quản lý;
Một thay đổi nhỏ ảnh hưởng đến nhiều chức năng;
Thiếu kiểm thử hồi quy;
Tài liệu kiến trúc không còn phản ánh đúng hệ thống.
Đó là technical debt.
AI không phải nguyên nhân duy nhất tạo ra technical debt. Phát triển truyền thống cũng có thể tạo ra vấn đề này. Tuy nhiên, khi tốc độ tạo code tăng lên, nợ kỹ thuật cũng có thể tích lũy nhanh hơn nếu thiếu review, kiểm thử và kỷ luật thay đổi.
Kết luận: AI không xóa bỏ trách nhiệm kỹ thuật