→ EU AI Act compliance services

EU AI Act compliance for teams that actually ship AI

Most guidance on this is written by people who have never deployed a model. Here is what the regulation asks of engineering, which obligations attach to your use case, and what to build into the system now so the record exists later.

Request an assessment→All consulting options

Overview

How we approach this work.

EU AI Act compliance is not a document you write at the end. Most of the obligations are engineering decisions: what you log, whether a human can overrule the system, whether you can explain an output six months later, and whether you know what the model was trained or prompted on.

The obligations follow the use case, not the technology and not where you host it. The same language model can be unregulated in one product and high risk in another. That is the part most teams get wrong, usually in the direction of panic, occasionally in the direction of ignoring it entirely.

We are a Croatian company building AI systems in production under EU law. This page is what we tell clients, written down. If you want it applied to your own systems, that is part of the AI readiness assessment.

What you get

Concrete deliverables.

Use case classification

Where your AI feature actually falls: prohibited, high risk, limited risk with transparency duties, or minimal. Most business software lands in the last two.

Transparency in the product

Telling people they are interacting with AI, and labeling generated content, built into the interface rather than buried in terms.

Human oversight that is real

A person who can review, overrule and stop the system, with the authority to do it. Auditors ask whether the override was ever used.

Logging and traceability

Inputs, outputs, model version, prompt version and who acted on it, retained long enough to answer a question about a decision months later.

Data governance

Where training and retrieval data came from, what it contains, and the lawful basis for processing it.

Technical documentation

The record itself: purpose, architecture, evaluation, known limitations and how the system behaves when it fails.

Scope

What we look at.

Where processing happens

EU region endpoints on Azure OpenAI, AWS Bedrock and Vertex AI, private VPC deployments, or open weights models on hardware you control. Each carries a different answer to the processor question.

Evidence we build in

Structured audit logs, model and prompt version pinning, eval suites in CI with retained results, override tracking, and dataset provenance records.

What we work against

Regulation (EU) 2024/1689, GDPR, and the sector rules that usually matter more in practice: medical devices, financial services, employment.

Outcomes

What you walk away with.

A written classification of each AI feature, with the reasoning, so the answer survives a change of staff.
Logging and oversight built into the system rather than promised in a policy.
Technical documentation produced alongside the build, not reconstructed under deadline.

References with names available after a first call.

In depth

The four risk tiers, in plain terms

The Act sorts systems by what they are used for. Reading that list honestly takes an afternoon and saves months of misdirected work.

Prohibited: social scoring, certain biometric categorization, manipulation of vulnerable groups. If you are here, the conversation is about stopping, not compliance.
High risk: employment decisions, credit, education access, critical infrastructure, medical devices, law enforcement. Heavy obligations, and the ones that need engineering from day one.
Limited risk: chatbots, generated content, emotion recognition. Transparency duties, mainly telling people what they are dealing with.
Minimal: everything else, which is most internal business software. No specific obligations under the Act, though GDPR still applies.

What auditors ask, and what actually answers it

The questions are narrower than the regulation is. Each is answerable in a sentence when the system was built with them in mind, and a project when it was not.

Where is this processed and by whom. Can a human overrule it, and has anyone ever done so. What did the system output on this date for this person, and on what basis. What data went into it and where did that data come from. What are the known limitations, and who was told about them.

Notice that none of those are satisfied by a policy document. They are satisfied by logs, version pinning, an override that exists in the product, and a dataset record. Retrofitting them costs several times what building them in costs, which is the whole argument for looking at this before the build rather than after.

Self-hosting answers some of it, and not the rest

Running open weights models on your own hardware removes the processor relationship, the external logging and most of the residency argument. That is a real simplification and it is why regulated clients ask for it.

It does not change your obligations. A high risk use case is high risk on your own servers. Human oversight, traceability and documentation are all still required, and an auditor will not be impressed that the GPU is in your building. Choose the deployment for the data question and handle the use case question separately.

Timing, and what to do now

The dates moved in 2026. The Digital Omnibus on AI, in force since 27 July 2026, pushed the high risk obligations back to 2 December 2027 for the use cases listed in Annex III, such as hiring, credit scoring and education, and to 2 August 2028 for AI built into products that already fall under EU product safety law. Systems placed on the market before 2 August 2026 are only caught if they are substantially changed afterwards.

The transparency duties did not move. Telling people they are dealing with an AI system applies from 2 August 2026, and machine readable marking of generated content has a grace period to 2 December 2026 for systems already on the market. The prohibited practices and the AI literacy duty have applied since February 2025.

The extra time is not a reason to wait, because the part that takes longest is the record, and a record only starts when you start keeping it.

Classify each AI feature you ship and write down the reasoning. Add logging and version pinning to anything already in production, because that is the part you cannot reconstruct retroactively. Decide who the human in the loop is and give them a real override. For anything that looks high risk, get the technical documentation started alongside the build.

Where the rules are genuinely unsettled, we will say so rather than invent certainty. We are engineers, not your lawyers, and the classification of a borderline use case is a decision your counsel should confirm.

Related services

Other places this work shows up.

AI readiness assessment Private and on-premise AI infrastructure All AI consulting options

FAQ

Frequently asked.

Does the EU AI Act apply to us if we only use an API like OpenAI or Anthropic?

Yes. Obligations attach to the deployer of a system as well as the provider of a model. Using somebody else's model does not move the responsibility for how you use it, though it does shift some of the documentation burden to them.

Is our chatbot high risk?

Almost certainly not. A customer support or internal knowledge chatbot is usually limited risk, which mainly means telling people they are talking to AI. It becomes high risk when it makes or materially supports a decision about somebody's employment, credit, education or health.

Does self-hosting make us compliant?

No. It answers the data processing and residency questions well, which is why regulated clients choose it, but obligations follow the use case. A high risk system is high risk wherever it runs.

What is the single most useful thing to do first?

Add logging and version pinning to whatever is already in production. Classification can be done later from documents. The record of what your system did last March cannot be created after the fact.

When do the EU AI Act high risk rules apply?

From 2 December 2027 for the high risk use cases in Annex III, such as hiring, credit scoring and education, and from 2 August 2028 for AI inside products covered by EU product safety law. The Digital Omnibus moved both dates in 2026. Transparency duties for chatbots and generated content still apply from 2 August 2026.

Can you do this for us?

Yes, in two shapes. A five day review of one existing AI feature, €4,500 to €6,500, gives you a written classification and a list of what to add. The two week AI readiness assessment, €9,500 to €14,000, covers several use cases and the build decision. Assessment fees come off the first invoice if we go on to build what we recommended, on projects above €50,000, valid for six months. We are engineers rather than lawyers, so for a borderline classification we give you our reasoning and your counsel confirms it.

Do you work with companies outside the EU?

Yes, and they ask about this more often than EU companies do, because the Act reaches systems used in the EU regardless of where the provider sits.

Not sure it is worth building? Ask us first.

Tell us what you are considering. We reply within one business day with whether an assessment makes sense for you, which one, and what it would cost.

Request an assessment→