Ai đã đồng ý cho agent làm vậy? Lập RAID log và decision log có cột người duyệt

OWASP xếp Excessive Agency vào danh mục rủi ro LLM năm 2025 với mã LLM06.

Ở dự án tại khách, rủi ro này hiếm khi lộ ra trong code review. Nó thường nằm ở một cuộc họp: ai đó gật đầu cho agent ghi vào hệ thống của khách, và không ai ghi lại cái gật đầu ấy.

Vì thế FDE cần hai tài liệu nghe có vẻ nhàm chán nhưng có thể cứu cả dự án: RAID log và decision log. Khi sự cố xảy ra, hai tài liệu này trả lời được ba câu hỏi: chuyện gì đã được lường trước, ai đã chấp nhận rủi ro đó, và vì lý do gì.

Cả hai đều dựng được ngay trong repo dự án, với điều kiện có thêm một cột tách riêng khỏi owner: người duyệt, tức người có quyền chấp nhận rủi ro.

Bạn sẽ dựng gì, và cần chuẩn bị gì?

Kết quả cuối cùng là một file raid-log.md và một thư mục decisions/, mỗi quyết định nằm trong một file riêng. Markdown là lựa chọn hợp lý vì có thể review qua pull request, có lịch sử thay đổi, và khách đọc được mà không phải cài thêm gì.

Nếu khách yêu cầu dùng công cụ quản lý dự án của họ, cứ giữ nguyên bộ cột bên dưới là được.

Ví dụ xuyên suốt bài là một dự án giả định: chatbot RAG trả lời câu hỏi nội bộ cho phòng chăm sóc khách hàng (CSKH) của một công ty bảo hiểm, cộng thêm đề xuất cho agent tự gửi email trả lời. Mọi vai trò và ngày tháng trong ví dụ đều là giả định.

Bạn cần ba thứ: một repo mà cả team lẫn đầu mối phía khách đều đọc được, danh sách những người có quyền ra quyết định ở phía khách, và nửa tiếng ngồi với tech lead.

Bước 1: dựng khung bốn ngăn, có hai cột không được gộp

Theo Process Street, RAID log là kho trung tâm theo dõi rủi ro, giả định, vấn đề và phụ thuộc trong suốt dự án.

Hiểu nhanh: rủi ro là sự kiện có thể làm dự án trễ hoặc trượt mục tiêu, giả định là điều được coi là đúng nhưng chưa kiểm chứng, phụ thuộc là việc phải chờ việc khác hoặc yếu tố bên ngoài, còn vấn đề là chuyện đã xảy ra.

Cả bốn ngăn nằm chung một file và dùng chung một bộ cột, để sau này lọc hay đối chiếu đều dễ.

# RAID log — Chatbot CSKH (ví dụ)

| ID | Loại | Mô tả | Tác động | Owner | Người duyệt | Trạng thái | Cập nhật | Quyết định liên quan |
|----|------|-------|----------|-------|-------------|------------|----------|----------------------|

Cột Loại chỉ nhận một trong bốn giá trị R, A, I, D. Owner là người phải làm gì đó với mục này. Người duyệt là người có quyền chấp nhận rủi ro hoặc đóng mục lại. Hai cột này được tách ra có chủ ý: FDE thường là owner, nhưng hiếm khi có quyền chấp nhận rủi ro thay cho khách.

Cột người duyệt cũng khớp với NIST AI RMF. Theo Playbook của khung này, mục GOVERN 2 đòi hỏi có cấu trúc trách nhiệm giải trình để đúng nhóm, đúng cá nhân được trao quyền và chịu trách nhiệm quản lý rủi ro AI. Mục GOVERN 2.1 yêu cầu vai trò và trách nhiệm phải được ghi thành văn bản.

NIST phát hành khung này ngày 26/01/2023 và chỉ khuyến nghị áp dụng tự nguyện. Dù vậy, khi khách hỏi vì sao log cần cột này, dẫn GOVERN ra sẽ thuyết phục hơn nhiều so với “vì team thấy cần”.

Kiểm tra: tự hỏi xem nếu FDE nghỉ việc ngày mai, người đọc log có biết ai chịu trách nhiệm từng dòng không.

Bước 2: viết giả định trước rủi ro

Thử hình dung buổi kickoff: phía khách khẳng định kho tài liệu nghiệp vụ đã chuẩn, cứ thế mà index. Đó chưa phải sự thật, mới là một giả định. Với dự án RAG, đây là giả định nên kiểm chứng đầu tiên, vì chatbot chỉ trả lời tốt bằng chính những tài liệu nó được đọc.

