Tuyên bố áp dụng (SoA) ISO 42001 là gì? Cách lập SoA cho hệ thống quản lý AI | Ví dụ
Nội dung bài viết 11 mục
Khi chuyên gia đánh giá mở hồ sơ AIMS, một trong những tài liệu đầu tiên họ đọc là Tuyên bố áp dụng – Statement of Applicability (SoA). Nó cho biết trong 38 biện pháp kiểm soát của Phụ lục A, tổ chức dùng những cái nào, không dùng cái nào, vì sao, và đã thực hiện tới đâu. SoA tốt là “bản đồ” của toàn bộ hệ thống kiểm soát AI; SoA kém là nguồn phát hiện không phù hợp nhanh nhất.
Tóm tắt nhanh
- SoA (điều 6.1.3) liệt kê control cần thiết, lý do đưa vào, lý do loại trừ và tình trạng thực hiện.
- SoA là thông tin dạng văn bản bắt buộc, phải cập nhật khi rủi ro hoặc hệ thống AI thay đổi.
- Lý do áp dụng dựa trên sổ rủi ro, đánh giá tác động, pháp luật, hợp đồng hoặc chính sách – không phải “theo tiêu chuẩn”.
- Lỗi lớn: lập SoA trước đánh giá rủi ro, ghi “Áp dụng” không có bằng chứng, loại trừ A.6 mà không chuyển trách nhiệm sang A.10.
SoA là gì?
Theo điều 6.1.3 ISO/IEC 42001, trong quá trình xử lý rủi ro AI, tổ chức phải lập một tuyên bố áp dụng chứa:
- Các biện pháp kiểm soát cần thiết (kể cả biện pháp ngoài Phụ lục A);
- Lý do đưa vào;
- Lý do loại trừ đối với control Phụ lục A không áp dụng;
- Tình trạng đã thực hiện hay chưa.
SoA là thông tin dạng văn bản bắt buộc và phải được cập nhật khi rủi ro hay hệ thống AI thay đổi.
Vì sao SoA quan trọng?
- Chứng minh tổ chức đã đối chiếu đủ với Phụ lục A — không bỏ sót biện pháp kiểm soát cần thiết.
- Kết nối rủi ro → biện pháp → bằng chứng, giúp đánh giá nội bộ và chứng nhận đi đúng trọng tâm.
- Thể hiện vai trò của tổ chức: bên phát triển, bên sử dụng sẽ có SoA khác nhau.
- Là tài liệu chia sẻ với khách hàng (bản rút gọn) để chứng minh quản trị AI.
Lý do áp dụng: dựa vào đâu?
Mỗi control được đưa vào vì một hoặc nhiều lý do:
| Mã lý do | Ý nghĩa |
|---|---|
| RR | Xử lý rủi ro trong sổ rủi ro AI (ghi mã rủi ro) |
| TĐ | Kết quả đánh giá tác động hệ thống AI |
| PL | Yêu cầu pháp luật, quy định |
| HĐ | Yêu cầu hợp đồng, khách hàng |
| CS | Chính sách, mục tiêu AI của tổ chức |
Loại trừ: khi nào hợp lý?
Loại trừ được phép nhưng phải có lý do thuyết phục, nhất quán với phạm vi và vai trò. Ví dụ hợp lý:
- Tổ chức chỉ sử dụng AI mua ngoài, không phát triển hay huấn luyện mô hình → một phần control thiết kế–phát triển (A.6.2.3) có thể giới hạn hoặc loại trừ, với điều kiện các nội dung liên quan được chuyển sang quản lý nhà cung cấp (A.10.3).
- Tổ chức không cung cấp hệ thống AI cho khách hàng bên ngoài → A.10.4 có thể giới hạn ở khách hàng nội bộ.
Ví dụ loại trừ không hợp lý: “A.5.5 – không áp dụng vì công ty nhỏ”; “A.7.4 – dữ liệu do nhà cung cấp lo”. Thông thường các nhóm A.2, A.3, A.5, A.9 gần như luôn áp dụng với mọi vai trò.
Cấu trúc một SoA
| Cột | Nội dung |
|---|---|
| Mã control | A.2.2 … A.10.4 (và control bổ sung, ví dụ X.1) |
| Tên control (tóm tắt) | Tên ngắn tự đặt |
| Áp dụng? | Có / Không / Một phần |
| Lý do | Mã lý do + mã rủi ro/đánh giá tác động |
| Hệ thống AI liên quan | Chatbot, Camera AI, Dự báo bảo trì… |
| Cách thực hiện | Tóm tắt biện pháp |
| Tài liệu tham chiếu | Mã quy trình, biểu mẫu |
| Tình trạng (thực hành tốt) | Đã thực hiện / Đang thực hiện / Kế hoạch (ngày) |
| Chủ sở hữu | Bộ phận phụ trách |
| Phiên bản, ngày duyệt | Kiểm soát thay đổi |
Ví dụ: trích SoA của công ty điện tử ở Bắc Giang (minh hoạ)
Công ty có camera AI kiểm tra ngoại quan (tự phát triển với đối tác), dự báo bảo trì (tự phát triển), chatbot nội bộ (mua SaaS).
| Control | Áp dụng | Lý do | Cách thực hiện | Tình trạng |
|---|---|---|---|---|
| A.2.2 Chính sách AI | Có | CS, HĐ | Chính sách AI v1.1 do TGĐ ký | Đã thực hiện |
| A.3.3 Báo cáo lo ngại | Có | TĐ-03 | Hộp thư ẩn danh + hotline đạo đức | Đã thực hiện |
| A.5.5 Tác động xã hội | Có | TĐ-01..03 | Mục 5 trong biểu mẫu đánh giá tác động | Đã thực hiện |
| A.6.2.4 Kiểm định | Có | RR-01, RR-02 | Tập kiểm thử độc lập, chạy song song 4 tuần | Đã thực hiện |
| A.6.2.8 Nhật ký | Có | RR-01, HĐ | Log ảnh + kết quả 12 tháng | Đang thực hiện (31/12) |
| A.7.5 Nguồn gốc dữ liệu | Có | RR-01 | Sổ đăng ký bộ dữ liệu, liên kết phiên bản mô hình | Đã thực hiện |
| A.8.3 Báo cáo bên ngoài | Một phần | HĐ | Kênh khiếu nại khách hàng hiện có, bổ sung mục AI | Đã thực hiện |
| A.10.3 Nhà cung cấp | Có | RR-06 | Bộ câu hỏi đánh giá nhà cung cấp AI | Đã thực hiện |
| A.10.4 Khách hàng | Một phần | – | Chỉ thông tin cho khách về kiểm tra AI theo yêu cầu | Đã thực hiện |
| X.1 Kiểm thử chống prompt injection | Có (bổ sung) | RR-07 | Kiểm thử trước mỗi lần cập nhật chatbot | Kế hoạch (15/11) |
Kết quả: 38/38 control được xem xét, 36 áp dụng đầy đủ hoặc một phần, 2 control giới hạn có lý do, 1 control bổ sung (số liệu minh hoạ).
Các bước lập SoA
- Hoàn thành danh mục hệ thống AI, đánh giá tác động và đánh giá rủi ro.
- Với mỗi rủi ro cần xử lý, chọn biện pháp kiểm soát (từ bất kỳ nguồn nào).
- Đối chiếu từng control Phụ lục A: đã được chọn chưa? Nếu chưa, có cần không?
- Ghi lý do áp dụng/loại trừ, tham chiếu mã rủi ro.
- Ghi cách thực hiện và tình trạng; giao chủ sở hữu.
- Phê duyệt cùng kế hoạch xử lý rủi ro và rủi ro còn lại.
- Cập nhật khi có hệ thống AI mới, sự cố, kết quả đánh giá nội bộ.
SoA 42001 và SoA 27001
Doanh nghiệp đã có ISO 27001 quen với SoA 93 control của Phụ lục A 27001. Có thể quản lý hai SoA trong cùng một file (hai sheet) hoặc một SoA tích hợp có cột “Tiêu chuẩn”. Lưu ý: không thay control AI bằng control an toàn thông tin — ví dụ A.7.4 (chất lượng dữ liệu) không được đáp ứng chỉ bằng kiểm soát truy cập. Xem tích hợp 42001 và 27001.
Lỗi hay gặp
- SoA lập trước khi đánh giá rủi ro, nên lý do áp dụng là “theo tiêu chuẩn”.
- Ghi “Áp dụng” nhưng không có tài liệu tham chiếu hay bằng chứng.
- Loại trừ hàng loạt control A.6 vì “chúng tôi chỉ dùng AI” mà không chuyển trách nhiệm sang A.10.
- Không cập nhật SoA khi thêm hệ thống AI mới vào phạm vi.
Câu hỏi thường gặp
SoA có phải công bố công khai không? Không bắt buộc. Nhiều tổ chức chia sẻ bản rút gọn với khách hàng khi được hỏi.
Có cần ghi control không thuộc Phụ lục A? Có, nếu đó là biện pháp cần thiết để xử lý rủi ro; nên đánh mã riêng.
SoA cần phê duyệt bởi ai? Do tổ chức quy định, thường là đại diện lãnh đạo về AIMS hoặc ban quản trị AI, cùng với phê duyệt rủi ro còn lại của chủ sở hữu rủi ro.


