AI 客服機器人要不要導入？小型網站的成本、限制與替代方案評估

去年幫一個做手工皂的客戶看網站，他開口第一句是：「我想裝一個 AI 客服機器人，同業都裝了。」我問他，你上個月收到幾則客戶詢問？他打開後台算了一下，二十七則。其中十九則問的是同一件事——寄送要幾天到。

那次我們沒有裝機器人。我們花了兩個小時，把「出貨與運送」寫成一頁完整的說明，放進導覽列，並且在購物車頁面加了一行連結。下一個月的詢問掉到十一則，而他省下來的是每月一筆訂閱費、一次知識庫整理、以及往後每次改運費規則都要同步更新機器人的維運責任。

這篇不是要告訴你 AI 客服機器人不好用。它在對的規模、對的問題型態上非常有效。但它同時是一個被過度推銷的東西，而推銷的人不會告訴你：真正的成本不在訂閱費，答錯的責任會回到你身上，而且對多數每月諮詢量在三位數以下的小型網站來說，把 FAQ 寫好、把站內搜尋修好、把表單分流做對，投資報酬率明顯更高。這篇要給你的是一套可以自己跑一遍的評估框架，包含實際查證過的價目、真正的法律責任邊界，以及一條誠實的停損線。

先講結論：三個問題答完，你大概就知道要不要裝了

我把整篇濃縮成三個問題。如果你只有五分鐘，看完這一節就可以先離開。

第一，你每個月收到多少則客戶詢問？如果低於一百則，幾乎可以直接跳過機器人這個選項。理由不是「量太小不值得」，而是量太小的時候你根本無法判斷它有沒有用——三十則裡答錯兩則，你分不清是巧合還是系統性問題，也沒有足夠的對話紀錄可以拿去改善知識庫。沒有回饋迴路的自動化，只是把問題藏起來。

第二，你的問題集中還是分散？把過去三個月的詢問攤開分類，如果前五種問題涵蓋了七成以上的量，那你需要的是把這五題寫清楚，不是機器人。反過來，如果每一則問題都不太一樣、都要看客戶的訂單或帳號狀態才能回答，那機器人也幫不了你——它會變成一個很有禮貌的轉接台。真正適合機器人的甜蜜點在中間：問題有一定的重複性，但變化多到寫不成一頁 FAQ，而且答案全部可以從公開文件裡找到。

第三，答錯一題的代價是多少？如果你賣的是保健食品、金融商品、醫療或法律相關服務，或者你的商品規格會直接影響安全（電器、嬰幼兒用品、寵物食品），那答錯的代價不是客訴而是責任。這類產業要導入的話，能開放的範圍應該只有「查詢訂單狀態」「引導到正確的頁面」這種不做實質判斷的功能。

三題都通過，才進到後面談成本與做法。三題有一題不過，後面談的替代方案那一章對你比較有用。

三種東西常被混為一談，成本與失敗模式完全不同

市面上所有叫「AI 客服」的東西，技術上至少是三種完全不同的產品。它們的建置成本差十倍，出錯的方式也完全不一樣。搞混這三種，是我看過最常見的評估錯誤——很多人拿第三種的能力想像，去買第一種的價格，最後得到第二種的維運負擔。

第一種：規則式 FAQ 機器人（決策樹）

這是最老、也最被低估的一種。它本質上是一棵選單樹：使用者點「我要查訂單」，它給三個選項；點「運送問題」，它跳出一段預先寫好的文字。有些會做關鍵字比對，輸入「退貨」就跳到退貨那一支，但判斷邏輯仍然是你手寫的規則。

它的優點被嚴重低估：它永遠不會編造答案。每一句話都是你寫進去的，所以它說錯的唯一可能是你寫錯，而那是可以修的。對於答錯成本高的產業，這個特性的價值遠超過對話體驗上的粗糙。

它的失敗模式也很單純：使用者的問題不在你的樹上，於是他在三層選單裡繞不出去，最後放棄。這不是幻覺，是覆蓋率不足，症狀明顯、可量測、可補洞。

成本結構：多數即時通訊工具的免費或入門方案就包含這個功能，真正的成本是你花在設計選單樹的時間，大約半天到兩天。之後每次改政策要同步更新，但改的地方是固定的。

第二種：檢索式問答（RAG）

RAG 的全稱是 retrieval-augmented generation，中文常譯成「檢索增強生成」。運作方式是：先把你的說明文件、FAQ、商品頁切成小段存進向量資料庫，使用者提問時先去撈出最相關的幾段，再把那幾段連同問題一起丟給大型語言模型，請它「只根據這些段落回答」。

這是目前絕大多數商用「AI 客服機器人」實際採用的架構，包括你在各家定價頁上看到的那些 AI agent。它比規則式強在能處理沒被預想到的問法，也能把兩三個文件裡的資訊組合起來回答。

它的失敗模式比較隱蔽，而且有三種：檢索撈錯段落（問退貨，撈到換貨的條款）、撈對了但模型讀錯（把「訂購後三個工作天出貨」講成「三天到貨」）、以及撈不到卻硬答（這就是幻覺，模型會用訓練資料裡的通用知識填空，講出一套聽起來很合理但跟你家政策無關的說法）。第三種最危險，因為語氣自然、格式正確，看不出來是編的。

成本結構最容易被低估的也是這一種。訂閱費只是入場券，真正的工作量在「知識庫整理」——你的資料必須先變成乾淨、無矛盾、有明確時效的文件，機器人才可能答對。多數小型網站的說明文件是五年來陸續補的，裡面有三套互相矛盾的運費規則，兩個已經停用的優惠代碼，還有一段寫在圖片上的公告。這些東西 RAG 全都讀不出來或讀錯。

第三種：直接接通用大型語言模型

就是把使用者的問題原封不動丟給模型，不做檢索、不給文件，靠模型自己的知識回答。這種做法在客服場景幾乎沒有正當用途，但它出現的頻率遠比你想的高——通常是因為某個外掛安裝時預設就是這樣，或是知識庫還沒建好就先開起來測試，然後忘了關。

失敗模式只有一個，但很嚴重：它會用一般常識回答你家的專屬問題。問「你們可以七天鑑賞期退貨嗎」，它會給你一段從網路上學來的、大致正確的通論，而不是你網站上實際寫的條款。這種答案有時候剛好對，所以更難被發現。

如果你在評估任何工具，第一個要問廠商的問題就是：當知識庫裡找不到答案時，它的預設行為是什麼？正確答案是「說不知道並轉真人」。如果答案是「盡力回答」，那你買到的是第三種偽裝成第二種。

三種的對照

類型	答案來源	典型失敗	建置工作量	適合的情境
規則式 FAQ 機器人	你手寫的固定文字	覆蓋率不足，使用者繞不出選單	半天到兩天	問題高度集中；答錯成本高的產業
檢索式問答（RAG）	你的文件庫，經模型改寫	撈錯段落、讀錯語意、撈不到硬答	知識庫整理二到五天，之後持續維運	問題有重複性但問法多變；文件齊全且無矛盾
直接接通用模型	模型的訓練資料	用通論回答你家的專屬規則	接上去只要幾分鐘	客服場景幾乎沒有適用情境

看這張表的重點不是選哪一種，而是確認你正在評估的那個產品，實際上是哪一種。很多低價方案賣的是第一種加一層語言模型潤飾，行銷文案卻寫得像第二種。試用的時候問它一個「答案只存在於你網站某個角落」的問題，答案會誠實地告訴你它是哪一種。

