What should you ask an AI automation partner before you sign?

The demo was good. Everyone in the room could see the invoice being read and the record appearing in the CRM. What you couldn't see is what happens in month four, when the supplier changes their layout, or who you call when the system approves something it shouldn't have.

These nine questions are the ones that surface that. Ask them before you sign, and ask for the answers in the proposal rather than across a table.

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 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 is one who has built a dependency, whether or not they meant to. Ownership, access and licensing should be written into the engagement terms, including for any third-party services the system uses.

2. What happens when it's wrong?

Every system is wrong sometimes. The question 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 why it decided that), and how a correction changes future runs. A bad answer talks about accuracy percentages and changes the subject. We've written about the design behind the good answer in how to keep a person in charge.

3. How will we know whether it worked?

The partner should name a measure, want a reading of it before the build, and commit to reporting against it afterwards. If they can't name one for your process, they don't yet understand what it's for. How to measure whether it paid for itself covers what that 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 anything. Ask what access the partner's own people have to your systems during and after the build. The answer should be specific to the design, not a policy page. If a technical evaluator on your side wants it in detail, that's a reasonable ask.

5. Which of our systems have you connected before?

Connections are where surprises live. A partner who has worked with your CRM or accounting package knows its limits. One meeting it for the first time will learn them on your clock. Neither is disqualifying, but you want to know which it is, and you want them to check your systems' connection options before the proposal rather than after.

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

The only test that counts is your real cases, including the awkward ones, run side by side with what your team would have done. Ask how many cases, who reviews the results, and what happens to the differences. A partner who tests on their own sample data is testing their product, not 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. The honest answer is never nothing. A partner who promises no involvement is either going to 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 its interface, 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 team if you want it to. The answer should be a line in the proposal, not a conversation to have when something breaks.

9. What would you tell us not to automate?

This is the question that separates a partner from a vendor. Some processes are better served by a simpler fix, a clearer form, or a conventional rule with no AI in it. A partner who has looked at your business should have an opinion on which of your ideas to leave alone, and why. If every answer is yes, nobody has looked.

Answers to be wary of

A few answers come up often enough to be worth naming. "Our accuracy is over ninety-nine percent" in reply to what happens when it's wrong: accuracy is a statement about the average, and your question was about the exception. "We handle all of that" in reply to who owns the system: ask again, in writing. "It's fully autonomous" in reply to what it needs from your team: either they haven't understood your process or they intend to learn it on your clock. "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 the question again and wait for a specific answer. The partners worth working with don't mind being asked twice, and the specific answer is usually better for both sides than the reassurance was.

How to use the answers

Put the nine questions in the brief you send to each firm, so the proposals come back in the same shape and can be compared. Then read the three that decide it first. If any of those answers is vague, the rest doesn't matter.

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

One more use for the list. The answers tell you what the first weeks of the work will feel like. A partner who names your exception owner before you do, asks for your real cases, and wants a reading of the measure before they build, is going to run the project the way you'd want it run. A partner who talks about the model, the platform and the roadmap is going to run it the way they'd want it run. The nine questions are a way to find that out before the first invoice rather than after the third.

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, the measure.
3. Read the three deciding answers first and put aside any proposal that doesn't answer them.
4. Ask for the remaining answers as lines in the proposal, not as reassurances in a meeting.

You can ask us all nine on the first call. Our answers to most of them are already written on the reliability page, and we'd rather you read it before we speak.