摘要
很多公司導入 AI 的第一個混亂點，不是工具太難，而是員工早就開始用了。
有人用免費帳號整理會議紀錄，有人把客戶信件貼進聊天工具改寫，有人用 AI 產出對外簡報，有人讓工具協助整理報價或合約重點。每個人都覺得自己只是提高效率，但公司層面卻不知道：哪些資料被輸入、哪些輸出被對外使用、誰檢查過、出錯時誰負責。
本文提供一份給非技術主管的員工 AI 使用規範清單。它不是厚重制度，也不是法律文件，而是一套讓團隊每天能用、敢用、知道邊界的工作規則。
核心結論
員工 AI 使用規範的目的，不是禁止大家用 AI，而是把「可以怎麼用」講清楚。
一份可落地的規範，至少要回答六個問題：
| 問題 | 規範要寫清楚 | 沒寫清楚時會發生什麼 |
|---|---|---|
| 可以用在哪裡 | 允許的任務、工具與資料類型 | 同仁各自判斷，風險不一致 |
| 不能輸入什麼 | 客戶、財務、合約、個資、帳號與內部機密邊界 | 敏感資料被貼進未核准工具 |
| 輸出怎麼用 | 內部草稿、對外內容、系統寫入的審核差異 | AI 初稿被誤當成正式結論 |
| 誰能開權限 | 個人帳號、公司帳號、付費工具與外掛權限 | 工具越開越多，沒有人統一管理 |
| 出錯怎麼回報 | 錯誤類型、截圖、修正方式與 owner | 錯誤只在聊天室抱怨，沒有改善 |
| 何時可以擴大 | 試用紀錄、採用率、錯誤率與主管放行條件 | demo 成功後直接全員放大 |
非技術主管不需要變成資安工程師，但要能把日常使用規則說清楚。AI 工具越普及，越不能靠每位同仁自行猜測界線。
目錄
- 為什麼公司需要 AI 使用規範
- 先把用途分成三個層級
- 禁止輸入資料要寫得比口號更具體
- AI 輸出不能直接等於公司立場
- 帳號、外掛與連接工具要有人管理
- 一頁式員工 AI 使用規範範本
- 小團隊的 30 天落地流程
- 參考來源與資料時間
- 常見問題
為什麼公司需要 AI 使用規範
很多主管會等到公司正式採購 AI 工具，才開始談使用規範。
這通常太晚。
現場更常見的狀況是：員工已經在用各種 AI 工具，只是沒有講出來。有人用來潤飾 email，有人整理會議摘要，有人寫社群貼文，有人分析客戶留言，有人把內部 SOP 貼進去請 AI 改寫。
這些用途未必都危險。真正危險的是公司沒有共同規則。
常見問題有五種：
| 現場狀況 | 表面看起來 | 真正風險 |
|---|---|---|
| 每個人各用各的工具 | 團隊很積極嘗試 | 公司不知道資料流向與工具權限 |
| 用免費帳號處理工作資料 | 節省預算 | 缺少公司層級的管理、稽核與退場流程 |
| AI 草稿直接對外使用 | 交付變快 | 錯誤承諾、語氣失準或來源不清 |
| 把工具接上雲端文件 | 查資料很方便 | 權限範圍可能大於原本任務需要 |
| 出錯後只口頭提醒 | 很快修掉單點問題 | 沒有紀錄，下一個人會再犯 |
所以使用規範不是為了讓 AI 變慢，而是讓效率有邊界。
如果公司不先定義規則，真正的結果不是「大家自由創新」，而是每個人用自己的風險標準處理公司資料。
先把用途分成三個層級
制定規範前，不要一開始就列一長串工具名稱。工具會換，但任務風險比較穩定。
建議先把員工 AI 用途分成三層。
| 層級 | 定義 | 可以怎麼管理 |
|---|---|---|
| 低風險輔助 | 不含敏感資料、不對外、不寫入正式系統 | 可開放使用，保留人工判斷 |
| 需審核使用 | 會影響客戶、品牌、合約、報價、公開內容或重要決策 | AI 只能產出草稿，需指定人審核 |
| 暫不開放 | 涉及高敏感資料、金錢動作、帳號權限、法律或人事判斷 | 未建立流程前先排除 |
例如：
| 任務 | 建議層級 | 原因 |
|---|---|---|
| 把公開文章改成社群貼文草稿 | 低風險輔助 | 資料本來公開，但仍需人工確認語氣 |
| 整理內部會議待辦 | 低風險或需審核 | 取決於是否含客戶、財務或人事資訊 |
| 改寫客戶 email | 需審核使用 | 對外語氣與承諾需真人確認 |
| 分析客服對話 | 需審核使用 | 可能含個資與客戶抱怨脈絡 |
| 產出報價、合約或退款回覆 | 暫不開放或高度審核 | 涉及金錢、條款與責任邊界 |
| 自動寫入 CRM、訂單或付款系統 | 暫不開放 | 需要批准、紀錄與回復機制 |
這樣分層後，主管比較容易說清楚：「不是所有 AI 使用都一樣。有些可以直接當助手，有些只能當草稿，有些現在不要做。」
禁止輸入資料要寫得比口號更具體
很多公司會在規範裡寫一句：「不得輸入機密資料。」
這句話太抽象。
員工真正需要的是具體例子，否則每個人對機密的理解都不同。客服同仁可能覺得只貼一段對話沒關係，業務可能覺得只遮掉公司名稱就可以，主管可能覺得只要不是財務數字都還好。
建議把禁止輸入資料寫成清單。
| 類型 | 不應輸入的例子 | 比較穩健的替代方式 |
|---|---|---|
| 客戶個資 | 姓名、電話、地址、email、訂單、身份資料 | 去識別化後只保留問題類型 |
| 商務機密 | 報價底線、合約條件、未公開合作、採購價格 | 改用範例情境或已核准模板 |
| 帳號權限 | 密碼、API key、後台截圖、權限設定 | 只描述錯誤現象，不貼憑證 |
| 內部人事 | 績效、薪資、離職、申訴、健康資料 | 不用一般 AI 工具處理 |
| 財務與付款 | 發票、付款、銀行、退款、信用卡資訊 | 由內部系統或指定流程處理 |
| 未公開產品 | Roadmap、上線前功能、供應商素材 | 改成抽象需求，不貼原始資料 |
如果公司已採購企業版或有內部核准工具，也不要因此把所有資料都放行。不同工具的資料處理、管理功能、保存設定、連接權限與管理者可見範圍都不同，仍要依公司實際設定確認。
OpenAI 的企業隱私與商業資料頁面說明了企業與商業帳戶的資料控制承諾，但這不代表每家公司所有使用方式都自動適合貼入敏感資料。主管要做的，是把「工具層級承諾」轉成「公司內部可執行規則」。
AI 輸出不能直接等於公司立場
員工使用 AI 最容易漏掉的一件事是：AI 輸出看起來很完整，但它不會自動變成公司核准過的說法。
尤其是這些情境：
- 客服回覆。
- 銷售信與合作邀約。
- 合約、條款、退款或保固說明。
- 對外簡報與公開文章。
- 招募、人事、績效或申訴相關文字。
- 產品功能、價格、交付時程或案例成果說明。
這些內容可以用 AI 做初稿，但不能把初稿當正式結論。
建議把輸出用途分成三類：
| 輸出用途 | 可以怎麼用 | 必要檢查 |
|---|---|---|
| 內部草稿 | 摘要、待辦、腦力激盪、初稿整理 | 使用者自行確認來源與脈絡 |
| 對外內容 | 客戶 email、社群、簡報、文章、FAQ | 由內容 owner 或主管確認 |
| 高影響決策 | 報價、合約、退款、人事、財務、醫療、法律相關 | 不由一般 AI 輸出直接決定 |
一個簡單規則是：
AI 可以協助起草，但不能替公司承諾；AI 可以協助整理，但不能替主管判斷責任。
這句話比「使用者自行負責」更有用。因為它讓主管也承擔設計流程的責任，不只是把錯誤推給第一線同仁。
帳號、外掛與連接工具要有人管理
員工 AI 使用規範不能只談聊天內容，也要談帳號與連接權限。
現在很多 AI 工具不只是聊天視窗。它可能連接 Google Drive、Gmail、Calendar、CRM、Slack、Notion、資料庫、瀏覽器、外掛、API 或公司內部工具。
一旦工具能讀資料或執行動作，風險就不只是「問錯問題」，而是「它能接觸到多少資料、代表誰做什麼」。
建議至少管理五件事：
| 管理項目 | 要問的問題 |
|---|---|
| 帳號類型 | 是個人免費帳號、個人付費帳號，還是公司管理帳號？ |
| 管理者 | 誰能新增、停用、移除使用者與查看設定？ |
| 連接權限 | 工具能讀哪些文件、信件、日曆、客戶資料或系統？ |
| 外掛與動作 | 是否能寄信、改資料、建立任務、填表或觸發流程？ |
| 離職與退場 | 同仁離職、轉調或工具停用時，資料與權限怎麼收回？ |
OWASP 對 LLM prompt injection 的風險提醒也適用在這裡：當模型會讀取外部內容或連接工具時，外部輸入可能影響模型行為。對非技術主管來說，重點不是理解所有攻擊細節，而是知道一件事：能連工具的 AI，不應和只能寫草稿的 AI 用同一套規則管理。
一頁式員工 AI 使用規範範本
小公司不需要一開始就寫 30 頁政策。先做一頁式規範，反而比較容易被團隊記住。
可以用這個結構：
| 區塊 | 規範內容 |
|---|---|
| 使用目的 | AI 用來協助整理、草擬、改寫、分類、查核與提高工作效率，不代替員工與主管的專業判斷 |
| 核准工具 | 列出目前允許使用的工具、帳號類型與適用部門 |
| 允許用途 | 會議摘要、公開內容改寫、內部草稿、已去識別化的問題分類 |
| 禁止輸入 | 客戶個資、合約、報價底線、付款資料、帳號密碼、API key、人事資料、未公開產品 |
| 對外輸出 | 客戶、公開頁面、社群、簡報與銷售信必須由指定 owner 確認 |
| 高風險排除 | 報價、退款、合約、人事、財務、法律、醫療、資安事件不由一般 AI 工具直接決定 |
| 錯誤回報 | 記錄輸入類型、輸出問題、使用工具、是否已對外、修正方式 |
| 權限管理 | 工具、外掛、文件連接與退場流程由指定主管或管理者核准 |
| 更新節奏 | 每月回查一次錯誤紀錄、工具清單、禁止資料與使用案例 |
這份規範最重要的不是寫得漂亮，而是能被用。
如果員工看完仍不知道某份資料能不能貼、某段輸出能不能寄、某個外掛能不能開，那規範就還不夠具體。
小團隊的 30 天落地流程
如果你是非技術主管，可以用 30 天先做最小版本。
| 時間 | 動作 | 交付物 |
|---|---|---|
| 第 1 週 | 盤點同仁目前怎麼用 AI | 使用情境清單與工具清單 |
| 第 2 週 | 分類允許、需審核、暫不開放用途 | 三層用途表 |
| 第 3 週 | 寫出一頁式規範並找 2 到 3 位同仁試讀 | 第一版規範與常見疑問 |
| 第 4 週 | 開始記錄錯誤、疑問、例外與新增需求 | 月度回查表 |
這 30 天不要追求完美制度。先讓團隊有共同判斷方式：
- 這種資料可以貼嗎？
- 這段 AI 輸出能不能寄給客戶？
- 這個工具能不能接公司文件？
- 出錯時誰要知道？
- 下個月要不要擴大使用？
當這些問題能被穩定回答，公司才適合把 AI 從個人效率工具，慢慢升級成可管理的工作流。
參考來源與資料時間
本文撰寫與審核時參考以下公開資料，資料時間為 2026-07-26：
| 來源 | 本文使用方式 |
|---|---|
| NIST AI Risk Management Framework | 參考 AI 風險治理、盤點、量測與管理的基本思路 |
| NIST AI RMF Playbook / Core | 參考組織如何把治理目標轉成實務行動與紀錄 |
| OWASP LLM01 Prompt Injection | 參考外部輸入與連接工具可能影響模型行為的風險提醒 |
| OpenAI Enterprise Privacy / Business Data / ChatGPT Enterprise | 參考企業帳戶、資料控制、管理與權限相關公開說明 |
本文是員工 AI 使用規範與管理流程建議，不是法律、資安、人資或合規意見。涉及個資、雇用、金融、醫療、法律、付款、合約、資安事件或高敏感資料時，應由公司內部相應 owner 與專業人員依實際情境審核。
常見問題
公司還沒採購企業版 AI 工具，也需要使用規範嗎？
需要。越是還沒採購統一工具，越容易出現員工各自使用免費或個人付費帳號的情況。規範可以先從禁止資料、允許用途、對外輸出審核與錯誤回報開始，不必等到正式採購後才做。
直接禁止員工用 AI，會不會比較簡單？
短期看起來簡單，長期通常不可行。員工仍可能私下用 AI 解決工作問題，只是公司更看不見。比較務實的做法，是先開放低風險用途，明確排除高敏感資料與高影響決策，再用紀錄決定是否擴大。
員工用 AI 改寫 email，需要主管每封都看嗎？
不一定。一般內部信件或低風險草稿可由使用者自行確認。但只要涉及客戶承諾、價格、退款、合約、功能支援、交付時程、投訴或法律語氣，就應由指定 owner 或主管審核後再送出。
可以把公司文件接到 AI 工具裡查詢嗎？
不要一律開放。先確認工具帳號類型、管理者、文件權限、資料保存設定、可讀範圍與退場方式。若文件包含客戶個資、合約、財務、人事、未公開產品或系統權限，應先排除或改用公司核准的封閉流程。
使用規範多久要更新一次？
小團隊建議每月回查一次，至少看三件事：員工新增了哪些用途、錯誤或疑問集中在哪裡、工具權限是否有變。當公司開始導入 Agent、外掛、雲端文件連接或系統寫入，就應重新審核規範。
這樣做能完全避免 AI 使用風險嗎？
不能。規範的價值不是消除所有風險，而是讓團隊知道哪些事情可以做、哪些需要審核、哪些暫時不要做。真正成熟的做法，是把規範、教育、權限、錯誤回報與定期回查放在同一個流程裡。
延伸閱讀
- 非技術主管的 90 天 AI 升級路線：不用寫程式，也要能交付可驗證成果
- 企業導入 AI Agent 前，哪些資料絕對不能交給代理自動處理？
- AI 試點上線前，人工審核與停損線怎麼設？非技術主管的 12 項檢查表
SEO Meta
- Title: 員工 AI 使用規範清單：非技術主管如何管理資料、權限與輸出審核
- Description: 員工日常使用 AI 工具時，主管該如何訂規範？本文整理允許用途、禁止資料、對外輸出審核、帳號權限、錯誤回報與 30 天落地流程。
- Keywords: 員工AI使用規範, AI治理, 非技術主管, 中小企業AI, 資料邊界, AI使用政策