標籤: 脫敏管道

為什麼要從「順序」談起

很多公司導入 AI 治理失敗,不是技術不行,是順序錯了。常見錯誤:

• 先買 Gateway 軟體,再去定資料分級 → 規則沒依據,Gateway 變裝飾
• 先請大家寫 brain markdown,沒有 Curator 制度 → 3 個月後變過期文件墳場
• 先做華麗 Dashboard,沒有 audit log 來源 → KPI 是亂編的
• 先全公司鋪開,沒先試點 → 第一週體驗不好,80 人對系統信任歸零,救不回來

本文每個 Step 都標「為什麼是這個位置」,讓你看完知道哪些可以平行、哪些必須串行。

四維檢查框架

每個 Step 都要回答四個問題。如果一個 Step 四維都打不到 ≥1 分,就砍掉 — 是 nice-to-have,不是 must-have。

Phase 0:基礎準備(W0–W2)

不要先動程式碼。先把組織結構和知識容器建好。

Step 1 — 召集 Working Group(W0,3 天)

• 目標:讓 5-7 人(準 CISO + 法務 + IT + 3-4 部門 senior + 老闆 sponsor)成為這套系統的第一批決策者
• 動作:第一次會議 60 分鐘,議程:同步為什麼要做、確認名單、排定 Phase 0 清單會議、訂下兩週一次例會
• 產出:一份 working group 章程文件、會議紀錄、共享日曆
• 四維:🔒 ✅(分級權威來源)、🛡️ —、📚 ✅(決策歷史可追)、😊 ✅(員工知道有人扛責)
• 常見坑:老闆不到場 → 後面拍板沒人敢動;法務一個人說了算 → 後面所有東西判 A 級

Step 2 — 建立雙 Repo(W1,2 天)

• 目標:把「公司腦」和「個人腦」變成兩個物理上分離的 git repo
• 動作:在公司 GitHub Org 建 company-brain(private)、發給每位員工一份 personal-brain template(github classroom 或 cookiecutter)
• 產出:兩個 repo + README 說明使用方式 + .gitignore 範本
• 四維:🔒 ✅✅(個人腦永不 push 中央=物理保證)、🛡️ ✅(git 提供版本+回復)、📚 ✅(每筆變更有 PR)、😊 ✅(員工用熟悉的 git workflow)
• 常見坑:個人腦放公司 GitHub 而不是員工自己的 → 隱私保證失效;沒有 .gitignore 擋掉 .env / 密碼檔 → 第一週就有人 commit 進去

Step 3 — Iron Rules v0(W1-W2,1 週)

• 目標:寫下 3-5 條全公司必守的紅線,變成 company-brain/global/CLAUDE.md
• 動作:Working Group 開 1 次會議,每個人提 5 條,合併成 3-5 條全體共識
• 範例:「禁止把客戶合約原文送雲端 LLM」「Bug log 進公司腦前必須脫敏」「所有 brain 修改必須走 PR」
• 產出:CLAUDE.md v0 commit 進 company-brain/global/
• 四維:🔒 ✅(底線設定)、🛡️ —、📚 ✅(規則進 git)、😊 ✅(規則少而清楚 > 50 條沒人記)
• 常見坑:寫成 30 條 → 沒人記得住;寫太抽象(「做正確的事」)→ 不能執行

Phase 1:同步機制(W3–W4)

讓「腦子」能流到員工每個 AI 工具。不寫 Gateway,先解決 build & sync。

Step 4 — build.sh 中性編譯器(W3,3-5 天)

