小丁的家

標籤: ISO 42001

  • 腦子系統壓軸:萬人製造集團 AI 治理 1 年實戰藍圖

    重點摘要(TL;DR)

    • 腦子系統前 7 篇是理論藍圖。本篇是萬人跨國製造集團 1 年實戰執行版:Day 1 到 M12 的 5 個 Phase Gate、三層治理、預算 NTD 4,000-6,000 萬具體 breakdown、22 個關鍵 gap、5 場真人會議。
    • 骨架不是憑空寫的 — 經過 4 輪 AI agent review × 10 個 domain × 28 份 expert opinion:CISO / AI 治理 / ERP / 法務 / IT 架構 / 組織變革 / 製造業 BU senior / HR / CFO / 外部會計師。
    • 核心心法 5 條:鄉村包圍欽點啟動、三條紅線下放、90 天法律化(非 30 天)、三道防線(內稽必須第三線獨立)、預算具體到 NTD 級距(非「中等到中高」)。
    • 給 CIO 的訊息:這份藍圖的價值不是告訴你答案,是告訴你接下來要問哪 5 群真人哪些問題。
    • 本文是腦子系統八部曲的壓軸實戰篇。前七篇:Why / How / Scale / Tools / ERP / Self-Service / ISO。

    一、為什麼寫這篇

    腦子系統前 7 篇講的是理論:為什麼這樣設計、怎麼蓋、怎麼擴展。但理論到實戰之間,有一條鴻溝 — 萬人跨國集團的真實政治、文化、預算、合規。

    這個鴻溝不是 1 篇文章 + 1 個 IT 主管腦袋能跨過。我為一家萬人製造集團寫了完整的 1 年實戰藍圖,經過4 輪 AI agent review × 10 個 domain expert(總共 28 份 expert opinion)後,把所有 cross-confirmed 的議題壓縮成這一篇。

    10 個 domain 包括:

    • CISO 資安(ISO 27001 + OWASP Top 10 LLM 紅隊)
    • AI 治理(ISO 42001 + 倫理 + 偏見)
    • ERP 架構(SAP / Oracle / iDempiere / Dynamics)
    • 法務合規(個資法 / 營業秘密法 / GDPR / 勞基法)
    • IT 架構(K8s / Gateway / SRE / vLLM)
    • 組織變革(萬人台灣集團 + 家族企業文化)
    • 製造業 BU senior 主管(20 年資歷)
    • HR / 員工關係(第四輪新增)
    • CFO / 財務(第四輪新增)
    • 外部會計師 / 內控(第四輪新增)

    每一個 domain 都找出了前面 9 個 domain 沒看到的盲點。這是本文跟一般 AI 治理藍圖的根本差異:不是某個 IT 主管的個人見解,是 28 份不同視角壓縮的最大公約數。

    二、戰略骨架(一句話)

    鄉村包圍城市:三條集團紅線下放 → 各 BU 自然生長 → 根據地正規化 → Working Group 整理已發生事實 → 集團 Gateway 上線。

    不從總部開始,從願意動的 BU 開始。起爆階段必須欽點(不能等自願)、擴散階段才靠拉力。

    為什麼不用傳統由上而下:啟動成本太高、規範是空白紙上畫的(法務全判 A 級系統失效)、員工沒採用動機。

    三、三條 Iron Rules + 90 天法律化(不是 30 天)

    1. BOM 配方 / 製程參數 / 合金成分 / 熔煉 know-how
   → 禁止送任何雲端 LLM
   → 「送出」涵蓋: completion / embedding / vector / fine-tune /
     batch / log retention / 第三方 RAG
   → 違反視同營業秘密外洩

2. 未公告財報數字(月報 / 季預估 / 年度計畫 / 財務假設)
   → 禁止送任何 AI 工具(含本地)
   → 違反視同內線交易風險

3. 客戶合約 / 訂單金額 / 供應商報價 / 客戶聯絡資料
   → 禁止送雲端 LLM
   → 須脫敏後才可使用 AI 協助分析

    第一個重大修正(來自會計師 review):CIO 一人簽 Iron Rules 在台灣上市公司治理上有重大瑕疵 — 涉及營業秘密 + 重大資訊管控屬資安政策層級,需經審計委員會或董事會核備。CIO 單簽日後查核會被會計師列 deficiency。

    真實時程 90-120 天(原藍圖寫 30 天嚴重低估):

    階段 動作 時間
    Day 1 CIO 緊急發布(行政命令位階)+ 全員 email 1 天
    Day 1-30 CISO 簽核 + 法遵核可 30 天
    Day 30-60 工會協商(勞基法 § 70 細則,30 天起) 30 天
    Day 60-90 工作規則修正報主管機關核備 14-30 天
    Day 90-120 審計委員會核准 + 董事會決議 30 天

    過渡期免責條款(會計師建議):Day 1-90 期間若違規,公司立合規導向處理(培訓 + 警告),不得作為解雇 / 賠償依據。否則「合理保密措施」舉證會被法院質疑。

    工會協商失敗 fallback(HR review):Iron Rule 1(BOM)走營業秘密法 § 13-1 強制,不需工會同意;Rule 2/3 走員工自願同意 + 工具權限分流(不簽就限制 AI 工具,不解雇)。

    四、五個 Phase Gate

    Gate 月 通過硬條件
    G0 啟動 M1 CIO 簽 Iron Rules + 任命準 CISO + 法遵 / 內稽通知
    G1 種子 M3 至少 2 個 BU 各 5 人在用、無 Iron Rules 違反
    G2 根據地 M4-M5 至少 2 BU 完成雙 Repo + 分級表 v0.1 + 脫敏字典
    G3 包圍 M8 Working Group 4 場核心會議完成 + 集團 v1 + AIIA SOP + Iron Rules 走完董事會核准(若 M8 未完,fallback「議程已排定 + 審計委員會初審通過」)
    G4 進城 M9-M10 Gateway + 雙引擎接入 + 北極星 70% + ERP MCP 1 BU 跑(用 Token Impersonation,不是 service account)
    G5 稽核就緒 M12 內審完 + Gap 補完 + ISO 27001 + 42001 stage 1 audit 通過

    五、三層治理結構(三道防線正確版)

    第二輪 AI review 點出 v0.2 違反三道防線(內稽應第三線獨立),v0.3 大幅修正:

    [第二線:管理]
