EU AI Act assurance

Know exactly what the EU AI Act asks of you — and prove it.

Tell us about your AI system. We show you the requirements that apply, help you gather the evidence, and check that it holds up — then issue a certificate you can stand behind.

Get started → See how it works

The EU AI Act sets a shared standard for AI that's safe, fair, and transparent. We think that's worth getting right — and we make getting it right simple.

EU-hostedIndependentEvidence-based

Are you looking at a certificate? Verify a certificate → Validate its authenticity in seconds — no account needed.

Requirements for your systemAI system · deployer

ART. 5Prohibited-use checkChecking…

ART. 10Data & governanceChecking…

ART. 13TransparencyChecking…

ART. 15AccuracyChecking…

ART. 14Human oversightChecking…

Evidence checkedEU-hosted

How it works

From scattered documents to a clear path.

Five steps — just the requirements that apply to you, and a straight route to evidencing them.

Tell us about your system

A short set of questions about what it does and how it's used.

See what applies

We map the Act to your system, so you work from your requirements.

Add your evidence

Attach what you already have — documents, links, notes.

We check it

Our EU-hosted assessment shows where it's solid and where there's a gap.

Get your certificate

Evidence that holds up, in a certificate you keep current each year.

See the full process →

Two ways to work

Simple where it can be. Serious where it must be.

On the platform

Straightforward systems

Most systems — especially lower-risk ones — can be handled start to finish yourself. Explore before you commit to anything.

With our experts

Complex & high-risk systems

For systems that carry more weight and more scrutiny, our specialists work alongside you.

Security & your data

Built to keep your evidence in the EU.

Everything runs in the EU

The platform and the AI that assesses your evidence both run on European infrastructure.

We hold as little as possible

Built to minimise personal data, with sensitive details kept out of what the AI sees.

An audit trail by design

Every action is recorded in an append-only log — a clear "who did what, when."

Your compliance evidence stays within EU jurisdiction.

Get started

See what the EU AI Act asks of your system.

Create a project, answer a few questions, and see what applies — before you commit to anything.

Get started →Meet the team

How it works

From scattered documents to a clear path.

Compliance work is usually spread across documents, teams, and legal text. We turn it into five clear steps.

Tell us about your system

Answer a short set of questions — what your system does, your role (whether you build it or use it), and how it's deployed. This defines your profile.

See what applies to you

Based on your profile, we present the EU AI Act requirements relevant to your system, each linked to the part of the Act it comes from and explained in plain language.

Add your evidence

For each requirement, attach what shows you meet it — a document, a link, a short explanation. Your whole team can contribute; a compliance lead keeps oversight.

We check your evidence

Our EU-hosted assessment reads what you've attached and judges whether it actually satisfies each requirement — not a checkbox, an evidence check. You get a clear status for every item and the specific gap where something's missing.

Get your certificate

When your evidence meets the bar, you can issue a certificate — a record of what applied to you, the evidence you provided, and the assessment of it. Every step is logged, so your trail is audit-ready.

What you receive

A live view of where each requirement stands.
A clear next step wherever there's a gap.
An audit-ready evidence record.
A certificate, when you're ready.

Staying current

The Act evolves, your system changes, and your evidence ages. Certificates are reviewed yearly, so what you show stays true — not a one-time stamp, but assurance you can keep relying on.

Your certificate is evidence of a thorough, evidence-based self-assessment. It supports your compliance work; it isn't a legal guarantee or a substitute for legal advice.

Two ways to work

Simple where it can be. Serious where it must be.

On the platform

Straightforward systems

Most systems — especially lower-risk ones — can be handled start to finish yourself.

With our experts

Complex & high-risk systems

For high-risk AI, regulated sectors, and intricate deployments, our specialists define exactly what applies, build the evidence where it doesn't yet exist, and prepare you for the level of assurance a high-risk system demands.

Get started →

The EU AI Act

The EU AI Act, in plain terms.

The first broad law setting a common standard for trustworthy AI in Europe. Its aim is simple and, we think, sensible: AI that people can rely on to be safe, fair, and transparent. Meeting it shouldn't be the hard part — that's where we come in.

