Ninety days is enough for most small and mid-sized businesses to reach a defensible EU AI Act position: weeks 1-2 inventory, weeks 3-4 classification and prohibited-practice screening, weeks 5-8 vendor evidence and deployer controls, weeks 9-11 transparency and training, weeks 12-13 assembly of the audit file and handover to routine operations.
EU AI Act 90-Day Compliance Roadmap for Businesses
What Can Realistically Be Done in 90 Days
A 90-day programme will not take a brand-new high-risk product through conformity assessment; that is a longer engineering effort. What it reliably achieves, for the majority of businesses whose role is deployer plus perhaps provider of lower-risk tools, is a complete, documented, defensible compliance position under Regulation (EU) 2024/1689: every AI system found and classified, prohibited practices screened out, vendor evidence collected, oversight and logging in place for high-risk deployments, transparency fixed on public-facing AI, staff trained, and the whole story filed where an authority or enterprise customer can be answered within a day. This roadmap assumes a small core team, one accountable owner, plus part-time help from IT, HR, and whoever manages vendors, and it is sequenced so that the legally live items come first.
The Plan at a Glance
| Phase | Days | Outcome |
|---|---|---|
| Discover | 1-14 | Complete AI inventory with owners |
| Classify and screen | 15-28 | Risk tier per system; Article 5 clearance; role map |
| Control | 29-56 | Vendor evidence, oversight, logging, FRIA where needed |
| Communicate | 57-77 | Transparency fixes, worker notices, literacy training |
| Consolidate | 78-90 | Audit file, gaps register, routine operations handover |
Days 1-14: Find Everything
The inventory is the foundation, and the common failure is stopping at the obvious tools. Cast four nets. Survey team leads with a concrete question, which tools that suggest, predict, generate, score, or rank does your team use, naming categories like chatbots, writing aids, screening tools, and forecasting. Pull the procurement and expense records for software subscriptions and check each product page for AI features. Ask IT for single sign-on and browser-extension data revealing unsanctioned tools, the shadow AI layer. And list AI features inside incumbent platforms, CRM lead scoring, helpdesk suggestions, HR suite parsing, since these are the most-missed items. Record per system: name, vendor, purpose as actually used, data involved, users, and a named business owner. Close the phase with a leadership note announcing the programme and the rule that new AI tools now pass through an intake check, because the inventory starts decaying the day it is finished.
Days 15-28: Classify and Screen
Run each inventory line through the decision sequence. First the Article 5 screen, the only step with immediate legal force: does anything perform emotion inference on employees or students, vulnerability-targeted manipulation, social scoring, sensitive biometric categorisation, or facial-image scraping? Vendor features rarely use those names, so screen by function, engagement analytics, attention tracking, wellness scoring. Anything caught stops now. Second, high-risk mapping: does the system serve employment decisions, credit, education assessment, essential services, biometrics, or other Annex III purposes? Mark these for the control phase. Third, transparency triggers: customer-facing bots and content generation. Everything else is minimal risk. In parallel, fix your role per system, deployer for bought tools, provider where you sell or substantially modify, since duties follow roles. Document every conclusion with two sentences of reasoning and a date; this fortnight produces the single most-requested artefact in the whole programme.
Days 29-56: Build the Controls
Four workstreams run in this month. Vendor evidence: for every high-risk tool, request in writing the instructions for use, classification reasoning, conformity status, logging capabilities, and incident notification commitments; start now because vendor latency is the schedule's main risk. Oversight: for each high-risk deployment, name the human overseers, give them authority to suspend the system, and train them on its instructions, limitations, and failure signs, recording the training. Logging: configure retention of automatically generated logs for at least six months, checking that default settings do not silently delete earlier. Assessments: where you are a public body, an essential-services provider, or use AI for credit scoring or life and health insurance pricing, complete the fundamental rights impact assessment before continued use, building on any existing DPIA. If you are a provider of a high-risk product, this phase instead triages the documentation and conformity gap and produces a realistic engineering plan that extends beyond the 90 days, with registration and assessment milestones booked.
Days 57-77: Fix What People See and Know
Transparency first. Every customer-facing bot discloses its artificial nature at the start of interaction unless context makes it obvious; check that redesigns have not stripped earlier notices. Synthetic media and generated text published to inform the public carry the required marking or disclosure, with the human-editorial-review exception documented where relied on. Deepfake-capable workflows get a standing disclosure rule. Then people. Deliver the AI literacy training in role-sized portions, general awareness for all staff using AI, deeper modules for overseers of high-risk systems, and record completion. Where high-risk AI operates in the workplace, inform workers and their representatives before continued use, in plain language: what the system does, what it influences, who oversees it, and how to raise concerns. Finish the phase by updating external-facing documents, privacy notices that mention automated decision-making, and customer contracts where your tools embed AI.
Days 78-90: File, Register, Hand Over
Assemble one audit file: the inventory with classifications and reasoning, the Article 5 screening record, role map, vendor correspondence and documents received, oversight appointments and training logs, log-retention configuration evidence, assessments, transparency screenshots, worker notices, and training records. Alongside it, write the honest gaps register: items still open, vendor responses outstanding, provider-side engineering still running, each with an owner and date, because a documented gap with a plan reads entirely differently from an undocumented one. Then convert the project into routine: AI intake check in procurement, reclassification trigger on new uses and major updates, quarterly inventory refresh, and an annual training cycle. Brief leadership on the end state and residual risks. The closing test of the 90 days is simple: if a customer questionnaire or an authority letter arrived tomorrow, could you answer from the file within a day? If yes, the roadmap did its job.
Effort Budget: Who Does What and for Roughly How Long
The roadmap fails most often when it is assigned as a side note to people with full calendars, so it helps to put indicative planning figures on the table from day one. For a typical mid-sized organisation whose role is mainly deployer, the load looks like this.
| Role | Main phases | Indicative effort |
|---|---|---|
| Programme owner | All five phases | About half a day per week for the full thirteen weeks |
| IT or security lead | Discovery, logging configuration | Three to five days in total |
| Vendor or procurement manager | Control-phase correspondence | Two to four days, spread out |
| HR lead | Worker information, training rollout | Two to three days |
| Team leads | Inventory survey, intake adoption | One to two hours each |
| Leadership | Kickoff note, final briefing | Two short sessions |
The total for a deployer-mostly organisation lands around twenty-five to forty person-days across the quarter, modest next to the cost of a single stalled enterprise deal that a missing compliance answer can cause. The largest schedule variable is not internal effort but vendor latency, which is why the roadmap front-loads every external request into the first half.
The Five Most Common Stalls and How to Clear Them
Vendor silence is stall one: escalate through the account manager rather than the support queue, set a written response date, and record the request trail in the gaps register, because a documented unanswered request reads very differently from no request at all; for a high-risk tool, persistent silence is itself decision-relevant information about the vendor. Stall two is inventory sprawl, when discovery finds so many minor tools that classification bogs down: timebox the phase and rank by consequence, putting systems that influence decisions about people first and writing aids last. Stall three is classification debate, with teams arguing borderline cases for weeks: write the two-sentence reasoning for the more cautious answer, mark the item for review when official guidance clarifies the point, and move on. Stall four is training fatigue: keep modules role-sized, minutes for general staff and depth only for overseers, and fold them into onboarding so the effort happens once. Stall five is the ownership vacuum, a committee with no single accountable name: the fix is structural, one owner with a leadership mandate, since shared ownership of a 90-day plan reliably produces a 180-day plan.
Adapting the Roadmap to Your Position
A pure deployer of minimal-risk tools can compress the whole arc to roughly half: discovery and the Article 5 screen stay, the control phase shrinks to vendor letters for the few tools that matter, and the file is thinner but follows the same skeleton. A provider of a high-risk system should read the 90 days as triage plus planning: the inventory, screening, and transparency work still complete, but technical documentation, the quality management system, conformity assessment, and registration form an engineering programme measured in months, and it should leave day 90 as a booked plan with milestones rather than an apology. A non-EU company serving EU customers adds one workstream: confirm scope, since the Act reaches providers and deployers outside the EU when the system's output is used in the EU, and appoint an authorised representative where that is required for high-risk provision. Public bodies and essential-services operators must anchor the schedule to the fundamental rights impact assessment, which belongs before continued use, not in the consolidation phase.
What Day 91 Looks Like
The end state is not a binder but a routine. New tools enter through the intake check in procurement; classifications refresh quarterly and reopen whenever a use case or a major update changes the picture; log retention is checked rather than assumed; training runs on an annual cycle with records; and the gaps register is reviewed monthly until it empties. The audit file answers a customer questionnaire or an authority letter the same day, which over time is worth more in won deals than the whole programme cost. The steady state typically consumes a small fraction of the build effort, which is the strongest argument for doing the build once, properly, rather than re-running a crisis version of it after the first hard question arrives.
Check your AI compliance readiness — free.
Take the Readiness Check 3 minutes · 10 questions · no signup requiredThis article is for informational purposes only and does not constitute legal advice. Regulatory requirements change frequently — verify current rules with official sources. Built by Sawai Gyoseishoshi Office, Hiroshima, Japan.