Choosing an AI provider requires looking beyond the demo. The decision-maker must verify which problem will be taken on, what data and permissions enter the flow, how actions are recorded, where a person intervenes, and how the operation continues in failures or changes. The best proposal is the one that transforms capability into verifiable responsibility.
The demo measures the best minute of a solution. The contract needs to protect all the others: the day an exception arrives, data is incomplete, integration changes, the response seems convincing but is wrong, the provider updates the system, or the company decides to terminate the contract.
It is in this difference that a good AI purchase separates from a presentation purchase. Smooth videos, quick responses, and a sleek interface help understand the proposal but do not show who takes on the work when the scenario goes off script. For a decision-maker, the central question is not only “what can this AI do?”. It is “what operation will we have after it starts doing it?”.
At XMACNA, we evaluate AI by its ability to execute within a process with owner, limit, recording, and human handoff. The experience of more than +600 Digital Employees in operation shows that value does not arise from an isolated response. It comes from continuity between understanding input, acting with permission, recording what happened, recognizing an exception, and delivering context to the right person.
Therefore, choosing an AI provider is an operational decision. Technology matters. But technology without clear responsibility merely transfers uncertainty inside the buying company.
What problem will the AI provider truly take on?
Start with the work, not the tool. “Using AI in service” is too broad to guide a purchase. “Receiving requests via WhatsApp, identifying intent, consulting authorized information, recording the next step, and forwarding exceptions to the responsible person” already allows discussion of scope, risk, and outcome.
A well-defined problem needs to show input, expected action, result, exceptions, and final responsible. Without this, different providers seem equivalent because each showcases the scenario most favorable to their solution. The comparison becomes cosmetic.
Before requesting a proposal, describe three situations:
- the normal case that should proceed smoothly;
- the incomplete case requiring a question or validation;
- the sensitive case that needs to stop and go to a person.
This description also helps decide between buying or building AI for service. The company stops comparing feature lists and starts comparing who can assume an outcome with explicit limits.
What evidence proves the solution works in your context?
A commercial promise is not operational evidence. Ask the vendor to demonstrate the workflow with representative samples, including bad inputs, ambiguities, and context changes. The test needs to include what usually breaks the process, not just the happy path.
Also differentiate four layers of proof:
- capacity: the solution can perform the task under controlled conditions;
- quality: the result meets the criteria defined by the company;
- continuity: the flow preserves context, record, and next step over time;
- control: errors, changes, and exceptions are detectable and have an accountable party.
A solution can be impressive at the first layer and fragile in the others. Therefore, the pilot must use acceptance criteria defined before the test. If the standard changes after each demonstration, the vendor is being evaluated by narrative, not by work.
What data and permissions enter the operation?
Every vendor should be able to clearly outline, in understandable language, what data they receive, why they need it, where they use it, how long they keep it, who can access it, and what happens when the contract ends. The same clarity applies to permissions: consulting is different from changing; suggesting is different from sending; preparing is different from approving.
The principle is minimal access for the defined task. If the case requires calendar consultation, there is no automatic reason to grant broad access to the entire commercial history. If the flow only prepares an action, the permission to execute it requires a separate justification.
Good process automation makes every boundary explicit. The vendor should not ask for generic trust. They must show the operation map and allow the company to restrict, revoke, and review access without dismantling the entire service.
How does the AI record what it did and explain an exception?
When a person works, the company expects history, accountability, and the possibility of review. With AI, the requirement can be no less. Each relevant action must leave a record that allows reconstructing what was input, what rule or context was used, what was executed, what the result was, and who took over continuity.
This does not mean exposing incomprehensible technical details. It means producing useful evidence for operation, quality, and auditing. A manager needs to know why a case advanced. A support team needs to understand why another was escalated. A risk officer needs to be able to locate changes and incidents.
Also ask how the vendor handles updates. If behavior can change, who communicates it, who validates it, and how does the company compare before and after? A silent change in a system that performs work is a silent change in the company’s process.
Where does the person take over and with what context?
"There is a human in the loop" is an insufficient phrase. The operational contract must specify when the person steps in, who that person is, what information they receive, what decision they can make, and how the case returns to the flow.
Triggers can include low confidence, data conflict, out-of-policy request, financial impact, sensitive data, unhappy customer, or unauthorized action. The point is not to create a universal list. It's to prevent AI from continuing to improvise when it should stop.
A good handoff package contains a summary, current state, actions already taken, available evidence, reason for escalation, and suggested next step. Without this, automation just transfers the queue and forces the person to reconstruct the conversation.
This is the divide between a resource that responds and a Digital Employee that executes responsibly. It’s not a chatbot. It is work designed to continue even when the exception requires human judgment.
What happens when the solution fails?
Every serious contract needs to address downtime, errors, and incidents before going live. Ask how the operation detects failures, who is notified, what support exists, how the service recovers, and what alternative path preserves service meanwhile.
The continuity plan does not need to promise no failures. It needs to prevent a failure from becoming silence. For critical processes, there may be fallback to a manual step, temporary scope reduction, action blocking, or routing to a human queue. The design depends on the impact but must exist and be testable.
It is also important to separate technical availability from business continuity. A system can be online and still produce inadequate responses, lose records, or fail to forward cases. Monitoring only if the page opens does not protect the operation.
Does the contract follow the operation or just the license?
The contract must reflect what was discovered in the evaluation. Scope, data, permissions, responsibilities, quality criteria, support, change communication, incidents, asset ownership, continuity, and termination cannot remain only in presentations or commercial conversations.
Certifications and policies help but do not replace evidence applied to the case. A security document alone does not answer how a commercial exception will be handled. A generic availability clause does not define what happens when the integration works but the flow stops recording the next step.
Business, technology, security, legal, and operations areas need to look at the same design. This reduces the risk of each approving a different part and no one approving the entire operation. Legal and regulatory requirements vary by sector, data, and use; specialized review remains necessary.
How to avoid dependence on the AI vendor?
Dependency does not arise only from technology. It arises when the company loses its own data, rules, history, quality criteria, and ability to operate without the vendor. Therefore, the exit plan must be discussed before deployment.
Ask what can be exported, in what format, how long it takes, how accesses are revoked, how data is eliminated according to applicable obligations, and who supports the transition. Also verify which parts of the process belong to the company and which exist only inside the contracted service.
The goal is not to switch vendors at any time without cost. It is to maintain enough reversibility so a future decision does not become impossible. The company must remain the owner of the process, even when contracting technological execution.
How to turn the pilot into a purchase decision?
A good pilot is not an extended free sample. It is a controlled rehearsal of the operation. It must have scope, responsible parties, entry criteria, test cases, permission limits, a way to measure, interruption triggers, and a final decision.
Use sanitized real situations or data suitable for the test, include exceptions, and observe the human work created around the solution. If AI reduces one queue but requires another team to fix, verify, or feed the process, that cost must appear.
The AI ROI calculator can help organize the economic decision, but the return should not be isolated from operational risk. A cheap solution that requires permanent supervision, hides failures, or blocks exit may cost more than the proposal shows.
In the end, the decision does not have to be just approve or reject. It can be approve with limited scope, require corrections, repeat tests, or condition expansion on specific evidence. The important thing is to record why the company decided and which conditions need to remain true.
Which signals should block the contract?
Some signals do not prove that a vendor is unsuitable for all use but prevent responsible contracting at this moment:
- cannot explain data flow and permissions;
- avoids testing exceptions or imperfect inputs;
- does not offer useful records of actions taken;
- treats human handoff as a promise without trigger and context;
- does not specify how relevant changes are communicated;
- does not present continuity for failures and incidents;
- keeps ownership, export, or termination unclear;
- pushes for production before acceptance criteria are met.
The best vendor is not the one who says “yes” to everything. It is the one who recognizes limits, shows evidence, and helps design an operation the company can govern.
In summary
- Choosing an AI vendor starts with work and exceptions, not demonstrations.
- Capacity must come along with quality, continuity, and control.
- Data, permissions, logging, human handoff, and changes must be verifiable.
- Contract, pilot, and operation must tell the same story.
- The company must preserve ownership over process, evidence, and exit plan.
Before contracting another tool, find out which process is ready to receive AI execution and what controls are still missing. Do the XMACNA Assessment and identify where to start.
Frequently asked questions
How to choose an AI vendor for a company?
First define the problem, results, and exceptions. Then evaluate evidence in your context, data flow, permissions, action logging, human handoff, continuity, contractual responsibilities, and exit plan. The demonstration is only part of the evaluation.
What questions to ask an AI vendor?
Ask what work the solution assumes, what data it accesses, what actions it can execute, how it logs decisions, when it interrupts the flow, how it communicates changes, how it responds to incidents, and how it returns data and accesses upon termination.
Is a pilot sufficient to approve an AI solution?
Only when the pilot reproduces normal cases and exceptions, uses criteria defined before the test, and also measures the human work created. A pilot done only with the happy path validates the presentation, not the operation.
Do certifications guarantee the AI vendor is safe?
Certifications can provide important evidence about controls, but they do not guarantee suitability for the entire process. The company still needs to assess scope, data, permissions, integrations, behavior, continuity, and specific requirements of its context.
How to avoid being locked into an AI vendor?
Preserve ownership of data, rules, history, and quality criteria. Define export, access revocation, data deletion, transition support, and termination responsibilities before signing. Reversibility is part of the contracting architecture.