Phụ lục A ISO 42001 là gì? 38 biện pháp kiểm soát AI theo 9 nhóm | Ví dụ

Nếu điều 4–10 là “bộ khung” hệ thống quản lý, thì Phụ lục A là “bộ đồ nghề” kiểm soát AI. Phụ lục A của ISO/IEC 42001:2023 có 38 biện pháp kiểm soát chia thành 9 nhóm mục tiêu (A.2 đến A.10). Đây là phụ lục quy định (normative): theo điều 6.1.3, tổ chức phải so sánh các biện pháp xử lý rủi ro của mình với toàn bộ danh sách này để không bỏ sót, rồi ghi vào Tuyên bố áp dụng (SoA) control nào cần, control nào không và vì sao. Phụ lục B (cũng là phụ lục quy định) đi kèm, cho hướng dẫn thực hiện từng control.

Tóm tắt nhanh

• Phụ lục A gồm 38 control trong 9 nhóm A.2–A.10, là “bộ đồ nghề” kiểm soát AI bên cạnh khung điều 4–10.
• Không bắt buộc áp dụng hết: đánh giá rủi ro và tác động → chọn biện pháp → đối chiếu Phụ lục A → ghi vào SoA.
• Phải xem xét hướng dẫn Phụ lục B (6.1.3 e) nhưng được mở rộng, điều chỉnh cách thực hiện cho phù hợp.
• Lỗi lớn: coi Phụ lục A là checklist có/không, loại trừ A.5 thiếu thuyết phục, không có bằng chứng log hệ thống AI.

Phụ lục A dùng thế nào?

Phụ lục A không phải danh sách bắt buộc áp dụng hết. Logic đúng là: đánh giá rủi ro và tác động → chọn biện pháp xử lý → đối chiếu với Phụ lục A để không bỏ sót → ghi SoA → lập kế hoạch xử lý rủi ro và xin phê duyệt của cấp quản lý được chỉ định. Tổ chức được thêm biện pháp ngoài Phụ lục A, tự thiết kế hoặc lấy từ nguồn khác.

Về Phụ lục B, cần hiểu đúng hai điểm:

• Tổ chức phải xem xét hướng dẫn Phụ lục B khi triển khai control (điều 6.1.3 e). Nhưng không phải ghi lý do áp dụng hay bỏ qua từng gạch đầu dòng hướng dẫn trong SoA — SoA chỉ nói ở mức control.
• Hướng dẫn không phải lúc nào cũng phù hợp hoặc đủ. Tổ chức được mở rộng, điều chỉnh hoặc tự định nghĩa cách thực hiện control theo rủi ro của mình. Hãy coi Phụ lục B là “điểm xuất phát”, không phải kịch bản bắt buộc từng chữ.

Ngôn ngữ trong Phụ lục B chủ yếu là “nên” — nhưng khi control đã được đưa vào SoA, chuyên gia đánh giá sẽ dùng chính các gợi ý đó để hỏi bạn đã làm gì tương đương.

Tóm tắt 9 nhóm (diễn giải bằng lời của chúng tôi)

Nhóm	Tên nhóm	Số control	Mục đích (tóm tắt)
A.2	Chính sách liên quan đến AI	3	Lãnh đạo định hướng và hỗ trợ AI theo yêu cầu kinh doanh
A.3	Tổ chức nội bộ	2	Thiết lập trách nhiệm giải trình cho cách tiếp cận AI có trách nhiệm
A.4	Nguồn lực cho hệ thống AI	5	Nắm đủ nguồn lực (thành phần, tài sản) để hiểu rủi ro và tác động
A.5	Đánh giá tác động của hệ thống AI	4	Đánh giá tác động tới cá nhân, nhóm người, xã hội suốt vòng đời
A.6	Vòng đời hệ thống AI	9	Mục tiêu, quá trình phát triển có trách nhiệm; tiêu chí cho từng giai đoạn
A.7	Dữ liệu cho hệ thống AI	5	Hiểu vai trò và tác động của dữ liệu suốt vòng đời
A.8	Thông tin cho bên quan tâm	4	Bên liên quan có đủ thông tin để hiểu và đánh giá rủi ro, tác động
A.9	Sử dụng hệ thống AI	3	Dùng AI có trách nhiệm, đúng chính sách tổ chức
A.10	Quan hệ bên thứ ba và khách hàng	3	Rõ trách nhiệm, phân bổ rủi ro hợp lý khi có bên thứ ba