什麼情況根本不該導入

這一章是整篇裡最不會有人跟你講的部分，所以我放在成本之前。因為如果你落在下面任何一種情況，後面的價格比較對你就沒有意義了。

情況一：每月諮詢量低於一百則

先算一筆帳。假設你每則詢問平均花四分鐘回覆，一個月三十則就是兩小時。以台灣接案者常見的自估時薪來算，這兩小時的機會成本大約落在一千到兩千元台幣之間。而一個入門的 AI 客服方案，依後面查證的定價，月繳普遍落在美金二十到七十元之間，換算後跟你自己回的成本差不多，甚至更高——而且你還要另外付出建置與維運的時間。

更關鍵的是回饋迴路。量小的時候，你沒辦法判斷機器人的表現。三十則對話裡答錯兩則，這是 6.7% 的錯誤率還是巧合？下個月改了知識庫之後降到一則，是改善還是隨機波動？沒有足夠的樣本，你就沒有辦法迭代，而 RAG 系統的品質完全來自迭代。裝一個永遠不會被改善的機器人，比不裝更糟，因為你會以為問題已經被處理掉了。

情況二：問題是長尾的，每一則都不一樣

如果你是接案的設計師、顧問、或做客製化服務，你的「客服問題」其實是需求討論，每一則都要看對方的專案脈絡才能回答。這種情況機器人能做的只有兩件事：問對方叫什麼名字，然後告訴你有人來訊。這兩件事表單也能做，而且不會製造「我以為我在跟能解決問題的東西對話」的錯覺。

判斷方法很簡單：把過去三個月的詢問抓出來，看前五種問題涵蓋多少比例。低於五成，就是長尾型，機器人的可解決率會非常難看。

情況三：答錯成本高的產業

有些領域答錯不只是體驗差。保健食品的功效敘述、金融商品的報酬與費用、醫療與診療相關的說明、法律與稅務的適用條件、以及會影響安全的商品規格（電器功率、嬰幼兒用品的年齡限制、寵物食品的成分禁忌），這些題目一旦被機器人自信地答錯，後果可能是行政裁罰或損害賠償，而不是一句道歉能結束的。

《消費者保護法》第 7 條第 1 項寫得很清楚：「從事設計、生產、製造商品或提供服務之企業經營者，於提供商品流通進入市場，或提供服務時，應確保該商品或服務，符合當時科技或專業水準可合理期待之安全性。」同條第 2 項要求「商品或服務具有危害消費者生命、身體、健康、財產之可能者，應於明顯處為警告標示及緊急處理危險之方法」，第 3 項則定有企業經營者的連帶賠償責任與過失減輕。（該法最新公布版為民國 104 年 6 月 17 日，全法規無未施行條文，查閱日 2026 年 8 月 2 日。）你的機器人在對話裡把安全警語講漏了，那個責任不會因為「是 AI 講的」而消失。

這類產業不是完全不能用，而是能開放的功能範圍要嚴格限縮在不做實質判斷的動作：查訂單、查營業時間、把人帶到正確的頁面、收集資訊後轉真人。只要是需要「解釋規則」或「給建議」的題目，就不該讓生成式的回答直接面對客戶。

情況四：你的說明文件本身還沒寫好

這是最普遍、也最諷刺的一種。RAG 機器人的答案品質上限就是你的文件品質，它不會無中生有把一份自相矛盾的說明整理清楚，只會把矛盾用流暢的中文說出來。

如果你現在的網站上，運費規則寫在三個地方而且金額不一致，或者最新的退換貨政策只存在於客服信箱的罐頭回覆裡，那麼整理文件這件事你無論如何都要做。做完之後你會發現，光是把整理好的文件放到網站上，詢問量就掉了一大截——這正是我開頭那個手工皂客戶的情況。整理文件是導入機器人的前置作業，而它本身往往就是解方。

真實成本結構：訂閱費只是入場券

以下所有價格都是我在 2026 年 8 月 2 日逐一打開官方定價頁確認的。這裡要先講一個評估時最常踩的陷阱：幾乎所有 SaaS 的定價頁預設都停在「年繳」，卡片上那個大字是年繳總額除以十二的均攤價，不是你按月付的價格。月繳通常貴 20% 到 30%。這件事在你只是試水溫、還不確定會不會用滿一年的時候特別重要。

訂閱費本身

下表是八個常被小型網站考慮的產品，全部標明月繳與年繳均攤的差別，每一列都連到我實際打開的那一頁。這些數字會變，做決定前請自己再開一次官方頁確認。

產品	計價單位	入門付費方案（月繳）	入門付費方案（年繳均攤）	免費方案
Tidio Starter（Lyro AI 另購）	整包，含 10 席、100 則計費對話／月	US$29／月	US$24.17／月（年繳＝2 個月免費）	有：50 則計費對話／月，另贈終身一次性 50 則 Lyro 對話
Tidio Lyro AI 加購	每則 AI 對話	US$39／月起（含 50 則）	US$32.50／月起（含 50 則）	無（僅上列一次性 50 則）
Intercom Essential（含 Fin）	每席	US$39／席／月	US$29／席／月（查閱日另掛新客 35% off＝US$19）	無，僅 14 天試用
Zendesk Support Team	每客服專員	US$25／人／月	US$19／人／月	無，僅試用
Zendesk Suite Team	每客服專員	US$69／人／月	US$55／人／月	無
Crisp Mini	每工作區，含 4 席	US$45／月	官網只說可在後台切換年繳，未公布折扣幅度	有：2 席，無 AI 額度
tawk.to ＋ AI Assist	每個網站（property），非每席	平台 US$0；AI Assist US$29／月	加購頁未列年繳選項	平台永久免費；AI Assist 另有未公布額度的免費層
Chatbase Hobby	每月 message credits（含 500）	US$40／月	US$32／月（年繳總額 US$384）	有：50 credits／月
Zoho SalesIQ Professional	每 operator	US$17／人／月	US$12.75／人／月	有：3 席，但不含 chatbot

幾個值得單獨指出來的細節。Chatbase 與 Tidio 的定價頁預設都停在年繳：Chatbase 卡片上的 US$32 是年繳均攤，月繳其實是 US$40，差 25%；Tidio 的 Lyro 加購卡片寫「Starts at $32.50/mo」，月繳則是 US$39 起。Zoho SalesIQ 的定價頁會依你所在地區自動切換幣別，看到數字前務必先確認幣別，不要把別國貨幣的數字當成美元。tawk.to 的定價資訊不在 /pricing（我查閱當天那個網址直接回 404），實際在加購項目頁。

還有一個容易被忽略的結構差異：Zoho SalesIQ 的 Answer Bot 是「自備金鑰」（BYOK／BYOAI）架構——官方在方案比較頁把它明白歸類在「THIRD-PARTY LLM (BYOAI)」這一段，內建 Zia LLM 的 Answer Bot 則只有 Enterprise 才有。也就是說你要自己去申請第三方模型的 API 金鑰接上去；至於那筆模型費用怎麼算，官網定價頁與比較頁都沒有寫，請以官網與該模型供應商的公告為準。這種結構在定價頁上通常只有一行小字，但它決定了你的實際支出是不是可預測的。

用量計費的三種單位，而且互相不能比較

這是我認為評估時最容易出事的地方。各家的用量單位定義完全不同，把數字直接拿來比大小是沒有意義的。

