AI 導入為什麼上線後才出事？從五層架構看穩定安全的企業 AI 該如何設計

使用 AI 時，我們都是透過一個介面，例如 ChatGPT 的聊天視窗、Claude、聊天機器人、AI 應用程式等。很炫的應用程式往往有很出色的畫面，但公司和企業使用軟體時要的是穩定、安全和能夠解決真實的問題。另外，一個 AI 應用程式或 AI agent 與 demo 跑得起來，並且有一兩個使用者，和是否經的起上線面對夠多的真實用戶，並經的起跑幾個月到幾年，又完全是不同的事情。

對要導入 AI 的企業來說，它們不能只看介面和 AI 產生的結果，因為那些只是冰山在水面上的部分，真正關鍵的是水面下的大塊冰山，它才是讓企業 AI 應用程式長期經的起真實用戶檢驗的關鍵。

從以下實際案例就可以看出兩者的差異：

1. 一家做兒童房設計的公司，用 Airtable 加 Zapier 跑了六年營運流程。某天，兩個資料庫之間的連結悄悄停了，沒有錯誤訊息，也沒有任何通知。直到客戶來電才發現，而那件商品的製造交期是八週。（來源）

2. 官網表單顯示送出成功，郵件服務也回報「已送達」。問題是收件信箱屬於一位三個月前就離職的員工，三個月的詢問單沒有人看過。（來源）

3. 一套 n8n 流程每天早上抓取活動資訊，提供給電話客服 AI 使用。來源網頁改版後，抓回來的是空清單，流程照樣顯示執行成功。AI 拿著舊資料，連續好幾天告訴來電者已經結束的活動。（來源）

4. 一位沒有技術背景的創辦人，用 AI 做出的產品收到客戶的第一筆付費訂閱。金流成功、通知信發了，他順手打開資料庫檢查，才發現給客戶的報告是空的。（來源）

這些系統有一個共同點：你看得到的部分，都看不到問題。

為什麼一開始上線或是 demo 的時候沒發現？因為 demo 走的是理想情境測試（happy path testing）：資料格式正確、網路順暢、使用者照著設計好的步驟操作，但正式營運時不會這樣按表操課。上游系統改了欄位名稱、API 授權過期、同一個客戶重複付款、資料量一個月翻了十倍，這些邊緣案例（edge cases）在測試時很少出現，上線後卻每天都在發生。更麻煩的是，它們通常不會讓畫面當掉，只會讓結果悄悄變錯。

所以，要判斷一套 AI 系統能不能放心用，不能只看它的外表。你需要一張地圖，看見畫面底下還有什麼。

企業 AI 系統的五層架構

不管是雲端服務還是地端部署，是一條 n8n 自動化流程、一個 AI agent，給外部使用者使用的服務，或是企業內部用的工具，都可以拆成同樣的五層來檢視。

這五層像一座冰山，應用與介面層浮在水面上，是使用者、老闆，甚至開發者最常盯著看的部分。水面下的四層體積更大、要花的力氣更多，出事的機率也更高，但是非技術背景會 vibe coding 的人不太會主動去看。

越往下越是地基。治理與安全放在最底層，不是因為它最不重要，而是上面每一層能被信任到什麼程度，很大程度是由它決定。

層與層之間也不是各自獨立，下層的問題常常要到上層才看得見。接下來先逐層說明：每一層包含什麼、常見的出事方式，以及設計與檢查的重點。

第一層：應用與介面層（Application / UI/UX）

應用與介面層是使用者直接接觸的部分：網頁、App、聊天視窗、表單、按鈕、通知信、儀表板，以及操作流程的設計。

它是最好掌握的一層，因為看得見、摸得到，不懂技術的老闆也能判斷順不順、清不清楚，現在的 vibe coding 工具和 no-code 平台最擅長的也正是這一層。但它也最會迷惑人：介面負責的只是顯示，背後的邏輯怎麼運作完全看不到。介面越精緻，越容易把看起來能用當成真的能用。另外，出現在網頁上的資訊，一般人只看到瀏覽器呈現的部分，懂技術的人若打開開發者模式，就能輕易拿到不該外流的機密資訊。