Bảng chi tiết cả 38 control (mã – tên tóm tắt – cách làm – bằng chứng) xem tại hướng dẫn từng control ISO 42001.

A.2 – Chính sách liên quan đến AI (A.2.2–A.2.4)

Mục đích: có định hướng của lãnh đạo về việc phát triển hoặc sử dụng AI, khớp với chiến lược kinh doanh.

Việc cần làm thực tế:

• Viết chính sách AI dựa trên chiến lược kinh doanh, giá trị và khẩu vị rủi ro, mức rủi ro của các hệ thống AI, yêu cầu pháp lý và hợp đồng, tác động tới bên quan tâm.
• Ngoài các nội dung điều 5.2 bắt buộc, chính sách nên có nguyên tắc dẫn dắt mọi hoạt động AI và cách xử lý ngoại lệ, sai lệch so với chính sách.
• Rà các chính sách đang có (chất lượng, an toàn thông tin, an toàn lao động, dữ liệu cá nhân) xem chỗ nào giao thoa với AI → sửa chính sách đó hoặc đưa điều khoản vào chính sách AI (A.2.3).
• Giao một vai trò được lãnh đạo phê duyệt chịu trách nhiệm xây dựng, rà soát chính sách; rà soát định kỳ và khi bối cảnh pháp lý, kinh doanh, công nghệ thay đổi, có dùng kết quả xem xét của lãnh đạo (A.2.4).

Bằng chứng chuyên gia đánh giá hay hỏi: chính sách có ngày duyệt và phiên bản; bảng đối chiếu chính sách AI ↔ chính sách khác; biên bản rà soát gần nhất; hồ sơ phê duyệt ngoại lệ.

Lỗi thường gặp: chính sách chỉ là khẩu hiệu “AI có trách nhiệm”, không có quy tắc xử lý ngoại lệ; không ai được giao rà soát; chính sách bảo mật cũ vẫn cho phép đưa dữ liệu khách vào công cụ AI công cộng, mâu thuẫn chính sách AI.

Chi tiết: chính sách AI và vai trò theo ISO 42001.

A.3 – Tổ chức nội bộ (A.3.2–A.3.3)

Mục đích: ai cũng biết mình chịu trách nhiệm gì với hệ thống AI, và có kênh để nêu lo ngại.

Việc cần làm thực tế:

• Xác định vai trò dựa trên chính sách, mục tiêu và rủi ro AI. Các mảng thường cần người phụ trách: quản lý rủi ro, đánh giá tác động, tài sản và nguồn lực, an ninh, an toàn, quyền riêng tư, phát triển, hiệu năng, giám sát của con người, nhà cung cấp, tuân thủ pháp lý, chất lượng dữ liệu.
• Lập kênh báo cáo lo ngại (A.3.3) có: lựa chọn bảo mật/ẩn danh; được phổ biến cho cả nhân viên và người làm theo hợp đồng; người xử lý có năng lực và đủ quyền điều tra; cơ chế leo thang kịp thời lên lãnh đạo; bảo vệ khỏi trù dập; thời hạn phản hồi. Có thể dùng lại kênh tố giác sẵn có (tham khảo ISO 37002).

Bằng chứng: RACI/ma trận trách nhiệm theo hệ thống AI; quyết định bổ nhiệm; quy trình kênh báo cáo; sổ tiếp nhận và kết quả xử lý (đã ẩn danh); bằng chứng truyền thông kênh.