• Tidio 按「AI 對話則數」計：加購 Lyro 額度的官方級距是 50 則 US$39、200 則 US$140、300 則 US$210、1,000 則 US$700（月繳），所以 200 則以上正好是每則 US$0.70。定義上，只要 AI 客服代理在該次互動裡至少回覆過一次，就算一則；官方也寫明就算它回了十幾次，仍然只算一則。所以使用者問一句就走人，也計費。
• Intercom 按「成果（outcome）」計，每次 US$0.99。它的定義是：客戶確認問題已解決、或客戶在 Fin 回覆之後沒有再要求協助、或 Fin 完成了一個流程（包含轉真人）。官方明說同一則對話只計費一次，並且有每月最低承諾用量（官方舉的例子是 50 個 outcomes）。
• Zendesk 按「自動化解決（automated resolution，AR）」計。方案內含的額度是「每客服專員每月 5 到 15 個 AR」（Support Team 與 Suite Team 是 5，Enterprise 是 15），超出之後，事先承諾用量的價格是每次 US$1.50，隨用隨付是每次 US$2.00。但這裡有一個 2026 年 5 月 18 日才上路的重要變動：AR 現在分成三層，只有通過 LLM 覆核的 Verified resolution 才會扣額度；AI 只做了收資料、驗證身分、分流然後仍轉真人的（Assisted escalation），以及 AI 講完但沒通過覆核的（Contained resolution），官方明文寫「不計入你的額度」。這對後面的試算影響很大。
• Chatbase 按「message credits」計，加購是 US$40 買 1,000 credits，等於每 credit US$0.04。但官方 FAQ 寫得很明白：每次呼叫模型消耗的 credit 數依模型而異（文件裡列出 1 到 5 credits 不等），而且如果你啟用了 action，一次回覆可能打好幾次模型、扣好幾倍 credit。1 credit 不等於 1 則訊息，這句話務必記住。
• Crisp 的 AI 額度直接用美元標示，Mini 方案含 US$5、官方說明約當 90 則自動對話（換算下來每則約 US$0.056，這是我用它自己給的數字推算的，官方沒有明文寫單價）。對話總量本身不計費，是每個工作區的固定月費。

把這些放在一起就會發現：同樣是「三百則客戶詢問」，光是 AI 用量這一段在不同家的帳單上就可能是 US$210、US$119 或 US$590（下一節有算式）。差別不在誰比較貴，在於你被計費的那個事件是什麼。

用量計費會隨流量暴衝，這不是假設

做一個具體試算。假設你平常每月三百則客戶詢問，其中八成由機器人處理。

用 Tidio 的 Lyro 加購 300 則，月繳 US$210（再加 Starter 的 US$29 才是完整帳單）。用 Intercom，假設四成的對話符合 outcome 定義，就是 120 × US$0.99 ≈ US$119，加上至少一席 Essential 月繳 US$39，合計約 US$158。用 Zendesk Suite Team 一席月繳 US$69、內含 5 個 AR，在最壞情況下——其餘 295 則全部被判定為 Verified resolution 且採隨用隨付——那是 295 × US$2.00 = US$590，加上席位費約 US$659。

Zendesk 這條線要特別說明：依它 2026 年 5 月的新制，只有通過覆核的 Verified resolution 才扣額度，所以「295 則全計費」其實是理論上限而不是預期值，實際帳單會低於這個數字；但官網沒有公布各層級的分布比例，我不替它推估，你自己試算時請把它當成上限來看。

三個數字已經差三倍。真正的問題在下一段。

如果某個月你的一篇內容在社群上被大量轉發，詢問量從 300 變成 3,000，會發生什麼事？Tidio 那條線你需要升級到更高的額度級距，帳單大約變十倍（官方級距表到 1,000 則是 US$700，再上去要問業務）。Zendesk 那條線在隨用隨付模式下，上限就是 2,950 × US$2.00 = US$5,900，一個月。而這筆錢裡有相當比例是花在「路過的人隨口問一句就走」——那些人不會下單。

這件事的教訓不是「用量計費很邪惡」，而是導入前一定要確認三件事：有沒有用量上限或預算警示可以設？超額之後是自動升級還是停止服務？能不能限制機器人只在特定頁面（例如結帳頁、會員頁）出現，而不是全站每一頁都彈出來？第三點最有效——把機器人放在「已經有購買意圖的頁面」，可以把計費對話量壓掉一大半，同時提升每則對話的商業價值。這件事跟WooCommerce 的結帳流程設定要一起想，因為機器人擋在結帳頁前面反而會降低轉換的情況並不罕見。

自建 RAG 的 token 成本，比你想的低很多

如果你有能力自己接 API，成本結構會完全不同。以下是 2026 年 8 月 2 日OpenAI、Anthropic、Google 三家官方定價頁上的數字，單位是每一百萬 token。

模型	輸入（每百萬 token）	輸出（每百萬 token）	免費層
OpenAI gpt-5.6-luna（短脈絡、標準模式）	US$0.20	US$1.20	該頁未列出 API 免費額度
OpenAI gpt-5.6-sol（短脈絡、標準模式）	US$5.00	US$30.00	同上
Anthropic Claude Haiku 4.5	US$1.00	US$5.00	該頁未列 API 免費額度
Anthropic Claude Opus 5	US$5.00	US$25.00	同上
Google Gemini 3.1 Flash-Lite	US$0.25（文字／圖片／影片）；音訊 US$0.50	US$1.50（含 thinking token）	有免費層
Google Gemini 3.1 Pro Preview	US$2.00（提示 ≤ 200k token）；超過為 US$4.00	US$12.00；超過 200k 為 US$18.00	免費層不提供

拿前面那個「每月三百則對話」來算。RAG 的一則對話大約會送進去八千個 token（提示詞加上檢索到的文件片段），產出四百個 token。三百則就是二百四十萬個輸入 token、十二萬個輸出 token。

用 Gemini 3.1 Flash-Lite：2.4 × US$0.25 + 0.12 × US$1.50 = US$0.78。用 Claude Haiku 4.5：2.4 × US$1 + 0.12 × US$5 = US$3.00。

不到一美元到三美元。跟前面那些每月一百到六百美元的訂閱方案比，差了兩個數量級。

這個對比要正確解讀。它不代表自建比較便宜——那些訂閱方案賣的是後台介面、對話紀錄管理、真人接手的工作流、多渠道整合、以及有人幫你維護。它真正說明的是：模型本身的計算成本已經便宜到幾乎不影響決策，你付的錢絕大部分是在買軟體與省下自己的工。所以評估時該問的不是「哪家 token 比較便宜」，而是「這筆訂閱費省下我多少小時，那些小時值多少錢」。

兩個技術細節值得順帶記下來，因為它們會顯著改變試算結果。第一，Anthropic 的定價文件寫明「A cache hit costs 10% of the standard input price」，也就是快取命中只要標準輸入價的 10%，而 RAG 的系統提示詞與常用文件片段幾乎每次都一樣，善用快取可以把輸入成本壓掉一大截。第二，同一份文件在不同世代的模型上會被切成不同數量的 token——同一份文件寫明較新的模型使用新版分詞器，「produces approximately 30% more tokens for the same text」，同一段文字大約會多產生三成的 token。所以「同樣的單價」不等於「同樣的帳單」。

訂閱費之外的四筆成本，加起來通常比訂閱費高