├─ Steering Committee(每季 sponsor)
│  └─ 家族成員 / 總經理室掛名,不參與每月運作
│  ⚠️ 議事規則明文「不得對 Working Group 個案決議下指導」+ 會議錄音
│
└─ Working Group(7-8 人,雙週例會,治理者)
   ├─ 準 CISO(主席)
   ├─ 法務 / 法遵代表
   ├─ IT/RD 代表
   └─ 3-4 BU senior 代表

[第三線:獨立監督]
└─ AI 治理監督委員會(每季,獨立)
   ├─ 內稽處長(召集人,雙線報告:行政→CIO,職能→審計委員會)
   ├─ 1 名獨立董事
   └─ 外部顧問(由審計委員會選聘 + 預算獨立 + 3 年輪換)

   季度 audit Working Group 自身 + Gateway log + bias probe
   直接向審計委員會報告(不經 CIO)

[第一線:執行]
└─ BU 內部
   ├─ BU Curator(技術骨幹,每週 45 分跑 PR)
   ├─ BU Senior 把關人(每週 15-30 分簽字)
   └─ BU 種子員工

    家族干預仍是 SOX 疑點(會計師 review):即使家族「掛名 sponsor」,Big-4 仍可能列「tone-at-the-top deficiency」。所以加 Steering Committee 議事規則 + 會議錄音是必要補丁。

    外部顧問獨立性閉環:必須由審計委員會選 + 預算獨立 + 3 年輪換 + 不得轉任公司任何職位,否則 Big-4 視為 management’s specialist 形同虛設。

    六、AI Agent Team 編制 + Curator HR 認證

    v0.1 寫「BU senior 兼任 Curator 每週 1 小時」,但 HR review 點出實務上 100% 推給課長 / 工程師 — senior 行事曆已被「客訴會、月結、業務檢討、產能調度」塞滿。v0.3 拆角色:

    • BU Curator(技術骨幹):>8 年資歷工程師,每週 45 分跑 PR review
    • BU Senior 把關人:senior 主管,每週 15-30 分簽字 + A 級判斷 + 口述補充業務知識

    HR 認證制度(避免空文化)

    • 完成 6 個月任期 + brain 達標 → HR 核發「AI 治理認證」
    • 0.5 P-band 加分(等同跨部門輪調)— 但需走集團人才發展委員會核可,IT 處單獨發會被 HR 退件
    • PBC 5%-10% 權重(集團強制下限 7%,避免 BU 主管壓到 5%)
    • senior 連 2 週缺席 → 自動升級 CIO,1 個月失能撤銷認證
    • 分初級 / 資深 Curator:資深需 2 年 + 跨 BU 貢獻才核發,避免認證貶值(1-2 年後人人有獎=沒獎)

    培訓教材決策(M2 必須定)

    8 小時 OWASP Top 10 LLM + ISO 42001 + 公司 brain 規範。中文教材沒現成 — 外購(BSI / SGS 客製課 35-60 萬/梯)vs 內製?M2 前必定。HR LMS(Cornerstone / SuccessFactors / 自建)需要排版上架、考題設計、合格標準 ≥ 80%、補考機制。

    七、預算 NTD 4,000-6,000 萬具體 breakdown(CFO 視角)

    v0.3「中等到中高」級距完全不能進審計委員會。CFO 真實要的數字:

    項目 級距 NTD 備註
    CapEx GPU 3-5x H100 1,200-2,000 萬 DGX 整機約 $300K USD/台,5 年攤提 ≈ 250 萬/年
    CapEx 多台 4090 200 萬 本地推理 + Layer 2 分類器
    OpEx 雲端 LLM Enterprise 1,500-3,000 萬/年 萬人 seat × $40-80/月(Anthropic / Azure / Bedrock)
    OpEx ISO 雙標稽核 + 內審準備 200 萬 Schellman / TÜV SÜD / BSI / DNV 任選
    OpEx RD x 2 + Curator 折算 600 萬
    OpEx SIEM 自架 stack 100-150 萬 OpenSearch + S3 + Glacier vs Splunk 商業版 3,000-8,000 萬,自架降一個量級
    OpEx 培訓教材外購 60-100 萬 BSI / SGS 客製課
    Year 1 全包 4,000-6,000 萬 這是 CFO 要的具體數字

    稅務套利(產創條例 §10-1)

    • GPU CapEx 認列「智慧機械」可申請 5% 投資抵減營所稅
    • 萬人集團單年 H100 採購 1,500 萬 → 抵減 75 萬
    • 5 年攤提下,財報「壓力」比一次性 OpEx 燒掉小

    ROI / Risk-Adjusted Savings(對審計委員會講)

    • 避免 GDPR 罰鍰:營收 4% 上限(萬人製造集團風險:數十億)
    • 避免 ISO 失效訂單損失:B2B 客戶常要求 ISO 認證,失效 = 失客戶
    • 員工生產力:保守 5% × 萬人 × 平均薪資 = 數億效益
    • 對審計委員會用「保險費比喻」,不要堆生產力數字

    預算占比 / 排擠效應

    • 萬人製造集團年 IT 預算約營收 0.8-1.5%
    • AI 治理 4-6 千萬 ≈ IT budget 8-12%
    • 會排擠 ERP 升級 / MES / 製造 IoT — 必須在董事會列「AI 治理 vs 其他 IT 投資」優先序

    隱性成本(v0.3 漏)

    • Layer 2 GPU HPA 4x baseline → 雲端 burst 月結尖峰可能單月燒 30% 預算 → 加 monthly cap
    • 廠商封鎖演練(每年 1 次)→ 計入 BCP 成本
    • WORM 7 年 audit log 取出費(egress)→ incident 時單次可能數十萬,需準備金

    八、Audit Log 三軌制(法庭採信 + 個資合規)

    Track 內容 保留 儲存 / 解密
    A. Metadata 員工 hash、tool、decision_code、bu_context、token jti 7 年 WORM OpenSearch 30天 → S3 1年 → Glacier 7年;HSM mapping CISO+法務雙簽
    B. 全文 prompt/response 完整對話內容 90 天 OpenSearch 加密分離,90 天自動刪
    C. Incident 凍結全文 觸發事件相關全文 7 年 WORM S3 Object Lock;CISO+法務+內稽三方簽

    HSM mapping 雙簽 break-glass 必須留書面審批單(會計師補丁):申請書 + 核准單 + 時戳服務(TWCA)。否則 SOX 404(d) ITGC 證據能力不足。

    勞動事件法 § 35(法務補丁):員工有舉證請求權調閱自身 audit log → 加員工查閱 SLA 14 天 + HR 介接窗口。

    九、4 輪 AI review 找出的 22 個 cross-confirmed gap

    從 28 份 expert opinion 提煉的最重要議題,按 review 階段:

    第一輪(v0.1 → v0.2,7 個 expert):結構性問題

    • Iron Rules 加 embedding / vector / fine-tune 涵蓋(防 OpenAI embedding 破口)
    • Curator 拆角色(senior + 技術骨幹)
    • Multi-ERP 不做統一 schema
    • SAP S/4HANA 工程量 6-9 個月(原估 3-4 嚴重低估)
    • Token Impersonation 強制(禁用 service account)
    • 三條 Iron Rules 治理路徑(CIO 簽不夠)
    • Brain PR Scanner + 雙審 + 簽章 commit

    第二輪(v0.2 → v0.3):重大治理結構

    • 三道防線正確化(內稽從 Working Group 退出第三線獨立)
    • 家族介入降溫(Steering Committee 季度 sponsor,不掛主席)
    • WORM 三軌制(metadata 7年 / 全文 90 天 / incident 7 年)
    • MCP tool schema 欄位級遮罩
    • iDempiere MSession + cache 分級 + 月結 SLO 例外
    • Gateway K8s HPA 5-15 pods(不寫死 3)
    • GPU 容量 3-5x H100 + 區域副本
    • 同意書脫鉤雇用條件
    • per-BU view scope(不全集團統一最高 A 級)
    • 跨境 geo-routing by 工作地 BU(不 by 國籍)

    第四輪(HR + CFO + 會計師)— 進階 gap(只在新 domain 加入後才被發現)

    • §16 重寫具體 NTD 級距 + 產創條例 §10-1 + ROI(CFO P0)
    • 30 天法律化時程改 90-120 天 + 過渡期免責(會計師 P0)
    • 監督委員會獨立性閉環(內稽行政線雙線報告 + 外部顧問獨立預算 + 3 年輪換)(會計師 P0)
    • HSM break-glass 留書面審批單 + 時戳(會計師 P0)
    • bias probe 獨立 validator(自選 = 自評違反 A.6.2.4)(會計師 P0)
    • 工會協商 fallback(HR P0)
    • HR LMS + 培訓教材外購 / 內製決策(M2 必定)(HR P0)
    • 退休 / 離職 brain 智財 + 錄影同意 SOP(HR P0)
    • 勞動事件法 § 35 員工查閱 SLA 14 天(法務 P0)

    關鍵 insight:第四輪 9 個 gap 是前 3 輪沒有任何 expert 點到的 — 這證明 HR / CFO / 外部會計師三個 domain 是真正的盲點。任何 AI 治理藍圖如果沒有這 3 個 domain 獨立 review,等於沒做完。

    十、真人 review 接手 — 5 場會議

    會議 時長 對象
    法律 / 合規 review 2-3 hr 法遵處長 + 外部勞動法律師 + 個資律師 + 工會代表
    組織治理 review 2 hr CIO + 法遵 + 內稽 + 獨立董事 + 審計委員會
    財務 review 2 hr CFO + 財務副總 + 集團 IT 預算負責人
    HR review 1.5 hr HR 處長 + LMS 負責人 + 工會代表
    IT / 工程 review 2-3 hr IT 主管 + RD lead + ERP 顧問
    BU 實戰 review 各 1.5 hr BU senior + 種子員工(各 BU 一場)
    ISO 機構 mock audit 半天 Schellman / TÜV SÜD / BSI / DNV 任選

    第一次 mock audit 應在 M9(不是 M11),時間夠改正。SOC 2 Type 2 需 6 個月運行證據,M12 才 Stage 1 → SOC 2 Type 2 報告最快 M18+。

    十一、Day 1 待確認的 6 件事

    1. 三條 Iron Rules 法務 review — BOM 配方、未公告財報、客戶合約合不合法務認知
    2. ERP 現況 — SAP / iDempiere / Oracle / Dynamics / 混合?(影響 30% 工程量)
    3. 準 CISO 人選 — IT 主管?資安代表?
    4. 種子 BU 候選 — 欽點 1 個營收前三主力 BU(不要等自願)
    5. 預算核給 — Year 1 NTD 4-6 千萬具體編列
    6. ISO 稽核機構意向 — Schellman / TÜV SÜD / BSI / DNV 任選一家

    十二、給 CIO 的最後三句話

    三條 Iron Rules + 90 天法律化 + 鄉村包圍欽點啟動 = Day 1 全部要做的事。

    4 輪 AI review + 28 份 expert opinion 找到的 22 個 gap 是骨架。真正的肉、血、溫度,在你接下來那 5 場真人會議。

    這份藍圖的價值不是「告訴你答案」,是「告訴你接下來要問哪 5 群真人哪些問題」。

    延伸閱讀:腦子系統八部曲

  • 腦子系統 ISO 整合治理框架:6 篇收成 1 個合規可審計藍圖

    重點摘要(TL;DR)

    • 把腦子系統前六篇收成合乎 ISO 27001:2022 + ISO 42001:2023 的整合治理框架。雙標準有 ~40% 重疊,已 27001 認證可快 30-40% 取得 42001。
    • 多場景多用戶多工具的統一架構:5 個共用元件(Gateway / 分級表 / Audit log / Curator / KPI Dashboard)+ 4 類工具(Coding Agent / Chat-native / Bridge / Self-service HTML)+ 5 種角色(銷售 / 客服 / 採購 / RD / 管理層)。
    • 鄉村包圍踏實落地的 5 個 Phase Gate:每個階段過渡前要過硬條件,對應 ISO 稽核里程碑。沒過 Gate 不要硬上下一階段。
    • 月度健檢三個關鍵指標:覆蓋率(80%+)、合規 gap 減少率、稽核就緒度。月度報告 ≠ 一次性稽核 — 持續可量測。
    • 稽核準備 90% 自動化:從 git log / Gateway log / Audit DB / Curator review 自動 export,RD 投入時間從 1-2 個月降到 1-2 週。
    • 本文是腦子系統第七篇收尾。前六篇:Why / How / Scale / Tools / ERP / Self-Service。

    一、問題重述

    腦子系統六篇文章寫完後,有個關鍵問題沒明確收斂:

    1. 整套架構合不合 ISO 27001 + ISO 42001?哪些直接合、哪些有 gap?
    2. 第三篇的「鄉村包圍」策略講了大方向,但怎麼穩定踏實做完?哪些真實風險會讓計劃流產?
    3. 多場景(銷售/客服/RD/管理層)、多用戶(80 人 vs 萬人)、多 AI 工具(Claude Code / OpenCode / QwenPaw / Self-service HTML)— 怎麼用一套框架統一治理?
    4. 怎麼確保多方都得到正確、安全、合規、整合的資料?

    本文是腦子系統的收尾整合,把前六篇收成可審計、可執行、可量測的治理框架。

    二、ISO 範圍界定(事實驗證)

    2.1 適用標準三件套

    標準 範圍 關鍵內容
    ISO 27001:2022 資安管理(ISMS) Annex A 共 93 controls,4 themes(Organizational 37 / People 8 / Physical 14 / Technological 34)
    ISO 42001:2023 AI 管理(AIMS) Annex A 共 38 AI-specific controls,9 control objectives,Clauses 4-10 結構
    ISO 27701 個資管理(PIMS) 針對 GDPR / 個資法,腦子系統的脫敏管道對應這個

    2.2 雙標準的重疊與互補

    • ~40% 重疊:Annex A 的 Clauses 4-10 結構大部分一致(Context / Leadership / Planning / Support / Operation / Performance / Improvement),已 27001 認證可快 30-40% 取得 42001([來源])
    • 60% AI-specific:42001 的 Clause 8(Operation)幾乎沒重疊 — AI Risk Treatment / AI System Impact Assessment / AI System Lifecycle / Data Management 都是 27001 沒有的
    • 同樣 3 年認證週期,可整合 audit 降低 disruption

    實務建議:先 27001 → 再加 42001。如果並行做,跟同一個認證機構(Schellman / TÜV SÜD / BSI / DNV)約整合稽核,證據文件大量 reuse。

    三、六篇文章 × ISO 控制項映射

    每一篇對應到具體 ISO 控制項。標 ✅ 是文章已涵蓋,標 ⚠️ 是 gap 需要補。

    3.1 ISO 27001:2022 Annex A 對應

    Control 名稱 對應篇 狀態
    A.5.10 Acceptable use of information 第 1 篇 Iron Rules ✅
    A.5.12 / A.5.13 Classification / Labelling of information 第 1 篇 A/B/C 分級 ✅
    A.5.19-21 Supplier relationship 第 4 篇 OpenClaw 教訓 ✅
    A.5.34 PII protection 第 2 篇脫敏 pipeline ✅
    A.6.3 Awareness, education, training 第 1 篇 Layer 3 規則+教育 ✅
    A.8.3 Information access restriction 第 5 篇 iDempiere AD_Role ✅
    A.8.15 Logging 第 2 篇 Gateway audit log ✅
    A.8.20-23 Networks security / Web filtering 第 1 篇 Gateway 流量管制 ✅
    A.8.28 Secure coding 第 6 篇 LLM 產 HTML 安全規範 ⚠️ 部分
    A.8.32 Change management 第 2 篇 git PR review ✅
    A.5.7 Threat intelligence 未涵蓋 ⚠️ Gap
    A.5.30 ICT readiness for business continuity 未涵蓋 ⚠️ Gap
    A.7.x Physical controls(機房 / 進出管制) 未涵蓋 ⚠️ 範圍外

    3.2 ISO 42001:2023 Annex A 對應(關鍵 9 個 control objectives)

    42001 Annex A 範疇 對應篇 狀態
    AI 政策(AI Policy) 第 1 篇 Iron Rules + 第 2 篇 Working Group ✅
    AI 風險評估(AI Risk Assessment) 第 2 篇分級表 + 第 4 篇 OpenClaw 廠商風險 ✅
    AI 系統影響評估(AI Impact Assessment) 第 2 篇 Working Group 跨部門 ✅
    AI 系統生命週期(AI System Lifecycle) 第 2 篇 Phase 0-5 + 第 4 篇 Harness 修改 ✅
    資料治理(Data Management) 第 5 篇 iDempiere AD_Role + 分級表 ✅
    透明度與可解釋(Transparency) 第 4 篇三層漏斗(規則優先,LLM 兜底) ✅
    第三方關係(Third-party relationships) 第 4 篇 Enterprise 合約 + DPA ✅
    監控與量測(Monitoring & Measurement) 第 2 篇 KPI Dashboard ✅
    人為監督(Human Oversight) 第 2 篇 Curator + 第 6 篇預設 read-only ✅
    偏見緩解(Bias Mitigation) 未明確涵蓋 ⚠️ Gap
    事故管理(AI Incident Management) 部分(audit log 可追,但無 SOP) ⚠️ 部分

    四、Gap 補強方案

    對應前面標 ⚠️ 的條款,給每個 gap 具體補強做法:

    4.1 A.5.7 Threat intelligence

    • 定期收集 LLM 廠商安全公告(Anthropic / OpenAI / Microsoft 等)
    • 訂閱 prompt injection / jailbreak / model 漏洞情報源(OWASP Top 10 for LLM Applications)
    • 每季 working group 會議納入「AI 威脅情報」議程,新威脅進腦子的 brain markdown

    4.2 A.5.30 ICT readiness for business continuity

    • Gateway 高可用(HA)+ 失效時的降級策略(本地 LLM 接管)
    • 本地 Ollama 機器是 backup endpoint(雲端 frontier 掛時切回來)
    • BCM 演練每年 1 次:模擬 Anthropic API 全面斷掉,測員工是否能繼續工作

    4.3 A.8.28 Secure coding(LLM 產 HTML)

    • 第 6 篇講的「textContent 不用 innerHTML」、「不用 eval」是 prompt 規範,但需要 server side 驗證
    • Gateway 端加 HTML scanner:用 ESLint security rules 或 OWASP HTML Sanitizer 掃 LLM 產的 HTML
    • 不通過 scanner 的 HTML 不出 Gateway,改要員工重新 prompt

    4.4 ISO 42001 偏見緩解(Bias Mitigation)

    • 定期測試 LLM 對特定 prompt 的回應差異(性別、年齡、地區)
    • 建立 baseline test set:每季用同一組 prompt 測各廠 LLM,看 bias drift
    • Working Group 評估該 bias 是否影響業務,進腦子 brain markdown 註明

    4.5 AI 事故管理(Incident Management)

    • 定義「AI 事故」:LLM 產生危害內容、員工誤洩 A 級資料、Gateway 規則失效、模型 hallucination 造成業務錯誤等
    • SOP:發現 → 通報 CISO → audit log 凍結 → 影響評估 → 補救 → 事後檢討進 brain
    • 每年至少 1 次 incident 演練(tabletop exercise)

    五、鄉村包圍踏實落地的 5 個 Phase Gate

    第三篇講了大方向。本節補上「每個 Phase 過渡前的硬條件」,沒過 Gate 不要硬上下一階段。每個 Gate 同時對應 ISO 稽核里程碑。

    Gate 時機 硬條件 ISO 對應
    G0 啟動 M1 W1 CIO 簽核 3 條集團 Iron Rules + 任命準 CISO 42001 Clause 5 Leadership commitment
    G1 種子 M2 結束 至少 2 個 BU 各有 5 人在用、無重大 Iron Rules 違反事件 27001 A.6.3 Awareness 已生效
    G2 根據地 M4 結束 至少 2 BU 完成雙 Repo + 分級表 v0.1 + 脫敏字典 + Pre-commit hook 27001 A.5.12-13 + 42001 Data Management
    G3 包圍 M6 結束 Working Group v1 集團 CLAUDE.md + 集團分級表 + 三場核心會議全 done 42001 Clause 6 Planning + AI Policy 落地
    G4 進城 M9 結束 Gateway 上線、雙引擎接入、KPI Dashboard 跑、北極星比例 > 70% 27001 A.8.x + 42001 Clause 8 Operation
    G5 稽核就緒 M12 內部稽核完成、gap 補完、外部稽核機構 walk-through 通過 兩標準 stage 1 audit 通過

    5.1 過 Gate 的紀律

    • G1-G2 沒過,不要進 G3 包圍:沒實戰數據的 Working Group 會回到「法務全判 A 級」失敗模式
    • G3 沒過,不要急著裝 Gateway:沒分級表的 Gateway 是裝飾,只浪費 RD 時間
    • G4 沒過,不要排稽核:北極星 < 70% 表示員工沒採用,稽核員問「實際運作」會答不出來

    六、多場景統一治理框架

    6.1 五個共用元件(全公司一套)

    元件 角色 維護方
    LLM Gateway 所有 AI 流量必經(LLM call + ERP query) 中央 RD + IT
    分級對應表 A/B/C 級資料定義 Working Group 月度 patch
    Audit Log 全程紀錄(誰、何時、查什麼) 中央 SIEM
    Curator 制度 brain 品質把關 + 過時知識淘汰 每 BU 一名
    KPI Dashboard 月度健檢 + 北極星追蹤 中央 RD

    6.2 五種角色 × 四類工具的整合矩陣

    角色 \ 工具 Coding Agent Chat-native Bridge Self-Service HTML
    RD ✅ 主要 輔助 ✅ 出差/移動 輔助
    銷售 不適用 ✅ 主要 不適用 ✅ 主要
    客服 不適用 ✅ 主要 不適用 ✅ 主要
    採購 不適用 ✅ 主要 不適用 ✅ 主要
    管理層 不適用 輔助 不適用 ✅ 主要(儀表板)

    關鍵:不同角色用不同工具,但全部走同一個 Gateway。Gateway 那層的分級 / 脫敏 / audit / 路由規則,所有工具共用。

    6.3 確保「正確 / 安全 / 合規 / 整合」的四個機制

    • 正確:資料不來自 LLM 幻覺,而是來自 ERP via MCP/Gateway。LLM 只是把 ERP 資料整理 + 渲染,不產生資料
    • 安全:三層縱深 — 員工身分(SSO)、Gateway 規則(分級脫敏)、ERP 角色(AD_Role)
    • 合規:每個元件都對應 ISO 控制項,稽核證據自動 export
    • 整合:Single Source of Truth — 不同部門看到的資料一致(因為都來自同一個 ERP)、不同 AI 工具產的回應背後是同一個 Gateway

    七、月度健檢:踏實的可量測指標

    7.1 北極星(唯一最重要)

    本月 Gateway request 數 ÷ (Gateway + 偵測到的網頁版 LLM 流量)