• 目標:一個 script 把 markdown 編譯到所有 AI 工具的格式
• 動作:寫 bash / Python script,輸入 company-brain/ + personal-brain/,輸出:
  • .claude/CLAUDE.md(Claude Code / Desktop)
  • .cursor/rules/*.mdc(Cursor)
  • .github/copilot-instructions.md(Copilot)
  • ~/chatgpt-system-prompt.md(ChatGPT 用 Custom GPT 貼用)
• 關鍵設計:每個 brain 檔的 frontmatter 加 tools: [claude, cursor, copilot, gpt],編譯時依目標 model 過濾
• 產出:可執行的 build.sh + 4-5 種工具的編譯範例
• 四維:🔒 ✅(可依工具過濾敏感腦)、🛡️ ✅(編譯失敗有錯誤訊息)、📚 ✅(中性格式不被工具鎖死)、😊 ✅✅(員工不用學新格式)
• 常見坑:編譯太久 → 員工不願意每天 build,設成 git pre-push hook 自動跑

Step 5 — 種子部門試跑(W4,1 週)

• 目標:挑 10-15 人的部門(通常是 RD)當第一批用戶,真實流量驗證 Phase 0+1
• 動作:每天收 1 次回饋(短 Slack 頻道)、每週 1 次 30 分鐘 retro 會議、補 brain
• milestone:第一週結束,company-brain 有 ≥10 筆 brain markdown(由種子用戶產出)
• 四維:🔒 —、🛡️ ✅(早期發現問題)、📚 ✅(brain 種子)、😊 ✅(早期使用者教其他員工)
• 常見坑:挑錯部門 → 行政部根本不寫 brain;挑太大部門 → 回饋處理不過來。挑用 AI 最多的小團隊

Phase 2:分級與脫敏(W5–W8)

這是整個系統的核心。沒這 Phase,後面 Gateway 全是空殼。

Step 6 — 分級對應表 v0.1(W5-W6,2 週)

• 目標:列出 50-100 種公司會接觸的資料類型,粗分 A/B/C
• 動作:Working Group 兩次會議,每次 90 分鐘,一次處理 30 種
• 產出:company-brain/global/data-classification.md 表格化,進 git 管理
• 原則:不糾結邊界 → 先有 v0.1 → Phase 2 試點時精修
• 四維:🔒 ✅✅✅(整套架構的權威來源)、🛡️ —、📚 ✅✅(可審計、可移交)、😊 —(員工目前還用不到,但是後續所有 UX 的基礎)
• 常見坑:法務說「不確定就 A 級」→ 後續 Gateway 90% 流量被擋,系統失效。**邊界 case 預設 B 級**(脫敏後可送雲),不是 A 級

Step 7 — 脫敏字典 v0(W7,5 天)

• 目標:三份純文字字典,擋掉 80% 紅字
• 動作:從 CRM / HR / 專案系統匯出
  • client_names.txt(客戶公司名 + 簡稱)
  • employee_names.txt(員工姓名 + 暱稱 + Slack ID)
  • project_codes.txt(內部專案代號、產品代號、合約格式 regex)
• 產出:三份 .txt + 每月由 HR / PM 維護的責任分配
• 進階(可選):接 Microsoft Presidio v2.2.362(2025/3 釋出,2026/5 仍是最新版)當第二層補強。Presidio 是開源 PII 脫敏框架,內建 NER + regex + checksum,支援多語言,還有 image redactor 處理 DICOM 醫療影像。字典擋已知字、Presidio 擋通用 PII(信用卡、身分證、地址等),兩層疊加。
• 四維:🔒 ✅✅(一次擋掉 80% 洩漏)、🛡️ ✅(純文字,壞不掉)、📚 ✅(離職員工從字典移除有歷程)、😊 ✅(員工不用記哪些字是紅字)
• 常見坑:字典放 git 中 → 字典本身就是敏感資料(客戶 list)。要放另一個 access-controlled repo,build.sh 用 SSH key 拉

Step 8 — Pre-commit Hook + Browser Extension MVP(W8,1 週)

• 目標:在員工提交 brain 時、貼資料到網頁版 LLM 時,第一道防線
• 動作:
  • Pre-commit hook(.git/hooks/pre-commit):掃 staged 檔案,字典命中就 block commit
  • Browser Extension(Chrome/Edge):偵測 chat.openai.com / claude.ai 的 paste 事件,字典命中跳警告 + 自動替換
• 產出:兩個工具 + 內部 IT 自助安裝頁
• 四維:🔒 ✅✅(防呆,擋住 80% 「員工懶得開 IDE」場景)、🛡️ ✅(本地執行,不 break 工作流)、📚 —、😊 ✅(警告比阻擋友善)
• 常見坑:Pre-commit 跑太慢(掃整個 repo) → 員工 git commit --no-verify 繞過。**只掃 staged diff**,< 1 秒

Phase 3:Gateway 上線(W9–W16)

這是工程量最大的 Phase。前面都做完才有意義。

Step 9 — LLM Gateway 骨架(W9-W11,3 週)

• 目標:用開源 AI Gateway 做基礎,偽裝 Anthropic / OpenAI API。2026 主流選擇:LiteLLM(unified API 到 100+ providers)、Portkey(內建 guardrails + PII redaction + observability)、Kong AI Gateway。企業常見組合是 LiteLLM 當 proxy + Portkey 做 observability。
• 動作:
  • 架 LiteLLM 在內網(Docker),或用 Portkey self-host
  • 第一版只做 proxy + audit log,不做分級
  • 讓種子部門切過來:ANTHROPIC_BASE_URL=https://company-llm.internal/v1
• 產出:可用 Gateway + audit log 進 SIEM + 每日 throughput 報告
• 四維:🔒 ✅(流量集中)、🛡️ ✅✅(HA + 健康檢查)、📚 ✅✅(全程 audit)、😊 ✅(員工只改一行設定)
• 常見坑:沒做 HA,Gateway 掛 = 80 人不能工作。**第一天就要 HA**,或備用 endpoint 自動切換

Step 10 — 三層漏斗實作(W12-W14,3 週)

• 目標:在 Gateway 內加分級 + 路由邏輯
• 動作:
  • Layer 1:Aho-Corasick 演算法搜字典(< 5ms)
  • Layer 2:fine-tune 小模型做分類(BERT、Qwen3 1.7B、Llama 3.2 3B 都可),0.1-0.3s
  • Layer 3:fail-safe 全部判 B 級走脫敏 + 雲端
• 產出:三層命中率分布 dashboard
• 四維:🔒 ✅✅✅(自動分級)、🛡️ ✅(每層獨立可降級)、📚 ✅(每筆分類有紀錄)、😊 ✅(員工無感)
• 常見坑:一開始就追求 Layer 2 LLM 完美 → 永遠上不了線。**先 Layer 1 + Layer 3 兩層上線**,Layer 2 之後加

Step 11 — 雙引擎接入(W15-W16,2 週)

• 目標:把雲端 frontier 和本地頂級開源模型都接進 Gateway
• 動作:
  • 雲端:簽 Anthropic Enterprise(Claude Opus 4.7)、Azure OpenAI(GPT-5.5)、AWS Bedrock(多家)、Google Vertex AI(Gemini 3.1 Pro)。要 DPA + zero data retention 條款。2026 主流是「routing by task type」:Opus 4.7 跑 multi-file coding、GPT-5.5 跑 terminal/browser、Gemini 3.1 Pro 跑 long-context research。
  • 本地:架 Ollama 或 vLLM(production 用 vLLM,2-4x 並發)+ Qwen3-Coder-Next(80B 總參 / 3B active,MoE,256K context)或 Qwen3.6,給 A 級任務專用。MoE 架構讓消費級 GPU 可跑。
  • Gateway 路由規則:A 級 → 本地、B 級 → 脫敏 + 雲端、C 級 → 直接雲端,並依任務型別選最適合的雲端模型。
• 產出:完整雙引擎可用、第一張月度安全報告(攔了多少 A 級)
• 四維:🔒 ✅✅✅(A 級永不出去)、🛡️ ✅(雲端掛了本地頂)、📚 ✅(成本/用量數據)、😊 ✅(員工拿到 frontier 能力)
• 常見坑:用個人帳號的 Claude / GPT → ISO 27001 第三方供應商不過。**必須 Enterprise 合約有 DPA**,費用貴 30-50% 但這是硬門檻

Phase 4:治理機制(W13+,與 Phase 3 並行)

沒這個 Phase,brain 會在 6 個月內變垃圾堆。Gateway 蓋好但沒 KPI,3 個月後沒人知道有沒有效。

Step 12 — Curator 制度(W13,2 週啟動)

• 目標:每個 team 一個 Curator,有權合併 / 刪除 brain
• 動作:
  • 挑選:每 team 一個 senior(自願 + 部門主管同意)
  • 授權:GitHub team admin 權限 + 每週 1 小時 review brain PR
  • 儀式:每季全公司「腦子健檢日」,半天清掃過時 brain
• 產出:Curator list + review SLA(PR 5 個工作天內處理)
• 四維:🔒 ✅(防止劣化)、🛡️ —、📚 ✅✅✅(知識保鮮)、😊 ✅(垃圾不會堆)
• 常見坑:Curator 沒被分配時間 → 永遠不 review。**1 小時/週要正式排進 KPI**,不是「有空就做」

Step 13 — KPI Dashboard(W14-W16,3 週)

• 目標:把 North Star + 四象限 KPI 變成可看的 dashboard
• 動作:
  • 串 Gateway audit log → Grafana / Metabase / 自寫
  • 串 firewall log → 偵測網頁版 LLM 流量
  • 串 git activity → 計算 brain 增長率
  • 每月例會看「3 個問題」:North Star、Top 3 繞過原因、安全收益
• 產出:每月 dashboard + 月報自動產生
• 四維:🔒 ✅(可量測)、🛡️ ✅(早期警告)、📚 ✅(歷史趨勢)、😊 ✅(高層願意持續投資)
• 常見坑:做太多指標(20+)→ 沒人看。**只看 5-7 個**,北極星 + 四象限就夠

Phase 5:長期演進(M5+,持續)

系統上線後不是結束。三件事要持續做。

Step 14 — ISO 對應與稽核準備(M5-M6)

• 目標:把 Step 1-13 的產出對應到 ISO 27001 / 42001 控制措施
• 動作:
  • 產出 iso-mapping.md:每條 ISO 控制措施 → 對應的 Step + 證據(git log / Gateway log / Dashboard)
  • 第一次內部稽核(找外部顧問跑一遍)
  • 修正稽核發現的 gap
• 產出:ISO 對應表 + 稽核 readiness 報告
• 四維:🔒 ✅✅(對外背書)、🛡️ ✅(壓力測試)、📚 ✅✅(合規資產)、😊 —(這 Phase 員工不會直接受益,但對外贏單時受益)
• 常見坑:把稽核當一次性活動 → 證書到手就鬆懈,3 年後重審手忙腳亂。**Dashboard 要持續跑**,稽核資料 90% 自動產出

Step 15 — 第二批工具支援(M5+)

• 目標:涵蓋第一批沒處理的工具
• 動作:
  • ChatGPT 透過 Custom GPT Action 串 Gateway HTTP API
  • 移動端 Claude / ChatGPT app(只能靠規則 + 教育,管不到)
  • n8n / Dify / 自建 workflow 接 Gateway
• 四維:🔒 ✅(更多入口受控)、🛡️ —、📚 ✅、😊 ✅(更多員工享受到拉力)

Step 16 — 過時知識淘汰機制(M6+)

• 目標:防止 brain 累積成考古學遺址
• 動作:
  • 每筆 brain 加 last_verified: 2026-05 frontmatter
  • 用量遙測:90 天無 reference 的 brain 自動標 stale: true
  • 每季 Curator 審 stale list,合併 / 刪除 / 更新
• 四維:🔒 —、🛡️ ✅(防誤用過期知識)、📚 ✅✅(品質才是知識的本質)、😊 ✅(搜尋更準)

16 Step 全景表

關鍵心法:這 16 步背後的設計原則

1. 安全在前,但好用不能放最後

Phase 0-2 都在做安全基礎設施,但每個 Step 的「好用」維度都要 ≥1 分。**安全是必要不充分,沒有好用的安全系統會被員工繞過,等於沒做**。Step 4 的 build.sh、Step 8 的 Browser Extension,都是「安全 + 好用」並重的範例。

2. 物理保證 > 規則約束

能用 git 結構保證的(Step 2 雙 Repo),不要靠政策文件。能用 Pre-commit hook 自動擋的(Step 8),不要靠員工自律。能用 Gateway 路由強制的(Step 11),不要靠規範。**規則會被忘記,結構不會**。

3. 拉力 > 推力

Step 11 雲端 frontier 接入是「拉力」核心 — 員工為什麼選 Gateway 不選網頁版?因為 Gateway 給他 frontier model + 公司腦自動注入 + 速度更快,**而且不用自己付費**。讓 Gateway 比網頁版好用,員工自然不繞過。

4. 先粗版上線,真實流量精修

Step 6 分級表 v0.1、Step 7 字典 v0、Step 9 Gateway 骨架都明確標 v0 / 骨架。**等想清楚才上線 = 永遠不上線**。Phase 2 試點 4-6 週收斂的速度,比關門想 6 個月快 10 倍。

5. 治理機制與技術建設並行

很多公司先蓋 Gateway 再想 Curator,結果 Gateway 上線 6 個月後 brain 變垃圾堆。Step 12 Curator 在 W13 啟動,**和 Step 13 KPI Dashboard 並行**,因為 brain 累積速度從 Phase 1 試點就開始,治理不能等。

常見問題

16 週太長,3 個月能上線嗎?

可以,但要砍 Phase 3+4。「3 個月版」=Step 1-8 + 簡化版 Gateway(只做 proxy + audit log,不做分級),Phase 4 治理機制延後。**重點是先把基礎(雙 Repo + 分級表 + 脫敏字典 + 種子部門)立起來**,Gateway 可以 v0.5 上線、v1.0 慢慢迭代。

16 步可以跳哪幾步?

可跳:Step 8(Browser Ext)、Step 15(第二批工具)。 不可跳:Step 1(Working Group)、Step 6(分級表)、Step 12(Curator)— 跳了系統會壞。 可緩:Step 14(ISO 稽核)— 等系統穩定再啟動。

一個人(全職)能撐多少?

• Phase 0-2(8 週):一個人可獨立完成,主要是文件 + 字典 + 簡單 script
• Phase 3 Gateway(8 週):**要 1.5-2 個 RD**,因為要做 HA + 規則層 + 雲/本地對接
• Phase 4-5(持續):0.5 個 RD + 0.3 個 CISO 角色就能維護
• **最低配置:1 個全職 RD + 1 個準 CISO 兼職,跑 4 個月**

沒有 ISO 認證需求,還要做這套嗎?

要,只是 Step 14 可以跳。這套架構即使不認證 ISO,**對「accumulating domain knowledge」「員工生產力」「資安基線」三件事**都有獨立價值。ISO 是副產品,不是目的。

結語:安全 / 穩定 / 累積 / 好用,缺一不可

大部分企業 AI 治理失敗,不是某一維崩了,是四維沒有平衡:

• 只要安全 → 員工地下繞過 → 安全也沒了
• 只要穩定 → 沒有治理 → 半年後變垃圾堆
• 只要累積 → 沒有 Gateway → 客戶資料外流
• 只要好用 → 沒有分級 → 一夕事故

這 16 步的順序,就是「四維平衡的最小可行路徑」。每一步都至少打中兩維,串起來就是一個能跑、能審、能成長、員工願意用的系統。

第 0 週要做的事只有一件:打開行事曆,把 Step 1 的 Working Group 第一次會議排進去。其他 15 步都會跟著動起來。

延伸閱讀:《80人公司的AI腦子系統:從個人腦擴展到全公司不洩密的工程設計》 — 講為什麼這樣設計、雙引擎本地+雲、能管 vs 不能管的邊界、拉力哲學。本文是它的實作續篇。

2026/5 技術棧時間戳

本文 Step 9-11 涉及的具體工具版本以撰文時間為準:

• Gateway:LiteLLM(open source)、Portkey(內建 guardrails + PII redaction + 1600+ LLM)、Kong AI Gateway。企業常見組合 LiteLLM + Portkey 雙搭。
• 本地 LLM:Qwen3-Coder-Next(80B-A3B MoE,256K context)、Qwen3.6、Kimi K2.6、DeepSeek V4、Llama 3.3 70B。Ollama 為日常 default,production 並發推 vLLM V1。
• 雲端 frontier:Claude Opus 4.7(2026/4)、GPT-5.5(2026/4)、Gemini 3.1 Pro、DeepSeek V4。各家擅長領域不同,「routing by task type」是 2026 主流架構。
• PII 脫敏:Microsoft Presidio v2.2.362(2025/3 釋出,2026/5 仍是最新版),含 image redactor + DICOM 支援。
• 合規認證:ISO/IEC 42001:2023(目前唯一可認證的 AI 管理系統標準)。Schellman、TÜV SÜD、BSI、DNV 都是合格認證機構。