arize-compliance-audit

Arize 合规审计技能

当用户希望审计其 AI Agent 或大模型应用是否符合监管要求时，使用此技能。该技能会扫描代码库以查找合规缺口，交叉核对 Arize 埋点是否覆盖审计追踪，并生成量身定制的检查清单，可选提供修复方案。

触发语句：“审计我的应用是否合规”“EU AI Act 要求”“NIST AI RMF 检查清单”“AI 的 GDPR”“我的 AI 应用是否合规”“合规检查清单”“监管审计”“ISO 42001”“AI 管理体系”“AIMS 认证”。

免责声明

开始任何操作前，先向用户逐字呈现此免责声明：

---

⚠️ 法律免责声明

本次审计仅供参考，不构成法律建议，也不是完整的合规评估。本审计根据公开的监管框架识别常见技术模式和缺口，但无法评估贵组织的具体法律义务、合同承诺、数据处理协议或运营流程。

请勿将此结果作为替代合格法律顾问的依据。 监管合规认定复杂、因司法管辖区而异，并且取决于具体事实。请务必聘请合格律师或合规专家进行具有约束力的评估。

---

核心原则

• 优先检查，而非修改——提出更改建议前，先了解代码库。
• 务实，不作法律判断——提供开发者可执行的事项，而非法律意见。
• 根据司法管辖区和使用场景量身定制——聊天机器人和招聘工具的义务不同。不要罗列整个监管框架的所有内容。
• 交叉核对埋点——合规需要审计追踪；检查 Arize 跟踪是否捕获了监管机构预期的信息。
• 始终提供修复方案，但务必先确认——呈现检查清单后，提出实施具体修复的选项，但未经用户明确确认，绝不修改代码。
• 保持输出简洁并以生产环境为导向——除非用户要求，否则不要生成额外的文档或摘要文件。
• 绝不嵌入实际凭据值——始终引用环境变量。绝不要求用户在编码 Agent 聊天中粘贴机密信息。

阶段 0：框架选择与使用场景

扫描代码前，先确定适用的合规框架。

步骤 1 — 框架选择

使用 AskUserQuestion 工具询问用户适用哪些框架。不要推断或自动选择——务必明确询问。

询问：

Which compliance frameworks should this audit cover?
Select all that apply (reply with numbers, e.g. "1, 3"):

1. EU frameworks — EU AI Act, GPAI Code of Practice, GDPR
   (choose if end-users or data subjects are located in the EU)

2. US frameworks — NIST AI RMF, state laws (Colorado AI Act, NYC LL144),
   HIPAA (if processing health data)
   (choose if operating in the United States)

3. ISO 42001 — International AI Management System standard
   (choose if pursuing ISO 42001 certification, operating globally,
   or wanting an internationally recognised baseline)

You can select any combination. If unsure, select all that seem relevant
and we can narrow down during the audit.

根据所选框架：

• 选择 1 — 适用 EU AI Act、GPAI Code of Practice、GDPR。参见 references/eu-ai-act-gpai.md。
• 选择 2 — 可能适用 NIST AI RMF、Colorado AI Act、NYC LL144、HIPAA。参见 references/us-ai-compliance.md。
• 选择 3 — 适用 ISO 42001 AIMS 控制措施。参见 references/iso-42001.md。注意：ISO 42001 是组织管理体系——本次审计仅涵盖可通过技术手段审计的控制措施；纯组织性条款（领导层评审、内部审计）将另行标出。
• 选择多个 — 所选框架均适用；审计将涵盖各项要求的并集，并在框架要求重叠处提供交叉引用。

步骤 2 — 确定使用场景类别

使用 AskUserQuestion 工具询问：你的 AI 应用有什么用途？

• 通用聊天机器人 / 助手 — 有限风险（EU），一般义务（US）
• 招聘 / HR — 高风险（EU 第 6 条、附件 III）；适用 Colorado AI Act；若涉及 NYC，则适用 NYC LL144
• 医疗保健 — 高风险（EU）；若处理 PHI，则适用 HIPAA
• 信贷 / 金融 — 高风险（EU）；适用 Colorado AI Act
• 教育 — 高风险（EU）
• 内容生成 — 有限风险（EU 第 50 条透明度要求）；一般义务（US）
• GPAI 模型提供商 — 适用 GPAI Code of Practice（EU）

