Before signing, ask an AI vendor to answer in writing where data is processed and stored, whether that data trains any shared or third-party model, what happens to the system and the data if the contract ends, what service level covers uptime and support after go-live, and who owns the resulting code and any fine-tuned models. Ask for at least two references from projects of comparable scope and industry, and actually call them rather than accepting a written case study at face value. Ask how the vendor handles underlying model or API deprecation, since providers change pricing and capability frequently, and get a clear, written answer on exit costs in case a switch becomes necessary later. Confirm whether pricing is fixed, time and materials, or usage-based, and request worst-case cost scenarios in writing, not only the best-case projection used in the pitch. Ask what certifications the vendor holds, such as SOC 2 or ISO 27001, and request the actual audit report rather than a badge displayed on a marketing page. Finally, clarify in writing who is accountable when the system produces a wrong or harmful output once it reaches production. Nanobase AI answers each of these in a written scope document before any contract is signed, since vague answers here tend to predict problems later.
Why the written answer matters more than the verbal one
A sales conversation can produce a confident, reassuring answer to almost any question. What separates genuine due diligence from a pleasant call is getting each answer in writing, in the contract or an accompanying document, before signing, since a vendor's willingness to commit an answer to paper is itself informative. A vague verbal answer that becomes specific and favorable once put in writing is a good sign; one that becomes vaguer in writing is a warning worth taking seriously.
Any question on this list that a vendor cannot or will not answer in writing before signing should be treated as unresolved, not assumed to be fine.
The core due-diligence questions
| Category | Question to ask | Why it matters |
|---|---|---|
| Data handling | Where is data processed and stored, and does it train any shared or third-party model? | Determines exposure if the vendor's infrastructure is compromised or data leaks into a shared model |
| Ownership | Who owns the resulting code, prompts and any fine-tuned models? | Prevents a costly dependency if the relationship ends |
| Exit terms | What happens to the system and data if the contract ends? | Avoids losing access to a business-critical system with no transition plan |
| Support | What SLA covers uptime and support after go-live? | Distinguishes a vendor built for ongoing operation from one built only to deliver a launch |
| Model changes | How is underlying model or API deprecation handled? | Protects against sudden breakage when a provider retires or changes a model |
| Pricing | Is pricing fixed, time and materials, or usage-based, and what is the worst-case cost? | Prevents budget surprises once real usage volume is known |
| Accountability | Who is accountable when the system produces a wrong or harmful output? | Establishes a clear response path before an incident, not during one |
| Certifications | What certifications, such as SOC 2 or ISO 27001, does the vendor hold? | Provides a verifiable, third-party-audited baseline for security practices |
References are a question too
Ask for at least two references from projects of comparable scope and industry, and actually call them rather than accepting a written case study, since a case study is marketing material written by the vendor about itself. During the call, ask what went wrong during the engagement and how the vendor responded, not just whether the reference is satisfied overall, since almost every reference a vendor offers will describe general satisfaction.
Turning the answers into a decision
Collecting written answers to all of these questions before signing is useful only if the answers actually inform the decision rather than being filed away once a contract is close to done. A practical approach scores each vendor's answers against the same rubric used for the checklist above and treats any missing or evasive answer as a deduction, not a neutral gap. For the broader evaluation this due diligence feeds into, see how to choose the right enterprise AI company.
- Send the full question list to each finalist vendor in writing, with a deadline for a written response.
- Score each answer as clear and favorable, vague, or missing.
- Follow up specifically on any vague or missing answers before proceeding further.
- Only move to contract negotiation once every question has a documented, acceptable answer.
Frequently asked questions
Should these questions be part of the RFP or asked separately after shortlisting?
Include the most critical ones, data handling, ownership and exit terms, directly in the RFP so weaker vendors self-select out early. Save the more detailed due-diligence questions, such as reference calls and specific SLA terms, for the shortlisted finalists to keep the initial RFP responses manageable.
What if a promising vendor cannot yet meet every certification requirement?
Smaller or newer AI firms may not hold every certification but should be able to demonstrate equivalent practices and a credible path toward certification. Treat an absence as a discussion point rather than an automatic disqualifier, particularly for a firm otherwise strong on technical delivery.
How do we verify a vendor's claimed SLA is realistic?
Ask for the SLA history from an existing client, if the vendor can arrange it, or ask directly what percentage of past incidents were resolved within the stated response time. A vendor with no ability to speak to actual past SLA performance is offering an untested promise rather than a demonstrated one.
Is it reasonable to ask a vendor about model deprecation risk if we plan to use a hosted API?
Yes, and it is one of the more overlooked questions. Hosted model providers periodically deprecate or change pricing on specific model versions, and a vendor with no plan for handling that change is passing an operational risk directly to the client without warning.
How Nanobase AI helps
Nanobase AI answers each of these questions in a written scope document before any contract is signed, since vague answers at this stage tend to predict problems later in the relationship. Data handling, ownership terms and exit provisions are addressed explicitly up front rather than left for a client to discover after the engagement has started.
Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.