一篇於 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。