第 3 步 — 确定风险等级

根据使用场景和所选框架：

• 已选择 EU：根据 references/eu-ai-act-gpai.md 将其分类为不可接受、高、有限或极低风险
• 已选择 US：分类为高风险（根据 Colorado AI Act，涉及重大影响的决策）或一般风险
• 已选择 ISO 42001：风险等级不是 ISO 42001 中的正式分类，但请注明该系统是否属于高风险领域（这会提高影响评估和偏见控制的优先级）

阶段 0 输出

简要总结：

Frameworks selected: {EU / US / ISO 42001 / combination}
Use case:            {category}
Risk tier:           {EU tier if applicable} / {US tier if applicable}
Applicable:          {list of specific regulations and standards}
ISO 42001 note:      {if selected} Audit covers technically-auditable controls only;
                     organisational clauses will be flagged but not code-audited.

然后直接进入阶段 1。

阶段 1：代码库审计（只读）

本阶段不要编写任何代码或创建任何文件。

系统地扫描代码库，检查七个领域的合规证据和差距。针对每个领域，运行列出的搜索并记录发现。

A. 透明度和披露

检查内容：

• 面向用户的字符串中是否披露了 AI 的参与：在 UI 模板、API 响应和面向用户的代码中搜索 AI、artificial intelligence、automated、bot、machine learning、generated by、powered by 等术语
• 内容标注：AI 生成的输出（文本、图像、音频）上是否有标记
• 代码库中是否提及服务条款和隐私政策

风险信号： 面向用户的代码中完全没有披露 AI 的参与，尤其是在应用会生成内容或提供建议时。

B. 数据保护和隐私

检查内容：

• 代码中的 PII 字段名称：在提示词、上下文或检索到的文档中搜索 email、phone、ssn、social_security、date_of_birth、address、name
• Trace span 属性中的 PII：检查发送到 Arize 的 input.value 或 output.value 是否可能包含未经脱敏的个人数据
• 同意机制：检查是否提及 consent、opt-in、opt-out、gdpr、ccpa
• 是否提及 DPIA 或隐私评估
• 数据保留和删除处理程序
• 数据主体权利：right_to_access、right_to_erasure、data_subject_request、data_protection_officer

C. 安全

检查内容：

• 提示词注入防御：输入验证、防护栏库（guardrails-ai、nemo-guardrails、rebuff、lakera）、内容过滤、系统提示词保护
• 数据泄露防护：返回给用户前扫描输出、检测敏感数据
• 工具/函数调用控制：权限边界、允许列表、工具执行沙盒
• AI 端点上的速率限制和身份验证
• 硬编码密钥：源文件中的 api_key、secret、password、token 字面值（而非环境变量引用）

D. 测试和评估

检查内容：

• 偏见和公平性测试：提及人口统计均等、影响比率、公平性指标
• 红队或对抗性测试套件：提示词注入测试、越狱测试
• 评估框架：Arize 评估器、自定义评估脚本、基于 pytest 的评估、实验基础设施
• A/B 测试或模型比较基础设施

E. 文档

检查内容：

• 模型卡：MODEL_CARD.md、model_card.json、model_card.yaml 或类似文件
• 系统架构文档
• 提示词和模型更新的变更日志或版本跟踪
• 事件响应文档

F. 监控和可观测性

检查内容：

• Arize 跟踪设置：arize-otel、register()、TracerProvider、opentelemetry、openinference 导入
• 如果存在跟踪，检查覆盖范围：
  • 是否跟踪所有 LLM 调用（而非仅部分调用）
  • 是否有用于保持对话连续性的会话 ID
  • 是否有用于支持数据主体请求的用户 ID
  • 是否有错误跟踪和异常 span
• 告警和漂移检测配置
• Trace 保留配置

G. 供应商管理

检查内容：

• 第三方 AI API 的使用情况：导入或实例化 OpenAI、Anthropic、Google、Azure、Bedrock、Cohere 的客户端
• 模型版本管理：是否固定了特定模型版本（例如 gpt-4-0613），还是使用 latest / 未指定版本的标识符
• 提供商之间的回退和故障转移逻辑

