EU AI

为什么风险等级对SaaS至关重要

我们的分类工作流程

步骤 1：捕获系统描述

我们要求产品负责人撰写一段简短的叙述，涵盖三个要点：AI 组件的核心功能、它消耗和产生的数据以及预期的用户或受影响的人。叙述不需要是技术性的；简单的英语段落就足够了。我们将此文本存储为下一步的种子。由于法案关注目的和上下文，我们保持描述不包含实现细节，例如编程语言或云提供商，这些可能会分散分类器的注意力。

步骤 2：将功能映射到 AI 法案附录

法案的附录列出了被认为是高风险的特定 AI 实践，例如生物识别识别、关键基础设施管理或就业筛查。我们对描述进行标记化，并寻找与这些附录条目相匹配的关键字。例如，如果文本提到“面部识别”或“员工绩效评分”，我们标记一个潜在的高风险匹配。我们还检查有限风险触发器，例如与消费者交互的聊天机器人或情绪识别系统。这一步生成一个基于找到的最强匹配的临时层。

步骤 3：分配初步层

如果找到任何不可接受的风险附录条目（例如社会评分、公共场所的实时远程生物识别识别），我们将系统标记为不可接受并停止进一步处理，因为法案禁止此类 AI。如果没有出现不可接受的匹配，但至少有一个高风险附录条目存在，我们将层设置为高风险。当只有有限风险条目出现时，我们将层设置为有限风险。如果没有附录条目匹配，我们默认为最小风险。这一基于规则的方法提供了一个透明的初始输出，律师稍后可以审查。

步骤 4：运行差距检查

一旦层设置完成，我们将生成一个与该层相对应的义务清单。对于高风险，清单包括风险管理系统、数据治理文档、技术文档、日志记录、透明度信息、人工监督措施、符合性评估和上市后监测等项目。对于有限风险，清单重点关注透明度义务，例如告知用户他们正在与 AI 交互。对于最小风险，清单为空，但我们仍然建议基本的安全卫生。差距检查将您的当前工件（例如现有的数据表、测试报告）与每个清单项进行比较，并标记任何缺失的部分。

分层细则和义务

风险等级 | 典型AI例子 | 法案下的关键义务 不可接受 | 社会评分、公共场所实时远程生物识别识别、利用漏洞的操纵性AI | 禁止；不允许在市场上销售 高风险 | 生物识别访问控制、关键基础设施AI、招聘工具、医疗设备软件、信用评分 | 风险管理系统、数据管理、技术文档、日志记录、透明度、人工监督、合规评估（CE标志）、上市后监测、事件报告 有限 | 聊天机器人、情绪识别、深度伪造生成器、具有自适应难度的AI视频游戏 | 透明度义务：告知用户他们正在与AI交互；交互前提供明确通知 最小 | 垃圾邮件过滤器、电子商务推荐引擎、AI辅助拼写纠正 | 没有特定的AI法案义务；一般产品安全和数据保护规则仍然适用

我们常见的陷阱

忽视通用人工智能

误解透明度义务

对于有限风险人工智能，法律要求明确通知用户正在与人工智能系统交互。一些团队将通知放在冗长的服务条款文档中或隐藏在工具提示后面。委员会的指导方针要求通知在交互时呈现，以清晰的语言和足够的对比度，以便于注意。我们已经看到了一些由于缺失或不明确的通知而导致在审计期间发现不符合要求的情况。

忽视上市后监测

高风险人工智能需要在发布后监测性能的计划，包括输入和输出的日志记录、周期性的漂移测试以及报告严重事件的流程。早期团队通常专注于发布前的验证，并忘记构建日志记录管道。该法案要求监测计划成为技术文档的一部分，并至少每年更新一次。我们建议将日志记录步骤集成到您的CI/CD管道中，以便每次部署都可以自动将日志条目添加到安全存储中。

什么这不是

