The four questions to ask before you buy AI automation

Why these four questions?

Because they target the part that fails. AI use is close to universal, with 88% of organizations reporting regular use in at least one business function,⁰¹ while 60% of companies report minimal or no value from the investment.⁰² Two different surveys, one consistent picture: the technology is everywhere and the value is not, which means the risk you are pricing in a vendor meeting is not whether the machine can read a document. It is whether this vendor's system will survive contact with your actual paperwork, your people, and your software, and keep surviving after the invoice is paid.

You cannot settle that by learning the vocabulary. You can settle it with four questions whose good answers are mechanisms anyone can inspect, and whose bad answers are audible to anyone in the room. The vendor's register is itself the test: every question below has a plain answer when the design behind it is sound.

Question one: where does our data go, and can we turn the access off?

A good answer names a place and a switch. The strongest shape: the system is built inside accounts your business already controls, the vendor works under access you grant, and you can revoke that access on any day you choose without the system stopping. Follow with the quieter half most vendors skip: what does the vendor's own website or product store about you and your staff, separate from the workflow's data? A vendor who separates those two without being pushed has thought about it.

A bad answer is a reassurance category: certification names, "bank-grade", "fully secure". Those words answer an audit question you did not ask. The question you asked has a mechanical answer, where the documents sit, who holds the keys, what happens on the day you say stop, and a vendor who cannot give it in one breath is describing someone else's system.

Question two: what happens when it is wrong?

A good answer assumes wrongness from day one and describes the machinery for it: anything the system is unsure about routes to a queue that one of your people works, with the original document beside the system's answer; anything consequential, a payment, a filing, a message a customer sees, waits for a person before it happens; and before go-live, the error rate was measured on your own paperwork against a bar someone on your side signed. Ask who signed the bar and on whose documents it was measured. Those two follow-ups take thirty seconds and expose more than any demo.

A bad answer is an accuracy number with no unit and no origin. A percentage measured on the vendor's benchmark describes the vendor's documents, and a percentage with no queue behind it describes a system whose errors go somewhere nobody is looking. The wrongness question is the one vendors most want to answer with capability; hold it to operations.

Question three: what does it cost, end to end, and when can we stop?

A good answer is a number that stops moving: a fixed price for the build, agreed before it starts, staged so you can stop between stages, with any paid diagnostic credited to the build it precedes. Running costs named separately and metered per document or per run, so the bill is legible against the work. The stopping question matters as much as the price: a well-shaped engagement has points where walking away is cheap and stated in advance.

A bad answer is a meter with no ceiling: per-seat pricing for a workflow that is not about seats, a subscription that quietly becomes the largest line, a pilot priced low with production priced later, after your alternatives have expired. Uncertainty about your own workflow is honest; a vendor unable to say what anything costs until you are committed is pricing your exit, not their work.

Question four: who owns it afterwards?

A good answer survives the vendor's disappearance. The system, its documentation, and its records are yours in writing; your people can run it after a handover, or the vendor runs it for a stated monthly fee that you can stop; and if the vendor vanished tomorrow, the system would keep running where it already lives, with the bills still arriving from your own suppliers. Ask that question in exactly that form, what happens if you disappear, and listen for whether the answer needs the vendor to exist.

A bad answer is ownership that evaporates on cancellation: the workflow lives in the vendor's platform, the configuration is theirs, the export is a PDF, and stopping the subscription means starting over. That is not automation you bought. It is automation you rent, priced accordingly, and the time to learn that is before the build, not at renewal.

What to do with the answers

Ask all four of every vendor, including us, and treat the register of the answers as data: plain mechanisms are what a sound design sounds like, and a technology lecture in response to an operational question is an answer to something you did not ask. Our own four answers are written down in buyer's words on the plain-English page, and the technical version, for whoever on your side wants it, is what we install, exactly. If you want a score before any meeting, the free readiness check takes three minutes, asks for no sign-up, and tells you which of the seven production gates your workflow already clears.

Frequently asked questions

What should I ask an AI vendor if I am not technical?

Four things, in plain words: where does our data go and can we turn the access off; what happens when the system is wrong and who catches it; what is the all-in price and when can we stop; and who owns the system afterwards. Every one has a plain answer when the vendor's design is sound, so a jargon answer is itself information.

What is a red flag in an AI vendor's answer?

An accuracy number that was not measured on your own documents, reassurance words in place of a mechanism, a price that only exists as a subscription, and any answer to the data question that does not include who can switch the access off. None of these requires technical knowledge to spot; they are answers to a different question than the one you asked.

Do I need a technical person in the room to evaluate the answers?

Not for these four. Each answer is checkable in operational terms: an access grant you control, a queue your own person works, a written bar with a name against it, a fixed price on paper, an ownership clause in the contract. A technical reviewer helps later, at the build; the disqualifying answers are audible to anyone.

What does a good answer on wrong answers actually sound like?

Something like: the system routes anything it is unsure about to a queue your person checks; anything consequential waits for approval before it happens; and before go-live the error rate is measured on your own paperwork against a bar you sign. If the vendor cannot say who looks at the queue and how often it was wrong last month, the system is not being operated, only sold.