How it works, briefly

The Act sorts AI by risk.

Unacceptable

A few uses are off-limits — such as social scoring by public authorities.

High risk

Most obligations sit here — AI used in areas like hiring, credit, education, or essential services. This is where we focus.

Limited risk

Lighter transparency duties — for example, letting people know they're dealing with AI.

Minimal risk

Everyday, low-risk uses, with little to no specific obligation.

Who it applies to

It's not only for the companies that build AI.

If you build or supply an AI system, you have obligations. If you use one under your own responsibility, you have obligations too. We handle both — the questions we ask sort out which apply to you.

The good news

Most of it is what good teams want anyway.

The Act asks you to do these things on purpose, and to keep the evidence — and that's exactly the part we make simple.

Know your data.

Be able to explain what your system does.

Be clear about where its limits are.

Keep a human in the loop where it matters.

Show that it works.

Keep the evidence current.

Want the detail? We write about the specifics — how requirements apply, how to evidence them, and how the rules are evolving — on the blog. This page is a general overview, not legal advice.

Security & your data

Built to keep your evidence in the EU.

You're trusting us with sensitive compliance evidence. Here's how we look after it — plainly.

EU-hosted

Everything runs in the EU

The platform and the AI that assesses your evidence both run on European infrastructure. Your compliance evidence stays within EU jurisdiction — it isn't sent outside it.

Data minimisation

We hold as little as possible

The platform is built to minimise personal data. Where we can identify you by a reference instead of a name, we do, and sensitive data is kept out of what the AI sees where it isn't needed.

Accountability

An audit trail by design

Every meaningful action — evidence added, an assessment run, a certificate issued — is recorded in an append-only log, so you always have a clear "who did what, when."

Access

Built for teams

Your company's data is isolated. Colleagues are invited per project; a compliance lead keeps oversight across everything.

Questions about data processing? See our DPA, or contact us.

About us

Compliance you can trust comes from people who understand both the law and the technology.

We're an independent assurance company with one focus: making EU AI Act compliance simple to reach and simple to prove.

Why us, plainly

Good AI compliance sits between two worlds — the law and the technology.

Most teams have one or the other. We have both, plus the experience of building companies that ship.

Law

Tobias Edvardsson

Lawyer specialised in intellectual property, data protection, and EU legislation, with 25 years in the software and investment industry.

AI & engineering

Magnus Hyttsten

An AI expert with extensive experience from startups and Google. Builds the assessment engine and the EU-hosted infrastructure behind it.

Delivery

Ulf Zettersten

Company builder and former founder and CEO, responsible for shaping products customers and partners can adopt and rely on.

Independent by design

We don't build our customers' AI systems — so our assessment is our own.

That independence is what makes a certificate worth something.

Get started →See how it works

Blog

Straight, practical writing on the EU AI Act.

What it means, how to evidence it, and how it's changing. No hype, no scare tactics — just the detail, when you want it.

Explainer

The EU AI Act without the panic

What the Act actually asks of you — plainly, and without the fear.

6 min read

Update

What's changed, and what hasn't

Reading the latest updates to the Act calmly, and what they mean for you.

4 min read

Evidence & testing

Bias in AI systems: what "fair enough" really means

Why there's no single fairness score — and what the Act actually expects.

6 min read

Evidence & testing

Does your AI use the right sources?

Factual reliability and source grounding, explained for compliance.

5 min read

Evidence & testing

If you build on MCP servers: the quiet failure

How an under-described tool can cause big, confident mistakes.

6 min read

Essentials

Provider or deployer?

How to tell what the Act asks of you, and where you sit.

3 min read

Get started

See what the EU AI Act asks of your system.

Two ways in, depending on your system. You can explore before you commit to anything.

Straightforward systems

Start on the platform

Create a project, answer a few questions, and see what applies to you.

Create a project →

Complex or high-risk

Talk to us

Tell us a little about your system and we'll help you find the right path — on the platform, with our experts, or a mix.

Talk to us

Pricing. Straightforward and per-certificate — you pay for the assurance you need, not a subscription you don't. [Headline price to confirm.]

