The cost of waiting
A common position in compliance functions right now is that it is too early to act: the harmonised standards are not final, guidance is still emerging, and building to a moving target risks wasted work.
The reasoning is understandable and the conclusion is usually wrong. Most of what the EU AI Act requires is not novel. It asks organisations to know what AI systems they operate, understand what those systems do, assess their risks, document their design decisions, test them, monitor them in production, and keep records that demonstrate all of the above.
None of that depends on the final wording of a technical standard. Organisations that begin this groundwork now will spend the transition period refining a working system. Organisations that wait will spend it building one from nothing, under deadline, with the same scarce specialists everyone else is trying to hire.
Start with classification
The Act's obligations scale with risk category, so classification is the first substantive task and the one most likely to produce surprises.
Two patterns recur. The first is organisations discovering they operate more AI than they thought, typically embedded in purchased software where the vendor markets a feature rather than a model. The second is discovering that a system assumed to be low-risk falls into a high-risk category because of the decision it informs rather than the sophistication of the technique. A simple rules-based tool used in recruitment screening carries obligations that a sophisticated model used for internal document search does not.
This is why classification cannot be delegated to a technical team alone. It requires someone who understands both the system and the regulatory framing of its use.
Obligations that flow from your supply chain
Most organisations will be deployers rather than providers, which is often read as a lighter obligation. In practice it introduces a harder problem: you inherit responsibility for a system whose internals you cannot fully inspect.
You will need to know what the model was trained on, how it was evaluated, what its documented limitations are, and how you will be told when it changes. Very little of that is obtainable after contract signature if you did not ask for it beforehand.
This is the single most actionable step available today. Procurement language for AI systems can be updated now, without waiting for any further guidance, and it determines what evidence you will be able to produce later.
Documentation is a design constraint
The Act's record-keeping requirements are demanding, and organisations consistently underestimate them because they think of documentation as something produced at the end.
Technical documentation, risk management records, data governance evidence, and post-market monitoring logs all describe decisions made during development. Reconstructing that record afterwards is expensive and often impossible; nobody remembers why a threshold was set at 0.7 eighteen months later.
Treating documentation as an output of the development process, generated as decisions are taken, is far cheaper than treating it as a compliance deliverable. It also produces better evidence, because contemporaneous records are more credible than retrospective ones.
Build capability, not just a project
The most common failure pattern is running AI Act readiness as a time-boxed programme that ends at the compliance deadline.
The Act imposes continuing obligations: monitoring systems in production, responding to incidents, keeping documentation current as models are retrained. A programme that disbands on the deadline leaves nobody accountable for any of it.
The organisations that will handle this well are building durable capability, which means people with the knowledge to make these judgements as part of ordinary operations rather than as a special exercise. That is a slower investment than a compliance sprint, and a considerably more useful one.
If you are mapping regulatory obligations to audit evidence, the AAAP certification covers that methodology directly.
