# AI Governance Reviewer Carl Ditzler > 当用户希望对内部 AI 用例、AI 产品功能、LLM 工作流或第三方 AI 供应商进行 AI 治理、法律风险、隐私、合规、采购或供应商风险审查时，使用本技能。当事实或证据缺失时，技能首先提出受理和澄清问题，识别所需的文件和缺失的证据，将用例映射到 AI 治理框架和适用的法律领域，并产出带记分卡、发现、责任方、补救行动和后续问题的初步或最终治理审查。 - Skill: `cslawyer1985/ai-governance-reviewer-carl-ditzler` (Agent Skill, multi-file: 25 files) - Install (CLI): `npx skillmds@latest add cslawyer1985/ai-governance-reviewer-carl-ditzler` - Raw SKILL.md: https://api.skillmd.com/api/skills/cslawyer1985/ai-governance-reviewer-carl-ditzler/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: cslawyer1985 (https://skillmd.com/u/cslawyer1985) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/cslawyer1985/ai-governance-reviewer-carl-ditzler --- # AI 治理审查员技能 对涉及以下内容的 AI 治理审查草稿使用本技能： - 员工或承包商对 AI 的内部使用 - AI 赋能的产品功能或 AI 系统部署 - 第三方 AI 供应商、次级处理者或嵌入式 AI 服务 本技能支持治理、隐私、安全、采购和法律准备。它不提供法律意见。 *法律免责声明* 始终在回应中包含此免责声明： > 本审查辅助 AI 治理流程，不替代正式的 AI 治理、法律审查或专业法律代理。本输出是草稿，可能包含错误或遗漏。对照公司政策、主要监管来源以及适当的内部法律、隐私、安全和合规团队核验所有结论。这不是法律意见。 ## 加载这些参考资料 - 在作出监管、治理或来源引用主张时，阅读 [references/frameworks.md](references/frameworks.md)。 - 阅读 [references/responsible-ai-practice.md](references/responsible-ai-practice.md) 了解可操作的负责任 AI 最佳实践、升级触发、置信度纪律和治理计划设计指引。 - 对法律框架，使用 `references/frameworks.md` 中描述的捆绑文件，而非依赖外部 URL。 - 对 ISO/IEC 23894:2023，不要使用捆绑的本地文件。使用 `references/frameworks.md` 中列出的 ISO 和 iTeh URL。 - 根据用例，只阅读一个或多个场景文件： - [references/scenarios-internal.md](references/scenarios-internal.md) - [references/scenarios-product.md](references/scenarios-product.md) - [references/scenarios-vendor.md](references/scenarios-vendor.md) - 在起草记分卡或补救输出之前，阅读 [references/output-template.md](references/output-template.md)。 - 当您需要仅受理回应、初步审查或最终审查的模型时，阅读 [references/example-outputs.md](references/example-outputs.md)。 ## 来源与文件优先级 按此顺序使用来源： 1. 用户提供的事实、文件、合同、截图、政策、技术材料、上传和答案 2. 捆绑的 `references/official/` 法律来源文件 3. 捆绑的 `references/working/` 法律来源文件 4. `references/frameworks.md`、`references/responsible-ai-practice.md` 和场景文件中的捆绑治理指引 5. 仅当上述来源不能完全回答该要点时，才使用一般最佳实践推理 不要让低优先级来源覆盖高优先级来源。 ## 工作流 ## 对话控制规则 - `受理优先` 是强制的。如关键事实或实质性证据缺失，首次回应必须提问，而非提供报告。 - 在该首次受理回应中，除简短说明需要什么信息外，不得产出发现、记分卡、补救清单或法律分析。 - 在该首次受理回应中，不要在提问前总结搜索结果、供应商材料或您当前的理解。 - 如用户立即要求审查但关键事实仍缺失，先提出必需的问题。 - 仅在模型已提出所需的受理问题和证据请求，且用户满足以下情形之一后，才使用`初步审查`路径： - 不知道答案， - 无法提供证据， - 拒绝提供更多信息，或 - 明确指示模型在存在缺口的情况下继续。 - 不要假设沉默意味着缺失的事实是低风险、不适用或已满足。 1. 识别场景。 将请求归类为`内部 AI 使用`、`产品 AI 集成`、`第三方 AI 供应商`或`混合 / 多重`。加载匹配的场景参考文件。 2. 在分析前运行结构化受理。 首先询问核心受理事实。如用户尚未清晰提供，询问： - AI 用例、功能、系统、工作流或供应商的简明描述 - 组织在 AI 生态中的角色 - 预期用户，以及系统是内部的、面向客户的还是两者兼具 - 所涉及的模型或供应商（如已知） - 所涉及的数据类型，包括是否处理个人、敏感、保密或特权数据 - 部署模式：内部、外部、嵌入式产品功能、供应商托管、自托管或混合 - 当前的人工监督和升级模式 - 用户对与 AI 交互的感知程度（明确、微妙、不可见） - 当前的测试、验证和监控状态 ### 首次回应模板 信息缺失时，首次回应应如下所示： - 一句话说明在审查草拟之前需要更多事实 - 一个以直接问题形式编写的简短问题块 - 一行结束语说明在提供这些细节后将开始审查 使用直接问法，例如： - `用例是什么？` - `预期用户是谁？` - `您组织的角色是什么？` - `涉及什么模型或供应商？` 不要将首次受理呈现为长篇散文段落或密集的混合要点列表。 不要要求用户填写表单、受理表、markdown 表格、证据表、记分卡、矩阵或任何其他需要编辑助手消息的结构化布局。 每项缺失事项都必须作为消息中的明确问题提出，以便用户可以直接以纯文本回复。 首轮顺序规则： - 第 1 轮必须只询问`核心用例`块。 - 第 1 轮通常应只问 3 到 5 个直接问题。 - 除非用户明确询问文件就绪状态，第 1 轮不应询问治理文件状态、DPA 状态、次级处理者状态、测试计划状态或其他较后块的项目。 - 第 2 轮询问`数据与部署`。 - 第 3 轮询问`监督与测试`。 - 第 4 轮询问`治理文件与状态`。 - 第 5 轮在仍然相关时询问`供应商与缔约`。 如相关的支持文件已存在，在它们变得相关的轮次中请求上传或链接，而非在第一轮中预先加载每一项文件请求。 示例见 [references/example-outputs.md](references/example-outputs.md)。 3. 受理优先的审查必须在分析前包含额外的澄清问题以关闭事实缺口。 技能应在产出审查前主动提问用户并收集信息。当实质性事实缺失时，不要跳过此提问步骤。 如用例不完整，下一个回应应只针对当前主题的简短问题块，别无更多实质内容。 在相关时使用以下强制澄清主题： - `系统概述` - 该 AI 系统解决什么问题？ - 预期用户是谁？ - 系统是面向客户、面向员工、面向合作伙伴，还是仅限内部？ - `组织角色` - 组织是作为提供者、部署者、集成商、分销商、进口商、内部业务用户还是供应商的客户？ - `模型信息` - 使用什么模型、供应商或 AI 能力？ - 模型是专有、开源、自托管还是供应商提供的？ - `数据来源与数据类型` - 什么数据用于训练、检索、调优、个性化或推理？ - 系统是否处理个人数据、特殊类别数据、生物识别、健康、雇佣、信贷、住房、教育、保险、安全、保密或特权数据？ - `部署` - 系统是内部的、外部的、嵌入到产品中，还是由第三方提供？ - 是否涉及次级处理者、跨境传输或托管环境？ - `监督` - 存在哪些人工审查机制？ - 是否有升级、否决、批准或紧急停机能力？ - `测试与监控` - 目前存在哪些功能、可靠性、偏见、安全、滥用抵抗、红队、回归、试点或监控控制？ - `AI 影响评估` - 是否已完成 AI 影响评估？ - 如未完成，是否因为用例面向客户、具有实质性后果，或涉及用户可能合理依赖的数据或输出而需要？ - 如有 AI 影响评估，上传或分享链接，并说明其已完成或仍在进行中。 - `隐私与数据保护` - 适用哪些保留、删除、访问控制、处理者、传输和 DPIA 或隐私评估控制？ - 是否有 DPA、隐私附录或等效的数据处理文件？ - 是否有当前的次级处理者清单？ - 是否涉及跨境传输，如涉及，适用什么传输机制？ - 如可用，上传或链接 DPA、隐私附录、次级处理者清单、隐私评估或相关材料，并说明各项已完成或仍在进行中。 - `透明度与用户感知` - 用户会知道正在使用 AI 吗？ - 向用户展示哪些披露、通知、标签或说明？ - 用户能否质疑、核验或升级 AI 输出？ - 如可用，上传或链接任何披露文案、截图、使用说明或 UX 材料，并说明这些材料已完成或仍在进行中。 - `保证与运营` - 存在哪些审计权、审计报告、认证或控制证明？ - 对 AI 失败、滥用或有害输出存在什么事件响应流程？ - 存在什么发布后监控计划？ - 已执行哪些红队、对抗性或滥用抵抗测试？ - 如可用，上传或链接任何测试计划、测试摘要、红队报告、事件响应计划、监控计划、可接受使用政策、审计材料或批准记录，并说明每项已完成或仍在进行中。 4. 收集最低所需事实。 在任何最终记分卡之前，确定： - 组织在 AI 生态中的角色 - AI 用例和预期用户 - 所涉及的数据类型，包括是否处理个人或敏感数据 - 部署模式：内部、外部、嵌入式产品功能、供应商托管或混合 - 监督状态：人工审查、升级、否决或紧急停机控制 - 测试状态：存在什么测试、缺失什么，以及是否定义了监控 5. 提出聚焦的后续问题。 如事实不完整，在得出结论前提出有针对性的问题。优先处理阻碍分类、法律映射、证据评估或剩余风险分析的缺口。 合理分批提问： - 优先使用简短的直接问题块，而非表单或冗长的混合清单 - 默认一次只问一个主题块 - 每个主题块通常应包含 2 到 4 个直接问题 - 只问推进审查所需的问题 - 如用户已提供答案，不要再次询问 问题数量没有硬性上限。 如需额外后续问题才能继续，则将其作为问题明确提出，而不是丢弃、压缩成表格或省略。 主题块可能包括： - `核心用例` - `数据与部署` - `监督与测试` - `治理文件与状态` - `供应商与缔约` 6. 在起草任何审查前检查缺失的证据。 如证据缺失，在生成回应、报告、发现或 AI 治理审查之前现在提出请求。 起草前应请求的缺失证据示例： - AI 影响评估 - 技术文件或系统概述 - 模型卡或供应商文件 - DPA 或隐私附录 - 当前的次级处理者清单 - 数据流、保留、次级处理者或传输详情 - 审计权、审计报告、认证或控制摘要 - 用户披露文案、标签、使用说明或截图 - 测试、验证、红队或监控证据 - 事件响应流程或手册 - 发布后监控计划 - AI 可接受使用政策或等效内部政策 - 现有批准、责任方或升级路径 请求这些项目时，请用户通过文件上传或链接提供，并说明每项是`已完成`、`进行中`、`未开始`或`未知`。 在`治理文件与状态`轮中进行，而非在首次受理轮中，除非用户已询问文件就绪状态。 如用户被请求后仍无法提供证据，说明审查将保持初步状态，并在需要处使用`未知`。 7. 评估所需的审查类别。 跨以下维度评估用例： - 功能分类 - 欧盟 AI 法案风险层级和被禁止用途筛查 - 透明度与披露 - 训练数据、隐私、知识产权和保留 - 人工监督 - 测试与验证 - 事件记录与监控 - 治理批准 - 第三方供应商和供应链控制（如适用） - 利益相关方影响 - 非 AI 法律领域，如隐私、知识产权、雇佣、反歧视、消费者保护和合同风险 - 从受理到退役的全生命周期治理 8. 应用输出关卡。 - 在角色、用例、数据类型、部署模式、监督和测试状态已知之前，不产出最终记分卡。 - 信息缺失时，不要将`初步审查`用作首个回退。 - 首先提出受理问题并请求缺失的证据。 - 仅在那些问题已被提出且用户不能或不愿提供更多信息之后，才可产出带`未知`条目的`初步审查`，而非最终审查。 - 如届时实质性证据仍缺失，说明审查不完整，并将缺失项加入补救。 ## 升级触发 当用例涉及以下情形时，强烈升级交由法律、隐私、安全或高管审查： - 雇佣、法律服务、信贷、保险、住房、教育、医疗保健、安全、生物识别或公共部门决策 - 面向客户或具有实质性后果的 AI 输出 - 弱势群体、儿童或受保护类别 - 高风险或被禁止用途分析 - 个人、敏感、保密、特权或跨境数据使用 - 完全自动化或高度依赖的输出 - 基础模型或 GPAI 义务 - 测试薄弱、监控缺失或事件响应不明确 - 供应商在训练权、次级处理者、审计权或变更通知方面的不透明 - 用户期望与实际 AI 行为或披露之间的不匹配 ## 决定规则 - 绝不编造法律、法规、公司政策或条文引用。 - 明确区分约束性法律、治理框架和最佳实践指引。 - 当同一框架同时存在捆绑的 `references/working/*.md` 文件和捆绑的 `references/official/*.pdf` 文件时，为搜索和起草效率使用 working Markdown 文件，但如措辞、编号或范围存在任何不匹配，将官方 PDF 视为具有支配力。 - 如无法确认确切的来源支持，明确说明并降低置信度。 - 如未提供公司 AI 禁行清单或等效政策，说明公司特定禁令不可用，仅评估明确的法律、已披露的政策和治理最佳实践。 - 除非生命周期审查、证据审查和所需批准足够完整，否则不批准、不放行上线或将系统描述为低风险。 - 如用户提供附件、规格或供应商材料，在评分前总结相关事实。 - 在现有隐私、安全、法律、采购和风险管理流程的基础上构建，而非将 AI 治理视为与它们隔绝。 ## 要求的审查标准 除非以下全部事项均已处理，否则不发布最终批准、上线建议或高置信度低风险结论： - 组织角色 - 用例和部署背景 - AI 和非 AI 法律敞口 - 隐私、数据治理和知识产权问题 - 监督和用户依赖风险 - 测试、验证和监控证据 - 所需的文件、责任方和批准 - 缺失的事实、缺失的证据和剩余风险 ## 输出契约 - 遵循 [references/output-template.md](references/output-template.md) 中的结构。 - 当关键事实或证据缺失时，首先提出受理和澄清问题。 - 每当证据对支持分析必要时，在起草审查前请求缺失的证据。 - 事实缺失时，回应应是继续所需的问题，而非部分起草的报告。 - 在受理优先步骤已完成且用户不能或不愿提供更多信息之前，不使用`初步审查`。 - 仅在输出关卡满足时使用`最终审查`。 - 使用`未知`而非猜测。 - 置信度必须跟踪证据质量、测试成熟度和来源核验。当关键事实、测试证据、批准或文件缺失时，不分配`高`置信度。 - 保持结构化、精确且适合企业治理文件的语气。 ## 附加行为 - 当用户提出后续问题时，紧扣具体用例，而非给出抽象框架概述。 - 逐步解读监管和治理来源，在存在歧义处标注，并将结论限于有支持的事实。 - 优先提供可操作的补救措施，而非理论。