中小企業老闆部署 Slack / Microsoft Teams AI 助理完整指南：4 條技術路徑、5 個資料邊界、3 個治理紅線

「Slack 官方 AI 一個 seat 一個月 60 美金，我們 50 人就是 3,000 美金——但我不知道它能不能讀我的 Notion，也不確定 DM 裡的薪資討論會不會被 AI 看到。」這是六月我們最常聽到的問題。幾乎每隔一兩週，就有中小企業老闆或 IT 主管帶著這個困惑來問。

我們公司自己每天就在跑 20+ 個 AI 流程，其中 5 條接 Slack webhook——包括客戶詢問單自動分類、weekly digest、跨系統資料同步，以及 n8n 自動把 GitHub issue 彙整後推進 Slack 指定頻道。一年下來我們沒有用 Slack 官方 AI，但最近 6 月有兩家客戶問我們同一件事：「要不要直接買官方 AI、還是自己接 webhook？」這讓我們花了不少時間把這個問題拆清楚。這篇文章就是那次拆解的結果。

先說結論：對 50 人以下的公司，真正要問的問題是「你的資料邊界能不能接受這個路徑」——工具誰比較強，在這裡反而是次要的。Slack AI 技術上很成熟，Microsoft Copilot 的整合也很深，但在你掏錢之前，有 5 個資料邊界和 3 個治理紅線必須先想清楚，否則往後一年你會為了「修邊界」花比工具本身更多的力氣。

這篇完整覆蓋四條技術路徑（官方 AI、第三方 marketplace、Zapier/Make/n8n 中介、自架 webhook）、五個資料邊界決策、三個治理紅線，以及一份 30/60/90 天部署里程碑。拆完讓你做完自己的決策，不需要全部外包出去。對整合細節有疑問，也可以參考我們的 AI 系統開發服務。

把 AI 嵌進 Slack / Teams 的四條路徑，各自的代價是什麼

在決定「要不要導入」之前，先把四條路徑的本質差異看清楚。這四條路徑的差異不在功能強弱，而在資料控制權、鎖定風險、導入門檻三個維度上的取捨。

路徑一：Slack AI / Microsoft Copilot for M365 官方方案

Slack AI 是 Slack 官方直接提供的 AI 功能，每個 seat 收 $10/月（Pro 方案附加費），Enterprise Grid 另計。它能做：頻道摘要、thread 摘要、搜尋強化、Huddle 逐字稿。優點是零導入複雜度，IT 主管當天就能開。缺點是它只讀 Slack 內部資料，Notion、Google Drive、內部 ERP 的資料它觸及不到。

Microsoft Copilot for M365 的定價是 每 seat $30/月（年約），須搭配 M365 Business 方案。Teams 整合最深，可以在會議中即時摘要、在 Teams chat 中問 SharePoint 裡的文件。但它綁定 Microsoft 生態：你的核心資料必須在 SharePoint / OneDrive，才能充分發揮——如果你的 SOP 在 Notion、客戶資料在 Google Drive，效果會大打折扣。

路徑二：第三方 marketplace bot（Glean、Notion AI for Teams、Guru）

這一類產品的定位是「跨工具知識搜索」。Glean 的中小企業方案約 $15-25/seat/月，可以同時讀 Slack、Google Drive、Confluence、Jira、Notion，在 Slack 裡直接 /glean 查詢。優勢是跨工具；缺點是多一個 OAuth scope，等於多開了一扇進入你 Slack workspace 的門——資料治理的面積變大了。

路徑三：Zapier / Make / n8n 中介層

這是我們自己用的路徑。n8n 透過 Slack Webhook 或 Slack Events API 監聽特定頻道的訊息，觸發後執行 AI 流程（Claude API / OpenAI API），再把結果 POST 回 Slack。成本是 API 用量（Claude API $3-15/MTok 不等）+ n8n 自架或雲端費用（自架近乎免費、n8n Cloud 從 $24/月起）。這條路徑最靈活、資料不出你的控制範圍——但需要有人懂 webhook 配置和 API 串接，不適合 IT 資源為零的公司。可參考我們的 AI 顧問服務了解評估要點。

路徑四：自架 chatbot 接 Slack / Teams webhook

這是 自架 AI 助理（#849）的延伸——把 Open WebUI 或 LibreChat 的回應接到 Slack 頻道。技術上需要自架一個 chatbot 服務，監聽 Slack events，呼叫本地 LLM 或 Claude/OpenAI API，回傳到 Slack。優點：完全自控、資料不出內網；缺點：維護成本高，需要專人管理基礎設施。適合資料敏感度極高、有自己 IT 團隊的公司。

