Small Business AI Vendor Evaluation Checklist

Choosing an AI vendor is a business-risk decision, not a feature comparison. Before a contract is signed or sensitive information is shared, a small business should be able to explain the intended use, the vendor’s role, the data boundary, who remains accountable, how performance will be tested, and how the relationship can end. This checklist keeps that work in the pre-contract phase.

1. Define the business need before reviewing vendors

The U.S. Small Business Administration recommends starting small, testing whether an AI tool adds value, and considering both benefits and risks. [5] Write a short use-case brief before watching demos so the vendor is evaluated against your work rather than its broadest claims.

• Problem: what recurring business problem should the product help address?
• Users: which employees, contractors, or customers would interact with it?
• Allowed task: what may the product draft, classify, retrieve, summarize, recommend, or automate?
• Excluded task: which decisions, commitments, records, or actions remain outside scope?
• Baseline: how is the work handled today, and what quality, time, cost, or risk measure will be compared?
• Decision owner: who can approve, reject, narrow, or stop the purchase?

A vendor should be able to respond to the bounded use case. If the proposed solution depends on expanding scope before it can be evaluated, return to the problem definition.

2. Screen for organizational fit

NIST describes its AI Risk Management Framework as a voluntary resource for incorporating trustworthiness considerations into the design, development, use, and evaluation of AI systems. [1] Its Govern, Map, Measure, and Manage functions are useful due-diligence prompts, but using them does not establish certification or compliance.

3. Map every data flow before sharing data

Ask for a diagram or written explanation showing what data enters the service, where it goes, which subprocessors receive it, how long it remains, and what leaves. The FTC advises businesses to take stock of personal information, keep only what is needed, protect what is retained, dispose of it properly, and plan ahead for incidents. [4]

• List proposed input types, including prompts, files, customer records, employee information, logs, feedback, and connected-system data.
• Classify confidential, personal, regulated, contractual, financial, health, employment, credential, and security-sensitive information.
• Ask where data is stored and processed, including backups and support systems.
• Identify every subprocessor or model provider that may receive content or metadata.
• Confirm retention periods, deletion methods, backup deletion timing, and export options.
• Determine whether prompts, files, outputs, feedback, or usage metadata may be used to train, tune, evaluate, or improve any model or service.
• Ask what administrators, vendor personnel, and third parties can access and how that access is controlled and logged.

The FTC has warned AI companies to uphold privacy and confidentiality commitments, including statements made in terms, privacy policies, promotional materials, and marketplaces. [3] Compare the sales explanation, contract, data-processing terms, privacy notice, and technical documentation; record and resolve contradictions before signing.

4. Request security evidence that matches the use case

Do not treat a badge, questionnaire answer, or generic security page as complete evidence. Request current documentation appropriate to the information and access involved, then have a qualified reviewer assess it.

• Authentication options, role-based access, administrator controls, multifactor authentication, and account-recovery procedures
• Encryption for data in transit and at rest, including how keys are managed
• Logging, audit trails, log retention, customer access to logs, and alerting options
• Secure development, vulnerability handling, dependency management, penetration testing, and remediation practices
• Tenant separation and protections against cross-customer disclosure
• Incident notification terms, response contacts, cooperation duties, and evidence preservation
• Business continuity, backups, recovery objectives, and service-dependency risks
• Documented deletion and return of data at contract end

The right depth depends on the use case. A public drafting aid with no accounts or confidential data should not be assessed as if it controls a production database, while a deeply connected service warrants stronger evidence.

5. Evaluate model behavior and limits with evidence

The NIST AI RMF Playbook offers voluntary suggested actions aligned to Govern, Map, Measure, and Manage and explicitly says it is not a checklist that must be followed in its entirety. [2] Select questions that fit the proposed use and ask the vendor to show how it measures relevant limitations.

