小機構的AI風險，藏在沒人想到要寫的範疇裡
【本研究筆記資料蒐集與整理由 claude-sonnet-5 和GPT-5.6 Luna 協助完成，經作者審核定稿。】
0. 這篇筆記並非「AI 治理專家」撰寫的文章——我不是。促成這篇文章的，是一個非常實際的問題：一間資源有限的小型 CSO，員工已經在日常工作中使用 AI 工具，但機構層面卻連一份最基本的使用規則都沒有。
生成式 AI 工具（如 ChatGPT、Claude 等）近兩年快速普及，小型 NGO 員工個人已經在使用，但機構層面往往缺乏明確規則，「用咗再算」。有些可能誤以為「不儲存歷史紀錄」同時不少主要資助機構開始在申請或報告流程中詢問受助機構的 AI 使用情況，形成外部壓力。小型 NGO 的處境跟大機構／企業不同：
資源有限，沒有專職的資訊安全或法務團隊去審查每個 AI 工具
經常處理服務對象（受害人、難民、舉報人等）的高敏感度個資
對資助方有問責義務，資料處理方式可能受捐款人合約條款約束
部分 CSO（人權倡議、法律支援類）本身就是監控/打壓的目標，資料外洩風險的後果比一般企業嚴重
那麼究竟有沒有專門為公民社會/NGO機構設計的 AI 政策範本或框架？有沒有已知因誤用 AI 工具而導致資料外洩或其他事故的機構案例可供參考？本文分為兩部分：先說明初步資料搜集的觀察，再基於這些觀察，嘗試解答「一份政策範本最少應涵蓋哪些範疇」的疑問。
先說觀察
首先談一個落差：坊間已經有不少「機構 AI 政策」的一般性資源——面向所有機構的範本、原則清單、checklist。初步搜集確實找到一份專門針對為公民社會團體設計的資源（下文第4點會提到），但相對於大量通用範本而言，仍屬少數。而大部分範本，均假設機構設有法務部門審查合約、有專職部門審核服務供應商，而公民社會團體通常兩者皆無——這個落差正是核心問題所在。
針對人道／發展／保育類機構，NetHope 曾發布一份產業級的倫理框架（Humanitarian AI Code of Conduct）。當中「強調人手覆核 AI 產出的決策」「對弱勢群體使用合成媒體須有限制」這兩點方向，本身都來自搜尋引擎自行生成的摘要文字，精確度須打折扣。
資助機構那邊，情況較為模糊。有搜尋結果提到，主要基金會開始在資助流程中詢問受助機構的 AI 使用情況，但同時又有數字指出「大部分基金會仍未向受助機構提供任何 AI 實施支援」。這兩個現象可能同時成立——多問不等於多幫。
真正與小型 CSO 處境貼近的，是烏克蘭 Digital Security Lab 發布的「Human-Rights-Compliant Use of AI Systems」工具包，專門為公民社會而設計。
相對於上面幾份針對公民社會或人道機構的資源，英國 Charity Excellence 發布的《Charity AI Policy Template》則是一份通用的慈善團體範本。範本涵蓋九大範疇，值得留意的是「環境考量」獨立一節（承認 AI 系統「極高耗能」）；另有獨立的網絡安全與版本控制兩個章節。不過這份範本畢竟是英國慈善機構語境下的產物（例如 DPIA 是英國 GDPR 特有的概念），不能照搬所有細節到其他司法管轄區的小型 CSO 身上。
由此我有一項小觀察（並非結論）：集中式的商業 AI 服務，資料須經第三方系統處理，此風險對高風險機構而言，並非抽象概念。「使用 AI 工具是否會製造資料外洩／被反查的危機」是一個確切的風險，而一份機構的 AI 政策，可能是介入的起點。
以下疑問尚未有結論性答案：第一，是否已有因誤用 AI 工具導致資料外洩的非營利機構具體案例，目前只能說這是一個被普遍提出的理論風險。第二，AI 供應商在「資料是否用於訓練模型」這個問題上，各家合約條款的具體差異——這部分只能停留在常識層級：企業版／API版通常設有opt-out選項，免費版通常沒有；具體做法則需要深入分析各供應商的資料政策和實際操作。
不如試寫一份範本
以上觀察帶出一個更基本的問題：與其每次逐項爭論何種做法最好，或者因懷疑而全盤否定使用AI工具，不如問一份具體可供執行的政策，最少應涵蓋哪幾個範疇？我嘗試擬寫一個草稿，歸納為以下11個範疇。
目的與適用範圍： 機構制定AI政策的目的可概括為「訂定安全、尊重權利、安全可靠及具問責性的人工智能使用最低要求，包括生成式AI、自動化、AI應用程式、代理式系統，以及模型上下文協議（MCP）整合」。由於政策適用範圍不僅限於職員，還包括顧問、義工、實習生、董事會成員，以及使用組織資料的合作夥伴人員，訂定目的對於會接受資助/委託執行專案的小型CSO特別重要，確認規範的範圍。
一般原則： 「甚麼時候該用AI，甚麼時候絕對不應該用AI？」是一個經常討論的問題，但每個機構接觸和可能處理的資料，涉及的風險也不盡相同。目前這份草稿列出十項原則：人類責任、必要性及合乎比例、保密及資料最少化、預設安全、準確性及可提出異議、公平及不歧視、透明度、權利及尊嚴、可追溯性、可逆性及升級處理。為機構奉行的原則列成一張清單本身並非新鮮事，但置於政策最前面有一個作用，就是之後所有具體規則（哪個工具可獲批准、哪類資料可否輸入）都可以追溯回這十條原則，不必每次都從零開始論證。
個人裝置與例外處理： 撰寫這一部分時，我個人認為小機構最常見的AI風險入口，往往不是機構所選工具出事，而是職員自己在個人手機上打開一個ChatGPT或者Gemini就開始輸入內容。因此訂立這一節的規則可以堵住這個漏洞。用字也較為斬釘截鐵：「禁止使用個人裝置或個人帳戶處理任何工作相關的AI使用」，屬於預設規則，而非「建議改用公司帳戶」這種軟性建議。同時訂立一些例外情況，例如「有記錄的營運需要、沒有合理可用的機構替代方案、書面批准、符合最低保安要求、不處理敏感資料」、並為例外情況訂立到期日，要求有明文記錄（Log）。
在工作流動裝置上使用AI： 那麼甚麼情況下，機構人員可以在工作用的流動裝置上使用AI呢？這個細節容易被通用範本忽略。事實上大部分範本假設AI使用發生在電腦上，但小型CSO職員很多時候第一時間使用的是手機。很多時候電腦、手機的設定對於同一用戶資料的處理方式已經可以有分別。目前撰寫的草稿訂明六個前提缺一不可：一、工具已獲批准在流動裝置使用；二、該裝置已加入流動裝置管理（或同等控制）；三、透過獲批准帳戶登入；四、需要使用AI的情境已列入登記冊(Log）、五、除非明確授權否則不處理敏感資料；六、不會造成不安全的記錄／位置追蹤／通知／截圖／同步風險。這部分會引伸機構作進一步討論，例如甚麼屬於「低風險用例」——草擬非敏感文字、翻譯非敏感材料是否屬於可以納入AI工作流程？甚麼屬於「需要事先批准的情境」？特別關於接觸風險人士，需要保護消息來源身分的人士，這些都是機構在擬寫政策時可以具體考慮的情境，從而草擬出適合機構需要又切實可行的政策。
AI工具分類：不同機構的風險評估各異，草稿將機構納入評估的AI工具分為五類：獲批准、附帶限制獲批准、試行、禁止、待評估。一些政策生效之前職員申請在機構試行使用的工具，都須申報並補做評估，不應假設「開始使用即代表已獲機構批准」。
AI工具審批條件： 草稿列出九項審批條件：工具及供應商身分、模型訓練、預期處理的資料類別、私隱及保安、審計及管理控制、連接權限、版權責任、人權及營運影響、工具周期管理。這張清單的價值在於將「審查供應商」這個合規流程分拆成九項具體問題，資源有限的機構才有可能真正逐條具體跟進。
安裝、帳戶、保安及資料設定：這一章節旨在規範 AI 工具的安裝、帳戶管理、權限控制及資料設定，確保使用組織管理的帳戶和安全配置，防止未經授權存取、資料外洩及不當使用，並建立一致的技術保安基線。例如要求只有機構的科技總監或獲授權管理員才可以安裝/設定/連接AI工具；一律使用組織管理帳戶，而不接納沒有追蹤管理的共用帳戶；啟用多重認證及按角色分配存取權限；在服務容許的情況下停用供應商以組織輸入進行訓練等。最常見的機構設定「不要貼個資」，在AI的語境下並不足夠。如餘下的內容組合起來仍可識別人士、消息來源、合作夥伴、個案或地點，也不得輸入。
AI風險分類： 這一範疇旨在按 AI 工具及使用情境的潛在風險分級，訂定相應的批准、資料限制、人員監督及披露要求，協助組織在控制風險的同時，合理及負責任地使用 AI。草稿將風險級別分成4級，每級設定不同情境，訂出該級別下使用AI工具的權限和監督要求。同一工具可以獲批准作低風險用途，但對較高風險的使用情境則被禁止或受到限制。這個設計可以避免將AI工具一刀切分成使用或完全禁止。
以風險為本的批准及人員監督： 每一級風險對應不同的監督強度：第1級由使用者自行檢查即可，第2級須有實質人員覆核，第3級須事先書面批准加第二名人員獨立覆核，AI只能提供建議，不能作最終決定；第4級則禁止使用AI工具。草稿對「覆核」有一個明文定義，特意強調負責任的人員對輸入、方法、輸出、情境及後果作實質評估，並「有權拒絕、更正或要求 AI 系統重新工作」，而不只是快速查看或進行自動檢查。這句提醒至關重要，一份政策寫下「AI輸出須由人手覆核」很容易，但實際上能否做到，要看機構是否真的有人手有時間、有知識去覆核。
披露AI使用指引：草稿並無一條硬性規則，屬於個案判斷：如果AI在實質程度上生成、轉換或處理內容，而讀者原本會以為完全出自人手，一般應予披露；若決定不披露，對具實質影響的輸出須記下理由。這個範疇並不嘗試將披露簡化成一條非黑即白的規則，而是要求「有決定、有記錄」。
核實AI生成的資料及輸出。 草稿要求覆核人按風險程度：對照權威或第一手來源核實事實聲稱；檢查日期、姓名、引述、引用、計算、翻譯、連結；識別幻覺、遺漏、虛構來源、偏見、誤導性的確定語氣；在安全環境測試程式碼；確認沒有披露機密或個人資料；檢查版權/許可證/同意/署名要求。最後一句最為關鍵：AI輸出不可以是「涉及人士的決定、保安應對、保障行動、法律立場、資助或僱傭決定、公開的事實聲稱」的唯一依據。
篇幅所限，本次筆記未有逐個範疇討論。然而一份範本應該涵蓋的範疇還有：分享及發布AI生成輸出前的檢查、採用開源平台上的AI技能（開源不等於安全，未經覆核的外部技能須當作不受信任的程式碼處理）、開發自己的AI技能的流程、MCP及連接工具的獨立審批（讀寫刪除發送權限分開評估、不可逆行動須有人員確認）、審計更新與檢討間隔（每月/每季/重大變更後/事故後/每年）、異常情況及「疑似污染」事故程序（提示詞注入、惡意MCP行為、資料外洩，停用受影響工具、不要刪除證據、通知、記錄）、角色及責任分工、合規及例外處理，以及實務附錄（工具白名單、黑名單、最低使用記錄、初步落實清單）。這些部分，值得另開一篇文章專門討論，或者將來可以整理成一份真正可用的範本。
這份草稿並非說機構須一次過做齊11+個範疇才可以開始。機構可以挑選其中幾個範疇作為第一輪執行AI政策的方向和重點。但如果一份範本本身漏掉整個範疇（例如完全沒有提及流動裝置，或沒有涉及MCP這類連接工具），到出事時才發現無規則可循，才是真正的風險。這張地圖的價值不在於逼機構立即填滿所有範疇，而在於讓機構知道自己目前身處何處、遺漏了哪些部分。
假如你的機構開始著手草擬AI政策，你覺得最需要處理哪些問題？
參考資料
（查證日期：2026-09-23）
Open Culture Foundation 等，《2025 Civil Society Organizations' Call to the Taiwan Government on Digital Human Rights》— ocf.tw/en/p/rightsco...
歐盟委員會，AI literacy practices — digital-strategy.ec....
台灣行政院，《Guidelines for the Use of Generative AI by Executive Yuan and Subordinate Agencies》— www.ey.gov.tw/Page/4...
台灣數位發展部，AI Application Impact Assessment — moda.gov.tw/major-po...
NetHope, Humanitarian AI Code of Conduct — nethope.org/toolkits...
Candid, Getting started on a responsible AI use policy for nonprofits — candid.org/blogs/how...
Community IT, Template: Acceptable Use of AI Tools in the Nonprofit Workplace — communityit.com/temp...
Digital Security Lab Ukraine, Human-Rights-Compliant Use of Artificial Intelligence Systems: Toolkit for Civil Society — dslua.org/publicatio...
Just Security, Human Rights at Risk in the Sprint Toward AI Sovereignty — www.justsecurity.org...