The short version
The Act is tiered. Most internal productivity systems land in the low-obligation band; a minority sit in high-risk and carry documentation, logging, oversight and data-governance duties. Classify per system, early, and the engineering work is modest.
Regulation (EU) 2024/1689 — the AI Act — applies obligations by risk tier rather than by technology. The consolidated text is public, the Commission publishes an implementation timeline, and there is an official FAQ aimed at non-lawyers. Read those three before you read any vendor's compliance marketing.
The tiers, as a buyer experiences them
| Tier | Typical example in an enterprise | What it costs you in practice |
|---|---|---|
| Prohibited | Social scoring, certain biometric inference | Do not build it |
| High-risk | Systems used in recruitment, creditworthiness, essential services, safety components | Risk management, data governance, technical documentation, logging, human oversight, accuracy and robustness evidence |
| Transparency obligations | Customer-facing chat, synthetic content generation | Tell people they are dealing with AI; label generated content |
| Minimal risk | Internal drafting help, document search over your own files | Good practice, no specific Act obligations |
Two things surprise buyers. First, your role matters: obligations differ for a provider that puts a system on the market and a deployer that uses one. Second, general-purpose model providers carry their own duties, which means part of your compliance evidence comes from your model vendor's documentation rather than from your own code.
What the engineering actually looks like
For a high-risk system, most of the obligations map onto things a well-built system should have anyway:
- —Logging: immutable records of inputs, retrieved sources, model version, output and the human decision that followed.
- —Human oversight: a defined intervention point, plus refusal or escalation when confidence is low.
- —Data governance: provenance for training and evaluation data, documented bias checks, retention rules.
- —Technical documentation: architecture, intended purpose, limitations, evaluation results, change history.
- —Accuracy and robustness: a maintained evaluation suite with results per release, not a one-off benchmark.
The expensive version of this is retro-fitting it. Adding an audit trail to a system already in production usually means reworking how retrieval and prompting are recorded — weeks of work to reproduce evidence you could have captured from the first commit.
A two-day classification exercise
- 01Inventory every AI-touching workflow, including the shadow ones people run on personal accounts.
- 02For each, record purpose, decision affected, data categories, and whether you are provider or deployer.
- 03Map to a tier and note the specific evidence that tier requires.
- 04Mark the gaps that are engineering work versus the gaps that are policy work.
- 05Give each system an owner and a review date.
This is engineering support, not legal advice. We build the documentation, logging and oversight your counsel's classification calls for — and we will tell you when a question belongs with counsel rather than with us.
What we would do in a pilot
Classification workshop plus a gap list per system, then implementation of the logging, oversight and documentation the tier requires — delivered as part of the build rather than as a compliance project bolted on afterwards.
Sources
- 01Regulation (EU) 2024/1689 — consolidated text — EUR-Lex
- 02Timeline for the implementation of the EU AI Act — European Commission — AI Act Service Desk
- 03Navigating the AI Act — FAQ — European Commission — Shaping Europe's digital future
- 04Implementation Guidance for the EU AI Act — European Commission (Futurium)
Figures drawn from our own engagements elsewhere on this site are illustrative placeholders. Anything attributed above links to its public source.