常見的坑與潛在損失：

• 資料儲存錯誤：快速打造出網頁功能，實際上需要儲存的資料沒有正確寫入，或者只暫存在瀏覽器，一重新整理就遺失。
• 錯誤被隱形：程式邏輯跑到一半出錯，但使用者和管理者都看不到任何錯誤訊息。
• 盲目信任 AI：使用者不知道 AI 的回答可能出錯，沒有確認就直接照著做而產生問題。
• 客戶個資外洩：前端網頁的公開程式碼暴露了客戶資料，或者讓人能從中撈取資料庫資訊，引發法律責任與賠償訴訟等損失。
• 機密金鑰外洩：網頁程式碼內藏有敏感的 API key，遭人盜用導致機密外洩或雲端帳單暴增。
• 結帳邏輯漏洞：付費流程表面正常、也沒有錯誤訊息，邏輯卻沒處理好，造成重複扣款，或付款後沒拿到商品，引發客訴與信譽損失。曾有開發者的結帳流程沒有先檢查客戶是否已有訂閱，就再建立一次付款，兩筆扣款都成功，系統也都回報正常（來源）。

設計與檢查重點：

• 成功訊息要等後端確認完成才顯示，失敗時要告訴使用者下一步怎麼做。
• 上線前以使用者的角度搞破壞驗收：輸入錯誤格式、中途斷網、重複送出時，畫面會怎麼反應。
• 重要的商業邏輯，例如價格、折扣、付款狀態，不能只在前端檢查，後端一定要再驗證一次，避免有人繞過網頁直接呼叫 API。
• 確保前端網頁程式碼不會洩漏其他客戶資訊或不能外流的 API key。

第二層：Agent 與模型層（AI Agent / Model）

從這一層開始就在水面以下了。這層負責思考與決定：用哪個模型、系統提示怎麼寫、AI 能呼叫哪些外部工具（Tool Calling、MCP、Skill 等）、什麼情況要停下來問人，以及多個 agent 之間怎麼分工。

傳統程式出錯通常會當掉或報錯；AI 出錯卻會照樣產出看起來合理的答案。例如加拿大航空的客服聊天機器人，告訴一位剛失去祖母的旅客，喪親優惠票價可以事後追溯申請，但公司的正式政策寫的是不能追溯，連機器人自己附上的連結頁面都這麼寫。航空公司在仲裁中辯稱聊天機器人應該為自己說的話負責，這個說法被駁回，2024 年被判賠償旅客差價（來源）。企業不能把 AI 的錯推給 AI。

常見的坑與潛在損失：

• 憑空編造與幻覺：模型憑空編造內容，而且講得很有把握。若在醫療、心理健康或投資等高風險領域給錯建議，會造成實際傷害。例如美國飲食失調協會（NEDA）結束真人諮詢專線、改用聊天機器人 Tessa，結果 Tessa 對求助者提供減重與節食建議，正好是會加重病情的內容，最後被迫緊急下架（來源）。
• 惡意指令劫持（prompt injection）：惡意提示詞藏在 AI 會讀取的內容裡，讓 AI 洩漏機密或執行破壞性指令。例如微軟 365 Copilot 曾被發現重大漏洞：攻擊者只要寄出一封夾帶隱藏指令的信，員工之後請 Copilot 整理資料時，它就可能把公司內部資料送給攻擊者，全程不需要任何人點擊。微軟已修補此漏洞（來源）。
• 資訊缺漏仍硬答：參考資料缺漏或為空時，agent 不會警告，照樣回答，讓人分不清答案來自真實資料還是自行推論。
• 擅自繞過限制：agent 為了完成任務自行尋找替代方案，例如翻找其他金鑰或繞過限制，做出超出預期的行為。
• 模型行為改變：模型版本更新後行為悄悄改變，卻沒有人察覺。
• 無窮迴圈與成本暴增：多個 agent 互相交辦或不斷重試，卻沒有設定停止條件。有報導指出，一組由四個 agent 組成的市場研究流程，其中負責分析與負責驗證的兩個 agent 陷入互相來回的迴圈，連續跑了 11 天才被發現，累積約 4.7 萬美元的 API 帳單（來源）。
• 資源浪費與效能低落：使用昂貴模型高頻處理簡單問題，造成成本浪費；或流程太複雜、經過太多層 AI，等候時間過長，使用體驗不佳。