一、知識庫整理。把散落各處的說明整理成無矛盾、有時效標記的文件。以一般電商或服務型網站的規模，抓兩到五個工作天是合理的。這一筆是一次性的，但如果你的文件現況很亂，它可能比第一年的訂閱費還貴。

二、對話設計。決定機器人在什麼情況下說「我不知道」、什麼情況轉真人、開場白怎麼寫、要不要主動彈出、彈出的時機。這件事沒做，機器人就會用預設的行為對待你的客戶，而預設行為幾乎一定是「盡量回答」。抓一到兩天。

三、持續維運。這是最容易被漏掉的一筆。每次你改運費、改優惠、上新品、改退貨規則，都必須同步更新知識庫，否則機器人會用舊資料回答，而且它會講得非常有自信。實務上建議把「更新機器人知識庫」寫進你改政策的固定流程裡，就像改價格要同步改商品頁一樣。每月抓一到兩小時。

四、對話紀錄的檢閱。每週花二十分鐘讀二十則對話，是這整套系統唯一的品質控制手段。不讀的話，你永遠不會知道它在什麼題目上一直答錯。這一筆是持續的，而且不能外包給機器人自己。

把四筆加起來，第一年的真實成本大約是訂閱費的兩到三倍。如果你算完之後覺得「那我不如自己回」，那個結論很可能是對的。順帶一提，如果你的網站已經裝了一堆外掛，多加一個對話工具還會影響載入速度——第三方對話視窗通常會拉進額外的腳本與字型，這件事在Core Web Vitals 的實測與修正那篇有量測方法，也可以對照把外掛精簡到 11 支的取捨過程來判斷值不值得多留一個。

幻覺與錯誤回答：責任到底歸誰

這一章是準法律議題，我盡量只寫可以查證的東西。以下引用的法條都經過現行有效版本的確認，但這仍然是一般性的資訊整理，不構成個案的法律意見；真的遇到爭議請洽律師或主管機關。

先看廠商的條款怎麼寫

先講一個事實：所有模型供應商的條款都明白地把輸出正確性的責任推給你。這不是隱藏在附件裡的小字，是寫在最顯眼的地方。

OpenAI 的使用條款（台灣讀者適用的是 rest-of-world 版）在「Accuracy」段落寫著：「Output may not always be accurate. You should not rely on Output from our Services as a sole source of truth or factual information, or as a substitute for professional advice.」下一句還要求「You must evaluate Output for accuracy and appropriateness for your use case, including using human review as appropriate, before using or sharing Output from the Services.」——使用或分享輸出之前，你要自己評估，必要時要人工審查。

要注意的是，那份使用條款適用的是消費端服務；如果你是透過 API 自建，適用的是 OpenAI Services Agreement（我查閱時的版本更新日為 2025 年 12 月 1 日、2026 年 1 月 1 日生效），其中第 4.3 條寫得更直白：「Customer is solely responsible for all use of the Outputs and for evaluating the accuracy and appropriateness of Output for Customer’s use case.」——輸出怎麼用、準不準，全部是客戶自己的責任。

Anthropic 的商業條款同樣寫明：「Customer acknowledges, and must notify its Users, that factual assertions in Outputs should not be relied upon without independently checking their accuracy, as they may be false, incomplete, misleading or not reflective of recent events or information.」注意它還加了一句「must notify its Users」——你有義務告訴你的使用者這件事。

兩家的責任上限條款也都限縮到你過去十二個月付給他們的金額：OpenAI 第 14.2 條寫「EACH PARTY’S TOTAL LIABILITY UNDER THE AGREEMENT WILL NOT EXCEED THE TOTAL AMOUNT CUSTOMER PAID TO OPENAI DURING THE TWELVE MONTHS IMMEDIATELY PRIOR TO THE EVENT GIVING RISE TO LIABILITY」，Anthropic 也限縮在「Fees paid by Customer for the Services in the previous 12 months」。換句話說，如果你的機器人講錯話害你賠了客戶十萬元，你能從模型供應商那裡拿回來的，最多就是你這一年付給他們的訂閱費。

順帶說明一件查證上的事：openai.com 的條款頁對自動抓取一律回 403，我是用一般瀏覽器打開讀的，上面兩段引文與條號都經過逐字比對。你自己點連結時可以正常看到內容。

一個真實的案例：加拿大的 Moffatt v. Air Canada

這是目前討論度最高、也最容易被誤引的一個案子，所以我直接引裁決原文。

2024 年 2 月 14 日，加拿大不列顛哥倫比亞省民事解決法庭（Civil Resolution Tribunal）作成 Moffatt v. Air Canada, 2024 BCCRT 149（案號 SC-2023-005609，裁決人 Christopher C. Rivers）。事實是：Moffatt 的祖母過世，他上加拿大航空的網站訂機票，網站上的聊天機器人告訴他可以在搭機後追溯申請喪親優惠票價。他照做了，航空公司拒絕，理由是官網「Bereavement travel」頁面寫的是不能追溯申請。

加拿大航空的抗辯是：它不需要為聊天機器人提供的資訊負責。裁決書第 27 段對這個主張的回應值得逐字看：「In effect, Air Canada suggests the chatbot is a separate legal entity that is responsible for its own actions. This is a remarkable submission. While a chatbot has an interactive component, it is still just a part of Air Canada’s website. It should be obvious to Air Canada that it is responsible for all the information on its website. It makes no difference whether the information comes from a static page or a chatbot.」

第 28 段還處理了另一個常見抗辯——「正確資訊在網站別的地方找得到」。裁決指出，航空公司並未說明為什麼那個標題為「Bereavement travel」的網頁，天生就比它的聊天機器人更值得信賴，也沒有說明為什麼客戶必須拿網站某一部分的資訊去跟另一部分互相查證。

最後認定過失不實陳述成立。裁決主文命加拿大航空於 14 日內給付總計 812.02 加幣，內含損害賠償 650.88 元、判決前利息 36.14 元，以及 125 元的法庭規費。

這是加拿大的裁決，在台灣沒有拘束力，我引它是因為那段推理清晰地指出了問題核心：機器人不是一個獨立的法律主體，它就是你網站的一部分。你不會主張「我網站首頁上那句話不是我寫的所以我不負責」，機器人講的話也一樣。

台灣法怎麼看

台灣目前沒有針對 AI 客服錯誤回答的專門規定，但既有的法條已經足以處理絕大多數情境。

《消費者保護法》第 22 條（現行有效，最新公布版民國 104 年 6 月 17 日，全法規無未施行條文）規定：「企業經營者應確保廣告內容之真實，其對消費者所負之義務不得低於廣告之內容。企業經營者之商品或服務廣告內容，於契約成立後，應確實履行。」你的機器人在對話裡對商品規格、優惠條件、退換貨政策所做的陳述，性質上很接近對特定消費者所為的招徠說明，把它當成「不得低於」的下限來看待，是比較安全的自我要求。

《民法》第 224 條（現行有效；民法確有一條掛在未施行清單上，是民國 88 年增訂的第 166-1 條，與本條無關）：「債務人之代理人或使用人，關於債之履行有故意或過失時，債務人應與自己之故意或過失負同一責任。但當事人另有訂定者，不在此限。」這一條是理解「工具出錯算誰的」最直接的線索——你用來履行債務的手段出了問題，責任回到你身上。機器人不是「使用人」（它不是人），但這條背後的歸責邏輯是一樣的：你選擇用什麼工具面對客戶，工具的行為就是你的行為。