Lỗi thường gặp: giao hết cho phòng IT; không có ai phụ trách giám sát con người; kênh báo cáo tồn tại trên giấy nhưng nhân viên không biết, không có thời hạn phản hồi.

A.4 – Nguồn lực cho hệ thống AI (A.4.2–A.4.6)

Mục đích: biết đủ những gì hệ thống AI dùng — thành phần, dữ liệu, công cụ, hạ tầng, con người — để hiểu rủi ro và tác động.

Việc cần làm thực tế: lập “hồ sơ nguồn lực” cho mỗi hệ thống AI, có thể dùng sơ đồ luồng dữ liệu hoặc sơ đồ kiến trúc:

• Dữ liệu (A.4.3): nguồn gốc, ngày cập nhật gần nhất, loại dữ liệu (huấn luyện, kiểm định, kiểm thử, vận hành), cách gán nhãn, mục đích dùng, chất lượng, chính sách lưu giữ/hủy, thiên lệch đã biết, cách chuẩn bị.
• Công cụ (A.4.4): loại thuật toán và mô hình, công cụ xử lý dữ liệu, phương pháp tối ưu và đánh giá, công cụ cấp phát tài nguyên, phần mềm/phần cứng phục vụ thiết kế–triển khai.
• Hệ thống và tính toán (A.4.5): yêu cầu tài nguyên, vị trí (tại chỗ, cloud, máy biên), xử lý, mạng, lưu trữ, và cả tác động môi trường, chi phí của phần cứng.
• Con người (A.4.6): năng lực cho phát triển, triển khai, vận hành, quản lý thay đổi, bảo trì, chuyển giao, ngừng sử dụng, kiểm tra và tích hợp — gồm nhà khoa học dữ liệu, người giám sát, chuyên gia an toàn/bảo mật/riêng tư, chuyên gia nghiệp vụ.
• Nếu thiếu nguồn lực, điều chỉnh đặc tả thiết kế hoặc yêu cầu triển khai cho phù hợp.

Bằng chứng: AI inventory kèm hồ sơ nguồn lực; sơ đồ kiến trúc; danh mục mô hình và phiên bản; ma trận năng lực người làm AI.

Lỗi thường gặp: chỉ liệt kê phần mềm, quên dữ liệu và con người; không ghi phiên bản mô hình/thư viện; không ai tính chi phí, năng lượng GPU.

Ví dụ: hồ sơ hệ thống “Camera AI kiểm tra vết xước” ghi: 12.000 ảnh huấn luyện (phiên bản DS-03), framework cố định phiên bản, máy tính biên tại line 3, 2 kỹ sư thị giác máy và 1 QC trưởng duyệt nhãn (minh hoạ).

A.5 – Đánh giá tác động của hệ thống AI (A.5.2–A.5.5)

Mục đích: hiểu hệ thống AI có thể gây gì cho cá nhân, nhóm người và xã hội suốt vòng đời.

Việc cần làm thực tế: quy trình nêu khi nào phải đánh giá (mức quan trọng của mục đích sử dụng, độ phức tạp và mức tự động hoá, độ nhạy cảm của dữ liệu, hoặc khi những yếu tố này thay đổi đáng kể), các bước (nhận diện – phân tích – đánh giá – xử lý – lập hồ sơ, báo cáo), ai làm, kết quả dùng để làm gì. Xét tác động tới vị thế pháp lý và cơ hội sống, sức khoẻ thể chất và tinh thần, quyền con người, xã hội. Lưu hồ sơ trong thời hạn xác định.

Bằng chứng: quy trình; hồ sơ đánh giá từng hệ thống (mục đích, lạm dụng có thể dự đoán, tác động tích cực/tiêu cực, lỗi có thể dự đoán và biện pháp, nhóm nhân khẩu học liên quan, vai trò con người, ảnh hưởng việc làm); bằng chứng kết quả đã chảy vào đánh giá rủi ro.

