The AI Vendor Due Diligence File
Your AI Vendor Approval File: 38 Answers Before You Sign
Put the vendor's data use, contract terms, open questions, and decision owner in one record before purchase, renewal, or feature approval.
Unlock the full document
This document is free. Leave a work email so we can send corrections and updated versions, and the full sheet unlocks below.
Before you approve the AI vendor
An AI product is waiting for your approval. Your team wants it, a client asks whether you use it, or a vendor you already pay has switched on a feature inside three-year-old software.
You own the decision. You may also own the customer questionnaire, security review, patient-data exposure, confidentiality question, or partner approval behind it. The product page will not tell you which data enters the model, who can train on it, what changes without notice, or how deletion works after termination.
Use the same 38 questions before purchase, during contract review, and at annual renewal. Keep one file across all three dates.
The file is a spreadsheet plus written vendor answers. Buy nothing to build it.
Three rules for the record you will approve
Rule one: the same questions apply to every AI vendor. Small vendor, large vendor, a startup, a platform you already trust. The category does not change the questions. What changes is how long it takes them to answer, and that is itself information.
Rule two: an answer without evidence stays open. A verbal assurance from a sales engineer is a lead, not a fact. Mark the row open until you have a document, a contract clause, a configuration screenshot, or a written statement from someone who can bind the company. Open rows are fine. Open rows recorded as closed are how organizations end up surprised.
Rule three: there is no score. This file deliberately produces no number and no pass mark. A weighted score lets a vendor win on twenty easy questions and lose on the three that mattered, and it lets the person who wants the tool argue about weighting instead of about facts. Read the answers. Decide with your eyes open.
One more thing that follows from rule three: this file names no preferred platform and recommends nothing. Any vendor could score well on it. That is intentional.
Nine fields behind your approval
Every question row carries these nine fields. They are what turn a questionnaire into a record you can act on.
| Field | Definition |
|---|---|
| Answer | What the vendor said, in their words, with the date and the person who said it |
| Evidence link | The document, clause, configuration screenshot, or written statement that supports it. Blank means the row is open |
| Answer owner | Who at the vendor is accountable for this answer. A named person with a title |
| Reviewer | Who on your side read it and judged it sufficient |
| Open question | What is still missing, stated specifically enough to send in an email |
| Contract term | Where this commitment appears in the agreement, by section number. If it appears nowhere, say so |
| Risk owner | Who inside your organization owns the residual risk if this answer turns out to be wrong |
| Decision | Accept, accept with contract change, accept with restriction, reject, or pending |
| Review date | When this row is re-asked. AI vendor terms change more often than most software terms |
The contract term field does the heaviest lifting. An answer that lives only in a sales email is a description of current practice, and current practice can change on a Tuesday without telling you. An answer written into the agreement is a commitment. Sorting your answers into those two piles is often the single most useful hour of the whole review.
The risk owner field is the second most useful, and the most uncomfortable. Every unresolved answer has a residual risk, and that risk belongs to a named human. If nobody will take it, that is the finding.
Section 1: Who will sign and stand behind the answer
| # | Question | What a real answer contains |
|---|---|---|
| 1 | What is the legal entity we would contract with: name, jurisdiction of incorporation, headquarters location, and any parent or holding company | The entity that will actually sign, which is sometimes different from the brand on the website. Watch for a foreign parent that the marketing does not mention |
| 2 | Who owns a controlling interest, and is a change of control under way or completed in the last 24 months | Named owners or investors, and a direct statement on pending transactions. Acquisition changes data practices, and it changes them after you have signed |
| 3 | How many people work here, how many in engineering and security, and which functions are contracted out, to whom, in which countries | Headcount with a breakdown. Contracted engineering or support in another country is common and acceptable, and it is something you need to know before a client asks you |
Section 2: Where your data goes
| # | Question | What a real answer contains |
|---|---|---|
| 4 | What data does the product receive from us, by category, including anything collected automatically: prompts, uploaded files, telemetry, usage metadata, and account information | A list by category. If the answer is only about what users type, ask again about files, metadata, and telemetry |
| 5 | Where is our data processed and stored, by region and by infrastructure provider, including at inference time | Named regions and named providers. Inference often runs somewhere other than storage, and vendors routinely answer only about storage |
| 6 | Does our data leave your systems to reach a model or service operated by a third party. If so, which one, under what agreement, and in what region | A named model provider and a named agreement. This is the question that most often surprises the buyer, because many AI products are interfaces over someone else’s model |
| 7 | Who at your company can view our content, under what circumstances, is that access logged, and are we notified | Named circumstances: support requests, abuse review, manual review of flagged content, debugging. Plus whether the access log is available to us |
| 8 | Is our content ever used to produce outputs shown to another customer, in any form, including caches, shared retrieval indexes, or shared embeddings | A direct no with an explanation of tenant isolation, or a direct yes with the mechanism. Vague answers here are worth a second round |
Section 3: Whether the vendor trains on your data
| # | Question | What a real answer contains |
|---|---|---|
| 9 | Do you train, fine-tune, or otherwise improve models using our inputs or outputs, by default | Yes or no about the default. Defaults matter more than options, because defaults are what happens when nobody configures anything |
| 10 | Can training use be disabled, exactly where is that setting, and does it apply to every feature including features released later | The setting’s location, plus a statement about new features. Products add features that arrive with fresh defaults |
| 11 | If our content was used for training before we disabled it, what happens to it | An honest answer here is usually that it cannot be extracted from a trained model. That is the technical reality. What matters is whether they say so plainly, and what they commit to going forward |
| 12 | Do your subprocessors or model providers train on our data, and which contract term prevents it | A clause reference in their upstream agreement. “Our provider says they do not” without a term is a hope, not a control |
Section 4: How long the vendor keeps your data
| # | Question | What a real answer contains |
|---|---|---|
| 13 | How long are inputs, outputs, and logs retained by default, by category | Numbers with units, by category. “As long as necessary” is not a retention period |
| 14 | Can retention be configured, what is the shortest available setting, and does the setting cover backups and derived data such as embeddings, indexes, and caches | Derived data is where retention answers usually fall apart. Ask specifically |
| 15 | What do you retain after we stop paying, and for how long | A number of days, and what the retained data consists of |
| 16 | Where is retention stated contractually rather than in a help article or a settings page | A section number. A help article can be edited without notice, and frequently is |
Section 5: What deletion means after you leave
| # | Question | What a real answer contains |
|---|---|---|
| 17 | What is the process to delete specific records at our request, what is the expected timeframe, and what confirmation do we receive | A named process, a number of days, and the format of the confirmation. A confirmation you can show a client or a regulator is worth asking for by name |
| 18 | Does deletion reach backups, logs, derived artifacts, and subprocessor copies. If any of those are excluded, what remains and for how long | Almost every honest vendor has a backup window during which deleted content still exists. The good ones tell you the window. The concerning ones claim instant total deletion |
| 19 | What is the maximum deletion timeframe you will commit to in the agreement | A number in the contract. This is the answer that matters if you ever have a client demanding removal or a regulator asking |
Section 6: Which other companies receive your data
| # | Question | What a real answer contains |
|---|---|---|
| 20 | Provide your current subprocessor list with purpose, data categories, and processing region for each | An actual list, ideally at a URL that is maintained. Compare it against the answer to question 6 |
| 21 | How are we notified of a new or replaced subprocessor, how far in advance, and may we object | A notice period in days and an objection mechanism. “We update the page” is a notice method that requires you to check the page |
| 22 | What obligations flow down to subprocessors: confidentiality, security requirements, deletion, training restriction, breach notification | Flow-down terms named individually. Training restriction is the one most often missing |
| 23 | Which single subprocessor failure would cause your longest outage, and what is your plan for it | This question tells you whether they have thought about it. The answer is usually their model provider or their cloud provider, and an honest vendor will say so |
Section 7: Which dated security evidence you can inspect
| # | Question | What a real answer contains |
|---|---|---|
| 24 | Which security artifacts do you hold today, with scope and period: audit reports, attestations, penetration test reports, architecture documentation. Provide them under NDA | Documents with dates and, most importantly, scope. A report covering a different product than the one you are buying is common and easy to miss |
| 25 | Who has privileged access to systems holding our data, how many people, and how is that reviewed | A count, a review cadence, and MFA enforcement stated with scope |
| 26 | How is our data encrypted at rest and in transit, who manages the keys, and who is able to decrypt it | Key custody is the substantive part. “Encrypted at rest” where the vendor holds all keys and all access means encryption protects you against a stolen disk and nothing else. That may be entirely acceptable, and you should know it |
| 27 | What is your vulnerability management practice: scan cadence, remediation targets by severity, and current open critical and high counts | Actual current numbers. A vendor who will give you open finding counts is telling you something about their culture |
| 28 | Do you log access to our data, how long are those logs kept, and can we obtain them on request | Yes or no on customer access to logs. This matters enormously during an incident and is almost never asked before one |
Section 8: When the vendor must tell you about an incident
| # | Question | What a real answer contains |
|---|---|---|
| 29 | What is your contractual notification commitment in hours, and measured from what event: discovery, determination, or confirmation | Both halves. A 72-hour commitment measured from “confirmation” with no definition of confirmation is a commitment with no clock |
| 30 | What will the notice contain, and will you tell us whether our specific data was involved | A commitment to customer-specific impact detail. Many vendors send a general notice and never say whether you were affected, which leaves your own obligations unresolvable |
| 31 | Will you support our own regulatory notification obligations with forensic detail and a named contact, and is that in the agreement | A clause. Your notification clocks run whether or not the vendor cooperates, so cooperation belongs in writing |
| 32 | Have you had a security incident affecting customer data in the last 24 months. Describe what happened and what changed | A described incident with a remediation is a better answer than a denial. Every mature company has had something |
Section 9: What can change before your next review
| # | Question | What a real answer contains |
|---|---|---|
| 33 | How are we notified when the underlying model version changes or a model provider is swapped, and how far in advance | A notice mechanism and a lead time. Many vendors have neither, and will say so if asked directly |
| 34 | Can we pin a model version or defer an upgrade, and for how long | Yes with a duration, or an honest no. An honest no is workable if you know it before you build a workflow on top of the product |
| 35 | What testing do you perform before a model change ships, and will you share results relevant to our use case | Evidence of a test process. This question separates products with an engineering practice from wrappers that inherit whatever the provider ships |
Section 10: What you can take, delete, and keep when you leave
| # | Question | What a real answer contains |
|---|---|---|
| 36 | In what format can we export our data, our configuration, and our outputs, and is export available after termination and for how long | A format and a post-termination window. “Contact support” is not an export mechanism |
| 37 | At termination, what is the deletion timeframe, do we receive a deletion certificate, and what survives | A number, a document, and an honest list of what survives, usually backups on a stated cycle |
| 38 | What would we be unable to take with us: prompts, tuned configuration, historical outputs, embeddings, integrations | The honest answer is usually more than the buyer expects. Ask before signing, because the answer determines your real switching cost |
Who earns money from your approval
Ask these of whoever is recommending the vendor to you: your outsourced IT provider, your integrator, your consultant, or the internal champion. Ask them in writing, and record the answers in the same file.
| Field | The question | Why it changes the reading |
|---|---|---|
| Reseller | Do you resell this product, and do you receive a margin on the license | A reseller’s recommendation is still capable of being correct, and you should read it knowing the margin exists |
| Referral | Do you receive a referral fee, finder’s fee, or spiff for introducing us | Referral fees are common and almost never volunteered |
| Integration | Do you receive revenue for implementing or configuring this product, and how much of the total project value is that | An advisor paid to implement has an interest in the implementation being chosen |
| Usage | Do you receive anything tied to our usage volume, seat count, or consumption | Usage-linked compensation creates an interest in you using more of it |
| Renewal | Do you receive anything at renewal, and does it differ from the first-year amount | Renewal economics are why some recommendations are stickier than they should be |
| Switching | Do you receive anything if we move off a current product to this one | Migration incentives exist and they shape which options get presented |
The point of these fields is not suspicion. Disclosed incentives are manageable and undisclosed ones are not, and any advisor who answers all six plainly has just told you something useful about how they operate. An advisor who will not answer has also told you something.
Apply the same lens to the vendor’s own incentives: usage-based pricing means the vendor benefits when your consumption grows, which is worth knowing before you design a workflow that generates volume.
Which open answers can stop your approval
You will not get all thirty-eight answered well. Here is where to spend your attention.
The six that carry the most consequence:
| Question | Why |
|---|---|
| 6 (third-party model) | Determines who actually holds your data. Everything downstream depends on it |
| 9 and 12 (training use, by vendor and by upstream provider) | Training use is effectively irreversible. There is no deletion request that retrieves content from a trained model |
| 19 (contractual deletion timeframe) | This is the answer you need when a client or a regulator asks, and it needs to be in the agreement |
| 29 (notification commitment and its trigger event) | Your own notification clocks depend on learning quickly. A vendor’s vague trigger becomes your missed deadline |
| 36 and 38 (export and what you cannot take) | Determines whether this decision is reversible. Reversible decisions deserve less scrutiny, and you can only know which kind you have by asking |
And the questions that are worth asking mainly for the reaction: 23, 27, 32, and 35. A vendor who answers these candidly, including with unflattering specifics, is showing you an engineering culture. One who deflects all four is showing you something as well.
Vendor claims that still need a source or contract clause
These appear constantly in AI vendor marketing and none of them answer any question in this file.
| Claim | What is wrong with it | What to ask instead |
|---|---|---|
| ”Enterprise-grade security” | Means nothing. There is no definition and no issuing body | Questions 24 through 28 |
| ”Military-grade encryption” | Marketing for AES-256, which is ordinary and fine. It says nothing about key custody | Question 26, specifically who holds keys |
| ”NIST compliant” or “NIST AI certified” | No such certification exists. NIST AI 600-1 is a voluntary profile of actions for managing generative AI risk, published July 2024. It is guidance and it carries no deadline and no certificate | Ask which specific NIST AI 600-1 actions they have implemented and what evidence exists. A vendor who has actually used the profile can answer |
| ”SOC 2 compliant” with no report offered | SOC 2 is an examination that produces a report with a defined scope and period. A claim without a report and a scope is unverified | Question 24. Ask for the report, the scope, the period, and whether it covers the specific product |
| ”We never sell your data” | Selling and training are different things, and this sentence is often deployed to answer a training question | Questions 9 through 12 |
| ”Your data is encrypted and secure” | Answers nothing about access, retention, or training | Questions 7, 13, and 9 |
| ”99% accurate” | Meaningless without the test set, the task, and the date | Ask what was measured, on what data, when, and what happens when it is wrong |
| ”GDPR compliant” | Compliance is a property of processing activity, not a badge a product can hold | Ask for the DPA, the subprocessor list, and the deletion terms |
| Certification logos in a footer | Frequently belong to a parent company, a different product, or an expired period | Ask for scope and period for each one |
What belongs in your answer column
The distinction is usually visible in a single sentence.
| Question | Deflection | Good answer |
|---|---|---|
| Do you train on our data | ”Your data is private and secure." | "By default, no, for accounts on the Business plan and above. The setting is at Admin, Data Controls, and it is off by default on those plans. On the free plan the default is on. Our agreement covers this at section 4.3.” |
| Where is our data processed | ”In the cloud, with enterprise-grade security." | "Storage in us-east-1 on [provider]. Inference runs on [model provider] in the United States under our agreement with them dated [date]. No processing outside the US for your account configuration.” |
| How fast do you notify us of a breach | ”We take security very seriously and would notify you promptly." | "72 hours from determination that customer data was affected. Determination is defined in section 9.2. The notice includes whether your specific tenant was involved.” |
| Can we delete our data | ”Yes, absolutely, just contact support." | "Deletion via the API or console, removed from production within 24 hours, purged from backups within 35 days on our backup rotation, deletion certificate available on request. Section 6.4.” |
| What happens when the model changes | ”We are always improving the product." | "Model version changes get 30 days notice by email to admins. You can pin the current version for up to 90 days. We publish evaluation results for changes affecting the summarization feature.” |
The pattern in the right-hand column: a number, a location, a definition, or a section reference. The pattern in the left: a sentiment. When you get a sentiment, send the question again with the specific form you need, and note the round trip in the open question field. Two rounds is normal. Four rounds without specifics is an answer of its own.
Send the answer request before your decision date
The questions are the easy part. Getting them answered is a process problem, and a few mechanics make it much faster.
Send them in writing, in one batch, to a named person. Not in a demo. Not over a call. A call produces confident answers from someone whose job is to produce confident answers, and none of it is evidence. Ask the account executive to route the file to whoever owns security, and ask for that person’s name and title.
Say what happens next. “We are evaluating three products and this file is the review. Answers with documents move fastest.” Vendors triage. A buyer who has told them what the process is gets prioritized over a buyer who has sent an unexplained spreadsheet.
Accept partial answers on the first pass. Push everything unanswered into the open question field and send a second round with only those. A short, specific second email gets answered. A repeat of the full file does not.
Watch the routing, because it is data. A vendor who connects you to a security engineer within a week is different from one who has sales answer all thirty-eight. Neither is disqualifying, and the difference tells you what support during an incident will look like.
Expect these timelines, and read a large deviation as information:
| Vendor type | Reasonable time to a substantive first response |
|---|---|
| Established platform with a trust page and a standard DPA | 2 to 5 business days, often self-service |
| Mid-size vendor with a security owner | 1 to 2 weeks |
| Early-stage vendor without a dedicated security function | 2 to 4 weeks, and the answers may be candid because nobody has yet learned to deflect |
One sentence that saves the most time. Put it at the top of the email: “Where a question does not apply to your product, say so and why, rather than leaving it blank.” Blanks are ambiguous. A stated non-applicability is an answer you can record.
One completed row for your review file
One question, filled in, showing what a completed record looks like.
| Field | Content |
|---|---|
| Question | Q9. Do you train, fine-tune, or otherwise improve models using our inputs or outputs, by default |
| Answer | ”Customer content is not used for model training on Team and Enterprise plans. Free and Pro individual accounts are opted in by default.” Stated by [name], Solutions Engineer, on [date], by email |
| Evidence link | /vendor-file/[vendor]/email-2026-08-04-training.pdf, plus terms-of-service-v14.pdf section 4.3, plus screenshot of Admin Data Controls dated [date] |
| Answer owner | [Name], VP of Security, [vendor]. Confirmed the engineer’s statement in writing on [date] |
| Reviewer | [Your name], [date] |
| Open question | Does the exclusion apply to features released after the contract date. Asked [date], no answer yet |
| Contract term | Section 4.3 of the MSA, plus DPA section 7. Note: the MSA language covers “Customer Content” and does not define whether telemetry is included. Flagged to counsel |
| Risk owner | [Name], VP Engineering, for the telemetry ambiguity |
| Decision | Accept with contract change. Requesting an added sentence that the training exclusion applies to all features, current and future |
| Review date | [date + 12 months], or on any terms-of-service change notice |
Notice what this row does. It records the answer, catches an ambiguity in the contract language that the sales answer glossed, keeps one question genuinely open, and assigns the residual risk to a person. That is the whole method.
When AI appears inside software already under contract
You did not evaluate this vendor. You licensed a helpdesk, a practice management system, a document platform, or a CRM years ago, and in a release note they added an AI feature. The data flow changed. No purchase order was raised, no review was triggered, and in many cases the feature is on by default.
This is now a common way AI enters an organization, and it is the one most review processes miss entirely, because every review process is attached to a purchase.
Two things to put in place.
A trigger. When any existing vendor announces an AI capability, it gets a row. Assign someone to read release notes and vendor emails for your top ten platforms. That is a fifteen-minute monthly task and it is the only detection method that works here.
A short question set. You do not need all thirty-eight for an incremental feature in a product you already contract with. Ask these ten, and cite your existing agreement while doing it.
| Priority question | Number in the full set |
|---|---|
| Which model powers this feature, and is it operated by you or a third party | 6 |
| Is our content used to train or improve any model, by default | 9 |
| Can the feature be disabled entirely, at the tenant level, by us | 10, adapted |
| Does this feature introduce a new subprocessor, and when did the subprocessor list change | 20, 21 |
| Does content processed by this feature follow the retention terms in our existing agreement, or different ones | 13, 16 |
| Does our existing DPA cover this processing, or does it need an amendment | 12, 22 |
| Who at your company can view content processed by this feature | 7 |
| Is the feature available to all our users, and can we scope it by role | 25, adapted |
| Does this feature influence any decision about a person | 1 in the shadow AI decision screen |
| Where is this feature’s data processing documented, in a contract rather than a help page | 16 |
The question about the DPA is the one that matters most and the one vendors are least prepared for. An existing data processing agreement was negotiated against the processing that existed at the time. A new AI feature may introduce processing the agreement never contemplated, including a new model provider as a subprocessor. Ask directly whether the vendor considers the existing DPA to cover it. Ask in writing, and keep the reply.
If the feature is on by default and the answers are not yet in, turning it off while you review is reversible. Leaving it on while you review is not.
What counsel needs to screen before your decision
Stated accurately, because a great deal of what is said about AI regulation in sales conversations is wrong.
There is no federal AI certification. NIST published a generative AI profile in July 2024 that provides voluntary actions for identifying and managing generative AI risk. It is guidance. It is not a certification and it sets no deadline.
State law is where enacted dates exist. Colorado’s amended AI law carries an enacted effective date of January 1, 2027 for covered automated systems used in consequential decisions. Whether a specific system falls in scope is a legal determination for your counsel.
State privacy laws continue to take effect on staggered dates: Louisiana and Oklahoma on January 1, 2027, Alabama on May 1, 2027, Vermont on January 1, 2028. Applicability varies by state, by entity type, and by data type, and each law has its own thresholds and exemptions.
Two implications for this file. First, whether a tool is used in a consequential decision about a person, and whether a qualified human reviews the output before it is acted on, are two separate questions that must stay separate in your record, since a tool can be either without being the other. Second, if the consequential-decision answer is yes, this stops being a technology decision and needs counsel before it goes further.
Use the same file at purchase, contract review, and renewal
| Moment | What you do | Time |
|---|---|---|
| Before purchase | All 38, plus the six commercial conflict fields addressed to whoever recommended it. Expect two rounds of email. Accept open rows and record them | 4 to 8 hours across two weeks |
| At contract review | Walk the contract term field. Every answer that matters and lives only in email becomes a redline request. This is where the file earns most of its value | 2 to 3 hours |
| At annual renewal | Re-ask the six that matter most, plus any row whose review date has come. Compare against last year’s answers. Changed answers are the finding | 2 hours |
The renewal pass is the one people skip and the one that catches the most. AI vendors change model providers, revise terms, add features with new defaults, and get acquired, all at a pace that makes a twelve-month-old answer genuinely unreliable.
Before you add another governance platform
There is a category of third-party AI risk platform being sold on the premise that vendor due diligence requires software. It does not. This file is a spreadsheet and a set of emails, and the hard part is reading the answers, which no product does for you.
Before anyone quotes you a platform, ask two things: which of these thirty-eight questions the product answers without you sending an email, and what it does when a vendor sends back a sentiment instead of a number. If the honest answer is that it tracks questionnaires you still have to send and read, you have already built that here.
If your advisor’s first response to your vendor review is a platform proposal, ask which parts of the review the proposal removes, and answer the six commercial conflict fields about that advisor first.
Record the decision, owner, and next review date
This document is general guidance on evaluating AI vendors. It is not legal advice. Whether a specific vendor arrangement, data flow, or use case triggers an obligation under state AI law, state privacy law, HIPAA, GLBA, professional responsibility rules, or your existing client agreements is a legal determination that your counsel makes. Contract language, in particular, should be reviewed by counsel before you rely on any answer recorded here.
Every regulatory claim above is sourced inline to a named authority through SBK’s source register. Where a requirement varies by state, entity type, or data type, this document says so rather than giving you one number. Where something has no certification or no deadline, it says that plainly, because a good deal of AI sales language depends on you assuming otherwise.
SBK Consulting is a family-run, vendor-neutral IT advisory firm serving the New York, Connecticut, and New Jersey metro area. Founded 2010. Zero vendor partnerships, zero reselling, zero commissions or referral fees. 125+ years combined experience, 100% US-based. We review completed vendor files if you want a second reading on your open rows before you sign. If you never call us and this document gets you thirty-eight honest answers, it did its job.
(718) 407-4169