《民法》第 153 條第 1 項：「當事人互相表示意思一致者，無論其為明示或默示，契約即為成立。」如果你的機器人被設計成可以直接確認訂單、承諾折扣、答應改期，那它做的就是意思表示。這是為什麼我強烈建議：不要讓機器人擁有「做出承諾」的權限。查詢可以，引導可以，做決定要交給人。

兩件今年新增的規範，要知道但不必恐慌

第一件事情剛好就發生在今天。歐盟《人工智慧法》（Regulation (EU) 2024/1689）第 50 條的透明度義務自 2026 年 8 月 2 日起適用。第 50 條第 1 項原文是：「Providers shall ensure that AI systems intended to interact directly with natural persons are designed and developed in such a way that the natural persons concerned are informed that they are interacting with an AI system, unless this is obvious from the point of view of a natural person who is reasonably well-informed, observant and circumspect, taking into account the circumstances and the context of use.」

白話說：使用者必須知道自己在跟 AI 講話，除非那已經明顯到不需要說。今年歐盟通過的數位法規簡化包（Digital Omnibus）延後了高風險 AI 的部分期限，但沒有動到第 50 條——依該法第 113 條，被排除在 2026 年 8 月 2 日之外的只有第一章與第二章（2025 年 2 月 2 日起）、第三章第四節與第五、七、十二章及第 78 條（2025 年 8 月 2 日起），以及第 6 條第 1 項（2027 年 8 月 2 日起），第 50 條所在的第四章不在其中。至於「合成內容標記（第 50 條第 2 項）對已上市系統另有緩衝期」的說法，目前我看到的都是各家法律事務所的解讀，還沒查到刊登在官方公報上的條文，如果你有歐盟客戶，這一點請以公報版本為準。

台灣的小型網站會不會被適用？要看你的服務是否觸及歐盟境內的使用者。多數只做台灣市場的網站不會，但如果你有歐洲客戶，這件事值得確認。而且老實說，就算法規沒管到你，把「這是 AI 助理」寫在對話視窗開頭，本來就是應該做的事——隱瞞這件事在使用者發現時造成的信任損失，遠大於誠實標示帶來的那點體驗折損。

第二件是台灣自己的《人工智慧基本法》，總統民國 115 年 1 月 14 日令制定公布全文 20 條，第 20 條規定自公布之日起施行，所以它已經生效了。但要把性質講清楚：這是一部基本法，多數條文的規範對象是政府機關，不是直接課予一般業者義務。第 4 條列的七項原則（永續發展與福祉、人類自主、隱私保護與資料治理、資安與安全、透明與可解釋、公平與不歧視、問責）是「政府推動人工智慧之研發與應用」時應遵循的原則；其中第五款寫「人工智慧之產出應做適當資訊揭露或標記」，這是政策方向，不是可以直接拿來罰你的條文。

第 18 條要求政府檢討所主管之法規與行政措施，並在本法施行後二年內完成法規的制（訂）定、修正或廢止。也就是說，真正會影響你的細部規範還在路上。現在該做的不是恐慌，而是把揭露與人工把關這兩件事先做起來，等細則出來的時候不必回頭大改。

把責任風險降到可接受範圍的五個具體做法

1. 在對話開頭明確標示這是 AI 助理，並說明它可能出錯、正式資訊以網站頁面為準。這一句話同時處理了揭露義務與期待管理。
2. 凡是涉及金額、期限、資格條件的回答，一律附上來源頁面的連結。這樣客戶會去看原始頁面，而你也在對話紀錄裡留下了「我有指向正確來源」的證據。
3. 不給機器人做承諾的權限。折扣、退款、改期、例外處理，全部轉真人。
4. 建立不確定就轉真人的預設行為，並且在導入前實際測試：問一個知識庫裡沒有的問題，看它是說不知道還是硬掰。
5. 保存完整對話紀錄。萬一有爭議，紀錄是你唯一能還原事實的東西。同時記得，對話紀錄本身就是個人資料，保存有保存的責任，這是下一章的主題。

資料隱私與個資：對話內容送到哪裡去了

裝一個第三方對話工具，等於在你的網站上開了一條管道，把使用者輸入的東西送到別人的伺服器。這件事在法律上不是中性的。

一段客服對話裡會出現什麼

實際看過對話紀錄的人都知道，客戶為了讓你查得到，什麼都會講：姓名、電話、Email、訂單編號、收件地址、有時候還會直接把整張出貨明細截圖貼上來。退換貨的對話裡會出現「這個是要送給我媽的」「我住的地方沒有電梯」；醫美或健康相關的網站，對話裡出現健康狀況的機率非常高。

《個人資料保護法》第 2 條把個人資料定義得很寬，包含姓名、聯絡方式、財務情況、社會活動及其他得以直接或間接方式識別該個人之資料。你的對話紀錄幾乎不可能完全不含個資。

更需要注意的是第 6 條第 1 項（現行有效，不在未施行修正清單內）：「有關病歷、醫療、基因、性生活、健康檢查及犯罪前科之個人資料，不得蒐集、處理或利用」，只有該項但書所列的六種情形才例外。如果你的產業性質會讓客戶在對話裡談到健康狀況，那你就必須認真面對這一條——而一個開放式的對話框，正是最容易誘使客戶說出這類資訊的介面。這是選擇「結構化表單」而非「自由對話」的一個很實際的理由。

告知義務：第 8 條要你講清楚六件事

這是導入對話工具時最常被漏掉的一步。《個人資料保護法》第 8 條（現行有效，不在未施行修正清單內）規定，公務機關或非公務機關依第 15 條或第 19 條規定向當事人蒐集個人資料時，應明確告知下列事項：一、公務機關或非公務機關名稱。二、蒐集之目的。三、個人資料之類別。四、個人資料利用之期間、地區、對象及方式。五、當事人依第 3 條規定得行使之權利及方式。六、當事人得自由選擇提供個人資料時，不提供將對其權益之影響。同條第 2 項另列了六種得免告知的情形（例如依法律規定得免告知、當事人明知應告知之內容等），但一般商業網站的客服對話幾乎都不會落在那六款裡，別拿它當免告知的理由。

注意第四款裡的「地區」與「對象」。如果你的對話工具把內容送到境外的伺服器、再轉給另一家模型供應商處理，那個「地區」與「對象」就跟你原本的隱私權政策不一樣了。裝上機器人之後，隱私權政策要跟著改，這是實質的義務，不是形式。

第 3 條（現行有效）則列出當事人的五項權利，並明文規定「不得預先拋棄或以特約限制之」：查詢或請求閱覽、請求製給複製本、請求補充或更正、請求停止蒐集處理或利用、請求刪除。所以如果有客戶要求你刪掉他的對話紀錄，你不能用服務條款擋掉——而且你要確認你真的刪得掉，包含存在第三方廠商那裡的副本。導入前就該問廠商：資料保存多久？我能不能單筆刪除？刪除會不會連帶影響已經生成的索引？

蒐集與利用的界線：第 19 條與第 20 條

第 19 條第 1 項規定非公務機關對個人資料之蒐集或處理，除第 6 條第 1 項所規定資料外，應有特定目的，並符合八款情形之一。對客服場景最常適用的是第二款「與當事人有契約或類似契約之關係，且已採取適當之安全措施」，以及第五款「經當事人同意」。注意第二款附帶了「且已採取適當之安全措施」這個條件，不是無條件成立。

