Regulation (EU) 2024/1689, the AI Act, is the first comprehensive law of its kind. Its approach is simpler than the length of the text suggests: obligations do not depend on what kind of model it is, but on what it is used for and who it can harm.
Four levels
| Level | What it covers | Consequence |
|---|---|---|
| Unacceptable risk | Prohibited practices | Cannot be used |
| High risk | Systems in sensitive areas of use and safety components of products | The largest set of obligations |
| Limited risk | Systems that interact with people or generate content | Transparency duties |
| Minimal risk | Everything else | No specific obligations |
Most of what organisations use day to day lands in the bottom two categories. That does not mean there is no work - it means the work is different.
A model that drafts text is minimal risk when it summarises a meeting and high risk when it is used to shortlist job applicants. Classification is done per use case, not per tool. An organisation with one tool and ten ways of using it has ten items to assess, not one.
Why you start with an inventory
The first question is not "is this high risk". The first question is which systems are we actually using. The answer is almost always incomplete, for three reasons:
- Embedded features. Existing business software acquires AI functionality through an update, without a procurement decision.
- Tools introduced by staff. The free tier of a tool someone uses to prepare documents passes through neither procurement nor IT.
- Supplier services. An external provider processing your data with the help of AI introduces it into your chain without a decision on your part.
The inventory is therefore not obtained by asking IT but by the same method used to build an asset register: walking the processes and talking to their owners.
Your role determines your obligations
The Act distinguishes roles, and the most important distinction is between whoever develops and places a system on the market and whoever uses it. Most organisations sit in the second group, with a substantially lighter set of obligations - but not with none.
That role can change through an incautious step, however. An organisation that takes someone else's system, puts its own name on it or substantially modifies it may take on the heavier obligations as well. Which is why a decision to fine-tune a model is not purely technical.
What to do now
- Build the inventory. System, owner, use case, data going in, decision it influences.
- Flag use cases that touch people. Recruitment, evaluation, access to services, employee monitoring - those are the areas where the level rises.
- Check the input data. If personal data goes in, the GDPR applies in parallel, with its own requirements for a lawful basis and impact assessment.
- Set the rules before you need them. An internal usage policy, with a clear list of what must not be entered into external tools, will prevent more problems than any subsequent analysis.
The AI Act applies in stages, with provisions taking effect at different dates. Prohibited practices and the AI literacy obligation apply first, obligations for high-risk systems later. Check which date applies to your situation before planning a project timeline.
Not sure where you stand?
Half an hour of conversation, with no obligation. By the end you know what needs doing and in what order.