AI is one of the easiest technology categories to sell badly.
A polished demo can hide weak architecture. A chatbot can be labeled an "AI employee." A few API calls can be presented as proprietary infrastructure. A prototype can be priced like a production system. A vendor can promise automation without explaining permissions, failure handling, integrations, or who owns the system after launch.
Technical buyers do not need to become machine-learning researchers to avoid this.
They need to ask better production questions.
The goal of vendor evaluation is not to find the company with the most AI vocabulary. It is to find the team that can explain how your workflow becomes reliable software.
Start by asking what problem they think you have
Before discussing models, ask the vendor to describe the operational problem back to you.
A strong answer should mention:
- the current workflow
- the people involved
- source systems
- repetitive steps
- decisions
- exceptions
- approval points
- expected business outcome
A weak answer jumps directly to "we will build you an AI agent."
If the vendor cannot explain the process that exists today, it is unlikely to automate the process well.
Ask for the workflow before the architecture diagram
Architecture matters, but architecture should follow the work.
Ask:
"Walk me through exactly what happens from the moment this task enters the system until it is complete."
For example, if the project is support automation, the answer should describe how the system:
1. receives the request 2. identifies the customer 3. retrieves account information 4. finds approved knowledge 5. decides whether it can answer 6. drafts or sends a response 7. updates the ticket 8. escalates exceptions 9. records the outcome
That conversation reveals more than a diagram full of AI logos.
Ask what is deterministic and what is probabilistic
This is one of the best questions you can ask.
A serious vendor should be able to tell you which parts depend on model judgment and which parts are enforced in software.
For example:
Probabilistic
- interpret user intent
- classify text
- summarize documents
- draft a response
- choose among constrained tools
Deterministic
- authenticate the user
- enforce permissions
- validate an account ID
- apply a refund limit
- store workflow state
- enforce an approval requirement
- prevent duplicate execution
Be cautious if business rules exist only in prompts.
"The prompt tells the agent not to do that" is not a strong control for an important action.
Ask what happens when the AI is uncertain
Many demos are designed so the AI always has an answer.
Real data does not work that way.
Ask the vendor what happens when:
- the answer is not in the knowledge base
- two sources conflict
- the requested record does not exist
- the user lacks permission
- a tool fails
- the model returns invalid output
- a required field is missing
A mature system has explicit abstention and escalation behavior.
A weak system relies on the model to "try its best."
Ask how they prevent cross-customer or cross-department leakage
If the system touches sensitive business data, ask how access is enforced.
Do not accept "we use secure prompts" or "the model is enterprise grade" as the answer.
You want to hear about actual identity and authorization boundaries:
- tenant filters
- document permissions
- application roles
- row-level access
- source-system ACLs
- least-privilege tool permissions
Ask whether unauthorized data is filtered before it reaches the model context.
That distinction matters.
Our Secure and Private AI page describes the kinds of controls technical buyers should expect.
Ask how retrieval works
If the project includes a knowledge base, ask the vendor to explain retrieval without using the words "RAG" or "vector database" for the first five minutes.
Ask:
- How do you identify the correct source?
- How do you handle exact IDs?
- How do you handle document versions?
- How do you handle stale records?
- How do you handle permissions?
- How do you handle structured databases?
- When do you use semantic search?
- How are citations produced?
If every answer is "embeddings," the architecture may be too simplistic.
Production retrieval often combines deterministic, lexical, structured, and semantic methods.
See Deterministic Retrieval for why this matters.
Ask to see failure cases, not only demos
A strong vendor should be comfortable discussing where the system fails.
Ask them to show or describe:
- a query the knowledge system should refuse
- an agent action that requires approval
- a tool failure
- a retrieval miss
- an ambiguous request
- a bad model output caught by validation
If the vendor claims the system does not hallucinate, ask how that statement is measured.
Reliable engineering is about controlled failure, not magical absence of failure.
Ask how quality is evaluated
"We test it" is not enough.
Ask what the evaluation set contains.
For a RAG system, good evaluation may include:
- retrieval correctness
- citation correctness
- groundedness
- completeness
- missing-answer behavior
- permission-sensitive questions
For an agent, it may include:
- tool selection
- tool arguments
- task completion
- approval behavior
- retry behavior
- final business outcome
Ask whether evaluations run when prompts, models, or retrieval configurations change.
This tells you whether the vendor has a production quality process or a demo-tuning process.
Ask how they debug one bad result
Give the vendor a scenario:
"A user says the agent gave the wrong answer yesterday. How do you investigate it?"
A serious answer should mention traces, source retrieval, model and prompt version, tool calls, permissions, and data state.
If the answer is "we will adjust the prompt," that is too shallow.
The team needs to determine why the failure occurred before choosing a fix.
Ask where your data goes
Get a concrete data-flow answer.
Ask which services receive:
- uploaded documents
- extracted text
- embeddings
- prompts
- audio
- customer records
- logs
- traces
- evaluation data
Then ask how long each service retains the data and which deployment options exist.
Do not review only the language-model provider.
Parsing, transcription, analytics, vector storage, and observability services may handle sensitive data too.
For sensitive projects, ask whether the vendor can support private network or on-prem patterns where required.
Ask what you will own
Ownership should be clear before development starts.
Ask:
- Who owns the application code?
- Who owns custom prompts and workflow definitions?
- Who owns the data and indexes?
- Which infrastructure accounts are in your name?
- Can you export your data?
- Can another engineering team operate the system?
- What proprietary vendor components are required?
- What happens if the relationship ends?
There is nothing inherently wrong with a managed platform. The dependency should simply be explicit.
A custom-development engagement and a managed SaaS subscription have different ownership models.
Know which one you are buying.
Ask what is actually proprietary
AI sales material uses the word "proprietary" loosely.
Ask the vendor to separate:
- third-party models
- open-source libraries
- standard infrastructure
- custom application code
- proprietary platform components
- customer-specific data and configurations
This is not a gotcha question.
A vendor does not need to train its own foundation model to create value. In many projects, the valuable work is integration, workflow design, data architecture, evaluation, and reliable application engineering.
The problem is pretending commodity components are unique intellectual property to justify a vague premium.
Ask about model portability
You do not need perfect provider independence.
You do need to know how tightly the system is coupled.
Ask:
- Can the model be changed?
- What breaks if it changes?
- Are model-specific behaviors covered by tests?
- Is business logic stored outside prompts?
- Are retrieval and permissions independent of the model?
A good vendor should acknowledge that models behave differently and explain how a migration would be evaluated.
Ask about production operations
Who responds when something fails at 10 a.m. on a Monday after launch?
Ask about:
- monitoring
- alerts
- failed job queues
- retry handling
- model outages
- provider rate limits
- connector failures
- backup and restore
- security updates
- dependency upgrades
- incident response
Many AI agencies are optimized to deliver a prototype and move on.
If the system will become operationally important, support and ownership need to be part of the scope.
Ask how they price uncertainty
AI projects contain discovery risk.
A vendor may not know the exact quality of your documents, APIs, or workflow until it inspects them.
That is normal.
Be cautious of two extremes:
Fake certainty
A fixed price for a large production system before anyone has inspected the data or integrations.
Infinite discovery
A vague consulting engagement with no defined deliverables or path to production.
A practical model is often staged:
1. discovery and architecture 2. focused prototype or technical validation 3. production implementation 4. operational hardening 5. ongoing improvement if needed
Each stage should have clear outputs and a decision point.
This is close to our Delivery Process.
Ask for business metrics, not AI metrics
Model accuracy matters. It is not the final metric.
Ask how the vendor expects the project to affect operations.
Examples include:
- response time
- manual minutes per case
- ticket backlog
- lead follow-up time
- document review time
- extraction correction rate
- percentage of work completed without re-entry
- escalation rate
- cost per completed workflow
If the only success metric is "the model is 94 percent accurate," ask what that means for the business process.
Watch for common red flags
Be cautious when you hear:
- "This agent can automate anything."
- "Hallucinations are solved."
- "We do not need your subject-matter experts."
- "We can connect to every system in a few days."
- "Security is handled by the model provider."
- "The prompt makes sure it never does that."
- "You do not need evals; the model is very strong."
- "Everything is proprietary."
- "We will figure out ownership later."
None of these statements automatically proves a vendor is bad. They should trigger more questions.
Positive signals are less flashy
Good production teams tend to talk about boring things.
They ask about:
- APIs
- permissions
- document versions
- approval rules
- failure cases
- source systems
- data retention
- test sets
- observability
- support ownership
They are willing to say that a deterministic workflow is better than an agent for part of the problem.
They are willing to say that an AI feature should not be built if the economics do not work.
They can explain what the model does and what normal software does.
Those are strong signals.
A 15-question vendor checklist
Before signing, get clear answers to these questions:
1. What exact workflow are we automating? 2. What systems will the AI read from and write to? 3. What data is sent to model or AI-service providers? 4. How are user and tenant permissions enforced? 5. Which parts are deterministic versus model-driven? 6. What happens when evidence is missing or conflicting? 7. Which actions require human approval? 8. How is quality evaluated before launch? 9. How are regressions detected after model or prompt changes? 10. How do you debug one incorrect result? 11. How are retries and duplicate actions prevented? 12. What do we own at the end of the engagement? 13. Which vendor-specific components are required to operate the system? 14. Who maintains and monitors the system after launch? 15. What business metric will prove the system is worth keeping?
A vendor that can answer these clearly is giving you something more valuable than a flashy demo: an operating model.
Buy a production path, not an AI story
The best AI vendor is not necessarily the team using the newest model or the most complicated agent framework.
It is the team that can take your real workflow, connect it to real data, define the boundaries, measure the result, and leave you with a system that is understandable and supportable.
That is what technical due diligence should uncover.
If you are evaluating a significant AI build before committing budget, our AI Architecture Review can also be used to pressure-test architecture, vendor proposals, integrations, and rollout assumptions.
Next step: Talk to an engineer about applying this to your stack.