It starts with the tool and stalls at the pilot
Many artificial intelligence projects begin like this: licences for an assistant are bought for everyone, there is a presentation, and then everyone waits. A few months later a couple of people use it to rewrite emails, the others have forgotten about it, and nobody can say whether it has helped. Or an interesting pilot is launched and stays a pilot, because nobody had decided beforehand what it was supposed to prove.
The right starting point is the opposite: a specific task that costs time today, and a simple question. If AI did it well, what would change? The tool comes later.
Where to start: the tasks that waste time
Ask each department where its time goes on repetitive work. Typical answers: customer service answers the same questions every day; the accounts team retypes supplier invoice data by hand; technicians hunt for the right procedure in shared folders; someone sorts the emails in the general inbox by hand. Each task should be assessed against two criteria: its value if it works, and its feasibility, meaning whether the data exists and what an error costs.
| Task | Value if it works | Data needed | If it gets it wrong |
|---|---|---|---|
| Recurring customer questions | Fewer repetitive calls, answers outside office hours too | An up-to-date set of answers | The customer gets wrong information: there must be a handover to a person |
| Data from invoices and documents | Less retyping, fewer typing errors | Legible documents, clear fields | A wrong amount in the accounts: a check is needed |
| Searching internal documents | Less time wasted searching | Well-organised documents, current versions, correct permissions | An outdated procedure, or a confidential document shown to someone who should not see it |
| Email classification | Requests routed faster | A history of previously sorted emails | A request ends up in the wrong queue and is delayed |
The ideal first project has clear value and an error that costs little or is easy to catch. Cases where a mistake affects a person, a contract or a payment can come later, with more checks.
An assistant is only as good as the documents it reads
One of the most requested use cases is the internal assistant that answers questions using company documents. It works like this: when a question comes in, the system first finds the relevant passages in the documents and then builds the answer on them, showing where they came from. That is the difference between an assistant that answers by citing its sources and one that produces plausible text that may well be made up.
It follows that quality depends on the documents. If three versions of the price list and an outdated procedure that nobody ever deleted sit side by side in the folders, the assistant will use them all. And it must respect the permissions of the person asking: it should search only where that person could already go on their own. In the story The assistant that knew when not to answer we explain why, in a real project, permissions came before the model.
A pilot that leads to a decision
- Decide the metric before you start: time saved on a specific task, errors avoided, requests handled without intervention. Measure how things stand today, otherwise you will have nothing to compare against.
- Appoint an owner in the company who knows the process and has time to devote to it.
- Use real users and real data: a demo on hand-picked examples always goes well, and that is exactly why it proves nothing.
- Set a duration, and a criterion for deciding at the end whether to continue, adjust or stop. Stopping is a legitimate outcome.
Where errors are costly, a person stays in the loop: the AI proposes, someone checks and approves. That applies to an invoice to be recorded just as much as to a reply to a complaint.
The costs that are not in the subscription
Licences are charged per user or by consumption, according to how much the service is used; with consumption pricing, spend grows as use grows, and it needs watching. But the subscription is only part of the cost. There is also the integration with the systems you already use (the ERP, the CRM, the document archive), the work of putting the data in order, and maintenance: documents to update, checks on the answers, models that change version and need to be tested again.
Rules first, not as an afterthought
You need a usage policy stating which data can be entrusted to these tools and which never can: without one, people use outside services on their own initiative, as the guide on Shadow AI explains. Then there is the AI Act (Regulation (EU) 2024/1689): the obligations depend on the risk level of the use case, and the Regulation also calls for AI literacy among the staff who use these systems (Article 4). You will find the levels, obligations and deadlines in the guide on what changes with the AI Act.
Adoption has to be built
The training that works is practical: a session on people's own work, with their own documents, is worth more than a generic course on artificial intelligence. And there needs to be a simple channel for reporting when the assistant gets something wrong or cannot answer. Those cases are the best material for improving it, and they often show which documents are missing or need correcting.
In short
An AI project starts from a task where time is lost today, not from a tool. You choose a case with clear value and manageable errors, put the data in order, measure a pilot against a metric decided in advance and make the decision based on the result. Usage rules, full costs and practical training make the difference between an experiment and a tool people actually use.