Before You Buy AI Implementation, Buy the Decision

A lot of AI proposals start too far down the road.

The vendor is already talking about integrations, deployment phases, and production timelines. The buyer still has not defined the workflow, the data boundary, who owns the outcome, or what a good result is worth.

That is not implementation readiness. It is expensive optimism.

When the business problem is real but the delivery path is still fuzzy, the first paid step should usually be a fixed-scope assessment. The point is not to buy more discovery meetings. The point is to produce enough evidence for a clear decision: proceed, revise the idea, compare other options, or stop.

A useful assessment buys down uncertainty. A weak one just delays the sales pitch.

An implementation proposal assumes too much

Implementation pricing only means something when the scope is credible.

If nobody has mapped the current workflow, a vendor cannot know which exceptions will require human judgment. If the data sources are unknown, the integration estimate is partly a guess. If success measures are missing, the buyer has no clean way to accept the work or reject it.

The proposal may still look polished. That does not make it dependable.

Before you accept an implementation promise, you should be able to answer:

Which exact workflow is changing?
What triggers the work, and what closes it?
Which systems, files, and data fields are involved?
What may the AI read, write, send, or retain?
Which decisions stay with a person?
Who owns exceptions, support, spend, and shutdown authority?
What baseline will the new process be compared against?
What evidence would make the company say no?

These are buying questions. They are also scope questions. Skipping them does not make the project move faster. It moves the uncertainty into implementation, where every unanswered question costs more.

The assessment should end with a decision packet

Do not buy an assessment because the word sounds responsible. Buy a defined deliverable.

The output should be a decision packet that another qualified team could review without sitting through every discovery call. At a minimum, it should contain seven things.

1. A bounded problem statement

The assessment should name one business problem in plain language. “Use AI in customer service” is not a problem statement. “Reduce the time agents spend finding approved return-policy answers without letting AI approve exceptions” is closer.

The boundary matters. It keeps a broad AI ambition from becoming an open-ended technology project.

2. A current workflow map

Document the trigger, steps, systems, handoffs, delays, common exceptions, and final output. Include the work people do outside the official process. The spreadsheet, side conversation, or manual approval everyone forgot to mention may be the part that decides whether automation works.

This is also where you ask whether AI is necessary. A simpler integration, rule, form, or process change may solve the problem with less cost and risk.

3. Requirements and risk boundaries

Write down what the solution must do, what it must never do, and what needs human approval.

The NIST AI Risk Management Framework Playbook tells organizations to document the intended purpose, business value, risk tolerance, requirements, application scope, expected benefits and costs, and human oversight. That is a solid structure for commercial discovery too. You cannot price a responsible implementation until those boundaries are visible.

4. A data and integration map

List every source system, destination system, data owner, permission, interface, and retained copy involved in the proposed workflow. Mark what is confirmed and what is still an assumption.

Do not accept “we integrate with your CRM” as a complete answer. Which objects? Which fields? Read only or write access? How is identity handled? What happens when the API is unavailable? Who fixes a failed connector after launch?

If sensitive data is involved, use the assessment to document the questions the vendor must answer about processing and retention. Our AI vendor data retention guide can help structure that review.

5. A cost model with named assumptions

The assessment does not need to predict every dollar perfectly. It does need to expose the cost drivers.

Include software and model usage, implementation services, internal labor, integration work, security review, testing, training, monitoring, support, and expected change after launch. Show which figures came from a vendor quote, which came from internal records, and which are estimates.

A neat total built on hidden assumptions is not a budget. It is a sales number.

6. Options, not one predetermined answer

A vendor-led assessment often ends with the vendor’s product. Shocking, I know.

A buyer-focused assessment should compare viable paths. That may include improving the current process, configuring an existing platform, buying a specialized tool, building a narrow workflow, running a controlled pilot, or doing nothing yet.

The options do not need equal weight. They do need honest tradeoffs across cost, speed, risk, internal ownership, portability, and operating effort.