四條路徑比較表

五個資料邊界：部署前每一條都要逐項確認

資料邊界是「AI 能看到哪些資料、誰能看到 AI 的輸出」這兩個問題的交集。在 Slack / Teams 裡，每一層都有各自的決策點，遠比想像中複雜。

邊界一：公開頻道（Public Channel）

Slack AI 預設可以讀所有公開頻道的歷史訊息（包含已離職員工發的訊息）。這對「知識搜尋」有用，但如果你的公開頻道裡有客戶名稱、合約金額、薪資討論——即使你以為那是「半公開」的，AI 都能整合到摘要裡。決策點：公開頻道的資料分類原則是什麼？有沒有不該放的資訊被放進公開頻道？

邊界二：私人頻道（Private Channel）

Slack AI 在 Business+ 以上方案可以讀私人頻道，但前提是使用者有該頻道的訪問權。IT 主管在啟用 Slack AI 時，需要確認：HR 頻道、薪資討論頻道、董事會頻道，是否應該排除在 AI 索引範圍之外。Microsoft Purview（Copilot for M365 的資料治理工具）可以做更精細的排除設定。

邊界三：直接訊息（DM）

DM 是最敏感的邊界。Slack Enterprise Key Management（EKM）文件明確說明：標準 Slack AI 不會讀 DM，除非使用者主動在 DM 中呼叫 AI 功能。但如果你用的是自架 webhook 方案，並且你的 Bot 有 `im:history` scope，它就可以讀所有 DM——這是你在 OAuth 授權時需要嚴格控制的 scope。決策點：你的 AI bot 需要哪些 Slack scope？有沒有比需要的更多？

邊界四：Connector / 跨工具整合範圍

有一個實際發生過的案例值得注意：某家 50 人公司在導入第三方 Slack bot 時，因為勾選了「讀取 DM 以提供更個人化的 AI 回覆」選項，結果三個月後員工才發現 HR 頻道的所有 DM（包含個別員工的薪資調整討論）都被 bot 索引了。這個案例的教訓是：OAuth scope 的授權流程對中小企業的 IT 主管來說通常太技術性，容易在快速點擊「允許」時授予超出需要的權限。建議的做法是：在授予任何 AI bot OAuth 權限之前，先列出它要求的每個 scope，對應到「這個 scope 讓 bot 能讀什麼」，然後逐一確認是否真的需要。最小權限原則（Principle of Least Privilege）在 Slack AI 整合裡尤其重要。

第三方 bot（Glean、Notion AI）在連接 Slack workspace 時，會要求讀取特定 scope。常見的風險點是「連接器一旦授權，未來新加入的頻道也自動納入索引」——你今天授權時只有 30 個頻道，六個月後可能有 60 個，其中包括新增的敏感頻道。決策點：使用第三方連接器時，是否有定期審查哪些頻道在索引範圍內的機制？

邊界五：訊息留存期（Message Retention）

Slack 的訊息留存政策（Message Retention）決定了 AI 能往回讀多遠。如果你的留存設為 180 天，AI 就能讀 180 天的歷史。如果你的公司有法遵要求（金融業、醫療業等），留存期和 AI 索引範圍的設定可能需要同步審查。決策點：AI 的訓練 / 索引範圍是否與你的留存政策和法遵要求一致？

五個資料邊界決策表

三個治理紅線：跨過這條線，補救成本會是導入成本的 10 倍

治理紅線是「一旦踩到，光是修補就會付出巨大代價」的邊界。這些代價有業界實際案例可以對照，每一條都有真實的補救成本數字。

紅線一：Shadow IT 上線（未經 IT 審查的 AI 工具）

中小企業最常見的場景：行銷部門自行訂閱了一個 Slack 上的 AI bot，IT 和老闆都不知道。那個 bot 有 channels:read 和 channels:history scope，三個月後才有人發現它一直在讀所有頻道——包括競標資訊、客戶報價、員工薪資討論。業界經驗顯示，Shadow IT 工具平均每家中小企業有 12 個，其中 4-6 個有資料讀取權限。把這個數字從 12 降到 3，是可以做得到的，方法是建立 AI 工具上線審查 SOP。可參考我們整理的「員工 AI 使用政策手冊」（#827）。

紅線二：客戶資料外流

