Artificial intelligence is becoming increasingly prevalent in the workplace. Many companies are already testing assistants, content generation tools, or solutions capable of automating specific tasks.
However, moving from a one-off test to a fully integrated enterprise solution changes the nature of the project.
It is within this context that the European Union adopted the AI Act, a regulation establishing a common framework for the development and use of artificial intelligence within the EU. Having entered into force in August 2024, it is being implemented gradually over a multi-year timeline.
As soon as an AI is involved in a business process, accesses internal data, interacts with customers, or triggers actions, new questions arise. With the AI Act, these questions now also carry regulatory weight.
The goal, however, is not to hinder AI projects. The priority is to provide better structure from the outset.
The AI Act is based on a simple logic: requirements depend on the level of risk associated with the AI's use.
This risk level depends not only on the technology used, but primarily on the use case and its context. For example, an internal assistant that searches for information in documentation can have very different implications depending on the nature of the data accessed, the employees using it, and the potential consequences of its responses.
Before discussing technology, you must first define the use case:
This step is essential. Saying "we want to use AI in recruitment" or "we want an AI agent for customer service" is still too vague.
The project design depends on what the system actually does in practice.
AI can operate at different levels of responsibility.
It can simply assist a user, for example by summarizing a document or drafting a response. It can also recommend an action, generate content, or even trigger certain operations itself.
This distinction has a direct impact on how the solution is designed.
Take a customer service agent, for example. Allowing it to suggest a response to an employee is very different from allowing it to automatically issue a refund or modify an order.
The more autonomy an AI has, the more thought must be given to the limits imposed upon it.
Certain questions then become central: in what situations must a human intervene? Which actions can be automated? Which cases must be blocked or transferred to an employee?
For certain high-risk systems, the AI Act explicitly requires human oversight. But even outside of these cases, clearly defining the human's role remains a best practice in design.
Transparency is another practical issue.
When a user interacts directly with an AI system, they must, in certain situations specified by the AI Act, be informed that they are interacting with an AI.
For a company developing a chatbot or a conversational agent, this directly influences the user experience.
In particular, you need to consider how to introduce the assistant, how to explain its limitations, and at what point to allow the user to switch to a human.
A chatbot that answers general questions does not have the same impact as an agent that handles a complaint, a contractual issue, or a complex situation.
Transparency should therefore not be viewed as a simple note to add to the interface. It is an integral part of designing the user journey.
An AI solution becomes truly useful when it can work with company context: internal documents, CRM, ERP, knowledge bases, or business tools.
But these connections require setting clear boundaries.
What data can the AI access? Can it only read information or can it also modify it? Can it send an email, create a ticket, or update a customer record? Should certain actions require validation?
You must also be able to understand what the system did when a problem occurs.
Depending on the system type and its risk level, the AI Act may impose specific requirements regarding risk management, documentation, logging, or security.
But regardless of regulations, these topics are primarily important architectural choices.
Limiting access, controlling permissions, or keeping a record of certain actions helps build a more reliable and easier-to-operate solution.
The risk would be to assume that all these issues require designing a complete solution immediately.
For many AI projects, a progressive approach remains the most effective: scope → develop a POC → test → measure → secure → deploy.
A POC allows you to quickly verify if the idea actually works.
Take a company that wants to develop an assistant capable of answering employee questions based on internal documents.
Before deploying the tool to the entire organization, a POC helps answer a few essential questions: Are the answers reliable enough? Does the tool find the right information? What are its main failure points? Do users actually save time?
This phase also makes it possible to identify constraints related to data, security, or technical integration earlier on.
The goal is not just to verify that the AI "works." It is primarily about determining whether it provides enough value in the company's real-world context.
The success of an AI project does not depend solely on the chosen model. It depends primarily on how the solution is conceived and integrated into its actual context of use.
What problem are we trying to solve? What role are we giving the AI? What data can it use? How far can it act on its own? When should a human intervene? How do we measure the quality of the results?
The AI Act reinforces the importance of these questions without hindering experimentation.
For a company, the challenge is therefore less about starting with regulation and more about starting with a well-defined use case and a design adapted to its risk level.
It is with this logic that DJM lab supports companies, from scoping needs to developing POCs, MVPs, and AI solutions integrated into existing tools and processes.
At DJM Lab, we don't just build products. We build success stories.
