What to ask before buying any AI tool

Buying an AI tool is easy. Living with it for two years is the difficult part. Almost every demo works: it is prepared with clean data, the most favourable use case and someone who knows the product by heart. The real cost appears later, when you need to connect the data that actually exists, fit the tool into the workflow, explain to the team what it does and decide what happens on the day it makes a mistake.

This is not a problem confined to large companies with purchasing departments. A small business buying a chatbot, an invoicing assistant or a voice agent faces exactly the same risk, only without a legal department reviewing the contract before signing. What follows are the questions we ask before recommending a tool. They are not a procurement form: they are the five points where, when something goes wrong, it was almost always wrong from the moment of signing.

What happens to my data if I want to leave?

The answer you need in writing: the data leaves with you, in a format another system can read, with its full history and without relying on the supplier’s goodwill. Everything else in this section is about checking that sentence is true.

The first question is not about features: it is about the exit, because that answer determines everything that follows.

For a small business, the question is: if I stop paying next year, can I take my data, the instructions we have refined and the conversation history with me, or do they stay inside the platform?

It is worth going one level deeper, because “yes, you can export” allows very different answers: export in what format, with which fields, how long does it take, and who does it? A consultancy that has spent two years answering customer questions with an assistant has a real asset there; if the export is one PDF per conversation, that asset does not exist.

Two more questions belong in the same conversation, both yes-or-no. Is our data used to train the supplier’s model? Who writes and maintains the code connecting the tool to our systems? If the answer to the second is “your IT person”, the supplier is not selling a platform: it is selling a component someone in-house will have to assemble and maintain.

Is the integration real or a workaround?

It is real if the AI tool reads and writes directly in the application where the work already happens; it is a workaround if it moves files or data through an intermediate layer someone has to watch.

“More than a thousand integrations” tells you nothing: only one matters, and two very different things are described with the same word. A native connection reads and writes data in that application. A generic connector built on an intermediate layer moves information from one place to another when a condition is met, and someone has to fix it every time a field changes.

For an accounting practice or professional firm, the question is very specific: can this tool read and write directly in the management software we already use, or will someone have to export and import files manually every week? If the answer includes the word “export”, the tool does not remove that work: it moves it elsewhere and adds another point of failure.

The way to check is to ask for specifics. Which exact field is written, which screen it appears on, what happens if two people edit the same record at once. A supplier that has already built that integration answers in a minute; one that has not answers with the number of integrations it offers.

What happens when it fails?

The question is not whether it fails — every AI tool makes decisions based on probabilities and therefore makes mistakes — but whether the failure is visible, acknowledged and passed to a person with the context in front of them.

Every demo is prepared with questions the system answers well. The test that actually tells you something is the opposite: ask, in front of the supplier, a question the tool clearly should not know how to answer, and see what it does. Does it say it does not know, or confidently improvise an answer? Does it hand over to a person? And when it does, does that person receive the complete conversation, or must the customer explain everything again from the beginning?

In customer support and voice agents, that difference is almost the whole product. A well-handled failure is invisible: the customer feels they are being passed to someone who already knows what the issue is. A badly handled failure is why a customer gets angry with the brand, not the technology, and no later model improvement can recover that conversation.

What can you really demand from a supplier?

Specifics, not percentages.

Here it is worth challenging a much-repeated piece of advice: that suppliers must give you figures from customers similar to you. It sounds demanding and is the opposite. A savings percentage is the easiest thing to produce and the hardest to verify: nobody publishes the projects that went wrong, most of those numbers have neither a baseline measurement nor a method behind them, and “40% less time” without the process it refers to cannot be checked or reproduced.

We do not publish customer percentages either, so we do not recommend asking anyone for them as proof.

The specifics you can demand, where a capable supplier distinguishes itself in five minutes: which process is automated and which is not, what data the system works with, what it decides alone and what it leaves to a person, what happens when it gets something wrong and who detects it, how much work we need to do before it runs, and how we leave. If the answer to “how much time does this actually save?” is a round number rather than “it depends on how many cases arrive through that channel and what they look like today”, the problem is not modesty: nobody has looked at the process.

It is the same difference as that between a catalogue and a comprehensive AI audit: looking at the process, the available data and what happens when the system makes a mistake. None of those three questions is answered with a percentage.

Does it comply with what the law already requires?

In the European Union this is no longer optional, and there is no need to present it as a threat. Any tool that talks to customers, uses voice or generates automated content should be able to explain its risk category under Regulation (EU) 2024/1689 and the transparency obligations it meets. A serious European supplier has a written answer and sends it without having to be chased.

Asking before signing avoids rebuilding a process later. The provision affecting the most businesses is Article 50, whose transparency obligation has applied since 2 August 2026: disclose that someone is talking to an automated system and identify AI-generated content. If the bot you buy today does not let you configure that notice where it needs to be read, you inherit the problem along with the tool. The complete timetable, including what was postponed and what was not, is in what really changes in August 2026.

The question that sums up all the others

Before signing, you should be able to answer three questions without relying on intuition: which specific process is being automated, what happens if the supplier raises its price or disappears, and who is responsible if the tool makes a mistake in front of a customer. If those three answers are unclear, it is not time to buy the tool yet, however good it looked in the demo.

In the most practical terms, these are five sentences you can read aloud in the meeting:

• “If we stop paying in January, what do I take with me, and in what format?”
• “Does it write directly to our management software? In which field?”
• “Ask it a question now, here, that it should not know how to answer.”
• “What does the system decide on its own, and what does it leave to a person?”
• “Which transparency obligation does it meet, and where is the notice configured?”

None of the five requires technical knowledge, and all five can be answered in one meeting. A supplier that works well welcomes them, because they prevent an unhappy customer in month six. One that dodges them has already answered.