要用 AI 草擬內部政策，先確定政策的授權依據、負責人、獲批原始資料、適用範圍和受影響角色。只讓 AI 草擬這些資料能支持的陳述，並為每項有後果的規則附上審批類別、審批人、狀態、例外負責人和覆核日期。AI 可以整理文字，但不能決定法律要求甚麼、誰有權限，或政策是否已獲批准。

這是通用使用 AI 方法的受管治應用，產出可供審核的政策候選稿，而不是 SOP 或風格指南。AI 輔助的 SOP 或檢查清單把獲批規則轉為可重複的操作；帶人工審批的 AI 工作流程管理範圍更廣的輸入和決定。本文的交付成果是政策本身，以及一份可追溯的審批矩陣。

關鍵要點

草擬規則前，先寫明授權依據和問責負責人。

凍結獲批證據包，讓衝突保持可見。

分清強制規則、指引、例外和未決問題。

為有後果的條款指定審批類別和具名審批人。

絕不讓 AI 聲稱某條款屬法律要求或已獲批准。

只在完成有版本、與角色相稱的簽核後才採納政策。

內部政策的權威從哪裏來？

政策需要可問責的授權來源：董事會或管理層決定、經合資格法律顧問解釋的法律、合約、監管責任、風險決定、僱傭框架、保安標準，或其他經正式批准的授權。來源必須具體到審核人能夠核實。「最佳做法」或「AI 建議」都不是政策授權。

NIST AI 風險管理框架核心以政策、流程、程序和實務組織管治，並在整個生命周期明確問責、記錄角色。［1］NIST 生成式 AI 設定檔補充了生成式系統特有的風險和行動。［2］它們是有用的管治參考，但不會替你委任審批人，也不會把自願框架變成法律責任。

草擬前先建立授權登記冊：

Authority ID	來源	適用對象	負責人	詮釋狀態
A-01	獲批的管理層決定	具名業務單位	高層發起人	已確認
A-02	經法律顧問審核的要求	具名司法管轄區及活動	法律部	已確認／有爭議
A-03	保安風險決定	具名系統及數據	保安負責人	已確認
A-04	合約條款	具名協議及訂約方	合約負責人	已確認／已屆滿

不要把享有法律專業保密權的意見、僱員紀錄、客戶資料、機密協議或保安細節貼到未獲批准的工具。只提供最少量的去敏陳述，受控來源參照留在機構紀錄系統內。

如何確定範圍、角色及政策結構？

寫明政策涵蓋誰、甚麼、在哪裏、何時適用：組織、員工類別、系統、數據類別、地點和生效條件，以及重要的排除項目。只寫「所有用戶」卻不界定用戶，會令執行標準不一。

NIST SP 800-18 Rev. 2 把記錄系統保安計劃、角色、職責和控制列為系統層面規劃的一部分。［3］借用這個原則即可，毋須假裝每份內部政策都是系統保安計劃：範圍和責任應清晰到足以落實和審核。

採用穩定的骨架：

目的及授權依據；
範圍及排除項目；
定義；
政策陳述；
角色及職責；
例外及上訴；
監察及執行；
紀錄及保存；
覆核周期及變更控制；
審批及生效日期。

政策應以結果為本；詳細的按鈕操作、腳本和日常工作次序通常屬於程序文件。內容風格指南可以管理語氣和術語，但不應在不知不覺間成為私隱、僱傭、財務或保安規則的授權依據。

如何用 AI 草擬內部政策，只寫有依據的條款？

把骨架、已去除敏感資料的授權依據、已定義術語和條款台帳交給模型。要求它只根據這些輸入草擬，欠缺證據時保留空白欄位。

你正在草擬供審核的候選稿，而不是在創設授權。

就每項政策條款：
- 引用一個或多個 Authority ID；
- 分清強制規則、指引、例外和未決問題；
- 嚴格使用已定義術語；
- 除非所提供、經法律顧問批准的依據明確如此，否則不得聲稱某規則屬法律要求；
- 不得明示或暗示任何條款已獲批准；
- 標示衝突、欠缺的範圍、未界定的角色和執行缺口；
- 只提出建議的審批類別，絕不作最終審批決定。

每項條款只寫一個可執行的意思。用常見字詞、直接動詞、短句和具體條件。GOV.UK 的清晰語言指引建議使用淺白字詞，避免不必要的行話。［4］含糊的政策看似靈活，實際卻把難做的決定推給個別員工。

除非授權依據確實訂下絕對規則，否則避免「一律」「絕不」「零風險」這類絕對字眼。避免隱藏行為人的被動句。「申請須經審核」不及「私隱負責人在批准前審核申請」有力。

如何標示衝突及未知項目？

不要讓 AI 挑一句最方便的話去調和互相衝突的依據。記錄衝突、受影響條款、負責人和需要作出的決定。在草稿中使用 UNRESOLVED-U03 這類可見標記，而不是匯出時可能消失的註解。

把缺口分類：

授權缺口： 沒有獲批來源支持擬議規則；
範圍缺口： 受影響的人員、系統、地點或日期不清楚；
角色缺口： 沒有指定問責負責人或獲授權審批人；
控制缺口： 機構暫時無法落實或監察該規則；
衝突： 兩個獲批來源要求不同結果；
證據時效缺口： 來源可能已被取代或已屆滿。

模型可以提出問題，但必須由負責的領域負責人回答。如果某個缺口妨礙安全詮釋，就把該條款從待採納版本中移除，或在解決前標示為不生效。

如何建立政策審批矩陣？

按每項條款的後果分配審核責任。同一份政策可能需要就法律詮釋、個人資料、保安控制、員工責任、開支權限、營運可行性和管理層風險接受分別審批。

