SAFE RFC: Cơ chế trao đổi sự cố AI theo kiểu hàng không của OSAA là một bản dự thảo mở, chưa phải là một hệ thống

Vào ngày 4 tháng 8 năm 2026, khi Black Hat USA khai mạc tại Las Vegas, Linux Foundation đã công bố Bản Yêu cầu Nhận xét (Request for Comments) cho Nhóm làm việc Shared AI Findings Exchange (SAFE) — một đề xuất để các tổ chức báo cáo các sự cố an ninh AI và các tình huống suýt xảy ra vào một kênh chia sẻ bảo mật, cùng nhau học hỏi từ chúng và công bố các biện pháp kiểm soát phòng thủ được rút ra từ những gì đã thất bại. Bản thảo ban đầu được phát triển bởi những người đóng góp từ Cisco, CrowdStrike, Hugging Face, NVIDIA và Red Hat, cùng với các thành viên liên minh khác, Linux Foundation cho biết trong thông báo của mình. Cùng ngày, nó đã được mở để cộng đồng xem xét thông qua kho GitHub của Open Secure AI Alliance. Mục nhập không mô tả bất kỳ tổn hại nào: đây là một hồ sơ chính sách, được lưu trong kho lưu trữ với mức độ nghiêm trọng info và mức độ tin cậy A, và đối tượng của nó là một quy trình chứ không phải một sự kiện. Mức độ nghiêm trọng, xếp hạng độ tin cậy và danh sách nguồn của hồ sơ nằm trong kho lưu trữ sự cố AI, cùng với các mục được lưu xung quanh nó.

Bản dự thảo yêu cầu các thành viên báo cáo bốn điều, và bỏ qua lý do tại sao.

Văn bản tháng Tám không có nhiều lời lẽ hoa mỹ và rất cụ thể về các điều kiện kích hoạt. Dưới tiêu đề có tên Reporting Compact, văn bản yêu cầu các thành viên đồng ý — như một điều kiện của tư cách thành viên — báo cáo một sự cố khi họ biết hoặc nghi ngờ một cách hợp lý rằng một hệ thống AI do họ vận hành đã làm một trong bốn việc: truy cập, khai thác, làm gián đoạn, lạm dụng hoặc sửa đổi hệ thống của bên thứ ba mà không được phép; gây tác động đến bên thứ ba bằng cách thoát khỏi hoặc vượt qua ranh giới sandbox, mạng, danh tính, chính sách hoặc công cụ; truy cập thông tin mật của bên thứ ba mà không có sự đồng ý của chủ sở hữu; hoặc tiếp tục thăm dò, truy cập hoặc sửa đổi một mục tiêu trong môi trường sản xuất sau khi bên vận hành biết, hoặc nghi ngờ một cách hợp lý, rằng hoạt động đó là không được phép hoặc nằm ngoài phạm vi đã được phê duyệt.

Tiếp đến là câu đóng vai trò chủ chốt: “Ý định không quyết định liệu một sự kiện có thuộc diện phải báo cáo hay không. Việc tin rằng một môi trường đã được mô phỏng có thể giải thích một sự cố, nhưng không xóa bỏ nghĩa vụ báo cáo sự cố đó.” Mệnh đề đó dường như nhắm đến trường hợp một hệ thống đang chạy trong môi trường mà người vận hành tin là môi trường kiểm thử kín và coi hạ tầng đang hoạt động là một phần của bài diễn tập: niềm tin của người vận hành về môi trường có thể giải thích sự kiện, nhưng không xóa bỏ nghĩa vụ báo cáo. Bản dự thảo cũng yêu cầu các thành viên báo cáo các sự kiện suýt xảy ra sự cố, không chỉ những sự kiện đã gây ra thiệt hại được xác nhận, và nộp một phân tích sơ bộ về lỗi kiểm soát trong vòng 30 ngày.

Thời hạn: ngay lập tức, 72 giờ, bốn ngày làm việc, chín mươi ngày