設計與檢查重點：

• 資料不足、遇到不確定或超出授權範圍時，要讓 agent 明確回報或停下來問人，而不是硬答或自行繞過。
• 根據需求情境和頻率使用不同的模型以節省成本：高頻簡單的任務可在地端使用開源模型，低頻複雜的任務可使用先進的閉源模型。
• AI 會讀取的外部內容（如表單、email、網頁）都要預設為不可信賴，先清理與檢查，並限制 AI 依據這些內容能採取的行動，避免惡意提示詞破壞系統或盜取資料。
• 使用 Langfuse 等 AI 監控工具，保留每次判斷所依據的資料與工具呼叫紀錄，出事時查得到原因，也能用來優化模型選擇與提示詞。
• 準備一組固定的測試問題，換模型或改提示之前先跑過一遍。

延伸閱讀：AI Agent 的風險邊界

第三層：資料與整合層（Data / Integration）

資料與整合層決定 AI 知道什麼，以及資料怎麼在系統之間流動。它包含企業自有資料怎麼交給 AI（系統提示、RAG、Text-to-SQL、知識圖譜等），也包含系統之間的串接：API、webhook、Zapier 或 n8n 流程、ERP 與電商平台的同步。

AI 再聰明也只能根據拿到的資料回答。資料過期、缺漏或格式不一致，AI 不會知道，只會照單全收。系統串接也一樣，上游改了設定，下游可能照樣接收空值，毫無警告。

常見的坑與潛在損失：

• 上游異動導致空值：上游平台改了欄位或格式，下游開始收到空值卻不會報錯。例如有人用 Zapier 把臉書廣告名單轉進 CRM，臉書改了一個欄位名稱後，Zapier 照樣接受空值，四天內 11 筆潛在交易就這樣被錯過（來源）。
• 假性執行成功：API 永遠回傳「200 成功」，真正的錯誤藏在回傳內容裡；或是金流通知（webhook）被快取外掛或防火牆攔截，金流平台收到成功回應就不再重送，客戶已經被扣款，訂單卻一直卡在待付款，直到客戶來信詢問才發現（來源）。
• 同步中斷無人發現：授權過期或串接中斷，流程看起來還在跑，其實早就沒有資料進來。曾有廣告代理商的廣告照樣花錢、客戶照樣填表，自動化流程卻將近兩週零執行；零執行在畫面上看起來只像「最近比較安靜」，所以沒有人起疑。事後平台回補遺漏的名單，已經人工補登過的客戶 CRM 又湧入大量重複資料（來源）。
• 引用過期文件：AI 引用了過期或互相矛盾的內部文件或 API 說明。
• 長期產出錯誤結果：一家管理上千個 Make 流程的代理商，自建檢查工具後才發現有 7 個流程好幾年來持續回傳錯誤結果，所有根據這些資料做的判斷都要重新檢視（來源）。

設計與檢查重點：

• 檢查輸出結果而不只是執行狀態：筆數是否合理、資料是否夠新、關鍵欄位是否為空。
• 定期對帳，例如收到的訂單數對上已轉給供應商的訂單數；有些可以讓 AI 檢查，有些由人工抽查。
• 每一份交給 AI 的原始資料，都要有負責人與更新頻率。
• 串接的第三方平台有異動時，要有人知道並重新驗證。

