参与式人工智能治理：以内部专家协作打通最后一公里

🎓 专业 IRMaD 结构解读

I. Introduction（引言）

本文研究欧盟《人工智能法案》（Regulation 2024/1689）在组织内部真正落地时的“最后一公里”问题。法案把此前自愿性的伦理原则转为对高风险系统的强制性义务，覆盖技术文档、数据治理、风险管理、透明度、性能评估、人类监督与持续监测。既有治理研究多停留在两个上层：产业层通过法规与标准设定要求，组织层通过政策与管理体系承接要求，而团队层由开发者日复一日写下的代码如何被这些要求改变，实证证据稀少。原因不难理解：团队层是组织的商业机密所在，外部研究者很难获得进入许可（Scheuerman 2024）。已有实证工作多以访谈方式记录实践者的困难（Ali 等 2023；Sloane 与 Zakrzewski 2022；Rakova 等 2021），较少检验具体干预手段是否奏效；提出的框架也大多缺乏真实场景验证（Mökander 等 2022；Kuehnert 等 2025）。作者据此提出研究问题：协作式工作坊如何赋能技术团队，把 AI 治理要求整合进既有的软件开发流程。文章的理论贡献是把团队层落地从“规范性呼吁”转为“可观察的干预过程”，方法贡献是给出“法律文本到行动”的五步流水线（准备、呈现、评估、排序、后处理），经验贡献是在一家不到十人的创业公司里完整记录了 14 条要求的评议、排序、分解与八周内的实施进展。

I. Theoretical Framework & Hypotheses（理论框架与假设）

理论骨架由三条文献线合成。第一条是三层治理结构（Shneiderman 2020；Lu 等 2024）：要求由产业层制定、组织层适配、团队层执行，越往下越依赖解释性劳动，也越容易断裂。作者借用物流隐喻把断裂点命名为“最后一公里”，强调其非线性：铺开仓库体系是规模问题，送到每户门口才是摩擦问题。第二条是参与式设计，特别是北欧传统在工作场所把劳动者纳入影响其劳动的技术设计（Asaro 2000）。作者刻意与 FAccT 主流的外部利益相关者参与区分：后者追求民主正当性与权力再分配，本文的参与者是受治理约束的开发者本人，目标是实施有效性与所有权分散。按 Kallina 等（2025）的术语，这属于“专家参与”，本文进一步扩展为“专家协作”，因为参与者不仅被咨询，还共同设计治理策略。第三条是“桥梁工作”（Deng 等 2023）：在不同视角之间来回翻译的迭代劳动，通常不被团队理解，却带来额外负担与倦怠。本文把治理官的独任翻译视为典型桥梁工作，并提出协作工作坊可以让这项隐形劳动可见、可分担。三条线共同支撑一个机制命题：当开发者自己发现合规与既有权重的重叠时，治理承诺的分量会不同于外部强加；配套的实践策略是 Sloane 与 Zakrzewski（2022）所说的“搭便车”，即把治理工作嵌进已排定的产品会议而非另开专场。

M. Materials & Methods（材料与方法）

研究设计为单案例内部行动研究（insider action research；MacIntosh 等 2007；Coghlan 2019），按诊断、规划行动、采取行动、评估行动的循环组织全文。第一作者同时担任公司的人工智能治理官与研究者，既推动合规，又把推动过程作为研究对象；为对冲内部人偏差，工作坊由一名外部研究者共同主持并提供独立观察，研究设计由公司外的第二作者每周例会复核。研究场域为一家约十人的工业人工智能创业公司，持有 ISO 27001 与 ISO 42001 认证，现有产品尚不属高风险类别，管理层出于前瞻考虑启动准备。作者依据风险分类结果，选取法案第 9 至 15 条、第 50 条、第 72 条与附件四，剔除主要涉及组织领导（治理结构、资源分配）与外部核查（合格评定、市场监督）的条款，整理为 14 条高层要求、6 个主题板块；框架与两次技术负责人预备会议完成情境适配。工作坊设计咨询了四位具政治学与计算机背景、长期做参与式研究的学者，采用先发散后收敛的钻石模型三段式：呈现、评估与构思、排序。会后策略被细化为动作并录入 Jira，与技术负责人共同确定 12 个月路线图。数据来源为会前会后问卷（n=8，仅描述性统计）、Miro 白板产物、外部共同主持人的结构化观察记录，以及对三项动作的八周实施追踪。本文不报告推断统计，也不报告编码者间信度；外部观察为单人记录，是本设计的方法学短板。

R. Results（结果）

工作坊对 14 条要求全部产出了实施策略，其中三项在会后八周内落地并被详细追踪。作者据此归纳出三种反应模式，并用“谁受益”解释其分布。模式一“会合”：合规目标与开发团队已有的优先项指向同一方案。日志记录（第 12 条）与团队的可观测性需求重叠，两名全栈开发者用两天、约 32 人时自建 Langfuse 实例，覆盖开发、测试、生产三套环境；但第 12 条第 3 款 d 项要求识别参与结果验证的自然人，当前实现只到租户级，补齐需改动认证与日志架构并触及隐私冲突。模式二“既有实践”：人工智能交互告知（第 50 条第 1 款）经审查由入口命名、通用图标与开场提示三项既有设计满足，合规工作仅两小时的文件记录；网络安全措施与既有 ISO 27001 一致。模式三“脱节”：技术文档（第 11 条及附件四）由治理官访谈三名开发者、协作绘制系统上下文、容器与组件三级 C4 图，耗时约八小时，开发者对合规之外价值的评价为“可忽略”；正式风险管理流程被排入“钱坑”象限。数据治理的脱节源于法律模糊：团队作为基础模型使用者不训练模型，难以确定适用动作；第 11 条第 2 款要求的中小企业简化文档模板在法案生效十八至二十个月后仍未发布。会后问卷显示，八人中有七人同意治理要求与产品质量争夺有限时间与资源；在治理模式偏好上，四人选择“共同决策并共同执行”，两人选择“共同执行”，无人选择仅被通知。

a / D. Discussion & Conclusion（讨论与结论）

讨论把三类模式收束为一个判据：合规被体验成打勾，就会被当作打勾来对待。影响—投入矩阵的分布不是主持人引导的结果，而是参与者自评的产物：服务终端用户（交互告知、人类监督、使用说明）与服务开发者（日志、性能监测）的要求聚集在高影响区；主要服务审计者与监管者（技术文档、正式风险管理）的要求集中在高投入、低影响一角。作者由此提出翻译命题：同一法律义务可以被读成“把系统写清楚，好让自己看得懂、改得动”，也可以被读成“把系统写清楚，好让外部核查你做了什么”；两种读法都成立，但前者激发实质投入，后者诱发符号化应对。对监管设计的含义是，核查型要求并非多余，外部监督本就依赖证据，问题在于要求文本与实施指导是否把改进性理由说清楚。文章同时列出五项未解难题：资源竞争是结构性的，可见性不等于新增产能，协作不转移法律专业能力，态度转变在持续运营压力下的耐久性未知，核查型要求与质量收益的断裂未被消解。局限包括单案例、n=8、仅八周追踪、内部人视角可能影响参与者作答，以及公司具备前瞻意愿与既有认证这一有利条件。作者据此倡议纵向追踪、跨组织比较，并探讨把法律校验嵌入协作流程而不重新引入自上而下。