What should you ask an AI partner before you sign?

The demo was good. Everyone in the room watched an invoice being read and a record appearing in the ERP. What nobody saw is what happens in month four, when a supplier changes their layout, or who you call when the system approves something it shouldn't have.

For a company without a data team, those questions carry more weight, because once the system is live, the partner you choose may be the only one who understands how it works. These nine questions bring the answers out. Ask them before you sign, and ask for the answers in the proposal.

The three that decide it

1. Who owns the system after launch?

The accounts, the workflows, the documentation and the connections should be set up in your company's name, so that if the relationship ends, the system stays. Ask it directly: if we part ways next year, what do we keep, and what stops working? A partner who hesitates has built a dependency, whether or not they meant to. Ownership, access and licensing belong in the engagement terms, including for any outside services the system uses.

2. What happens when it's wrong?

Every system gets things wrong sometimes. What matters is whether anyone notices and what they can do about it. A good answer names the person in your business who sees exceptions, what they see (the input, the system's output and the reason for it), and how a correction changes future runs. A weak answer quotes an accuracy figure and moves on.

3. How will we know whether it worked?

The partner should name a measure for your process, want a reading of it before the build, and commit to reporting against it afterwards. If they can't name one, they don't yet understand what the process is for. How do you measure the ROI of an AI project? covers what that reading should look like.

The six that shape the engagement

4. Where does our data go, and who can see it?

Ask which services the system will send your data to, where it's stored, and whether any of it is used to train a model. Ask what access the partner's own people will have to your systems during the build and after it. The answer should describe this design, in plain terms your finance director could repeat. AI security without a security team lists the follow-up questions.

5. Which of our systems have you connected before?

Connections are where the surprises are. A partner who has worked with your kind of ERP or ticketing tool knows its limits. One meeting it for the first time will learn them on your budget. Neither rules them out, but you want to know which it is, and you want them to check how your systems connect before the proposal is written.

6. How will you test it before it goes live?

The test that counts uses your real cases, including the awkward ones, run side by side with what your team did. Ask how many cases, who reviews the results, and what happens to the differences. A partner who tests on their own sample data has tested their product and learned nothing about your process.

7. What does this need from our team?

Time from the people who know the process, access to the systems, and a few sessions for review and testing. In a lean team that time is hard to find, so you want the number of hours and the names of the roles. A partner who promises no involvement will either ask for it later or build something that doesn't match how you work.

8. What does support look like after launch?

Systems drift. A supplier changes a form, a tool updates, a new kind of request appears. Ask who notices, who fixes it, how quickly, and what that costs. Ask whether the arrangement can end in a handover to your own staff if you want it to. If your IT team is two or three people, this answer is as important as the build itself.

9. What would you advise us not to automate?

Some processes are better served by a clearer form, a fixed rule with no AI in it, or being left alone. A partner who has looked at your business should have an opinion on which of your ideas to drop, and why. If every answer is yes, nobody has looked.

Answers to be wary of

• "Our accuracy is over ninety-nine percent", in reply to what happens when it's wrong. Accuracy describes the average, and you asked about the exception.
• "We handle all of that", in reply to who owns the system. Ask again, and ask for it in writing.
• "It's fully autonomous", in reply to what it needs from your team. Either they haven't understood your process or they plan to learn it on your budget.
• "We'll agree support later". Later is the month something breaks.

None of these is a reason to walk away on its own. Each is a reason to ask again and wait for a specific answer. The partners worth working with don't mind being asked twice.

How to use the answers

Put the nine questions into the brief you send each firm, so the proposals come back in the same shape and can be compared. Read the three deciding answers first. If any of them is vague, the rest of the proposal doesn't matter yet.

Once you've chosen, the answers become the terms. Ownership, exception handling, the measure and support all go in writing, so that what was said in the sales meeting is what you can hold the partner to in month four.

The answers also tell you how the first weeks will feel. A partner who asks who will handle the exceptions before you raise it, wants your real cases, and asks for a reading of the measure before they build, will run the project the way you'd want it run. A partner who talks mostly about the model and their platform will run it their way.

What to do this week

1. Write the nine questions into your brief before you send it to anyone.
2. Describe the process the same way to every firm: the systems, the volume, the exceptions you know about and the measure.
3. Read the three deciding answers first, and set aside any proposal that doesn't answer them.
4. Ask for the remaining six as lines in the proposal.

You can put all nine to us. Answering them for your process is how a strategy engagement starts: we look at the systems, the exceptions and the measure with you before anyone writes a proposal.

Get the next article when it's published.