# Kiểm toán viên không đọc code, họ lần theo một quyết định của AI

> Nếu một dòng log không dẫn được tới bộ test, người duyệt và cảnh báo drift, ngày go-live sẽ phải lùi lại.

Bản gốc: https://fdetimes.net/vi/bach-khoa/kiem-toan-noi-bo-hoi-gi-ve-he-thong-ai/

Thử hình dung thế này: còn hai tuần nữa là go-live, hệ thống AI hỗ trợ thẩm định hồ sơ vay bạn dựng cho một ngân hàng đã chạy ổn trên staging. Rồi một email từ phòng kiểm toán nội bộ gửi tới. Họ muốn biết hệ thống được kiểm thử thế nào, ai giám sát nó và log được lưu ở đâu.

Nhiều FDE coi email đó là thủ tục giấy tờ, giao cho bên compliance của khách rồi quay lại viết code. Đó là sai lầm. Với hệ thống AI trong lĩnh vực có quản lý, phần lớn bằng chứng kiểm toán cần chỉ có thể do người dựng hệ thống tạo ra, và nếu đến lúc bị hỏi mới tạo thì đã muộn.

Bài này dạy bạn đọc câu hỏi của kiểm toán viên như một bản đặc tả kỹ thuật. Thiết kế đúng ngay từ đầu, buổi làm việc với kiểm toán sẽ chỉ còn là việc mở đúng tài liệu ra. Để đến phút cuối, mỗi chỗ thiếu bằng chứng đều có thể đẩy lùi ngày go-live.

## Kiểm toán viên lần theo dấu vết chứ không đọc code

Muốn chuẩn bị tốt, bạn cần biết người hỏi đang dùng lăng kính gì. Viện Kiểm toán Nội bộ (IIA) có một AI Auditing Framework, mô tả là hướng dẫn thực hành cho kiểm toán viên nội bộ về quản trị, quản lý và kiểm toán AI.

Khung này dựa trên Three Lines Model, vì thế câu hỏi đầu tiên thường là ai sở hữu hệ thống ở từng tuyến: nghiệp vụ, quản trị rủi ro và tuân thủ, rồi đến kiểm toán.

Cách làm việc của họ cũng rất cụ thể. Một checklist kiểm toán theo chuẩn ISO 42001 của ISMS.online hướng dẫn chọn mẫu hai hệ thống AI trong phạm vi, rồi lần theo bản đánh giá tác động của từng hệ thống từ lúc lập đến khi được duyệt và mọi hành động khắc phục đã đóng.

Kiểm toán viên không đọc hết mọi thứ. Họ chọn một sợi chỉ rồi kéo.

Bằng chứng họ chờ đợi phần lớn do hệ thống sinh ra. Cũng checklist đó liệt kê log truy cập, đầu ra giám sát, dashboard hiệu năng model, cảnh báo drift và ticket sự cố. Toàn bộ những thứ này đều nằm trong phần việc của bạn.

## Luật nói gì về log và tài liệu?

Nếu hệ thống thuộc diện rủi ro cao theo EU AI Act, một phần câu hỏi đã được luật quy định sẵn. Điều 12 yêu cầu hệ thống rủi ro cao về mặt kỹ thuật phải cho phép tự động ghi lại sự kiện trong suốt vòng đời.

Log đó phải phục vụ ba mục đích: nhận diện tình huống rủi ro, giám sát sau khi đưa ra thị trường và giám sát vận hành.

Điều 26 đặt nghĩa vụ lên bên triển khai, tức chính khách hàng của bạn. Họ phải giữ log do hệ thống tự sinh ra, trong phạm vi log đó nằm dưới quyền kiểm soát của họ, tối thiểu sáu tháng trừ khi luật khác quy định khác.

Họ cũng phải giao việc giám sát con người cho những người có đủ năng lực, được đào tạo và có thẩm quyền.

Cụm "dưới quyền kiểm soát của họ" là chỗ FDE phải để ý. Nếu log chỉ nằm trong tài khoản cloud của vendor, khách hàng không thể giữ được nó.

Điều 11 còn yêu cầu tài liệu kỹ thuật phải được lập trước khi hệ thống đưa vào sử dụng và luôn được cập nhật. Theo trang tổng hợp luật, ngày áp dụng là 2/12/2027 cho nhóm Annex III và 2/8/2028 cho nhóm Annex I.