Lỗi thường gặp: chỉ xét thiệt hại cho công ty; quên nhóm dễ tổn thương (người cao tuổi, trẻ em, người khuyết tật, người lao động); làm một lần rồi bỏ. Chi tiết: đánh giá tác động hệ thống AI.

A.6 – Vòng đời hệ thống AI (A.6.1.2–A.6.2.8)

Mục đích: phát triển AI có mục tiêu và quá trình có trách nhiệm; mỗi giai đoạn có tiêu chí và yêu cầu rõ.

Việc cần làm thực tế:

• A.6.1.2: biến mục tiêu (ví dụ công bằng) thành yêu cầu cụ thể ở từng bước: đặc tả, thu thập dữ liệu, huấn luyện, kiểm định — kể cả quy định công cụ/phương pháp kiểm thử bắt buộc.
• A.6.1.3: quy trình phát triển nêu giai đoạn vòng đời, yêu cầu kiểm thử, yêu cầu giám sát của con người, thời điểm đánh giá tác động, quy tắc dữ liệu huấn luyện, năng lực người phát triển, tiêu chí phát hành, các cổng phê duyệt, kiểm soát thay đổi, tính dễ dùng và kiểm soát được, sự tham gia của bên quan tâm.
• A.6.2.2–A.6.2.8: đặc tả (có lý do kinh doanh, cách huấn luyện và dữ liệu cần), tài liệu thiết kế (cách học, thuật toán, phần cứng/phần mềm, mối đe doạ an ninh đặc thù AI như đầu độc dữ liệu, đánh cắp mô hình, suy ngược mô hình), V&V có tiêu chí định trước, kế hoạch triển khai với tiêu chí phát hành, vận hành tối thiểu gồm giám sát hiệu năng – sửa lỗi – cập nhật – hỗ trợ, tài liệu kỹ thuật theo từng nhóm người đọc, và log sự kiện ít nhất khi hệ thống đang được dùng.

Bằng chứng: đặc tả có tiêu chí chấp nhận; báo cáo kiểm thử trên dữ liệu độc lập; phiếu phê duyệt phát hành; dashboard giám sát trôi dạt; kế hoạch xử lý sự cố/quay lui; model card; cấu hình log và thời hạn lưu.

Lỗi thường gặp: “đạt” theo cảm tính vì không có tiêu chí trước; cập nhật mô hình thẳng lên sản xuất; bên chỉ sử dụng AI bỏ qua A.6, quên rằng cấu hình, kiểm thử chấp nhận và giám sát vận hành vẫn thuộc vòng đời. Chi tiết: vòng đời hệ thống AI.

A.7 – Dữ liệu cho hệ thống AI (A.7.2–A.7.6)

Mục đích: hiểu vai trò và tác động của dữ liệu trong phát triển, cung cấp và sử dụng AI.

Việc cần làm thực tế: quy trình quản lý dữ liệu xét quyền riêng tư và bảo mật, mối đe doạ an ninh/an toàn từ dữ liệu, khả năng giải thích dữ liệu đã dùng thế nào, tính đại diện so với môi trường vận hành, độ chính xác và toàn vẹn (A.7.2); ghi chi tiết thu thập — loại, số lượng, nguồn, đặc tính nguồn, đặc điểm chủ thể dữ liệu, lịch sử xử lý trước đó, quyền dữ liệu (dữ liệu cá nhân, bản quyền), metadata (A.7.3); yêu cầu chất lượng đo được, xét thiên lệch (A.7.4); ghi nhận nguồn gốc qua các lần tạo, cập nhật, biến đổi, chuyển quyền kiểm soát (A.7.5); tiêu chí và phương pháp chuẩn bị dữ liệu (A.7.6).

Bằng chứng: sổ đăng ký bộ dữ liệu; báo cáo chất lượng dữ liệu; liên kết phiên bản dữ liệu ↔ phiên bản mô hình; hướng dẫn gán nhãn; hồ sơ quyền sử dụng dữ liệu.