目標: 90%+
< 70% = 拉力策略失敗,要查為什麼員工繞過

    7.2 三個關鍵健檢指標

    指標 定義 目標 頻率
    覆蓋率 月活使用 Gateway 員工 / 全公司 80%+ 月
    合規 gap 減少率 本季新發現 gap 數 vs 已修復 gap 數 修復 ≥ 新增 季
    稽核就緒度 90% 證據可從系統自動 export M9 後達標 季

    7.3 月度報告(高層用)

    不要丟一堆數字給高層,只回答三個問題:

    1. 「上個月 X% 員工選擇 Gateway over 網頁版」← 北極星
    2. 「員工繞過 Gateway 的 Top 3 原因」← 下個月修哪邊
    3. 「ISO 稽核就緒度 + 安全收益 + 雲端費用」← 投資回報

    八、稽核準備 90% 自動化

    傳統公司 ISO 稽核要花 1-2 個月補資料、做文件、開會。腦子系統的設計讓大部分證據自動產出:

    稽核需要的證據 來源 準備時間
    AI 政策文件 + 變更歷史 company-brain git log 0(隨時可拉)
    分級表執行紀錄 Gateway audit log 0(已存在)
    脫敏執行實證 Gateway pipeline log 0(已存在)
    員工訓練紀錄 HR 既有訓練系統 既有資料
    第三方供應商 DPA 合約管理系統 既有資料
    KPI 持續監控 Dashboard 0(自動產生)
    變更管理 git PR 紀錄 0(已存在)
    事故管理 SIEM ticket 系統 既有系統
    人為監督 Curator 月度 review log 0(已存在)

    結果:RD 投入稽核準備時間從 1-2 個月降到 1-2 週。準備重點變成「整理 + 解釋」,而不是「補資料」。

    九、12 個月時程(對應第三篇 + 本文)

    月 關鍵交付 Gate
    M1 Iron Rules 三條 + 準 CISO 任命 + 種子 BU 招募 G0
    M2 2 BU 種子員工開始用 AI G1
    M3-M4 BU 各自雙 Repo + 分級表 v0.1 + 脫敏字典 G2
    M5-M6 Working Group 三場核心會議 + 集團 v1 G3
    M7-M9 Gateway 上線 + 雙引擎 + Self-service HTML + iDempiere MCP G4
    M10-M11 Gap 補強 + 內部稽核 + 外部顧問 walk-through —
    M12 ISO 27001 + 42001 stage 1 audit G5

    對 80 人公司:可加速到 6-9 個月。對萬人集團:可能延長到 18 個月,但鄉村包圍策略讓每個 BU 看到自己的進度,而不是等全集團一起。

    十、結語:從 6 篇到 1 個治理框架

    前六篇是分散的拼圖:Why / How / Scale / Tools / ERP / Self-Service。本篇把它們收成一個整體。

    「合不合 ISO」答案是:大部分天然合,有 5 個 gap 要補強。「鄉村包圍怎麼踏實做完」答案是:5 個 Phase Gate + 月度健檢 + 北極星 KPI。「多場景多用戶多工具怎麼統一」答案是:5 個共用元件 + 角色×工具矩陣。

    真正讓系統「正確、安全、合規、整合」的不是任何一個元件,是所有元件都會合在 Gateway 那一層:那是員工、AI、ERP、稽核員看的同一個交集點。設計對了,後面都對。

    對企業 IT 主管的最後一個具體下一步:

    1. 把本文的 ISO 控制項對應表存成 git repo 一份檔,作為日後稽核 SoA(Statement of Applicability)的基礎
    2. 下一次 working group 會議,把本文的 5 個 Phase Gate 排進共享日曆
    3. 稽核機構初步接洽:Schellman / TÜV SÜD / BSI / DNV 任選一家,問整合 27001 + 42001 報價
    4. 北極星 KPI 上 dashboard,讓員工看得到(透明度本身是 ISO 42001 的要求)

    延伸閱讀:腦子系統七篇

    可運作的 Reference Links(2026/5 撰文時驗證)

    ISO 標準官方

    Annex A 控制項對照(實作指南)

    業界實戰

    OWASP Top 10 for LLM(對應 A.5.7 Threat Intelligence)

  • 萬人跨國集團如何導入AI腦子系統:農村包圍城市策略

    重點摘要(TL;DR)

    • 萬人跨國集團導入 AI 腦子系統,不能用 80 人公司的 16 步從上到下做法 — 規模差兩個量級,順序要倒過來:農村包圍城市。
    • 四階段:農村期(各自長)→ 根據地期(BU 正規化)→ 包圍期(中央彙整)→ 進城期(集團 Gateway),總時程 6-12 個月。
    • 唯一不能省的前提:集團 Iron Rules 三條紅線今天就要 CIO 一人發出(BOM 配方/未公告財報/客戶合約)。其他都可以等。
    • 核心翻轉:Working Group 從第一步延後到第三階段,Iron Rules 從第三步前置到最開始,Gateway 從中段砍到最後。
    • 本文是《80 人公司的 AI 腦子系統》(why)和《16 步驟實戰建置》(how)的尺度延伸版。前兩篇是 80 人,本篇是萬人。

    一、為什麼不用由上而下

    傳統企業 IT 系統導入是由上而下:高層決策 → 統一規範 → 全面部署。這個模式在萬人跨國集團有三個致命弱點:

    1. 啟動成本極高

    第一步就需要 CIO + 法務 + 各事業群 VP 全員對齊,光是排到那個會議就要一個月,對齊完再兩個月,什麼都還沒做就半年過去了。

    2. 規範是空白紙上畫出來的

    在真實使用前就要定出 500+ 種資料分級,必然失準。法務傾向把所有邊界 case 定 A 級,導致 Gateway 裝好後 90% 流量被擋,系統等同報廢。

    3. 員工沒有動機

    「IT 規定要用」跟「用了真的更方便」,員工選哪個不言而喻。由上而下的系統沒有拉力,員工繼續用自己的 ChatGPT 帳號,治理形同虛設。

    二、農村包圍城市的核心邏輯

    借用毛澤東的戰略概念:不從總部開始,從願意動的團隊開始。

    農村期            根據地成形        包圍城市          進城
