The EU AI Act is the first comprehensive AI law on the planet, and it is already in force: it entered into force on 1 August 2024, its bans on prohibited AI practices applied from 2 February 2025, obligations for general-purpose AI models start on 2 August 2025, and the heavy regime for high-risk systems applies from 2 August 2026. The Act reaches any organisation that puts an AI system into service in the EU or whose system's output is used in the EU — regardless of where the company is headquartered — so most global enterprises are in scope whether they planned for it or not. This article is the practical preparation checklist: how to classify your systems, what the timeline demands by each date, and how to build the governance that makes the Act an operational habit rather than a deadline crisis.
The Evolving AI Regulatory Landscape in 2025
The AI Act is the centrepiece of a regulatory environment that has been tightening for years, and its enforcement posture should be read in context. GDPR, the Act's sister regime, has produced cumulative fines of more than €4 billion across more than 2,000 decisions since 2018, according to DLA Piper's GDPR Fines & Data Breach Survey — evidence that EU regulators, once they have a law, enforce it. The AI Act's penalty scale is deliberately higher: up to €35 million or 7% of global annual turnover for violations of prohibited practices and general-purpose AI obligations, €15 million or 3% for most high-risk system violations, and €7.5 million or 1.5% for supplying incorrect information to authorities. For a multinational, a 7% figure is not a legal fine; it is a board-level financial event, which is exactly why the Act's requirements belong in the annual planning cycle, not the legal inbox.
The scale of what must be governed is substantial. The European Commission estimates that more than 8,500 organisations supply AI systems in the EU, and every deployer — not just the developer — carries obligations: users of high-risk systems must monitor for incidents, keep logs, and cooperate with authorities. Meanwhile the adoption curve keeps climbing: McKinsey's State of AI survey (May 2024) found 65% of organisations regularly using generative AI in at least one function and 72% having adopted AI somewhere, while Gartner's July 2024 research projected that 30% of generative AI projects would be abandoned after proof of concept through 2025, frequently on data-quality and risk-control grounds. The Act lands exactly where those two trends collide: lots of AI running, thin governance around it.
China's Personal Information Protection Law and AI Compliance
For enterprises that also operate in China, the AI Act and PIPL create parallel obligations with the same underlying disciplines. PIPL — in force since November 2021, with fines of up to RMB 50 million or 5% of annual turnover — requires explainable automated decisions, opt-out from personalised recommendations, and dedicated cross-border transfer routes, while China's generative AI interim measures (effective August 2023) add training-data governance and content-safety duties. The AI Act requires risk classification, technical documentation, transparency, and human oversight. The overlap is not coincidence: both regimes operationalise the same ideas — proportionality of risk, traceability of decisions, accountability of deployers — through different administrative machinery.
The practical consequence is that a single design standard serves both. A system built with a documented risk assessment, a model card, decision logging, and a named human-oversight workflow satisfies the AI Act's high-risk documentation duties and simultaneously satisfies PIPL's transparency and explainability requirements. Data minimisation, aggregation, and in-region processing — the techniques that keep Chinese personal data out of the cross-border transfer apparatus — also simplify the AI Act's data-governance requirements for training data. Multinationals that build to the strictest standard once, rather than per-jurisdiction, find that the second and third regulatory regimes cost a fraction of the first, because the artefacts are identical. Enterprises that treat each law as a separate project pay for the same documentation three times — and still end up with inconsistencies between them.
How Do You Classify Your AI Systems Under the AI Act?
Classification is the single most consequential step in AI Act preparation, because everything else — documentation depth, conformity assessment, registration in the EU database — follows from the risk tier. The Act establishes four tiers:
- Prohibited practices — systems that manipulate human behaviour to cause harm, exploit vulnerabilities (including of children), score people socially, use real-time biometric identification in public spaces (with narrow law-enforcement exceptions), scrape facial images, or infer emotions in workplaces and schools; these are banned outright since 2 February 2025
- High-risk systems — systems used in the Act's Annex III areas (employment, education, credit and essential services, law enforcement, migration, critical infrastructure, biometric identification) and safety components of products subject to EU product law; these carry the heaviest obligations
- Limited-transparency systems — chatbots, deepfakes, and emotion-recognition or biometric-categorisation systems with disclosure duties
- General-purpose AI — foundation models and the systems built on them, with transparency obligations for all and systemic-risk duties for models trained above defined compute thresholds
The classification process needs a documented method, because the Act makes no provision for "we did not think it was high risk". Build a classification worksheet per system that records the intended purpose, the Annex III categories touched, the decision's impact on individuals, and the reasoning — signed by the system owner. Run the classification again when the system's purpose or capabilities change, because repurposing a system can change its tier. And keep the register current: the EU's high-risk database registration requirement assumes an accurate, living inventory, and the first thing a regulator will request is the classification documentation, not the strategy slide.
The AI Act Timeline and Your Compliance Roadmap
The Act's phased timeline is also a project plan, and each phase has a deliverable attached:
- Now — inventory and classify — every AI system documented and risk-tiered, with shadow AI (business units' unsanctioned deployments) included, because undeclared systems are the most dangerous ones
- By 2 February 2025 — prohibited practices eliminated — audit for any banned use case and stand down or redesign before the prohibition bites (already in force)
- By 2 August 2025 — general-purpose AI obligations — technical documentation, copyright policy, and transparency summaries for foundation models, plus systemic-risk duties for the largest models
- By 2 August 2026 — high-risk obligations — risk management system, data governance, technical documentation, logging, transparency, human oversight, accuracy/robustness/cybersecurity standards, and EU database registration
- From 2027 — remaining in-scope products — high-risk systems that are safety components of products regulated under EU product directives face their obligations from 2 August 2027
For most enterprises, the critical path runs through the high-risk obligations, and the work should be scheduled backwards from August 2026: standards harmonised under the Act (the Commission has tasked CEN/CENELEC with developing the technical standards) will pin down what "adequate" documentation and risk management mean, so procurement of conformity-assessment capacity and third-party testing slots should start early, because assessors will be a bottleneck across the market. For deployers — organisations using rather than building high-risk systems — the checklist is shorter but real: verify the supplier's documentation, keep usage logs, monitor for incidents, and report serious incidents and malfunction to the authorities. The timeline rewards enterprises that treat each deadline as a release gate: by August 2026, the organisations that started classification in 2025 will be in maintenance mode, while the ones that waited will be in crisis mode, competing for scarce assessment capacity.
Building a Proactive AI Compliance Programme
The AI Act, done well, becomes the backbone of a proactive AI governance programme that outlives any single deadline. The programme has six components: a living system register with risk classification and owners; a risk-management process aligned with the Act's framework (identify, estimate, evaluate, mitigate, verify, monitor) that runs continuously rather than at launch; documentation automation — model cards, technical files, and logs generated by the pipeline rather than assembled by hand for audits; a conformity-assessment track with named assessors for high-risk systems and a calendar for re-assessment when systems change; an incident and post-market monitoring function with defined triggers and reporting obligations; and a horizon-scanning function that tracks delegated acts, harmonised standards, and national enforcement guidance, because the Act's details are still being filled in and the operating requirements will evolve through 2026 and beyond.
Finally, connect the programme to the rest of the business. AI Act compliance intersects procurement (verify vendor documentation before buying), product (transparency disclosures are now product features), HR (hiring for documentation and testing skills), and finance (budget for assessment and testing costs). The enterprises that treat the Act as a compliance department problem will pay for it in penalties and rework; the ones that treat it as a product and engineering standard will discover that the documentation the Act demands — explainability, traceability, oversight — is the same infrastructure that makes AI deployments faster and safer to operate. Preparation is not a countdown to August 2026; it is the process of building an AI operating model that any regulator in any market will recognise as responsible, and that is an asset, not a cost.
How do you determine your AI system's risk classification?
The Act tiers systems as unacceptable, high-risk, limited, and minimal. High-risk covers uses like hiring, credit scoring, and safety components—each carrying obligations for risk management, data governance, documentation, and human oversight. The first step is an inventory that maps every AI use case to a tier.
Beehive Strategy recommends a register with owner, purpose, data, and intended use, scored against the Annex criteria. Most enterprises discover they run more high-risk systems than they assumed, because the definition is broad and purpose-driven, not model-driven.
What documentation does a high-risk system require?
High-risk systems need technical documentation: intended purpose, design, data provenance, risk analysis, and performance metrics. You must keep logs of behavior, enable human oversight, and demonstrate accuracy and robustness. Post-market monitoring and incident reporting round it out.
Treat documentation as living artifacts tied to the model version, not a one-time submission. Regulators expect you to show the system as it runs today, not as it was described at launch.
What should the enterprise checklist contain before enforcement?
The checklist: (1) an AI use-case register with risk tiers, (2) owners assigned per system, (3) data governance evidence, (4) human-oversight design, (5) logging and monitoring, (6) bias and robustness testing, (7) supplier due diligence for third-party models, and (8) a remediation path for non-compliant systems.
Start with the register; everything else hangs off it. Enterprises that began early treat the Act as a governance upgrade, while laggards face a scramble as deadlines arrive.
How do you manage third-party and open-source AI under the Act?
You cannot outsource accountability. For vendor models, require documentation of the provider's conformity and keep evidence; for open-source, assess whether your use case triggers high-risk obligations regardless of who wrote the code. The Act follows the use, not the origin.
Maintain a supplier dossier per system and a clause requiring notification of changes that affect compliance. A model update from a vendor can silently change your risk posture, so the contract must keep you in the loop.
What happens after a high-risk system goes live?
Obligations continue: post-market monitoring catches emerging risks, incident reporting notifies regulators of serious issues, and periodic re-assessment confirms the system still meets requirements as data and context shift. Compliance is a state you maintain, not a launch checkbox.
Assign a permanent owner and a review cadence. The enterprises that treat the Act as operations—not a project—avoid the scramble when an audit or incident arrives.
How do you operationalize the Act across a large, messy AI portfolio?
Large enterprises discover dozens or hundreds of AI use cases, many undocumented. The first operational move is discovery: scan codebases, vendor contracts, and business units to build a use-case register, then triage each against the risk tiers. You cannot govern what you have not enumerated, and most organizations underestimate their true count by a wide margin.
Once registered, assign an owner to every system and route high-risk ones into a compliance workflow with the required artifacts: data governance evidence, technical documentation, human-oversight design, and logging. Lower-risk systems get a lighter path, but none escape the register. This tiered approach keeps the program proportionate instead of uniformly heavy.
Automate the evidence collection wherever possible. Pull model metadata, training-data lineage, and monitoring signals directly from your ML platform so documentation reflects the system as it runs. Manual paperwork drifts from reality within weeks; automated evidence stays true and is what an auditor actually trusts. The Act rewards organizations that made compliance a property of their systems.
What are the common mistakes that sink AI Act programs?
The first mistake is treating the Act as a legal-only problem. Counsel can interpret the regulation, but only engineering can produce the technical documentation and the runtime controls that satisfy it. Programs that exclude the platform team stall, because the evidence lives in systems lawyers cannot reach. Build a joint ownership model from day one.
The second mistake is boiling the ocean: attempting full compliance on every system simultaneously. Prioritize by risk tier and by exposure, and deliver the high-risk register first. A phased program shows progress and builds the muscle the long tail requires. Attempting everything at once usually delivers nothing on time.
The third mistake is treating launch as the finish line. The Act's post-market obligations—monitoring, incident reporting, re-assessment—are where most failures occur, because no one owns them after go-live. Assign a permanent owner and a recurring review, and the system stays compliant as it evolves instead of decaying into violation.
How should smaller teams approach the Act without a large compliance staff?
Smaller organizations can still comply by leaning on automation and templates rather than headcount. Use a lightweight register, adopt a ready-made documentation template mapped to the Act's Annex, and rely on your ML platform's built-in logging and lineage to generate evidence automatically. The burden scales with system count and risk, not with team size.
Prioritize ruthlessly: confirm whether any use case is actually high-risk, because many are limited or minimal and need far less. Spend your thin capacity on the few systems that carry real obligations, and document the rationale for the rest. A focused program beats a sprawling, unfinished one.
