# Cách FDE chuẩn bị hồ sơ model risk để qua hội đồng AI theo EU AI Act

> Hội đồng AI của khách không chấm độ chính xác của model; họ muốn biết sau mọi biện pháp, phần rủi ro còn lại là gì và ai đã ký chấp nhận nó.

Bản gốc: https://fdetimes.net/vi/bach-khoa/ai-governance-cho-khach-doanh-nghiep/

Còn hai tuần nữa là go-live. Hội đồng AI của khách hàng gửi email với một câu hỏi duy nhất: "Rủi ro còn lại của hệ thống này có chấp nhận được không, và ai đã quyết định vậy?"

Bạn có dashboard, có bộ eval, có demo chạy mượt. Nhưng không thứ nào trong đó trả lời được câu hỏi kia.

Với một FDE làm cho khách hàng ở châu Âu, đây là lúc dự án hoặc đi tiếp, hoặc nằm chờ thêm một quý. Kỹ năng cần có không phải là thuộc luật, mà là biết biến công việc kỹ thuật mình đã làm thành một lập luận hội đồng đọc được.

## Hội đồng không đọc code, họ đọc lập luận

Điều 9 của EU AI Act yêu cầu hệ thống AI rủi ro cao phải có một hệ thống quản lý rủi ro được thiết lập, triển khai, lập tài liệu và duy trì. Chữ quan trọng nhất là "duy trì".

Luật viết rõ quy trình này phải được hiểu là một quá trình lặp liên tục. Vì thế hồ sơ của bạn không phải bản PDF nộp một lần rồi quên, mà là thứ sống cùng hệ thống.

Điều 9 cũng đặt ra đích đến: rủi ro còn lại tổng thể phải được đánh giá là chấp nhận được. Đó chính là câu hỏi trong email kia. Hội đồng không cần rủi ro bằng không, họ cần thấy nó đã được gọi tên, giảm bớt và có người ký nhận phần còn lại.

Phụ lục IV cho bạn khung nội dung tối thiểu. Trong đó có mô tả chi tiết hệ thống quản lý rủi ro theo Điều 9, phần giải thích vì sao các chỉ số hiệu năng phù hợp với hệ thống cụ thể, và mô tả cách đánh giá hiệu năng ở giai đoạn sau khi đưa ra thị trường.

**Điểm mấu chốt:** Hội đồng không hỏi model tốt đến đâu, mà hỏi phần rủi ro còn lại ai đã chấp nhận.

## Khi tùy biến, bạn có thành nhà cung cấp không?

Trước khi viết dòng nào, hãy xác định vai trò. Điều 25 nói bên triển khai hoặc bên thứ ba có thể bị coi là nhà cung cấp nếu thay đổi mục đích sử dụng khiến hệ thống trở thành rủi ro cao, hoặc thực hiện sửa đổi đáng kể.

Điều 25 cũng áp dụng khi một bên gắn tên hay nhãn hiệu của mình lên hệ thống rủi ro cao đã có trên thị trường. Thử hình dung đội bạn lấy một model đa dụng rồi viết prompt và tool để nó lọc hồ sơ ứng viên.

Nếu pháp chế của khách xếp mục đích mới này vào nhóm rủi ro cao, Điều 25 có thể kéo bên bạn vào vai nhà cung cấp.

Lời khuyên thực tế là ghi vai trò ngay trang đầu hồ sơ. Ai là nhà cung cấp, ai là bên triển khai, và thay đổi nào của đội bạn có thể làm vai trò đó dịch chuyển.

Pháp chế cần trang này vì vai trò quyết định ai phải gánh nghĩa vụ của nhà cung cấp, trong đó có việc lập và duy trì hệ thống quản lý rủi ro theo Điều 9. Chưa chốt được điều đó thì mọi trang phía sau đều chưa biết đứng tên ai.

## Một hồ sơ mẫu: agent sàng lọc CV

Thử hình dung bạn triển khai một agent đọc CV và đề xuất loại hoặc giữ ứng viên cho một công ty tuyển dụng ở Đức. Giả sử pháp chế của khách đã xếp hệ thống này vào nhóm rủi ro cao. Phần lõi của hồ sơ là một sổ rủi ro như sau.

