The EU AI Act, translated into engineering work

The expensive version of this mistake ships in a sprint. A team adds a model that ranks job applicants and calls it "a wrapper around an API". Nine months later an enterprise buyer in Germany asks for the technical documentation, the risk management file and the logging design for a high-risk AI system, and none of it exists.

The mirror image is just as common: a company freezes an internal meeting-summary tool because someone read a headline about bans. That tool is in the lowest tier and needs almost nothing beyond telling users it is AI.

The gap between the two is two questions you can answer in an afternoon.

Provider or deployer decides most of it

A provider develops an AI system, or has one developed, and places it on the market under its own name. If you build a product with AI in it and sell it, you are the provider — including when the model underneath is somebody else's. Calling OpenAI, Anthropic or Vertex AI does not make them the provider of your system. They provide the model; you provide the system.

A deployer uses an AI system under its own authority in a professional context. A bank running a bought fraud-scoring product is a deployer, and its duties are far lighter: use the system as instructed, assign competent human oversight, keep the logs you control, inform affected people in certain contexts.

Two traps. A deployer becomes a provider if it puts its own name on the system, substantially modifies it, or changes its intended purpose: repurpose a general tool for CV screening and you inherit the full provider set. And the regulation reaches outside the Union, so a US company with no EU entity is in scope if the system is placed on the EU market or its output is used there.

The tiers, and where real products land

Prohibited practices include social scoring by public authorities, manipulative techniques causing significant harm, untargeted scraping of facial images, emotion inference in workplaces and education, and most real-time remote biometric identification in public spaces. Read the list once, properly. It is short and absolute.

High risk has two routes in. Either the system is a safety component of a product already covered by EU product law, or it falls into the listed use cases: biometrics, critical infrastructure, education, employment, access to essential services including creditworthiness and insurance pricing, law enforcement, migration, and justice.

Employment is what catches ordinary SaaS companies. Recruitment, CV filtering, task allocation, promotion and termination decisions, and monitoring of worker performance all sit there. Creditworthiness pulls in fintech.

There is a filter for systems in a listed area that only perform a narrow procedural task or prepare work for a human, but relying on it means documenting the assessment and registering anyway, and profiling always keeps you in.

Limited risk carries transparency duties: say when someone is interacting with an AI system, mark synthetic media in machine-readable form, disclose deepfakes. Minimal risk is everything else, with no mandatory obligations.

What high risk asks of engineers

Strip the legal phrasing and the provider obligations are a system you would recognise. A risk management process running across the lifecycle rather than a document written at launch. Data governance for training, validation and test sets: provenance, known gaps, bias examination. Technical documentation to the Annex IV contents, covering architecture, performance metrics and their limits, foreseeable misuse, oversight design and version history.

Automatic logging sufficient to trace how an output came about: inputs, model and prompt version, retrieval context, the output, the human decision that followed, a timestamp. Human oversight designed in, so the assigned person can see the output's limits, resist automation bias and stop the system. A reviewer with 400 items an hour and one approve button is not oversight.

Then accuracy, robustness and cybersecurity proportionate to the purpose, including resistance to attempts to change behaviour through the input: prompt injection and data poisoning are named, not theoretical. On top, conformity assessment, CE marking, registration in the EU database, post-market monitoring and incident reporting.

Providers of general-purpose models carry a separate set, including model documentation and a copyright policy. Theirs is an input to your technical file, so ask for it during procurement.

If you run ISO 27001, the management system and audit machinery transfers, and ISO/IEC 42001 is the AI management system standard worth reusing as scaffolding. Treat this as one control set with several mappings rather than a parallel programme, as in mapping one control set across frameworks. The Statement of Applicability habit fits recording which AI obligations apply and why.

The dates are phased and the standards unfinished

Application is staged after entry into force rather than switching on at once: prohibitions and AI literacy first, general-purpose model obligations next, then the bulk of high-risk duties, with a longer runway for AI embedded in products already subject to sectoral conformity assessment. The phases are counted in months, and the sequencing has itself attracted amendment proposals aimed at simplification and delay. Check the current position for the obligation that binds you rather than a date you remember from a conference talk.

Be equally clear-eyed about the detail. Much of what would let a team implement precisely is meant to arrive as harmonised standards from CEN and CENELEC, plus Commission guidance and codes of practice, and parts of that work are still in progress. Conformity with a harmonised standard buys a presumption of conformity, which is why teams want them. Until they land, implement against the text and structure the documentation so it can be re-cut.

What teams forget

• AI literacy applies at every tier. Staff working with AI systems must be competent. One of the earliest duties, and the easiest to evidence with a dated training record.
• The inventory does not exist. Most companies find three to five forgotten AI features, usually in HR tooling and support.
• Bought systems still create obligations. Your HR platform's ranking feature makes you a deployer, and you need the provider's instructions for use.
• Logging is a design decision, not a setting. Added later, the historic cases stay unanswerable.
• This does not replace GDPR. Personal data in training sets, prompts and logs still needs a lawful basis and a retention rule; see GDPR as engineering controls.

What to do this week

Build the inventory. One sheet, one row per AI-touching feature including bought tools and internal scripts, with four columns: what it decides or produces, provider or deployer, whether a listed high-risk use case is in play, and who owns it. An hour with the engineering leads and the HR system admin turns an unbounded worry into a list with three interesting rows. If two of them land in employment or creditworthiness, that is the point to bring in help, and the first thing we scope in an AI compliance review.