Lỗi thường gặp: không biết mô hình đang chạy học từ bộ dữ liệu nào; dữ liệu không đại diện (chỉ ca ngày, chỉ một loại vật liệu); dùng dữ liệu khách hàng mà không kiểm tra quyền. Chi tiết: dữ liệu cho AI.

A.8 – Thông tin cho bên quan tâm (A.8.2–A.8.5)

Mục đích: bên liên quan có đủ thông tin để hiểu, đánh giá rủi ro và tác động (cả tích cực lẫn tiêu cực).

Việc cần làm thực tế:

• A.8.2: cho người dùng biết họ đang tương tác với AI (hoặc nội dung do AI tạo), mục đích, cách dùng, khi nào và cách ghi đè hệ thống, giới hạn, độ chính xác, nhu cầu giám sát của con người, thông tin liên quan từ đánh giá tác động, cập nhật thay đổi, đầu mối liên hệ, tài liệu hướng dẫn. Ghi lại tiêu chí quyết định cung cấp thông tin gì, và kiểm tra người dùng thực sự tiếp cận được.
• A.8.3: kênh để bên ngoài báo tác động bất lợi (ví dụ đối xử không công bằng).
• A.8.4: kế hoạch thông báo sự cố cho người dùng: loại sự cố, thời hạn, có báo cơ quan nào không, nội dung — có thể gộp vào quy trình sự cố chung nhưng lưu ý yêu cầu riêng của AI.
• A.8.5: xác định nghĩa vụ báo cáo thông tin về hệ thống AI cho bên quan tâm, kể cả cơ quan quản lý (tài liệu kỹ thuật, rủi ro, kết quả đánh giá tác động, log).

Bằng chứng: hướng dẫn sử dụng, thông báo “đây là AI” trên giao diện; sổ phản ánh bên ngoài; kế hoạch truyền thông sự cố; danh mục nghĩa vụ báo cáo theo luật/hợp đồng.

Lỗi thường gặp: chatbot không cho biết là AI; không có cách “gặp người thật”; quy trình sự cố chỉ nói về rò rỉ dữ liệu, không nói về AI trả lời sai hàng loạt.

Ví dụ: chatbot CSKH của một chuỗi điện máy hiển thị “Bạn đang trò chuyện với trợ lý AI”, có nút “Gặp nhân viên” và nút “Báo câu trả lời sai”.

A.9 – Sử dụng hệ thống AI (A.9.2–A.9.4)

Mục đích: dùng AI có trách nhiệm và đúng chính sách.

Việc cần làm thực tế:

• A.9.2: quy trình quyết định có dùng một hệ thống AI hay không — phê duyệt cần có, chi phí (cả giám sát, bảo trì), yêu cầu nguồn cung được duyệt, yêu cầu pháp lý.
• A.9.3: đặt mục tiêu sử dụng có trách nhiệm (công bằng, giải trình, minh bạch, giải thích được, tin cậy, an toàn, vững và dự phòng, riêng tư và bảo mật, khả năng tiếp cận) và cơ chế đạt được — đặc biệt giám sát của con người có thực chất: người xem lại có quyền ghi đè, theo dõi độ chính xác đầu ra, báo cáo lo ngại, cân nhắc quyết định tự động hoàn toàn có phù hợp không. Người giám sát phải được đào tạo và hiểu hướng dẫn.
• A.9.4: dùng đúng mục đích dự kiến và theo tài liệu đi kèm; dữ liệu đầu vào khớp điều kiện tài liệu; giám sát vận hành; nếu dùng đúng hướng dẫn vẫn gây lo ngại thì báo nội bộ và nhà cung cấp; lưu log chứng minh dùng đúng mục đích.

Bằng chứng: danh sách công cụ AI được duyệt; quy định sử dụng; hồ sơ ghi đè của con người; log vận hành; biên bản phản ánh với nhà cung cấp.

