一句話摘要

如果你不知道員工用了什麼 AI 工具、餵了什麼資料進去，那就不可能管理 AI 的安全風險。稽核是 AI 治理的基礎。

為什麼需要 AI 使用稽核

飛飛在企業資安顧問工作中遇過一個印象深刻的案例。一家中型科技公司的業務人員把客戶的報價單貼進免費版 ChatGPT，請 AI 幫忙生成一份競品比較表。這份報價單包含了客製化的折扣方案和合約條件，屬於高度商業機密。公司在三個月後才知道這件事，是因為競爭對手在提案中出現了非常類似的定價結構。調查的時候，公司連「誰在什麼時候做了這件事」都查不到，因為沒有任何 AI 使用紀錄。

這個案例說明了 AI 稽核的三個核心價值。

第一，法規要求。台灣個資法第 27 條要求對個人資料的處理要有適當的安全維護措施，包括「使用紀錄、軌跡資料及證據保存」。個資法施行細則第 12 條更進一步規定，安全維護措施應包含「資料安全稽核機制」。如果員工把客戶個資貼進 AI，你需要有紀錄證明你知道這件事、做了什麼處理。沒有稽核紀錄，在主管機關調查時就無法證明你的管理義務已經盡到。

第二，事件回應。如果發生資料外洩，調查時需要知道：誰在什麼時間用了什麼 AI 工具處理了什麼資料。沒有日誌就無法做根因分析，也無法評估影響範圍。飛飛做過的資安事件調查中，最痛苦的就是沒有日誌的案例——你知道事情發生了，但無法回溯過程，等於在黑暗中辦案。有日誌的案例通常兩天內就能釐清影響範圍，沒日誌的案例可能要花兩週以上。

第三，持續改善。透過使用數據了解員工的 AI 使用模式，可以優化培訓內容、調整政策、和選擇更好的工具。例如，如果數據顯示行銷部門每月使用 AI 的次數是其他部門的三倍，那下一次的 AI 安全培訓就應該優先安排給行銷部門。如果數據顯示某個團隊一直在用未核准的 AI 工具，那代表核准工具可能不夠好用，或團隊不知道有核准工具可以用。

該記錄什麼

最低限度要記錄五個欄位。

誰（Who）：使用者身份。用企業帳號或 SSO 登入的工具可以自動記錄，個人帳號則需要靠政策和自主申報。在設計日誌格式時，使用者身份建議用員工編號而非姓名，減少日誌本身的隱私風險。如果公司有 Active Directory 或類似的帳號管理系統，直接從 SSO 的認證日誌中提取身份資訊是最可靠的做法。

什麼時間（When）：時間戳記，精確到秒。用 UTC 或 ISO 8601 格式統一。台灣的企業在記錄時間時常見的錯誤是混用不同時區格式——有些系統用 UTC+8，有些用 UTC，日誌彙整時就會對不上。飛飛建議統一用 UTC 儲存，在報告中再轉換成台灣時間顯示。

用了什麼工具（Which Tool）：ChatGPT、Claude、Copilot、或其他。區分版本（免費版 vs 企業版）也很重要，因為資料處理政策不同。ChatGPT 免費版的對話預設可能被用於模型訓練，而 ChatGPT Enterprise 則明確承諾不會。這個差異在事件調查時很關鍵：如果員工用的是企業版，資料外洩的風險相對可控；如果用的是免費版，風險評估就截然不同。

資料分類（Data Classification）：輸入的資料屬於公開、內部、機密、或限制等級。這通常需要使用者自行標記，或透過 DLP 工具自動偵測。自行標記的準確度取決於員工的訓練程度——如果員工不清楚什麼資料算「機密」，標記就會不準確。飛飛的建議是在 AI 使用政策中用具體範例說明每個等級的定義，例如「客戶的聯絡方式和購買紀錄屬於機密等級」，而非只寫「涉及商業利益的資料」這種抽象描述。

做了什麼（What Action）：查詢、生成、分析、翻譯、程式碼產生等。不需要記錄對話的逐字內容（那會有隱私問題，而且儲存量太大），但需要知道用途類別。用途分類可以簡化成五到八個類別：文案撰寫、資料分析、程式碼輔助、翻譯、文件摘要、客服回覆草稿、內部報告、其他。

進階記錄（視需求）：輸入的 Token 數量（用來估算成本和偵測異常——突然大量上傳可能代表有人在批次處理敏感資料）、輸出是否通過人工審核、是否有安全告警觸發、以及使用的模型版本。

