政府導入 AI 幕僚的資安、稽核與地端部署要求

政府機關評估 AI 幕僚時，功能展示往往不是最後的關卡——資安審查才是。資料會不會送到境外？誰能看到哪些內容？AI 的每次產出有沒有紀錄可查？系統能不能完全放在機關自己的機房？本文整理政府導入 AI 幕僚系統時的六大資安要求、稽核設計與地端部署選項，並提供可直接放進採購規格書的檢核清單。

先看框架：政府 AI 資安的規範地圖

機關導入 AI 幕僚要面對的不是單一法規，而是四層規範疊加：資通安全管理法所建立的機關資安責任等級與系統防護基準、個人資料保護法對個人資料蒐集與利用的界線、行政院針對公務機關使用生成式 AI 所發布的參考指引，以及政府採購與共同供應契約對供應鏈安全與廠商資格的要求。本文後續的六大要求，幾乎每一項都能對應回這四層當中的一層——採購規格書寫得出來的條款，多半不是廠商自訂的品質承諾，而是規範早已要求的事。

以下僅為一般性的框架說明，協助承辦人建立整體圖像。實際適用範圍、作業要求與應辦事項，仍應以主管機關最新公告、貴機關所屬的資安責任等級，以及機關資安人員與政風單位的認定為準。

這四層規範的共同精神其實只有兩個字：可控與可查。可控是指資料在哪裡、由誰處理、能被誰看見，機關都說得出來；可查是指事後有人問起，機關拿得出紀錄佐證。理解這一點之後，後面的六大要求就不會像是廠商推銷的功能清單，而是把可控與可查落實到系統設計的具體作法。

一、資料主權：資料不出境是底線

多數公有雲生成式 AI 服務的推論發生在境外機房，這對政府業務是根本性的障礙——公務資訊一旦進入境外服務，機關即失去對資料流向的控制。合規的 AI 幕僚系統應確保：資料主機與模型推論皆在台灣境內、供應商具備 ISO 27001 資訊安全管理認證、資料傳輸採 TLS 1.2 以上加密。採購規格書應明文要求「資料儲存與處理均不得離開台灣境內」。

規格書條款可寫成：本案所有資料之儲存、處理與模型推論均應於台灣境內完成，不得以任何形式傳輸至境外機房或境外 AI 服務，廠商並應於投標文件檢附機房所在地說明與 ISO 27001 認證文件；如涉及第三方元件或委外處理，須逐項列明處理者、處理地點與資料項目，異動時應事先報請機關同意。把這段話寫進規格，等於在投標階段就把不符合的方案篩掉，避免審查期才發現架構無法調整。

二、部署選項：雲端、私有雲與地端的選擇

依業務機敏程度，部署選項由低到高為：台灣境內雲端（適合以公開輿情為主的監測業務）、政府私有雲、以及完全地端部署（On-Premise）——系統與模型都在機關自有機房運行，連模型推論都不需對外連線。整合內部公文與機敏資料的 AI 幕僚，建議直接以地端為目標架構；外部輿情蒐集層可保留雲端，形成「外雲內地」的混合架構，兼顧資料涵蓋與安全邊界。

把外雲內地列為建議架構的理由很單純：外部輿情資料量大、來源變動頻繁，交由雲端蒐集與清洗最有效率，而這些資料本來就是公開的；內部公文與研判則完全沒有離開機關的必要。兩者以一道明確的邊界隔開，機關對外只需說明一件事——跨越邊界的是什麼資料、往哪個方向流動——這比起把所有東西都搬上雲或全部塞進地端，在審查時反而更容易說清楚。

地端模型怎麼選：台灣機關可用的開源選項

決定走地端之後，下一個問題是模型從哪裡來。台灣機關目前可實際列入評估的開源或開放權重模型主要有四類：TAIDE、Gemma 4 31B、GPT-OSS 與 Mistral 系列。選型判準不是排行榜分數，而是三件事——授權條款是否允許機關內部使用與客製、模型對繁體中文與公文語境的掌握程度，以及在單張或少量高階 GPU 上是否跑得動。多數機關的第一套地端系統受限於機房與預算，硬體可行性往往比模型能力更早成為決定因素。

