政府がAI幕僚を導入する際のセキュリティ・監査・オンプレミス要件

機関がAI幕僚を評価する際、機能デモが最後の関門になることはほとんどありません——セキュリティ審査こそが関門です。データは国外に送られないか?誰が何を見られるのか?AIの出力は毎回記録され確認できるのか?システム全体を機関自身のサーバールームに置けるのか?本記事は、政府がAI幕僚システムを導入する際の6大セキュリティ要件、監査設計、オンプレミス展開オプションを整理し、調達仕様書にそのまま使えるチェックリストを提供します。

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

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

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

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

1. データ主権:データを国外に出さないことが最低ライン

多くのパブリッククラウド生成AIサービスの推論は国外のデータセンターで行われます。これは政府業務にとって根本的な障害です——公務情報が一度国外サービスに入れば、機関はデータの流れへのコントロールを失います。コンプライアンスに適合するAI幕僚システムは、データホスティングとモデル推論の両方が台湾国内にあること、ベンダーがISO 27001認証を持つこと、データ転送がTLS 1.2以上の暗号化を使うことを保証すべきです。調達仕様書には「データの保存と処理は台湾国内から出てはならない」と明記すべきです。

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

2. 展開オプション:クラウド・プライベートクラウド・オンプレミスの選択

業務の機密度に応じて、展開オプションは低い順に:台湾国内クラウド(公開世論中心のモニタリング業務に適する)、政府プライベートクラウド、そして完全オンプレミス——システムもモデルも機関自身のサーバールームで稼働し、モデル推論さえ外部接続を必要としません。内部公文書や機密データを統合するAI幕僚は、最初からオンプレミスを目標アーキテクチャとすることを推奨します。外部世論収集層はクラウドに残し、「外はクラウド・内はオンプレミス」のハイブリッド構造で、データカバレッジとセキュリティ境界を両立させます。

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

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

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

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

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

3. アクセス制御:誰が何を見られ、何を尋ねられるか

AI幕僚が集約する情報の機密度は一様ではありません:公開世論は誰でも見られますが、質疑論戦資料は幕僚サークルに限定され、個別案件に関わる内部分析は特定レベルのみアクセス可能です。システムはロールベースアクセス制御(RBAC)をサポートすべきです——職務レベルと業務分担に応じてデータの可視範囲と機能権限を設定し、多要素認証(MFA)を組み合わせます。同じシステムの中で、首長、部局長、担当者が見る内容と実行できるクエリは異なるべきです。

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

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

4. 使用記録:モデルの行動に痕跡を残す

生成AIは新しい監査対象を持ち込みました:モデル自身の行動です。コンプライアンスに適合するシステムは、誰がいつ何を照会したか、モデルがどの資料を引用して応答を生成したか、アラートとブリーフィングが誰に送られたかを保存すべきです。これらの記録には2つの用途があります——セキュリティ事案の事後調査と、「AIが不適切に使われていないか」という監督上の疑問への回答です。使用記録のないAIシステムは、政府環境では監査の死角に等しいのです。

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

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

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

5. 出力監査:AIが書いた部分と人が直した部分を分離できること

プレスリリースや答弁資料がAI支援で作成される場合、機関は「どこがAIの執筆か、誰が修正したか、誰が承認したか」に答えられなければなりません。システムは完全なバージョン証跡を保持すべきです:AI生成版、人による修正版、修正者、承認者、引用資料、生成時刻。これは監査要件であるだけでなく、担当者を守る設計でもあります——争議が生じた際、人によるゲートキーピングが確かに行われたことを明確に立証できるのです。

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

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

6. 出典追跡可能性:すべての結論に出所を

セキュリティ審査はデータがどう入り、どう保護されるかに注目します。説明責任のメカニズムは結論がどう生成されるかに注目します。AI幕僚のすべての分析と提言は原資料に遡れるべきです——ニュース原文、SNS投稿、公文書、会議録——そしてインターフェース上で確認済みの事実、世論の観察、AIの推論を区別すべきです。追跡可能性は調達の必須条件とすべきです:出所を説明できない出力は、政府のプロセスにおいて正式な価値を持ちません。

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

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

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

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

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

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

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

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

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

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

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

調達仕様チェックリスト

• データ保存とモデル推論がともに台湾国内、ベンダーはISO 27001認証を保有
• 完全オンプレミス展開オプション、または「外部収集はクラウド+内部ナレッジはオンプレミス」のハイブリッド構造を提供
• RBACロール権限、MFA多要素認証をサポートし、権限変更の記録を保持
• 完全なクエリ記録とモデル使用記録を保存し、セキュリティ監査で閲覧可能
• AI出力のバージョン証跡を保持:生成版・修正版・修正者・承認者・時刻
• すべての結論に原資料リンクを付け、インターフェースで事実・観察・AI推論を区別
• 個人情報の取り扱いは個人情報保護法に準拠:公開コンテンツのみ収集し、統計化して表示