The legal expert asks for human oversight. The developer adds an approval button. The business manager explains that nobody will have time to click it. In three sentences, a meeting about artificial intelligence can reveal the real obstacle to compliance: teams use the same words without meaning the same thing. Looking ahead to September 2026, the phased implementation of the EU AI Act makes this challenge critical. Knowing how to translate a rule into an operational decision is becoming a collective skill, as important as the quality of the model.
One regulatory timetable, several internal clocks
The EU regulation on artificial intelligence entered into force on 1 August 2024 and provides for phased implementation. The provisions on prohibited practices and AI literacy have applied since 2 February 2025. A further stage, covering general-purpose AI models in particular, took effect on 2 August 2025. Under the legislation’s original timetable, 2 August 2026 marks the next major milestone, while certain obligations relating to high-risk systems embedded in regulated products are scheduled for August 2027.
These dates do not mean that all tools become subject to the same obligations simultaneously. Transitional provisions exist, particularly for certain systems or models already on the market. This outlook towards September 2026 is based on the adopted regulation and its original timetable: any subsequent changes must be checked against the applicable legislation. The first useful skill, then, is knowing how to ask the question before announcing a deadline.
Yet each function runs on its own clock. Legal teams think in terms of application dates, developers in releases, procurement in contract renewals and business teams in quarterly targets. Without coordination, everyone can meet their own schedule while causing the project to miss its deadlines.
Translate use cases before translating the law
Take a hypothetical case: a company wants to use an assistant to prepare for recruitment. “It only saves time,” the business team insists. But what exactly does it do? Does it write a job advert, summarise applications or rank candidates for interview? These uses do not raise the same questions. Certain systems intended for recruitment or selection fall within the regulation’s high-risk categories, subject to the specified conditions and exceptions.
The dialogue must therefore begin with verbs, not commercial labels. Who provides the data? What does the system produce? Who reviews the output? What decision might follow from it? A demonstration of an end-to-end workflow is often worth more than a presentation promoting a “responsible” solution. It allows the legal expert to understand the actual use and the developer to see the consequences of their choices.
Identifying the roles of the parties involved requires the same precision. Is the company a provider, a deployer, or potentially subject to a change of role if it substantially modifies a system? Buying an interface does not, on its own, answer that question. A shared vocabulary does not eliminate legal complexity; it prevents that complexity from being hidden behind shorthand.
Turn an obligation into a verifiable decision
Translation becomes useful when it connects a requirement to an observable action. “Ensure human oversight” remains abstract. Determining who can interrupt processing, with what information and what authority, is already a design decision. For the systems concerned, oversight is not simply a matter of placing a person at the end of the process: that person must also be able to understand, challenge and correct.
In our hypothetical recruitment scenario, the team could consider one proposal: not allowing an automated ranking to trigger a rejection on its own. This choice is neither a universal solution nor a guarantee of compliance. It does, however, force a discussion about the time available, access to the original applications and the risk that the recruiter will mechanically follow the recommendation.
A shared framework can fit into five lines per topic:
- The requirement: what the applicable legislation requires, with its source.
- The specific risk: what could happen to a person or to the process.
- The decision: what the team builds, limits or abandons.
- The evidence: the test, document or record that makes it possible to verify this choice.
- The owner: the person responsible for the action and its follow-up.
This framework avoids two dead ends: the legal memo nobody knows how to apply and the feature delivered without an explicit link to the obligation. It also makes disagreements visible before they become incidents.
Structure disagreement rather than seek a weak consensus
An effective meeting is not one in which everyone agrees. It is one in which objections become actionable. The legal expert must be able to distinguish between a prohibition, an obligation subject to conditions and an area of uncertainty. The developer must specify what is technically possible, costly or impossible to guarantee. The business team must acknowledge when its working arrangements prevent a check from being carried out, even though the interface provides for it.
Restating one another’s constraints is a simple exercise: each person explains the other’s constraint before defending their own solution. “If I understand correctly, you need to be able to retrieve the information that led to this recommendation.” Or: “Your team cannot review every application again within the current timeframe.” This discipline exposes false agreements without requiring everyone to become an expert in an adjacent field.
A decision-making rule is then needed. Who decides to narrow the scope, postpone the launch or accept a residual risk within the limits of the law? The decision deserves a brief record: options considered, reasons for the choice, reservations and conditions for review. Compliance then gains an institutional memory rather than a collection of scattered approvals.
Train people to act
Article 4 of the regulation provides for measures to ensure a sufficient level of AI literacy among staff and other relevant people, taking into account their knowledge, experience and context of use, among other factors. This approach goes beyond identical, generic training for everyone. Knowing how to write a prompt for an assistant is not enough to understand when its output becomes dangerous or inappropriate.
A procurement professional must know what information to request from the provider. An operational manager must recognise when use drifts from its intended purpose. A developer must understand why certain tests need to replicate real-world conditions. Short workshops built around a plausible incident can help develop these instincts: a fabricated output, a disputed recommendation or a model change by a service provider.
Concrete progress can then be observed without inventing a magic metric: are requests better described? Are warnings raised before launch? Do teams know whom to contact when they have doubts? The quality of the dialogue is measured above all by the decisions it enables.
What next? As implementation of the regulation progresses, organisations may discover that their best investment is not another committee but a few robust habits: describing uses, restating constraints, documenting decisions and revisiting them when the system changes. That is the challenge ahead: making compliance a shared capacity to adapt, rather than a final check whose conclusions nobody really understands.