Viết giả định trước rủi ro có vẻ ngược thứ tự, nhưng nhiều rủi ro thật ra mọc lên từ chính một giả định chưa ai kiểm chứng. Ghi nó xuống trước thì bạn biết mình đang đứng trên nền nào.

| A-01 | A | Tài liệu nghiệp vụ đủ sạch và đủ mới để làm nguồn RAG | Nếu sai: chatbot trả lời theo quy trình cũ | FDE | Trưởng phòng CSKH | Chưa kiểm chứng — hạn 2026-10-16 | 2026-10-09 | — |

Mỗi giả định cần có cách kiểm chứng và hạn chót. Chẳng hạn, lấy mẫu 20 tài liệu rồi cùng trưởng phòng CSKH đánh dấu những tài liệu đã lỗi thời. Nếu kiểm chứng cho thấy giả định sai, đừng xoá dòng đó. Hãy tạo một dòng R hoặc I mới và trỏ ngược về A-01.

Kiểm tra: mọi dòng A phải ghi “Chưa kiểm chứng” kèm hạn, hoặc “Đã kiểm chứng” kèm ngày. Không dòng nào được ghi trống không một chữ “OK”.

Bước 3: dùng OWASP làm checklist để nghĩ ra rủi ro AI

Đến lúc ngồi với tech lead liệt kê rủi ro AI, thứ khó nhất là trang trắng: ai cũng biết model có thể sai, nhưng không ai nói được sai ở đâu. Hãy mở danh mục OWASP LLM Top 10 2025 ra làm gợi ý. Với dự án ví dụ, có ba mục đáng xét: LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure và LLM06 Excessive Agency.

| R-01 | R | Nhân viên không đủ quyền hỏi chatbot và nhận được thông tin cá nhân của người mua bảo hiểm (OWASP LLM02:2025) | Lộ dữ liệu, dự án có thể bị dừng | FDE | Đại diện bảo mật phía khách | Mở | 2026-10-09 | QĐ-002 |
| R-02 | R | Agent tự gửi email sai nội dung cho khách hàng thật (OWASP LLM06:2025) | Khiếu nại, ảnh hưởng uy tín | FDE | Giám đốc CSKH | Mở | 2026-10-09 | QĐ-001 |
| R-03 | R | Nội dung trong tài liệu nguồn hoặc câu hỏi làm lệch hành vi model (OWASP LLM01:2025) | Trả lời sai, bỏ qua giới hạn | FDE | Tech lead phía khách | Mở | 2026-10-09 | — |

Hãy viết mỗi rủi ro thành một kịch bản cụ thể trên hệ thống của khách, đừng chép nguyên tên mục OWASP. Một dòng chỉ ghi “Prompt Injection” thì không ai biết phải làm gì. Một dòng nêu rõ ai, làm gì, gây hậu quả gì thì có người nhận.

Kiểm tra: người duyệt của mỗi rủi ro AI phải là người phía khách, vì chỉ họ mới có quyền chấp nhận rủi ro trên dữ liệu và khách hàng của họ.

Bước 4: phụ thuộc và vấn đề, hai ngăn hay bị bỏ trống

Ở site khách, thứ chặn bạn đầu tiên nhiều khi không phải model mà là một tài khoản chưa được cấp. Quyền truy cập hệ thống của khách là ví dụ điển hình của phụ thuộc. Dùng tiền tố DEP- để khỏi nhầm với mã quyết định.

| DEP-01 | D | Cần quyền đọc kho tài liệu CSKH để index | Chưa có thì chưa thể bắt đầu đánh giá | FDE | Trưởng IT phía khách | Chờ | 2026-10-09 | — |

Ranh giới giữa R và I nên giữ thật đơn giản: chuyện có thể xảy ra thì nằm ở R, chuyện đã xảy ra thì chuyển sang I. Nếu DEP-01 trễ hai tuần, hãy mở một dòng I mới trỏ về DEP-01, đừng chỉ sửa lại ngày.

Bước 5: mỗi quyết định lớn là một file kiểu ADR

Kỹ sư vốn đã quen với một định dạng phù hợp. ADR ghi lại một quyết định kiến trúc cùng lý do của nó, và theo adr.github.io, tập hợp các ADR của một dự án chính là decision log của dự án đó.

