序：規範就像風，無形卻無處不在

我常常在專案會議上聽到這樣的對話：

• 工程師：「功能已經跑起來了！」
• PM：「那這樣可以交付嗎？」
• QA：「等等，我們還沒過安全驗證。」
• 法務：「不好意思，這在歐盟根本不能賣。」

那一刻，我感覺到一股看不見的風，吹亂了桌上的圖紙。這股風，就是「合規與資安標準」。

對 AI × Hardware 來說，這些規範不像軟體一樣容易熱修補。它們是上市的入場券，是市場信任的基礎，也是產品能不能真正被使用者接受的關鍵。於是我開始把這些國際標準整理成一份「地圖」，像旅行者帶的指南針，讓我和團隊知道在每個領域裡要注意什麼。

第一章：AI 標準 — 黑盒裡的透明度

AI 的挑戰在於「不可解釋性」。很多標準正是為了讓黑盒變得可被理解。

1. NIST AI RMF（美國風向）

• 背景：美國國家標準與技術研究院提出的 AI 風險管理框架。
• 核心概念：可信 AI 要素（可靠、可解釋、隱私保護、公平性）。
• 適用場景：AI 模型做出任何決策會影響安全、隱私或公平性的情境。
• 落地建議：在 PRD 裡加入「風險評估」欄位，例如：模型可能的偏誤、數據敏感性等。

2. ISO/IEC 22989 & 23894

• 22989：定義 AI 的術語與概念，幫助跨團隊避免誤解。
• 23894：AI 風險管理標準，要求把風險流程寫進系統設計。
• 案例：醫療 AI 需能解釋決策過程，否則醫師無法依法使用。

第二章：功能安全 — 機器動起來時的生命防線

一旦 AI 控制馬達、煞車或刀片，安全標準就成了生命線。

1. ISO 26262（道路車輛功能安全）

• 背景：專為汽車產業設計的安全標準。
• 場景：自駕輔助、ADAS、車內 AI 控制模組。
• 重點：要求每個需求都有對應的測試案例（traceability）。
• 落地建議：在 SRS 裡必須寫清楚「當感測器失效，系統進入什麼安全模式」。

2. IEC 61508（通用功能安全）

• 背景：適用於工業控制與一般電子系統。
• 案例：智慧工廠裡的 AI 控制機械手臂。
• 落地建議：設計 fail-safe 狀態，例如停機或降速。

3. DO-178C（航空軟體安全）

• 背景：航空系統軟體驗證標準。
• 場景：無人機、自動駕駛飛行器。
• 落地建議：AI 模組通常只能輔助，最終決策仍需冗餘系統驗證。

第三章：隱私與資料保護 — 使用者信任的基石

AI × Hardware 的感測器常蒐集影像、聲音、定位，這些都可能涉及隱私。

1. GDPR（歐盟）

• 重點：個資必須有明確用途、使用者可要求刪除、必須最小化蒐集。
• 案例：智慧吸塵器上傳家中地圖，是否經過使用者同意？
• 落地建議：在 PRD 明確規定資料蒐集目的與保存週期。

2. CCPA（加州）

• 重點：強調使用者可選擇「不出售資料」。
• 案例：IoT 裝置蒐集數據後給第三方廣告商。

3. ISO/IEC 27001（資訊安全管理系統）

• 背景：資訊安全的管理系統框架。
• 適用：需要雲端後端的 AI × Hardware 系統。
• 落地建議：建立 log 與監控，確保數據不被濫用。

第四章：IoT 與邊緣設備 — 小裝置的大漏洞

很多 AI × Hardware 會部署在 IoT 裝置上，而這些通常是資安最薄弱的環節。

1. ETSI EN 303 645（IoT 安全標準）

• 重點：預設密碼必須避免、必須有更新機制。
• 案例：智慧門鎖被攻破的新聞屢見不鮮，原因就是預設密碼與不更新。
• 落地建議：在 PRD 裡必須加一條「產品必須支援 OTA 更新」。

2. NIST SP 800-183（IoT 架構）

• 重點：如何安全管理感測器到雲端的連線。
• 落地建議：加密傳輸、金鑰輪換。

3. IEEE P7000 系列（AI 倫理設計）

• 特色：針對 AI 系統的人權、隱私與透明度設計。
• 案例：可穿戴醫療裝置的 AI 分析，不應造成歧視或差別待遇。

第五章：如何在專案裡落地？— 我的實務做法

標準再多，如果沒有落地方法，最終只會變成文件堆疊。我常用這些技巧：

1. 把標準翻譯成 PRD 條款
   • 例如：GDPR → PRD 必須寫「使用者可刪除數據」的需求。
2. 用 Spec 驗證合規
   • 例如：ISO 26262 → 每個需求對應一個測試案例。
3. 在圖表裡標出風險點
   • 例如：sequence diagram 裡標記「感測器輸入 → 資料隱私」。
4. AI 輔助產生草稿
   • 用 AI 生成合規清單，再人工檢查。

第六章：案例故事 — 從吸塵器到無人機

案例一：智慧吸塵器

• 問題：上傳家中地圖 → GDPR 個資疑慮。
• 解法：PRD 裡加入「資料不出裝置」，並提供刪除選項。

案例二：無人機

• 問題：自動避障功能，涉及安全性。
• 解法：Spec 裡加入「感測器失效時，必須降落」。符合 IEC 61508。

案例三：工廠機械手臂

• 問題：OTA 更新可能被惡意利用。
• 解法：強制韌體簽章，符合 ETSI EN 303 645。

第七章：合規地圖總覽（整理表）

結語：追風的人需要地圖

當我從 PM 轉到 Program Manager，再到需要懂合規的 SA，我發現：
寫 PRD 不只是寫功能，而是寫「產品能否合法、安全存在」的根基。
這些國際標準看似繁瑣，其實就是那股無形的風，吹著我們走在更穩健的道路上。

當 AI × Hardware 的專案在會議桌上討論時，我會攤開這份「地圖」，告訴大家：

• 哪裡有山壁（強制法規）
• 哪裡有暗流（資安漏洞）
• 哪裡有捷徑（AI 協助檢查）

追風的人不是盲目衝撞，而是帶著地圖，找到與風同行的方向。

參考與延伸閱讀

• NIST AI Risk Management Framework
• ISO/IEC 22989: AI Concepts and Terminology
• ISO/IEC 23894: AI Risk Management
• ISO 26262: Road Vehicles – Functional Safety
• IEC 61508: Functional Safety
• DO-178C: Software Considerations in Airborne Systems
• GDPR
• ETSI EN 303 645
• IEEE P7000 Series