AO2 FIELD GUIDE · N040 · 企業知識庫與治理
知識使用範圍需同時記錄資料對象、允許用途與核准責任。附分級工作表及輸出核對表，讓網站、業務與 AI 使用合適版本，並驗證實際存取。
文件可以被團隊閱讀，不表示它能直接放上網站、寄給客戶或交給外部 AI 工具。先為來源與衍生內容記錄可使用對象、用途、版本與核准責任，再由系統驗證實際權限；單靠一個「內部」標籤，無法完成所有控制。
知識使用範圍：先分開誰能看與可以拿來做什麼
某位業務有權閱讀研發文件，並不代表能把其中每一頁寄給客戶；公開規格可以對外引用，也不表示附帶的客戶註解可以一起發布。實務上需要至少兩個維度：存取對象與允許用途。對象可能是公開訪客、特定部門或指定合作團隊；用途可能是內部查詢、客戶提案、公開內容或 AI 檢索。兩者應各自有依據。
可再加上產品、專案、地區、有效日期與保留方式，但不要在第一天建立幾十種無人理解的等級。先選一條產品線，用常見任務試填：編輯要寫文章、業務要回答問題、AI 要找到來源。若不同角色對同一標籤有不同理解，就先調整定義，而不是急著把全公司文件一次貼標。
| 示意分類 | 允許對象與用途 | 發布前責任 |
|---|---|---|
| 公開核准 | 訪客可讀，限核准版本及表述 | 產品與內容責任人確認 |
| 內部工作 | 指定團隊查詢與協作 | 負責人確認外傳限制 |
| 專案限制 | 指定合作角色與約定用途 | 逐專案確認授權及分享 |
| 待確認 | 尚未判定來源或允許用途 | 先停止對外及 AI 輸出 |
標示是決策資料，實際控制要在使用工具中驗證
Microsoft Purview 的敏感度標籤可以用於分類與保護，保護行為取決於標籤、加密與相關環境的設定。這與在檔名加上「機密」不同。本文的分級表是組織工作範本，不會自動替任何系統建立存取限制，也不假設一種標籤能在所有第三方工具完整生效。
在選定工具後，應由管理者以不同角色測試：是否能開啟、搜尋、下載、分享及引用內容。不能只用最高權限帳號測一遍。若外部合作帳號不應看到資料，測試也要涵蓋已被分享到連結、匯出檔案或搜尋索引的衍生版本。控制是否成功，以實際使用結果與設定核對，不以工作表填滿為準。
來源含有限制資料時，公開摘要需有自己的核准紀錄
以下為假想電子產業情境。一份產品驗證文件同時包含可公開的功能描述、尚未公開的規格與特定客戶的測試配置。直接把整份文件標為內部，可以降低誤用，卻不能幫編輯快速取得可發布文字。較可維護的做法是由責任人建立核准公開摘要，保留它與原文件的來源關係及可用範圍。
公開摘要應有獨立版本和核准人，不能只把文件中的敏感句子刪除後就視為可用。刪除可能讓條件失去上下文，也可能仍留下可辨認客戶的型號組合或圖片。若無法完成核對，先用一般方法說明或空白範本，避免為了趕內容把尚未核准的資料當成素材。
| 輸出位置 | 需要帶出的資訊 | 實際驗收 |
|---|---|---|
| 網站文章 | 核准摘要版本與來源關係 | 正文與附件未帶入限制資訊 |
| 業務提案 | 對象、用途與可引用範圍 | 收件角色及檔案權限正確 |
| 翻譯素材 | 正式原稿、版本與禁止改寫內容 | 多語稿保留相同限制 |
| AI 檢索與回答 | 來源、版本與授權條件 | 不同角色的允許與拒絕題皆測試 |
AI 檢索要把範圍帶到回答之前
RAG 系統將文件轉成可檢索片段後，仍需保留來源 ID、版本與允許對象等資訊。只在回答最後要求模型「不要洩漏」，不能代替檢索階段的授權檢查。Microsoft 的 RAG 說明也把安全與治理列為重要挑戰，指出使用者與代理應只取回獲授權的內容。實際實作須依採用的系統能力驗證。
測試題應包含公開規格可答、內部註解不可對外答、缺少權限不能以摘要洩露，以及使用者改寫問題仍不能取得限制內容。被拒絕的內容也不應出現在引用標題、片段預覽或匯出紀錄中。本文不提供通用權限設定步驟，因為不同平台的身分、索引與分享機制並不相同。
讓責任與更新跟著內容移動
文件升級為可公開或改列限制時，應追查網站、提案、翻譯、客服答案與 AI 索引是否仍保留舊版本。資料等級調整不是只換一個欄位；還需確認已公開副本是否能撤回、哪些歷史資料需保留，以及誰負責對外說明。無法撤回的內容要如實記錄，不把主檔已改標籤當作所有副本已修正。
生技製藥合作資料尤其可能同時涉及企業內部方法、合作方素材與產品敘述。編輯先取得指定用途可使用的版本，不把「合作夥伴提供」等同「可公開發布」。需要正式資格、產品效能或客戶名稱的內容，仍交由相應責任角色確認。這是資料使用與內容核准的分工，不是對特定法規適用性的判定。
常見問題
可以只分公開與機密兩類嗎？
可以從少量分類開始，但每類都要對應實際動作。至少寫清可使用對象、用途、公開或下載限制、核准人與例外申請方式。若內部一般資料和僅限特定專案的資料需要不同權限，兩類就可能不夠。用真實任務測試員工、合作夥伴與外部訪客各能取得什麼；若分類名稱相同卻應有不同限制，應補充規則或拆分，而不只是新增標籤。
文件已放內部雲端就安全了嗎？
不能只憑位置判定。檢查群組成員、外部帳號、分享連結、下載權限與離職或結案後的存取安排，並用不同權限帳號實測。文件若接入搜尋或 AI，也要確認索引與回答沿用原本限制，不能在集中後變成所有人可讀。保存資料負責人與定期回查紀錄；出現不明分享範圍時，先交由管理者確認，避免只把資料搬進另一個雲端資料夾就視為完成。
先去識別再交給 AI 就一定可用嗎？
不能一概保證。去掉姓名後，產品批次、專案日期、稀有事件或多個欄位組合仍可能辨識對象；資料也可能包含未公開技術或商業內容。先確認使用目的與必要欄位，再核對工具的資料處理條件、存取與組織政策。以最少必要資訊完成任務，保留核准紀錄；無法確認可用範圍時交資料負責人判定。這是工作流程建議，不代替特定法域或契約要求的專業判斷。
來源與方法範圍
查核日期：2026 年 10 月 22 日。官方資料僅支持文中對應的平台或方法說明；工作表、決策步驟與核對方式為 AO2 編輯整理。產業情境依文中標示作假想示例，不作客戶實績、產品資格或效果背書。