日誌架構設計

根據組織規模和資源，飛飛建議分成三個層級來規劃。

簡單方案（適合 20 人以下的小團隊）：用 Google Sheets 或 Notion 資料庫做手動記錄。欄位就是上面的五個基本欄位，每次使用 AI 處理非公開資料時填寫一筆。這個方案的建置成本幾乎為零，但缺點是依賴員工自律，漏報率高。飛飛建議搭配「每週快速檢視」——每週花 10 分鐘掃一下紀錄，看有沒有明顯的空白期或異常。如果某個員工整週都沒有紀錄，但你知道他的工作一定會用到 AI，那可能代表他沒有填寫。

實作建議：在 Google Sheets 中用資料驗證功能限制欄位的輸入值（例如工具名稱用下拉選單、資料等級用下拉選單），避免自由填寫造成的格式不一致。可以設定一個 Google Apps Script 定時檢查，如果某個員工連續三天沒有新紀錄就發提醒郵件。

中階方案（適合 20-200 人的企業）：用企業版 AI 工具的管理後台。ChatGPT Enterprise 和 Claude for Enterprise 都有管理員儀表板，可以看到使用量統計、活躍使用者、以及對話數量（但看不到對話內容）。搭配內部政策要求使用企業版帳號，可以掌握大部分的使用行為。

這個方案的關鍵在於「收攏」——確保員工使用的是企業版帳號。如果有些人用企業版、有些人用個人帳號，你從管理後台看到的數據就不齊全。飛飛建議在這個階段同時部署基本的網路監控，至少能偵測到有沒有流量流向未經核准的 AI 服務。中階方案的額外配置：設定瀏覽器擴充程式提醒員工在存取 AI 工具時使用企業帳號；在公司的 DNS 或 Proxy 設定中記錄對主要 AI 服務網域的存取日誌。

進階方案（適合 200 人以上的企業或有嚴格合規要求的產業）：整合 DLP、CASB 和 SIEM，建立自動化的偵測和告警機制。

進階方案的四層架構：

網路層：透過 Proxy 或 CASB（如 Netskope、Zscaler）攔截往 api.openai.com、api.anthropic.com 等 AI 服務的流量，記錄存取日誌。CASB 的優勢在於它可以識別「影子 AI」——員工使用的未經核准的 AI 服務。Netskope 在 2026 年已經內建了 AI 應用程式清單，可以自動分類和監控超過 300 種 AI 相關服務。

端點層：透過 Endpoint DLP（如 Microsoft Purview、Symantec DLP）偵測從端點裝置上傳到 AI 服務的敏感資料。偵測方式包括剪貼簿監控（偵測複製貼上的內容）和瀏覽器內容檢查（偵測在網頁表單中輸入的內容）。

應用層：透過 AI 工具的管理後台 API 或 Webhook 記錄使用行為。如果公司透過 API Gateway（如 LiteLLM、Portkey）統一管理 AI API 的呼叫，Gateway 本身就是最好的日誌來源——每一筆 API 呼叫都經過 Gateway，紀錄自動產生，不需要額外設定。

彙整層：所有日誌匯入 SIEM（如 Splunk、Elastic Security、Microsoft Sentinel）做關聯分析和告警。告警規則的範例：「如果某個使用者在一小時內上傳超過 50,000 個 Token 到 AI 服務，觸發告警」，或「如果偵測到信用卡號格式的資料被上傳到非企業版 AI 服務，觸發即時告警並阻擋」。

DLP 整合的實作細節

DLP（Data Loss Prevention）在 AI 稽核中的角色是自動偵測敏感資料的外流。設定得好，它可以在資料離開組織之前就攔截下來。

設定 DLP 規則的重點：定義敏感資料的模式。台灣常見的模式包括：

身分證字號：格式是一個大寫英文字母加上九位數字，第二位是 1 或 2（舊格式）。正規表達式大約是 [A-Z][12]\d{8}。注意 2020 年後新式統一證號的第二位也可以是 8 或 9。

手機號碼：09 開頭的十位數字，格式是 09\d{8}。

信用卡號：16 位數字，可用 Luhn 演算法驗證。注意要處理數字中間有空格或連字號的情況（例如 4111-1111-1111-1111）。