Shadow IT 的問題在中小企業特別嚴重，因為中小企業沒有企業 IT 部門的審批流程。行銷部門看到一個好用的 AI Slack bot，當天就能裝——沒有採購審核、沒有安全審查。一個可行的輕量做法是：在 Slack workspace 的管理員設定中，關閉「所有成員可以安裝 App」，改為「只有管理員可以安裝 App」，再建立一個簡單的申請流程（Google Form + Slack 通知）。這個改動不需要花錢，但可以把 Shadow IT 從「每個人都能裝」變成「至少有人知道裝了什麼」。

Slack 上的客戶資料（合約細節、報價、投訴記錄）一旦進入 AI 的訓練 / 索引範圍，就面臨兩個風險：（1）跨客戶洩漏（AI 摘要中不小心混入其他客戶的資訊）；（2）AI 廠商的資料使用政策——某些 AI 服務會用使用者輸入的資料做模型微調。解法：在連接任何 AI 工具前，先確認廠商的資料使用政策，並對應你的客戶合約中的保密條款。可參考 AI 軟體廠商盡職調查 SOP（#818）中的 12 項審查清單。

紅線三：員工離職後的權限回收

當員工離職，他的 Slack 帳號被停用——但如果他在任時建立了一個 OAuth app（比如個人 Zapier 帳號接的 Slack 連接器），那個連接器的 token 不會自動失效。業界 IT 稽核發現，中小企業的離職員工遺留 token 平均需要 14 天才被發現和撤銷。目標是把這個 SLA 壓到 24 小時。方法：離職 SOP 中加一條「撤銷所有 OAuth token」的 checklist。

三個治理紅線對照表

我們認為 30 人以下的公司從官方 AI 起手，往往是錯的

這是一個有點刺的判斷，但我們認為值得說清楚。

Slack AI 和 Copilot for M365 在技術上很成熟，但它們的設計前提是「你的資料已經在對的地方」——Slack AI 假設你最重要的知識都在 Slack 頻道裡，Copilot 假設你最重要的文件都在 SharePoint。對 30 人以下的公司，這個前提幾乎不成立。你的 SOP 在 Notion，客戶資料在 Google Sheets，進貨記錄在老闆的 LINE 對話裡。這種情況下，你付了 50 人 × $10-$30/月 = $500-$1,500，換來的 AI 只能讀 Slack 或 M365 那一小塊資料。

我們的建議：先用 Zapier / Make 或 n8n 接 webhook 試 6 週，把你真正高頻的 1-2 條流程自動化，看流量、看效果，再決定要不要升級到官方 AI。這樣你至少知道「AI 在 Slack 裡能幫你做的事」的真實樣貌，而不是買了再試。預算和精力可以先集中在「把資料放到對的地方」，而不是「先買 AI 工具再說」。這個判斷跟我們內部的取捨一致：我們公司自己一年沒買官方 AI，但每天 5 條 Slack webhook 流程都在跑。

例外：如果你的公司 100% 在 Slack 上工作（IT、Sales、HR 的核心溝通都在 Slack，沒有平行的 Google Drive 或 Notion），那官方 Slack AI 確實值得考慮。那個「頻道搜尋」功能對高頻 Slack 用戶的價值是真實的——搜尋三個月前某個決策被誰說過、在哪個頻道，這個場景 Slack AI 做得比任何 webhook 方案都好。但即使如此，你仍然需要先做資料邊界設定，不能直接開啟就算完成部署。同樣地，如果你的公司全面在 M365 生態（全員 Outlook + Teams + SharePoint），Copilot for M365 的整合深度確實有其價值，尤其是「在 Teams 會議中即時摘要決議」這個場景。核心問題還是那個：你的核心資料在哪裡？AI 在哪裡才能幫到你？

30 / 60 / 90 天部署里程碑：從評估到穩定運行

無論走哪條路徑，這份里程碑的邏輯是一樣的：先做資料盤點和邊界設定，再做小規模試點，最後才是全面鋪開。很多公司跳過前兩個月直接做第三個月的事，然後花半年在修補問題。

第一個月最重要的輸出是「資料邊界決策文件」——不是技術文件，是業務文件。老闆、IT 主管、HR 三方都要簽字確認「哪些頻道可以給 AI 讀、哪些不行」。沒有這份文件，後面的所有技術部署都是在沙上蓋房子。

我們自己怎麼用：5 條 Slack webhook 流程的實際設計

