BA/PO đưa rủi ro AI vào user story trước khi phải “chữa cháy”
Theo Thoughtworks, rủi ro AI được quyết định từ lúc chọn dữ liệu, kiến trúc, nhà cung cấp và mức tự chủ của agent. BA/PO có thể biến các câu hỏi này thành yêu cầu, acceptance criteria và checklist rõ ràng.
Một tính năng AI có thể bắt đầu bằng một yêu cầu rất ngắn: “Tóm tắt lịch sử tương tác và hỗ trợ nhân viên xử lý yêu cầu khách hàng.”
Nhưng trước khi đưa vào sprint, BA/PO cần làm rõ những câu hỏi khó hơn: AI được đọc dữ liệu nào? Có được gọi sang hệ thống nghiệp vụ không? Ai phê duyệt hành động? Dữ liệu có còn trong vector database hoặc bộ nhớ agent sau khi khách hàng yêu cầu xóa?
Theo Thoughtworks, các quyết định về dữ liệu, kiến trúc, nhà cung cấp và mức tự chủ của AI thường được đưa ra từ giai đoạn discovery, thiết kế kiến trúc và lựa chọn vendor — trước khi bộ phận pháp chế hoặc tuân thủ tham gia sâu.
Vì vậy, yêu cầu sản phẩm không chỉ cần mô tả AI làm gì, mà còn phải nêu AI được phép làm đến đâu và được kiểm soát như thế nào.
Rủi ro AI là quyết định sản phẩm, không chỉ là việc của pháp chế
Thoughtworks cho rằng trách nhiệm khi AI hoặc AI agent gặp sự cố trong môi trường vận hành đang dịch chuyển nhiều hơn về phía lãnh đạo sản phẩm. Lý do là những lựa chọn tạo ra mức độ rủi ro đã được chốt từ sớm: dữ liệu đầu vào, mức tự động hóa, kiến trúc tích hợp và nhà cung cấp.
Bài viết cũng nêu rằng, theo EU AI Act, mức phạt đối với thực hành bị cấm có thể lên tới 35 triệu euro hoặc 7% doanh thu toàn cầu; với phần lớn nghĩa vụ khác, mức phạt có thể lên tới 15 triệu euro hoặc 3% doanh thu toàn cầu.
Nếu hệ thống AI xử lý dữ liệu cá nhân, một sự cố có thể đồng thời liên quan đến EU AI Act và GDPR. Thoughtworks lưu ý tổ chức cần đánh giá mức độ phơi nhiễm theo từng khuôn khổ áp dụng.
Điều này không có nghĩa BA/PO phải tự diễn giải luật. Vai trò của BA/PO là biến vùng rủi ro thành:
câu hỏi cần được trả lời;
quyết định có chủ sở hữu;
yêu cầu phi chức năng;
acceptance criteria có thể kiểm tra.
Một user story AI thiếu ràng buộc về dữ liệu, quyền hành động và khả năng truy vết cũng giống một story thanh toán không có điều kiện xử lý lỗi: có thể demo được, nhưng chưa đủ để vận hành đáng tin cậy.
Bốn câu hỏi cần có trong discovery và refinement
BA/PO có thể tạo một mục AI risk assumptions trong Epic hoặc tài liệu Confluence. Khi refinement, hãy đưa các câu hỏi dưới đây vào trao đổi với tech lead, data owner, security và legal/compliance khi cần.
1. Tổ chức đang là controller, processor, provider hay deployer?
Thoughtworks phân biệt bốn vai trò:
Controller: quyết định vì sao và cách dữ liệu cá nhân được sử dụng.
Processor: xử lý dữ liệu thay mặt khách hàng, theo chỉ dẫn của khách hàng.
Provider: xây dựng AI và phát hành dưới tên của mình.
Deployer: sử dụng AI của bên khác.
Việc dùng một công cụ AI bên thứ ba nội bộ thường gắn với vai trò deployer. Tuy nhiên, nếu tổ chức tích hợp AI vào sản phẩm và phát hành dưới tên của mình, tổ chức đó nhìn chung có thể là provider, kể cả khi mô hình nền tảng đến từ nhà cung cấp khác.
Thoughtworks cũng lưu ý rằng việc sửa đổi đáng kể hệ thống hoặc đổi mục đích sử dụng sang trường hợp rủi ro cao có thể làm thay đổi trách nhiệm.
BA/PO nên ghi rõ trong feature:
Tính năng được phát hành dưới tên ai?
Dữ liệu nào được xử lý và thuộc về ai?
Ai quyết định mục đích sử dụng dữ liệu?
Điều gì có thể làm thay đổi vai trò của tổ chức?
2. Feature có mức rủi ro nào?
Theo Thoughtworks, không nên gán một nhãn chung như “chatbot” cho toàn bộ sản phẩm. Mỗi feature AI cần được xem xét riêng theo vai trò và nhóm rủi ro liên quan.
Rủi ro có thể tăng khi feature:
dùng dữ liệu khách hàng cho mục tiêu riêng của tổ chức, như phân tích, cải thiện sản phẩm hoặc huấn luyện mô hình;
quyết định dữ liệu được lưu trong bao lâu hoặc chia sẻ cho ai;
xử lý dữ liệu nhạy cảm như dữ liệu sức khỏe, sinh trắc học hoặc dữ liệu trẻ em;
theo dõi con người trên quy mô lớn.
Các trường nên có trong feature assessment:
Dữ liệu đầu vào gồm những loại nào?
Có sử dụng dữ liệu cho mục đích thứ cấp không?
Dữ liệu được lưu trong bao lâu và ai nhận dữ liệu?
Có dữ liệu nhạy cảm hoặc hoạt động theo dõi quy mô lớn không?
Ai xác nhận việc đánh giá và thời điểm xác nhận?
3. AI chỉ đề xuất hay được quyền hành động?
AI tóm tắt hoặc soạn thảo nội dung có một hồ sơ rủi ro khác với agent có thể thực hiện chuỗi hành động qua nhiều hệ thống.
Thoughtworks nhận định agent thường xử lý theo “happy path”. Nếu không được thiết kế rõ ràng, agent sẽ không tự nhận biết ranh giới bảo mật, yêu cầu đồng thuận hay ràng buộc tuân thủ.
BA/PO cần mô tả ranh giới bằng ngôn ngữ nghiệp vụ:
AI được đọc, soạn, đề xuất hay thực thi?
Hành động nào có tác động cao hoặc khó đảo ngược?
Ai phải phê duyệt trước khi hành động xảy ra?
Agent dùng loại credential nào và trong bao lâu?
Có thể chứng minh agent đã làm gì và bằng cách nào không?
4. Dữ liệu có được xóa trên toàn bộ vòng đời AI không?
Thoughtworks lưu ý rằng xóa bản ghi trong cơ sở dữ liệu quan hệ chưa chắc đã đáp ứng đầy đủ yêu cầu xóa dữ liệu nếu thông tin vẫn còn trong embedding vector, bộ nhớ agent hoặc trọng số mô hình.
Bài viết đề xuất duy trì data bill of materials có phiên bản để theo dõi nguồn gốc và đường đi của dữ liệu trong toàn bộ vòng đời AI.
Với BA/PO, acceptance criteria không nên chỉ ghi:
> Xóa hồ sơ khách hàng thành công.
Cần làm rõ thêm:
Phạm vi dữ liệu phái sinh cần được rà soát.
Nơi dữ liệu có thể tồn tại sau xử lý.
Bằng chứng thực hiện xóa hoặc xử lý theo chính sách.
Người chịu trách nhiệm xác nhận.
Ví dụ: chuyển rủi ro thành user story
Giả sử một trợ lý AI tóm tắt yêu cầu khóa thẻ từ lịch sử chat, sau đó đề xuất thao tác cho nhân viên. Nhân viên có thể xác nhận để gửi lệnh sang hệ thống thẻ.
Điểm cần chốt không phải chỉ là chất lượng bản tóm tắt. Đội cần làm rõ AI có được tự gửi lệnh hay không, ai phê duyệt và log nào được lưu.
User story minh họa:
> Là nhân viên hỗ trợ, tôi muốn nhận bản tóm tắt và đề xuất khóa thẻ từ AI để xử lý yêu cầu nhanh hơn, nhưng chỉ gửi lệnh khóa sau khi tôi xem và xác nhận.
Acceptance criteria minh họa:
text
Given AI đã tạo đề xuất khóa thẻ
When nhân viên chưa xác nhận
Then hệ thống không gửi lệnh sang hệ thống thẻ
Given nhân viên xác nhận đề xuất
When hệ thống gửi lệnh khóa thẻ
Then hệ thống lưu định danh agent, người phê duyệt, thời điểm
và payload lệnh đã thực thi
Given dữ liệu được chuẩn bị để gửi cho AI
When dữ liệu rời khỏi ranh giới tin cậy của hệ thống
Then dữ liệu nhạy cảm được xử lý theo cơ chế đã được phê duyệt
Ví dụ này phản ánh các cơ chế mà Thoughtworks đề cập: giới hạn quyền của agent, phê duyệt của con người cho hành động tác động cao và lưu dấu vết rõ ràng cho hành động đã thực hiện.
“Có log” chưa phải là một yêu cầu đủ rõ
Thoughtworks cho rằng chain-of-thought hoặc reasoning trace nội bộ của mô hình không phải là bản ghi kiểm toán đáng tin cậy.
Thay vì ghi chung chung rằng “hệ thống phải có audit log”, BA/PO nên yêu cầu một audit schema rõ ràng. Theo bài viết, bản ghi này cần gắn được:
ngữ cảnh đồng thuận của người dùng;
định danh agent duy nhất;
payload công cụ chính xác đã được thực thi.
Trong BPMN hoặc flow nghiệp vụ, nên thể hiện riêng:
Điểm lấy dữ liệu và bước lọc dữ liệu.
Agent phân tích hoặc đề xuất hành động.
Gateway phê duyệt của con người cho hành động tác động cao.
Tool call sang hệ thống nghiệp vụ.
Bước ghi audit và xử lý thất bại.
Luồng xử lý xóa dữ liệu, bao gồm dữ liệu phái sinh cần rà soát.
Những câu hỏi BA/PO nên đưa vào trao đổi kiến trúc
Thoughtworks đề xuất các cơ chế như credential ngắn hạn, giới hạn theo tác vụ cho từng sub-agent và tool invocation; đồng thời tránh để agent kế thừa token OAuth người dùng có quyền rộng và tồn tại dài hạn.
Bài viết cũng khuyến nghị tách ranh giới ngữ cảnh. System prompt, dữ liệu RAG và input người dùng có thể cùng đi vào context window; vì vậy cần xem xét cơ chế lọc dữ liệu nhạy cảm trước khi payload rời khỏi ranh giới tin cậy, cũng như lọc tenant-ID chặt chẽ trong vector index và agent cache.
BA/PO không cần quyết định giải pháp kỹ thuật, nhưng có thể hỏi:
Agent có dùng credential giới hạn theo tác vụ và thời hạn không?
Hành động nào bắt buộc phải có human-in-the-loop?
Dữ liệu nhạy cảm được lọc ở điểm nào?
Tenant-ID được kiểm soát ở đâu trong vector store và cache?
Cơ chế xóa có bao gồm embedding, agent memory và dữ liệu phái sinh không?
Cách review đầu ra AI và yêu cầu AI
Dù AI được dùng để hỗ trợ soạn story hay tổng hợp workshop, BA/PO vẫn cần kiểm tra ba lỗi phổ biến.
Thiếu yêu cầu: Có nêu “cần phê duyệt” nhưng không nêu ai phê duyệt, vào lúc nào và hành động nào bị chặn.
Mơ hồ: Các cụm như “bảo mật dữ liệu”, “log đầy đủ” hoặc “xóa hoàn toàn” không chỉ ra phạm vi, cơ chế và bằng chứng.
Mâu thuẫn: Story nói AI chỉ đề xuất, nhưng flow lại cho phép tool call tự động; hoặc nói không lưu dữ liệu nhưng không đề cập cache, embedding hay agent memory.
Trong meeting notes, nên ghi rõ:
quyết định đã được chốt;
giả định đang áp dụng;
câu hỏi còn mở;
người sở hữu;
thời điểm cần xác nhận.
Đây là dấu vết quan trọng khi feature thay đổi qua nhiều sprint.
Checklist trước khi đưa AI feature vào sprint
[ ] Đã xác định các vai trò có thể áp dụng: controller, processor, provider hay deployer.
[ ] Đã mô tả dữ liệu đầu vào, dữ liệu phái sinh và mục đích sử dụng.
[ ] Đã xác định AI chỉ đề xuất hay được phép thực thi hành động.
[ ] Đã có điểm human-in-the-loop cho hành động tác động cao hoặc khó đảo ngược.
[ ] Đã có yêu cầu về audit, tách tenant và xử lý dữ liệu phái sinh.
[ ] Đã đưa vendor, SDK, model API và vector store vào đánh giá rủi ro trước khi ký hợp đồng.
[ ] Đã xác định người chịu trách nhiệm xác nhận các giả định về pháp lý, bảo mật và kiến trúc.
AI governance không phải là một cổng kiểm tra đặt ở cuối delivery. Với BA/PO, đó là chất lượng của yêu cầu ngay từ đầu: làm rõ dữ liệu, quyền hành động, ranh giới kiểm soát và bằng chứng cần lưu.
Khi các câu hỏi này xuất hiện trong backlog thay vì chỉ được nêu ra sau sự cố, đội sản phẩm có cơ sở tốt hơn để quản lý rủi ro và chứng minh mức độ kiểm soát với khách hàng.