An arXiv software engineering paper submitted on August 17, 2026 addresses a gap many AI teams face: the EU AI Act calls for documentation, risk management, and human oversight, while Agile teams ship AI features in short iterations using a Definition of Done, Sprint Reviews, working agreements, and backlogs rather than abstract regulatory provisions. The researchers set out to translate those obligations into activities that fit an existing delivery rhythm.
The authors use Design Science Research. They assess EU AI Act articles along three dimensions, classify them with a traffic-light scheme, and map the highly relevant items to documented pain points among Agile teams working with AI. They then validate the resulting catalog through a survey and 11 additional semi-structured expert interviews, analyzed with qualitative content analysis. This is a research-produced and initially practitioner-validated guideline, not an official regulator checklist.
The resulting guideline contains 12 items across roles and responsibilities, risk and quality management, transparency and traceability, monitoring, and regulatory sandboxes. The important design choice is not to create a parallel compliance process. Instead, the paper maps responsibility and evidence to activities teams already use: clarify AI-system roles in a working agreement, add risk and traceability criteria to the Definition of Done, capture data and test conditions during backlog refinement, and show model behavior and monitoring evidence during a Sprint Review.
That translation is useful for AI workflow design. If compliance requirements remain only in legal documents, engineers may not know when evidence must be collected. If approval happens only before launch, risk may already have accumulated in data, model, and product decisions. Mapping obligations to daily work gives the team points at which to record ownership, test results, change rationale, and monitoring plans across requirements, build, validation, release, and review.
The paper does not present the approach as a one-click solution. Practitioners generally rated the catalog understandable and relevant, but feasibility varied with organizational maturity. The authors conclude that adoption requires collective ownership across roles and integration into existing Agile events instead of an isolated compliance function. That explains why the same template can have very different implementation costs in a team with mature product governance versus one still establishing basic AI controls.
Teams can turn the study into three starting questions: who owns each high-risk AI capability, what evidence is enough to support release, and who will observe and respond to issues after launch? The answers can become part of the Definition of Done, decision records, test reports, and monitoring alerts rather than a one-off presentation. This does not replace legal review, but it gives product, engineering, risk, and operations a shared working language.
The arXiv paper is research guidance, not legal advice or an official interpretation of the EU AI Act. Organizations still need professional advice based on their role, product classification, jurisdiction, and current regulatory requirements. The paper's contribution is a testable translation method: turn an external rule set into workflow artifacts that a team can execute, inspect, and keep current.
