AI Act compliance consulting turns Regulation (EU) 2024/1689 into engineering work: classifying your AI systems by risk, finding the gaps against the obligations that apply to them, and building the logging, evaluation and documentation controls those obligations require. It reaches any organisation that provides or uses AI systems in the EU market, wherever it is headquartered. Obligations for high-risk systems listed in Annex III apply from 2 August 2026. This guide is written for the people who own that date: compliance officers, CTOs and heads of AI who need to buy implementation, not a memo. It is not legal advice; interpretation of the regulation belongs with your lawyers.
What AI Act Compliance Consulting Covers
The work runs in phases, and each phase has an output you can inspect. It starts with a system inventory: every model, pipeline and third-party AI feature in production or procurement, each with a named owner. Risk classification comes next, mapping every system against the regulation's categories and recording the reasoning so an auditor can retrace it. A gap assessment then compares the controls an in-scope system already has, from logging through to human oversight, against what its risk class requires. The output is a remediation roadmap: a prioritised backlog of engineering work, each item with an effort estimate.
Remediation is where most of the budget goes: audit logging, evaluation harnesses, documentation pipelines and oversight controls built into systems that were designed without them. AI model governance services cover that build phase. The last phase, operational handover, puts your own engineers in charge of running the controls once the consultants leave. If a proposal you are evaluating stops at the gap assessment, you are buying a diagnosis, and the treatment will be a second contract.
The AI Act Timeline: What Applies When
The regulation entered into force on 1 August 2024 and applies in stages. Since 2 February 2025, prohibited practices are banned and AI literacy obligations apply. Since 2 August 2025, obligations for general-purpose AI models apply, along with the governance structure and the penalties regime. On 2 August 2026, the obligations for high-risk systems listed in Annex III take effect. General-purpose AI models placed on the market before 2 August 2025 have until 2 August 2027 to comply, and high-risk systems used by public authorities have until 2 August 2030.
Work backwards from 2 August 2026. Confirm the inventory and the legal role you hold for each system first, then buy remediation only for what survives that filter.
Does the AI Act Apply to You? Risk Classification in Practice
The AI Act is risk-based regulation: obligations attach to what a system is used for, not to the technology inside it. The four risk levels are unacceptable risk (prohibited practices, such as social scoring), high risk (systems used in areas such as employment, credit or education), limited risk (transparency duties, such as telling users they are talking to a machine) and minimal risk (no new obligations).
Two consequences matter for scoping. First, the regulation reaches beyond the EU: it applies to providers placing AI systems on the EU market and to organisations whose system outputs are used in the EU, regardless of where the company is established. Second, your role determines your obligations. A provider develops a system and places it on the market, and carries the full set of high-risk obligations. A deployer uses an AI system under its own authority and carries a narrower, operational set. Most enterprises are both, on different systems, which is why an AI Act compliance consulting engagement begins with an inventory of what you actually run.
High-Risk Obligations as Engineering Deliverables
EU AI Act Articles 9–15 map high-risk provider obligations to auditable production controls. Each deliverable below covers part of one obligation and produces evidence an auditor can check; whether the control environment as a whole satisfies the regulation is a call for your counsel. An audit asks whether an artefact matches what runs in production, so the third column records the proof that each one is current.
The third column is where compliance programmes fail. A repository is not a controlled document: teams ship model v2.7 while the evaluation report describes v2.3 and the technical documentation describes v2.1. The real deliverable behind that column is the mechanism that keeps artefacts in step with production, usually release gates plus documentation versioned against the release. Much of the Article 10 work builds on the data governance for AI an organisation should have anyway.
Articles 9–15 bind providers. Deployers of high-risk systems have a separate, narrower regime under Article 26: retaining the logs the system generates, assigning oversight to people with the competence and authority to intervene, using the system in line with the provider's instructions, and reporting serious incidents. An AI Act compliance consulting scope should state which role each system puts you in, because buying provider-grade controls for a system you merely deploy wastes budget, and the reverse leaves you exposed.
What a Compliance Engagement Produces
A statement of work you can hold a vendor to names three things per phase: the inputs you provide, the artefact the vendor delivers, and the acceptance criterion that says when it is done. Inputs are your side of the contract, which means access to repositories and pipelines, a complete list of systems, and named owners with decision authority. Classification decisions in particular stay on your side of that line. Acceptance has one practical test: your own engineer, with nobody from the vendor in the room, takes a sampled production decision and reproduces it from the deployed model version, its data lineage, its evaluation record and its override path. A system that passes that test has a named owner, an approved role classification, tested controls and evidence that matches production.
Monitoring is part of that scope, not an aftercare option. Documentation, evaluations and risk registers hold only while they describe the system actually running, so the engagement has to leave behind drift monitoring and release gates that fire when production moves away from what the artefacts claim. AI governance tooling automates much of that synchronisation. Tools maintain evidence; the scope decisions and the compliance judgement stay with you. The final deliverable of AI Act compliance consulting is an operating state: your team runs the controls, and evidence of currency comes out of shipping software rather than getting assembled in the weeks before an audit.
Where GenAI, RAG and Fine-Tuned Models Fit
Most enterprise GenAI systems are built on general-purpose AI models supplied by someone else. The model provider carries the general-purpose obligations that have applied since August 2025; your obligations depend on what you do with the model and what the resulting system is used for. Treat an upstream version bump the way you treat a change in your own code: re-run the evaluation harness, refresh the affected artefacts. A RAG assistant answering HR policy questions and one screening job applications can share the same enterprise RAG architecture blueprint. The second sits in Annex III territory; the first typically does not. The use case sets the risk class, and the stack underneath gets no say in it.
Fine-tuning and heavy modification raise a second question: role. If your organisation changes a system's intended purpose or takes responsibility for placing the modified system on the market, pause implementation and obtain legal role classification before scoping provider-grade controls. That call belongs to counsel, and the engineering scope only becomes clear once it is made. What AI Act compliance consulting adds is generative AI governance sized to the confirmed role: transparency and oversight controls for deployers, the full Articles 9–15 stack where your organisation is the provider.
How to Choose an AI Act Compliance Partner
Law firms interpret the regulation, and you need one. Large advisory firms build board-level programmes. Do not assume either proposal includes writing the logging middleware or the evaluation harness. If the statement of work does not name engineering deliverables, price that work separately. Five questions separate an AI Act compliance consulting partner that delivers implementation from one that delivers a report:
- Who on the team has merged code into a production ML system in the last year?
- Can you show an anonymised remediation backlog from a past engagement, at the level of engineering tickets?
- How do you keep documentation synchronised with model releases after you leave?
- Which of our systems would you classify as out of scope, and what would you refuse to build?
- What do you hand over, and what breaks if we end the contract early?
The last two are the informative ones. A partner willing to shrink scope is optimising for your outcome; one that treats every chatbot as high-risk is optimising for the size of the statement of work. Where compliance is one strand of a wider platform effort, enterprise AI transformation work can absorb the same controls into a broader roadmap.
Classification and gap assessment take weeks, remediation takes months, and August 2026 does not move. If you want the assessment and the engineering delivered by one team, talk to our AI governance team.
FAQ
When do high-risk obligations start to apply?
Obligations for high-risk systems listed in Annex III apply from 2 August 2026. High-risk systems already used by public authorities have a longer transition, until 2 August 2030. An AI Act compliance consulting engagement should be scoped backwards from the earlier date: classification and gap assessment first, so the engineering remediation fits in the time remaining.
Does the AI Act apply to companies outside the EU?
Yes. The regulation applies to providers placing AI systems on the EU market and to organisations whose system outputs are used in the EU, regardless of where the company is established. A US or UK company selling into the EU carries the same obligations as an EU-based provider for those systems.
What are the penalties for non-compliance?
The highest tier applies to prohibited practices under Article 5: fines of up to EUR 35 million or 7% of global annual turnover. Breaches of high-risk obligations fall into a lower tier of fines. Commercial exposure can arrive before the regulatory one, because a buyer's procurement process may require compliance evidence independently of the statutory deadline.
Is our RAG chatbot considered high-risk?
The architecture does not decide; the use case does. A retrieval-augmented chatbot answering product questions falls under transparency duties. The same stack used for recruitment screening, credit decisions or another Annex III purpose is high-risk, and the provider obligations follow. Classify each deployment separately before assuming the answer.
.webp)
