Before choosing an artificial‑intelligence agent, a SME should list what will remain in human hands. This exercise, more useful than listing what one would like to hand over to the machine, defines the scope, the budget and how to evaluate the project.
A scope that is too broad makes the agent impossible to test.
The scenario recurs often. An executive watches a demo and imagines an assistant that would answer emails, qualify prospects, update the CRM (customer‑relationship‑management software), follow up on quotes and summarise meetings. On paper, it’s a project. In practice, these are five jobs, each with its own sources of information.
The first obstacle is testing. An agent is validated on concrete cases: a given request arrives, here’s what it must do. For a single task, a few dozen real cases cover most situations. For five, the combinations multiply, and it is often the edge cases that cause trouble. A client writes to place an order and complain about a delivery in the same message: who handles it, order processing or customer service?
Each additional access point, whether it’s email, the CRM or invoicing, also adds another door to secure. It is better to start with one task, one input channel and one expected result, then expand once that initial scope holds.
Three criteria to sort a task
The first criterion is frequency. A task that occurs twice a month hardly ever justifies an agent, because the time spent building, testing and maintaining it exceeds the gain. A task that occurs several times a day changes the equation, and provides enough cases to test before launch.
The second is rule stability. Just ask the person who does the task today if they can explain in one page how they decide. If the answer starts with “it depends” and continues with ten minutes of exceptions, the rule does not yet exist, and the agent will reproduce that ambiguity.
The third is the cost of an error. The question is not whether the agent will make a mistake, but what happens when it does. A mis‑classified email costs a few minutes. A wrong price quoted to a client or an appointment recorded on the wrong day costs much more, and is not always recoverable. If the error can be spotted before it leaves the company, automation is feasible. Otherwise, the agent prepares and a human validates the dispatch.
When the agent addresses the public directly, a legal obligation is added. Article 50 of the European AI regulation, applicable since 2 August 2026, requires that people know they are interacting with an AI, unless this is obvious from the context.
Choose the tool, then monitor the agent
For routine tasks such as appointment booking, inbox triage or meeting minutes, software maintained by its vendor and billed monthly already exist. The sensible reflex is to test one on real cases for a few weeks. Custom development is justified when the task depends on tools that the market cannot connect, when the rules are part of the company’s know‑how, or when the data cannot be entrusted to a third‑party platform.
A provider that processes personal data on behalf of the company is a sub‑processor under the GDPR. Article 28 requires that this processing be “governed by a contract or another legal act”. This contract must be requested before any connection, just as one must know what would happen if the vendor changed its prices or shut down the service.
Once the agent is in service, every processed request must leave a trace, and a weekly review of this log during the first month quickly shows where the agent hesitates. Model providers also evolve their versions, and an agent can change behaviour without any modification on our side. Keeping a series of anonymised real cases and replaying them after each change allows verification. Finally, the contract must specify who owns the code, the instructions and the automation scenarios, and the documentation must enable another provider to take over the agent.
