The EU AI Act enforcement timeline is not a distant planning horizon. With the first substantive obligations — prohibited practices bans, GPAI model transparency requirements, and high-risk system conformity assessments — already live or entering force through 2025 and 2026, organisations building AI systems under Agile delivery models face a structural challenge: how do you make compliance a continuous property of the product, rather than a gate-check event that arrives like an audit six months after the code was written?
This post answers that question with the practical mechanics: which sprint ceremonies to modify, how to restructure the backlog to make compliance obligations first-class citizens, and what team rituals make AI governance culturally sticky rather than a grudging compliance tax.
"Governance bolted on at the end is not governance — it is remediation. The only sustainable model is one where every sprint produces not just working software, but demonstrably compliant working software."
The Bolt-On Problem
The standard enterprise response to new regulation is to stand up a programme-level compliance workstream, task it with translating regulatory text into requirements, and hand those requirements to delivery teams as a batch — usually six to twelve months before a compliance deadline. Teams treat them as an unplanned interrupt that competes with product roadmap commitments, the backlog becomes adversarial, and the resulting delivery is technically compliant but organisationally resented and poorly understood by the people maintaining it.
Under the EU AI Act, this model is particularly dangerous. The Act requires that certain documentation, testing, and oversight mechanisms be demonstrably part of the development and deployment process — not retroactively attached. Article 9 on risk management systems, Article 10 on data governance, Article 15 on accuracy and robustness: these are not documentation obligations that can be satisfied by writing a policy after the fact. They require evidence that the processes existed during development.
Notified Bodies assessing high-risk AI systems under Annex III will look for evidence that risk management, data governance, and accuracy monitoring were active during development — not just described in post-hoc documentation. Teams that sprint without governance artefacts cannot reconstruct that evidence reliably after the fact.
Restructuring the Backlog
The first integration point is backlog design. Most AI product backlogs are structured entirely around capability: the model learns to do X, the API returns Y, the UI displays Z. Governance work — risk assessment, data quality checks, explainability features, human oversight mechanisms — appears as an afterthought if it appears at all.
The fix is to introduce a parallel governance backlog thread that runs alongside every capability stream and is reviewed in the same ceremonies. This is not a separate backlog or a separate team. It is a set of acceptance criteria and story types that make compliance obligations explicit at the story level.
Modifying Sprint Ceremonies
Backlog structure is necessary but not sufficient. The ceremonies are where governance either becomes embedded practice or remains a paper commitment. Here is how each standard Scrum ceremony can carry governance weight without becoming a compliance theatre performance.
Sprint Planning
Add a standing governance capacity allocation — typically 10–15% of sprint capacity — explicitly labelled on the planning board. This is not a tax on the team; it is an honest acknowledgement that governance work takes time and, if not planned, will either be skipped or will arrive as crunch work at the end of the sprint when no one has energy for it. Naming the allocation makes it negotiable and visible, both of which are improvements on the status quo.
Definition of Done
The single highest-leverage change available. For AI systems operating in high-risk categories under Annex III, the Definition of Done should include:
- Risk register updated with any new risks introduced by this story's changes
- Data documentation current — any new data sources, transformations, or filters are recorded
- Human oversight pathway confirmed — for decisions that trigger manual review, the pathway is documented and tested
- Technical documentation version-bumped — the Article 11 technical file is updated to reflect the current model state
This adds perhaps thirty minutes per sprint story — less if teams build templates. It generates the audit trail that makes conformity assessment assessable rather than reconstructed.
Sprint Review
Invite a compliance or legal stakeholder to the sprint review as a standard participant — not a guest, not an auditor, but a team member with a seat at the table. Their role is not to block acceptance but to maintain awareness of the direction of travel and flag regulatory implications before they become technical debt. This is the cheapest form of legal review available.
Retrospective
Add a standing retrospective question: "Did any governance work slip to the 'next sprint' pile this cycle?" If yes, understand why. Usually it is either under-estimation (add buffer) or prioritisation pressure from product (a conversation to have with the Product Owner about compliance as a non-negotiable, not a nice-to-have). The retrospective is where culture is built; the question signals that governance is as important as velocity.
Making It Culturally Sticky
Structural changes to backlog and ceremony are necessary. Cultural stickiness requires something more: the team needs to understand why the governance obligations exist, not just what they are.
At the start of each PI or programme increment, run a thirty-minute exercise with the full team: for the capabilities planned this increment, who could be harmed if the system behaves unexpectedly, and how would they know? This is not a risk assessment — it is an empathy exercise. Teams that can answer this question coherently tend to write better acceptance criteria, ask better questions about edge cases, and treat governance stories as meaningful rather than bureaucratic.
A second cultural practice: make the risk register legible to engineers. Legal and compliance documents are typically written for auditors, not engineers. A team that has never read the risk register for their own system cannot meaningfully contribute to its accuracy. Every quarter, spend thirty minutes in a team session walking through the top three risks in plain language: what the risk is, what is currently being done about it, and whether the team thinks the mitigation is adequate. The answers will often be more honest than what the formal documents say.
Governance by Sprint: A Reference Model
The following is a reference model for a two-week sprint in a team building a high-risk AI system under Annex III. It is not a template to copy mechanically but a starting point to adapt to your team's context.
-
Sprint Day 1Sprint Planning includes governance capacity allocationExplicitly block 10–15% of capacity for compliance stories. Review any regulatory updates since the last sprint (EU AI Act implementing acts, sector-specific guidance).
-
Sprint Days 1–8Development with governance DoD applied per storyRisk register updates, data documentation, and human oversight confirmation are acceptance criteria — not post-sprint activities.
-
Sprint Day 9Compliance stakeholder review of governance artefacts30-minute sync with legal/compliance representative. Not a gate — an alignment checkpoint. Surface any emerging concerns before the sprint review.
-
Sprint Day 10Sprint Review with compliance participantDemo includes a brief governance summary: what changed in the risk register, any incidents, current conformity status. Keeps leadership visibility current.
-
Sprint Day 10 (cont.)Retrospective with governance standing question"Did any governance work slip?" If yes: root cause and resolution. If no: acknowledge it explicitly — this reinforces that the norm is working.
When Governance and Velocity Conflict
The hardest conversations are not about structure or ceremony — they are about what to do when a product manager or business sponsor pushes back on governance work consuming sprint capacity. This happens. It is a natural consequence of organisations that measure teams on velocity rather than compliance-adjusted delivery.
The answer is not to hide governance work in technical stories or deprioritise it silently. The answer is to make the trade-off explicit and escalate it to the right level. A team that makes a conscious, documented, business-owner-approved decision to defer a governance story is in a different legal and operational position than a team that simply forgot to do it.
The Competitive Upside
It is worth ending on a point that often gets lost in compliance conversations: organisations that embed AI governance into their delivery model by default are not just managing risk — they are building a competitive capability. They can respond faster to regulatory evolution (because the compliance infrastructure already exists), they can deploy to regulated customers and markets that require conformity evidence (without a multi-month preparation sprint), and they accumulate the audit trail that increasingly sophisticated institutional clients and regulators will require as a condition of engagement.
Governance-by-design is not a cost centre. In a market where the regulatory bar for AI systems is rising annually, it is a delivery capability that compounds in value with every increment.