Bảng thông báo trong dự thảo là nội dung cụ thể nhất trong đó, và dòng đầu tiên hoàn toàn không phải là một thời hạn: tổ chức bị ảnh hưởng trực tiếp phải được thông báo ngay lập tức. Mọi thời hạn đều được tính từ thời điểm thành viên biết được các sự việc tạo cơ sở hợp lý để nghi ngờ có một sự kiện phải báo cáo — chứ không phải từ thời điểm cuộc điều tra kết thúc. Bảng dưới đây được sao lại từ bản dự thảo ngày 4 tháng 8; bản sửa đổi tháng 10 giữ nguyên các khoảng thời gian như vậy.

Ba trong số các hàng đó nói về việc thông báo cho người khác, và bốn hàng nói về việc thông báo cho chính SAFE. Sự phân biệt này quan trọng vì khuôn khổ này rõ ràng không phải là một chế độ công bố thông tin: dự thảo nêu rằng "Các mốc thời gian này không thay thế bất kỳ nghĩa vụ nào của nhà cung cấp trong việc thông báo cho các bên bị ảnh hưởng, thông báo cho khách hàng thông qua các thông lệ tốt nhất hiện hành về Coordinated Vulnerability Disclosure, hay các nghĩa vụ hợp đồng và nghĩa vụ pháp lý khác liên quan đến việc thông báo cho cơ quan quản lý hoặc cơ quan thực thi pháp luật." Những gì SAFE bổ sung là một nghĩa vụ song song đối với một cơ quan không phải là cơ quan quản lý — cùng với một mô hình công bố ba cấp, trong đó chỉ cấp cuối cùng, báo cáo an toàn công cộng, là nhằm mục đích được chia sẻ rộng rãi.

Tám lớp kiểm soát vào tháng Tám, mười một lớp vào tháng Mười

Các đánh giá được tổ chức xoay quanh ngăn xếp vận hành chứ không chỉ xoay quanh mô hình. Bản dự thảo tháng Tám đã liệt kê tám lớp và đặt một câu hỏi cho mỗi lớp — liệu mô hình có nhận ra sự không chắc chắn và các điều kiện dừng hay không; các giả định về quyền hạn và môi trường có được nêu rõ ràng hay không; các bộ phân loại, phê duyệt và giới hạn hành động có hoạt động hay không; thông tin xác thực, quyền và việc thực thi có bị ràng buộc hay không; cô lập và ranh giới dữ liệu có được xác minh độc lập hay không; người vận hành có thể phát hiện và ngắt trong thời gian thực hay không; các đường leo thang và quy trình dừng khẩn cấp có rõ ràng hay không; liệu một đối tác đám mây, đánh giá, dữ liệu hoặc công cụ có làm vô hiệu hóa các biện pháp kiểm soát được giả định hay không.

Bản sửa đổi tháng Mười, đề ngày 21 tháng 10 năm 2026 và được commit vào kho mã vào ngày hôm sau, bổ sung ba lớp: đường dẫn phục vụ, việc cấp quyền tại thời điểm thực thi, và tổ hợp luồng công việc qua một chuỗi hành động. Bản này cũng biến bản đánh giá thành một đánh giá có phân mức với bốn câu trả lời được phép — đạt, không đạt, không đủ bằng chứng, không áp dụng — và nêu trong nhật ký thay đổi rằng những phát hiện này không chứng minh được tính an toàn tổng quát của hệ thống hay việc tuân thủ pháp luật. Sự tiến triển này đáng đọc như một mô tả về những điều mà các tác giả đã học được để thấy đáng lo ngại: không phải việc mô hình có hành xử đúng đắn hay không, mà là liệu mô hình đã trả lời có đúng là mô hình đã được cấu hình hay không, liệu quyền có còn hiệu lực khi hành động được thực thi hay không, và liệu toàn bộ chuỗi có nằm trong phạm vi đã khởi tạo nó hay không.

