
CosAI công bố "Khung trách nhiệm chung về AI"
URL bài viết: https://www.coalitionforsecureai.org/whos-responsible-when-ai-goes-wrong-a-new-framework-aims-to-answer-that-question/ URL bình luận: https://news.ycombinator.com/item?id=48317514 Điểm: 1 Bình luận: 0
Liên minh AI An toàn công bố nghiên cứu mới về định danh và bảo mật tác nhân sau các phiên họp cấp cao tại RSAC 2026
Ngày 6/5/2026
Khi một hệ thống AI gây ra thiệt hại hoặc không vượt qua được cuộc kiểm toán tuân thủ, việc đổ lỗi gần như bắt đầu ngay lập tức. Nhà cung cấp mô hình đổ lỗi cho cấu hình. Nhà cung cấp đám mây chỉ vào người thuê. Nhóm ứng dụng viện dẫn những hạn chế của mô hình. Khung Trách nhiệm Chia sẻ AI mới của chúng tôi được thiết kế để chấm dứt vòng luẩn quẩn đó trước khi nó bắt đầu.
Hầu hết các tổ chức đã dành nhiều năm để xây dựng các ranh giới sở hữu rõ ràng xung quanh các ngăn xếp công nghệ của họ. Họ biết ai sở hữu mạng, ai sở hữu lớp ứng dụng, ai gọi nhà cung cấp khi có sự cố lúc 2 giờ sáng. AI đã làm phức tạp tất cả những điều đó.
Vấn đề không phải là các hệ thống AI vốn dĩ không thể quản lý được. Vấn đề là các cấu trúc trách nhiệm mà hầu hết các tổ chức dựa vào được thiết kế cho một kỷ nguyên công nghệ khác. Một kiến trúc trách nhiệm chia sẻ đám mây truyền thống phân chia thế giới rõ ràng giữa nhà cung cấp và khách hàng. Các hệ thống AI hoạt động trên các lớp mà kiến trúc này chưa bao giờ được thiết kế để giải quyết: các mô hình nền tảng được đào tạo trên dữ liệu của bên thứ ba, các nền tảng kết nối nhiều nhà cung cấp, các hệ thống tác nhân có thể thực hiện các hành động tự động thay mặt người dùng và các yêu cầu quy định khác nhau trên ngăn xếp tùy thuộc vào ngành bạn hoạt động.
Khi có sự cố xảy ra trong kiến trúc như vậy, câu hỏi “đây là lỗi của ai?” trở nên thực sự khó trả lời. Và càng mất nhiều thời gian để trả lời, càng mất nhiều thời gian để khắc phục.
Đọc toàn bộ Khung Trách nhiệm Chia sẻ AI tại đây.
Một Khung được Xây dựng cho Cách AI Thực sự Hoạt động
Nhóm công tác 2 của CoSAI đã dành một năm qua để xây dựng một câu trả lời có cấu trúc cho vấn đề này. Kết quả là Khung Trách nhiệm Chia sẻ AI (AI SRF), một mô hình năm lớp ánh xạ trách nhiệm trên toàn bộ ngăn xếp AI và chỉ định chính xác một bên chịu trách nhiệm cho mỗi thành phần.
Năm lớp phản ánh cách các hệ thống AI thực sự được xây dựng và vận hành:
AI Business and Usage (Kinh doanh và Sử dụng AI) bao gồm quản trị, tuân thủ quy định và các quyết định kinh doanh mà các tổ chức đưa ra về cách AI được triển khai. Lớp này tồn tại vì các quy định cụ thể về AI (hướng dẫn của FDA cho phần mềm là thiết bị y tế, quản lý rủi ro mô hình SR 11-7 trong dịch vụ tài chính, các yêu cầu của Đạo luật AI của EU) tạo ra các nghĩa vụ mà các khung tuân thủ đám mây truyền thống đơn giản là không giải quyết được. Ai đó phải chịu trách nhiệm về những nghĩa vụ đó. Lớp này làm cho điều đó trở nên rõ ràng.
AI Information (Thông tin AI) giải quyết dữ liệu: ai sở hữu dữ liệu đào tạo, ai quản lý thông tin mà các tác nhân có thể truy cập và cách các tổ chức quản lý vấn đề ngày càng tăng của AI bóng tối — nhân viên sử dụng các công cụ AI bên ngoài mà không ai cho phép, giám sát hoặc bảo mật. Đây là một lớp mà mô hình đám mây ba tầng truyền thống bỏ qua hoàn toàn.
AI Application (Ứng dụng AI) bao gồm các nhóm xây dựng và triển khai các sản phẩm được hỗ trợ bởi AI. Các nhà phát triển ứng dụng tích hợp AI thông qua API chịu trách nhiệm cụ thể về xác thực đầu vào, kiểm soát truy cập, hệ thống an toàn và bảo mật tích hợp, những trách nhiệm này khác biệt so với những gì mà nền tảng hoặc nhà cung cấp mô hình sở hữu.
Nền tảng AI bao gồm cơ sở hạ tầng và các dịch vụ lưu trữ, cung cấp mô hình AI. Các nhà cung cấp dịch vụ đám mây, nền tảng MLOps và dịch vụ API mô hình đều có các nghĩa vụ xác định ở lớp này, bao gồm bảo mật điện toán, chứng nhận tuân thủ và các nguyên tắc quản lý danh tính, quyền truy cập mà người thuê phụ thuộc vào.
Nhà cung cấp mô hình AI là một lớp mới cho các khuôn khổ trách nhiệm chung và giải quyết một vấn đề vốn là điểm mù dai dẳng: chuỗi cung ứng mô hình nền tảng. Ai chịu trách nhiệm về khả năng dễ bị tấn công bởi prompt injection (tiêm lệnh) đã biết của một mô hình? Ai lập tài liệu về nguồn gốc dữ liệu huấn luyện? Ai duy trì các quy trình tiết lộ lỗ hổng khi phát hiện ra các điểm yếu ở cấp độ mô hình? Lớp này gán các trách nhiệm đó cho các nhà cung cấp mô hình một cách rõ ràng và không mơ hồ.
Những điểm khó khăn mà khuôn khổ này được thiết kế để giải quyết
Những khoảng trống về trách nhiệm mà AI SRF giải quyết không phải là lý thuyết. Các tòa án và cơ quan quản lý đã đưa ra các quyết định mà các tổ chức chưa chuẩn bị.
Năm 2024, Air Canada bị buộc phải chịu trách nhiệm sau khi chatbot dịch vụ khách hàng của hãng cung cấp thông tin sai lệch cho hành khách về giá vé tang lễ. Hãng hàng không lập luận rằng chatbot là một thực thể riêng biệt. Tòa án không đồng ý và ra lệnh cho Air Canada phải thực hiện mức giá vé giảm. Không ai trong tổ chức đã rõ ràng chịu trách nhiệm về việc chatbot được phép cam kết điều gì thay mặt công ty, hoặc điều gì sẽ xảy ra khi nó mắc lỗi.
Cùng thời điểm đó, một đại lý ô tô đã thêm một chatbot AI vào trang web của mình. Trong vòng vài ngày, khách hàng đã thao túng nó để đồng ý bán một chiếc Chevy Tahoe mới với giá một đô la. Một lần nữa, khoảng trống không phải là một lỗi kỹ thuật theo nghĩa truyền thống. Đó là một lỗi về trách nhiệm: không ai xác định ai chịu trách nhiệm đặt ra giới hạn về những gì chatbot có thể cam kết, và ai sẽ xác minh rằng những giới hạn đó thực sự được áp dụng.
Đây không phải là những trường hợp cá biệt. Chúng là những ví dụ ban đầu về những gì xảy ra khi việc triển khai AI vượt quá khả năng quản trị.
Hãy xem xét một kịch bản kỹ thuật phức tạp hơn mà khuôn khổ trực tiếp giải quyết: một cuộc tấn công prompt injection vượt qua các biện pháp bảo vệ trên chatbot hướng tới khách hàng và làm lộ thông tin nhận dạng cá nhân từ một cơ sở dữ liệu được kết nối. Theo các thực hành hiện tại, việc ứng phó sự cố thường bị đình trệ vì không ai có thẩm quyền rõ ràng về việc phát hiện, ngăn chặn và khắc phục trên nhiều bên liên quan.
Theo khuôn khổ năm lớp, trách nhiệm được truy vết rõ ràng. Nhà cung cấp mô hình chịu trách nhiệm về khả năng dễ bị tấn công bởi injection của mô hình cơ sở và tài liệu về các điểm yếu đã biết. Nhà cung cấp nền tảng chịu trách nhiệm về các biện pháp bảo vệ cấp độ cơ sở hạ tầng. Nhà phát triển ứng dụng chịu trách nhiệm về các biện pháp bảo vệ, đầu vào




Nguồn tin: Hacker News AI — Tác giả: fatpil. Bản dịch tiếng Việt do AI thực hiện, có thể có sai sót.