A certificate is evidence of an evidence-based self-assessment. It supports your compliance work and isn't a legal guarantee or a substitute for legal advice.

← Back to blog Explainer

The EU AI Act without the panic

What the Act actually asks of you — plainly, and without the fear.

6 min read

The EU AI Act has a reputation for being enormous, complicated, and a little frightening. Some of that is fair — it's a broad law, and the text is long. But most of the fear comes from reading it all at once, out of order. Taken step by step, it's far more manageable than it looks. Here's the calm version.

It starts from a good idea

Strip away the legal language and the Act is built on a simple goal: AI that people can trust. That it's safe, that it's fair, that people know when they're dealing with it, and that someone is accountable when it's used in ways that affect their lives. Most teams building AI already want these things. The Act just asks you to do them on purpose — and to keep the evidence.

It sorts AI by risk, and most AI is low-risk

The Act doesn't treat every system the same. A small number of uses are simply not allowed. High-risk systems — AI used in areas like hiring, credit, education, or essential services — carry most of the obligations. Limited-risk systems carry lighter transparency duties, like telling people they're dealing with AI. And everything else — the large majority of everyday AI — carries little to no specific obligation.

The first useful thing you can do is find out where your system sits. A lot of anxiety disappears the moment you realise a given system isn't high-risk at all.

The obligations are mostly good practice

If your system is high-risk, the obligations tend to be things a careful team would want to do anyway: understand your data and check it for bias, be able to explain what the system does and where its limits are, keep a human able to step in, make sure it's accurate enough for its job, and keep records. The Act's real ask is that you do these deliberately and can show you did — with evidence, not just good intentions.

It applies to more than the builders

A common misconception: "we didn't build the model, so this doesn't apply to us." Not quite. If you build or supply an AI system, you have obligations. If you use one under your own responsibility, you have a different, lighter set. Knowing which side you're on is part of figuring out what applies.

The calm way through

You don't need to read all hundred-plus pages, and you don't need to panic. You need a method: work out whether your system is in scope and at what risk tier; from that, find the specific requirements that apply to you, not the whole Act; gather the evidence that shows you meet them; and keep it current as your system and the rules evolve.

The Act is large, but your slice of it usually isn't — and once you can see your slice clearly, compliance stops being frightening and becomes a to-do list. That's exactly what we built Assurance Vector to do: turn the Act into your specific list, and help you prove you've met it.

Want to see your slice?

See what applies to your system →

This is a general overview, not legal advice.

← Back to blog Update

What's changed, and what hasn't

Reading the latest updates to the Act calmly, and what they mean for you.

4 min read

The EU AI Act didn't arrive all at once, and it isn't standing still. Its obligations phase in over time, and the timeline has been adjusted as the EU works through the practical details. If you've found the shifting dates confusing, you're not alone. Here's how to think about it without the whiplash.

What's changed: the timeline has more give in it

The headline change is timing. Some of the heavier obligations — particularly for high-risk systems — have been given more runway than the original schedule implied, as part of broader efforts to make the rules workable in practice. In plain terms: for many organisations, the moment you must be finished has moved further out than you might have feared.

Because these dates continue to move, we won't pin exact ones here — check the current position, or ask us, before you plan around a specific deadline.

What hasn't changed: the direction, and the work

This is the part that matters more, and it's easy to miss under the date changes:

The obligations themselves haven't softened. More time doesn't mean less to do. What a high-risk system needs to demonstrate is essentially unchanged.
Some duties already apply. Parts of the Act are already in force — "it's all in the future" isn't accurate.
Your customers aren't waiting. Increasingly the pressure isn't only the law — it's procurement. Companies are asking their AI suppliers to show they're compliant, well ahead of any legal deadline.

Why "more time" is not a reason to stop

It's tempting to read a deferral as permission to put this down. That's the trap. The work didn't get easier; there's just more space to do it well instead of in a panic. And getting ahead now is almost always cheaper and calmer than scrambling later — you can build good evidence into how you work, rather than reconstructing it under deadline pressure.

Watch the dates, but don't be governed by them. The runway is a gift — use it.