Ngoài châu Âu, NIST AI RMF Playbook là nguồn tham chiếu phổ biến. NIST nói rõ cả khung lẫn Playbook đều dùng trên cơ sở tự nguyện, nên hãy coi nó là một thực đơn bằng chứng để chọn, không phải checklist bắt buộc.

## Bảng ánh xạ: mỗi câu hỏi ứng với một bằng chứng

Công cụ hữu ích nhất bạn có thể mang đến buổi làm việc là một bảng, trong đó mỗi câu hỏi của kiểm toán ứng với một bằng chứng cụ thể, một nơi lưu và một người chịu trách nhiệm.

| Câu hỏi của kiểm toán | Bằng chứng | Nơi lưu | Người sở hữu |
|---|---|---|---|
| Hệ thống được kiểm thử thế nào? | Bộ test, metric và công cụ dùng để kiểm thử, đánh giá, xác nhận (TEVV theo NIST MEASURE 2.1) | Kho tài liệu dự án, gắn với từng release | FDE, nhóm kỹ thuật |
| Sau go-live, chất lượng được theo dõi ra sao? | Dashboard hiệu năng, ngưỡng và cảnh báo drift | Hệ thống giám sát trên hạ tầng của khách | FDE bàn giao, vận hành phía khách nhận |
| Hệ thống không dùng được ở đâu? | Phần "Giới hạn đã biết" ghi rõ những điều kiện hệ thống chưa được thử | Tài liệu kỹ thuật, cập nhật theo phiên bản | FDE viết, nghiệp vụ ký |
| Ai giám sát và họ có đủ thẩm quyền không? | Danh sách người duyệt, hồ sơ đào tạo, quyền override | Hồ sơ nhân sự và đào tạo của khách | Tuyến một của khách |
| Có truy vết được một quyết định không? | Log sự kiện kèm ticket sự cố | Hạ tầng log của khách, giữ tối thiểu sáu tháng | FDE thiết kế, khách lưu trữ |

Dòng một và dòng ba lấy từ NIST Playbook: phần MEASURE yêu cầu ghi lại bộ test, metric, công cụ, và cả giới hạn khi đưa hệ thống ra ngoài điều kiện nó được phát triển. Dòng hai ghép câu hỏi của NIST về cách theo dõi các chỉ số như độ chính xác sau triển khai với dashboard và cảnh báo drift mà checklist ISO 42001 liệt kê.

## Lần ngược một quyết định

Quay lại ví dụ ngân hàng. Kiểm toán viên chọn một hồ sơ mà hệ thống đề xuất "chuyển thẩm định viên xem lại" và hỏi vì sao. Bạn chỉ trả lời được nếu bản ghi log trông đại loại như sau:

```json
{
  "event_id": "evt_000123",
  "system": "credit-assist",
  "model_version": "credit-assist-v1.4",
  "prompt_template": "tpl-thamdinh-v3",
  "eval_suite": "eval-v7",
  "input_ref": "hoso/8812",
  "output": { "recommendation": "refer", "score": 0.62 },
  "reviewer_id": "u_lan",
  "reviewer_action": "override_approve",
  "reason_code": "thu_nhap_da_xac_minh"
}
```

Từ `model_version` và `eval_suite`, bạn mở được báo cáo eval-v7 để cho thấy phiên bản này đã qua bộ test nào và đạt metric bao nhiêu.

Từ `reviewer_id`, phía khách chỉ ra người duyệt là ai và họ đã được đào tạo những gì. `input_ref` chỉ là con trỏ tới hồ sơ chứ không chép dữ liệu cá nhân vào log, để log có thể lưu lâu mà không biến thành một kho dữ liệu nhạy cảm thứ hai.

Bây giờ hình dung bản ghi thiếu `eval_suite`. Bạn biết model nào đã chạy nhưng không chứng minh được nó đã qua kiểm thử nào, và sợi chỉ đứt ngay ở bước thứ hai. Kiểm toán viên sẽ ghi nhận một phát hiện, và go-live phải chờ đến khi phát hiện đó được đóng lại.

**Điểm mấu chốt:** Bằng chứng kiểm toán phải được thiết kế từ tuần đầu, không phải gom lại vào tuần cuối.

## Năm việc nên làm trước khi bị hỏi

