1.Why EU AI Act & Compliance Sprints is worth getting right
A recurring theme is writing AI Act obligations as acceptance criteria rather than as a phase that happens after a feature is otherwise complete. If a feature requires a disclosure that a user is interacting with an AI system, that disclosure belongs in the same Definition of Done as any other functional requirement, checked at the same Sprint Review, not verified separately by a compliance function weeks after release. A decision lab scenario walks through a feature that turns out to sit in a higher risk tier than the team assumed at planning time, forcing a mid-Sprint conversation about what changes as a result.
2.How it works in practice
The module closes on supply chain obligations, since many teams building on top of third-party or open-weight models inherit compliance responsibilities from their upstream provider's own documentation, and on monitoring obligations that continue after release, transparency and incident reporting that need to be built into the product rather than retrofitted. The framing throughout treats audit evidence the same way the DevSecOps module treats it: a natural byproduct of doing the work properly during the Sprint, not a document assembled under deadline pressure later.
3.Role reality
Compliance training talks about the regulation. Delivery teams have to talk about which item on the board it changes.
| Textbook theory | Delivery reality |
|---|---|
| Risk classification is a legal team decision. | Legal sets the framework, but the team classifies each feature during refinement, because they are the ones who know what it actually does. |
| Compliance is a gate before release. | A gate at the end finds problems too late to fix cheaply. Obligations belong in acceptance criteria from the first Sprint. |
| Documentation is paperwork produced afterwards. | Documentation produced afterwards is usually wrong. Evidence should be a by-product of the Definition of Done, generated as the work happens. |
| Third party models are a procurement concern. | Model supply chain documentation is a delivery concern the moment that model sits inside a Sprint's Increment. |
| Monitoring starts after go live. | Post-market monitoring has to be designed and built inside the same Sprints that build the feature, or it never gets built at all. |
4.Core delivery pillars
The disciplines that keep a Scrum team compliant without becoming a compliance department.
Every AI-touched Product Backlog item gets a risk tier label before it is ready for a Sprint. Unclassified items are not refined enough to pull.
Logging, human oversight hooks and dataset documentation are acceptance criteria on the item itself, so the evidence exists the moment the Increment ships.
Third party and open source models get the same scrutiny as a code dependency: version, licence, known limitations and an owner who reviews updates.
Drift detection and incident reporting are part of the feature, not a follow-up ticket that never gets prioritised once the feature ships.
5.Compliance health signals
Days between an AI feature entering refinement and getting a confirmed risk tier. Long lag hides risk until release.
Share of shipped AI items with full audit evidence generated at Definition of Done, not reconstructed later.
Share of models in production with an up to date documentation record and a named owner.
Time from a high-risk feature going live to its post-market monitoring being active. Zero is the target.
6.Situations you will be asked to handle
The module puts you inside 4 decisions rather than asking you to recognise the right answer on a list. Each one is a situation practitioners meet, with several defensible options and consequences that follow from the one you pick. The scenarios below are the shape of the judgment the subject demands.
- Lesson 26.3: Game - classify the risk tier
- Lesson 26.6: Game - evidence or theatre
- Lesson 26.7: Decision lab - launch date against a conformity gap
- Lesson 26.10: Decision lab - the auditor asks for data lineage
7.Common mistakes and why they fail
Treating risk tiering as a legal team's job, decided outside the Sprint
Skipping the risk classification during refinement and letting a separate compliance review discover it later, after design decisions that depend on the tier have already been locked in.
Writing AI Act obligations as a follow-up task instead of an acceptance criterion
Shipping a feature and adding required disclosures or documentation afterward, rather than including them in the same Definition of Done the feature is measured against.
Ignoring inherited obligations from a third-party or open-weight model
Assuming compliance responsibility stops at your own code, when using a third-party model can carry supply chain obligations the team needs to actively check rather than assume away.
Treating monitoring and incident reporting as launch-day-only concerns
Building transparency and reporting mechanisms only for the initial release, without maintaining them as an ongoing part of the product that survives past the first Sprint Review.
8.Questions worth asking before you commit time to this
When should a team classify a feature's AI Act risk tier?
During refinement, before the feature enters a Sprint, not after it is built. The tier determines what documentation, oversight, and disclosure the feature needs, and those requirements shape the design, so discovering the tier late means redoing work.
How do AI Act obligations fit into a Definition of Done?
As explicit acceptance criteria alongside functional requirements. A required user disclosure or documentation artifact is part of what makes the feature done, checked at the same Sprint Review as everything else, not handled by a separate compliance step after release.
Does using a third-party AI model remove a team's compliance obligations?
No. Using someone else's model can add supply chain obligations on top of your own, since you need to understand and often document what the underlying provider has already established about the model's risk profile and limitations.
What ongoing work does the AI Act require after a feature ships?
Monitoring and incident reporting mechanisms that continue past launch, not just at release. These need to be built as durable product capabilities during the Sprint that ships the feature, not treated as a one-time compliance checkbox.
9.What to remember
- Classifying AI risk tiers during refinement instead of after the audit request
- Building a Definition of Done that generates evidence as a side effect of delivery
- A situational matrix for supply chain documentation and post-market monitoring
10.Where this sits in the Scrumling course
Turn AI regulation into ordinary Sprint work: risk tiers in refinement, obligations as acceptance criteria, and audit evidence as a by-product of delivery.
About 80 minutes of lessons and decision scenarios.
- Lesson 26.1: What the AI Act actually asks of a delivery team
- Lesson 26.2: Risk tiers belong in refinement
- Lesson 26.4: Compliance as backlog items, not a phase
- Lesson 26.5: Definition of Done for regulated AI features
- Lesson 26.8: Transparency obligations and the user-facing Increment
- Lesson 26.9: General purpose models, vendors and the supply chain
- Lesson 26.11: Post-market monitoring and incident reporting
- Lesson 26.12: Review and Retrospective with compliance in the room
- Lesson 26.3: Game - classify the risk tier
- Lesson 26.6: Game - evidence or theatre
- Lesson 26.7: Decision lab - launch date against a conformity gap
- Lesson 26.10: Decision lab - the auditor asks for data lineage
Assessment: EU AI Act & Compliance Sprints quiz