第 20 條第 1 項規定非公務機關對個人資料之利用，除第 6 條第 1 項所規定資料外，應於蒐集之特定目的必要範圍內為之（該項但書另列七款得為目的外利用的情形）。這一條在客服機器人的情境裡有一個很具體的意義：客戶為了問運費而留下的 Email，不自動包含「加入你的行銷名單」這個用途。很多對話工具會很自然地把蒐集到的聯絡方式同步到行銷工具裡，這個動作在法律上是目的外利用，需要另外的合法基礎。第 20 條第 2 項與第 3 項還要求：當事人表示拒絕接受行銷時應即停止，首次行銷時應提供拒絕的方式並支付所需費用。要做電子報就走正規的訂閱流程，讓對方自己按下訂閱——這部分可以看訂閱名單的來源與退訂率控制那篇。

安全措施：第 27 條要看仔細

這一段容易寫錯，值得慢慢看。

如果你現在到全國法規資料庫查《個人資料保護法》第 27 條，頁面上會顯示「（刪除）」。但那是民國 114 年 11 月 11 日修正公布的版本，而該次修正的施行日期由行政院定之，法規資料庫同時標示「本法規部分或全部條文尚未生效，最後生效日期：未定」。截至本文查核日 2026 年 8 月 2 日，該次修正尚未施行，第 27 條仍然有效。要看現行有效條文，要點進民國 112 年 5 月 31 日的歷史版本，全文是：「非公務機關保有個人資料檔案者，應採行適當之安全措施，防止個人資料被竊取、竄改、毀損、滅失或洩漏。中央目的事業主管機關得指定非公務機關訂定個人資料檔案安全維護計畫或業務終止後個人資料處理方法。前項計畫及處理方法之標準等相關事項之辦法，由中央目的事業主管機關定之。」——後兩項也要一起看，因為它們是主管機關拿來訂行業辦法的授權依據。

那「適當之安全措施」是什麼？《個人資料保護法施行細則》第 12 條（該細則最新公布版為民國 105 年 3 月 2 日，全條文皆已生效）給了清單，包含配置管理之人員及相當資源、界定個人資料之範圍、風險評估及管理機制、事故之預防通報及應變機制、內部管理程序、資料安全管理及人員管理、認知宣導及教育訓練、設備安全管理、資料安全稽核機制、使用紀錄與軌跡資料及證據保存，以及整體持續改善。同條也寫明這些措施應「以與所欲達成之個人資料保護目的間，具有適當比例為原則」——一人經營的網站不需要做到企業級資安稽核，但也不能什麼都不做。

換算成小型網站可以實際執行的版本：對話工具的後台帳號一定要開兩步驟驗證、只給真正需要的人存取權、離職或合作結束時立刻撤銷、API 金鑰不要寫在前端程式碼裡也不要存在共用文件裡。金鑰與帳密的保管方式可以參考密碼管理器與帳密交接的做法，網站本身的登入防護則可以對照WordPress 網站安全的基本功。

萬一外洩：第 12 條的現行版本

第 12 條同樣落在未施行修正的清單裡，所以要引現行有效的版本（民國 112 年 5 月 31 日版）：「公務機關或非公務機關違反本法規定，致個人資料被竊取、洩漏、竄改或其他侵害者，應查明後以適當方式通知當事人。」動詞是「應」，不是「得」。

順帶說明，民國 114 年 11 月 11 日修正後的新版第 12 條大幅擴張了義務：知悉資料被竊取、竄改、毀損、滅失或洩漏時應通知當事人，符合一定通報範圍者還要向主管機關通報，並應採取即時有效之應變措施、記載相關事實與影響、保存紀錄以備查驗。那一版目前尚未施行，但它已經公布，方向很清楚。現在就把對話紀錄的存取控制與事故應變流程準備好，不會白做。另外要留意，個人資料保護委員會目前的官方名稱仍是「個人資料保護委員會籌備處」，這也顯示相關制度還在建置中。

你的對話會不會被拿去訓練模型

這是實務上最常被問、也最常被想當然耳答錯的一題。答案取決於你走哪一條路。

OpenAI 的開發者文件寫得很明確：「Your data is your data. As of March 1, 2023, data sent to the OpenAI API is not used to train or improve OpenAI models (unless you explicitly opt in to share data with us).」同一份文件也說明，濫用偵測的日誌預設會保留最多 30 天（原文是 up to 30 days，但要注意它逐一列出端點，少數端點寫的是「Until deleted」，不是一律 30 天）。Anthropic 的商業條款則寫「Anthropic may not train models on Customer Content from Services.」

但這裡有一個關鍵的差異值得單獨拉出來講：Google Gemini API 的定價頁上，每個模型都有一列標示資料是否「Used to improve our products」，免費層是「Yes」，付費層是「No」。我把該頁上所有模型逐列比對過，沒有例外。也就是說，用免費額度做客服機器人，在條款上等於把客戶的問題交給廠商改進產品。這對一個要處理客戶訂單與聯絡方式的系統來說，是必須寫進評估表的一行。

另外要提醒的是，如果你用的是打包好的 SaaS 對話工具，你面對的是那家工具商的條款，不是模型供應商的條款。工具商可能有自己的資料使用政策，也可能把你的資料再交給第三方。導入前要問清楚：資料存放在哪個地區？保留多久？有沒有簽資料處理協議的機制？這幾題問不出答案的廠商，就是答案本身。同樣的政策風險評估邏輯，在AI 寫作工具的定價與政策風險那篇也整理過一次，兩邊可以互相參照。

替代方案：這四件事通常比機器人划算

如果你走到這裡發現機器人的成本效益不成立，這一章是實際的替代路徑。這四件事我建議按順序做，因為後面每一項的效果都依賴前一項。

一、把 FAQ 真的寫好（而且用資料決定寫什麼）

大部分網站的 FAQ 頁是憑印象寫的，寫了八題，其中五題沒人問。正確的做法是用資料反推。

兩個資料來源。第一，把過去三到六個月的客戶詢問全部匯出來分類，數出前十名。這是最準的，因為它就是真實需求。第二，用 Google Search Console 看有哪些查詢字詞把人帶到你的網站上——搜尋字詞裡面藏著大量「使用者以為你會回答但你沒回答」的問題。Search Console 的查詢報表怎麼看那篇有操作步驟，這一步不用花錢。

寫法上有幾個直接影響效果的細節。每一題用完整問句當標題，而且用客戶會講的話，不要用內部術語（客戶問的是「什麼時候會到」，不是「配送時效政策」）。答案的第一句就要給答案，不要鋪陳；細節放後面。每題獨立成段，可以單獨被連結，這樣客服回覆時可以直接貼那一題的網址。

還有一個常被忽略的：把 FAQ 放在問題會發生的地方，不要只放在導覽列最右邊那個「常見問題」。運費問題放在購物車頁，退貨問題放在商品頁下方，尺寸問題放在選尺寸的旁邊。我開頭那個手工皂客戶的詢問量減半，主因就是這件事。

二、把站內搜尋修好

很多網站的站內搜尋是壞的——搜「運費」找不到那頁說明，因為那頁標題叫「配送須知」。使用者搜一次沒結果就不會再搜第二次，直接改用問的。

檢查方法很土但有效：把你 FAQ 的每一題，用客戶的講法在自己網站上搜一次，看第一筆結果對不對。搜不到的，就在那頁加上客戶會用的詞。這件事一小時之內做得完，而它處理的是「使用者原本可以自己解決但被系統擋住」的那一段流量——這一段流量在裝了機器人之後，會變成你付費的計費對話。