各自長出來   →   各 BU 正規化   →  由上而下彙整  →  大腦子上線
(自然生長)      (誰準備好誰先走)  (整理已有事實)    (全集團 loop in)

    每個階段的關鍵心法:

    • 農村期:不強制格式,不需要中央協調,只要三條紅線保底
    • 根據地:哪個 BU 準備好就先走,不等其他人
    • 包圍城市:Working Group 整理的是「已發生的事實」,不是「空想的規範」
    • 進城:Gateway 最後才裝,分級表已經實戰驗證,不是猜測

    三、唯一不能省的前提:集團 Iron Rules

    農村期開始之前,有三條紅線今天就要定下來。不需要 Working Group,CIO 一人決定即可發出。

    集團 AI 使用紅線 v0(全員適用)

    1. BOM 配方、製程參數、合金成分比例
      → 禁止送任何雲端 LLM,僅可使用公司核准的本地 AI 工具
    2. 未公告財報數字(月報、季預估、年度計畫)
      → 禁止送任何 AI 工具(含本地)。違反視同內線交易風險處理
    3. 客戶合約原文、訂單金額、供應商報價
      → 禁止送雲端 LLM,須脫敏後才可使用 AI 協助分析

    為什麼只有三條:條數越多,記得住的人越少。三條紅線,員工背得起來,才有意義。

    四、四個階段詳細規劃

    第一階段:農村期(各自長出來)

    • 時間:2-3 個月
    • 壓力:低,自然生長,不強制
    • 需要誰:願意動的 RD / Senior,不需要主管強制

    各 BU 各自做的事

    動作 說明 工具
    個人 brain 開始建立 員工把自己的工作 SOP、常見 prompt、領域知識整理成 markdown 任何工具(Obsidian / Notion / 純文字均可)
    BU 層級 Iron Rules 在集團三條之上,各 BU 自己再加 3-5 條(例:電線電纜加「電纜規格書禁止送雲端」) 一份 Google Doc 即可
    BU 資料類型盤點 列出「我們 BU 最常碰到的 20-30 種資料,哪些是絕對不能送出去的」 表格,不需要格式
    紀錄什麼 AI 用得好 哪些場景 AI 幫上忙?哪些場景踩過坑? Slack 頻道 / 週會口頭分享均可

    農村期的成功標準

    • 每個 BU 至少有 5-10 個員工在用 AI 做日常工作
    • 每個 BU 至少有 1 個人願意分享自己的 brain / prompt 給同事
    • 集團三條 Iron Rules 沒有被違反的事件

    農村期刻意不做的事

    • ❌ 不裝 Gateway(分級表還沒出來,裝了是空殼)
    • ❌ 不要求統一格式(這個階段要讓實踐先長出來)
    • ❌ 不開大型跨 BU 會議(成本高,收益低)
    • ❌ 不建集中式 repo(時機未到)

    第二階段:根據地成形(各 BU 正規化)

    • 時間:每個 BU 各自 1-2 個月,可以交錯進行
    • 壓力:中,BU 主管需要支持,但不需要集團介入
    • 關鍵原則:誰先準備好,誰先走。不等其他 BU。

    正規化的六個動作

    ① 建立 BU brain repo

    {bu-name}-brain/  (BU 私有 git repo)