Whether the deadline is next year or the year after, the sensible move is the same: understand what applies to you, start assembling the evidence, and keep it current. Teams that treat the extra runway as a head start, not a snooze button, are the ones who'll breeze through when the dates finally bite.

Get ahead of it, calmly.

See where your system stands →

A general overview, not legal advice. Timelines change — verify the current position before planning around a specific date.

← Back to blog Evidence & testing

Bias in AI systems: what "fair enough" really means

Why there's no single fairness score — and what the Act actually expects.

6 min read

"Is our AI fair?" sounds like a yes/no question with a number behind it. It isn't. Fairness in AI is one of those topics where the honest answer is more useful than the simple one — and understanding why will save you from both false comfort and unnecessary worry.

Bias and fairness aren't the same thing

Bias, in the technical sense, is just a measurable difference in how a system treats different groups. Fairness is a judgement about which of those differences are acceptable. A system can show a statistical difference between groups and still be defensible — or look even-handed on one measure and unfair on another. Numbers tell you where the differences are; deciding what's fair is a human call on top of them.

There is no single "bias score"

This is the part that surprises people. There are several well-established ways to measure fairness — equal selection rates, equal error rates, equal accuracy, and others. The catch, proven mathematically, is that you usually can't satisfy all of them at once. When two groups differ in the underlying data, improving one measure of fairness often worsens another. There's no setting where every definition is satisfied simultaneously.

Anyone who offers you a single "unbiased" checkmark is overselling. Fairness is a defensible choice, not a green light.

That's not a reason for despair — it's a reason for judgement. The right question isn't "is it unbiased?" but "which definition of fairness matters most for this use, and can we defend that choice?"

What the Act actually asks

The EU AI Act is refreshingly practical here. For high-risk systems it doesn't demand a mythical perfectly-fair model. It asks you to examine your data for biases that could lead to unfair outcomes, take reasonable steps to detect and reduce them, and — crucially — document what you did. In other words: look properly, act sensibly, and keep the evidence. "Fair enough" means a considered, defensible, documented position — not perfection.

Generic tests only get you so far

There are good off-the-shelf ways to screen a system for common biases, and they're worth running. But they measure generic patterns, not whether your system disadvantages a specific group in your context. Real fairness questions attach to a particular use, a particular population, and a particular idea of harm. That's why a credible bias assessment combines standard tests with judgement about what fairness means for your case.

So "fair enough" is not a number you hit. It's a defensible position you can evidence: you looked for bias in the right places, you chose a definition of fairness that fits your use, you reduced what you reasonably could, and you can show all of it. That's what the Act wants, and it's what stands up to scrutiny.

See how this applies to your system.

See what applies to you →

A general overview, not legal advice.

← Back to blog Evidence & testing

Does your AI use the right sources?

Factual reliability and source grounding, explained for compliance.

5 min read

When an AI system answers a question, where does the answer actually come from? Increasingly it's not just the model's memory — it's documents it retrieves, searches it runs, and tools it calls. That shift changes the reliability question in a way that matters for compliance, and it's worth understanding.

"Is it right?" is really four questions

It's tempting to collapse everything into "is the answer correct?" But for a system that consults sources, there are four separate things to check:

Is it correct? True in the real world.
Is it grounded? Actually supported by the source the system used.
Is it attributed? The source it cites genuinely says it.
Did it use the right source? The one that's authoritative and current — not just a plausible one.

Most tools only check the second. That leaves the most important one — did it consult the right source? — largely unanswered.

The trap: faithful but wrong

Here's the failure that catches people out. A system can be perfectly faithful to the document it retrieved — every claim supported — and still be wrong, because that document was out of date or simply incorrect. Faithfulness measures loyalty to the source, not the truth of the source.

An answer that's faithful to the wrong source is still the wrong answer — and it's the kind of mistake that looks completely trustworthy.

Why this matters for the Act

The EU AI Act asks high-risk systems to be accurate enough for their purpose, and to be honest about their limits. For a system that answers factual questions, that means you need to show more than "it sounds right." You need evidence that it consults authoritative, current sources, that its answers actually follow from them, and that it doesn't quietly fall back on stale memory when it matters most.