三、表單分流

如果你的問題是長尾型（每則都不一樣），最有效的工具不是對話框而是一張設計過的表單。理由是：表單能強迫收集你回答問題所必需的資訊，而對話框做不到——客戶在對話框裡只會說「請問我的訂單怎麼了」，你還是要再問一次訂單編號。

設計原則是先分類、再展開。第一個欄位是下拉選單「你要問的是：訂單／退換貨／商品規格／合作提案／其他」，選完之後才顯示對應的欄位（訂單問題要訂單編號，商品規格要品項）。這樣做有兩個好處：一是你收到的每一則詢問都是可以直接回答的；二是選項的分佈本身就是資料，三個月後你會清楚知道該優先寫哪一題 FAQ。

另外，表單在個資上比對話框安全得多。欄位是你定義的，你不會意外收到一段包含健康狀況的自由敘述。對照前面《個人資料保護法》第 6 條那一段，這個差別在某些產業是決定性的。

四、營業時間內的真人，加上明確的回覆承諾

這是最被低估的一項。多數人裝機器人的動機是「不想漏掉半夜的詢問」，但實際上客戶要的不是「立刻有人回」，而是「知道什麼時候會有人回」。

具體做法：在聯絡頁與表單送出後的畫面，明確寫出「我們的回覆時間是週一至週五 10:00–18:00，一般在一個工作天內回覆」。這一句話處理掉的焦慮，跟一個半夜回你但答不出來的機器人相比，效果往往更好，而成本是零。

如果你確實有大量非上班時間的詢問，中間還有一個選項：只在非營業時間顯示自動回覆，內容是「目前非服務時間，以下三個連結可能是你要找的」加上三個最常見問題的連結。這是規則式的做法，不會編造答案，也不用付用量費。

四種替代方案的取捨

做法	建置成本	持續成本	解決的問題類型	什麼時候會失效
寫好 FAQ 並放對位置	一到三天	改政策時同步更新	高度重複的問題	問題種類超過二十種時，使用者找不到
修好站內搜尋	約一小時	幾乎沒有	使用者知道自己要找什麼	使用者不知道該搜什麼詞
表單分流	半天	幾乎沒有	長尾、需要看個案資料的問題	客戶期待即時回覆時
營業時間真人＋回覆承諾	寫一段文字	你的工時	所有類型	量大到你回不完

看這張表的方式是：最後一欄才是你該不該導入機器人的真正判準。當你的問題種類多到 FAQ 頁裝不下、使用者不知道該搜什麼詞、而且量大到你回不完——這三件事同時成立的時候，機器人才是解方。只中一項，去修那一項就好。

如果真的要導入：最小可行做法與衡量指標

假設你評估完決定要做，這一章給你一條盡量不出事的路徑。核心原則只有一個：先證明它有用，再擴大範圍。

四週的最小導入流程

第一週：整理知識庫，但先不裝任何東西。把前十名問題的答案寫成十份獨立文件，每份標上「最後更新日」。過程中你一定會發現兩三處自相矛盾的政策，那些必須先在真實世界裡決定清楚。這一週結束時，把這十份文件直接發佈到網站上——這件事本身就有價值，而且是後面所有步驟的基礎。

第二週：只開規則式，不開生成式。用你選的工具做一棵最多兩層的選單樹，涵蓋前十名問題，每一支的終點是連到第一週寫好的那頁文件。同時設定好「其他問題」這一支，直接進表單或轉真人。這一週的目的是先驗證「使用者會不會用這個東西」，而不是「AI 答得準不準」。

第三週：開啟生成式回答，但範圍限縮。把知識庫接上去，並且做三件事：只在特定頁面顯示（例如商品頁與購物車頁，不要全站）、設定用量上限與預算警示、在對話開頭寫明這是 AI 助理且正式資訊以網站頁面為準。然後自己先跑三十題壓力測試，其中五題要故意問知識庫裡沒有的東西，確認它會說不知道。

第四週：讀對話紀錄，決定去留。把這一週所有對話讀完（如果量大就抽一百則），標記三種結果：答對、答錯、答不出來。這個比例就是你的決策依據。

三個必須看的指標，以及怎麼定義才不會騙自己

解決率。定義是：對話結束後，使用者沒有再從其他管道（表單、Email、電話）就同一件事聯絡你的比例。注意這個定義刻意避開了「使用者沒有再問」這種寬鬆算法——很多廠商的內建報表把「使用者關掉視窗」也算成解決，那個數字會漂亮到毫無參考價值。要算準，就要能把對話紀錄跟後續的客服信件對起來，這件事在導入初期人工比對一百則是可行的。

轉真人率。機器人主動判斷自己答不出來而轉給人的比例。這個數字不是越低越好，這一點非常反直覺。轉真人率過低（比如低於一成）通常代表它在硬答，而不是代表它很厲害。剛上線時我會希望看到三到五成之間，隨著知識庫改善逐步下降；如果一開始就是 5%，我第一個動作是去讀對話紀錄，而不是慶祝。

滿意度。對話結束後的一題式評分。收集率通常很低（一成上下是常態），所以不要拿它的絕對值當 KPI，要看趨勢，而且一定要保留一個文字欄位——那些文字比分數有用一百倍，它會直接告訴你哪一類問題讓人火大。

另外建議加一個大家很少追的指標：對話後的轉換率。跟機器人對話過的使用者，最後完成購買或送出表單的比例，跟沒對話過的比起來如何？如果對話過的人轉換率反而比較低，那你裝的東西正在扣分。這個要在分析工具裡設事件才追得到，GA4 的事件與轉換設定那篇有做法。

停損線要先寫下來

導入之前就把停損條件寫在紙上，否則三個月後你會為了「已經花了那麼多時間」而繼續留著它。我的建議是三條：

1. 三個月後解決率仍低於四成，且知識庫已經改過至少兩輪 → 關掉生成式，保留規則式選單。
2. 出現任何一次「機器人講的跟網站頁面不一致，導致客戶提出要求」的事件 → 立即限縮範圍，把該類問題改成純連結導引。
3. 每月總成本超過「你自己回覆這些詢問的機會成本」 → 這就是它在賠錢，數字不會騙人。

最後講一件與工具無關但更根本的事。客服品質的天花板從來不是回覆速度，而是你的商品說明、政策設計、以及交付流程本身有多清楚。如果你發現同一個問題每個月被問三十次，正確的反應不是把它自動化，而是去改那個造成問題的設計。最好的客服機器人，是一個不需要被問問題的網站。要動手改網站結構的話，五類網站建置工具的比較那篇可以幫你判斷現在的平台撐不撐得住。

常見問題

免費方案的 AI 客服夠用嗎？

看你的量與用途。Tidio 的免費方案給 50 則計費對話／月，另外贈送一次性的 50 則 Lyro AI 對話（官方寫的是 lifetime，終身一次，不是每月；要每月刷新得升級到 Lyro AI Agent 方案）；Chatbase 免費方案是每月 50 個 message credits，而且官方在方案卡上直接註明「AI agents get deleted after 14 days of inactivity on the free plan」；Zoho SalesIQ 的免費方案給 3 席但不含 chatbot；tawk.to 的平台本身永久免費，AI Assist 另有一個未公布額度的免費層。以上都是 2026 年 8 月 2 日查閱的。