├── global/
│   └── CLAUDE.md          ← BU Iron Rules(含集團三條)
├── departments/
│   ├── rd/
│   ├── sales/
│   └── manufacturing/
└── personal/              ← 員工個人 brain(不 push 至集團)

    .gitignore 必須擋掉:.env、密碼檔、含客戶名的原始資料

    ② BU 資料分級表 v0.1

    把農村期盤點的資料類型正式化,粗分 A / B / C:

    等級 定義 處理方式
    A 級 洩漏會造成法律責任或競爭損失(BOM、財報、客戶合約) 本地 LLM only / 禁止送 AI
    B 級 脫敏後可送雲端(去除識別資訊後的分析資料) 脫敏後可用雲端
    C 級 本來就是公開或無敏感性的資料 直接送雲端

    邊界 case 原則:不確定的預設 B 級,不預設 A 級。過度保守的分級會讓系統失效。

    ③ BU 脫敏字典 v0

    三份純文字,只需要這個 BU 用得到的:

    bu-client-names.txt      ← 這個 BU 的客戶名稱(從 CRM 匯出)
bu-employee-names.txt    ← 這個 BU 的員工(從 HR 匯出)
bu-codes.txt             ← 料號、專案代號、合約格式

    存放位置:不進 git,放另一個 access-controlled 位置,用 SSH key 拉取。

    ④ Pre-commit Hook 部署

    只掃 staged diff,< 1 秒完成:

    #!/bin/bash
