面向智能体部署的影响评估

三份文件，以及你的厂商并不欠你的那一份。

有三种评估常被混为一谈，而这个区分决定了笔握在谁手里。

• DPIA——GDPR 第 35 条下的数据保护影响评估，当处理活动很可能给数据主体带来高风险时，由控制者负责。这件事已存在多年，大多数组织都有模板和审阅人。
• FRIA——欧盟《AI 法案》第 27 条下的基本权利影响评估，由某些高风险系统的部署方负责：受公法管辖的机构、提供公共服务的私营主体，以及把高风险 AI 用于信用度评估、或用于人寿与健康保险的风险评估与定价的部署方。在 DPIA 已经覆盖某项义务的地方，FRIA 是对它的补充而非替代；而部署方须将评估结果通知市场监管机构。
• 内部 AI 评估——你自己的风险职能部门怎么叫它都行。它不是法律强制的，而通常也是三者中唯一真正会被造这东西的团队读的那一份。

请把第二条再读一遍，因为它把大多数采购流程里编码的那个直觉反转了过来。FRIA 是部署方的义务。训练了模型的那个实验室不欠你这份，平台厂商不欠你这份，而再多的厂商文档也无法免除它——这份评估讲的是你的流程、你的受影响人群、你的监督安排，而这些厂商一样也看不到。如果你为一次智能体部署准备的合规方案是一叠供应商声明，那你收集的是一份没人写过的文件的证据。

截止日期挪了。义务没挪。

《AI 数字综合法案》（Digital Omnibus on AI）于 2026 年 7 月 24 日在《官方公报》上公布，并于 2026 年 7 月 27 日生效。它把附件三所列的独立高风险系统的合规时点从 2026 年 8 月 2 日推迟到 2027 年 12 月 2 日，把嵌入在已受欧盟产品安全法覆盖的产品中的高风险 AI 推迟到 2028 年 8 月 2 日。

它没做的事，是改变实质内容。各项义务完好无损；挪动的是执行日期。这个区分正是在口耳相传中丢掉的那一个，而其实际后果很具体：把这次推迟读成「可以停工」的组织，会在 2027 年 12 月抵达时，需要为一个它到那时已经跑了十八个月的系统出一份评估，而手上没有任何关于这期间自己在做什么的同期记录。你写不出来的那份评估，正是回溯性的那一份。

所以请把这段多出来的时间当成它实际上是的东西——用来把测量那一侧建起来的余地，而那是昂贵的那一半，也是你无法事后补齐的那一半。文件本身是一周的活。让文件为真的那套遥测是一个季度的活，而且它只会往前产出历史。

把配置点出来，因为「这个系统」不是一个稳定的指称。

智能体特有的那个问题，可以用一个观察说完。传统的风险评估描述的是「有人部署它时才变化」的软件。而一个智能体的行为至少由六样东西决定，其中五样不经过部署就会变，而三样甚至不需要你公司里任何人做任何事就会变。

# What actually determines this agent's behaviour, by change cadence

model + version        vendor's schedule, not yours      # can change silently
system prompt          edited by whoever owns the prompt  # often weekly
tool list + scopes     grows as integrations land         # per sprint
retrieval corpus       whatever got indexed last night    # continuous
guardrail thresholds   tuned in response to incidents     # ad hoc
autonomy level         raised when the team gains trust   # rarely logged

# Of these, how many go through your change-control process?

   typically: one (the code), and it is the least behavioural

因此，一份以「那个客服智能体」为锚的评估，其实没锚在任何可核查的东西上。请改以上面那六个字段为锚，记下评估当时它们的取值，于是你的重新评估触发条件就变成机械的、而不是一次判断：其中任何一项发生变化，就是被评估的那个系统发生了变化。这六项里有两项值得特别留意——厂商能在你脚下挪动的那个模型版本，正是未钉定的厂商默认值里编目的那个问题；而被非正式地抬上去的自主性级别，则是最有可能让一份评估失效、却又不留下任何「它发生过」的记录的那一项变化。

这也是评估在内部而非在法律上赚回身价的地方。把「到底是什么决定了行为」写下来这个动作，往往会翻出一件没人记得自己授予过的工具，和一段没人认领的提示；而无论是哪个监管者在问，这两条都是值得拿到的发现。

让每一条结论都能被监控推翻。

这是本页承重的那条建议。一条写成散文的风险结论——「歧视性结果的风险已通过对所有不利决定的人工复核得到缓解」——无法被核查、无法过期，也无法被除一次事故之外的任何东西推翻。请改为把每条结论写成四个字段，于是这份文件就变成了一组常设主张，而你的遥测要么支持它们、要么与它们相矛盾。