Hàng không, nhưng là phần nào của hàng không?

Cách diễn đạt của chính hồ sơ — một hệ thống được mô phỏng theo Hệ thống Báo cáo An toàn Hàng không của NASA — bám theo thông cáo của Linux Foundation chứ không phải bản dự thảo. Thông cáo mô tả ASRS là "một hệ thống báo cáo tự nguyện, bảo mật, được thiết kế để phân tích và ứng phó với các tai nạn bay theo cách cho phép ngành học hỏi và cải thiện." Cả bản dự thảo tháng 8 lẫn bản chỉnh sửa tháng 10 đều không nhắc đến ASRS ở bất cứ đâu; bản dự thảo chỉ nói rằng SAFE "nên tiếp nhận những đặc điểm mạnh nhất của các hệ thống báo cáo an toàn bảo mật." Đó là một khác biệt nhỏ nhưng kéo theo hệ quả thực tiễn: thông cáo đặt ra một kỳ vọng mà văn bản vẫn chưa cam kết thực hiện.

Phép loại suy đã làm dấy lên bình luận ngay bên trong chính quy trình RFC. Một pull request ban đầu được mở vào ngày 5 tháng 8, bởi một người đóng góp viết với tư cách cá nhân, lập luận rằng “phép loại suy ASRS thiếu một yếu tố thể chế” — rằng ASRS vận hành một phần đáng kể vì các báo cáo được NASA tiếp nhận, xử lý và loại bỏ thông tin nhận dạng, “một bên thứ ba công khai, phi quản lý và phi thương mại—không phải FAA với tư cách cơ quan quản lý và cũng không phải các hãng hàng không mà hoạt động của họ đang được báo cáo.” Pull request này, cũng dựa trên quy trình quản trị internet năm 1998, vẫn mở vào ngày 30 tháng 10. Việc liệu đơn vị vận hành SAFE có thể đảm nhận vai trò của NASA hay không là một câu hỏi thiết kế chưa được giải quyết chứ không phải một tính năng đã được chốt: văn bản tháng 10 đặt nhóm công tác dưới cơ chế quản trị của chính Alliance, với việc công bố xung đột lợi ích, tự rút khỏi vai trò và một cơ chế khiếu nại lên Ủy ban Chỉ đạo Alliance.

Các bài đưa tin độc lập đã vạch ra một sự phân biệt thứ hai, hẹp hơn. Infosecurity Magazine, trong bài báo ngày 6 tháng 8, lưu ý rằng bài đăng của Linux Foundation không đề cập cụ thể đến các tác nhân AI — cách diễn đạt theo hướng tác nhân thuộc về bài đăng đồng hành của NVIDIA, bài này lập luận rằng “một tác nhân AI không chỉ là một mô hình. Nó là một hệ thống,” và liệt kê các harness, sandbox, rào chắn và công cụ đánh giá do các thành viên liên minh đóng góp. Các yếu tố kích hoạt trong dự thảo, nếu đọc theo nghĩa đen, nói về các hệ thống hành động vượt quyền; còn thông điệp quảng bá của thông báo, đọc theo nghĩa đen, nói về các tác nhân.

Những gì người bình luận nói về việc ai phải gánh chịu chi phí

Một trong những phản đối cụ thể nhất được công bố đối với dự thảo nguyên văn đến từ một thành viên sáng lập của liên minh chứ không phải một nhà phê bình bên ngoài. Stephen Sargent, người sáng lập kiêm giám đốc công nghệ của Avondale.AI, đã gửi một bản tuyên bố lập trường qua email vào ngày 7 tháng 8 — ngày mà tài liệu nói rằng đội ngũ pháp lý của Linux Foundation đã xác nhận bản này — và công bố nó vào ngày 9 tháng 8. Ông mở đầu bằng việc ủng hộ sứ mệnh và sau đó lập luận rằng bản giao ước không thể mở rộng theo quy mô tổ chức: "RFC không phân biệt giữa một tổ chức có 50.000 nhân viên và một nhóm nhỏ." Theo đánh giá của ông, một báo cáo trong bốn ngày làm việc cộng với một gói dữ liệu pháp y được bảo toàn có thể tiêu tốn nhiều thời gian nhân sự hơn mức một nhà vận hành nhỏ có thể dành ra; khuyến nghị của ông là một khuôn khổ phân tầng, với báo cáo bí mật và việc công bố bị trì hoãn hoặc ẩn danh là mặc định dưới một ngưỡng quy mô.

