5 questions to ask an AI vendor before signing

Every AI assistant demo looks alike: a question, a flawless answer, astonished faces. What separates a serious product from a future problem isn't visible in the demo; it's visible in how the vendor answers five uncomfortable questions. These are the ones I'd ask, along with the answer you should expect to each.

You don't need a technical background to ask them. And you don't need to understand every answer in depth either: as you'll see at the end, it's often enough to notice how they answer.

1. Is the permission applied when searching for the information, or after finding it?

It's the most important question on the list and the one asked least. Many systems first retrieve everything relevant to the question and then filter out what the user shouldn't see, already in the application layer. That order (search first, filter afterwards) is a recurring failure pattern in the industry: it only takes an error in the filter, an unfilled metadata field or a connector that indexed too much for HR or management information to end up in anyone's answer.

The answer you want to hear: «the permission is part of the query itself, enforced at database level». The one that should worry you: «we filter the results before displaying them». They sound similar; they are not the same.

2. Does employees' sensitive data pass through the same search index as everything else?

Payroll, performance reviews, personal data. If all of that is vectorised and enters the same semantic search index as the product manuals, the problem is structural: the search returns what is relevant, and for an innocent question about «weekend bonuses» the most relevant thing might be the entire salary table.

The answer you want to hear: sensitive data does not enter the semantic search pipeline. It lives separately, and every access to it is checked on the server, query by query.

3. Can I see who asked what and what they were told?

Without traceability you can't audit anything: you can't detect misuse, you can't understand why the system answered what it answered, and you can't demonstrate what information each person saw. Ask for two concrete things: that every answer cites its source verifiably (a document, a conversation, a person) and that a complete log of questions and answers exists.

And a third that almost nobody asks for: that the vendor's own support sessions are audited too. Whoever enters your system to fix something should leave the same trail as any of your employees.

4. What does the system do when it doesn't know the answer?

Language models have a natural tendency always to answer something, whether they know it or not. In a company, an invented answer delivered in a confident tone is worse than an «I don't know»: someone is going to act on it. Ask what happens when the information simply doesn't exist in the knowledge base.

The good answer: the system acknowledges it, logs the gap and routes the question to an expert. The bad one: «our model always finds something».

5. What happens to my data if I stop being a client?

Before going in, plan the way out. Three concrete things: how you export your knowledge (in a format you can reuse, not an unreadable dump), within what period your data is deleted and how that deletion is verified. And while you are a client: how it is guaranteed that your data doesn't get mixed with other companies'. The phrase you're looking for is «multi-tenant isolation», ideally enforced in more than one layer and verified with automated tests, not with promises. And ask for all of this to be in the contract, not in the sales rep's goodwill.

The bonus question: where do the models run?

If your sector requires that no data leaves your infrastructure, ask whether there's an option to run the models locally. Not every company needs it, but the answer tells you where the vendor's ceiling is. And even if you don't need it today, the reaction is revealing: someone who designed their system with isolation as a principle can at least consider it; someone rigidly dependent on third parties cannot.

How to read the answers

You don't need to understand the technical implementation of any of this. Pay attention to the shape of the answers. Someone who has solved it by design explains it to you in two sentences, precisely and without getting defensive, because they made those decisions at the start and know exactly why. Someone who patched it afterwards rambles, generalises, or assures you that «that has never happened».

I'll say this with my cards on the table: these questions are not neutral. They are exactly the ones I forced myself to answer properly when I started building Savia, because every shortcut in security is a debt the client ends up paying. But that's precisely why you can take them into any meeting, with any vendor, including me. A serious vendor shouldn't get nervous about any of the five.