| Rủi ro | Biện pháp | Rủi ro còn lại | Người chấp nhận |
|---|---|---|---|
| Agent loại nhầm ứng viên đủ chuẩn | Mọi đề xuất loại đều qua recruiter duyệt | Thấp | Trưởng bộ phận tuyển dụng |
| Recruiter duyệt theo quán tính, tin máy quá mức | Hiển thị lý do loại, lấy mẫu kiểm tra hằng tuần, đào tạo người duyệt | Trung bình | Trưởng bộ phận tuyển dụng |
| Định dạng CV mới làm parser đọc sai | Log từng lần xử lý, cảnh báo khi tỉ lệ lỗi tăng | Thấp | Trưởng nhóm kỹ thuật |
| Cần dừng hệ thống gấp | Nút dừng chuyển toàn bộ về quy trình thủ công | Thấp | Giám đốc vận hành |

Dòng thứ hai và thứ tư không phải để trang trí. Điều 14 đòi người giám sát có khả năng ngắt hệ thống bằng nút "stop" hoặc thủ tục tương tự, và phải nhận thức được nguy cơ phụ thuộc quá mức vào đầu ra của máy.

Tiếp theo là phần chỉ số. Phụ lục IV không chỉ cần con số, mà đòi bạn giải thích vì sao chỉ số được chọn là phù hợp với chính hệ thống này. Nếu bạn chỉ báo accuracy, hãy chờ câu hỏi: accuracy đo điều gì mà người bị ảnh hưởng quan tâm?

Với agent này, thứ đáng đo là mức đồng thuận của người duyệt với các đề xuất loại. Giả sử mỗi tuần lấy mẫu 200 đề xuất loại, recruiter đọc lại và đồng ý với 184. Tỉ lệ đồng thuận là 92%, nghĩa là 16 ứng viên có thể đã bị loại oan nếu không có người duyệt.

Con số đó trả lời luôn yêu cầu post-market của Phụ lục IV. Bạn ghi một ngưỡng giả định, chẳng hạn đồng thuận dưới 90% trong hai tuần liền thì mở lại sổ rủi ro. Đó là quy trình lặp mà Điều 9 nói tới, được viết thành một quy tắc có thể kiểm tra.

## Năm bước để tự làm

1. Xác định vai trò theo Điều 25 và ghi ở trang đầu: ai là nhà cung cấp, ai triển khai, thay đổi nào có thể đổi vai trò.
2. Liệt kê rủi ro theo người bị ảnh hưởng, không theo thành phần kỹ thuật. Mỗi dòng phải có biện pháp, mức rủi ro còn lại và tên người chấp nhận.
3.

Chọn chỉ số chính và viết một đoạn ngắn giải thích vì sao nó phù hợp với hệ thống này, đúng như Phụ lục IV yêu cầu.
4. Thiết kế giám sát con người và log cùng lúc. Điều 26 buộc khách giao việc giám sát cho người có năng lực, đào tạo và thẩm quyền, và phải lưu log do hệ thống tự tạo ra.
5.

Viết kế hoạch theo dõi sau triển khai với ngưỡng cụ thể và hành động khi vượt ngưỡng, rồi hỏi pháp chế xem khách có thuộc diện phải đánh giá tác động lên quyền cơ bản theo Điều 27 không.

Bước 4 là chỗ FDE tạo khác biệt. Khách hàng mới là người mang nghĩa vụ của Điều 26, nhưng họ chỉ làm được nếu hệ thống của bạn ghi log đủ và có màn hình duyệt rõ ràng.

Nếu hội đồng chưa quen ngôn ngữ của EU AI Act, NIST AI RMF là một khung tự nguyện có thể dùng làm ngôn ngữ chung. Nó giúp hai bên thống nhất cách nói về rủi ro trước khi bàn đến điều khoản.

## Những lỗi khiến hồ sơ bị trả về

Lỗi phổ biến nhất là sổ rủi ro không có cột rủi ro còn lại. Bạn liệt kê biện pháp rất kỹ nhưng không nói còn lại bao nhiêu, nên hội đồng không có gì để chấp nhận.

