AI vendor due diligence: 15 questions before connecting business data.

An AI tool can look remarkable in a controlled demonstration and still be the wrong place for your customer records, financial data, employee information, or operating authority.

AI vendor due diligence is the work of proving that a product fits a specific business use before it is connected to real systems. The decision is larger than choosing a model or comparing feature lists. Many AI products depend on several layers—a software vendor, one or more model providers, cloud infrastructure, plugins, data sources, and subcontractors. Your business experiences the combined behavior of that chain.

The newest NIST supply-chain due diligence guide describes due diligence as investigating pertinent information about a supplier or product so an organization can make an informed acquisition decision. Its assessment areas include provenance, resilience, foundational cybersecurity practices, and supply-chain tiers. Those ideas translate directly to business AI: know who and what you are trusting, how the system can fail, and how you will retain control.

The following 15 questions create a practical review. They are not a substitute for legal, security, or compliance advice. They are a way for business, operations, technology, and risk leaders to ask the same questions—and require evidence before access expands.

Define the use before comparing vendors.

Due diligence becomes vague when the proposed use is vague. “Help the finance team with AI” is not enough context to judge a product. “Extract invoice fields, match them to approved purchase orders, and route exceptions to an authorized reviewer” is testable. It identifies information, actions, users, and failure conditions.

1. What exact task will the system perform? Document the trigger, inputs, expected output, connected applications, users, and final owner. Separate drafting, recommending, and acting; they carry different levels of risk.
2. What happens when it is wrong or unavailable? Consider incorrect answers, missed records, duplicated actions, service outages, slow responses, and unavailable integrations. The business impact determines how much evidence and control you need.
3. What authority will it receive? Reading approved documents is different from changing prices, sending customer messages, creating payments, or deleting records. Define a risk tier and the maximum action allowed before anyone discusses a broad rollout.

A low-risk pilot may create internal drafts from non-sensitive information. A higher-risk workflow may touch financial records or take external action. The second use should require stronger identity controls, evaluations, approvals, monitoring, and recovery procedures. The vendor should explain how its product supports that distinction.

Ask what happens to your data.

Data terms can differ by product, subscription, configuration, region, and feature. Do not assume that an enterprise plan, a familiar logo, or a “private” label answers every question. The Australian Cyber Security Centre’s current AI guidance for small businesses specifically recommends reviewing vendor configuration, terms, privacy policies, access, use, storage, and data-handling practices.

4. What information does the product collect? Include prompts, uploads, retrieved records, user feedback, metadata, logs, generated output, and data pulled through integrations. Ask whether optional features collect anything additional.
5. Can submitted data be used to train or improve models? Get the answer for the exact plan and settings you will use. Confirm whether the rule covers prompts, attachments, feedback, and data sent to subprocessors—not just the vendor’s own model.
6. Where is information stored, and for how long? Ask about active storage, backups, logs, temporary processing, deletion timing, regional options, and what remains after an account closes. “We do not retain prompts” should come with a precise scope.
7. Who else can receive or process the data? Request the current subprocessor list and the purpose of each material provider. Understand whether support personnel can access content, how that access is approved, and whether the vendor will notify you when the list changes.

Then compare the answers with your own information classes. Public marketing copy, internal procedures, customer contact data, payment information, and employee records should not automatically receive the same treatment. If the vendor cannot express controls at the level your business requires, the product may be suitable only for a narrower use.

Map the model and supplier chain.

AI software rarely operates alone. A customer-facing application may call a third-party model, retrieve documents from another platform, send telemetry to an analytics provider, and rely on open-source components. This does not make the product unsafe. It does mean the buyer needs an understandable map of important dependencies.

8. Which models, platforms, and critical components are involved? Ask the vendor to identify material model providers, hosting providers, integration services, and external data sources. For self-hosted or open-source components, ask how source and integrity are verified.
9. How are versions and upstream changes managed? A model update can change quality, cost, latency, or behavior without altering the visible interface. Ask how changes are tested, documented, announced, and rolled back—and how long deprecated versions remain supported.

