The short answer
An AI implementation partner should translate one bounded operating problem into a controlled system that people can use, inspect and own. That requires more than selecting a model or presenting a polished demonstration. The partner should connect process design, reliable context, permissions, testing, change control, training and recovery to an outcome the business can observe.
Define the operating outcome before partner selection
Choose one process and document its trigger, current steps, responsible roles, information sources, common exceptions and intended finish. State how an improvement would be observed without promising a result in advance. This brief makes proposals comparable and prevents a technology catalogue from replacing the operating question.
Assess the capability behind the proposal
Ask who owns process architecture, data preparation, integrations, access controls, the AI boundary, security decisions, testing, adoption and ongoing administration. A credible team should explain how these disciplines fit together and where specialist or client decisions are required. Platform experience does not imply endorsement or a formal partnership, and a list of product logos does not establish that the proposed workflow, fields, limits or recovery behaviour are supported.
Require a bounded demonstration
Use sanitised but representative examples that cover an ordinary case, a duplicate, incomplete information and an unavailable connected system. Record what the demonstration proves and what it does not. A successful demo can show a design direction; it is not evidence that production permissions, data quality, scale, recovery or team adoption are ready.
Inspect the AI boundary
Confirm which approved sources provide context, whose permissions apply, how uncertain output is handled, where human approval is required and what is logged after an action. Material or sensitive decisions should remain with an accountable person. Exception handling should state what happens when context is missing, a model response is unusable or an external write has an uncertain outcome.
Separate implementation and running costs
Compare discovery, design, configuration, integration, testing, training, handover and stabilisation as explicit implementation items. Keep software licences, providers, messaging, storage and usage charges visible as recurring costs. Confirm who owns administrative access, usage controls, support, change requests and the option to move or recover the system later.
Ask for delivery evidence
Useful delivery evidence can include the current-process map, target design, data and permission decisions, test records, exception handling, training material, administrative handover, rollback criteria and a stabilisation record. Generated output on its own is not acceptance evidence. Acceptance criteria should let the business trace a requirement to a tested behaviour and a named owner.
Use one comparison brief
Give each prospective partner the same operating brief and ask the same questions about scope, assumptions, exclusions, access, testing, review, recovery, handover, recurring services and change control. Mark unanswered items rather than filling the gaps by inference. The stronger proposal is the one whose boundaries and evidence fit the operation—not necessarily the one with the longest tool list.