Lỗi kế tiếp là coi người duyệt như một biện pháp tự động đúng. Nếu không đo mức đồng thuận và không đào tạo, "human in the loop" chỉ còn là bước bấm duyệt cho có.

Lỗi cuối là đọc sai lịch áp dụng. Gói Omnibus dời hạn với hệ thống rủi ro cao độc lập thuộc Phụ lục III sang ngày 2/12/2027, và hệ thống nhúng trong sản phẩm thuộc Phụ lục I sang ngày 2/8/2028.

Nhưng mốc mới chỉ có hiệu lực pháp lý khi được đăng trên Official Journal. Tính đến lần cập nhật ngày 10/7/2026 của iubenda, việc đăng này chưa được xác nhận, và trước thời điểm đó lịch gốc của luật vẫn được áp dụng. Hãy tự kiểm tra trên EUR-Lex thay vì trích lại bài bình luận.

## Kỹ năng này thể hiện trong CV và phỏng vấn ra sao?

Khi đọc mô tả công việc FDE cho khách ở châu Âu, hãy để ý các cụm như "AI governance", "model risk" hay "regulated industries". Gặp chúng, bạn nên hỏi thẳng nhà tuyển dụng xem FDE có phải trình bày trước hội đồng AI của khách không; nếu có, ví dụ dưới đây là thứ nên mang theo.

Một dòng CV mạnh có dạng: "Thiết kế quy trình lấy mẫu 200 đề xuất mỗi tuần để đo mức đồng thuận của người duyệt, kèm ngưỡng tự động mở lại đánh giá rủi ro." Nó cho thấy bạn biến yêu cầu tuân thủ thành một chỉ số vận hành.

Hãy chuẩn bị cho một câu hỏi phỏng vấn kiểu này: "Đồng thuận giảm từ 184/200 xuống 170/200 trong hai tuần, bạn làm gì?" Lưu ý 170/200 là 85%, đã thủng ngưỡng 90% giả định ở trên.

Câu trả lời tốt đi qua ba bước. Kiểm tra log xem đầu vào có đổi không, tạm chuyển đề xuất loại về duyệt thủ công, rồi cập nhật sổ rủi ro và báo người đã ký chấp nhận.

Hồ sơ model risk tốt không làm hội đồng hết lo. Nó cho họ biết chính xác nên lo về điều gì, và ai sẽ nhận cuộc gọi khi con số bắt đầu trượt.

**Thử ngay tuần này:**

- Lấy một hệ thống bạn đang triển khai, viết sổ rủi ro 4 dòng với đủ các cột: rủi ro, biện pháp, rủi ro còn lại, người chấp nhận.
- Viết một đoạn 5 câu giải thích vì sao chỉ số chính của hệ thống đó phù hợp hơn accuracy.
- Tra trên EUR-Lex xem quy định dời hạn của gói Omnibus đã được đăng trên Official Journal hay chưa.

## Nguồn

- [Article 9: Risk Management System | EU Artificial Intelligence Act](https://artificialintelligenceact.eu/article/9/)

- [Annex IV: Technical Documentation Referred to in Article 11(1) | EU Artificial Intelligence Act](https://artificialintelligenceact.eu/annex/4/)

- [Article 25 | EU Artificial Intelligence Act](https://artificialintelligenceact.eu/article/25/)

- [Article 26: Obligations of Deployers of High-Risk AI Systems | EU Artificial Intelligence Act](https://artificialintelligenceact.eu/article/26/)

- [Article 14: Human Oversight | EU Artificial Intelligence Act](https://artificialintelligenceact.eu/article/14/)

- [Article 27: Fundamental Rights Impact Assessment | EU Artificial Intelligence Act](https://artificialintelligenceact.eu/article/27/)

- [EU AI Act Omnibus Agreement — Postponed High-Risk Deadlines and Other Key Changes](https://www.gibsondunn.com/eu-ai-act-omnibus-agreement-postponed-high-risk-deadlines/)

- [AI Omnibus adopted: what still applies from August 2](https://www.iubenda.com/en/blog/ai-omnibus-adopted-august-2-obligations-july-2026/)

- [AI Risk Management Framework | NIST](https://www.nist.gov/itl/ai-risk-management-framework)