I thought we needed a new car. He wanted to know what was wrong with the one in the driveway.

You can see how this happens with a finance technology project. The team evaluating the solution has spent weeks imagining what it could improve. The people responsible for funding, security and controls are just getting their first look—and they have their own questions.

You’ve sat through too many boring demos. Started calculating the benefits. Then someone from IT security or audit asks a question that sends everyone back to the drawing board.

Our AP Institute benchmark survey found that 32% named IT/security or compliance/audit requirements as their biggest barrier to broader AI adoption. Another 34% named unclear ROI or budget. Bring the people who can say no into the room early—and ask what they would need to say yes.

Enthusiasm gets a project started. Funding and permission require something more specific.

The questions are part of the design.

An accounting leader sees hours spent chasing missing receipts. Finance wants to know whether reducing those hours changes costs or creates capacity the business will use. Security wants to know which records the system can access. Audit wants to understand who authorizes its actions and what evidence remains afterward. Each is evaluating a different part of the same proposal.

When those questions arrive after vendor selection, answering them can mean revisiting assumptions, narrowing access or changing the workflow. What feels like a surprise veto may be a requirement nobody asked about.

Give them one specific task to evaluate. “Use AI to improve AP” leaves too much open. “Recommend resolutions for PO price mismatches, with the buyer approving any price adjustment” gives everyone something concrete to examine. Then work through three questions together.

1. What work will actually disappear?

Start with what happens today. How many mismatches arrive each month? How much time goes into research, follow-ups and resolution? Then account for the work the proposed solution leaves behind. Someone may still need to review recommendations, investigate uncertain cases and monitor performance.

If AI saves ten minutes of research but adds eight minutes of checking, your business case needs to reflect that.

Be equally clear about the benefit. Recovered capacity could reduce overtime, absorb growth or let experienced staff address a backlog. State which outcome you expect and who will make it happen. Hours saved become valuable when the operation uses them.

2. What will the system be allowed to do?

Reading an invoice, suggesting a correction and changing a financial record require different permissions.

Define the boundary. Which information can the system access? Where is it processed? Can it recommend an action - e.g. human in the loop, execute it or both? Which decisions require approval?

Ask security and audit to help establish those boundaries before asking vendors to demonstrate how they meet them. That turns a broad discussion about “AI risk” into an evaluation of a particular task.

3. What evidence would justify moving forward?

Agree on the decision before launching the pilot. For the price-mismatch example, success might mean fewer AP follow-ups and shorter resolution time, while preserving buyer approval and a record of every change.

Test the awkward cases, too. What happens when the PO and invoice conflict? When an AI  recommendation is wrong? The pilot should show whether the process works under those conditions—and whether the people accountable for it can inspect, correct and stop it.

Make the next meeting count.

Before the next demo, put one page in front of finance, IT security and audit: the task, today’s workload, the proposed authority and the evidence you’ll collect.

Then ask each person:

“What would you need to see to say yes?”

You may uncover a requirement that changes the project. Better to discover it while you can still shape the solution than after you’ve promised the result.