EU AI Act Compliance Consulting
Most organisations do not know which of their AI systems the Act covers, and that uncertainty is the expensive part. We establish scope system by system, classify each one by what it is used for, and map the obligations that genuinely follow. Often the useful finding is that less is in scope than feared.
Guesswork vs. a Scope Assessment
| Area | Common Approach | Structured Assessment |
|---|---|---|
| Scope | Assumed — either everything or nothing | Established per system, including extraterritorial reach |
| Risk classification | Guessed from the technology used | Assessed against the Act's purpose-based categories |
| Obligations | Read from a generic checklist | Mapped to your specific systems and your role for each |
| Evidence | Assembled when someone asks | Produced as the system is built, and kept current |
| Third-party models | Assumed to be the vendor's problem | Deployer duties separated from provider duties |
Scope First, Because Most of It Is Not High-Risk
The Act classifies by purpose rather than by how a system was built. That surprises teams who expect the size or sophistication of a model to determine its treatment.
In practice a good deal of enterprise AI sits outside the high-risk categories — internal search, forecasting, document processing, productivity tooling. Establishing that early stops you spending on controls you do not need, which is a real and common cost of reacting to the Act rather than assessing it.
Where systems are in scope, the obligations are largely documentation of practices a well-run project already follows. The usual gap is not that the work was done badly. It is that nobody wrote it down at the time, and reconstructing it afterwards is far harder.
Build the Evidence While You Build the System
Compliance evidence assembled retrospectively is expensive and weak. Nobody remembers why a threshold was chosen eighteen months ago, or which data version trained the model that is running now.
Captured as you go, the same material costs very little — data lineage, evaluation results, the reasoning behind design decisions, and who signed off. That is also what makes a system maintainable, which is why we treat it as engineering practice rather than a compliance overhead.
This pairs directly with how we take work from proof of concept to production, where the same documentation discipline is what separates a pilot from a system you can run.
Frequently Asked Questions
Does the EU AI Act apply to us if we are not in the EU?
Quite possibly. The Act reaches providers and deployers outside the EU where the system is placed on the EU market or its output is used in the EU. A model built in India and used by an EU customer can bring you into scope. This is the single most common reason organisations discover late that it applies to them.
How do we know which risk category our system falls into?
By its purpose, not its technology. The Act classifies by what the system is used for — a small model doing something the Act treats as high-risk carries more obligations than a large one doing something unregulated. Classification is the first piece of work, because everything after it depends on getting it right.
Is most of what we build actually high-risk?
Usually not, and that is worth establishing early. A great deal of enterprise AI — internal productivity tools, forecasting, document search — sits outside the high-risk categories entirely. Assuming everything is high-risk leads to spending on controls you do not need, which is its own kind of failure.
What does compliance actually require us to produce?
For high-risk systems, broadly: documented risk management, an account of your training data and its governance, technical documentation, logging, transparency to deployers, human oversight, and evidence of accuracy and robustness. Most of that is documentation of things a well-run project does anyway — the gap is usually that nobody wrote it down.
We already do model governance for financial regulation. Does that count?
It gives you a strong head start. Model risk management frameworks cover much of the same ground — validation, monitoring, documentation, accountable owners. The mapping is rarely one-to-one, so the work is identifying where your existing evidence satisfies an obligation and where a genuine gap remains, rather than building a parallel regime.
What if we use third-party models rather than building our own?
You still hold obligations, and they differ from the model provider's. Deployers carry duties around use, oversight and transparency even when someone else built the model. Knowing which obligations are yours and which sit upstream is a large part of what a scope assessment is for.
This page is general information about how we approach AI Act readiness. It is not legal advice, and obligations depend on your specific systems, your role in the supply chain and your markets. We work alongside your legal counsel rather than in place of them.
Start with a scope assessment — you may be in scope for less than you think.
Get a Free Proof of Concept within weeks.
Let’s talk
AI is here to stay
Let’s win together
Your first 45-min alignment session — and a small PoC — are free.
Or just say hello or write us an email.