本文探討如何在嵌入式安全關鍵（Safety-Critical）系統中安全地整合 AI，透過結合傳統 C/C++ 防護機制、AI 專屬驗證方法、資料治理、持續監控與人工監督，將智慧能力轉化為可被工程化驗證的信任。
重點摘要
AI 在航太、汽車與醫療設備領域的普及，帶來一種稱為「功能不足（Functional Insufficiency）」的新型風險。即使程式碼完全正確執行，仍可能因訓練資料不完整或運作假設錯誤而產生危險行為，迫使傳統安全關鍵軟體開發生命週期（SDLC）進行全面調整。
儘管 AI 持續進步，具備確定性（Deterministic）的 C 與 C++ 仍然不可或缺，因為它們提供合理性檢查（Plausibility Checks）、信心度監控（Confidence Monitoring）與備援觸發機制（Fallback Triggers）等防護措施，用來約束 AI 輸出並防止智慧系統造成危害。
傳統軟體缺陷（例如記憶體洩漏）可以透過單元測試與靜態分析找出，但 AI 失效往往源自知識缺口，因此工程師必須驗證其在真實世界中的能力，而不只是確認程式碼是否正確。
若僅將 AI 視為可部署的模型，將是極具風險且不完整的做法。AI 必須被視為完整系統進行工程化設計，涵蓋資料管線、推論引擎、後處理驗證以及確定性的監督軟體，同時組織必須回答有關安全責任分配、執行限制、備援機制、系統層級風險及持續學習等五項關鍵問題。
在導入 AI 的系統中，資料的重要性已與程式碼同等重要，因此必須嚴格管理環境涵蓋範圍、偏差（Bias）、邊界案例（Edge Cases）、標註一致性以及版本控制。許多組織因此開始設立專責的資料安全工程師（Data Safety Engineer）角色。
對安全關鍵系統而言，「99% 準確率」這類指標遠遠不足。真正的安全保證需要建立完整的論證架構，結合安全主張、量化證據、質化分析、架構層緩解措施、運作防護機制以及持續監控。
AI 大幅擴展了驗證工作的範圍，因此需要採用雙層驗證策略：保留傳統 C/C++ 的靜態分析、單元測試與覆蓋率分析，同時加入 AI 專屬驗證，包括不確定性評估、情境覆蓋率、對抗性穩健性（Adversarial Robustness）、領域漂移（Domain Drift）以及模型長期退化分析。
一次性的驗證已不再足夠。CI/CD 流程以及部署後的持續監控（包含執行期異常偵測、現場資料蒐集、漂移分析與受控 OTA 更新）已成為確保 AI 系統長期安全的必要條件。
在人命攸關的工程領域中，人類專業仍是最終決策者。AI 可以協助產生程式碼與測試，但安全判斷、架構決策、風險評估以及法規責任仍必須由人類掌控。
AI 如何改變嵌入式安全關鍵系統開發
在航太、汽車、醫療設備、鐵路與國防等領域，失敗從來都不是選項。如今，人工智慧正快速改變這些產業中的嵌入式系統。自主飛行控制、先進駕駛輔助系統（ADAS）、AI 驅動診斷以及工業機器人自動化都只是開端。
但問題在於：AI 的失效模式與傳統軟體完全不同，它可能以過去從未測試過的方式發生錯誤。
傳統嵌入式軟體建立在可預測且具確定性的行為基礎上。如果感測器介面或控制迴路發生錯誤，通常都能追溯到程式缺陷、硬體異常或安全漏洞。
工程師花了數十年時間學習如何找出並修正這類系統性故障。然而 AI 打破了這套模式。神經網路可能完全依照設計執行、程式碼毫無問題、執行期沒有任何錯誤，卻仍可能產生危險行為。原因是什麼？
因為訓練資料不完整、運作假設錯誤，或是遭遇了超出其學習經驗範圍的情境。
這已不再只是單純的軟體失效。
而是一種全新的問題：功能不足（Functional Insufficiency）。
傳統軟體缺陷是「做錯事情」；AI 的功能不足則是「在錯誤的世界中做對事情」。
這種轉變迫使我們重新思考整個軟體開發生命週期。你不能只是把 AI 模型加掛到既有嵌入式架構上，然後稱之為一項功能。AI 必須作為安全關鍵系統的核心組成部分進行工程化設計，包括：
- 強健的軟體控制機制
- 受治理的資料生命週期
- 架構層級的安全防護
- 持續驗證機制
安全關鍵嵌入式系統的未來不只是變得更智慧，而是要確保智慧本身能夠被工程化地建立信任。
為何 C 與 C++ 仍是嵌入式 AI 與功能安全的基礎
儘管機器學習蓬勃發展，幾乎所有安全關鍵嵌入式平台仍然仰賴具確定性的軟體運作，而其中以 C 與 C++ 為主。這些語言支撐著真正守護安全的核心機制：
- Sensor interfaces → 感測器介面
- Communication stacks → 通訊協定堆疊
- Control logic → 控制邏輯
- Fail-safe mechanisms → 故障安全機制
- Cybersecurity monitors → 網路安全監控機制
- Runtime supervision → 執行期監督機制
即使是最先進的神經網路，也無法單獨保證系統安全運作。真正決定如何解讀、限制、驗證甚至覆寫 AI 輸出的，是其周圍的嵌入式軟體。
以自動駕駛車輛為例。其感知模型或許能辨識障礙物，但可信任的 C++ 程式碼仍必須依據物理規則驗證這些偵測結果、監控信心度、交叉比對冗餘感測器資料，並在不確定性提高時啟動備援機制。
醫療 AI 也是如此。它可以提供診斷建議，但具確定性的防護機制會確保這些建議始終維持在安全且符合臨床規範的範圍內。
這也是為什麼傳統軟體工程實務比以往更加重要：
- 靜態分析
- 程式碼規範落實
- 自動化單元測試
- 整合測試
- 結構覆蓋率分析
- CI/CD 自動化
這些方法並沒有過時，它們正是確保 AI 安全運作的信任框架。
在安全關鍵嵌入式系統中，AI 提供智慧能力；而 C 與 C++ 則提供約束機制，避免這些智慧能力造成危害。
什麼是功能不足（Functional Insufficiency）？AI 與傳統軟體失效模式的差異
讓我們透過一個傳統軟體錯誤的例子來說明：醫療幫浦使用者介面因記憶體洩漏而當機。
這類問題可以透過單元測試找出，也能透過靜態分析檢測並修正。
然而 AI 的功能不足則不同。例如感知系統在夜間將行人誤判為其他物體，原因是訓練資料中夜間行走情境的樣本不足。
程式碼執行完全正常，模型運作也毫無異常，但系統仍然失效了。
這是知識上的缺口，而不是程式碼上的缺陷。而這種差異改變了一切。
因此，開發生命週期現在必須納入資料代表性、情境完整性、運作邊界、環境多樣性以及行為穩健性等考量，而不只是驗證程式碼是否正確。
工程師必須思考的是：「這套 AI 是否具備足夠能力在真實世界中安全運作？」而不只是「它是否正確執行？」
對於嵌入式安全關鍵產業而言，從「失效管理（Failure Management）」轉向「功能不足管理（Insufficiency Management）」可能是功能安全標準誕生以來最大的轉變。
AI 是完整系統工程挑戰，而非單純模型部署工作
把 AI 只當成一個模型來看待，就像建造火箭時只測試引擎一樣。在嵌入式安全關鍵環境中，這種思維極其危險且不完整。
AI 並非獨立存在的模型，而是一套彼此相互連結的系統：
- 資料管線
- 前處理濾波機制
- 推論引擎
- 後處理驗證機制
- 執行期監控機制
- 確定性的監督控制軟體
你不能只在模型層級評估安全性，而必須在整個資料與執行流程中進行工程化設計與驗證。
前處理階段必須確保感測器輸入可靠；模型負責執行推論；後處理則負責驗證輸出、執行合理性檢查、套用信心度門檻，並在必要時啟動備援控制機制。而周邊軟體則負責在 AI 出現不可預測行為時，仍確保系統目標受到保護。
工程團隊必須回答以下五個關鍵問題。
- 安全需求應如何在 AI 與傳統軟體之間進行分配？
- 執行期限制條件如何被落實？
- 備援機制如何維持系統安全？
- 系統層級互動會衍生哪些新的風險？
- 運作期間所蒐集的資料將如何持續改善系統認知與理解？
將 AI 視為單純模型問題的組織，往往會建立脆弱的系統；而將 AI 視為完整生命週期工程挑戰的組織，則能打造更具韌性的系統。
為何資料治理成為 AI 安全關鍵系統的重要環節？
在傳統軟體開發中，程式碼是核心資產。而在導入 AI 的系統中，資料的重要性已與程式碼並駕齊驅。訓練資料決定系統行為、驗證資料建立信心，而運作資料則影響未來的調整與演進。資料集不再只是被動資源，而是系統安全的主動組成部分。
治理不當的資料集將帶來隱藏風險：
- 環境涵蓋範圍不足
- 人口統計或運作偏差
- 邊界案例代表性不足
- 資料標註不一致
- 情境多樣性不足
在系統進入真實環境之前，這些問題往往難以察覺。對安全關鍵嵌入式系統而言，這是無法接受的風險。
因此，資料必須以與軟體相同的嚴謹程度進行管理，包括需求定義、驗證程序、可追溯性、缺口分析、版本控制、維護以及運作期間的持續改善。
那麼誰該負責這項工作？越來越多組織開始設立「資料安全工程師（Data Safety Engineer）」職位，由專人負責資料集完整性，就如同軟體安全工程師負責程式碼品質與安全性一樣。
安全的 AI 不僅依賴軟體品質，同樣高度仰賴資料集的完整性。
超越準確率指標：建立完整的安全保證論證
「99% 的準確率」聽起來很吸引人，但當你意識到剩下的 1% 可能導致人員傷亡時，事情就完全不同了。安全關鍵系統不是建立在平均值之上，而是建立在可證明的安全性之上。準確率只是表面的數字，真正重要的是安全保證。
完整且結構化的安全保證論證遠不只是單一指標，而是結合以下要素：
- 安全主張（Safety Claims）
- 量化證據
- 質化分析
- 架構層級緩解措施
- 運作防護機制
- 持續監控
例如，若要信任某個自動煞車模型，必須證明以下事項：
- 系統在良好天候條件下具有良好表現。
- 其訓練資料涵蓋夜間、雨天以及道路障礙物等情境。
- 已針對各種邊界案例進行穩健性測試。
- 當信心度下降時，系統具備備援機制。
- 具確定性的防護機制可在必要時覆寫不安全的輸出結果。
在嵌入式安全關鍵開發中，AI 的安全性無法單靠準確率證明，而是必須透過多層次且持續更新的工程證據來建立合理性與可信度。
嵌入式系統中的 AI 驗證與確認（V&V）
AI 並沒有減少驗證工作的需求，反而大幅擴大了驗證範圍。為了滿足功能安全合規要求，傳統 C/C++ 的驗證活動仍然不可或缺，包括靜態分析、程式碼規範遵循、單元測試、整合測試、結構覆蓋率分析以及需求可追溯性，這些都是驗證 AI 周圍確定性防護機制的重要手段。
然而現在還必須額外評估：
- 不確定性條件下的行為表現
- 情境覆蓋率
- 合成邊界案例
- 對抗性穩健性
- 領域漂移（Domain Drift）
- 分布外資料（Out-of-Distribution）表現
- 模型隨時間產生的效能退化
這是一種雙層驗證策略。傳統軟體工程負責確認系統是否被正確建構；AI 專屬驗證則負責確認系統是否持續具備足夠能力。兩者結合，才能建立可信任的嵌入式 AI 系統。
CI/CD 與持續監控如何提升嵌入式 AI 的長期安全性
在安全關鍵系統中，一次性的驗證已經成為過去式。AI 會演進、運作環境會改變、威脅也會持續變化，因此安全保證機制也必須同步演進。
現代 CI/CD 流程已將靜態分析、單元測試、結構覆蓋率分析、模型驗證、部署防護機制以及迭代更新整合至持續性的工程流程中，使品質管理從階段性的稽核轉變為全生命週期的持續治理。
部署後監控同樣至關重要。執行期異常偵測、現場資料蒐集、模型漂移分析、重新訓練治理以及經過驗證的 OTA 更新流程，都是維持長期安全不可或缺的要素。部署不再是終點，而是持續工程責任的起點。
AI 時代下的人工監督：安全關鍵系統的最終責任機制
AI 工具能加速程式碼產生、測試建立、覆蓋率提升，甚至協助修復缺陷。然而，安全關鍵工程不能將責任交給自主系統承擔。
在安全判斷、架構決策、風險評估、需求解讀、任務保證以及法規責任方面，仍然需要仰賴人類專業知識。
AI 是工程能力的放大器，而不是工程師的替代品。最成功的組織將會把 AI 的生產力優勢與人類治理結合，確保創新速度不會超越責任管理能力。在安全關鍵嵌入式開發領域中，真正的信任正是建立在這種平衡之上。
實用檢查表：安全關鍵系統導入 AI 前的 5 項檢查重點
可透過以下檢查表快速評估系統是否已準備好部署。
- 我們是否已找出所有功能不足的來源，而不只是程式碼缺陷？
- 訓練資料缺口
- 運作領域不匹配
- 邊界案例覆蓋率
2. 資料治理是否達到與軟體治理相同的水準？
- 資料版本控制
- 從需求到資料集的可追溯性
- 指定資料安全負責人
3. 我們是否針對每一個 AI 輸出建立確定性的防護機制？
- 合理性檢查
- 信心度門檻
- 備援機制
4. 我們是否超越準確率指標進行測試？
- 分布外情境測試
- 對抗性穩健性測試
- 模型長期漂移分析
5. 是否已建立 AI 的持續監控與 CI/CD 流程？
- 執行期異常偵測
- 現場資料蒐集
- 經驗證的 OTA 更新流程
如果無法勾選上述所有項目，代表系統尚未準備好部署至安全關鍵環境。
結論
AI 能帶來智慧能力，但只有嚴謹的工程方法才能建立信任。在安全關鍵系統中，信任永遠比智慧更重要。
成功不會屬於那些只是更快導入 AI 的組織，而是屬於那些以更高紀律整合 AI 的組織。他們將成熟的 C/C++ 工程實務、資料集治理、架構安全防護、傳統驗證方法、AI 專屬安全保證、持續監控、CI/CD 自動化以及人類責任機制結合在一起。
AI 或許能擴展系統能力，但只有透過工程化建立的信任，才能實現安全、可靠且值得信賴的創新。對嵌入式安全關鍵系統而言，智慧能力本身永遠不足以保證成功。
歡迎前往 ➤ 與 FSG 功能安全專家們繼續深入探討
文由Parasoft提供