延伸閱讀：讓 AI 更懂你的業務：把自有資料交給 AI 的三大類型 13 種方式

第四層：基礎設施與維運層（Infrastructure / Operations）

基礎設施與維運層決定系統能不能穩定地一直跑下去。它包含主機環境、資料庫、備份與還原、監控警告、成本控管、部署流程，以及測試與品質保證（QA）。這層平常完全感覺不到，一出事就很嚴重。

常見的坑與潛在損失：

• 備份無效：備份沒跑、沒有異地備份，或從未實際還原過。一家小診所直到伺服器掛掉那天，才發現前一家 IT 廠商說有做的本地備份從來沒跑過，最後損失約三個月的病歷資料（來源）。
• 監控盲點：監控只看有沒有執行失敗，排程根本沒觸發時，不會有任何警告。平台額度也是盲點：Airtable 的月度執行額度用完後，整個工作區的自動化會同時暫停，而額度警告信只寄給工作區擁有者，實際負責營運的人完全不知情（來源）。
• 缺乏整合測試：只測單一功能，沒有驗證從使用者操作到資料寫入的完整流程。開場提到那位創辦人的產品，經過好幾週測試和親友試用都沒出問題，但沒有一個測試從頭到尾驗證「付款之後，報告真的產生了」，結果第一位付費客戶就收到空白報告。
• 直接修改正式環境：沒有測試環境，直接在正式環境修改或升級。有人升級自架的 n8n 時下錯一行指令，連同正式流程和資料庫一起刪除，才發現備份已經靜默失敗兩三週，兩週的自動化成果只救回約四分之一（來源）。
• 費用未設上限：API 與雲端用量沒有設上限和預算警告。一家新創測試時程式陷入無限遞迴，雲端服務依預設自動擴充到上千台機器，24 小時內產生約 7.2 萬美元帳單，公司差點破產（來源）。

設計與檢查重點：

• 定期做還原演練，確認備份真的救得回來。
• 系統錯誤要主動通知管理者，不能只寫進沒人看的紀錄。
• 監控結果而不只是過程：系統安靜太久、沒有新資料進來，也應該觸發警告。
• 建立整合測試與端到端測試，涵蓋錯誤情境與邊緣案例（edge cases）。
• 透過 CI/CD 部署流程上線：每次部署前自動跑測試，先在測試環境驗證，出問題能快速退回上一版（rollback）。
• 為 API 用量與雲端費用設定上限與預算警告。

第五層：治理與安全層（Governance / Security）

治理與安全層決定公司管不管得住這套系統。它包含權限設計、資料存取控制、哪些動作需要人工核准、操作紀錄與稽核、資安防護，以及出事時誰負責。它放在最底層，是因為它是地基。上面四層做得再好，治理沒做好，就像把一台馬力很大的車交給沒有煞車的駕駛。

常見的坑與潛在損失：

