The EU AI Act for engineering teams

What the Act actually covers

The EU AI Act regulates AI systems by what they are used for, not by how they are built. There is no clause about transformers, no parameter threshold that makes a model regulated. A linear regression deciding who gets a loan carries more obligation than a large language model writing marketing copy.

This trips up engineers, because the instinct is to ask "does this apply to our model?" The Act asks a different question: what decision does this system participate in, and who is affected when it is wrong?

It also reaches further than EU-headquartered companies. If the output of your system is used in the EU, you are likely in scope regardless of where you are incorporated or where the model runs. For a team in Bangalore shipping a product with European customers, that is the relevant fact.

The risk tiers, in plain terms

Four tiers. Most engineering effort concentrates in one of them.

The practical consequence: your first job is not compliance, it is classification. Most teams discover they have one or two systems in the high-risk tier and a long tail of minimal-risk ones that need nothing. Treating everything as high-risk is the most common and most expensive mistake.

What changes for an engineering team

For a high-risk system, four obligations touch engineering directly. Each maps to something you either already do or can start doing without a new platform.

Documentation that describes the system as built

You need a record of what the system does, what data trained it, how it was evaluated, and what its known limitations are. The trap is writing this once at launch. A document describing a model two versions out of date is worse than no document — it is a confident statement that happens to be false.

The version that survives is generated from the repository: a model card committed next to the code, updated in the same pull request that changes the model.

Logging that can reconstruct a decision

When someone asks why a particular applicant was rejected in March, you need to answer. That means logging inputs, outputs, model version and timestamp — enough to reconstruct the decision, not enough to build a second copy of your user database.

Most teams already log some of this for debugging. The gap is usually retention and model version: debug logs roll off in fourteen days, and nobody records which model version served the request.

Human oversight that is real

A human must be able to understand the output, override it, and have the authority to do so. "A human reviews it" is not oversight if that human sees four hundred cases a day and the interface has a single Approve button.

This is a product and interface problem more than a modelling one. The engineering questions are: does the reviewer see the inputs that drove the output, is there a path to disagree, and is the disagreement recorded?

Data governance you can evidence

Training data needs to be relevant, representative, and checked for the biases that matter in your context. Nobody expects a perfect dataset. They expect you to have looked, written down what you found, and made a defensible decision about it.

  training data  ──▶  model  ──▶  deployment  ──▶  decision
       │               │              │               │
   governance      documentation   logging      human oversight
   (checked,       (model card,    (inputs,     (can see inputs,
    recorded)       versioned)      version,     can override,
                                    retained)    is recorded)
            

What to do first

In order, and none of it needs a budget line.

1. List the systems. Every model and every meaningful piece of automated decisioning. A spreadsheet is acceptable for a week; after that see building a model inventory.
2. Classify each one. Most will be minimal risk. Write down the reasoning, not just the answer — the reasoning is what you will be asked for.
3. Pick the highest-risk one and work it properly. Documentation, logging, oversight, data governance. One system done properly teaches you more than four done partially.
4. Make the classification a checklist item in whatever process you already use to ship. Governance that lives outside the delivery process decays.

What not to do: buy a compliance platform before you know how many high-risk systems you have. The answer is often one, and one does not need a platform.

What is still genuinely unsettled

Anyone presenting the Act as fully settled is overselling. Three areas where honest practitioners disagree:

General-purpose model obligations. Where the responsibility of a model provider ends and the deployer's begins is still being worked out in practice, particularly for teams building on a third-party API.

What counts as sufficient documentation. There is no template that guarantees acceptance. Current practice is to document more than feels necessary and keep it close to the code.

Interaction with existing regimes. If you are already under GDPR, DORA or sector rules, the overlap is real and the sequencing is not obvious.

Treating uncertainty as uncertainty is not a weakness in a governance programme. A risk register that records "we believe this is limited risk, here is why, we will revisit if guidance changes" is stronger than one asserting false confidence.