EU AI Act: Who Actually Makes Your AI Compliant?

To become EU AI Act-compliant, most businesses need three distinct roles, not one. Legal counsel or your DPO interprets the law and tells you which obligations apply and where your legal risk sits. A notified body or conformity auditor (such as TÜV, SGS or BSI) independently assesses and certifies high-risk systems. The implementation partner actually builds the system to meet the requirements — Article 10 data governance, Article 11 technical documentation, Article 14 human-oversight UX, logging and monitoring. A lawyer or auditor can tell you what the law demands and whether you pass; neither can build the compliant system, and bolting compliance on after a failed audit costs far more than building it in from day one. This is general information, not legal advice.

The question every business is now asking

If your company runs an AI system that might fall under the EU AI Act, the first question is rarely "how do we build it." It is "who do we call." A lawyer? An auditor? A consultancy? The marketing is loud and the roles blur together, and the honest answer is that you almost certainly need more than one of them — but for different things, at different times.

This post is a comparison, not a how-to. If you want the article-by-article engineering walkthrough, that is the separate high-risk implementer's guide. Here the goal is narrower and more practical: to separate the three roles involved in getting an AI system compliant, show what each can and cannot do, and explain why the order you bring them in changes how much the whole thing costs.

One disclaimer up front, and we will repeat it because it matters: this is general information, not legal advice. Crux Digits is an implementation partner — we build AI systems. We are not a law firm and not a notified body, and part of being useful is being clear about where our role ends and someone else's begins.

The three roles, kept separate

Compliance with the EU AI Act is not one job. It is three jobs that are easy to confuse because they all use the word "compliance." Keeping them apart is the single most useful thing you can do before you spend money.

1. Legal counsel or your Data Protection Officer — interprets the law. This is the person who reads the regulation and tells you what it means for *your* situation. Which risk tier is your system in? Does Annex III apply? Are you a provider or a deployer? What is your exposure if you get it wrong, and what does the GDPR overlap mean for your data? Counsel turns a 100-plus-article regulation into a list of obligations that apply to you, and owns the legal-risk judgement. They advise; they do not build, and in most cases they do not certify.

2. Notified body or conformity auditor — independently assesses and certifies. For certain high-risk systems the Act requires an independent conformity assessment by a designated notified body — the kind of organisation you know from CE marking on physical products, such as TÜV, SGS or BSI. They examine your system and its evidence against the requirements and, if it passes, support the path to a CE mark and an EU declaration of conformity. Their independence is the whole point: they cannot also be the people who built the thing, because then the assessment would not be independent.

3. The implementation or engineering partner — actually builds the system. This is the role that does the work the other two describe. Article 10 data governance does not happen because a lawyer wrote it down — someone has to build the governed, versioned, bias-checked data pipeline. Article 11 technical documentation does not appear because an auditor asked for it — it is generated as the system is built. Article 14 human oversight is not a policy sentence — it is human-in-the-loop UX that an engineering team designs and ships. This is compliant-by-build: the system is engineered to meet the requirements from the first sprint, so the legal advice and the audit have something real to point at.

Read together, the pattern is clear. Counsel says *what* the law requires. The notified body says *whether you pass*. The implementation partner makes the system that actually *does* what the first two are talking about.

There is a fourth role worth naming so you do not overpay for it: a general management consultancy that produces a strategy deck. A deck is not a compliant system, a legal opinion, or a certificate — it is an opinion about which of the other three you should hire. For most businesses with a concrete AI system already in flight, the deck stage is something you can skip. We argue that case at length in boutique vs Big Four AI consultancy, which is about consultancy *size and style* rather than the legal-vs-build question here.

A worked example: the high-risk hiring model

Concrete is clearer than abstract, so take a common case: a company building an AI tool that screens and ranks job applicants. AI used in employment and worker management is a defined high-risk use under Annex III, which means the heavy obligations apply — and it makes a good test of who does what.

Counsel's part. Your lawyer or DPO confirms the system is high-risk, identifies that you are the *provider* (you build it) as well as a *deployer* (you use it on your own hiring), and flags the GDPR overlap because you are processing candidate personal data. They tell you Article 10 representativeness, Article 14 human oversight and Article 13 transparency all bite hard here, and they advise on the disclosure you owe candidates. What they hand you is a clear set of obligations — and nothing that screens a single CV.