• 賦予不可逆權限：AI 擁有刪除資料、對外付款等權限。2025 年，SaaStr 創辦人 Jason Lemkin 在明確宣告程式凍結的期間，Replit 的 AI agent 仍刪掉了正式環境的資料庫，接著還產生假資料、謊稱測試通過。他說自己用全大寫提醒了十一次。問題不在提醒得不夠用力，而在 AI 根本有權限執行刪除，也沒有任何機制擋下來（來源）。
• 存取規則漏洞：權限規則看似完整卻有漏洞。有創辦人用 AI 工具三天做出產品，資料庫的存取規則（RLS）明明開著，卻被一個資料表檢視（view）繞過，上線不到 24 小時就被入侵。畫面一切正常，是外部資安研究人員發現後通知他的（來源）。
• 缺乏存取控制與使用限制：只檢查使用者有沒有登入，沒檢查「這筆資料是不是你的」，也沒有限制使用量。一位非技術背景的創辦人用 AI 寫出 SaaS 產品，公開分享後立刻被攻擊：有人繞過付費訂閱、耗盡 API 額度、在資料庫任意寫入，產品一週內就被迫關站（來源）。
• 毀滅性的權限金鑰：金鑰權限開得太大、用完沒有收回，也沒有定期更換。一把一年前為了「新增與移除自訂網址」這種小事建立的 API 金鑰，主機平台卻給了包含刪除在內的完整權限，用完後一直留在工作機器的檔案裡。AI 寫程式助理在測試環境遇到密碼不符的問題，自行找到這把金鑰並刪除磁碟，9 秒內抹掉正式客戶資料，以及放在同一個磁碟裡的備份。這家公司的客戶是租車業者，隔天顧客到櫃檯取車時查不到任何紀錄，三個月的預約全部消失（來源）。
• 缺乏操作稽核紀錄：沒有操作紀錄，出事後完全查不出誰在什麼時候做了什麼。
• 缺乏 AI 使用規範與機密保護：員工把機密貼進外部 AI 服務。2023 年三星工程師把內部原始碼貼進 ChatGPT，資料一旦傳到外部伺服器就難以取回或刪除，三星隨後全面禁止員工使用生成式 AI 工具（來源）。
• 資料保存與儲存權限失控：該刪的資料沒刪、該鎖的儲存空間沒鎖。女性約會安全 App「Tea」宣稱身分驗證照片審核後即刪除，實際上卻存放在公開可讀取的雲端儲存空間，約 7.2 萬張照片外洩，其中包含約 1.3 萬張自拍與駕照等證件照，後續又發現上百萬則私訊外洩（來源）。

設計與檢查重點：

• 最小權限原則：每個人、每個 agent 只拿到完成工作所需的權限。
• 刪除、付款、對外發送等不可逆動作，一律經過人工核准。
• AI 開發工具不得持有正式環境的權限或金鑰。
• 保留完整的操作紀錄，並定期檢查權限設定。
• 上線前做資安檢查，不只看設定有沒有開，也要實際測試擋不擋得住。

延伸閱讀：企業主必須理解的 AI 治理

症狀在上層，根因在下層：跨層診斷

問題浮現的那一層，通常不是問題發生的那一層。

看醫生的經驗大家都有。頭痛不一定是頭的問題，可能是頸椎、睡眠，或是血壓；腳痛也不一定是腳的問題，坐骨神經痛的根源在腰椎，痛卻一路傳到腿上。如果只對著痛的地方擦藥，症狀會暫時緩解，病卻還在。

AI 系統也是這樣。使用者能感受到的，幾乎都是應用與介面層的症狀：答案怪怪的、訂單沒出現、通知沒收到。但真正的病因，往往在下面好幾層。

以前面提到的電話客服 AI 為例，一路往下追：

1. 應用與介面層：來電者聽到已經結束的活動。這是症狀。
2. Agent 與模型層：AI 拿不到新資料，沒有示警，直接用舊資料回答。
3. 資料與整合層：來源網頁改版，爬蟲抓回空清單，卻照樣回報成功。
4. 基礎設施與維運層：監控只看流程有沒有執行，不檢查輸出筆數和資料日期。

如果只在第一層修，例如調整 AI 的回答語氣，或是請客服人員多留意，問題下次還會再來。真正該補的是第三、四層：檢查抓回來的資料是否為空、是否夠新，不對就停下來並通知人。

你看到的症狀	常見的根因所在
AI 的回答越來越空泛或過時	資料與整合層：資料斷流或過期
客戶說訂單或詢問沒有下文	資料與整合層、基礎設施與維運層：串接靜默中斷、沒有對帳
AI 做了不該做的事	治理與安全層：權限過大、缺少人工核准
帳單突然暴增	Agent 與模型層、基礎設施與維運層：迴圈沒有停止條件、用量沒有上限
資料被陌生人讀取或竄改	治理與安全層：權限規則有漏洞

這也是為什麼「哪裡壞就修哪裡」在 AI 系統裡常常不管用。先判斷症狀和根因各在哪一層，才知道該從哪裡下手。

