ISO/PAS 8800 車用 AI 安全標準是什麼？與 ISO 26262、SOTIF 的關係

「這個神經網路的 ASIL 等級怎麼定？它的失效率是多少？」——把傳統功能安全的問題丟給 AI 元件，會發現整套工具箱對不上：神經網路沒有可以逐行審查的邏輯、沒有可計算的硬體失效率，它的行為由訓練資料塑造，而資料永遠不可能涵蓋所有路況。2024 年發布的 ISO/PAS 8800 就是為這個缺口而生：車用 AI 的安全標準。

三份標準的分工：故障、性能不足、AI 特性

理解 8800 的最快方式，是看它跟前兩份標準怎麼分工：

• ISO 26262（2011 起）管故障：硬體隨機失效與系統性錯誤——前提是系統的正確行為可以被完整定義。
• ISO 21448 SOTIF（2022）管性能不足：沒有任何故障、系統照設計運作，但設計本身應付不了某些真實場景。
• **ISO/PAS 8800（2024）**管 AI 特有的問題：資料集的代表性、模型的不確定性、訓練與部署後的行為漂移——SOTIF 承認「性能有極限」，8800 進一步回答「當性能由機器學習決定時，怎麼系統性地給出安全論證」。

三份不是互相取代，是疊加：一套 ADAS 感知系統同時需要 26262 管它的運算平台故障、SOTIF 管它的場景涵蓋、8800 管它的模型與資料。

AI 安全生命週期：資料變成安全證據

8800 的核心是一條貫穿 AI 元件生命週期的安全迴圈——從場景與風險分析、資料與模型治理、架構性防護措施、驗證與確認，一路到部署後的營運監控。其中最顛覆傳統工程直覺的是資料的地位：訓練資料集的代表性、標註品質、與目標營運環境（ODD）的對應關係，本身就是安全證據——資料治理文件從「機器學習團隊的內部事務」變成「安全稽核的查核對象」。

部署後監控也是硬要求的方向：真實世界會漂移（新的道路元素、天候組合、行為模式），AI 元件的安全論證不能停在出廠那一刻。

為什麼 AI 元件難驗證

• 不可解釋：無法逐行審查「為什麼這樣判斷」，傳統的程式碼審查與 MC/DC 覆蓋率量測（VectorCAST 擅長的領域）適用於周邊邏輯，但對神經網路本體無從施力。
• 資料相依：行為由訓練資料決定，資料的盲區就是系統的盲區——而盲區在上路前不會自己現身。
• 場景爆炸：驗證要靠大量場景測試補足。這正是模擬工具的主場：DYNA4 的場景引擎支援 ASAM OpenSCENARIO、OpenDRIVE 與 OSI 標準，把極端天候、危險互動這類實車難以安全重現的場景系統性地生成與批次執行，搭配 CANoe.ADAS 做感知結果的同步比對。

台灣團隊現在該做的三件事

一、把資料治理當工程做：資料集的版本、來源、標註規範與 ODD 對應現在就開始留紀錄——事後補文件比先建流程貴十倍。二、建場景測試能力：場景庫與模擬環境是 SOTIF 與 8800 共用的基礎建設，一次投資兩邊受益。三、讓功能安全與 AI 團隊共用語言：8800 的安全論證需要兩邊協作，各做各的會在稽核時對不上。

常見問題釐清

ISO/PAS 8800 是什麼？

ISO/PAS 8800 是 2024 年發布的車用 AI 安全標準，涵蓋 AI 元件的完整安全生命週期：場景與風險分析、資料與模型治理、架構防護、驗證確認與部署後監控。它與 ISO 26262（故障）、ISO 21448 SOTIF（性能不足）疊加使用，補上「行為由機器學習決定」的系統怎麼給安全論證的缺口。

有了 SOTIF 為什麼還需要 8800？

SOTIF 處理「設計性能不足」的一般性問題，但沒有深入 AI 的特有機制。8800 補上 AI 專屬的層面：訓練資料集的代表性與品質怎麼論證、模型的不確定性怎麼處理、部署後的行為漂移怎麼監控。用 AI 做感知或決策的系統，兩份都需要。

ISO/PAS 8800 會影響型式認證嗎？

PAS（公開可用規範）是標準化的先行形式，尚非強制法規。但主管機關與稽核方對 AI 安全的關注明確在升高，8800 提供的是目前最完整的論證框架——先按它建立資料治理與場景驗證能力的團隊，在法規正式化時的轉換成本最低。