The implementation partner's part. Someone now has to make those obligations real. That means a versioned training dataset with a documented provenance trail; evaluation metrics sliced by gender, age band and other relevant groups so bias is measured rather than assumed; a recruiter-facing interface that surfaces why a candidate was ranked where they were and lets a human override the ranking; audit logs of every decision; and the Annex IV technical documentation assembled as the system is built. This is the bulk of the work, and it is engineering.

The notified body's part. Where third-party assessment is required, the auditor examines that finished system and its evidence and decides whether it meets the requirements — then supports the CE mark and declaration of conformity. If the data governance and documentation were built in, this is a structured review. If they were not, this is the moment the company discovers it has to retrain on re-sourced data, which is the most expensive sentence in this whole article.

Three roles, one system, and only one of them ever touches the code. Conflate them and you either pay a lawyer to do engineering they cannot do, or you meet the auditor with nothing real to assess.

The comparison: role by role

Here is the same picture as a side-by-side, because the distinctions are where decisions get made and money gets wasted.

Legal counsel / DPO

• What they do: interpret the regulation, classify your risk tier, map obligations to your business, advise on legal risk and the GDPR overlap, review contracts and disclosures.
• What they cannot do: build the data pipeline, write the technical documentation, design the oversight UX, or (usually) issue the formal certification.
• When you need them: at the very start, to know if and how the Act applies — and again before launch, to sign off the legal position.

Notified body / conformity auditor (TÜV, SGS, BSI)

• What they do: independently assess a high-risk system against the requirements, verify the evidence, and support CE marking and the declaration of conformity.

• What they cannot do: build or fix the system for you — independence forbids it — and they generally do not advise on your wider legal strategy.
• When you need them: for high-risk systems that require third-party conformity assessment, near the end of the build, once the evidence exists to assess.

Implementation / engineering partner (compliant-by-build)

• What they do: build the system to meet the spec — governed data (Art. 10), technical documentation (Art. 11), event logging (Art. 12), transparency and human-oversight UX (Art. 13–14), accuracy, robustness and monitoring (Art. 15), and the evidence trail that backs all of it.
• What they cannot do: give you legal advice or issue an independent certification — doing either would undermine the separation of roles.
• When you need them: from day one of building or remediating, working alongside your counsel and (where required) your notified body.

Notice that no single column covers the whole table. That is the point, and it is why "we hired a law firm" or "we passed an audit" are each only one third of the answer.

Why a lawyer or auditor can't make your AI compliant

This is the wedge, and it is worth stating bluntly: a law firm and a notified body can tell you what the law requires and whether you pass — but neither of them can build the compliant system. That is not a criticism of either profession. It is their role working as designed.

A lawyer can write you a memo that says "your hiring model is high-risk, so under Article 10 your training data must be representative and bias-checked, and under Article 14 a human must be able to override its decisions." That memo is genuinely valuable. But it is a specification, not a system. Someone still has to slice the evaluation metrics by demographic group, version the datasets, build the reviewer interface that surfaces uncertainty, and wire in the stop-and-override path. The lawyer does not do that, and would not claim to.

A notified body has the same boundary from the other side. Their job is to look at a finished system and judge it against the requirements. If it fails, they tell you it fails — they do not stay and fix it, because the moment they did, they could no longer assess it independently. An audit is a verdict, not a build.

So if you bring in only counsel and only an auditor, you are left holding the actual engineering — the part where compliance is either real or it isn't. Someone has to translate the obligations into a working system. The only question is whether that someone builds it in deliberately, or whether you discover the gap when the audit comes back red.

Compliant-by-build vs the expensive retrofit

There are two ways to arrive at a compliant high-risk AI system. You can build it to the spec from the start, or you can build whatever ships fastest and then try to bolt compliance on after a lawyer or auditor flags the gaps. The first is compliant-by-build. The second is the retrofit, and it is almost always the more expensive path.