7. A go, revise, or stop recommendation

The assessment should end with a decision and the evidence behind it.

NIST’s Manage guidance includes a direct decision point: determine whether the AI system achieves its intended purpose and whether development or deployment should proceed. It also asks organizations to consider viable non-AI alternatives and assign responsibility for disengaging or deactivating systems that do not perform as intended.

That is the standard buyers should expect. A decision packet that cannot recommend stopping is probably a proposal in disguise.

What the assessment should exclude

Clear exclusions protect both sides.

Unless the scope says otherwise, the assessment should not include production deployment, unlimited workshops, custom model development, final legal conclusions, security certification, guaranteed savings, or a promise that a named vendor will work in your environment.

It should also separate confirmed facts from open questions. “The platform supports an API” is not the same as “the platform supports the specific write action this workflow needs under our license and security policy.”

The assessment is allowed to find a blocker. That is part of its value.

How to keep paid discovery from becoming theater

Some buyers hear “assessment” and picture weeks of interviews followed by a generic slide deck. Fair concern. Put acceptance criteria in the statement of work.

Require the provider to state:

The decision the assessment will support
The named deliverables and file formats
The people and records the buyer must make available
The assumptions that will be tested
The options that will be compared
The person accountable for the recommendation
The date of the final decision review
What happens if evidence is unavailable
Whether implementation pricing will be separate

Ask for sample artifacts with confidential information removed. Look for actual workflow maps, requirement tables, assumption logs, and decision criteria. A table of contents is more useful than another promise of “strategic clarity.”

Ownership of the work product matters too. Confirm that your organization can use the requirements, maps, and evaluation criteria with another provider if you choose. If the assessment only has value when you buy the seller’s implementation, you did not buy an independent decision product.

When you can skip the assessment

Not every project needs a separate paid assessment.

You may be ready to move directly into implementation when the workflow is already documented, the data and integration boundaries are confirmed, the requirements and success measures are approved, the buyer has a credible cost model, and the delivery team has priced the work against that evidence.

A small, reversible configuration change may not justify a formal engagement either. Do the thinking, document the decision, and move.

The assessment earns its place when uncertainty is material. That usually means the workflow crosses teams or systems, sensitive data is involved, the AI can take consequential actions, the implementation estimate depends on unresolved integrations, or leadership expects a business result nobody has defined.

If the main unanswered question is whether the technology performs on representative work, the next step may be a pilot. That is a different deliverable. Use a structured AI proof of concept with a baseline, acceptance criteria, failure criteria, and a hard end date.

Use a simple buyer scorecard

Before signing an assessment, score the proposed engagement from zero to two on each question. Zero means missing. One means partly defined. Two means clear and written.

Buyer test	Score
The business decision is explicit	0-2
The workflow boundary is narrow enough to analyze	0-2
Deliverables are named and reusable	0-2
Data, permissions, and integrations are in scope	0-2
Current-state baseline and success measures are included	0-2
Costs and assumptions will be documented	0-2
Multiple options, including non-AI, will be considered	0-2
The provider can recommend revise or stop	0-2
Implementation is separately scoped	0-2
The buyer owns the decision packet	0-2

A low score does not mean the provider is bad. It means the engagement is not ready to buy.

Buy evidence before confidence

AI implementation is where the expensive work starts. It is a bad place to discover that the workflow has no owner, the data cannot be used, the integration does not support the required action, or the expected savings were never tied to a baseline.

Paying for an assessment can be smart. Paying for vague discovery is not.

Buy a defined decision. Require usable artifacts. Make the provider show its assumptions. Keep implementation separate until the evidence supports it. Then move with more confidence because the team did the work, not because the proposal sounded confident.

Catch Advisors offers a vendor-neutral AI Readiness Assessment for IT leaders who need a practical view of infrastructure, data, integrations, and use-case priorities before committing to a larger AI project. Review the scope, compare it against the scorecard above, and make sure your next AI dollar buys a better decision.