News in Practice
High risk: the regime is postponed, the characterisation is not
The deadline has moved to December 2027. Whether you fall within it is a question for now, since it determines the next eighteen months of work.
For firms and legal departments that need to establish their position. What Annex III covers, what actually concerns a legal organisation, and why the answer must be written down.
Does your use of AI fall within the high-risk regime? The question looks premature, since the corresponding obligations will not apply until December 2, 2027. It is not, for a reason of scheduling: if the answer is yes, compliance represents several months of work, and discovering that in the autumn of 2027 means doing it under pressure.
Why the question arises now
High-risk obligations are not declaratory. They presuppose a risk management system, technical documentation, logging, human oversight measures, a conformity assessment and registration.
They also presuppose that someone in the organisation owns them: designated, trained, and able to produce records over a defined retention period. None of these requirements is beyond a firm's reach, and none can be put in place in three weeks.
A firm discovering in September 2027 that it is caught would have three months to put all of that in place. That is materially insufficient, and it is the only reason the question deserves settling this year.
One should add that the burden of such compliance does not spread: it falls on the same people who already carry data protection and security, in organisations where those functions are rarely full-time.
Conversely, if the answer is no, establishing it now avoids reopening the question at every deadline and tying up a team on a settled matter.
What Annex III covers
It lists areas of use, not technologies. The same system may fall within the regime in one deployment and not in another, and that is the principal source of characterisation errors.
Three areas on that list may concern a firm or a legal department. Employment and worker management, covering in particular recruitment and evaluation. Access to essential services, public and private. And the administration of justice, covering assistance to judicial authorities in researching and interpreting facts and law.
A methodological point on reading the Annex: it targets purposes and contexts of deployment, so characterisation requires examining what the system does within the organisation, not what it is capable of doing. The same document-analysis tool deployed on client matters and on job applications receives two different characterisations.
That is what makes the exercise less intuitive than it appears, and what explains why it is often done badly: one instinctively reasons by tool, whereas the text reasons by use.
The case of legal production
This is the point on which firms most often wonder, and the answer is usually negative.
The area concerning the administration of justice targets assistance provided to a judicial authority. A law firm is not a judicial authority: it represents a party. A system assisting it in preparing submissions therefore does not, in principle, perform the function contemplated by that limb of the Annex.
This answer deserves to be established rather than assumed, for a practical reason: it will be asked for. A client, an insurer or an authority may question the firm on its position, and holding a dated analysis is worth more than a shared conviction.
A second reason argues for settling it now: it conditions procurement choices. A firm concluding that it falls within the regime would need to require technical documentation and a conformity assessment from its provider, which sharply narrows the field of available solutions and alters any deployment timetable.
Settling the characterisation before selecting a tool is therefore the logical order, and it is the opposite of common practice.
The characterisation risk does not sit in legal production. It sits in the internal uses nobody has inventoried.
Internal uses that raise the question
The risk is not where firms look for it. It lies in internal uses, where a firm acts like any other employer.
A system involved in screening applications, in evaluating associates or in staffing decisions falls within the employment area. The question then arises on the same terms as for any business, and it arises even where the system is a module of an HR platform that nobody has identified as an AI system.
The point is easy to miss because such modules are rarely presented as artificial intelligence. They are sold as ranking, matching or scoring features, and they are procured by a function that is not the one carrying compliance.
A related case is worth flagging: systems deployed by the firm on behalf of a client, for instance in an internal investigation concerning employees. Characterisation then arises on different ground, and it engages the client as well.
This is why an inventory of uses must precede characterisation: one does not characterise what one does not know one is using.
Why the answer must be written and dated
A characterisation has value only if one can establish when it was made, on what perimeter, and against which state of the text.
Practically, this means the analysis should be capable of being reread by someone who was not involved in it, in five minutes, two years later. That is a demanding standard and it is the only one that matters, since that is exactly the situation in which it will be used.
A 1–2-page document suffices: the list of uses identified, the characterisation adopted for each, the grounds, the date, and the name of the person who made it. This is the same requirement that applies to any legal analysis: a conclusion without a date or a perimeter is not enforceable, including against oneself.
It is worth mentioning what was examined and set aside, not only what was retained. A use examined and found out of scope should appear as such: that is what distinguishes an analysis from an oversight, and the distinction will be drawn by anyone rereading the document.
The document will need revisiting when the perimeter of uses changes, which will happen more often than expected: a software update can be enough to introduce a new function that alters the characterisation.
It has a second use, less obvious. The day a new use appears in the firm, the question of its characterisation arises immediately rather than waiting for the next deadline, because a framework exists to receive it.
This article sets out the state of the law at its review date. It does not constitute legal advice and does not replace a professional's analysis of a specific situation.