职工协商与共同决定

触发条件是「能力」，而你早就把它建好了。

德国《企业组织法》第 87 条第 1 款第 6 项，赋予职工委员会对「用以监控员工行为或绩效的技术设备」之引入与使用的共同决定权。联邦劳动法院长期以来对这句话作客观解释：只要该系统适合记录此类信息，就已足够。雇主是否打算监控任何人，根本不进入这道判准；而当监控能力客观存在时，法院驳回过「这个工具的主要目的是别的（IT 安全、稳定性）」这类抗辩。

现在拿这条标准去看你自己的智能体可观测性：每次运行一条 trace，关联到发起它的那个用户，带着时长、重试次数、工具调用、错误率与成本。那就是一份客观上适合记录个人绩效的记录，而你在第一周就把它建好了，因为不建就没法调试。

• 这里的共同决定权不是一项告知义务。它意味着职工委员会拥有实质发言权，而未经合意即引入的系统，可以被裁令停止使用。
• 这项权利附着于引入与使用，所以「我们已经上线了」是问题本身，不是答案。
• 德国是最锋利的那个案例，不是唯一的那个。荷兰、法国等国各自有自己的协商制度，触发条件与时间表都不相同；一次多国铺开面对的是好几口钟，不是一口。

两项义务，常被混为一谈，救济手段却不同。

「告知」与「共同决定」不是同一项义务，满足其一并不能免除其二。

• 告知。欧盟《AI 法案》第 26 条第 7 款要求，身为雇主的部署者在工作场所投入使用高风险 AI 系统之前，必须告知职工代表与受影响的员工。这是一项单向义务：你按各国关于员工知情的规则去通知。对于独立的附件三系统，这些部署者义务自 2027 年 12 月 2 日起适用——见面向智能体的欧盟《AI 法案》。
• 合意。各国劳动法下的共同决定是双向的。它的产物是一份经谈判达成的企业协议，谈不拢还有仲裁通道。它不按你的时间表走。

留意一个智能体落在这条线的哪一侧。附件三覆盖就业与劳动者管理——用于分配任务、或用于监控与评估绩效的系统——所以一个派活、给产出打分、或按员工分流工单的智能体，本身就相当可能落入告知义务的范围。但共同决定权也可以附着在一个完全不做这些事的智能体身上，仅仅凭它发出的遥测数据就够了。真正让人措手不及的，恰恰是那个平平无奇的内部工具。

「一个 AI 智能体」不算范围。在别人替你写之前，先把系统描述写出来。

被拿去谈判的，是一份描述某个系统的文件。你不带一份来，对方的草案就成了基线；而一份出于防御心态写就的草案，会禁掉你真正需要的东西。带一份足够具体到可以被同意、又足够收窄到你能长期忍受的描述过去。

• 采集什么、什么粒度、以谁为键。按运行、按用户、按团队、还是聚合。这是整份文件里后果最重的一行。
• 保留多久，到期之后发生什么——和 trace 采样与留存是同一批决定，只不过如今对面坐着一个外部对手方。
• 谁能查询、以什么目的、经由哪个界面。「有生产权限的工程师」不构成目的限制；一个具名角色去查一个无法按个人分组的视图，才构成。
• 什么是被彻底禁止的。一条经谈判确立的「不得将该数据用于绩效评估或纪律处分」的禁令，通常正是让其余一切成为可能的那个让步——而且它是一条你能用技术实现、而不必只用嘴承诺的禁令。
• 什么会触发重谈。现在就定义哪些变更会重启这份协议，否则每一次变更都会。

把系统设计成「可以被答应」的样子。

大部分摩擦是可以避免的，而且是在数据模型里避免，不是在谈判桌上。四个动作能造出一个容易被同意的系统。

• 默认聚合，例外才归属到个人。运维看板几乎从不需要一个个人键——p95 延迟、错误率、每任务成本都是团队级的问题。把个人标识推到一条单独的、按目的设关的通路后面，只用于支持与事件响应。
• 写入时就做假名化。一个稳定的按会话标识、只有经由受控关联才能还原到某个人，与一个盖在每条 span 上的用户 ID，是实质不同的两种东西——无论在法律上，还是在「一个工程师在糟糕的下午能干出什么」这件事上。
• 让禁令是可展示的。一句「我们不会跑绩效查询」的承诺，价值低于一个不含个人维度的数仓视图，外加原始表上的一份访问日志。后者你能拿出来给人看；前者你只能嘴上说。
• 把留存缩短。九十天的可归属到个人的 trace，比十四天难谈得多；而超过两周之后的调试价值接近于零。机制见智能体 trace 中的 PII 脱敏。

你的发版列车与一份谈成的协议，跑在不同的速度上。

协议是对着一份系统描述写的，而智能体一直在变——新工具、新模型、span 上的新字段。放任不管，要么每一次部署都成了一个通知事件，要么那份描述悄悄地不再描述这个系统；而后一种更糟。

• 给描述打版本，并把它绑定到一次发布上。把它当成仓库里的一份产物，像评审 schema 变更那样评审，并记录哪个版本在哪段时间生效——把发布与版本管理那套纪律套用到一份合规文件上。
• 把变更类型在协议里一次性归好类。同一接口下换个模型、加一个不带新遥测的新工具、加一个按用户的新字段：预先约定它们各自属于「仅需通知」还是「重启谈判」。签约时做这件事，代价是一次对话；每次变更时做，代价是每次一场。
• 给新增遥测字段设一道闸。现实中的失效不是某个惊天动地的新功能，而是某个工程师周五为了排查问题，往 span 上加了一个 user_email，于是系统悄悄挪到了约定范围之外。
• 把受影响的劳动者范围记进你的智能体清册。「我们哪些智能体正被德国的员工使用」应当是一次查询，而不是一串邮件。

把记录留下，因为这个问题几年之后才会来。

人家要你拿出来的证据，不是你的良好意图，而是一小撮枯燥的产物：当时留只要几分钟，事后则无法重建。

• 系统描述，按版本，附上每个版本的生效日期。
• 告知了谁、什么时候、以什么形式；而对《AI 法案》那项义务而言，还要能证明它发生在使用开始之前——一个当时记下来毫不费力、事后却无从证明的先后顺序。
• 协议本身与任何仲裁结果，并关联到它所覆盖的那些系统。
• 可归属到个人的那份数据上的访问日志。这一项才真正回答了人们在意的那个问题——不是「你承诺了什么」，而是「你跑了什么」。

这四样都该和你其余的审计轨迹放在同一个地方，并按问责与角色由一个具名的人负责——一份没有主人的合规记录，腐坏得比它所描述的那个系统还快。