要用 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 起草内部政策并标记审批：从依据台账到版本签核