Quick Answer
Before buying an AI product, ask what data enters the system, how it is stored and used, which evaluations reflect your use case, what the system can do without approval, how incidents and model changes are reported, who owns each decision, and how you can export data and leave. Record the answers, assign an internal owner, and pilot one reversible workflow before expanding.
The easiest time to ask about AI risk is before a customer, employee, or regulator asks you.
A polished demo shows the best path. A responsible buying decision needs to understand the operating conditions around that path.
For a smaller business, vendor review should not become a hundred-page enterprise exercise. It should also not be reduced to price, feature list, and a sales call.
The goal is to ask a small set of consequential questions and keep evidence of the answers.
Use NIST as a Risk-Management Map
The US National Institute of Standards and Technology developed the voluntary AI Risk Management Framework to help organisations manage risks associated with AI. The framework groups work under four functions: Govern, Map, Measure, and Manage.
NIST also published a Generative AI Profile that applies the framework to risks specific to generative systems.
A small business does not need to copy the framework word for word. It can use the structure as a map:
- Govern: who owns the rules and decisions?
- Map: where is AI used, for whom, and with what consequence?
- Measure: how will quality, failure, and risk be evaluated?
- Manage: what controls, monitoring, response, and changes are required?
This complements a practical AI governance starter for smaller businesses. Governance becomes useful when it changes how a tool is selected, configured, reviewed, and stopped.
Question 1: What Data Enters the System?
List the data the workflow may send:
- Customer names and contact information
- Messages, calls, or support history
- Employee records
- Financial information
- Contracts and confidential documents
- Product or source code
- Images, voice, or video
- Public marketing content
Ask the vendor which inputs are stored, for how long, where, under which account controls, and whether they are used to improve models or services.
Check access, encryption, deletion, backups, subprocessors, data location, and incident notification. Review the current contract and policy, not a salesperson's memory.
If the workflow does not need sensitive data, do not send it. Data minimisation is often the simplest control.
Question 2: Who Owns the Input and Output?
Understand the terms that apply to customer inputs, generated outputs, feedback, uploaded files, and retained history.
Ask whether the vendor claims rights to use material for training or service improvement. Check whether your plan or account settings change that treatment.
Ownership language alone does not resolve rights risk. Generated output may resemble third-party work, contain invented material, or use inputs your team was not authorised to provide.
Define an internal rule for acceptable inputs and review output before commercial use.
Question 3: Which Evaluations Match Our Use Case?
General benchmark performance does not establish fitness for your workflow.
Ask what the vendor has evaluated and under which conditions. Then build a small test set from your actual task.
For a customer-support assistant, test common questions, unclear questions, sensitive requests, refund or complaint cases, unsupported claims, and escalation. For document extraction, test the file types, languages, layouts, and error cases the business receives.
Measure what matters:
- Factual accuracy
- Completion quality
- Failure detection
- Escalation behaviour
- Latency
- Cost
- Consistency
- Security and privacy conditions
- Human review time
Do not rely on average quality when a small number of failures could cause serious harm.
Question 4: What Can the System Do Without Approval?
Autonomy changes risk.
An assistant that drafts a reply for review is different from a system that sends the reply, changes a customer record, issues a refund, updates a website, or triggers a payment.
Map the actions the tool can take and the permissions it holds. Use the least privilege needed. Require approval for high-consequence actions. Add spending, rate, or scope limits where supported.
Ask how actions are logged and whether the business can reconstruct what happened.
The article on three founder decisions that should stay human provides a useful boundary: AI may assist analysis, but humans should retain accountable decisions around position, people, promises, and meaningful exceptions.
Question 5: How Does the Vendor Handle Security and Incidents?
Ask for current security documentation appropriate to the product and plan.
Review authentication, role-based access, logging, encryption, vulnerability management, subprocessors, availability, backup, incident response, and notification terms.
Ask what happens when the model produces harmful or confidential output, when credentials are compromised, or when an integration performs an unintended action.
The vendor has responsibilities. Your business also has responsibilities for configuration, access, monitoring, employee use, and response.
Do not treat a certification logo as the entire review. Understand the scope, date, product, and controls it actually covers.
Question 6: How Are Model and Product Changes Communicated?
AI products can change behaviour when the model, system instructions, retrieval source, safety controls, interface, price, limit, or integration changes.
Ask:
- How are material changes announced?
- Can the account pin or choose a model version?
- What notice applies to deprecation?
- Will an update change data treatment or availability?
- Can the business test before a migration?
Define internal review triggers. Re-test when the provider, model, data, prompt, integration, audience, purpose, or autonomy changes materially.
A pilot approved six months ago is not automatically approved for a different model and a customer-facing action.
Question 7: What Monitoring and Logs Are Available?
You need enough visibility to detect failure and investigate incidents.
Ask whether logs show inputs, outputs, actions, approvals, errors, model versions, costs, users, and integration calls. Check retention and access controls.
Define a small monitoring view:
- Usage volume
- Cost
- Error and escalation rate
- Review corrections
- Unsupported or policy-sensitive outputs
- Customer complaints
- Failed integrations
- Unusual access
Monitoring should connect to a response owner. A dashboard nobody reviews is not a control.
Question 8: Can We Export Our Data and Leave?
Exit is part of vendor selection.
Ask what can be exported, in which format, how long it takes, what happens to retained data, and how integrations can be disconnected safely.
Identify dependencies such as proprietary prompts, agent configurations, vector stores, workflow histories, generated assets, and user accounts.
The guide to choosing AI vendors in Indian markets offers a broader view of fit, economics, support, and local operating conditions.
Avoid a workflow that cannot be stopped without losing critical business records.
Question 9: Who Is Accountable on Both Sides?
Name a vendor contact for security, data, support, and commercial issues when possible.
Inside the business, name one owner for the use case. That person does not need to perform every review, but should ensure the workflow has current documentation, testing, permissions, monitoring, and incident response.
Shared ownership often means no one notices when the tool changes.
Add the use case to a simple AI register with purpose, owner, data, vendor, risk level, approval, controls, review date, and status.
Use a Risk-Tiered Buying Process
Not every tool needs the same review.
Lower risk
Internal brainstorming using public information, with no autonomous action and full human review.
Medium risk
Internal summarisation or analysis involving business information, or external content that receives structured review.
Higher risk
Personal or confidential data, customer-facing advice, employment, money, contracts, regulated activity, safety, security, or autonomous actions.
Higher risk requires stronger evidence, permissions, approval, monitoring, and response. Some uses may not be acceptable.
The classification should reflect consequence, not excitement about the tool.
Run a Reversible Pilot
Choose one workflow with a baseline and a named owner.
Define:
- Current time, cost, quality, and error level
- Allowed data
- Test cases
- Human review
- Success and stopping criteria
- Pilot duration
- Monitoring
- Final decision date
Keep the first pilot reversible. Avoid immediate access to broad customer data or high-consequence actions.
The Indian SME AI implementation roadmap can help structure the movement from a controlled test to a maintained production workflow.
Red Flags That Deserve a Pause
Pause when:
- Data use cannot be explained clearly.
- Contract answers conflict with sales claims.
- The vendor cannot describe evaluation for the use case.
- Important actions cannot be logged or limited.
- Material product changes have no review path.
- The business cannot export critical records.
- The workflow requires sensitive data before value is proven.
- Accountability remains undefined.
A pause is not a permanent rejection. It is a request for enough clarity to make a responsible decision.
Final Takeaway
Do not buy only the demo. Buy the operating conditions around it.
Ask about data, rights, evaluation, autonomy, security, changes, monitoring, exit, and accountability. Record the answers. Pilot one reversible workflow. Expand only when the evidence and controls match the consequence.
The best time to discover a weak answer is before the tool becomes part of a customer promise.
Frequently Asked Questions
What is the first question to ask an AI vendor?
Ask what data the intended workflow sends, how that data is stored and used, and which contract and account settings govern the answer.
Does a small business need a formal AI vendor review?
Yes, but the depth can match the risk. Use a short documented review for lower-risk tools and stronger evaluation, security, legal, and leadership review for higher-consequence uses.
Are general AI benchmarks enough for vendor selection?
No. Benchmarks provide context, but the business should test its own data types, tasks, languages, edge cases, failure costs, and review effort.
How often should an AI vendor be reviewed?
Review on a schedule and when the vendor, model, data treatment, integration, purpose, audience, permissions, autonomy, price, or risk changes materially.
What should an AI exit plan include?
Include data export, configuration records, integration shutdown, account removal, retained-data treatment, customer continuity, replacement options, and an accountable owner.