有一條紅線必須先講清楚：中國開發的模型（例如 Qwen、DeepSeek）即使以地端方式部署、完全不對外連線，在台灣的政府機關與受規管企業仍不建議列入選項。原因有三——資料主權與模型來源國別的疑慮、政府採購對產品來源與供應鏈安全的限制，以及後續維護與權重更新管道同樣來自境外。實務上這類方案通常無法通過機關資安審查，與其在評選後段被退回，不如在選型第一輪就排除。

至於能力差距，地端開源模型與 GPT-5.6、Claude Fable 5、Gemini 3 這類最前沿的雲端模型確實仍有距離，但這個差距在公務場景可以用架構補足：把機關法規、歷年公文與會議紀錄建成知識庫，透過 RAG 架構讓模型每次作答都以檢索到的原文為依據，回答品質取決於知識庫整理得好不好，而非模型本身記得多少。換句話說，該投入的力氣在資料治理，不在追逐模型排行榜。台灣企業 LLM 選型指南 對各家模型的授權條件與硬體需求有更完整的比較，可作為選型會議的參考材料。

三、存取控制：誰能看到什麼、誰能問什麼

AI 幕僚匯集的資訊敏感度不一：公開輿情人人可看，質詢攻防資料限幕僚圈，涉及個案的內部研判只有特定層級可存取。系統應支援角色式存取控制（RBAC）——依職務層級與業務分工設定資料可見範圍與功能權限，搭配多因素驗證（MFA）。同一套系統中，首長、局處主管、承辦人看到的內容與可執行的查詢應該不同。

權限矩陣建議在需求訪談階段就畫出來，作為規格書附件。以常見的機關編制為例，可見範圍大致如下：

• 首長：全機關議題總覽、跨局處風險彙整、所有預警與研判報告
• 局處主管：本局處業務相關議題、所屬人員的交辦事項與進度
• 幕僚圈：質詢攻防資料、答詢草稿、跨局處議題脈絡，但不含個案敏感內容
• 承辦人：本人負責議題的原始資料與分析結果，可提出查詢但不可匯出全機關報表

四、使用紀錄：模型行為要留痕

生成式 AI 引入了新的稽核對象：模型本身的行為。合規系統應留存：誰在何時查詢了什麼、模型引用了哪些資料產出回應、預警與簡報發送給了誰。這些紀錄有兩個用途——資安事件的事後調查，以及回應「AI 是否被不當使用」的監督質疑。缺乏使用紀錄的 AI 系統，在政府環境等於稽核盲區。

規格書可將留存欄位逐項列出，避免廠商以系統本身有日誌一句話帶過。建議至少涵蓋：

• 查詢者：帳號、所屬單位與當時的角色權限
• 查詢時間：起訖時間戳記與來源網段
• 查詢內容：使用者輸入的提問或設定的監測條件
• 模型引用資料：本次回應檢索到的文件、段落或輿情來源清單
• 發送對象：預警與簡報的收件者、發送管道與發送時間

這些紀錄應設定保存期限與存取權限——能調閱紀錄的人本身也要留痕，否則稽核紀錄反而成為新的洩漏管道。

五、產出稽核：AI 寫的與人改的要分得開

對外新聞稿、答詢資料若經 AI 輔助產出，機關必須能回答「哪些是 AI 寫的、誰改過、誰核准的」。系統應保留完整版本軌跡：AI 產出版本、人工修改版本、修改者、核准者、引用資料與產出時間。這不只是稽核需求，也是保護承辦人的設計——出現爭議時能明確舉證人工把關確實發生。

完整的版本軌跡至少應包含下列欄位，並可依文件單獨匯出：

• AI 初始產出版本與產出時間
• 每一次人工修改的版本、修改者與修改時間
• 各版本之間的差異對照，可看出哪幾段被改寫
• 核准者、核准時間與核定的最終版本
• 本次產出所引用的資料來源清單

六、來源可追溯：每個結論都要有出處