誠實的答案是：免費方案適合拿來驗證「使用者會不會用」，不適合當長期方案。額度一定會撞牆，而撞牆的那個月通常就是你流量最好的那個月。另外要特別注意，Google Gemini API 的免費層在條款上會把資料用於改進產品，把它接到客服系統上要想清楚。

機器人講錯話，我可以用免責聲明擋掉責任嗎？

不能完全擋掉，但寫比不寫好。免責聲明的作用是管理期待與證明你有盡到告知，它不是免責盾牌。從加拿大 Moffatt v. Air Canada 那個裁決可以看到，法庭並不接受「正確資訊在網站別的地方」這種抗辯，也不接受把機器人當成獨立主體。台灣這邊，《消費者保護法》第 22 條要求企業經營者確保廣告內容真實、對消費者所負義務不得低於廣告內容，也不會因為一句免責聲明而消失。

真正有效的做法是結構性的：不給機器人做承諾的權限、涉及金額與條件的回答一律附上來源頁連結、不確定就轉真人。這三件事比任何免責文字都有用。以上為一般性資訊整理，個案請諮詢律師。

我是一人經營的小網站，個資法真的管得到我嗎？

管得到。《個人資料保護法》第 2 條第 8 款把「非公務機關」定義成「公務機關以外之自然人、法人或其他團體」，沒有規模門檻。你收到客戶的姓名與 Email 並存起來，這個動作在法律上就是蒐集與處理。

不過《個人資料保護法施行細則》第 12 條第 2 項寫明這些措施應「以與所欲達成之個人資料保護目的間，具有適當比例為原則」，所以一人網站不需要做企業級的資安稽核。實際要做的是：告知（隱私權政策要寫清楚資料會送到哪裡、給誰、留多久）、限縮（不要蒐集用不到的欄位）、保護（帳號兩步驟驗證、權限最小化）、以及能夠回應當事人的查詢與刪除請求。

ChatGPT 這類工具可以直接拿來當客服嗎？

技術上可以接，但那屬於本文說的「第三種」——如果沒有把你的文件接進去做檢索，它會用通用知識回答你家的專屬規則，而且語氣自然到你看不出來是編的。要當客服用，至少要走 RAG 架構，並且明確指示它只能根據提供的文件回答、找不到就說不知道。

另外提醒一個實務上的差別：消費端的使用條款與 API 的服務協議是兩份不同的文件，適用對象不同。你用 API 自建，適用的是後者，責任分配寫得更明確——輸出的正確性與適用性由客戶自行負責。

導入之後多久可以看出效果？

我的經驗是三個月，而且前一個月的數字幾乎沒有參考價值——那段期間的對話有一大半是你自己在測試、朋友在玩、以及使用者在試探這東西是什麼。真正可用的判斷要等到第二、第三個月的資料，而且中間至少要改過兩輪知識庫。

如果你需要在第一個月就給出結論，那個結論多半會是錯的。與其急著判斷，不如把第一個月拿來做前面說的那件事：讀對話紀錄。一百則對話讀完，你對「我的客戶到底在問什麼」的理解會超過任何一份報表。

資料來源

本文所有價格、條款原文與法條均引自以下官方頁面，查閱日期一律為 2026 年 8 月 2 日。定價與法規變動都快，做決定前請自行再開一次官方頁確認。

法規（全國法規資料庫）

• 《消費者保護法》：第 7 條、第 22 條（最新公布版民國 104 年 6 月 17 日，該法無未施行條文）
• 《民法》：第 153 條、第 224 條（該法唯一未施行的是民國 88 年增訂之第 166-1 條，兩條均不受影響）
• 《個人資料保護法》現行有效且不受未施行修正影響者：第 2 條、第 3 條、第 6 條、第 8 條、第 19 條、第 20 條
• 《個人資料保護法》第 12 條與第 27 條要特別注意：資料庫預設顯示的是民國 114 年 11 月 11 日修正公布版（第 12 條已改寫、第 27 條顯示「（刪除）」），該次修正施行日期由行政院定之、迄查閱日仍標示「最後生效日期：未定」。本文引用的是民國 112 年 5 月 31 日的現行有效版本
• 《個人資料保護法施行細則》第 12 條（母法為《個人資料保護法》；該細則最新公布版民國 105 年 3 月 2 日，全條文皆已生效）
• 《人工智慧基本法》：全文、第 4 條、第 18 條、第 20 條（民國 115 年 1 月 14 日制定公布全文 20 條，自公布之日起施行）
• 個人資料保護委員會籌備處（機關現行名稱）
• EUR-Lex：Regulation (EU) 2024/1689（歐盟人工智慧法）（第 50 條第 1 項原文、第 113 條的適用日期分層）
• Civil Resolution Tribunal：Moffatt v. Air Canada, 2024 BCCRT 149（第 27、28 段原文與給付主文；加拿大裁決，在台灣無拘束力）

對話工具定價

• Tidio 定價頁（Starter 月繳／年繳、席數與計費對話額度、Lyro 加購級距與「一則對話」的定義）
• Intercom 定價頁（Essential 席位費、Fin 每個 outcome US$0.99 與最低承諾用量）
• Zendesk 定價頁（Support／Suite Team 月繳與年繳、內含 AR 額度、超額 US$1.50／US$2.00；從台灣連 zendesk.com 會被導到這個網域）
• Zendesk 說明中心：About automated resolution tiers（2026 年 5 月 18 日起的三層制與哪些不扣額度）
• Crisp 定價頁（Mini 每工作區月費、含 4 席與 US$5 AI 額度約當 90 則自動對話、年繳說明）
• tawk.to 加購項目頁（AI Assist US$29／月、按 property 計、免費層）
• Chatbase 定價頁與模型 credit 對照文件（Hobby 月繳／年繳、免費層 14 天閒置刪除、US$40／1,000 credits、各模型每則扣 1 到 5 credits）
• Zoho SalesIQ 定價頁與方案比較頁（Professional 每 operator 月繳／年繳、免費層席數、Answer Bot 的 BYOK／BYOAI 歸類）

模型 API 定價與條款

• OpenAI API 定價（gpt-5.6-luna 與 gpt-5.6-sol 的短脈絡標準模式單價）
• OpenAI：Your data（API 資料不用於訓練、濫用偵測日誌保留期）
• OpenAI Terms of Use（rest-of-world 版）的 Accuracy 段落，以及 OpenAI Services Agreement 第 4.3 條與第 14.2 條（這兩頁對自動抓取回 403，我是以一般瀏覽器開啟後逐字比對）
• Anthropic：Pricing（Claude Haiku 4.5 與 Claude Opus 5 單價、快取命中為標準輸入價 10%、新版分詞器約多三成 token）
• Anthropic Commercial Terms of Service（輸出正確性須自行查核並告知使用者、不以客戶內容訓練模型、責任上限 12 個月）
• Google Gemini API 定價（Gemini 3.1 Flash-Lite 與 3.1 Pro Preview 單價與長脈絡分級、每個模型的「Used to improve our products」欄位）

兩點補充說明。第一，Intercom 在我查閱當天掛著「新客 35% off」的限時優惠，把 Essential 年繳價從 US$29 降到 US$19／席／月，那是促銷不是定價，所以表格裡我放的是原價。第二，Zoho SalesIQ 的 Answer Bot 走自備金鑰架構，但「第三方模型費用怎麼算」在它的定價頁與比較頁都查不到明文，我沒有替它推估數字，請以官網公告為準。