API Key 和密碼：以 sk-、ghp_、AKIA 等前綴開頭的字串，或是長度超過 20 個字元的隨機英數字組合。這類資料一旦外洩到 AI 服務，攻擊者可能從 AI 的訓練資料中提取出來。飛飛在滲透測試中就發現過從公開的 AI 服務回應中取得有效 API Key 的案例。

公司內部文件編號：每家公司有自己的格式，例如「PRJ-2026-」開頭的專案編號。這類規則需要客製化設定。

DLP 的限制：如果員工用手機拍螢幕再上傳、或把資料貼進 AI 的桌面應用程式而非網頁版，網路層的 DLP 就偵測不到。端點層的 DLP 可以補強，但也無法涵蓋所有情境。稽核不能只依賴技術手段，還需要政策和培訓配合。

DLP 的誤報處理：DLP 規則設定太寬鬆會漏掉真正的敏感資料，設定太嚴格會產生大量誤報，讓安全團隊疲於處理，最後乾脆忽略告警。飛飛的建議是先用「僅記錄」模式運行兩週，分析日誌中的誤報比例，根據結果調整規則，確認誤報率降到可接受範圍後，再切換到「記錄並阻擋」模式。

台灣法規對 AI 稽核的要求

除了前面提到的個資法第 27 條和施行細則第 12 條，還有幾個和 AI 稽核相關的法規要注意。

個資法第 29 條：如果因為未善盡安全維護義務導致個資外洩，企業要對當事人負損害賠償責任。有稽核紀錄可以證明企業已經採取合理的管理措施，在訴訟中是重要的抗辯依據。

金融業特別規範：金管會對金融機構的資訊安全有額外要求。金融資安行動方案要求金融機構建立資訊安全監控機制，包含日誌的收集、分析和保存。如果金融機構的員工使用 AI 處理客戶資料，稽核紀錄的要求會比一般產業更嚴格，日誌保存期限通常要求五年以上。

勞動基準法的考量：如果 AI 稽核機制涉及監控員工的工作行為（例如追蹤員工的 AI 使用頻率和時間），需要注意勞動隱私的界限。飛飛建議在 AI 使用政策中明確告知員工有稽核機制的存在、追蹤的範圍、以及資料的用途。「事前告知」是關鍵——如果員工不知道自己的 AI 使用行為會被記錄，事後拿出日誌來追究責任可能會引發勞資爭議。

資通安全管理法：適用於政府機關和關鍵基礎設施提供者。如果你的組織屬於這個範圍，AI 工具的使用紀錄需要符合資通安全管理法的稽核要求，包含日誌保存和定期稽核的義務。

ISO 27001 的延伸：雖然不是法規，但很多台灣企業已經取得 ISO 27001 認證。ISO 27001:2022 版本中對日誌管理和存取控制的要求，可以延伸到 AI 工具的使用管理。如果企業有 ISO 27001 的義務，AI 使用稽核可以整合到現有的資安管理體系中。

稽核報告格式

月報建議包含六個區塊。

總覽：當月 AI 使用次數、活躍使用者數、使用的工具分布（哪些工具最常被使用）、部門使用量排名。用圖表呈現會比純數字更直觀。飛飛建議用長條圖顯示各部門的使用量，用趨勢圖顯示月度變化。

安全事件：當月偵測到的安全事件清單，包含時間、類型、影響範圍、處理狀態。事件類型可以分成幾類：敏感資料上傳（最常見）、使用未核准工具、違反資料分級規定、其他政策違規。每個事件都要有處置結果和後續追蹤。即使當月沒有事件，也要明確記錄「本月無安全事件」。

政策遵循：抽查結果，包含合規率和主要違規類型。建議每月至少抽查 10% 的使用紀錄。抽查的方式：隨機抽取一些紀錄，檢查使用的工具是否在核准清單上、資料分類是否正確、是否遵守人工審核的要求。

成本分析：如果使用的是按量計費的 AI 服務（如 API 呼叫），追蹤每月的費用變化和各部門的分攤。突然的費用暴增可能代表有人在大量使用，值得了解原因。

趨勢分析：與前月的對比，標注異常變化（例如某部門的使用量突然暴增、新出現的未核准工具）。趨勢分析的價值在於發現緩慢惡化的問題——如果每個月的敏感資料上傳次數都在增加，單看某一個月的數據可能不覺得嚴重，但看到趨勢就知道需要介入。

