审计 AI Agent/LLM…

当需要为 AI Agent 或 LLM 应用做监管合规审计（EU AI Act、GPAI、GDPR、NIST AI RMF、Colorado AI Act、HIPAA、ISO 42001）时，用只读方式扫描代码库找出合规缺口并生成定制化整改清单。

适用场景

解决思路

1. 开始前先逐字向用户展示法律免责声明：本审计仅供参考，不构成法律意见或完整合规评估，不能替代合格律师，必须聘请专业律师或合规专家做有约束力的评估。
2. 遵循核心原则：优先检查而非修改；产出开发者可执行的条目而非法律意见；按司法辖区和用例定制，不要堆砌整个监管框架；交叉核对埋点（合规需要审计轨迹）；提供整改但始终先确认，未经用户明确同意绝不改代码；输出简洁面向生产，除非被要求否则不生成额外文档；绝不嵌入明文凭据，始终引用环境变量，绝不要求用户把密钥粘贴到对话中。
3. Phase 0 第 1 步：用 AskUserQuestion 工具询问用户适用哪些合规框架，不要推断或自动选择，必须显式询问。选项为：1) EU 框架（EU AI Act、GPAI Code of Practice、GDPR，适用于终端用户或数据主体在 EU）；2) US 框架（NIST AI RMF、州法如 Colorado AI Act、NYC LL144、HIPAA 若处理健康数据）；3) ISO 42001（国际 AI 管理体系标准，适用于追求认证、全球运营或想要国际基线）。可多选。按选择加载对应参考文件：选 1 看 references/eu-ai-act-gpai.md；选 2 看 references/us-ai-compliance.md；选 3 看 references/iso-42001.md（注意 ISO 42001 是组织管理体系，只审计技术可审计控制项，纯组织条款单独标记）；多选则覆盖并集并交叉引用重叠部分。
4. Phase 0 第 2 步：用 AskUserQuestion 工具询问 AI 应用做什么，确定用例类别：通用聊天机器人/助手（EU 有限风险、US 一般义务）；招聘/HR（EU 高风险 Art. 6 Annex III、Colorado AI Act、若在 NYC 则 LL144）；医疗（EU 高风险、若处理 PHI 则 HIPAA）；信贷/金融（EU 高风险、Colorado AI Act）；教育（EU 高风险）；内容生成（EU Art. 50 透明度有限风险、US 一般义务）；GPAI 模型提供方（EU GPAI Code of Practice）。
5. Phase 0 第 3 步：根据用例和所选框架确定风险等级：EU 按 references/eu-ai-act-gpai.md 分类为不可接受/高/有限/最小；US 按 Colorado AI Act 分类为高风险（重大决策）或一般；ISO 42001 无正式风险分级，但标注系统是否高风险（会提升影响评估和偏见控制的优先级）。
6. Phase 0 输出：展示简要摘要，包含所选框架、用例、风险等级、适用法规与标准列表、ISO 42001 备注（若选中），然后直接进入 Phase 1。
7. Phase 1（只读，不写任何代码或创建文件）：系统扫描代码库，在七个域中查找合规证据与缺口，逐域运行搜索并记录发现。
8. 域 A 透明度与披露：在 UI 模板、API 响应和面向用户代码中搜索 `AI`、`artificial intelligence`、`automated`、`bot`、`machine learning`、`generated by`、`powered by` 等披露 AI 参与的字符串；检查 AI 生成输出（文本、图像、音频）的内容标注；检查代码库中的服务条款、隐私政策引用。关注信号：面向用户代码中完全没有 AI 披露，尤其当应用生成内容或做推荐时。
9. 域 B 数据保护与隐私：在 prompt、上下文或检索文档中搜索 PII 字段名 `email`、`phone`、`ssn`、`social_security`、`date_of_birth`、`address`、`name`；检查 trace span 属性中 `input.value` 或 `output.value` 是否可能含未脱敏个人数据发往 Arize；检查同意机制 `consent`、`opt-in`、`opt-out`、`gdpr`、`ccpa`；检查 DPIA 或隐私评估引用；检查数据保留与删除处理器；检查数据主体权利 `right_to_access`、`right_to_erasure`、`data_subject_request`、`data_protection_officer`。
10. 域 C 安全：检查 prompt 注入防御（输入校验、guardrail 库如 `guardrails-ai`、`nemo-guardrails`、`rebuff`、`lakera`、内容过滤、系统 prompt 保护）；检查数据防泄漏（返回用户前的输出扫描、敏感数据检测）；检查工具/函数调用控制（权限边界、允许列表、工具执行沙箱）；检查 AI 端点的限流与认证；检查硬编码密钥（源文件中 `api_key`、`secret`、`password`、`token` 字面量而非环境变量引用）。
11. 域 D 测试与评估：检查偏见与公平性测试（人口统计均等、影响比、公平性指标引用）；检查红队或对抗测试套件（prompt 注入测试、越狱测试）；检查评估框架（Arize evaluators、自定义 eval 脚本、基于 `pytest` 的 eval、实验基础设施）；检查 A/B 测试或模型对比基础设施。
12. 域 E 文档：检查模型卡（`MODEL_CARD.md`、`model_card.json`、`model_card.yaml` 或类似）；检查系统架构文档；检查 prompt 和模型更新的变更日志或版本跟踪；检查事件响应文档。
13. 域 F 监控与可观测性：检查 Arize 追踪设置（`arize-otel`、`register()`、`TracerProvider`、`opentelemetry`、`openinference` 导入）；若已有追踪，检查覆盖：所有 LLM 调用是否都被追踪（而非只有部分）、会话 ID 用于对话连续性、用户 ID 用于支持数据主体请求、错误跟踪与异常 span；检查告警与漂移检测配置；检查 trace 保留配置。
14. 域 G 供应商管理：检查第三方 AI API 使用（OpenAI、Anthropic、Google、Azure、Bedrock、Cohere 导入或客户端实例化）；检查模型版本是否固定（如 `gpt-4-0613`）还是用 `latest`/未版本化标识；检查供应商之间的回退与故障转移逻辑。
15. Phase 1 输出第 1 部分——摘要表：按域 A–G 列出证据发现、识别缺口、评级（Compliant / Partial / Non-compliant / N/A）。
16. Phase 1 输出第 2 部分——缺口详情（每个 Non-compliant 或 Partial 评级都必须有）：为每个此类域写专门小节，包含 1) 精确代码路径：文件路径、行号和展示缺口的相关代码片段，不要转述，引用实际代码；2) 为什么在这个具体应用中重要：结合代码库解释具体风险（哪些工具可能被滥用、哪些数据流暴露、攻击者或监管者会发现什么）；3) 缺失什么：精确描述应存在但不存在的控制或代码（如“一个在 OTLP exporter 触发前对 `user_email` 做哈希的 span 属性处理器”，而不只是“加 PII 脱敏”）。每个 Non-compliant/Partial 域至少一个小节，不得省略——这是审计对工程团队的首要价值。然后直接进入 Phase 2。
17. Phase 2：用 Phase 1 发现和 references/compliance-checklist-template.md 模板生成定制化合规清单。生成规则：1) 只包含相关章节——US-only 跳过 GDPR 项，非医疗跳过 HIPAA，非 NYC 招聘跳过 LL144；2) 标记 Phase 1 条目——有证据的标 `Compliant`，有缺口的标 `Non-compliant` 并给具体整改建议；3) 正确排优先级——Critical=执法风险或系统禁止，High=法规要求，Medium=框架推荐，Low=最佳实践；4) 整改要具体——不说“实现输入校验”，而说“添加 `guardrails-ai` 之类的 guardrail 库，按内容策略校验 LLM 输入输出”；5) 包含模板中的埋点交叉引用表，若未设置 Arize 追踪则标为 Critical 缺口（EU Art. 12 和 NIST MAN-2.1 要求审计轨迹）。
18. Phase 2 最终报告：呈现单一整合报告含四节——第 1 节审计范围（Phase 0 摘要：所选框架、用例、风险等级、适用法规）；第 2 节代码库发现（Phase 1 摘要表 A–G 含证据、缺口、评级）；第 3 节缺口详情（Phase 1 展开，每个 Non-compliant/Partial 域一小节，含精确文件路径行号、引用代码片段、应用特定风险解释、缺失内容的精确描述，此节强制不得省略）；第 4 节合规清单（Phase 2 定制清单含状态与整改建议、埋点交叉引用表、优先级摘要、建议后续步骤）。用户要求报告文件时，写单个 markdown 文件到 `/tmp/<app-name>-compliance-audit-<YYYY-MM-DD>.md` 含全部四节。呈现报告后提供 Phase 3 整改。
19. Phase 3（可选整改）：呈现清单后提供实施具体修复。改任何东西前始终用 AskUserQuestion 工具确认。整改类别：添加依赖——提供安装 guardrail 库（如 `guardrails-ai`、`nemo-guardrails`）、PII 检测/脱敏包（如 `presidio-analyzer`、`scrubadub`）、内容安全分类器；插入代码——提供添加面向用户输出（模板、API 响应）的 AI 披露字符串、导出到 Arize 前对 span 属性做 PII 脱敏过滤器、AI 端点输入校验/净化、trace span 上的用户 ID 属性以支持数据主体请求；创建文档模板——提供脚手架模型卡模板（含标准章节的 markdown 文件）、事件响应计划模板、数据处理记录模板；配置监控——通过相关技能设置 Arize evaluators 做偏见检测和内容安全（经 `arize-evaluator` 技能）、追踪审计轨迹覆盖（经 `arize-instrumentation` 技能）。
20. Phase 3 整改规则：每个整改作为离散、可确认的动作呈现，绝不批量应用；先展示确切变更（文件、代码 diff 概念），再用 AskUserQuestion 工具获确认后才应用；遵循现有代码风格和项目约定；绝不嵌入凭据，始终用环境变量；变更后测试应用仍能构建。
21. 技能编排：当 Phase 1 或 2 识别的缺口需要其他 Arize 技能能力时，提供调用。调用另一技能前始终用 AskUserQuestion 工具询问并解释为何与合规缺口相关。映射：无追踪/审计轨迹不完整→`arize-instrumentation`（EU Art. 12 和 NIST MAN-2.1 要求事件日志）；无偏见或安全评估→`arize-evaluator`（创建 LLM-as-judge 评估器做公平性、内容安全或质量监控）；需要导出 trace 作合规证据→`arize-trace`（导出 span 用于监管文档或事件调查）；高风险决策需人工审查→`arize-annotation`（按 EU Art. 14 设置人工监督标注队列）；需要深链接分享合规证据→`arize-link`（生成指向特定 trace、span 或评估的 URL 供利益相关者审查）。
22. 埋点交叉引用：若已设置 Arize 追踪，验证其满足合规要求——审计轨迹需所有 LLM span 含输入/输出（验证所有 LLM 客户端调用都被埋点而非部分）；数据主体访问请求需 span 上的用户 ID 属性（检查 `user.id` 或自定义用户标识属性）；trace 中的 PII 需检查 `input.value`/`output.value` 是否含敏感数据（若 PII 未脱敏通过则标记）；事件调查需含完整上下文的错误 span（检查异常跟踪和 span 错误状态）；保留要求需 trace 数据保留规定期限（EU：高风险至少 6 个月；HIPAA：6 年）；偏见监控需人口统计或群体属性（检查支持公平性分析的元数据属性）。若未设置 Arize 追踪，这是重大合规缺口，提供：“要我运行 `arize-instrumentation` 技能来设置审计轨迹追踪吗？监管框架（EU AI Act Art. 12、NIST AI RMF MAN-2.1）要求 AI 系统事件日志。”
23. 参考链接：EU AI Act 全文 https://eur-lex.europa.eu/eli/reg/2024/1689/oj；GPAI Code of Practice https://digital-strategy.ec.europa.eu/en/policies/contents-code-gpai；Code of Practice 门户 https://code-of-practice.ai/；NIST AI RMF https://www.nist.gov/artificial-intelligence/ai-risk-management-framework；Colorado AI Act (SB24-205) https://leg.colorado.gov/bills/sb24-205；NYC Local Law 144 https://www.nyc.gov/site/dca/about/automated-employment-decision-tools.page；HIPAA https://www.hhs.gov/hipaa/index.html；ISO/IEC 42001:2023 https://www.iso.org/standard/42001.html；Arize AX Docs https://arize.com/docs/ax。
24. 参考文件：references/eu-ai-act-gpai.md（EU AI Act 和 GPAI Code of Practice 开发者指南）；references/us-ai-compliance.md（美国合规全景：NIST AI RMF、Colorado、NYC LL144、HIPAA）；references/iso-42001.md（ISO/IEC 42001:2023 AI 管理体系开发者指南，仅技术可审计控制项）；references/compliance-checklist-template.md（Phase 2 输出可复用清单模板）。

适用边界 · 注意事项

• 本审计仅供参考，不构成法律意见或完整合规评估，不能替代合格律师——有约束力的评估必须聘请专业律师或合规专家。
• ISO 42001 是组织管理体系，本审计只覆盖技术可审计控制项，纯组织条款（领导层评审、内部审计）只标记不做代码审计。
• 整改阶段未经用户通过 AskUserQuestion 明确确认，不得修改任何代码或批量应用变更。