# 字典命中就 block commit,提示員工手動脫敏
DICT_PATH="/secure/bu-dicts"
STAGED_DIFF=$(git diff --cached)

while IFS= read -r word; do
  [ -z "$word" ] && continue
  if echo "$STAGED_DIFF" | grep -qF "$word"; then
    echo "⛔ 偵測到敏感字詞:'$word'"
    echo "   請移除或脫敏後再 commit"
    exit 1
  fi
done < "$DICT_PATH/bu-client-names.txt"

exit 0

    ⑤ BU Curator 指定

    每個 BU 指定 1 名 Senior 擔任 Curator:

    • 每週 1 小時 review brain PR(排進週計畫,不是「有空就做」)
    • PR 5 個工作天內必須回應
    • 每季半天「腦子健檢」清掉過時 brain

    ⑥ 種子推廣

    Curator 挑 10-15 人的核心小組試跑 2-4 週,確認:

    • brain 真的有人用
    • Pre-commit hook 沒有造成工作流障礙
    • 分級表的 A/B/C 判斷在實際使用中合理

    確認後,向 BU 全員推廣。

    第三階段:由上而下彙整(包圍城市)

    • 時間:1-2 個月密集對齊
    • 時機:至少 2 個 BU 完成第二階段後才啟動
    • 這個階段 Working Group 才真正有意義

    為什麼這時候才開 Working Group

    此時 Working Group 做的是「整理已有的事實」:

    • 各 BU 帶著真實用過的分級表來開會
    • 各 BU 帶著真實踩過的坑來討論規則
    • 所有討論都有數據和案例,不是空想

    對比農村期就開 Working Group:那時所有人都在猜,法務說什麼都是 A 級,會議沒有結果。

    Working Group 三場核心會議

    • 第一場(90 分鐘):比對各 BU 分級表,找出共同模式(幾乎所有 BU 都把財報列 A 級)、找出差異點(電線電纜的料號是 A 級,不銹鋼的可能是 B 級)。產出:集團分級表草稿。
    • 第二場(60 分鐘):在三條保底紅線之上,加入各 BU 共識的條款。產出:集團 CLAUDE.md v1.0。
    • 第三場(90 分鐘):設計集團 Gateway 架構與統一格式 — 以各 BU 累積的真實流量數據為基礎,規劃集團共用編譯器(build.sh)、字典同步機制、Gateway 規則整合。具體實作對應 16 步建置的 Step 9-11,差別在於集團版是「整合多個已實證 BU 的版本」,不是「從 0 設計」。

    第四階段:進城(集團 Gateway 上線)

    • 時間:2-3 個月
    • 時機:Working Group 三場會議產出已落地、至少 2 個 BU 試過集團版規範

    這階段才裝集團 Gateway。具體實作 100% 對應 16 步建置的 Step 9-11(LLM Gateway 骨架 → 三層漏斗 → 雙引擎接入),差別在於:

    • 規模:集團採購 Anthropic Enterprise / Azure OpenAI 是大客戶等級合約,費率和 SLA 比 80 人公司有利
    • 路由:Gateway 規則已經被 2-3 個 BU 實戰過,直接套上不是猜測
    • 本地 LLM:集團規模可以共用一組中央 GPU 機房(8x A100 / H100),分攤到上千員工成本合理
    • 分級表:已經是 v3.0 而非 v0.1,失誤率低

    進城期結束 = 集團 AI 治理基礎建設完成。後續演進(ISO 認證、知識淘汰機制等)同 16 步的 Phase 5。

    五、16 步驟的對應關係

    這是把 80 人版的 16 步重新編排成萬人集團版的對應表。順序大幅調整,但每一步本身的工程細節不變 — 80 人版是教科書,本版是針對集團規模的「演奏順序重排」。

    原版步驟 農村包圍城市版對應 時機
    Step 1 Working Group 延後到第三階段,這時才有實際數據可以討論 M5-M6
    Step 2 雙 Repo 各 BU 在根據地期各自建,進城期才合併成集團架構 M3-M6
    Step 3 Iron Rules 前置到最前面,農村期開始前就要有三條 M1 Week 1
    Step 4 build.sh 進城期才需要集團版編譯器,各 BU 根據地期用簡化版 M7
    Step 5 種子部門 農村期本身就是種子,每個 BU 自然生長 M1-M3
    Step 6 分級對應表 各 BU 根據地期各自出草稿,Working Group 彙整 M3-M6
    Step 7 脫敏字典 各 BU 根據地期各自建,進城期接 SAP 自動同步 M3-M7
    Step 8 Pre-commit Hook 各 BU 根據地期部署,Browser Ext 進城期 MDM 統一推送 M3-M7
    Step 9-11 Gateway 進城期才裝,這時分級表已實戰驗證 M7-M9
    Step 12 Curator 各 BU 根據地期指定 BU Curator,Global Curator 在彙整期設立 M3-M6
    Step 13 KPI Dashboard 進城期 Gateway 上線後才有數據 M7+
    Step 14-16 ISO / 演進 系統穩定後(M10+)再啟動 M10+

    六、一句話說明這個策略

    原版是先建水庫再引水。

    這個策略是先讓各地水源自然流,找到真實路徑後,再建剛好合用的水庫。

    前者快但容易建錯地方;後者慢起步,但建好的系統是真實需求驅動的,員工願意用,知識才真正累積。

    第一步只有一件事:CIO 今天把三條紅線發出去。其他 15 步都會跟著動起來。

    延伸閱讀