# QĐ-001: Agent chỉ soạn nháp email, không tự gửi

Ngày: 2026-10-09 (ví dụ)
Trạng thái: Đã duyệt
Người tham gia: FDE, tech lead, Giám đốc CSKH, đại diện bảo mật
Người duyệt: Giám đốc CSKH
Rủi ro liên quan: R-02

## Tình huống
Agent được đề xuất tự trả lời email khách hàng.

## Quyết định
Agent chỉ tạo bản nháp; nhân viên CSKH bấm gửi.

## Phương án đã loại
Tự gửi với email thuộc nhóm "câu hỏi đơn giản".

## Hệ quả
Giảm tốc độ phản hồi; xem lại sau khi có số liệu đánh giá.

QĐ-002 viết theo đúng mẫu đó, chẳng hạn: chatbot chỉ truy xuất tài liệu mà người hỏi có quyền xem, hồ sơ cá nhân của người mua bảo hiểm không được index. Người duyệt là đại diện bảo mật phía khách, rủi ro liên quan là R-01.

Không phải chuyện gì cũng cần một file. Fellow khuyên chỉ lập decision log chi tiết cho các quyết định tác động lớn, như tuyển người, ngân sách hay sự kiện lớn, chứ không ghi mọi thảo luận nhỏ. Với dự án AI, bạn có thể đặt ngưỡng như sau: quyết định nào thay đổi dữ liệu model được thấy hoặc hành động agent được làm thì phải có file.

Ghi tên người tham gia không phải thủ tục cho có. Fellow chỉ ra rằng danh sách này có ích khi về sau có người chối rằng mình không tham gia cuộc thảo luận.

Kiểm tra: mỗi rủi ro đang ở trạng thái Mở phải trỏ tới một quyết định hoặc một kế hoạch xử lý. Trường người duyệt của mỗi quyết định phải là một người cụ thể, không ghi “cả team”.

Bước 6: giữ cho log sống

Process Street khuyên cập nhật RAID log đều đặn nhưng không nêu lịch cụ thể. Cách bền nhất là gắn việc này vào một nhịp sẵn có, ví dụ dành mười phút cuối buổi họp tuần với khách để rà các dòng còn Mở và các giả định sắp tới hạn. Một log không được nhắc đến trong cuộc họp nào thì sau một tháng sẽ thành đồ trang trí.

Những lỗi khiến log vô dụng

Lỗi đầu tiên là ghi tên FDE vào cả cột owner lẫn cột người duyệt. Làm vậy, bạn tự nhận phần rủi ro vốn thuộc về khách. Lỗi thứ hai là chép nguyên danh mục OWASP vào log, khiến log trông đầy đủ nhưng không ai biết hành động gì.

Hai lỗi còn lại ngược chiều nhau. Có team ghi mọi cuộc trao đổi thành quyết định, đến mức quyết định thật bị chìm giữa đống ghi chép. Có team lại để log trong máy cá nhân, khách chưa từng được xem. Đến khi có sự cố, không ai có thể nói khách đã chấp nhận một rủi ro mà họ chưa bao giờ đọc.

Kỹ năng này hiện ra ở đâu khi bạn đi làm FDE?

Ở site khách, nên dựng RAID log ngay trong tuần đầu và đi qua nó cùng sponsor phía khách. Đọc từng giả định trước mặt người có quyền quyết định cho bạn cơ hội phát hiện sớm chỗ hai bên đang hiểu khác nhau. Khi khách đề xuất mở thêm quyền cho agent, bạn đã có sẵn chỗ để ghi lại ai đồng ý và vì sao.

Khi đọc JD, nếu thấy các cụm như stakeholder management, risk hay governance đi kèm với deployment, hãy chuẩn bị sẵn một ví dụ về log của bạn cho buổi phỏng vấn. Trong CV, đừng chỉ viết “quản lý rủi ro”.

Hãy viết cụ thể, ví dụ: lập RAID log và decision log cho một triển khai RAG, gắn mỗi rủi ro LLM với người duyệt phía khách. Khi phỏng vấn, chuẩn bị sẵn câu chuyện về một quyết định bạn đã ghi lại và chuyện gì xảy ra nhờ có nó.

Model rồi sẽ thay, prompt rồi sẽ sửa. Dòng ghi “Người duyệt: Giám đốc CSKH” mới là thứ còn giá trị khi có người hỏi lại vì sao agent được phép làm điều đó.