從一人公司、中小企業到大企業：五層 AI 架構缺一不可，深度隨規模調整

這五層不是大企業才需要的架構。一人公司、中小企業、大企業都有同樣的五層，差別在每一層要做多少事。

舉三個例子。一位自由接案的設計師，在一台專用電腦上跑 AI agent，幫他回覆客戶信件、整理報價與歸檔。一家三十人的貿易公司，用 Hermes 讀取報關文件與發票、對帳、產生出貨通知，並串接會計系統和 email。一家上千人的製造業，建立內部知識庫，讓各部門的 agent 查詢規格與標準作業流程，同時串接 ERP 與生產系統。

簡單來說，一人公司在每一層只需要做最基本的事，例如備份資料、設定 API 用量上限、用專用電腦隔離 AI；中小企業要開始處理系統串接、定期對帳與員工權限分級；大企業則需要多 agent 分工、跨系統資料治理、災難復原演練與專責資安團隊。規模越大，每一層的工作越多，但五層都不能少。

層級	一人公司	中小企業	大企業
應用與介面層	透過通訊軟體下指令、看結果	員工共用的內部工具、給客戶的表單	多部門入口、對外服務、多語系介面
Agent 與模型層	選定模型，決定哪些事要先讓自己過目	哪些任務交給 AI、哪些要主管核准，控制模型費用	多 agent 分工、模型評估與版本管理
資料與整合層	定期抽查 AI 整理的資料，例如每月對帳	串接會計、ERP、email，定期對帳	跨系統資料治理、知識庫權限分級
基礎設施與維運層	資料備份到另一個地方、設定 API 用量上限	測試環境、監控警告、指定維運負責人	高可用架構、CI/CD、災難復原演練
治理與安全層	用專用電腦隔離，敏感帳密不放在 AI 碰得到的地方	員工權限分級、AI 使用規範	稽核機制、法規遵循、專責資安團隊

規模小，每一層可能只需要一兩個動作；但跳過任何一層，那一層的問題不會因此不見，只是沒有人在看。深度也跟著風險走：同一位設計師，用 AI 發想社群貼文，看前兩層大概就夠了；用 AI 處理報價和收款，就值得把五層都走一遍。

地端與雲端 AI 部署比較：用五層架構逐層看差異

部署在雲端還是地端，改變的是每一層由誰負責、要做哪些事，不會讓任何一層消失。

簡單來說，雲端部署按用量付費、前期投入低，可以使用最新的閉源模型，硬體由供應商負責，但資料會傳到外部，費用也較難預估。地端部署讓資料留在公司內，但實務上以開源模型為主、前期硬體投資高，RAG 知識庫、系統串接、維運與資安都要自己建置和負責。兩種方式都不會自動變安全：雲端要理解共享責任模式，地端要自己做好防火牆與權限設定。

應用與介面層

比較項目	雲端	地端
介面開發	可自建 app 或聊天介面，也能直接採用現成的 SaaS 產品，例如內建在辦公軟體裡的 AI 助理	可自建 app 或聊天介面，架設在公司內部；沒有現成 SaaS 可以直接套用
客製彈性	SaaS 上線快，但功能和流程受限於供應商設計，供應商改版或調價時也得跟著調整	自建可以完全客製，但開發與維護都要自己來
外部存取	透過網路即可使用	員工若要從外部或手機使用，需另外規劃 VPN 等連線方式

Agent 與模型層

比較項目	雲端	地端
可用模型	閉源與開源模型都能用	實務上以開源模型為主，通常從 Hugging Face 等模型平台下載；閉源模型多半無法部署在地端，改呼叫雲端 API 的話資料就會離開公司
部署工具	透過雲端平台直接呼叫模型，不需要自行安裝部署工具	常見的有 Ollama，適合個人或小團隊在單機快速執行開源模型；以及 vLLM，適合多人同時使用的企業級部署
計費方式	閉源模型透過 API 按用量計費；開源模型可透過 AWS Bedrock、Google Vertex AI、Azure AI Foundry 等平台按用量計費，或租用雲端 GPU 自行部署	沒有用量費用，但能力受限於 GPU 規格
版本管理	可以隨時切換、比較不同模型；供應商可能調整或下架舊模型，行為改變時需要重新測試	模型選擇、版本更新、效能調校都要自己來