Phản đối thứ hai liên quan đến việc công bố thông tin chứ không phải thời hạn: ông lập luận rằng “công bố công khai LÀ một hình thức thực thi” đối với các nhà khai thác nhỏ, vì báo cáo của một công ty lớn chỉ là chú thích còn của một công ty nhỏ lại trở thành tiêu đề, và đề nghị rằng báo cáo đã khử nhận dạng nên là mặc định dưới một ngưỡng quy mô. Phản đối thứ ba liên quan đến khung đánh giá chứ không phải đồng hồ: mô hình tám lớp giả định các nhóm doanh nghiệp được tách biệt, nên trong một triển khai chỉ có một người “nhà khai thác làm tất cả mọi thứ” và một lớp bị thiếu được hiểu là lỗi kiểm soát trong khi thực ra đó chỉ là một mô hình vận hành khác. Phản đối thứ tư của ông liên quan đến cụm từ “các thông lệ tối thiểu về khả năng tương tác và bảo đảm”, mà ông hiểu là một con đường từ báo cáo tự nguyện đến công cụ bắt buộc trên thực tế. Tuyên bố lập trường là quan điểm của một thành viên, do thành viên đó công bố. Thông báo ngày 4 tháng 8 của Linux Foundation có trước tuyên bố này và không đề cập đến câu hỏi. Một pull request sau đó, được mở vào ngày 5 tháng 10 và vẫn mở vào ngày 30 tháng 10, đề xuất một mẫu bằng chứng cho các nhà khai thác không có trung tâm vận hành bảo mật — một sự thừa nhận rằng mối lo ngại đã được tiếp nhận, và là một giải pháp ứng viên chứ không phải giải pháp đã được thông qua, với tác giả của nó tuyên bố rằng nó “không xác lập việc áp dụng SAFE hay tính đủ pháp lý.”

Điều gì đã thay đổi giữa ngày 4 tháng 8 và ngày 30 tháng 10?

Lịch sử của kho lưu trữ là bản ghi tốt nhất hiện có về những gì RFC thực sự tạo ra, và nó dễ đọc hơn so với những gì các bài báo đưa tin gợi ý. Những commit đầu tiên xuất hiện vào ngày 3 tháng 8; bản nháp và một readme mở rộng được commit lúc 00:14 và 00:19 UTC ngày 4 tháng 8. Sau đó kho lưu trữ im lặng trong mười tuần. Ngày 14 tháng 10, liên minh bổ sung một điều lệ và một tệp thành viên, đồng thời viết lại readme để biến kho lưu trữ thành nhà của nhóm làm việc SAFE; các chủ tọa lâm thời được ghi nhận vào ngày hôm đó là Paul DiOrio của NVIDIA và Josh Boyer của Red Hat. Ngày 21 tháng 10, nhóm làm việc xuất bản SAFE v1, với một nhật ký thay đổi mà mục đầu tiên là việc văn bản “loại bỏ ‘proposed’ khỏi mô tả của SAFE” và xác định nó là một nhóm làm việc đã được thiết lập của Alliance.

