Security, Audit and On-Premise Requirements for Government AI Copilots

When agencies evaluate an AI copilot, the feature demo is rarely the final hurdle — the security review is. Does data leave the country? Who can see what? Is every AI output logged and reviewable? Can the whole system live in the agency's own server room? This article organizes the six security requirements, audit design and on-premise deployment options for government AI copilot adoption, with a checklist ready for procurement specs.

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

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

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

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

1. Data Sovereignty: Data Staying Onshore Is the Baseline

Most public-cloud generative AI services run inference in offshore data centers — a fundamental obstacle for government business, since once official information enters an offshore service, the agency loses control over where the data flows. A compliant AI copilot system should ensure that data hosting and model inference both stay within Taiwan, the vendor holds ISO 27001 certification, and data transport uses TLS 1.2 or above. Procurement specs should state explicitly that data storage and processing must not leave Taiwan.

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

2. Deployment Options: Cloud, Private Cloud and On-Premise

By business sensitivity, deployment options range from Taiwan-based cloud (suitable for monitoring built mainly on public sentiment), through government private cloud, to full on-premise — where system and models run in the agency's own server room and even model inference needs no external connection. For an AI copilot integrating internal documents and sensitive data, target on-premise directly; the external sentiment collection layer can stay in the cloud, forming a "cloud outside, on-premise inside" hybrid that balances data coverage with the security boundary.

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

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

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

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

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

3. Access Control: Who Can See What, Who Can Ask What

The information an AI copilot aggregates varies in sensitivity: public sentiment is open to all, interpellation debate materials are restricted to the staff circle, and internal assessments touching individual cases are accessible only at specific levels. The system should support role-based access control (RBAC) — data visibility and feature permissions set by rank and business role — combined with multi-factor authentication (MFA). Within the same system, the executive, department heads and case officers should see different content and be able to run different queries.

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

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

4. Usage Logging: Model Behavior Must Leave a Trail

Generative AI introduces a new audit subject: the model's own behavior. A compliant system should retain who queried what and when, which materials the model cited to produce each response, and who received alerts and briefings. These records serve two purposes — post-incident investigation of security events, and answering oversight questions about whether the AI is being misused. An AI system without usage logs is an audit blind spot in a government environment.

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

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

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

5. Output Audit: What AI Wrote and What Humans Changed Must Be Separable

If press releases or response materials are AI-assisted, the agency must be able to answer: which parts did the AI write, who edited them, who approved them? The system should keep a complete version trail: the AI-generated version, human-edited version, editor, approver, cited materials and generation time. This is not only an audit requirement but a design that protects staff — when disputes arise, it proves that human gatekeeping actually happened.

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

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

6. Source Traceability: Every Conclusion Needs a Citation

Security review asks how data comes in and how it is protected; accountability asks how conclusions are produced. Every assessment and recommendation from an AI copilot should link back to original materials — news articles, social posts, official documents or meeting minutes — with the interface separating confirmed facts, sentiment observations and AI inference. Traceability should be a mandatory procurement condition: output that cannot account for its sources has no formal standing in government processes.

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

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

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

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

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

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

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

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

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

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

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

Procurement Spec Checklist

• Data storage and model inference both within Taiwan; vendor holds ISO 27001 certification
• Full on-premise deployment option, or a hybrid of cloud external collection + on-premise internal knowledge
• RBAC role permissions and MFA, with permission changes logged
• Complete query and model usage logs retained, available for security audits
• AI output keeps a version trail: generated version, edited version, editor, approver, timestamp
• Every conclusion links to original sources; the interface separates facts, observations and AI inference
• Personal data handling complies with the Personal Data Protection Act: only public content collected, presented in aggregate