阶段 1 输出

提交一份由两部分组成的报告：

第 1 部分 — 摘要表

领域	发现的证据	发现的差距	评级
A. 透明度	{findings}	{gaps}	合规 / 部分合规 / 不合规 / 不适用
B. 数据保护	{findings}	{gaps}	...
C. 安全性	{findings}	{gaps}	...
D. 测试	{findings}	{gaps}	...
E. 文档	{findings}	{gaps}	...
F. 监控	{findings}	{gaps}	...
G. 供应商管理	{findings}	{gaps}	...

第 2 部分 — 差距详情（每个评级为不合规或部分合规的领域都必须提供）

对于评级为不合规或部分合规的每个领域，请编写一个专门的小节，其中包括：

1. 确切的代码路径 — 文件路径、行号，以及显示差距所在位置的相关代码片段。不要转述；请引用实际代码。
2. 这对当前应用的重要性 — 结合此代码库说明具体风险（例如哪些工具可能遭到滥用、哪些数据流存在暴露风险、攻击者或监管机构会发现什么）。
3. 缺少的内容 — 精确说明应该存在但目前缺失的控制措施或代码（例如：“在 OTLP 导出器触发前，对 user_email 进行哈希处理的 span 属性处理器”，而不是简单地说“添加 PII 脱敏”）。

每个不合规或部分合规的领域至少要有一个小节。不要省略此部分——这是审计对工程团队最有价值的部分。

然后直接进入阶段 2。

阶段 2：合规检查清单

根据阶段 1 的发现和 references/compliance-checklist-template.md 中的模板，生成一份量身定制的合规检查清单。

生成检查清单的规则

1. 只包含相关部分。 如果用户只在美国运营，则跳过 GDPR 专属项目。如果不属于医疗保健行业，则跳过 HIPAA。如果不在纽约市招聘，则跳过 LL144。
2. 标记阶段 1 的项目。 找到证据的项目标记为 Compliant。存在差距的项目标记为 Non-compliant，并提供具体的修复建议。
3. 正确确定优先级。 严重 = 执法风险或系统禁用；高 = 法规要求；中 = 框架建议；低 = 最佳实践。
4. 提供具体的修复建议。 不要只说“实施输入验证”，而应说“添加类似 guardrails-ai 的护栏库，根据内容策略验证 LLM 输入和输出”。
5. 包含模板中的检测仪表化交叉引用表。 如果尚未设置 Arize 跟踪，则将其标记为严重差距——EU Art. 12 和 NIST MAN-2.1 要求审计跟踪。

最终报告

提交一份包含以下四个部分的综合报告：

第 1 部分 — 审计范围（阶段 0 摘要）

• 选定的框架、用例、风险等级、适用法规

第 2 部分 — 代码库发现（阶段 1 摘要表）

• 领域表（A–G），列出证据、差距和评级

第 3 部分 — 差距详情（阶段 1 扩展内容）

• 每个不合规或部分合规的领域各设一个小节，其中包含：确切的文件路径和行号、引用的代码片段、针对当前应用的风险说明，以及对缺失内容的精确描述。此部分为必填项，绝不能省略。

第 4 部分 — 合规检查清单（阶段 2）

• 量身定制的检查清单，包含状态和修复建议、检测仪表化交叉引用表、优先级摘要及建议的后续步骤

当用户要求生成报告文件时，创建一个包含全部四个部分的 Markdown 文件，路径为 /tmp/<app-name>-compliance-audit-<YYYY-MM-DD>.md。

提交报告后，提供阶段 3 修复服务。

第 3 阶段：整改（可选）

呈现检查清单后，提出可实施特定修复。进行任何更改之前，始终使用 AskUserQuestion 工具进行确认。

整改类别

添加依赖项 — 提议安装：

• 用于输入／输出验证的护栏库（例如，guardrails-ai、nemo-guardrails）
• PII 检测／脱敏软件包（例如，presidio-analyzer、scrubadub）
• 内容安全分类器

插入代码 — 提议添加：

