“Can your assistant get things wrong?” During a sales demonstration, the question can sometimes dampen the mood. The audience has just seen an impeccable summary, an instant answer, a document drafted in seconds. Acknowledging limitations can then seem to undermine the promise. Yet the real risk begins when nobody knows what to check. For teams deploying AI, the challenge as autumn 2026 begins is less about providing reassurance at any cost than about building trust that works in practice: knowing when to follow the tool, when to check its output and when to hand over to a person.
Trust cannot be established by declaration during a demonstration
Generative assistants have introduced an ambiguity into customer relationships. Their verbal fluency looks like expertise, even when they produce false information. Clear wording, a professional tone, a few references: everything encourages users to read the answer as if it came from a specialist. Yet the quality of the presentation does not guarantee the soundness of the content. For a user in a hurry, that distinction remains difficult to spot.
The Air Canada case illustrated this in concrete terms in 2024. A customer received incorrect information about a bereavement fare from the airline’s chatbot. British Columbia’s Civil Resolution Tribunal held the airline responsible for that information. The lesson extends beyond air travel: providing an automated interface is not enough to shift responsibility onto the tool or its user.
The events cited here are documented precedents; the proposals for September 2026 are forward-looking analysis. One development nevertheless appears fundamental: as AI becomes involved in sales, document handling and administrative processes, explaining the conditions for its use becomes part of the service. It is no longer merely a legal precaution or a task reserved for engineers.
Explain what can go wrong, not just that AI is imperfect
“AI can make mistakes” is a true statement, but not a particularly useful one. It does not explain which mistakes, under what circumstances or with what consequences. Repeated beneath every answer, it risks becoming background noise. The customer hears a general caveat, but is still left to discover the dangerous situations alone.
An effective explanation distinguishes three dimensions. Scope: which sources, languages and documents are covered? Weaknesses: what happens when a document is missing, a rule is new or a request is ambiguous? Action to take: what should be checked before making a decision? This breakdown turns an abstract weakness into concrete guidance.
For an assistant that analyses contracts, for example, it is better to state: “It identifies clauses in the documents provided, but may miss an exception spread across several appendices. Have your legal adviser review any points that create binding obligations.” This wording does not eliminate risk. It provides an understandable boundary, linked to an action and a person to consult.
Make uncertainty a conversation
Start with the customer’s intended use
Before explaining the model, it is important to understand the decision it is meant to inform. Producing a first draft and confirming entitlement to compensation do not require the same level of reliability. The right question becomes: “What will you do with this answer?” It reveals the real stakes without subjecting the customer to a lesson on probability or neural network architecture.
This is where interpersonal skills matter: listening, restating what has been said and being able to ask an uncomfortable question. A deployment lead must be able to say: “If this answer triggers a payment, our current setup is not sufficient without an additional check.” That does not sabotage the sale. It avoids selling a use case the system cannot safely support.
Explain without overwhelming
Presenting everything at once is no more helpful. An endless set of instructions may protect the organisation on paper, but leave the user at a loss when it is time to act. A stronger approach is to distribute the information: essential limitations before adoption, contextual alerts during use and technical details in accessible documentation. Effective transparency comes at the right time.
Confidence percentages also require caution. A score is useful only if its meaning is clear and its reliability has been assessed in the relevant context. Otherwise, it dresses uncertainty in misleading precision. Indicating that a source is missing, a document is old or two references contradict each other can be far more informative than a green gauge.
Show limitations during the demonstration
A demonstration made up entirely of successes teaches a bad habit: believing that the system always knows how to answer. It should also include an incomplete case, an out-of-scope question and a situation in which the assistant should refrain from answering. The customer then discovers not only what the tool produces, but how it behaves when conditions deteriorate.
This approach requires internal alignment. If the salesperson promises complete autonomy, the product displays a discreet warning and support later demands human validation, the customer receives three versions of the service. A shared vocabulary must connect the sales promise, the interface, training and the contract. Caveats cannot appear only after an incident.
- Before use: explain which tasks are suitable and identify important exclusions.
- During use: flag missing information and make sources available for consultation where they exist.
- After an error: offer a correction, a route to human assistance and a verified explanation.
After an error, acknowledge before justifying
When a customer reports a false answer, immediately explaining that models are probabilistic sounds like an evasion. The first response must acknowledge the problem and its impact: which information was incorrect, which process was affected and what can be put right? Technical analysis comes next, with a clear distinction between an established cause and a hypothesis.
It is also important to resist the reflexive promise: “This will not happen again.” Correcting a document repository does not prove that every future answer will be accurate. It is better to describe the action taken, the tests carried out and the remaining risk. Such precision may seem less reassuring in the moment; it prevents a second breach of trust.
The European Union’s AI Act, adopted in 2024, includes transparency obligations for certain interactions with AI systems in its implementation timetable. But identifying a chatbot as such is not enough to explain its reliability. For teams, the work of managing customer relationships remains: training users, organising escalation and checking that warnings are understood, not simply displayed.
What next? From September 2026, the ability to set honest boundaries around use could become a competitive advantage. The most credible teams will not necessarily be those promising the fewest errors, but those making errors detectable, open to discussion and correctable. That requires a collective practice: trust does not rest on a well-worded disclaimer, but on what happens when the model actually reaches its limits.