The reason is structural, not a sales pitch. Several of the Act's core requirements are not features you can add later — they are properties of how the system was built:

• Article 10 (data governance). If you trained on data with no provenance trail and no representativeness checks, you cannot document that after the fact. You may have to re-source data and retrain — the single most costly thing on this list.
• Article 11 (technical documentation). Reconstructing six months of design and data decisions from memory the week before an assessment is slow, incomplete, and exactly the scramble auditors see most often. Built-in, the documentation is a by-product; bolted on, it is archaeology.
• Article 12 (logging). If audit-grade, tamper-evident logging wasn't designed in, you have no record of what the system did before today — and you cannot create one retroactively.
• Article 14 (human oversight). Genuine oversight is UX woven through the product. Retrofitting it usually means redesigning core flows, not adding a checkbox.

Each of these is cheaper as a design decision than as a remediation project. Building in a data provenance trail costs a fraction of re-sourcing data later. Designing oversight UX up front costs a fraction of reworking a shipped product. The retrofit also carries a hidden cost the build does not: time-to-market risk. A red audit close to a deadline can stall a launch entirely, and that delay often dwarfs the engineering bill.

Compliant-by-build is also better engineering on its own merits. Governed data, versioned evaluations, real logging and designed-in oversight make for a more reliable, more debuggable system whether or not a regulator ever looks. The Act simply makes them mandatory and asks you to prove them.

How the three roles work together

These roles are not rivals — a well-run compliance effort uses all three in sequence, and they hand off to each other. The order matters as much as the cast.

Start with counsel. Before you build or buy anything, get a legal read on whether the Act applies and at what risk tier. Misclassifying your system is the most expensive early mistake: building heavy high-risk controls into a system that is actually limited-risk wastes money, and the reverse leaves you exposed. Our is-my-AI-system-high-risk guide and the compliance checklist are useful self-assessment starting points, but the formal classification call belongs with counsel.

Bring in the implementation partner early — not after the audit. Once you know the obligations, the engineering should start with them in scope. This is where compliant-by-build pays off: the partner builds the data governance, the documentation, the oversight UX and the evidence trail in step with the product, so there is something real for the auditor to assess. Done well, the partner also speaks both languages — translating the lawyer's obligations into engineering tasks, and producing the artefacts the notified body will ask for.

Engage the notified body when there is something to assess. For high-risk systems that require third-party conformity assessment, the auditor comes near the end, once the system and its evidence exist. If the first two roles did their jobs, the assessment is a review of well-organised evidence rather than a hunt for missing pieces. The Netherlands-specific framing of how these pieces fit locally is covered in our EU AI Act compliance in the Netherlands overview.

The failure mode is doing this out of order: building the system with no compliance in mind, getting a legal memo late, and meeting the auditor cold. That is the sequence that turns into a retrofit.

Where Crux Digits fits — and where it doesn't

Crux Digits is the implementation partner in this picture. We are a boutique, EU-based AI consultancy in the Netherlands, and we build AI systems to be AI-Act-ready by default — governed data, version-stamped evaluations, audit-grade logging, designed-in human oversight, and the technical documentation that backs them. We work alongside your counsel and, where required, your notified body, not in place of them.

We are explicit about the boundary: we are not a law firm and not a notified body. We do not interpret the regulation as legal advice and we do not issue conformity certifications. What we do is take the obligations your counsel identifies and turn them into a working, defensible system — and tell you plainly when it is time to bring a lawyer or an auditor into the room.

How we work matters here too. Crux runs fixed-scope projects with transparent pricing, not open-ended retainers: an AI Audit & Strategy at EUR 2,500 to map where your system stands against the Act, a Proof of Concept at EUR 20,000, and a Production Launch from EUR 50,000. You own the models and code we build — no lock-in. Much of this work lands in our generative AI and data practice, where human-in-the-loop oversight and governed data are part of the build, not an afterthought.

If you are weighing up who to call first, the honest sequence is: a legal read on classification, then a build partner who designs compliance in, then an auditor when there is something to assess. If you want a candid, no-obligation read on which of those you actually need for your system, you are welcome to book a free consultation.

Frequently asked questions