建議事項：根據數據提出的改善建議，例如「建議針對財務部門加強資料分類培訓」「建議評估是否需要將某工具加入核准清單（本月有 15 位員工嘗試使用）」。建議要具體、可執行，不要只寫「加強管理」這種空話。

安全考量

稽核日誌本身是敏感資料。日誌中可能包含員工的使用行為紀錄、處理的資料類型、甚至部分輸入內容的描述。這些日誌的存取權限要限制在資安團隊和管理層，一般員工不應該能看到其他人的使用紀錄。飛飛見過一個案例，某公司的 AI 使用日誌存放在一個共用的 Google Drive 資料夾中，任何員工都可以看到其他人的使用紀錄，包含他們用 AI 處理了什麼類型的資料，這本身就構成了隱私問題。

日誌的完整性保護。稽核日誌如果可以被修改或刪除，就失去了證據價值。飛飛建議使用 append-only 的日誌系統——只能寫入不能修改或刪除。技術實作的方式包括：使用 WORM（Write Once Read Many）儲存、將日誌寫入有完整性驗證的日誌服務（如 AWS CloudTrail Logs）、或至少設定嚴格的存取控制讓日誌管理員和日誌產生者的權限分離。

日誌保留期限。台灣個資法對日誌保留期限沒有明確的統一規定，但個資法施行細則建議保留「足以供查核的期間」。飛飛的建議是一般企業保留 1-3 年，金融業保留 5-7 年。太短可能在事件調查時找不到紀錄（有些資料外洩事件要幾個月後才被發現），太長則增加資料管理負擔和外洩風險。日誌超過保留期限後要確實銷毀。

員工隱私的平衡。過度監控會損害員工信任和降低使用意願。飛飛在企業培訓中常遇到員工問：「所以主管可以看到我跟 AI 聊了什麼？」這種擔憂是合理的。建議的做法是：事前告知員工有稽核機制（寫在 AI 使用政策裡，並在到職培訓時說明）、只記錄必要的後設資料（Meta Data）而非對話內容、以及用匿名化的統計數據做趨勢分析，只在發生安全事件時才查詢特定使用者的詳細紀錄。飛飛在培訓時常用的說法是：「這跟公司的門禁系統一樣，記錄誰在什麼時間進出大樓，不是在監控你在辦公室裡做什麼。」

稽核制度的有效性。不要為了稽核而稽核。如果蒐集了日誌卻從來沒有人看、沒有根據數據做改善，那這個制度就只是浪費資源。飛飛建議指定專人每月花 2-4 小時檢視日誌和產出報告。設定一個「稽核健康指標」：如果連續三個月的月報中沒有任何改善建議被執行，就代表稽核制度流於形式了。

稽核系統本身的安全防護。收集和儲存大量使用行為日誌的系統會成為攻擊者的目標——如果攻擊者入侵了稽核系統，他可以了解組織使用哪些 AI 工具、處理什麼類型的資料、甚至找到資安防護的缺口。稽核系統需要和一般的業務系統做網路隔離，並且定期做安全評估。

實作步驟建議

如果你的組織目前沒有任何 AI 稽核機制，飛飛建議分三階段推進。

第一階段（第 1-2 週）：盤點現況。了解組織中有多少人在使用 AI、使用了哪些工具、處理什麼類型的資料。可以用匿名問卷的方式收集初步數據。同時確認組織目前有沒有能涵蓋 AI 使用行為的日誌系統（例如既有的 Proxy 日誌或 CASB）。這個階段通常會發現一些意料之外的 AI 使用情況。

第二階段（第 3-4 週）：建立最簡可行的稽核機制。根據組織規模選擇上面三種方案中的一種。小團隊就先用 Google Sheet，中型企業就先把員工集中到企業版 AI 工具上。同時更新 AI 使用政策，加入稽核相關的條文（告知員工使用行為會被記錄）。

第三階段（第 2-3 個月）：試運行和調整。觀察稽核機制的運作狀況，調整日誌格式、收集頻率、報告內容。第一份月報產出後，評估資訊的有用程度——如果報告中的數據無法幫助你做出任何決策，那就需要調整收集的項目。

常見問題

小公司也需要做 AI 使用稽核嗎？

如果員工會用 AI 處理客戶資料或內部文件，就需要。規模可以很簡單：一個共享的 Google Sheet，欄位是日期、使用者、工具、資料類別、用途。每月花 30 分鐘看一下有沒有異常就好。飛飛的觀點是：稽核的核心目的是「出了事能查得到」，即使是最簡單的紀錄，也比什麼都沒有好太多。