Có hai điều về trạng thái đó đáng được tách bạch. Tệp README của kho lưu trữ hiện có dòng “Trạng thái: Đã phê chuẩn — Được Ban Chỉ đạo phê chuẩn”, là thứ gần nhất với một tuyên bố phê chuẩn trong hồ sơ công khai; trong khi đó, điều lệ, cũng thuộc kho lưu trữ này, vẫn ghi “Đang phát triển. Điều lệ SAFE sẽ được công bố tại đây sau khi được Ban Chỉ đạo phê chuẩn.” Nhật ký thay đổi gắn nhãn văn bản tháng Mười là “SAFE v1” và mô tả những gì nó thay đổi, nhưng không nói ai đã phê chuẩn, bằng cuộc bỏ phiếu nào, hay vào ngày nào. Một độc giả muốn biết liệu SAFE hiện nay là một đặc tả đã được phê chuẩn, hay là một nhóm làm việc mà điều lệ quản trị vẫn chưa được viết ra, sẽ không nhận được câu trả lời rõ ràng từ các tài liệu.

Điều gì đã được xác lập, và điều gì chưa.

• Thành lập: Một Request for Comments cho Shared AI Findings Exchange đã được công bố vào ngày 4 tháng 8 năm 2026 — Linux Foundation đã ghi ngày thông báo của mình là ngày đó — và các tổ chức được nêu tên là bên đóng góp trong đó gồm Cisco, CrowdStrike, Hugging Face, NVIDIA và Red Hat, được nêu tên cùng với “các thành viên khác của Open Secure AI Alliance”.

• Đã thiết lập: dự thảo bao gồm một thỏa thuận báo cáo với bốn điểm kích hoạt, một bảng thông báo từ ngay lập tức đến 90 ngày, một danh sách bảo toàn bằng chứng, một khung đánh giá nhiều lớp và một mô hình công bố ba tầng. Toàn văn được công khai trong kho lưu trữ và lịch sử của nó cũng được công khai cùng với đó.

• Được xác lập, chỉ kèm ghi nguồn: quy mô của liên minh — “hơn 120 tổ chức” — là con số của chính NVIDIA, được lặp lại trong báo cáo ngày 6 tháng 8 của Infosecurity Magazine. Không có bài đưa tin nào đã được xem xét cho thấy một cuộc kiểm toán thành viên độc lập, và tệp thành viên của kho lưu trữ chỉ liệt kê hai người đóng góp và hai chủ tịch tạm thời, không phải 120 tổ chức.

• Chưa được xác lập:rằng đã có ai nộp báo cáo theo hiệp ước hay chưa. Hồ sơ công khai ngày 30 tháng 10 cho thấy các commit, pull request và issue; hồ sơ không cho thấy báo cáo sự cố, một chương trình thí điểm, một trường hợp đầu tiên, hạn chót góp ý, quy tắc biểu quyết hay ngày phê chuẩn. Khuôn khổ này mô tả một nghĩa vụ mà các thành viên "đồng ý" như một điều kiện để trở thành thành viên, điều này không giống với một nghĩa vụ mà bất kỳ ai đã thực hiện cho đến nay.

• Có tranh cãi:liệu phép so sánh với ASRS có còn đúng khi không có một nhà vận hành công cộng trung lập hay không, điều đã bị phản biện trong một pull request mở; liệu gánh nặng báo cáo có tương xứng với các nhà vận hành nhỏ hay không, điều đã bị phản đối trong tuyên bố lập trường của một thành viên sáng lập; và bao nhiêu phần của khuôn khổ là đặc thù cho tác nhân so với an ninh AI tổng quát, một sự phân biệt được văn bản của Linux Foundation và văn bản của NVIDIA diễn đạt khác nhau.

Không điều nào trong số đó khiến hồ sơ trở nên sai, và mức A của kho lưu trữ vẫn có thể biện hộ theo tiêu chí của chính nó: các tài liệu nguồn sơ cấp khớp nhau về những gì đã được công bố, thời điểm và người công bố, và bản nháp có thể đọc được toàn văn. Điều mà mức điểm ấy không thể truyền đạt chính là thứ người đọc muốn nhất — liệu cơ chế có vận hành được hay không. Về điểm này, không có bằng chứng theo hướng nào, vì cơ chế chưa từng có trường hợp nào để thử.