• Which model or models are used, and can they change without notice?
• What known limitations, unsuitable uses, and failure patterns are documented?
• How does the product handle missing, conflicting, malicious, or out-of-scope input?
• Can responses cite or expose the source material used?
• What controls constrain tools, connected systems, data retrieval, and external actions?
• How are safety rules, system instructions, prompts, and configurations versioned?
• What customer-visible evidence is available for material changes and regressions?
• Can a customer require human approval before external communication or consequential action?

6. Run a bounded pre-contract evaluation

Use synthetic, public, or properly approved sample data unless written terms and controls already authorize other data. Define expected results before the test.

• Score accuracy or task quality using a documented rubric rather than a polished demo.
• Record unacceptable outputs, not only average performance.
• Measure reviewer effort and exception handling.
• Verify role permissions and data segregation with separate test accounts where appropriate.
• Confirm the product fails safely when a source, integration, or model is unavailable.
• Preserve the test set and results so a later product change can be compared.

7. Review oversight and accountability

• Name your business owner, technical owner, data owner, review owner, and contract owner.
• Ask who at the vendor owns security, privacy, model risk, support, and incident coordination.
• Define which outputs require human review and what information the reviewer receives.
• Require a usable escalation route for incorrect, unsafe, confidential, or suspicious behavior.
• Clarify whether the vendor can suspend features, accounts, integrations, or models and how customers are notified.
• Confirm your business remains able to pause use without waiting for vendor action.

8. Read the contract as an operating control

Commercial and legal review should reconcile the order form, master agreement, data-processing terms, privacy and security exhibits, service levels, acceptable-use terms, and referenced online policies. This checklist cannot determine what terms are legally sufficient.

• Authorized use, users, data categories, integrations, and prohibited uses
• Data ownership, output rights, confidentiality, and training or product-improvement use
• Subprocessor notice and objection processes
• Security obligations, incident notice, cooperation, and responsibility allocation
• Service availability, support scope, change notices, and remedies
• Price basis, usage limits, renewal, suspension, termination, and material policy changes
• Data export format, assistance, deletion, transition time, and post-termination access
• Audit, assessment, evidence, insurance, indemnity, liability, and governing terms as reviewed by counsel

Do not rely on a sales assurance that is absent from the controlling documents. The FTC’s discussion of privacy commitments is a reason to make representations specific and consistent, not a substitute for legal review. [3]

9. Plan the exit before approving the purchase

• Export representative records and configurations during the evaluation.
• Document which prompts, templates, knowledge files, workflows, logs, and outputs your business can retrieve.
• Identify proprietary formats, connected automations, and vendor-specific features that create migration work.
• Estimate the time and responsible owner for removing access, rotating credentials, disconnecting integrations, and restoring a manual process.
• Require written deletion confirmation where appropriate and understand backup-retention limits.
• Preserve a practical fallback if the vendor changes terms, price, model, ownership, availability, or product direction.

10. Make a documented selection decision

Proceed to contracting only when the use case is bounded, claims have supporting evidence, data flows are understood, security review matches risk, the evaluation meets predefined criteria, responsibilities are explicit, terms are reviewable, and an exit path is workable.

Revise or pilot more narrowly when the potential fit is real but data, controls, evidence, testing, or terms are incomplete.

Do not select when critical data use is undisclosed, representations conflict, the vendor will not support reasonable testing, required oversight is unavailable, or the business cannot exit without unacceptable disruption.

Vendor evidence record

• Use-case brief and excluded uses
• Data-flow and subprocessor record
• Security and privacy evidence reviewed, with dates and owners
• Model documentation, known limits, and change policy
• Evaluation cases, rubric, results, and unresolved findings
• Human-review and escalation design
• Contract-document list and approved exceptions
• Export, deletion, termination, and fallback plan
• Decision, approvers, conditions, and review date

Sources

1. [1] NIST: AI Risk Management Framework
2. [2] NIST AI RMF Playbook
3. [3] FTC: AI Companies—Uphold Your Privacy and Confidentiality Commitments
4. [4] FTC: Protecting Personal Information—A Guide for Business
5. [5] U.S. Small Business Administration: AI for small business