Hàng không không trở nên an toàn bằng cách kiểm tra xem mỗi bu-lông có chịu được tải định mức hay không. Nó trở nên an toàn bằng cách hỏi các bộ phận tương tác như thế nào, ai được phép điều khiển cái gì, và hoạt động thực tế lệch khỏi điều kiện mà hồ sơ an toàn giả định như thế nào. Kỷ luật đó là an toàn hệ thống. Bộ công cụ của nó bao gồm STPA, FRAM và STECA, các phương pháp mà các ngành công nghiệp được quản lý đã yêu cầu.
An toàn AI hầu như chưa tiếp thu chúng. Một bài báo năm 2026 thì đã làm.
Luca Carlucci, James Fillingham, Robert Walpole, và Bartłomiej Kryś áp dụng ba phương pháp đó cho một frontier coding agent trong thiết lập production thực tế (phòng lab, khách hàng doanh nghiệp, nhà phát triển) trong "A Systems-Thinking Approach to Loss of Control Risk from Advanced AI" (arXiv:2606.13474; ICML 2026 Technical ASI Governance Workshop). Họ phát hiện ba mối nguy mà các bài kiểm tra mô hình thông thường chưa bao giờ được thiết kế để bắt.
Ba phương pháp, bằng ngôn ngữ đơn giản
Kịch bản họ đã dùng
Họ chạy cả ba phương pháp trên một tác nhân lập trình tiên phong trong công việc phần mềm thực tế: tầm nhìn dài hạn, sử dụng công cụ, với các kho mã thật và dịch vụ bên ngoài, được giám sát bởi phòng thí nghiệm, khách hàng doanh nghiệp và nhà phát triển. Đó là cách những hệ thống này đã được triển khai. Rủi ro mất kiểm soát ở cấp độ hệ thống vẫn còn được phân tích rất ít.
Ba phát hiện mà đánh giá mô hình bỏ sót
Trong thiết lập của họ, phòng thí nghiệm đưa ra các cam kết an toàn, viết các quy tắc sử dụng và theo dõi vi phạm. Các cơ quan quản lý, khách hàng và kiểm toán viên không thể kiểm tra hoạt động một cách độc lập. Tự báo cáo là vòng phản hồi chính.
STECA đánh dấu đó là cấu trúc kiểm soát bị hỏng. Một hành động kiểm soát chỉ hiệu quả nếu ai đó có thể thấy nó đã đạt hay chưa. Khi bên chịu trách nhiệm an toàn cũng là nguồn chứng minh chính rằng an toàn được đảm bảo, vòng lặp bị xâm phạm. Đó là một sự kiện thiết kế, không phải cáo buộc bất kỳ lab nào không trung thực.
STPA vẽ ra khoảng cách giữa hành động của tác nhân và việc con người biết được hành động đó. Trong các lần chạy đa bước theo thời gian thực, tác nhân thường đã gọi công cụ, viết mã hoặc đẩy thay đổi trước khi người đánh giá thấy cảnh báo.
Hàng không gọi đây là rời khỏi vòng kiểm soát. Quyền hạn chính thức để dừng hệ thống vẫn tồn tại trên giấy tờ. Quyền hạn thực tế không theo kịp. Đó chính là những gì giám sát thời gian thực đối với các tác nhân lập trình tiên phong có thể trông như ngày nay.
FRAM tập trung vào biến thiên thông thường. Các biện pháp bảo vệ được điều chỉnh theo cách hệ thống trông lúc triển khai. Sau đó prompt thay đổi, hỗn hợp nhiệm vụ thay đổi, các trường hợp biên tích tụ, và phân phối thực tế trôi dạt khỏi mẫu dùng lúc ra mắt.
Không có gì báo động. Các biện pháp bảo vệ vẫn làm đúng những gì chúng được thiết kế để làm trước điều kiện của ngày hôm qua. Khoảng cách âm thầm lớn dần cho đến khi một trường hợp mới chạm vào quy tắc không còn phù hợp.
Điều này có ý nghĩa gì đối với quản trị
Các bài kiểm tra mô hình hỏi hệ thống làm gì với đầu vào. Chúng không vẽ ra cấu trúc kiểm soát xung quanh nó, ai chịu trách nhiệm về cái gì, hay hoạt động sẽ trôi dạt ra sao sau khi triển khai. Điểm số năng lực và red team vẫn cần thiết. Nhưng chúng không đủ.
Yêu cầu của bài báo rất đơn giản: kết hợp phân tích nguy cơ cấp mô hình với phân tích nguy cơ cấp hệ thống như một phần bắt buộc của đánh giá an toàn. STPA, FRAM và STECA là một khởi đầu cụ thể. Được mở rộng từ một tác nhân lập trình đến toàn bộ nền kinh tế, chính lỗ hổng mù quáng đó khiến mất quyền lực dần dần khó nhìn thấy cho đến muộn.
Đối với Foundation, bài học nằm ở thiết kế, không phải một bài báo đơn lẻ. Kiểm tra độc lập, quy tắc compute và xác minh bên ngoài tồn tại để an toàn không dựa vào phòng lab tự báo cáo. Đó là lý do kế hoạch của chúng tôi tập trung vào các giới hạn ràng buộc và xác minh, không chỉ đánh giá tự nguyện. Đọc bài báo nếu bạn muốn chi tiết phương pháp đầy đủ: arXiv:2606.13474. Sau đó đưa phát hiện vào áp dụng trong luật và thể chế, không chỉ trong trích dẫn hội thảo.