The European framework for regulating artificial intelligence rests on a simple idea: obligations depend on what the system does, not on how sophisticated the technology behind it is.
The risk-tier logic
The regulation sorts systems into categories, and each category carries a different set of obligations.
Prohibited practices. A limited number of uses are not permitted at all — for example those exploiting the vulnerabilities of particular groups, or carrying out generalised social scoring of individuals.
High-risk systems. Those used in areas where an error directly affects rights or safety: employment, access to education, essential services, safety components of products. This is where most of the concrete obligations sit.
Transparency obligations. Systems that interact with people, generate content or recognise emotions must make clear that they are automated.
Minimal risk. Everything else, with no specific obligations.
What \u201chigh risk\u201d means in practice
For a system in that category, the requirements translate into documents and processes that must exist before deployment:
- a documented, maintained risk management system;
- data governance: where data comes from, how it was checked, what gaps it has;
- technical documentation detailed enough for a third party to understand how it works;
- automatic logging of operation, retained for a defined period;
- clear instructions for whoever uses it;
- effective human oversight, not nominal oversight;
- an adequate level of accuracy, robustness and cybersecurity.
None of these can be added retroactively in a week. All of them presuppose decisions taken at design time.
The first question to ask
Not \u201cwhich model are we using\u201d, but: what decision does the system make or influence, about whom, and what happens if it gets it wrong?
A simple model used to filter job applications falls in the high-risk category. A very complex model used to suggest tags in an internal image library does not.
Your role in the chain
Obligations differ by role. Whoever develops the system has one set; whoever places it on the market under their own name has another; whoever merely uses it has a third. Many organisations consider themselves mere users but become providers in the regulation's sense the moment they substantially modify a system or market it under their own brand.
Worth starting now
Regardless of the exact application dates, three things are useful from day one and are never wasted:
- An inventory of systems. What automated decision systems exist in the organisation, what they do, who they affect, who is responsible.
- Documentation of decisions. Why this model was chosen, on what data, with what known limits, who approved deployment.
- A repeatable evaluation process. How the system is checked before and after launch, against what acceptance threshold.
Organisations that have those three will treat compliance as formalising what they already do. The rest will treat it as an emergency project.
This article describes the general structure of the regulatory framework and is not legal advice. For the specific obligations applying to a particular system, consult a specialist.