---
# System prepended metadata

title: OpenChain 2026 「面對 AI 與國際趨勢：在企業推開源的你不孤單」#001 小聚共筆

---

# OpenChain 2026 「面對 AI 與國際趨勢：在企業推開源的你不孤單」#001 小聚共筆

歡迎來到本次小聚的共筆 👋 也會成為後續整理的重要依據。

## ⚠️ 共筆使用原則（請先閱讀）
本次活動採用[「查塔姆守則（Chatham House Rule）」](https://zh.wikipedia.org/zh-tw/%E6%BC%86%E5%92%B8%E6%A8%93%E5%8E%9F%E5%89%87)

* ✅ 可以記錄觀點、問題、案例
* ❌ 請勿記錄「可辨識個人或公司」資訊
* ❌ 未經同意，不記錄發言者姓名或公司名稱
* ⚠️ 除非當事人明確同意與揭露，可例外標註；
**意味著，如你可以、希望被揭露，請於發言時特別提出！**

👉 建議共筆寫法：
* 「某金融業公司…」
* 「一位做 AI 產品的團隊…」
* 「電信產業提出…」

## 簡報
[活動導引簡報](https://ggl.link/oc2026001)

## 🙋‍♀️ 暖場自我介紹區
大家可以先簡單打個招呼與簽到！

* Ian/劉雁 ｜ 開源治理、NGO ｜ AI-SBOM 怎麼跑 | 大家交流一起說出真的困難與找到相互幫助的機會
* 不具名（案場資安工程師） ｜ 後端、資安 ｜ 政府專案法規、CRA 對標案影響 | 想知道 CRA 何時影響在做台灣政府案子
* 現場發言 ｜ 金融/法務 ｜ 協助公司推動 OSPO 流程 | 尋求法律面與實務導入經驗交流
* 現場發言 ｜ 電信、高階管理 ｜ 開源產業化、出海策略 | 思考 CRA 對產業與企業投入的影響
* 現場發言 ｜ 硬體、半導體研發 ｜ CRA 對數位元件責任、供應鏈影響 | 釐清硬體與韌體的合規責任邊界
* 現場發言 ｜ 電信、工程 ｜ 企業內部開源導入 | 學習如何規劃開源並符合合規要求
* 未具名（營運管理） ｜ 營運管理、開源導入 ｜ 軟體代理與法規環境 | 理解企業在開源與法規間的實務挑戰
* 現場發言 ｜ 金融、開源倡議 ｜ SBOM、人才培育、文化推動 | 了解不同產業導入開源的痛點
* fangling ｜金融/法務 |  | 
* Tim ｜往 DevSecOps 的路上 | SBOM、DevSecOps | 了解 SBOM 相關的名詞
* Ryan ｜OSPO,Open source, DevRel | OSPO, Open source Compliance, AI Goverance | 了解最新的開源合規趨勢 
* IU | 開源貢獻者, COSCUP, 軟體工程師 | 了解開源合規與企業的關係 

---

## 🎤 18:30–18:45｜開場與歐洲趨勢

---
## 🌍 18:45–19:15｜CRA × 開源合規實務
講者：SZ Lin（OpenChain Ambassador）
### 重點整理
* 數位元件 -> Digital Element  
    * 不只是軟體，還包含韌體、硬碟、網卡等  
    * Middleware 也在範圍內，整個 stack 都可能被納入  
* 歐盟產品更新最少 5 年  
    * 對比早期智慧型手機，常常買到很快就 End of Life  
    * 車用、醫療本來就有更嚴格規範（如 MDR、TFDA）  
* RED（無線設備指令）  
    * 2025 先行上路  
    * 後續安全要求會逐步整合進 CRA  
* Secure by Design  
    * 像「安全帶」，不是事後加，是一開始就設計進去  
* Linux Kernel / 開源元件問題  
    * 「我沒改 code 為什麼要修？」  
    * CRA 邏輯：只要包進產品一起出貨，就要負責  

---

### CRA / 合規趨勢觀察
* 判斷標準從「是不是開源」→「是不是商業活動」  
    * 有收費、訂閱、資料利用、甚至特定支持都可能被認定  
* 責任從「開發者」→「市場上的產品提供者」  
    * 關鍵是「誰把產品放到市場上」  
* Logo 法則  
    * 誰的品牌在產品上，誰負最終責任  
    * OEM/ODM 模式會被重新檢視  
* 強制漏洞通報機制  
    * 24 小時初報、72 小時分析、4 天內完成報告  
    * 不通報風險很高（內部或同業可能揭露）  
* 「不一定要修，但一定要處理」  
    * 可用補償性控制（隔離、監控、防火牆等）  
* 開源管家（Foundation）角色  
    * 建立政策、協助通報，但不承擔產品責任  
    * 將責任從社群轉移到商業使用者  

---

### 台灣可能面臨的挑戰
* 多數企業還沒有完整 SBOM / 資產盤點能力  
* 舊系統、 legacy code 很難追溯來源與漏洞  
* OEM/ODM 結構下責任分工不清楚  
* 法務、工程、資安之間缺乏整合機制  
* 對 CRA 等國際法規理解仍在早期  
* 成本壓力  
    * 是否會影響企業是否繼續進入歐洲市場  
    * 或轉嫁到供應鏈與中小企業  

---
# 💬 19:15–20:30｜QA 與企業交流（重點區🔥）
👉 大家可以直接補充自己想討論的情境或問題

### 現場提問

* 每一個出口到歐洲的產品，都要重新做合規檢查嗎？  
    * 新舊產品皆受影響：CRA 重點在「進入市場」，不只新產品，舊產品若仍在歐洲銷售也需符合規範  
    * 五年回溯期：需對 2022 年以來產品負擔安全維護責任  
    * 硬體連鎖效應：整機需確認每個數位元件（網卡、SSD 等）皆合規  

* CRA 何時、以什麼形式影響台灣市場或政府標案？  
    * 台灣已開始接軌：標檢局（BSMI）已導入參考歐盟標準（EN 303 645）之 CNS 規範  
    * 政府標案方向：數位發展部、經濟部已提出開源使用指引，納入 SBOM 與治理概念  
    * 目前多為鼓勵性質，但未來可能制度化  

* 導入 SBOM 與合規流程的成本與人力怎麼估？  
    * 不是買工具就好：SBOM 重點在流程與上下游整合  
    * 長期投入：通常是 2–3 年的組織轉型，而非一次性專案  
    * 類比 RoHS：如同硬體供應鏈曾全面重整，軟體也將面臨同樣規模的治理成本  

* 如果無法修補漏洞，什麼情況下可以「接受風險」？  
    * 不需修補所有漏洞：重點是「已被處理且風險可接受」  
    * 可用補償性控制：如物理隔離、監控、防火牆等方式降低風險