The most useful sentence I can give you about the EU AI Act is this: it stopped being a legal-team topic the moment the obligations landed rather than loomed, and it became a build problem. Teams treating it as a compliance document to review at the end are the ones doing expensive rework. Teams treating it as a set of constraints on the build are the ones shipping. I've watched both happen this year, and the gap between them is money.
So let me lay out what the Act actually requires, where the legal reading and the engineering reality split, and a posture that works if you're a mid-sized company rather than a hyperscaler with a standing regulatory-affairs function.
The risk tiers, fast
Four buckets, and almost everything downstream depends on which one you're in.
- Prohibited. Social scoring, certain biometric categorisation, manipulative systems. If you're here, the answer is don't.
- High-risk. Systems used in defined sensitive contexts — recruitment, credit, education, critical infrastructure, certain safety components. This is the tier with teeth, and the one most teams wildly underestimate their exposure to.
- Limited-risk. Chatbots, generated content. The obligation is mainly transparency: tell people they're dealing with AI or looking at synthetic media.
- Minimal-risk. Everything else. No specific obligations, though general law still applies.
The trap is assuming you're limited-risk because your product feels low-stakes. The classification follows the use context, not the feeling. A mundane scoring model becomes high-risk the second it's used in hiring or lending. Map your features to contexts early, because the tier sets the cost of everything else.
What "high-risk" actually forces
This is where the legal summary and the engineering reality are furthest apart. The legal version reads "risk management, data governance, documentation, logging, human oversight, accuracy and robustness." Translated into work your engineers actually have to do:
- Logging that's auditable, not just present. Records of what the system did and on what basis, retained and queryable. If your inference path doesn't emit structured, retained logs tied to inputs and model versions, that's a build item, not a config change.
- Data governance you can evidence. Provenance, representativeness, bias testing of training and validation data — documented, not asserted. Most teams can describe their data. Far fewer can produce the artefact proving they examined it.
- Real human oversight. Not a human who can technically click approve, but one positioned and equipped to actually intervene. A rubber stamp doesn't satisfy this, and it's obvious in an audit.
- Documentation maintained as the system changes. This is the one that rots. Docs written once at launch are wrong within two release cycles.
The theme runs through all four: every one is cheap if it's in the pipeline and ruinous if you reconstruct it afterwards. You cannot retrofit a year of audit logs you never wrote.
General-purpose models and the transparency layer
If you build on general-purpose models — most of us do — obligations sit both upstream and on you. Providers of the large models carry their own documentation and transparency duties. But you don't get to outsource your end. You still disclose AI interaction and synthetic content where the limited-risk rules apply, and if your use sits in a high-risk context, the provider's compliance does not discharge yours. Get clear contractually on what the model provider hands you — model cards, evaluation data, the documentation you can actually rely on — because the gaps become your problem at audit time.
The posture for a mid-sized company
You don't have a hyperscaler's headcount. So buy nothing you can build into the pipeline, and build the cheap controls now instead of the expensive ones later.
- Classify first, once, properly. A half-day mapping features to tiers saves months. Most of your surface is probably minimal or limited-risk; concentrate the effort on the genuinely high-risk slice.
- Make logging and versioning a platform capability, not a per-feature scramble. If model version, inputs, outputs and the oversight decision are captured by default, compliance for new features becomes near-free. Highest-leverage thing you can do.
- Treat documentation as generated, not authored. Pull model cards, eval results and data lineage from the systems that already produce them. Hand-maintained docs drift. Derived docs don't.
- Put one accountable owner on it. Not a committee. Someone who owns the classification and the evidence and updates both as the product changes.
Governance is a product problem
Here's the framing I keep coming back to. People file the AI Act under legal risk, alongside GDPR or a SOC 2. Category error. The obligations — logging, oversight, data governance, documentation — are all properties of how the system is built and run. They live in the pipeline. Which makes them an engineering responsibility that legal verifies, not a legal responsibility that engineering occasionally helps with.
Bake it in and the marginal cost per feature trends towards zero. Bolt it on and you pay twice: once to build the feature, again to reconstruct the evidence it was built responsibly. The Act didn't create that choice. It just made the bill for the wrong one payable.