Lỗi thường gặp: nhân viên tự dùng công cụ AI ngoài danh sách; “giám sát con người” chỉ là bấm duyệt hàng loạt; dùng mô hình ngoài điều kiện được kiểm định (ảnh mờ, ánh sáng khác).

A.10 – Quan hệ bên thứ ba và khách hàng (A.10.2–A.10.4)

Mục đích: tổ chức vẫn chịu trách nhiệm giải trình, rủi ro được phân bổ hợp lý khi có bên thứ ba ở bất kỳ giai đoạn nào.

Việc cần làm thực tế: ghi lại mọi bên tham gia vòng đời (cung cấp dữ liệu, mô hình, phát triển, sử dụng) và trách nhiệm của họ, kể cả vai trò bên kiểm soát/bên xử lý dữ liệu cá nhân (A.10.2); phân loại nhà cung cấp theo rủi ro, đặt yêu cầu, theo dõi, yêu cầu khắc phục khi thành phần AI không hoạt động đúng hoặc gây tác động trái cách tiếp cận của tổ chức, đòi tài liệu đầy đủ (A.10.3); hiểu kỳ vọng khách hàng, truyền đạt giới hạn phạm vi sử dụng để khách tự xử lý phần rủi ro của họ (A.10.4).

Bằng chứng: RACI theo hệ thống; bảng đánh giá nhà cung cấp AI; điều khoản hợp đồng; tài liệu bàn giao cho khách hàng. Chi tiết: bên thứ ba và nhà cung cấp AI.

Lỗi thường gặp: coi “mua SaaS là rủi ro của nhà cung cấp”; không theo dõi khi nhà cung cấp đổi phiên bản mô hình; không nói cho khách biết giới hạn của sản phẩm AI.

Ví dụ áp dụng: nhà máy linh kiện ô tô ở Vĩnh Phúc (minh hoạ)

Hệ thống AI	Nhóm control trọng tâm	Biện pháp cụ thể
Camera AI ngoại quan (tự phát triển)	A.6, A.7	Tập kiểm thử cố định 2.000 ảnh; tiêu chí recall ≥ 99,5%; đánh giá lại khi đổi vật liệu
Dự báo bảo trì máy ép	A.6.2.6, A.9.3	Cảnh báo chỉ là khuyến nghị; kỹ sư bảo trì quyết định dừng máy và có quyền bỏ qua
Chatbot nội bộ tra quy trình	A.8.2, A.10.3	Hợp đồng nhà cung cấp cấm dùng dữ liệu để huấn luyện; nút báo sai

Lỗi hay gặp chung

• Coi Phụ lục A như checklist “có/không” mà không gắn với rủi ro cụ thể.
• Loại trừ A.5 vì “chúng tôi không ảnh hưởng xã hội” — gần như không thuyết phục.
• Không có bằng chứng cho ghi nhật ký sự kiện (log) của hệ thống AI.
• Trả lời chuyên gia đánh giá bằng bộ quy trình mẫu, không khớp hệ thống AI thật.

Câu hỏi thường gặp

Phụ lục A của 42001 có giống Phụ lục A của 27001 không? Cùng cơ chế (SoA, đối chiếu), khác nội dung: 27001 về an toàn thông tin, 42001 về AI có trách nhiệm. Hai bộ bổ sung nhau.

Phụ lục B có bắt buộc không? Phụ lục B là phụ lục quy định và điều 6.1.3 yêu cầu xem xét nó. Nhưng hướng dẫn có thể được điều chỉnh, mở rộng, hoặc thay bằng cách làm riêng phù hợp rủi ro; không cần giải trình từng gạch đầu dòng trong SoA.

Có thể dùng NIST AI RMF thay Phụ lục A? Có thể dùng làm nguồn bổ sung biện pháp, nhưng vẫn phải đối chiếu và ghi SoA với Phụ lục A.

Bước tiếp theo

• Hướng dẫn từng control (38 control)
• Tuyên bố áp dụng (SoA)
• Checklist đánh giá nội bộ ISO 42001