What good evidence looks like

A credible check goes beyond "does the answer match the retrieved text?" It asks: are the sources the right ones for this domain? Are they current? When the system cites something, does that source really support the claim — and does the link even resolve? For systems that use tools or connect to live data, it also asks whether the system reached for the correct tool in the first place.

As AI systems get their facts from more places, "did it use the right source?" becomes the question worth answering — for reliability and for compliance. Being right by luck isn't enough; you want to show your system is right for the right reasons.

See how this applies to your system.

See what applies to you →

A general overview, not legal advice.

← Back to blog Evidence & testing

If you build on MCP servers: the quiet failure

How an under-described tool can cause big, confident mistakes.

6 min read

More and more AI systems are built by connecting an assistant to tools and data through MCP servers — a now-common way to give an AI access to databases, APIs, and live information. If you're building this way, there's a specific, quiet failure worth knowing about, because it doesn't look like a bug and standard checks often miss it.

The failure isn't in the model — it's in the description

When an AI decides which tool to use, it reads the tool's description and picks the one that seems to fit. That description is the entire basis for the choice. If it's vague or too broad, the AI can reach for a tool in a situation it was never meant for — and because the tool returns something, the answer comes back fluent and confident, just wrong.

A concrete example

Imagine a tool that serves historical interest-rate forecasts for a single country. That data is authoritative — but only for that country, only forecasts, only that time range. Now suppose the tool is described simply as "get interest-rate forecast data." Ask the assistant about a different country's rates, and it may happily call this tool and return the first country's figures — presented with total confidence. Nothing errored. The number is just wrong, in a way that's very hard to spot downstream.

The tool worked. The model worked. The description let them combine into a confident mistake.

The fix is scope, and it's testable

The remedy is to bind the tool's scope in its description and schema — spell out what it covers and what it doesn't: the country, the fact that it's forecasts rather than outcomes, the time range, the units. A well-scoped tool is one an assistant picks only when it's actually the right choice, and declines otherwise.

The good news is that this is testable. You can check, systematically, whether an assistant selects a tool correctly for in-scope questions — and, just as importantly, whether it avoids the tool for adjacent-but-wrong ones. That "does it correctly decline?" test is exactly the one that catches the quiet failure above.

Why it matters for compliance

For a high-risk system, this is an accuracy and robustness question in disguise. If your system can be led into confidently wrong answers by a loosely-described tool, that's a weakness you'd want found — and fixed — before someone else finds it. Testing your MCP servers for scope and correct selection, not just whether they function, is fast becoming part of doing this properly.

Building on MCP servers?

Talk to us about your system →

A general overview, not legal advice.

← Back to blog Essentials

Provider or deployer?

How to tell what the Act asks of you, and where you sit.

3 min read

The EU AI Act gives different responsibilities to different roles. Before you can know what applies to you, you need to know which role you're in. For most organisations it comes down to two: provider and deployer.

Provider: you build or supply it

You're a provider if you develop an AI system (or have one developed) and put it on the market under your name, or make it available for others to use. Providers carry most of the Act's obligations, because they shape how the system works — things like data governance, technical documentation, and making sure the system meets its requirements before it's used.

Deployer: you use it

You're a deployer if you use an AI system under your own authority — for example, a company using an AI tool to help screen job applicants. Deployers carry a lighter, but real, set of duties, focused on using the system responsibly: following the instructions, keeping appropriate human oversight, and — in some cases — assessing the impact on people's rights.

You can be both

Plenty of organisations are both at once — a provider for a system they built, and a deployer for tools they've bought. That's normal. It just means you look at each system separately and ask, for that one, "are we building it or using it?"

Why it matters

Your role decides your obligations. Reading the whole Act as if every duty applies to you is a fast route to unnecessary panic — most of it won't. The efficient path is to establish your role for each system first, and let that narrow the Act down to the part that actually concerns you. That's the first thing our questions sort out: for each system, whether you're the provider, the deployer, or both — and from there, exactly what applies.

Not sure which you are?

Find your role and requirements →

A general overview, not legal advice.