# One row per risk conclusion. If a row has no measurement, it is an opinion.

RISK          adverse decision issued without human review
CLAIM         every adverse outcome is reviewed before it is sent
MEASUREMENT   % of adverse-outcome events with a recorded reviewer id
THRESHOLD     < 100% over any rolling 24h window
OWNER         head of operations (named person, not a team)
ON BREACH     assessment marked stale; deployment to advisory-only
RE-ASSESS     any change to the six configuration fields

RISK          affected person cannot contest the outcome
CLAIM         an appeal route exists and is reachable in two steps
MEASUREMENT   appeals opened / adverse outcomes, by channel
THRESHOLD     ratio below the floor agreed with the business
OWNER         complaints lead
ON BREACH     the route is broken or unknown; investigate within 5 days

检验你是否做好了这件事的标准很直白：一个监控系统能否在没有人去读它的情况下推翻这份评估？如果不能，这份文件就是一张快照，而且在归档之前就会过期。如果能，它就是风险职能与遥测之间的一份契约，而「过期」从一次在审计中被发现的事，变成了一条告警。

两点实际注意。那些测量应当来自你本来就在跑的质量回归检测流水线，而不是一条平行的合规流水线——由另一个团队维护的第二套数字会在一个季度内发散，然后两套都没人信了。另外，阈值被突破并不自动等于一次事故：被写下来的应对通常应该是「评估已过期、降低自主性、重新评估」，这比重大事故报告里那条上报通路便宜得多，也把那条通路留给它该用的场合。

第 27 条的各项要素，以及每一项在智能体上会在哪里崩。

第 27 条要求部署方描述该系统将被用于其中的那些流程、预期使用的期间与频率、很可能受影响的自然人类别与群体、对这些类别的具体损害风险、人工监督措施，以及风险成为现实时要采取的措施——包括治理安排与投诉机制。这些落在一个智能体上时，每一项都别扭，而这种别扭值得提前料到。

• 预期使用的期间与频率。这是为「有人打开它来做一个决定」的系统写的。一个常驻智能体没有会话，所以请改为给出一个速率和一个上限——每天的决定数、最大并发运行数，以及你真正在强制的那个上限。一个你无法强制的频率不是一份描述，而是一个愿望。
• 很可能受影响的人的类别。陷阱在于，智能体会影响到从不与它交互的人。它读的某份文档里被点名的每一个人、它写入的某条记录里的每一个人、它采取的某个动作的下游每一个人。请从智能体的数据面与动作面去枚举，而不是从它的用户名单去枚举。
• 人工监督措施。这一项必须点名一个真能把系统停下来的人，连同机制和所需时间。如果诚实的答案是「停下来需要一次部署」，那就这么写——那是一条发现，它该跟急停开关放在一起，而不是被一句政策话术糊过去。同一个问题的设计那一侧是人在回路。
• 投诉机制。对智能体而言，会坏掉的不是「通路是否存在」，而是它的可达性：一个受影响的人首先得能知道有一个智能体参与过。这就是可申诉性与上诉的那个问题，也是最常被写成愿景的那一项要素。
• 治理安排。请点名角色，不是委员会。这一字段有用的那个版本，是每次部署对应一位可问责的个人——正如问责与角色所论证的。

如果 DPIA 已经为同一处理活动回答了上述某一项，请明确说出来并交叉引用，而不要换一套说法把它重述一遍。两份文件对同一道保障措施给出略有不同的描述，比一份文件加一个指针的处境更糟，而那处不一致恰恰是审阅人会注意到的东西。

它住在哪里，以及这个季度该做什么。

运作模式比模板更要紧，而它归结为四个决定。

• 把它存在清册条目旁边，而不是文档库里。评估里的配置字段与清册里的配置字段是同一组字段。把它们放两处，就保证了它们会不一致，而这处不一致会由某个外部的人发现。
• 按配置而不是按日历来给它版本。对一个主题每周都在变的东西，年度复审是错的节奏。触发条件是那六个字段发生变化；年度那一遍是「什么都没触发」情形下的兜底。
• 让「已过期」成为部署可以处于的一种状态。不是文件上的一个标签——而是一个带既定后果的状态，通常是在重新评估之前降低自主性。这是唯一能在两次审计之间给评估装上牙齿的机制，而它与面向智能体的模型风险管理里那些降级状态是同一件器械。
• 上面留一个人的名字。由一个职能部门拥有的评估，没有人会去复审。

范围说明：评估不能替代它所引用的那些证据。审计轨迹、留存，以及智能体读过什么的血缘，仍是各自独立的问题——见审计轨迹与溯源与面向智能体的数据治理。评估的职责是说清你相信什么，以及你会怎么知道自己错了。