使用以下範本：

Policy ID	Authority	Scope	Rule	Rationale / evidence	Owner	Approval class	Approver	Status	Exception owner	Review date
P-01	A-01	財務角色	規則草稿	決定紀錄	財務負責人	財務	具名角色	Draft	財務總監授權代表	日期
P-02	A-02	僱員數據	規則草稿	法律顧問意見	私隱負責人	法律 + 私隱	具名角色	Needs review	私隱主管	日期
P-03	A-03	生產系統	規則草稿	風險決定	保安負責人	保安 + 營運	具名角色	Draft	保安主管	日期

訂明容許的狀態值，例如 Draft、Needs evidence、Needs domain review、Approved、Rejected、Superseded 和 Effective。AI 不得設定 Approved 或 Effective，這些值必須由獲授權角色作出有紀錄的決定。

審批類別只是分流資料，不是結論。標示為「法律 + 私隱」的條款並未通過任何一項審核。審批人意見不一時，保留雙方決定和上報途徑，而不是要求 AI 折衷。

如何設計例外、上訴及執行？

例外流程應說明誰可申請例外、需要甚麼證據、誰可批准、最長期限、補償措施、續期規則和須保存的紀錄。除非已界定獲授權的管理角色和決策準則，否則不要寫「管理層可批准例外」。

當公平或獨立性有所要求時，上訴程序應與原決定分開。僱傭、紀律、私隱、財務和受規管的決定可能有特殊程序要求。應請合資格的內部審核人確認，不要用模型推斷。

執行字眼須與真實授權和營運能力相符。確認機構能傳達政策、培訓受影響角色、合法監察相關事件、保護紀錄並一致處理。某項控制尚未存在時，記錄為實施依賴，不要假裝政策能令它成真。

如何完成政策版本簽核？

以獨一無二的 Policy ID 和版本號凍結審核版本。向審批人提供草稿、授權登記冊、衝突紀錄、審批矩陣、例外設計和實施依賴。要求每位審核人記錄所審條款、決定、條件和日期。

使用簽核紀錄：

Policy ID 及版本：
審核範圍／條款 ID：
審批類別：
已核對的授權來源：
衝突或條件：
決定：批准/拒絕/修訂
是否有權訂定生效日期：是／否
審批人姓名及角色：
決定日期：
下次覆核日期：

批准後，核實發佈版本與簽核版本完全一致。生效日期應與草擬日期和批准日期分開記錄。連結實施程序、培訓和溝通資料，但不要把不穩定的操作細節寫進政策本身。

當授權依據、範圍、機構職責、風險、法律、合約或實施出現實質變化時，須重新審批。文法修正可走較簡便的受控程序，但意思有變就要再次取得相關領域批准。

草擬時應避免哪些常見錯誤？

把框架當作法律，或賦予它本身沒有的授權。［1］［2］
把政策結果與詳細程序、畫面操作指示混為一談。
用 AI 捏造理據、處分、保存期限或審批人。
因為所有欄位已填妥就標示為 Approved。
用更流暢的文字掩蓋衝突。
在例外和執行尚未具備營運條件時就發佈。
遺漏覆核日期、取代規則或版本識別。

總結

由真實的授權依據、具名負責人和明確範圍開始。
只草擬有證據支持的條款，保留缺口。
讓每項有後果的規則按審批類別分流。
清楚寫出例外、上訴、執行和實施安排。
只採納獲授權審核人簽核的那個確切版本。

常見問題

AI 能判斷政策是否屬法律要求嗎？

不能。AI 可以整理經法律顧問批准或其他具權威性的資料，但法律要求及其適用性，必須由合資格人員詮釋。

AI 能批准內部政策嗎？

不能。批准需要獲授權的人員角色和有紀錄的決定。模型可以建議審批分流，但無法提供機構授權。

政策與 SOP 有甚麼分別？

政策列明獲批的規則、結果、範圍和問責；SOP 說明落實獲批政策時使用的可重複步驟。

每項條款都應由同一人批准嗎？

不一定。法律、私隱、保安、僱傭、財務、營運和管理層方面的後果，可能需要不同領域分別審批。

未決問題應如何呈現？

為每個問題指定穩定 ID、負責人、受影響條款和需要作出的決定。不要把未決問題藏在註解中，也不要用看似合理的文字取代。

實施工作未全部完成時，政策能否生效？

只有在獲授權審核人明確接受這個安排，而政策亦寫明可行的生效條件時才可以。不要聲稱並不存在的執行能力。

內部政策應多久覆核一次？

按風險、授權依據變化、合約需要和機構慣例訂定覆核日期。出現實質變化時亦應觸發覆核，不要只等日曆到期。

本文是否屬法律或合規建議？

不是。本文描述的是一套草擬和審批控制方法。你的機構應視乎情況，取得合資格的法律、合規、私隱、僱傭、保安、財務和營運審核。

來源

Sources checked 2026 年 8 月 31 日。

NIST AI RMF, “Govern, Map, Measure, Manage” — https://airc.nist.gov/airmf-resources/airmf/5-sec-core/
NIST, “Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile” — https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence
NIST, “SP 800-18 Rev. 2: Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems” — https://csrc.nist.gov/pubs/sp/800/18/r2/final
GOV.UK Publishing, “Clear language” — https://guidance.publishing.service.gov.uk/writing-to-gov-uk-standards/writing-guidelines/clear-language/

延伸閱讀

**免責聲明：**本文提供關於草擬和審核控制的一般資訊，不構成法律、合規、僱傭、私隱、保安、財務或其他專業建議。

如何用 AI 草擬內部政策並標示審批：由依據台帳到版本簽核