資安審查關注資料怎麼進來、怎麼被保護；課責機制則關注結論怎麼產生。AI 幕僚的每個研判與建議都應能點回原始資料——新聞原文、社群貼文、公文或會議紀錄——並在介面上區分已確認事實、輿情觀察與 AI 推論。可追溯性應列為採購的必要條件：無法交代出處的產出，在政府流程中沒有正式價值。

驗收時可用抽驗的方式檢查這項要求是否真的落實：由機關人員在系統產出的研判報告中任意指定一個結論點，要求現場回溯到原始資料，確認來源存在、內容相符且時間正確；若指到的是 AI 推論，系統也應明確標示其為推論而非事實。抽驗題目由機關當場出題，並將通過標準寫入驗收項目，比事前審閱功能說明書更能反映實際可用性。

資安審查怎麼過：四步驟準備流程

資安審查之所以拖延，多半不是因為系統不合格，而是準備順序錯了——先做完系統才回頭補文件，往往發現架構已經無法配合。建議把審查視為四個階段的準備流程：自評與定級、文件準備、審查與補件、上線後的持續稽核。前兩步在簽約前就該啟動，第四步則要寫進契約的維護條款，否則上線即失控。

一、自評與定級：先確認自己要過的是哪一關

第一步不是找廠商，而是由機關資安人員確認兩件事：本系統對應的系統防護等級，以及即將進入系統的資料機敏分類。同樣叫做 AI 幕僚，只做公開輿情監測與整合內部人事、個案資料，適用的要求相差很大。把預計匯入的資料逐類列出——公開新聞、社群貼文、內部公文、會議紀錄、個案資料——標註各自的機敏等級與是否含個人資料，這張表會直接決定部署模式該選外雲內地或完全地端，也會決定後續文件的深度。跳過這一步，等於讓廠商替機關決定風險胃納。

二、文件準備：把架構說清楚比寫得漂亮重要

文件的核心是一張標明資料流向的系統架構圖：每一段資料從哪裡來、經過哪些元件、存放在哪台主機、由誰可以存取，箭頭方向與存放位置都要標示清楚。其餘常見的必備文件包含供應商的 ISO 27001 證書、個資盤點與法遵說明、權限矩陣、備份與營運持續計畫，以及弱點掃描或滲透測試報告。有政府導入經驗的廠商通常備有可套用的文件範本，機關只需就本案差異處調整，能省下相當可觀的往返時間。

三、審查與補件：把問題收斂成待辦清單

審查意見多半集中在幾個固定方向：資料是否可能外流、權限切分是否確實、紀錄能否調閱、廠商人員的維運存取如何控管。收到意見後，建議由機關承辦統一整理成一張待辦清單，逐項標註負責方是機關還是廠商、預計完成時間與佐證文件，而不是讓意見散落在各封往來信件中。同一輪把問題問完、補齊，通常比分多次零星補件快得多。

四、上線後：年度稽核與紀錄調閱演練

通過審查只是起點。系統上線後應納入機關的年度資安稽核範圍，定期檢視權限是否隨人事異動更新、離職或轉調人員的帳號是否確實停用、備份是否可還原。另外建議每年安排一次紀錄調閱演練：假設有人質疑某份 AI 輔助產出的資料，機關能否在合理時間內調出完整的查詢紀錄與版本軌跡。演練過一次，才知道紀錄是真的可用，還是只是存在。相關要求應一併寫入維護契約，明訂廠商的配合義務。

採購規格檢核清單

• 資料儲存與模型推論均於台灣境內，供應商具 ISO 27001 認證
• 提供完全地端部署選項，或「外部蒐集雲端＋內部知識地端」混合架構
• 支援 RBAC 角色權限、MFA 多因素驗證，權限異動留有紀錄
• 留存完整查詢紀錄與模型使用紀錄，可供資安稽核調閱
• AI 產出保留版本軌跡：產出版、修改版、修改者、核准者、時間
• 每個結論附原始資料連結，介面區分事實、觀察與 AI 推論
• 個資處理符合個人資料保護法：僅蒐集公開內容、統計化呈現