• 面向用户的输出中的 AI 披露文本（模板、API 响应）
• 将数据导出到 Arize 之前，对跨度属性进行 PII 脱敏的过滤器
• AI 端点上的输入验证／清理
• 跟踪跨度上的用户 ID 属性，以支持数据主体请求

创建文档模板 — 提议搭建：

• 模型卡片模板（包含标准章节的 Markdown 文件）
• 事件响应计划模板
• 数据处理记录模板

配置监控 — 提议通过相关技能进行设置：

• 用于偏见检测和内容安全的 Arize 评估器（通过 arize-evaluator 技能）
• 用于审计追踪覆盖的跟踪（通过 arize-instrumentation 技能）

整改规则

• 将每项整改作为独立且可确认的操作提出。切勿批量应用更改。
• 明确说明将要更改的内容（文件、代码差异概述），然后使用 AskUserQuestion 工具在应用更改之前获取确认。
• 遵循现有代码风格和项目惯例。
• 切勿嵌入凭据；始终使用环境变量。
• 更改后测试应用是否仍可构建。

技能编排

如果在第 1 或第 2 阶段发现的问题需要其他 Arize 技能提供能力，请提出调用这些技能。调用其他技能之前，始终使用 AskUserQuestion 工具询问，并解释该技能与合规问题的相关性。

问题	要调用的技能	原因
没有跟踪／审计追踪不完整	arize-instrumentation	EU Art. 12 和 NIST MAN-2.1 要求记录事件；Arize 跟踪可提供此功能
没有偏见或安全评估	arize-evaluator	创建 LLM-as-judge 评估器，用于公平性、内容安全或质量监控
需要导出跟踪数据作为合规证据	arize-trace	导出跨度，用于监管文档或事件调查
高风险决策需要人工审查	arize-annotation	按照 EU Art. 14 的要求设置标注队列，以便进行人工监督
需要可分享合规证据的深层链接	arize-link	生成指向特定跟踪、跨度或评估的 URL，供利益相关方审查

插桩交叉参考

如果已设置 Arize 跟踪，请确认其符合合规要求：

合规需求	所需跟踪数据	检查内容
AI 决策的审计追踪	包含输入／输出的所有 LLM 跨度	确认所有 LLM 客户端调用均已插桩，而不只是部分调用
数据主体访问请求	跨度上的用户 ID 属性	检查是否存在 user.id 或自定义用户标识符属性
跟踪数据中的 PII	input.value／output.value 中的敏感数据	检查 PII 是否未经脱敏便传递；若是，则标记
事件调查	包含完整上下文的错误跨度	检查跨度上是否跟踪异常并设置错误状态
保留要求	跟踪数据保留所需时长	EU：适当时长（高风险情况至少 6 个月）；HIPAA：6 年
偏见监控	人口统计或群体属性	检查是否存在可用于公平性分析的元数据属性

如果尚未设置 Arize 跟踪，这是一个重大的合规问题。提出：“要我运行 arize-instrumentation 技能来设置审计追踪跟踪吗？监管框架（EU AI Act Art. 12、NIST AI RMF MAN-2.1）要求 AI 系统记录事件。”

参考链接

资源	URL
《欧盟 AI 法案》全文	https://eur-lex.europa.eu/eli/reg/2024/1689/oj
GPAI 实践准则	https://digital-strategy.ec.europa.eu/en/policies/contents-code-gpai
实践准则门户网站	https://code-of-practice.ai/
NIST AI RMF	https://www.nist.gov/artificial-intelligence/ai-risk-management-framework
科罗拉多州 AI 法案（SB24-205）	https://leg.colorado.gov/bills/sb24-205
纽约市地方条例 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 文档	https://arize.com/docs/ax

参考文件

• references/eu-ai-act-gpai.md — 《欧盟 AI 法案》和 GPAI 实践准则开发者指南
• references/us-ai-compliance.md — 美国合规概况（NIST AI RMF、科罗拉多州、纽约市 LL144、HIPAA）
• references/iso-42001.md — ISO/IEC 42001:2023 AI 管理体系开发者指南（仅包含可通过技术审计的控制措施）
• references/compliance-checklist-template.md — 可复用于 Phase 2 输出的检查清单模板