一篇于 2026 年 8 月 17 日上传至 arXiv 的 software engineering 研究，处理一个很多 AI 团队都会遇到的落差：EU AI Act 的条文要求 documentation、risk management 和 human oversight，但敏捷团队以短周期交付 AI 功能，日常使用的是 Definition of Done、Sprint Review、working agreement 和 backlog，而不是抽象的法规条文。研究团队的目标，是把要求翻译成可以放进既有开发节奏的工作活动。
作者采用 Design Science Research，先从三个维度评估 EU AI Act 的条文，再以 traffic-light scheme 分类，并把高度相关的条文对应至过往研究记录的 AI 敏捷团队痛点。之后，团队以问卷和 11 次额外的半结构访谈验证整理出的 catalog，并以 qualitative content analysis 分析从业者回应。这是一份研究提出并经过初步实践验证的 guideline，不是监管机构发布的合规清单。
研究结果把 guideline 整理成 12 个项目，涵盖 roles and responsibilities、risk and quality management、transparency and traceability、monitoring，以及 regulatory sandboxes。作者的重点不是新增一条平行的 compliance 流程，而是把责任和证据分散到团队已经使用的活动中，例如在 working agreement 说清楚 AI 系统的责任角色，在 Definition of Done 加入风险和可追溯性要求，在 backlog refinement 补充数据和测试条件，再在 Sprint Review 展示模型行为与监控证据。
这种翻译方式对 AI workflow 设计很有启发。合规要求如果只留在法务文件，工程师不一定知道何时要收集证据；如果只在上线前做一次审批，风险又可能已经在数据、模型和产品决策中累积。把条文映射到每日工作，团队可以在需求、构建、验证、发布和回顾的节点，逐步留下责任分工、测试结果、变更理由和监控方案。
不过，研究也没有把这套做法说成一键解决方案。参与者普遍认为 catalog 容易理解而且相关，但可行性会随组织成熟度而变化。作者的结论是，真正有效的采用需要不同角色共同拥有责任，并把活动整合进既有 Agile events，而不是由一个合规部门在流程外独力维护。这一点也解释了为什么同一套模板，在有完善产品治理的团队和刚开始建立 AI 流程的团队，落地成本可能完全不同。
工程团队可以先把研究转化成三个简单问题：每一项高风险 AI 功能由谁负责、何种证据足以支持发布、以及发布后谁会观察和处理偏差？再把答案放到 Definition of Done、决策记录、测试报告和监控告警中，而不是只放在一次性的简报。这种做法不能取代法律审查，却能令产品、工程、风险和运营之间有共同的工作语言。
需要特别说明的是，这篇 arXiv 论文是研究建议，不能当成法律意见或 EU AI Act 的正式解读。企业仍要按自己的角色、产品分类、司法管辖区和最新监管要求取得专业意见。它的价值在于提供一个可测试的 translation method：把外部规范转成团队可执行、可检查、可持续更新的 workflow artifact。
