By Editorial — IT Researches
The EU AI Act is now in force in stages, and the practical effect on day-to-day delivery is more concrete than the early commentary suggested. We have been adapting our delivery process to it since the first drafts, and the documentation it requires has settled into a manageable shape. This is a working practitioner's summary, written for engineers and product owners who would like to ship and would also like to be compliant.
The first thing to understand is that the obligations are tiered by risk class, and the classification is not optional. Most systems we work on fall into the limited-risk or high-risk classes; very few fall into prohibited or minimal-risk. The classification has to be documented, with reasoning, before the project begins; we now treat it as a deliverable of the discovery phase.
For high-risk systems, the substantive obligations are: a documented risk-management process across the lifecycle; a data-governance regime covering provenance, quality and bias; technical documentation that allows a competent third party to assess conformity; record-keeping that supports traceability of decisions; transparency to the deployer; human oversight that is operationally meaningful, not nominal; and accuracy, robustness and cybersecurity commensurate with the use. For limited-risk systems the obligations are lighter but not absent; the duty to inform the user that they are interacting with an AI system, and the duty to label generated content, are the ones that most often catch teams out.
Operationally, what this means for our delivery work is a small number of additional artefacts produced as a matter of course. A risk register specific to the AI system, distinct from the general project risk log. A data sheet for each significant dataset, in the spirit of the Gebru et al. data-sheets-for-datasets paper. A model card for each production model, including its intended use, its known limitations and the populations on which it was evaluated. A monitoring plan with named owners and explicit thresholds. An incident-response runbook that names the human in the loop, the rollback path and the notification obligations.
None of these artefacts is novel, and several of them are good engineering practice independent of any regulation. The change the Act has produced is to make them mandatory, to give them a defined audience, and to give the absence of them a regulatory consequence. The practical effect on a well-run project is small; the practical effect on a poorly-run project is to surface, in writing, the gaps that the project would otherwise have ignored.
Two pieces of practical advice from the work we have done on this since 2023. First, treat the documentation as a product, not a tax: write it as you go, version it with the code, and review it on the same cadence. The cost of writing it as you go is a small fraction of the cost of writing it retrospectively before an audit. Second, name a single owner for AI compliance on each project, even if the role is fractional; the diffusion of responsibility for compliance across a team produces, reliably, no compliance at all.
The Act is not the obstacle the early commentary feared. It is, on balance, a moderately competent piece of regulation that has aligned its obligations with practices that the better-run AI teams were already adopting. The teams that find it onerous are mostly the teams whose existing practice was thinner than it should have been. The work it produces is the work that should have been being done anyway.