The OWASP guidance on AI supply-chain risk recommends vetting suppliers and data sources, reviewing terms and privacy policies, maintaining current component inventories, using verifiable sources, and monitoring for change. A small business may not need an exhaustive technical bill of materials for every low-risk tool, but it should know the critical parties that can affect its data and operations.

Provenance matters for purchased content and generated output too. If a vendor promises answers grounded in your files, ask whether the response can identify the source document and version. If a system recommends an action, ask whether your team can reconstruct which records, rules, model version, and human approval produced it.

Test permissions, reliability, and human control.

Security questionnaires often produce a list of certifications while leaving the business workflow unexplained. Certifications may be useful evidence, but the product still needs to enforce the way your people work. Test the actual user roles, connected accounts, output limits, and approval paths you plan to deploy.

10. How are identity and least privilege enforced? Look for business accounts, multifactor authentication, role-based access, separate service identities, scoped integration permissions, and prompt removal of access when a person changes roles or leaves.
11. What evidence shows the system is fit for this use? Ask for evaluation methods, representative test cases, known limitations, failure rates, and the conditions under which performance declines. A general benchmark is not proof that the product understands your documents or business rules.
12. Where can people approve, correct, pause, or reverse an action? Consequential work should have visible human responsibility. Ask whether approvals bind to an exact version, whether edits invalidate prior approval, and whether completed actions can be rolled back safely.

The NIST AI Risk Management Framework Core emphasizes defining intended use, knowledge limits, human oversight, third-party risk, evaluation, and monitoring. In practical terms, your vendor should be able to show where the AI stops, where business rules take over, and where an accountable person makes the decision.

Run your own acceptance tests. Include ordinary cases, incomplete records, conflicting sources, adversarial inputs, unauthorized users, unavailable integrations, and requests outside scope. Record both correct output and safe failure. A vendor that welcomes realistic testing is more useful than one that only repeats benchmark claims.

Plan for incidents, updates, and a clean exit.

A good agreement anticipates the day something changes. The vendor may have an outage, replace a model, alter a feature, experience a security incident, increase pricing, or discontinue the product. Your business should know how it will continue operating before the system becomes difficult to remove.

13. What will be logged, and how are incidents handled? Confirm which user, model, tool, data source, approval, and destination events are recorded. Ask about notification timing, investigation ownership, customer support, evidence preservation, and post-incident reporting.
14. What is the continuity and recovery plan? Identify manual fallback, data backups, service commitments, restore objectives, pause controls, and the process for reconnecting systems safely. The answer should match the operational importance of the use.
15. Can the business leave with its data and workflow knowledge? Ask about machine-readable exports, configuration and prompt ownership, documentation, API access, deletion confirmation, transition support, and any features that make replacement unusually difficult.

Portability is not an argument against a long-term vendor relationship. It is evidence that the relationship is healthy. Your customer and operational data should remain usable, your business logic should be documented, and your team should understand how work continues without one provider.

Score evidence—not promises.

Turn the answers into a written decision instead of relying on overall impressions. Start with blockers: unacceptable data use, missing access controls, no audit trail for a high-impact action, or no workable exit. A product that fails a blocker should not compensate with more features.

Next, score required controls. These may include source citations, specific user roles, approval gates, export formats, incident notification, service reliability, or model-change notice. Record the evidence you reviewed and the person responsible for the decision. Finally, compare useful capabilities, implementation effort, total cost, and expected business value.

Use a limited pilot to verify the highest-risk assumptions. Connect the minimum data, grant the minimum authority, and test defined success and failure cases. Review logs, corrections, false positives, user behavior, support quality, and actual workflow impact. Expand only after the evidence supports it.

Awayvo treats vendor selection as one layer of a complete operating design. The surrounding integration architecture still needs scoped access, reliable records, approval rules, monitoring, and recovery. For businesses comparing a point solution with a custom buildout, the Awayvo AI Assessment maps the workflow, information, risks, and authority before technology choices become commitments.

The purpose of AI vendor due diligence is not to remove every uncertainty. It is to make uncertainty visible, match controls to real business impact, and prevent an impressive demo from receiving more trust than the evidence supports.