在 AI 系統開發諮詢中，我們最常被問到的是「你們自己是怎麼接的」。以下是我們公司內部目前跑的 5 條流程，都是真實的、每天在運行的：

• 客戶詢問單自動分類：客戶在官網填表 → Payload webhook → n8n → Claude API 分類（服務類型、緊急度）→ 推進 Slack #inquiries 頻道並標 tag
• GitHub Issue weekly digest：每週一 9:00 AM 把上週新開的 GitHub issues 彙整成 Slack 訊息推進 #dev 頻道，附 priority label 和負責人
• Weekly AI 流程健康報告：n8n 每週統計各條 AI 流程的執行次數 / 失敗率，推進 Slack #ops 頻道
• 跨系統資料同步通知：Google Sheets 有新資料列 → Zapier → Slack #data 頻道通知，附超連結
• 文件更新 digest：Notion 特定 database 有新頁面 → n8n → Slack #knowledge 頻道摘要通知

這 5 條流程沒有一條用到 Slack 官方 AI——全部是透過 webhook 自己控制的。每條流程的平均月成本不到 $5（Claude API 用量）。但這不代表官方 AI 沒用，而是我們的場景需要跨系統整合，官方 AI 做不到這個。

員工面對 AI 助理的心態：技術上線只是第一步

很多老闆覺得「AI 工具上線了，員工自然會用」——但業界實際導入的經驗顯示，工具上線後三個月內，主動使用率通常不到 30%。背後有三個根本障礙：（1）員工不知道 AI 能幫他們做什麼；（2）他們擔心問 AI 的問題會被老闆看到；（3）他們不確定 AI 的回答能不能直接轉發給客戶。

這三個問題都需要在技術部署之外處理。關於員工 AI 訓練，可以參考 中小企業員工 AI 訓練計畫 60 天方案（#468）。關於 AI 使用政策，特別是「員工用 AI 的邊界在哪」，可以參考 AI 員工政策手冊：6 條款 4 紅線 3 分級使用（#827）。這兩篇和本篇形成一個三角：技術路徑（本篇）+ 員工政策（#827）+ 能力建立（#468）缺一不可。

一個讓員工使用率快速提升的做法：在 Slack 裡開一個 #ai-learning 頻道，每週讓一個員工分享他這週用 AI 省了什麼時間，或者遇到什麼 AI 回答的坑。這個頻道的心理安全感，比任何訓練課程都有效。

我們怎麼看：3 年後 Slack / Teams AI 的走向

Slack AI 和企業知識庫的關係：不要把它們搞混

這是個很常見的認知混亂：「我裝了 Slack AI，那我是不是就有內部知識庫了？」——兩件事不一樣。Slack AI 讀的是 Slack 的對話歷史，它不是一個結構化知識庫；RAG（Retrieval-Augmented Generation）系統讀的是你的正式文件（SOP、產品手冊、FAQ），它才是真正的知識庫。如果你想要後者，可以參考 企業內部知識庫 RAG 90 天路線圖（#521），那篇把 RAG 的技術路徑和導入節奏講得很清楚。

兩者可以並存：Slack AI 處理即時對話的搜尋和摘要，RAG 系統處理正式知識的查詢。但如果預算有限，先做哪個？我們的建議是先做 Slack AI（因為門檻低、見效快），再逐步建 RAG 系統——而不是反過來。原因很簡單：員工在 Slack 上的問題大部分是「即時型」的（「昨天的會議決議是什麼」「上週誰說要跟進 XX 客戶」），而不是「查文件型」的。

如果你想比較不同的協作工具和 AI 整合，也可以看一下 上班族 Slack 與 Teams AI 工作流 SOP（#606）——那篇是個人 / 上班族視角的工作流優化，跟本篇的「老闆部署決策」視角互補。

下一步：從路徑選型到試點部署

看到這裡，如果你手上的問題是「我知道要把 AI 接進 Slack / Teams，但不知道從哪一條路徑開始、資料邊界怎麼設」——這正是我們在 AI 系統開發和 AI 顧問服務中最常幫客戶做的那段工作：把框架設好，讓你的試點不會在六個月後要大幅返工。

這類整合在我們的 AI 系統開發和 AI 顧問服務範圍內。想討論你的內部 chat 怎麼接、資料邊界怎麼設——可以把現在的情況丟過來，我們陪你一起看看哪條路最適合你的規模和 IT 資源。也可以先看我們的 客製化系統開發服務頁了解完整服務範圍。