本指南不能保证任何由ClauseGuard生成的分类都会被监管机构接受。该工具根据您提供的文本提供初步的查看结果；它不能取代正式的法律分析。它不能保证涵盖每一种可能的AI场景100%，也不能保证按照清单进行操作永远不会错过任何义务。输出结果旨在告知您的内部审查，并帮助您为律师准备问题。在向国家机构提交任何符合性评估或文件之前，请始终涉及一名合格的律师。

我们如何保持分类器更新

监控官方更新

我们订阅欧盟官方公报，并关注人工智能法案的修正案。当新的委托法规或实施条例出现时，我们会审查更改并相应地调整我们的关键词列表。例如，最近关于生成式人工智能透明度的更新增加了新的短语，我们现在在系统描述中检查这些短语。

集成社区信息源

我们关注可靠的信息源，例如OWASP LLM风险页面（https://genai.owasp.org/llmrisk/-prompt-injection）和NIST人工智能风险管理框架（https://www.nist.gov/itl/ai-risk-management-framework），以捕获新出现的威胁模型和最佳实践。当这些信息源强调新的风险模式时，我们会在映射步骤中添加相应的触发器。

季度内部审计

每三个月，我们会进行一次内部审查，产品负责人、安全工程师和法律顾问使用当前的分类器对一组样本功能进行分类。我们将结果与最新指南的预期进行比较，并记录任何不匹配的地方。这些不匹配的地方会驱动规则集或我们为用户提供的文档示例的更新。

EU AI

我会在每个版本中保留一份书面清单，用于检查这个主题。清单故意设计得很简单：命名所有者，命名证据文档，命名回滚。如果一个步骤不能产生文件、票据或日志记录，那么它不是一个步骤——它是一个愿望。

在更改生产环境之前

- 冻结将要测量的分支或配置修订版。 - 记录当前故障模式，包括一个具体的输入和一个具体的输出。 - 确认作业运行的身份，并检查该身份是否可以访问不应访问的数据。 - 打开主要参考资料：https://commission.europa.eu/strategy-and-policy/priorities-2019-2024/europe-fit-digital-age_en，https://genai.owasp.org/llmrisk/-prompt-injection。

在运行检查时

- 更喜欢一个可复现的路径，而不是十个传闻截图。 - 在触发工具或查询之前，写下预期的安全结果。 - 捕获正在测试的确切命令、提示、模式或正则表达式——而不是一个概括。 - 如果系统可以执行操作（发送、写入、删除、传输），则需要在同一路径中要求确认边界。

完成后

- 即使扫描结果干净，也要将残余风险与所有者和日期一起存档。 - 不要将绿色检查转换为声称完整性的销售语言。 - 当模型、工具模式或验证规则发生变化时，重新运行相同的清单。

信号 | 记录内容 | 停止发货？ 意外写入或发送 | 工具名称、参数、身份 | 是，直到受控 缺少对破坏性操作的确认 | 调用路径和绕过 | 是 不受信任的文本被视为指令 | 源表面和结果操作 | 是，适用于代理范围 扫描结果干净，判断开放 | 推迟项目 + 所有者 | 仅当核心路径安全时

ClauseGuard 有助于实现可衡量的第一次传递。架构选择、法律签署和客户面向的声明仍然需要一个人类所有者。将清单中的每一行视为决策支持，而不是证书。

我如何向买家解释限制

当一个潜在客户问产品是否"涵盖一切"时，我会以这样的界限回答：自动检查可以捕捉已知的模式，但新的链条和政策判断仍需要人工审查。这种诚实可以降低支持负担，并保持博客内容与产品实际功能的一致性。

如果您需要第二个意见，请将此文档与下面的参考资料和您自己的测试环境结合起来。不要仅因为模型写了一个自信的总结就跳过测试步骤。

参考资料

- https://commission.europa.eu/strategy-and-policy/priorities-2019-2024/europe-fit-digital-age_en - https://genai.owasp.org/llmrisk/-prompt-injection - https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-06-Insufficient-Credential-Hygiene - https://www.nist.gov/itl/ai-risk-management-framework