We've seen two standard reactions to the EU AI Act. One is paralysis: freeze every AI initiative until legal says otherwise. The other is paperwork: commission a thick compliance report that describes systems as they were the month it was written, then goes stale in a drawer. Neither ships anything, and neither actually reduces risk.
We treat the Act the way we treat any other requirements document: read it, break it down, and turn it into backlog items with owners and acceptance criteria. This note is how that translation works, the same way whether the buyer is a manufacturer putting AI into a product line or a municipality putting it into a citizen-facing process.
Inventory before classification
You cannot classify what you haven't found, and every organisation we've looked at has more AI in use than its architecture diagram admits: a vendor feature that quietly became "AI-powered", a script a team relies on, a model inside a machine the supplier never mentioned. So the first ticket is never "classify our systems". It's build the inventory: one list of every system that learns, predicts, scores, or generates, with an owner, a purpose, and the data it touches. A no-blame rule matters here: the AI your staff already lean on only surfaces if admitting it is safe.
Classify per system, and write the reasoning down
The Act is tiered: prohibited practices, high-risk systems, transparency obligations, and everything below. Classification is done per system, against its actual use, not against the vendor's marketing category. The output that matters is not the label; it's the written reasoning. "We classify this as limited-risk because…" is the artifact a regulator, an auditor, or your own successor will ask for, and the borderline calls (there are always borderline calls) are exactly the ones worth documenting while the reasoning is fresh.
Each classification becomes a ticket with a named owner and a review trigger: reclassify when the use case, the data, or the model changes.
Data lineage is a pipeline property
Lineage kept in a spreadsheet is wrong within a quarter, because someone has to remember to update it. We make lineage something the pipeline emits: every training run records which dataset version went in, which transformations ran, and which model artifact came out, automatically, as build metadata. The engineering ticket is not "document our data flows". It's "make the pipeline record its own data flows", which is a week of instrumentation that stays correct forever after.
Model cards live in the repo
A model card delivered as a PDF is stale on arrival. Ours are files in the repository (intended use, training data summary, evaluation results, known limitations), regenerated from the registry on every training run and versioned together with the code that produced the model. When the technical-documentation obligations apply, the evidence is a git log away, not an archaeology project.
Audit logging a regulator will accept
"We log everything" usually means "we log nothing usable". The ticket has concrete acceptance criteria: for each in-scope decision, record the input, the output, the model version, and the timestamp; retain per the agreed schedule; make the trail append-only; and log human-oversight events (who reviewed, who overrode, and when), with the same care as the model's own outputs. That last part is where high-risk obligations meet daily operations, and it's cheap to build early and painful to retrofit.
Evidence produced as you ship
Run the translation this way and something useful happens: compliance stops being a project and becomes a property of the pipeline. Every training run updates the model card, every deployment extends the audit trail, every architecture change re-triggers a classification review. The evidence pack a regulator asks for is a byproduct of shipping, produced as you ship, not a months-long excavation after the letter arrives.
A compliance requirement that never becomes a ticket never becomes true.
For a manufacturer, this is what makes AI in the product line survivable next to existing machinery and safety obligations. For a public-sector buyer, it's something stronger: the ability to show a citizen, not just a regulator, exactly how a system that affects them works. Both are engineering outcomes. Both fit in a backlog.