EU AI Act and Compliance Sprints: Regulation as Ordinary

Making AI regulation part of the Sprint instead of a gate at the end

The EU AI Act reads like a legal document because it is one, but this module's central claim is that almost everything it requires can be handled as ordinary Sprint work if a team treats risk tiering as a refinement-time question rather than a legal team's separate deliverable. Early lessons cover what the regulation actually asks for in plain language, and a risk-tier classification game that forces teams to place a feature into the correct risk category, since the practical obligations, documentation, human oversight, transparency to users, differ sharply depending on that tier.

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.

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.

Mistakes teams make with this material

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.

Questions people ask

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.