AI SBOM (Danh mục thành phần phần mềm AI) và tính minh bạch chuỗi cung ứng trí tuệ nhân tạo
1. Tổng quan
Định nghĩa: AI SBOM (AI Software Bill of Materials, còn gọi là AI SBOM hoặc AIBOM - danh mục thành phần phần mềm AI) là bản đặc tả cấu thành ghi lại ở dạng máy đọc được các mô hình, tập dữ liệu, phần mềm, pipeline, hạ tầng, dịch vụ bên ngoài cấu thành nên một hệ thống trí tuệ nhân tạo cùng các quan hệ chuỗi cung ứng giữa chúng, kèm theo thông tin phiên bản, nguồn gốc, giấy phép và tính toàn vẹn.
SBOM truyền thống nhận diện các gói, thư viện, container cấu thành ứng dụng và quan hệ phụ thuộc, qua đó nâng cao khả năng quan sát chuỗi cung ứng phần mềm. Hệ thống AI ngoài những thứ đó còn có các tài sản ảnh hưởng đến kết quả như trọng số mô hình, dữ liệu huấn luyện, quá trình gán nhãn, mô hình embedding, prompt, chỉ mục tìm kiếm, tập đánh giá, runtime GPU và cả API suy luận bên ngoài. Vì vậy, một SBOM chỉ liệt kê phụ thuộc mã nguồn khó giải thích đầy đủ mô hình có nguồn gốc từ đâu, được huấn luyện bằng dữ liệu nào, kế thừa từ mô hình nào và khi triển khai kết nối với những dịch vụ nào.
Mục đích của AI SBOM không đơn thuần là lập danh sách. Cốt lõi là xác nhận sự tồn tại của các thành phần, truy vết quan hệ giữa chúng và nhanh chóng đánh giá tác động của thay đổi đến hiệu năng, bảo mật và trách nhiệm pháp lý. Ví dụ, trong dịch vụ RAG, chỉ cần thay mô hình embedding cũng có thể làm thay đổi phân bố kết quả tìm kiếm và khả năng lộ thông tin cá nhân. Nếu AI SBOM liên kết mô hình, dữ liệu, chỉ mục và kết quả đánh giá, ta có thể truy ngược từ nút bị thay đổi để tìm ra các dịch vụ bị ảnh hưởng và các hạng mục cần kiểm chứng lại.
Minh bạch chuỗi cung ứng AI không chỉ là nhiệm vụ của riêng tổ chức phát triển. Người phụ trách mua sắm phải xác nhận giấy phép và giới hạn sử dụng của mô hình bên ngoài, người phụ trách bảo mật phải kiểm tra tệp mô hình độc hại và thư viện có lỗ hổng, người phụ trách bảo vệ dữ liệu cá nhân phải xác nhận căn cứ xử lý dữ liệu huấn luyện·tìm kiếm và việc phản ánh yêu cầu xóa. Tổ chức vận hành phải truy vết suy giảm chất lượng và drift sau khi cập nhật mô hình, còn tổ chức kiểm toán phải có khả năng tái hiện cấu hình và bằng chứng phê duyệt tại thời điểm ra quyết định.
Bài này trình bày theo dạng bài luận nguyên lý cấu thành AI SBOM, phương thức tạo và kiểm chứng theo vòng đời, việc sử dụng CycloneDX và SPDX, sự khác biệt so với các tài liệu hiện có, các trường hợp áp dụng và các lưu ý từ góc nhìn Kỹ sư chuyên nghiệp (Professional Engineer). AI SBOM không phải là một tài liệu đơn lẻ thay thế model card hay datasheet, mà cần được hiểu là lớp nhận diện·truy vết liên kết nhiều tài liệu mô tả với các quan hệ cấu thành được tạo tự động.
2. Nguyên lý cấu thành và đối tượng quản lý của AI SBOM
2.1 Lý do mở rộng từ SBOM truyền thống sang AI SBOM
Với gói phần mềm, chỉ cần so sánh phiên bản và hash là có thể xác nhận tương đối rõ ràng hai gói có đồng nhất hay không. Ngược lại, mô hình dù cùng tên nhưng nếu tệp trọng số, tokenizer, phương thức lượng tử hóa, system prompt và runtime suy luận khác nhau thì sẽ hành xử khác nhau. Tập dữ liệu cũng vậy, kết quả huấn luyện thực chất thay đổi theo thời điểm thu thập dữ liệu gốc, quy tắc lọc, khử trùng lặp và chất lượng nhãn. Tức là định danh của thành phần AI không thể chỉ là cái tên mà phải là tổ hợp phiên bản, nguồn gốc, lịch sử biến đổi và quan hệ.
Hơn nữa, rủi ro của hệ thống AI phát sinh không chỉ từ bản thân thành phần mà còn từ cách chúng được kết hợp. Một mô hình công khai dù an toàn nhưng khi kết hợp với agent gọi công cụ có quyền rộng sẽ trở thành bề mặt tấn công mới. Một tập dữ liệu bình thường nhưng nếu chỉ mục embedding chứa thông tin cá nhân được nối với API tìm kiếm công khai thì rủi ro tái định danh có thể tăng lên. AI SBOM biểu diễn những quan hệ kết hợp này, qua đó mở rộng phạm vi quản lý từ "cái gì đã được đưa vào" sang "chúng được kết nối thế nào và tạo ra trách nhiệm gì".
2.2 Sơ đồ khái niệm cấu thành tổng thể
flowchart LR
A[Mục tiêu nghiệp vụ·Cấp độ rủi ro] --> B[Định danh hệ thống AI]
B --> C[Mô hình·Trọng số·Tokenizer]
B --> D[Dữ liệu huấn luyện·kiểm chứng·tìm kiếm]
B --> E[Mã nguồn·Thư viện·Container]
C --> F[Pipeline huấn luyện·tinh chỉnh]
D --> F
E --> F
F --> G[Bằng chứng đánh giá·phê duyệt]
G --> H[Runtime triển khai·GPU·API]
H --> I[Giám sát·Sự cố·Lịch sử thay đổi]
I -. Truy ngược .-> C
I -. Phân tích tác động .-> D
I -. Khả năng tái lập .-> G
Trước hết cần gắn mục đích nghiệp vụ và cấp độ rủi ro vào định danh hệ thống. Nếu cùng một mô hình nền được dùng cho tư vấn khách hàng và hỗ trợ ra quyết định y tế, thì dù mô hình giống nhau, bối cảnh sử dụng, mức sai số cho phép và yêu cầu giám sát là khác nhau. Do đó, đơn vị cao nhất của AI SBOM nên là hệ thống AI hoặc đơn vị triển khai có mục đích và ranh giới vận hành, chứ không chỉ là tệp mô hình.
Vùng mô hình ghi lại tên mô hình, phiên bản, kiến trúc, định danh trọng số, dòng dõi mô hình nền, việc có fine-tuning hay không và tokenizer. Vùng dữ liệu liên kết tên và phiên bản tập dữ liệu, nguồn gốc, căn cứ thu thập·đồng ý, tiền xử lý, gán nhãn, phân chia, thời hạn lưu giữ và xử lý xóa. Vùng mã nguồn trùng với SBOM thông thường nhưng phải bao gồm cả framework huấn luyện·suy luận và công cụ chuyển đổi mô hình.
Vùng pipeline gắn trực tiếp với khả năng tái lập của huấn luyện và triển khai. Nếu liên kết commit mã huấn luyện, siêu tham số, GPU sử dụng, tập đánh giá và kết quả với một thí nghiệm hoặc một bản phát hành mô hình, ta có thể kiểm chứng được cách nói "cùng một mô hình". Với RAG, việc thu thập tài liệu, chunking, embedding, cơ sở dữ liệu vector, xếp hạng tìm kiếm và prompt template cũng phải được biểu diễn thành quan hệ. Vùng vận hành chứa khu vực (region) triển khai, endpoint, API bên ngoài, quyền, giám sát và ticket sự cố, nhằm thu hẹp khác biệt giữa cấu hình thực sự được dùng và sản phẩm phát triển.
2.3 Thông tin cốt lõi theo đối tượng quản lý
| Đối tượng quản lý | Thông tin cốt lõi cần ghi | Mục đích quản lý |
|---|---|---|
| Mô hình·Trọng số | Tên, phiên bản, hash, mô hình nền, lịch sử fine-tuning·lượng tử hóa, giấy phép | Xác nhận tính đồng nhất·dòng dõi·quyền sử dụng mô hình |
| Tập dữ liệu | Nguồn gốc, thời điểm thu thập, xử lý·gán nhãn, đồng ý·giấy phép, phân chia, chỉ số chất lượng | Ứng phó quyền dữ liệu·chất lượng·thiên lệch·xóa |
| Phần mềm | Gói, phiên bản, hash, lỗ hổng, giấy phép, quan hệ build | Quản lý lỗ hổng chuỗi cung ứng mã và khả năng tái lập |
| Pipeline | Các bước huấn luyện·đánh giá·tìm kiếm, commit mã, tham số, phiên bản công cụ | Tái lập thí nghiệm và phân tích tác động thay đổi |
| Hạ tầng | GPU·TPU, runtime, container, region, kho lưu trữ, ranh giới mạng | Phân tích bảo mật·hiệu năng·chi phí·sự cố vận hành |
| Dịch vụ bên ngoài | Nhà cung cấp, phiên bản API, hợp đồng·SLA, vị trí xử lý dữ liệu, lịch sử sự cố | Quản lý rủi ro chuỗi cung ứng bên thứ ba·bậc N |
| Quản trị | Mục đích, cấp độ rủi ro, người phê duyệt, kết quả đánh giá, điều kiện hạn chế, kế hoạch hủy bỏ | Trách nhiệm giải trình·khả năng kiểm toán·tuân thủ quy định |
Chỉ điền đủ các hạng mục trong bảng thì tính minh bạch vẫn chưa hoàn chỉnh.
Ví dụ, dù đã ghi URL nguồn gốc của tập dữ liệu, nhưng nếu không liên kết được bản ghi nào đã bị loại khi tiền xử lý hay trọng số mô hình đã dùng phiên bản nào của tập dữ liệu đó, thì việc truy vết sẽ bị đứt đoạn.
Do đó, mỗi hạng mục phải có định danh duy nhất và thời điểm tạo, và được liên kết thành đồ thị qua các quan hệ như derived-from, uses, trained-on, deployed-as, evaluated-by.
3. Quy trình tạo và kiểm chứng theo vòng đời
3.1 Luồng tạo·tiêu thụ·phản hồi
flowchart TD
A[Lập kế hoạch·Mua sắm] --> B[Đăng ký tài sản và phân loại rủi ro]
B --> C[Thu thập dữ liệu·mô hình·mã]
C --> D[Tự động tạo AI SBOM]
D --> E[Kiểm chứng lược đồ·hash·quan hệ]
E --> F{Đạt chính sách?}
F -- Không --> G[Chặn·Bổ sung·Phê duyệt ngoại lệ]
G --> C
F -- Có --> H[Ký·Lưu trữ·Triển khai]
H --> I[Giám sát runtime]
I --> J[Sự kiện thay đổi·lỗ hổng·sự cố]
J --> D
H --> K[Kiểm toán·Phân tích tác động·Hủy bỏ]
Ở giai đoạn lập kế hoạch, xác định mục đích hệ thống, người dùng, mức tự động hóa cho phép và cấp độ rủi ro. Ngay từ giai đoạn này đã phải đưa vào hợp đồng và tiêu chí mua sắm việc yêu cầu chủ sở hữu và nhà cung cấp tài sản AI cung cấp những trường AI SBOM nào. Bởi vì nếu sau này nhà cung cấp mô hình không công khai nguồn gốc và thông tin dữ liệu huấn luyện thì rất khó bổ sung ở giai đoạn vận hành.
Ở giai đoạn phát triển, thu thập dữ kiện từ kho mã, model registry, data catalog, hệ thống theo dõi thí nghiệm và CI/CD thay vì dùng bảng hỏi thủ công. Tệp mô hình được ghi kèm hash mạnh và phiên bản trong model registry, còn tập dữ liệu được ghi quan hệ giữa bản gốc và bản dẫn xuất cùng quyền truy cập. Các chính sách, hạn chế và yêu cầu giám sát của con người không thể thu thập tự động được tách thành vùng bằng chứng do người phụ trách ký, nhưng phải liên kết tới tài liệu căn cứ của giá trị đó.
Ở giai đoạn kiểm chứng, thực hiện tách biệt kiểm chứng hình thức và kiểm chứng nội dung. Kiểm chứng hình thức xác nhận lược đồ, trường bắt buộc, cú pháp định danh và tính toàn vẹn tham chiếu của các quan hệ. Kiểm chứng nội dung xác nhận hash mô hình có khớp với tệp triển khai thực tế không, giấy phép có cho phép mục đích sử dụng không, quyền truy cập dữ liệu đã được phê duyệt chưa, và kết quả đánh giá có thuộc về phiên bản hiện tại không.
Ở giai đoạn triển khai, ký AI SBOM như một artifact phát hành và lưu giữ cùng mô hình, container và manifest. Nếu hash của mô hình đã triển khai hoặc phiên bản API bên ngoài không khớp với AI SBOM, policy engine sẽ dừng triển khai hoặc chuyển sang thủ tục phê duyệt ngoại lệ. Nguyên tắc quan trọng ở giai đoạn vận hành là không tạo SBOM một lần rồi quên đi. Mỗi khi có cập nhật mô hình, xóa dữ liệu, công bố lỗ hổng, thay đổi API bên ngoài, thay đổi prompt hoặc sự cố, cần tạo phiên bản mới và lưu lại khác biệt so với phiên bản trước.
3.2 Mô hình dữ liệu tối thiểu và ý nghĩa của bằng chứng
Bản ghi AI SBOM nhìn chung có thể được thiết kế với cấu trúc component, version, supplier, license, hash, relationship, source, timestamp, lifecycle, evidence.
component phân biệt loại mô hình, dữ liệu, mã, dịch vụ, còn relationship biểu diễn quan hệ cấu thành, dẫn xuất, huấn luyện, triển khai, đánh giá.
evidence liên kết định danh của model card, datasheet, báo cáo đánh giá, hợp đồng và ticket phê duyệt.
Như vậy AI SBOM không phải vật thay thế tài liệu mô tả mà trở thành chỉ mục để xác nhận tính xác thực và phạm vi áp dụng của tài liệu mô tả.
Định danh cần có cả tên để con người đọc và định danh ổn định để máy so sánh.
Hash tệp hữu ích để xác định có phải cùng một tệp không, nhưng không bảo đảm được cả thay đổi về ngữ nghĩa của tập dữ liệu hay thay đổi hành vi của API bên ngoài.
Vì vậy với tập dữ liệu phải ghi thêm phiên bản, snapshot, điều kiện thu thập; với API phải ghi thêm nhà cung cấp, phiên bản hợp đồng, chính sách định tuyến mô hình.
Để trống giá trị "không biết" cũng là rủi ro.
Giá trị chưa xác nhận được cần ghi rõ là unknown, kèm theo người chịu trách nhiệm, thời hạn xác nhận và việc có chấp nhận rủi ro hay không, thì mới làm lộ ra được các điểm mù quản lý.
3.3 Chỉ số kiểm chứng chất lượng
Chất lượng AI SBOM được đánh giá theo mức độ có thể sử dụng cho ra quyết định thực tế hơn là theo độ dài tài liệu. Thứ nhất, tính đầy đủ nghĩa là các mô hình, dữ liệu, mã, dịch vụ đã biết đều được biểu diễn không bỏ sót. Thứ hai, tính chính xác nghĩa là bản ghi khớp với phiên bản và hash của sản phẩm thực tế. Thứ ba, tính cập nhật nghĩa là sau khi thay đổi, SBOM được tạo lại trong khoảng thời gian quy định. Thứ tư, tính truy vết nghĩa là có thể di chuyển hai chiều từ thành phần tới dịch vụ triển khai và bằng chứng phê duyệt.
Ví dụ, tổ chức có thể đặt các chỉ số như "tỷ lệ tạo AI SBOM thành công trong các bản phát hành của hệ thống quan trọng 100%", "tỷ lệ phản ánh thay đổi mô hình·dữ liệu trong vòng 24 giờ 95%", "tỷ lệ chỉ định chủ sở hữu cho thành phần quan trọng 100%". Tuy nhiên, nếu chỉ nâng tỷ lệ tạo mà không kiểm tra độ chính xác của các quan hệ bắt buộc thì sẽ thành tự động hóa vỏ rỗng. Cần có kiểm toán chất lượng đối chiếu hash mô hình, snapshot dữ liệu, manifest triển khai trong SBOM với hệ thống thực tế đối với các bản phát hành được lấy mẫu.
4. So sánh tiêu chuẩn và các tài liệu tương tự
4.1 Sử dụng CycloneDX và SPDX
CycloneDX là định dạng có thể biểu diễn phần mềm, phần cứng, dịch vụ, phụ thuộc, lỗ hổng và mô hình học máy trong một mô hình BOM duy nhất. CycloneDX 1.7 công bố tháng 10/2025 đã được chấp nhận thành ECMA-424 ấn bản thứ 2 vào tháng 12/2025, và được mô tả là BOM đa dụng bao gồm mô hình học máy và minh bạch chuỗi cung ứng. Nếu tổ chức đã dùng pipeline tạo SBOM sẵn có thì ưu điểm là dễ liên kết các yếu tố liên quan đến mô hình và dữ liệu vào cùng hệ sinh thái BOM.
Dòng SPDX 3.0 cung cấp AI Profile và Dataset Profile như các profile tách biệt. AI Profile xử lý việc trao đổi hệ thống AI và sản phẩm mô hình, các thành phần phần mềm liên quan và phụ thuộc, còn Dataset Profile xử lý thông tin như tên, phiên bản, nguồn gốc, giấy phép, đặc tính của tập dữ liệu. Do đó phù hợp với tổ chức muốn trao đổi chi tiết cấu hình AI và mô tả dữ liệu, nhưng phải thiết kế quan hệ giữa nhiều profile và xác nhận phạm vi hỗ trợ của công cụ tiêu thụ.
| Tiêu chí so sánh | CycloneDX 1.7 | Dòng SPDX 3.0 |
|---|---|---|
| Góc nhìn trung tâm | Biểu diễn nhiều loại BOM bằng một mô hình đối tượng | Biểu diễn phạm vi trao đổi BOM và tính phù hợp theo profile |
| Biểu diễn AI·ML | Tích hợp mô hình học máy, cấu hình, dòng dõi·nguồn gốc vào BOM đa dụng | Phân tách vùng AI·dữ liệu bằng AI Profile và Dataset Profile |
| Bối cảnh tiêu chuẩn hóa | Dựa trên dự án OWASP, được chấp nhận thành ECMA-424 ấn bản 2 | Dòng dõi tiêu chuẩn quốc tế SPDX và cấu trúc profile 3.0 |
| Thế mạnh khi áp dụng | Dễ kết nối với CI/CD và công cụ SBOM hiện có | Khả năng tương tác theo profile cho AI·dữ liệu·giấy phép |
| Điểm lưu ý | Phải thiết kế mở rộng các trường quản trị AI của tổ chức | Phải kiểm chứng tổ hợp profile và mức hỗ trợ của công cụ |
Chọn một trong hai định dạng không có nghĩa là đã hoàn tất thiết kế quản trị AI. Tiêu chuẩn thống nhất cú pháp và ngữ nghĩa dữ liệu, nhưng trường nào là bắt buộc, công khai nguồn gốc dữ liệu huấn luyện nhạy cảm đến mức nào, ai phê duyệt rủi ro là vấn đề chính sách của tổ chức. Trong thực tế, cũng có thể áp dụng chiến lược tạo bằng định dạng mà pipeline và công cụ nội bộ hỗ trợ tốt, rồi chuyển đổi sang định dạng được yêu cầu khi mua sắm từ nhà cung cấp hoặc trao đổi kiểm toán. Phải lưu giữ định danh gốc và log chuyển đổi để dòng dõi mô hình hay quan hệ dữ liệu không bị mất trong quá trình chuyển đổi.
4.2 Khác biệt với model card, datasheet và SBOM
Model card mô tả dễ đọc cho con người về mục đích sử dụng dự kiến, giới hạn, kết quả đánh giá và các cân nhắc đạo đức của mô hình. Datasheet hoặc data card mô tả việc thu thập, cấu thành, xử lý, chất lượng và ràng buộc của dữ liệu. SBOM thông thường tập trung vào thành phần phần mềm và quan hệ phụ thuộc, lỗ hổng và giấy phép. AI SBOM không thay thế các tài liệu này mà liên kết từng sản phẩm với các thành phần phát hành thực tế bằng định danh và quan hệ.
| Tài liệu | Câu hỏi chính | Thế mạnh | Quan hệ với AI SBOM |
|---|---|---|---|
| Model card | Mô hình này có mục đích sử dụng và giới hạn gì? | Hướng dẫn diễn giải·sử dụng và mô tả đánh giá | Bằng chứng mô tả cho bản ghi mô hình |
| Datasheet·Data card | Dữ liệu được tạo ra thế nào và có ràng buộc gì? | Bối cảnh nguồn gốc·chất lượng·thiên lệch·xử lý | Căn cứ cho bản ghi tập dữ liệu |
| SBOM thông thường | Cấu thành phần mềm và lỗ hổng là gì? | Tự động hóa gói·phiên bản·giấy phép | Tập con phần mã của AI SBOM |
| AI SBOM | Hệ thống AI hiện tại gồm những gì và được kết nối ra sao? | Dòng dõi·thay đổi·phân tích tác động·truy vết chuỗi cung ứng | Điểm chuẩn liên kết các tài liệu và sản phẩm khác |
Tài liệu càng nhiều thì thiết kế giảm nhập liệu trùng lặp càng quan trọng. Ví dụ, nếu phiên bản mô hình trong model card và trong AI SBOM khác nhau thì không thể biết tài liệu nào là mới nhất. Cách phù hợp là lấy định danh duy nhất của model registry làm chuẩn để tài liệu mô tả, kết quả đánh giá, BOM triển khai cùng tham chiếu, còn phần thân tài liệu giữ phần giải thích dành cho con người.
5. Kiến trúc triển khai và biện pháp kiểm soát
5.1 Kiến trúc tham chiếu
Kho AI SBOM liên kết với data catalog, model registry, kho mã, CI/CD, nền tảng đánh giá và nền tảng triển khai. Bộ thu thập đọc thông tin cấu hình từ từng hệ thống và chuyển thành đối tượng chuẩn, còn bộ phân tích quan hệ bổ sung các quan hệ huấn luyện, dẫn xuất, triển khai, đánh giá. Policy engine kiểm tra tại cổng phát hành các điều kiện như cấm giấy phép, chưa xác nhận nguồn gốc, chưa hoàn tất đánh giá rủi ro, runtime có lỗ hổng, hash không khớp. Kho BOM đã ký bảo đảm tính bất biến theo từng bản phát hành, còn chỉ mục tìm kiếm giúp thực hiện nhanh kiểm toán và phân tích tác động.
Quyền được tách thành người tạo, người tiêu thụ và người kiểm toán. Nhà phát triển có thể tạo thành phần mô hình và mã nhưng có thể không cần xem chi tiết nguyên văn dữ liệu chứa thông tin cá nhân. Người kiểm toán cần đọc được quan hệ và bằng chứng phê duyệt nhưng không cần có quyền tải trọng số hay dữ liệu gốc. Bản thân AI SBOM cũng có thể chứa thông tin nhà cung cấp nhạy cảm và thông tin lỗ hổng bảo mật nên cần tách các view công khai, nội bộ và hạn chế.
5.2 Quy trình triển khai áp dụng
- Trước tiên xác định phạm vi hệ thống nghiệp vụ và tài sản AI, chỉ định chủ sở hữu cho mô hình, dữ liệu, mã, dịch vụ, hạ tầng.
- Tiếp theo khảo sát các trường đã có thể lấy được từ SBOM, data catalog, model registry hiện có để giảm thu thập trùng lặp.
- Chọn AI tạo sinh có rủi ro cao, API mô hình bên ngoài, hệ thống xử lý thông tin cá nhân làm đối tượng thí điểm.
- Xác định định dạng chuẩn và tài liệu hóa thành chính sách các trường bắt buộc,
unknownđược phép, thời hạn lưu giữ bằng chứng, sự kiện thay đổi. - Tự động tạo AI SBOM trong CI/CD khi commit, build, đăng ký mô hình và coi việc tạo thất bại là phát hành thất bại.
- Lưu giữ manifest triển khai cùng BOM đã ký và đối chiếu với cấu hình thực tế ở runtime.
- Khi phát sinh sự kiện lỗ hổng, giấy phép, xóa dữ liệu, model drift, dùng phân tích tác động để tìm các hệ thống liên quan và đánh giá lại.
- Hằng quý chọn mẫu bản phát hành để kiểm toán tính đầy đủ, chính xác, cập nhật, truy vết và cải tiến chính sách.
5.3 Kiểm soát bảo mật và thông tin cá nhân
AI SBOM nâng cao tính minh bạch nhưng cũng có thể cung cấp thông tin cấu hình cho kẻ tấn công. Nếu công khai nguyên vẹn ra bên ngoài vị trí tệp mô hình, thư viện có lỗ hổng, API nội bộ và tên tập dữ liệu, chúng sẽ trở thành thông tin trinh sát cho tấn công chuỗi cung ứng. Vì vậy BOM công khai bên ngoài chỉ cung cấp thông tin tối thiểu và định danh tóm tắt, còn BOM chi tiết đặt dưới xác thực mạnh và quyền theo mục đích.
Ghi lại nguồn gốc dữ liệu huấn luyện khác với sao chép thông tin cá nhân gốc vào BOM.
BOM chỉ lưu tham chiếu tới định danh trong data catalog, căn cứ xử lý, chính sách lưu giữ, trạng thái yêu cầu xóa, còn nguyên văn đặt ở kho lưu trữ được bảo vệ riêng.
Khi có yêu cầu xóa hoặc đính chính, phải tìm các mô hình, embedding, cache, bản sao lưu được dẫn xuất từ phiên bản tập dữ liệu đó để quyết định phạm vi huấn luyện lại và triển khai lại.
Khi đó, các quan hệ trained-on và derived-from của AI SBOM hỗ trợ phân tích tác động đối với xử lý thông tin cá nhân.
Áp dụng chữ ký điện tử cho trọng số mô hình và BOM, và bảo vệ khóa ký trong hệ thống quản lý khóa riêng. Việc BOM không bị giả mạo không có nghĩa là mô hình an toàn, nhưng đó là nền tảng để phân biệt cấu hình tại thời điểm phát hành với các thay đổi về sau. Mô hình và dữ liệu bên ngoài chỉ được đăng ký vào registry khi đã vượt qua kiểm tra nhà cung cấp tin cậy, xác minh hash, quét tệp độc hại, kiểm tra giấy phép và xác nhận kết quả đánh giá.
6. Trường hợp áp dụng
6.1 Trường hợp 1: Dịch vụ RAG tri thức nội bộ
Giả định một doanh nghiệp vận hành dịch vụ RAG tìm kiếm quy chế nội bộ và tài liệu dự án để trả lời câu hỏi. Ban đầu chỉ quản lý tên LLM và khóa API, nhưng sau khi thay đổi mô hình embedding và quy tắc chunking, độ chính xác tìm kiếm và kiểm soát truy cập có thể cùng bị lung lay. AI SBOM liên kết snapshot của kho tài liệu gốc, commit thu thập tài liệu, phiên bản chunking, hash mô hình embedding, phiên bản chỉ mục vector, cấu hình xếp hạng tìm kiếm, prompt template và phiên bản API LLM bên ngoài.
Khi có yêu cầu xóa thông tin cá nhân, tìm đối tượng cần xóa trong data catalog và lần theo quan hệ trong AI SBOM để truy vấn snapshot tài liệu, embedding, chỉ mục, cache và tập đánh giá. Với các lần triển khai thay mô hình, tính toán khác biệt giữa BOM cũ và BOM mới rồi thực hiện lại đánh giá chất lượng tìm kiếm, vượt quyền và tỷ lệ ảo giác (hallucination). Cách này cho phép giải thích nguyên nhân và tác động của thay đổi, hơn hẳn việc chỉ ghi "có sử dụng RAG".
6.2 Trường hợp 2: Mua sắm mô hình nền từ bên ngoài
Giả định một công ty tài chính mua mô hình nền của nhà cung cấp bên ngoài để hỗ trợ tư vấn.
Trước khi ký hợp đồng, yêu cầu phiên bản·trọng số hoặc phiên bản API của mô hình, phạm vi công khai nguồn gốc dữ liệu huấn luyện, quyền sử dụng thương mại, việc có dùng dữ liệu đầu vào để huấn luyện lại hay không, điều kiện thông báo sự cố·cập nhật.
Liên kết AI SBOM, model card, báo cáo đánh giá do nhà cung cấp cung cấp với bản ghi nội bộ; các trường không được công khai để là unknown rồi chỉ định người chấp nhận rủi ro và thời hạn bổ sung.
Sau khi triển khai, nếu nhà cung cấp thay đổi định tuyến mô hình thì dù cùng tên API, cấu hình thực chất đã khác. Nhận sự kiện thông báo thay đổi theo SLA để lưu BOM mới, và đánh giá lại độ chính xác, thiên lệch, thông tin cá nhân, khả năng giải thích cần thiết cho mục đích sử dụng là tư vấn tài chính. Khi kết thúc hợp đồng, xác nhận phạm vi hoàn trả và xóa mô hình, prompt, dữ liệu tìm kiếm, log, sản phẩm dẫn xuất bằng các quan hệ trong BOM. Trong trường hợp này, AI SBOM vừa là tài liệu kỹ thuật vừa đóng vai trò điểm chuẩn cho mua sắm, kiểm toán và phân định trách nhiệm.
7. Chuyên sâu: Xu hướng tiêu chuẩn·chính sách năm 2026 và điểm ra đề
Gần đây, thảo luận về chuỗi cung ứng AI đang mở rộng từ cạnh tranh hiệu năng mô hình sang cạnh tranh về kiểm chứng cấu thành và nguồn gốc. Hướng dẫn về các yếu tố tối thiểu của AI SBOM do CISA và các đối tác quốc tế đưa ra đề xuất hướng bổ sung thông tin minh bạch ở cấp mô hình, dữ liệu, hệ thống vốn khó nắm bắt chỉ bằng SBOM truyền thống. Tuy nhiên, không nên diễn giải các yếu tố tối thiểu trong tài liệu hướng dẫn thành danh mục kiểm tra bắt buộc thay thế hoàn toàn rủi ro và quy định ngành của mọi tổ chức; tổ chức phải mở rộng các trường cho phù hợp với bối cảnh sử dụng và cấp độ rủi ro.
CycloneDX 1.7 và ECMA-424 ấn bản 2 đã phát triển thành BOM đa dụng có thể biểu diễn không chỉ phần mềm và phần cứng mà cả dịch vụ, lỗ hổng, tài sản mật mã, mô hình học máy từ góc độ minh bạch chuỗi cung ứng. Dòng SPDX 3.0 cung cấp cấu trúc profile để trao đổi thông tin về hệ thống·mô hình AI và tập dữ liệu thông qua AI Profile và Dataset Profile. Hai định dạng không phải quan hệ cạnh tranh buộc phải chọn một, mà là phương tiện tương tác có thể lựa chọn hoặc chuyển đổi tùy theo hệ sinh thái công cụ, yêu cầu mua sắm và mức trưởng thành quản trị dữ liệu.
Trong bài thi Kỹ sư chuyên nghiệp (Professional Engineer), nếu chỉ định nghĩa AI SBOM là "danh sách thành phần AI" đơn thuần thì chưa đủ.
Thứ nhất, phải giải thích khác biệt so với SBOM hiện có thông qua quan hệ giữa mô hình, dữ liệu, pipeline, dịch vụ bên ngoài.
Thứ hai, phải đưa ra vòng khép kín gồm tạo tự động và ký, cổng phát hành, đối chiếu runtime, phân tích tác động thay đổi.
Thứ ba, phải bàn cả sự đánh đổi giữa minh bạch và bảo mật, thu thập dữ liệu tối thiểu và yêu cầu xóa, xử lý unknown đối với thông tin nhà cung cấp không công khai.
Cuối cùng, ở phần kết luận phải nhấn mạnh rằng điều kiện thành công là quản trị gồm người chịu trách nhiệm, chỉ số chất lượng, kiểm toán, phê duyệt ngoại lệ chứ không phải bản thân định dạng chuẩn.
8. Lưu ý và hàm ý
8.1 Tính nhất quán của phạm vi và đơn vị nhận diện
Mỗi tổ chức có thể khác nhau trong việc lấy mô hình hay dịch vụ làm đơn vị cao nhất của AI SBOM. Tuy nhiên, nếu mỗi dự án tự quyết tùy ý thì sẽ đếm một mô hình nhiều lần hoặc bỏ sót các phụ thuộc dữ liệu·công cụ ẩn trong một dịch vụ. Cần lấy định danh hệ thống có mục đích nghiệp vụ, ranh giới triển khai, cấp độ rủi ro làm chuẩn, bên dưới liên kết phân cấp mô hình, dữ liệu, mã, dịch vụ.
8.2 Tách biệt tự động hóa và phán đoán của con người
Mã, container, hash mô hình, phiên bản pipeline nên được tạo tự động tối đa để nâng cao tính cập nhật và chính xác. Ngược lại, mục đích sử dụng, căn cứ đồng ý, mức thiên lệch cho phép, giám sát của con người và chấp nhận rủi ro không thể quyết định chỉ bằng quét tự động. Nên phân biệt vùng tạo tự động với vùng phê duyệt của người chịu trách nhiệm, và yêu cầu tài liệu căn cứ cùng ngày hết hạn cho cả dữ liệu nhập thủ công.
8.3 Bảo toàn ngữ nghĩa hơn là chọn tiêu chuẩn
Khi chuyển đổi giữa CycloneDX và SPDX, nếu chỉ chuyển tên và phiên bản thì ý nghĩa của dòng dõi mô hình, xử lý dữ liệu, bằng chứng đánh giá có thể bị mất. Trước khi chọn tiêu chuẩn, tổ chức cần liệt kê các quan hệ và trường cần thiết, và đo lường mất mát thông tin bằng kiểm thử chuyển đổi. Các giá trị không thể chuyển đổi không được tùy ý bỏ đi mà phải lưu giữ bằng trường mở rộng hoặc tham chiếu ngoài.
8.4 Cân bằng giữa bảo mật và công khai
Minh bạch giúp phát hiện rủi ro chuỗi cung ứng, nhưng bản thân BOM chi tiết có thể trở thành thông tin vận hành nhạy cảm. Cần tạo view riêng cho nhà cung cấp bên ngoài, người kiểm toán, nhà phát triển, người vận hành, và giới hạn thông tin lỗ hổng và vị trí nội bộ theo đặc quyền tối thiểu. Phân loại tính toàn vẹn, sẵn sàng, bảo mật của BOM như tài sản trong hệ thống quản lý an toàn thông tin và xác định chính sách lưu giữ·hủy bỏ.
8.5 Thông tin cá nhân và chủ quyền dữ liệu
Càng ghi chi tiết nguồn gốc và dòng dõi dữ liệu thì nguy cơ sao chép quá mức thông tin cá nhân gốc càng lớn. AI SBOM cần được thiết kế là nơi tham chiếu data catalog và hồ sơ xử lý chứ không phải nơi lưu giữ bản gốc, và liên kết yêu cầu xóa·đính chính tới cả mô hình dẫn xuất và embedding. Khi dùng đám mây ở nước ngoài hoặc API bên ngoài, cần ghi rõ trong bản ghi nhà cung cấp khu vực xử lý, việc có dùng để huấn luyện lại, chuyển dữ liệu ra nước ngoài và quan hệ ủy thác.
8.6 Hệ thống chất lượng·vận hành liên tục
AI SBOM không phải công việc tài liệu cho một lần phát hành mà là một phần của quản lý thay đổi và quan sát vận hành. Cần định nghĩa model drift, thay đổi phân bố dữ liệu, thông báo lỗ hổng, thay đổi API bên ngoài, ticket sự cố là các sự kiện cập nhật SBOM, và bảo đảm kết quả phân tích tác động dẫn tới đánh giá lại. Báo cáo đồng thời các chỉ số đầy đủ, chính xác, cập nhật, truy vết cho ban lãnh đạo và tổ chức kỹ thuật để vừa kiểm soát chi phí vừa ưu tiên lấp các khoảng trống của hệ thống quan trọng.
Tài liệu tham khảo
- CISA, Software Bill of Materials for AI - Minimum Elements: https://www.cisa.gov/resources-tools/resources/software-bill-materials-ai-minimum-elements
- CISA, 2026 Minimum Elements for a Software Bill of Materials: https://www.cisa.gov/resources-tools/resources/2026-minimum-elements-software-bill-materials-sbom
- Ecma International, ECMA-424, 2nd edition, December 2025: https://ecma-international.org/publications-and-standards/standards/ecma-424/
- CycloneDX Specification Overview: https://cyclonedx.org/specification/overview/
- CycloneDX Authoritative Guide to ML-BOM: https://cyclonedx.org/guides/OWASP_CycloneDX-Authoritative-Guide-to-AI-ML-BOM-en.pdf
- SPDX Specification 3.0.1 AI Profile: https://spdx.github.io/spdx-spec/v3.0.1/model/AI/AI/
- SPDX Specification 3.0.1 Conformance: https://spdx.github.io/spdx-spec/v3.0.1/conformance/
- NIST AI Risk Management Framework: https://www.nist.gov/itl/ai-risk-management-framework
Tóm tắt một câu: AI SBOM là nền tảng vận hành quản lý cấu thành và dòng dõi của mô hình, dữ liệu, mã, pipeline, dịch vụ dưới dạng các quan hệ có thể ký và kiểm chứng, qua đó nâng cao tính minh bạch, khả năng tái lập, phân tích tác động và trách nhiệm giải trình của chuỗi cung ứng AI.