Việc đầu tiên, ngay trong tuần discovery, là hỏi khách ai sở hữu hệ thống ở từng tuyến. Câu hỏi này thường làm lộ ra chuyện chưa ai được giao việc giám sát. Phát hiện ra ở tuần đầu thì vẫn còn thời gian xử lý, còn phát hiện ở tuần cuối thì việc đó trở thành nguyên nhân làm lùi lịch.

Tiếp theo, thiết kế schema log trước khi viết endpoint đầu tiên, sao cho mỗi quyết định mang theo phiên bản model, phiên bản prompt, bộ eval và người duyệt. Đẩy log về hạ tầng của khách để họ giữ được tối thiểu sáu tháng. Coi bộ eval là một artifact có phiên bản, gắn với từng lần release, chứ không phải một notebook chạy một lần rồi bỏ.

Sau đó viết phần giới hạn đã biết bằng ngôn ngữ nghiệp vụ, ví dụ "chưa thử với hồ sơ doanh nghiệp, chỉ thử với hồ sơ cá nhân". Cuối cùng, trước buổi làm việc thật, tự đóng vai kiểm toán viên: chọn ngẫu nhiên hai quyết định và lần ngược từng bước theo bảng ở trên.

## Những chỗ hay hỏng

Lỗi thứ hai là chỉ có một con số độ chính xác trong slide mà không có bộ test và công cụ đi kèm, nên không ai tái lập được con số đó.

Lỗi thứ ba là dashboard có sẵn nhưng không có ngưỡng cảnh báo, cũng không có ticket nào cho thấy cảnh báo từng được xử lý.

Còn một lỗi tinh vi hơn là coi NIST Playbook như checklist rồi cố điền mọi mục. Làm vậy sẽ ra một tập tài liệu dày nhưng không có sợi chỉ nào nối các phần với nhau. Kiểm toán viên cần ít tài liệu hơn nhưng phải truy vết được từ đầu đến cuối.

## Biến kỹ năng này thành lợi thế nghề nghiệp

Nếu tin tuyển dụng FDE nhắc tới tài chính, y tế, bảo hiểm hay "regulated industries", nhiều khả năng bạn sẽ phải làm việc với kiểm toán nội bộ. Hãy luyện bài tập lần ngược một quyết định trước khi đi phỏng vấn.

Trong CV, đừng chỉ viết "triển khai hệ thống AI". Hãy viết rằng bạn đã thiết kế log truy vết và bộ bằng chứng giúp hệ thống qua được vòng kiểm toán nội bộ trước go-live.

Khi phỏng vấn, hãy mô tả bản ghi log cần những trường nào và vì sao từng trường tồn tại, thay vì nói chung chung về "tuân thủ".

Ở những khách hàng này, hệ thống chạy đúng thôi chưa đủ để được go-live. Bạn còn phải chứng minh điều đó cho những người không bao giờ đọc code, và đó cũng là một phần của việc bàn giao.

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

- Chọn một quyết định thật mà hệ thống bạn đang làm đã đưa ra, rồi bấm giờ xem mất bao lâu để lần ra phiên bản model, bộ eval và người duyệt của nó.
- Điền bảng 'câu hỏi kiểm toán → bằng chứng → nơi lưu → người chịu trách nhiệm' cho dự án hiện tại và đánh dấu đỏ mọi ô còn trống.
- Viết nửa trang 'Giới hạn đã biết' cho hệ thống của bạn và gửi cho người phụ trách nghiệp vụ phía khách hàng đọc.

## Nguồn

- [Article 12: Record-keeping | AI Act Service Desk](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-12)

- [Article 26: Obligations of deployers of high-risk AI systems | AI Act Service Desk](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-26)

- [Article 11: Technical Documentation](https://artificialintelligenceact.eu/article/11/)

- [The IIA's Artificial Intelligence Auditing Framework](https://www.theiia.org/en/content/tools/professional/2023/the-iias-updated-ai-auditing-framework/)

- [Measure - AIRC (NIST AI Resource Center)](https://airc.nist.gov/airmf-resources/playbook/measure/)

- [NIST AI RMF Playbook](https://www.nist.gov/itl/ai-risk-management-framework/ai-rmf-playbook)

- [AI Audit Checklist: A Practical Guide to Auditing AI Systems (ISMS.online)](https://www.isms.online/iso-42001/ai-audit-checklist/)