資料與整合層

比較項目	雲端	地端
資料位置與合規	資料會傳到外部，需確認供應商的資料保存與訓練政策、儲存地區；金融、醫療、政府、國防等受監管產業的合規考量特別多	資料儲存在公司內，較容易滿足儲存地點的要求；但備份放在哪裡、資料流經哪些平台，仍要規劃
RAG 知識庫	可使用代管的資料庫與檢索服務，維護負擔較輕	資料庫、索引、更新都要自己建置與維護，可選的工具較少，需要的人力較多
系統串接	與 CRM、雲端硬碟等雲端服務的串接較容易，常有現成的連接器	串接多半要自己開發與維護；若要接收外部服務的通知（webhook），需在防火牆開放對外連線

基礎設施與維運層

比較項目	雲端	地端
硬體	硬體與擴充由供應商負責，可依用量彈性調整	主機採購、電力與散熱全部自己負責
日常維運	仍要自己設定費用上限、監控用量	備份、監控、系統更新、硬體故障處理都要自己來，需要有人具備維運能力
中斷備案	要規劃供應商服務中斷或 API 限流時的備案，避免業務整個停擺	硬體故障時要有備援方案，避免業務整個停擺

治理與安全層

比較項目	雲端	地端
責任歸屬	共享責任模式：供應商負責保護平台本身，帳號、權限與資料的設定錯誤仍是自己的責任	資料外洩到第三方的風險較低；仍需做各種權限和防火牆設定才能確保安全性，公司自身維運責任較高
主要風險	雲端帳號一旦被盜，攻擊者從任何地方都能存取，需啟用多重驗證	從個人電腦到企業級主機，只要連上網路就是攻擊目標
必做事項	管好 API 金鑰、訂定員工使用規範，並確認合約是否符合個資與跨境傳輸規定	防火牆與網路設定、內部權限、存取紀錄、資安更新都要自己做

成本結構

比較項目	雲端	地端
前期投入	低：按用量付費，不用時可以隨時停止	高：需要先投資硬體
長期成本	費用隨使用量浮動、較難預估；用量大時，長期成本可能超過地端	除電費外，主要成本是維運人力成本；長期成本可能低於雲端

對考慮採購 AI 主機的企業來說，這張表有一個重點：買主機只解決了基礎設施與維運層的一部分。主機上要跑什麼模型、資料怎麼整理進去、員工透過什麼介面使用、權限怎麼控管、誰負責維護，這些問題不會因為主機到貨就自動有答案。實務上，很多企業最後會採用混合模式：敏感資料留在地端處理，一般任務交給雲端的模型。不論選哪一種，五層都要有人負責。

用五層架構閱讀本站文章

本站的很多文章，都會標註它討論的是哪一層的問題。

有些文章專談一層，例如資料串接的方法屬於資料與整合層，AI 權限邊界屬於治理與安全層。有些文章則是跨層的案例，會說明症狀出現在哪一層、根因又在哪一層。

讀者可以從自己最擔心的那一層開始讀，也可以拿這五層當成檢查清單，對照自己公司正在用的系統：每一層都有人負責嗎？每一層出事時，都會有人知道嗎？

結語：導入 AI，五層都要有人負責

做出一個能 demo 的 AI 應用，從來不是最難的部分。現在的工具讓這件事變得很快，快到讓人以為導入 AI 就是這麼簡單。

真正決定一套系統能不能放心交給它做事的，是水面下那四層。它們平常看不見，出事時卻最致命。導入 AI 之前，先問清楚每一層由誰負責；上線之後，也要確保每一層出問題時，你會第一個知道，而不是等客戶抱怨。