員工會不會覺得被監控而抗拒？

事前溝通很重要。強調稽核的目的是保護公司和員工（資料外洩對員工個人也有風險，特別是如果外洩的是客戶個資，經手人可能面臨法律責任），而且只記錄後設資料、不看對話內容。讓員工參與政策制定也能降低抗拒感。飛飛曾在一家公司推動 AI 稽核時遇到員工的反彈，後來邀請員工代表加入稽核政策的討論小組，抗拒感大幅降低。

用免費版 AI 的話怎麼稽核？

免費版 AI 工具沒有管理後台，你看不到員工用了什麼。這正是為什麼企業應該提供企業版帳號：一方面資料處理有保障，另一方面管理者有可見度。如果預算有限，至少要有政策要求員工主動申報。另一個選擇是透過網路層的監控（CASB 或 Proxy）來偵測員工對免費版 AI 服務的存取，雖然看不到對話內容，但至少知道誰在什麼時間用了什麼工具。

稽核日誌被駭客入侵怎麼辦？

日誌應該和一般的業務資料分開存放，並設定獨立的存取控制。建議用 append-only 的日誌系統防止日誌被竄改。定期備份到離線儲存也是好做法。如果使用雲端的 SIEM 服務，確認服務商有通過 SOC 2 或 ISO 27001 認證。

有推薦的 AI 稽核工具嗎？

企業級：Microsoft Purview（整合 DLP 加稽核）、Netskope（CASB 加 AI 流量監控，在台灣有代理商）。中小企業：先用企業版 AI 工具自帶的管理後台。技術團隊可以用 Elastic Stack 自建日誌分析。在台灣，趨勢科技也有針對 AI 使用安全的解決方案，對於已經使用趨勢科技產品的企業，整合起來會比較順暢。沒有一個工具能解決所有問題，通常需要組合使用。

稽核紀錄可以作為員工懲處的依據嗎？

可以，但要注意幾個前提。第一，員工必須事先被告知有稽核機制的存在（不能事後才拿出來）。第二，稽核紀錄的收集方式必須合法（不能侵犯員工隱私）。第三，懲處的依據是員工違反了事先公告的 AI 使用政策，稽核紀錄只是證據。飛飛建議在政策和員工簽署的確認文件中明確寫出稽核的範圍和違規後果。

多久需要檢視一次稽核機制的有效性？

建議每半年做一次檢視。檢視的內容包括：日誌的覆蓋率（有沒有新的 AI 工具沒有被納入監控）、告警規則的準確率（誤報率和漏報率）、報告的實用性（產出的報告有沒有人看、有沒有根據報告做出改善）、以及法規的變化（有沒有新的合規要求需要調整稽核項目）。AI 工具的生態變化很快，每隔幾個月就有新工具出現，稽核機制需要跟上這個速度。

遠端工作的員工怎麼稽核？

遠端工作讓 AI 使用稽核變得更困難，因為員工不一定透過公司的 VPN 或 Proxy 上網。幾個做法：要求遠端員工連接 VPN 後才能存取公司資源和 AI 工具、使用端點層的 DLP 工具（安裝在員工電腦上，不依賴網路路徑）、或統一透過 AI Gateway 來路由所有的 AI API 呼叫。最實際的做法是提供企業版的 AI 工具帳號，然後透過管理後台來監控使用行為，這個方式不受員工的網路環境影響。

如果發現員工大量上傳敏感資料到 AI，該怎麼處理？

處理流程建議分四步。第一步，立即確認資料的類型和敏感度等級。第二步，如果是限制等級的資料（如身分證字號、信用卡號），通知資安團隊啟動事件回應程序，包括聯繫 AI 服務商要求刪除資料。第三步，和當事員工了解情況，確認上傳的動機和範圍。第四步，根據調查結果決定是教育還是懲處，同時檢討是不是政策或工具有需要改善的地方。飛飛的經驗是，大部分的敏感資料上傳事件都不是惡意的，通常是員工不知道某個資料屬於敏感等級，這代表培訓需要加強。

延伸閱讀

  • AI 治理框架：從政策到實踐的落地指南
  • 企業 AI 政策怎麼寫：從資安到使用規範
  • Shadow AI 是什麼？員工私用 AI 的風險管理