模板
AI 政策模板：適用於工作的實用可接受使用政策
有效的 AI 政策會告訴員工現在可以做什麼、哪些事項需要批准、哪些行為被禁止，以及答案不明確時由誰決定。下面的模板是執行起點，並非法律意見。請根據組織的合約、司法管轄區、資料分類、聘僱實踐、安全計劃和實際工具進行調整。
研究與披露: 本模板參考了 NIST AI 風險管理框架、NIST 生成式 AI 配套框架和 OECD AI 原則，資料查核日期為 2026 年 9 月 4 日。本文為原創編輯材料，必須由組織的法務、隱私、安全、人力資源和業務負責人審查。
可複製並調整的 AI 政策模板
標題：負責任的 AI 可接受使用政策
負責人：[角色或團隊]
生效日期：[日期]
審查日期：[日期]
1. 目的
本政策定義工作人員如何為[組織]評估、採購、建構和使用 AI 系統。
適用於使用組織資料或代表組織行事的員工、承包商和供應商。
2. 已批准用途
工作人員可以將批准工具登記表中的工具用於[列出的低風險用途]。
必須遵循下文的資料、審查、歸因和記錄儲存規則。
3. 需要批准的用途
在使用 AI 作出會影響就業、資格、安全、法律權利、財務、客戶、
公開聲明、受監管記錄或生產系統的決定或輸出之前，必須獲得[角色]批准。
4. 禁止用途
不得使用未經批准的工具、繞過存取控制、冒充他人、偽造證據、
在沒有責任人的情況下作出具有後果的最終決定，也不得提交該工具
未獲準處理的資料類別。
5. 資料處理
遵守現有資料分類政策。除非具體工具和用途已經批准，否則不得輸入憑據、
受限個人資料、客戶機密資料、原始碼、合約或未公開財務資訊。
6. 人工審查
指定負責人必須在使用或分享輸出前，核實重要事實、來源、計算、權利、
偏差風險和必要披露。
7. 透明度與歸因
當法律、合約、平台規則、專業標準或組織慣例要求時，披露實質性的 AI 協助。
不得將 AI 回應引用為事實聲明的來源。
8. 採購與開發
採用前記錄目的、負責人、資料流、供應商、保留期限、訓練用途、
安全控制、失敗模式、評估和退出計劃。
9. 記錄與事故
儲存該使用場景要求的記錄。發現意外披露、有害輸出、政策繞過、重大錯誤
或未授權操作後，應在[時間]內報告至[事故渠道]。不得隱瞞或靜默修正事故。
10. 例外與執行
[角色]可以批准一項包含範圍、控制措施、負責人和到期時間的限時書面例外。
違規行為按照現有安全和行為政策處理。新增風險分級表
| 級別 | 示例 | 預設規則 |
|---|---|---|
| 低 | 使用公開資訊進行頭腦風暴 | 使用已批准工具並接受常規審查 |
| 中 | 根據公司資料起草內部分析 | 使用已批准資料路徑、指定審查者並儲存來源 |
| 高 | 就業、信貸、法律、健康、安全或公開聲明 | 正式評估並由責任人批准 |
| 禁止 | 欺騙、非法歧視、共享憑據、繞過控制 | 不得使用 |
風險取決於具體語境，而不是工具標籤。總結公開文章和篩選求職者可能使用相似技術，卻需要完全不同的控制措施。
定義員工會使用的術語
如果日常工作無法映射到政策詞彙，這項政策就會失效。應加入簡短定義：
- **AI 系統：**使用機器學習或生成模型來生成、分類、預測、推薦、提取或執行操作的軟體；
- **已批准工具：**針對規定用途和資料類別獲得批准的具體服務、套餐、設定和整合；
- **AI 輔助輸出：**由 AI 系統進行實質性起草、轉換、分析或推薦的工作；
- **後果性決定：**影響就業、存取、資格、權利、安全、財務、客戶或其他重大利益的決定；
- **責任人：**對最終使用或操作擁有權限並承擔責任的人；
- **受限資料：**因政策、合約、法律或安全分類而受到處理限制的資訊；
- **人工審查：**依據既定標準進行真實檢查，而不是在無法檢視證據時點選批准；
- **事故：**意外披露、有害或歧視性輸出、重大錯誤、控制繞過、未授權操作或其他政策違規。
這些定義應與公司現有語言一致。如果安全和隱私計劃已經定義機密資料或事故嚴重程度，不要另建一套不同含義。
分配角色和決策權
| 角色 | 最低職責 |
|---|---|
| 高管負責人 | 設定風險容忍度、解決重大例外、為實施提供資源 |
| 政策負責人 | 維護政策、示例、工具登記表、培訓和審查日曆 |
| 業務負責人 | 定義使用場景、結果、審查者和可接受失敗水平 |
| 安全團隊 | 審查身份、存取、整合、日誌、測試和事故回應 |
| 隱私團隊 | 審查個人資料、目的、最小化、保留和個人權利 |
| 法務或合規 | 審查適用義務、合約、披露和高影響用途 |
| 採購團隊 | 儲存供應商承諾、分包處理者、續約和退出條款 |
| 人力資源 | 負責員工溝通、培訓和就業相關用途 |
| 使用者 | 遵守批准範圍、審查輸出、保護資料並報告事故 |
為每條審批路徑指定決策人，而不只是一個群組。跨職能委員會可以提供建議，但員工需要知道誰可以回答“批准”“拒絕”或“暫不批准”。
維護已批准工具登記表
將變化較快的產品詳情放在核心政策之外的受控登記表中：
| 欄位 | 需要達到的具體程度示例 |
|---|---|
| 產品 | 供應商、產品、企業套餐和已批准帳戶類型 |
| 負責人 | 負責設定和續約的團隊 |
| 允許使用者 | 指定群組或角色 |
| 允許用途 | 起草公開內容；在限定來源下總結內部資料 |
| 允許資料 | 公開和一般內部資料；不含受限個人資料 |
| 整合 | 僅限已批准的儲存和身份連線 |
| 訓練用途 | 合約約定和設定狀態 |
| 保留 | 預設值、設定值和刪除流程 |
| 必要審查 | 作者審查；指定輸出需要專家審查 |
| 禁止操作 | 不得傳送、發布、刪除或更改記錄 |
| 批准日期 | 決策記錄和批准人 |
| 審查日期 | 定期複審或合約事件 |
批准應附著於具體設定和用途，而不是品牌名稱。消費者帳戶、企業帳戶、API 部署、瀏覽器擴充和連線操作功能可能具有不同的資料處理方式和權限。
將資料分類與工具使用連線起來
根據組織現有分類調整以下矩陣：
| 資料類別 | 預設 AI 規則 | 可能的例外 |
|---|---|---|
| 公開 | 可以使用已批准工具 | 常規內容和權利審查 |
| 一般內部 | 使用已批准的託管工具 | 目的、存取和保留控制 |
| 機密 | 除非明確批准，否則拒絕 | 具有合約和技術控制的指定工作流程 |
| 受限個人資料或受監管資料 | 必須進行高風險評估 | 僅限明確批准的系統、目的、欄位和審查者 |
| 憑據和認證秘密 | 不得輸入提示詞或追蹤記錄 | 使用專用秘密管理，而不是政策例外 |
派生資料也必須納入範圍。即使刪除附件，提示詞也可能暴露客戶關係。檔名、摘要、嵌入、日誌、工具引數和截圖都可能繼承來源的分類級別。
為操作和 Agent 新增規則
生成式工具正在從起草轉向執行。政策必須延伸到內容之外：
AI 系統只有在滿足以下條件時，才可以執行外部操作或更改記錄系統：
- 操作屬於已批准使用場景；
- 憑據被限制在最低必要權限；
- 允許的目標、金額、頻率和時間視窗受到約束；
- 系統驗證輸入並防止重複執行；
- 後果性操作需要授權角色批准；
- 操作和批准均被記錄；
- 已測試停止、撤銷和恢復路徑。把傳送、發布、採購、刪除、授予存取、更改記錄和聯絡人分別視為獨立權限。允許起草電子郵件並不代表允許傳送。
建立高風險用途評估
批准高風險用途前，要求提供一份簡短記錄：
業務目的和預期收益：
受影響人員和決定：
責任人：
AI 角色和人工權限：
輸入、輸出、資料類別和資料流：
供應商、模型、整合和版本：
已知限制和可預見誤用：
準確性、公平性、無障礙性、隱私和安全評估：
告知、解釋、申訴和糾正機制：
監控和事故閾值：
記錄與保留：
復原和替代流程：
批准人、條件、到期時間和下次審查：批准不是永久性的。將其範圍限制在已測試的工作流程、人群、資料和設定。出現新模型、新操作能力、新整合、新人群或新決策目的等重大變化時，應重新評估。
處理例外但不製造漏洞
一項例外應說明請求內容、業務理由、為何沒有可用替代方案、資料、使用者、控制措施、負責人、開始時間、到期時間和批准人。設定時間限制並防止靜默續期。緊急存取應按照既有流程接受事後審查。
不要因為工作已經開始或供應商試用即將結束就批准例外，那會獎勵繞過政策的行為。跟蹤重複請求，它們可能說明已批准工具集合不足，或者規則不夠清晰。
新增 AI 事故回應手冊
1. 在安全可行時停止或隔離受影響工作流程。
2. 儲存相關輸入、輸出、版本、操作和存取記錄。
3. 透過指定渠道通知事故負責人。
4. 識別受影響人員、系統、記錄和下游接收者。
5. 根據需要限制存取、撤銷憑據或撤回輸出。
6. 讓安全、隱私、法務、HR、溝通或業務負責人參與。
7. 在需要時修正記錄並通知受影響方。
8. 記錄原因、控制缺口和糾正措施。
9. 將失敗加入培訓、評估或監控。
10. 風險重大時，在重新啟動前重新授權工作流程。AI 政策應該引用現有事故處理計劃，而不是另建一套嚴重程度標準。需要改變的是必須儲存的證據：模型和提示詞版本、來源上下文、工具呼叫、批准和生成的交付物。
實施檢查清單
- 盤點實際 AI 使用情況，包括免費瀏覽器工具和嵌入式功能。
- 使政策與現有安全、隱私、記錄、採購和行為規則一致。
- 發布包含允許資料類別和使用場景的已批准工具登記表。
- 為工作人員提供快速提問和申請新工具的路徑。
- 使用貼近現實的允許、需批准和禁止示例進行培訓。
- 記錄例外事項的負責人和到期日期。
- 每季度審查事故、供應商變更和高風險用途。
不要只依賴每年一次的確認書。只有當政策出現在採購、入職、工作流程設計和審查清單中時，它才真正有用。
用決策而不是定義進行培訓
向員工提供簡短場景：
- 銷售人員能否把客戶合約貼上到免費助手中，以總結續約日期？
- 行銷人員能否依據目前官方來源生成產品對比？
- 經理能否讓 AI 對員工晉升進行排名？
- 開發人員能否提交可能包含憑據的生產錯誤日誌？
- 助手能否起草會議摘要並自動分配任務？
針對每個場景，詢問其中涉及哪個工具、哪些資料、哪位審查者、什麼操作和什麼記錄。培訓的成功標準是員工選擇正確路徑並知道向誰詢問，而不是背出一條定義。
在決策發生的位置加入政策提醒，例如採購表單、瀏覽器存取、資料分類標籤、工作流程模板、發布檢查清單、程式碼審查和事故接收渠道。
衡量政策是否有效
有用的訊號包括：
- 已記錄且指定負責人的活躍 AI 工具比例；
- 按風險級別統計的審批週轉時間；
- 具有目前有效評估的高風險用途比例；
- 未批准工具和受限資料事件；
- 按政策模糊領域分類的員工問題；
- 按原因、負責人和時長統計的例外；
- 事故、險情、修正時間和重複原因；
- 已批准高風險工作流程的評估與監控覆蓋率；
- 場景式培訓完成情況。
不要把問題數量為零設為目標。提問可能說明人們在風險發生前暫停了操作。更健康的目標是快速、一致地解決問題，並減少反覆出現的歧義。
政策維護日曆
| 頻率 | 審查內容 |
|---|---|
| 每月 | 工具登記表變更、即將到期的例外、重大事故 |
| 每季度 | 高風險使用場景、重複問題、供應商和整合變更 |
| 每年 | 核心政策、角色、培訓、風險容忍度和相關政策 |
| 事件觸發 | 新法律、合約、模型、能力、資料用途、人群或事故 |
發布變更日誌。對於重大變化，應確定哪些現有使用場景必須重新評估，不要假設新規則無需實施工作就能自然覆蓋它們。
如需具體場景，請參閱 AI 使用政策示例。對於技術威脅邊界，請將這份政策與 AI Agent 安全清單結合使用。
常見問題
小公司可以使用這份 AI 政策模板嗎？
可以，但必須明確責任歸屬。包含一份批准工具清單、清晰資料規則和容易聯絡的決策人的短政策，比無人能夠執行的長政策更有效。
政策應該禁止在所有 AI 工具中使用機密資料嗎？
政策應該禁止在未經批准的工具中使用機密資料。獲得批准的企業系統可能根據合約和控制措施處理特定資料類別，但這些權限應按工具和使用場景記錄。
誰應該負責 AI 政策？
由一名承擔責任的高管負責，並接受法務、隱私、安全、人力資源、採購和業務部門的意見。沒有決策人的委員會只會造成延誤和歧義。
AI 政策應該多久更新一次？
按照固定週期審查，並在重要工具、法律、合約、事故或高風險用途變化時更新。批准工具登記表應該比核心政策更容易更新。
這份模板屬於法律意見嗎？
不屬於。它只是一項執行起點。必須由具備資質的法律顧問和相關專家根據適用法律、合約、聘僱實踐、受監管活動和司法管轄區進行調整。
員工應該披露每一次 AI 使用嗎？
披露應遵守適用法律、合約、專業義務、平台規則和組織慣例。政策應該規定何時需要內部記錄和外部通知，而不是使用一條模糊的統一規則。
公司可以批准整個類別的 AI 工具嗎？
廣泛的類別批准存在風險，因為不同套餐、設定、整合、保留和操作權限並不相同。應針對規定的資料和用途批准具體服務與設定，並設定審查日期。
使用 Ottermind 將已批准政策、工具登記表和審查規則轉換為可複用的專案上下文，再讓團隊開始製作交付物。
