SELINA.ai
Sign in

AI Vendor Risk Assessment Questions Your Procurement Team Should Actually Be Asking

Most procurement teams now face a version of the same problem: the vendors you already approved are shipping AI features into products you already use, and nobody triggered a review. The standard ai vendor risk assessment questions floating around in blog posts and compliance templates were written for a world where you chose to buy AI. That world is gone. AI in procurement is no longer a discretionary purchase. It is a condition of your existing vendor relationships, and your risk framework needs to catch up.

Key Takeaways

Why Is AI Vendor Risk Different from Regular Vendor Risk?

Because AI changes the data-flow profile of a product without changing the product's name, price, or contract. A SaaS tool your security team vetted two years ago can add a chatbot, an auto-summarizer, or a predictive feature. That addition may route your data to a third-party model provider you have never assessed and may not even know exists. The vendor's SOC 2 report says nothing about model training on customer data or fourth-party model providers. Your existing controls were built for a different threat surface.

Traditional third-party risk management assumes you review a vendor when you buy something. AI breaks that assumption. A vendor relationship can look unchanged on paper while the underlying risk shifts with every product update. This is the structural problem, and adding ten more questions to a spreadsheet does not fix it.

How Does AI Enter an Organization Without a Purchase Order?

Three common paths. First, embedded AI: your existing vendor ships an AI feature into a product you already use. No new contract, no new procurement cycle. Second, shadow AI: individual employees or teams adopt AI tools on their own, outside IT's view. Only about a quarter of organizations report comprehensive visibility into employee AI use, even as 85% have integrated AI into core operations. Third, subprocessor chains: your approved vendor uses a model provider, which itself may use another provider. You inherit risk from vendors you never assessed.

Each of these paths can create a new data flow and source of risk without triggering a procurement review, a contract change, or a conventional vendor assessment. If your vendor risk model relies on periodic questionnaires tied to purchase events, these paths are invisible to it.

What Questions Should You Ask About Data Handling?

Start with the most important one: does this vendor use customer data to train or fine-tune its models? If the answer is yes, or "not currently," you need a contractual clause, not a verbal assurance. A no-training clause that survives contract termination is the single most important contract term in AI procurement right now. Without it, your data could be used for training even after you leave.

Beyond training, ask these:

These are not hypothetical concerns. Shadow AI tools often rely on their own third-party model providers and subprocessors, meaning an enterprise can inherit risk from entities it has never evaluated.

Why Don't SOC 2 and ISO 27001 Cover AI Risk?

Because they were designed to assess security programs, not AI-specific failure modes. A SOC 2 Type II report tells you a vendor has controls around access management, change management, and availability. It does not tell you whether the vendor's AI feature sends your data to a fourth-party model provider. It does not tell you whether that model was trained on data from other customers. It does not cover algorithmic bias, hallucination rates, or model provenance.

These certificates are necessary but not sufficient. Treat them as gates, meaning a vendor without them should not pass initial screening, but do not treat them as evidence that AI-specific risks are managed. The substance behind the badge needs separate assessment: data retention scope, training exclusions, subprocessor lists, and incident response for AI-specific failures like data leakage through model outputs.

What Does a Practical AI Vendor Risk Framework Look Like?

Not a single questionnaire. A 50-point AI vendor risk template organized across five domains gives you a working structure: security posture, compliance certifications, data handling, model provenance, and operational resilience. Each domain gets severity weighting and explicit go/no-go gates.

But the framework matters less than the cadence. AI vendor risk assessment is a renewal-cycle discipline. A vendor you assessed six months ago may have changed its model provider, updated its data retention policy, or added a new AI feature. If your review only happens at contract signing, you are operating on stale information for the entire contract term.

Practical implementation looks like this:

How Should You Handle Model Provenance and the AI Supply Chain?

Ask where the model came from. A vendor may have built its own model, fine-tuned an open-source model, or integrated a third-party model provider's API. Each scenario carries different risk. A vendor using a third-party model provider is adding a fourth party to your risk chain, one you did not select and may not be able to audit.

Specific questions worth asking:

Model provenance is not academic. Algorithmic risk in vendor contracts is a live topic in legal and compliance circles. Your contract should address what happens when the underlying model changes, because it will.

What Are the EU AI Act Deadlines That Actually Matter Right Now?

The timeline has shifted, and this is causing real confusion among both vendors and buyers. A June 2026 Digital Omnibus amendment pushed the high-risk system compliance deadline from August 2026 to December 2027. But transparency and content-labeling obligations stayed on the original August 2, 2026 schedule. European Parliament committees voted 101-9 to back fixed 2027/2028 deadlines for high-risk systems.

This split timeline matters for procurement because vendors will cite the delay to avoid answering governance questions. "We have until 2027" is a true statement about high-risk classification obligations. It is not a valid reason to skip data-handling transparency, which is already due.

More importantly, the company that deploys an AI system stays accountable for it even when a third-party vendor built or operates it. Hiring a vendor does not transfer your legal exposure. If your vendor's AI system creates a problem in a regulated context, the liability sits with you, the deployer.

Should You Wait for Regulators to Set Your Risk Bar?

No. Buyer-side diligence is already decoupling from regulatory enforcement. Customers, acquirers, and insurers are running their own AI vendor diligence independent of what regulators ultimately decide. Procurement teams are setting their own bar regardless of legal deadlines.

This is the practical reality: if you wait for the EU AI Act's final rules to stabilize before asking vendors hard questions, you are running unassessed risk for years. Your customers and your insurers are not waiting. They are asking you these questions now, and they expect you to have answers about your own vendors.

The vendors who treat governance readiness as part of their sales motion, rather than a legal cost center, are the ones who will close deals faster. If a vendor cannot answer basic questions about data handling and model provenance today, that tells you something about their operational maturity. The regulation is a useful forcing function, but it is not the reason to do this work.

What Does Shadow AI Risk Mean for Procurement Specifically?

Shadow AI (AI tools and features employees use without formal approval) is the fastest-growing blind spot in procurement risk. It enters through two doors: employees adopting standalone AI tools on their own, and vendors embedding AI into already-approved products without triggering a review.

The numbers are stark. Only a minority of organizations report full visibility into employee AI use. Shadow AI has been linked to a meaningful share of data breaches in recent studies, with significant per-incident costs.

For procurement teams, this means your approved vendor list is an incomplete picture of AI risk exposure. The tools your legal team vetted last year may now include AI features that were not part of the original assessment. The browser extension your sales team installed may be sending customer data to a model provider you have never heard of.

Two things help. First, build a discovery process. Regularly audit what AI-enabled tools and features are in active use, not just what was purchased. Second, add contract language requiring vendors to notify you before enabling new AI features that change the data-flow profile of their product. This is a reasonable ask, and vendors who resist it are telling you something.

How Is AI Being Used Inside Procurement Teams Themselves?

AI in procurement is not just something you assess in vendors. It is something procurement teams are adopting internally, for spend analysis, contract review, supplier discovery, and risk scoring. About 49% of procurement teams are running AI pilots, but only about 4% have reached meaningful deployment.

That gap between piloting and production is worth understanding. Common failure points: unclear ownership of the AI tool within the procurement function, insufficient data quality to power the AI effectively, and a lack of integration with existing procurement systems. AI tools for procurement teams range from contract analysis platforms to automated supplier risk scoring, but adopting them requires the same rigor you apply to vendor assessments. You are now the deployer, and the same questions about data handling, model provenance, and subprocessors apply to your own tools.

The useful framing: procurement teams evaluating AI tools for internal use should apply their own vendor risk assessment framework to themselves. If you would not accept vague answers from a supplier, do not accept them from the AI tool you are buying for your own team.

What Contract Clauses Matter Most for AI Vendors?

Five clauses carry most of the weight in an AI vendor contract. The no-training clause is the most important, and it needs to survive termination. If a vendor trains on your data during the contract and you leave, the training does not undo itself. The clause must cover post-termination use.

The other four, in rough order of importance:

  1. Subprocessor notification: the vendor must notify you before adding or changing a model provider or subprocessor involved in processing your data.
  2. Data deletion and propagation: deletion of your data must extend to the model provider's systems, with a defined timeline.
  3. AI feature notification: the vendor must notify you before enabling new AI features that change the data-flow profile of the product you are using.
  4. Incident response for AI-specific failures: the contract should define what constitutes an AI-specific incident (data leakage through model outputs, for example) and set response timelines.

Re-engineering vendor contracts for algorithmic risk is not a future project. It is a current one. If your contract template has not been updated since 2023, it almost certainly lacks these provisions.

How Do You Assess Operational Resilience in an AI Vendor?

Operational resilience for AI vendors has a dimension that traditional vendors do not: dependency on model providers. If your vendor's AI feature relies on a third-party model API, and that API goes down or changes its terms, your vendor's product is affected. Ask these questions:

These are not theoretical concerns. Model providers update their terms, change pricing, and experience outages. The state of vendor risk in the AI era includes dependency risk as a first-class concern. A vendor that cannot answer these questions has not thought through its own supply chain, and that should factor into your assessment.

How Should You Weight and Score AI Vendor Risk?

Not every AI risk is equal. A vendor using AI for internal analytics on aggregated, anonymized data is a different risk profile than a vendor using AI to process your customers' personal data in real time. Your scoring should reflect this.

A workable approach: categorize AI use by data sensitivity and autonomy. A feature that processes personally identifiable information and makes automated decisions (like fraud scoring or eligibility determination) gets the highest risk weight. A feature that uses AI for internal workflow optimization on non-sensitive data gets the lowest. Severity weighting with explicit go/no-go gates means some findings are blockers and others are notes for the next review cycle.

The go/no-go gates matter most. A vendor that trains on customer data without a contractual prohibition is a blocker, full stop. A vendor that cannot name its model provider is a blocker. A vendor with a slightly longer-than-ideal data retention window is a finding to negotiate, not a reason to walk away.

What Should a Quarterly AI Vendor Review Include?

Your renewal-cycle review should cover four things that change over time:

  1. Has the vendor added, changed, or removed any AI features since the last review?
  2. Has the vendor changed its model provider or added new subprocessors?
  3. Has the vendor updated its data retention or training policies?
  4. Have any AI-specific incidents occurred, including data leakage, model failures, or bias-related complaints?

This is not a heavy lift if you build it into existing review cadences. Most procurement teams already have quarterly or annual vendor reviews. Adding four questions about AI is straightforward. The hard part is getting vendors to answer them honestly, which is why the contract clauses above matter. If you have a contractual right to notification on these changes, the review is a confirmation, not a discovery process.

Continuous re-verification over point-in-time sign-off is the direction procurement is moving. The vendors who are ready for this cadence are the ones who have their own AI governance in order. The ones who resist are telling you their governance is immature, or absent.

Where Does This Leave Procurement Teams Today?

In a period where nearly 40% of enterprise applications will embed AI agents by the end of 2026, the procurement function cannot treat AI risk as a special category handled by a separate team. It is now a core part of vendor risk management, embedded in every sourcing decision, every renewal, and every vendor changelog.

The teams that will manage this well are the ones that stop treating AI vendor assessment as a one-time checklist and start treating it as an ongoing practice. Ask the questions above at intake. Ask them again at renewal. Put the five contract clauses in your template. Monitor vendor changelogs for AI feature announcements. Build discovery into your process so shadow AI does not blindside you.

The regulatory environment will keep shifting. The EU AI Act deadlines will probably shift again. But procurement teams that operate as if the strictest version of the rules already applies will not need to scramble when enforcement arrives. They will already be ready, and so will their vendors.

Start a free 7-day trial, no card required, if you want to see what this looks like in practice.

Frequently Asked Questions

Why is AI vendor risk different from traditional vendor risk?

AI can change a product's data-flow profile without changing its name, price, or contract, so a vendor you already vetted can add features that route data to unassessed third-party model providers. Traditional vendor risk management assumes review happens at purchase, but AI features can appear through updates without triggering any new procurement review.

How can AI enter a company without going through procurement?

It typically enters through three paths: embedded AI added to existing vendor products, shadow AI adopted by employees outside IT's view, and subprocessor chains where an approved vendor relies on model providers you never assessed. Each path can create new risk without a purchase order, contract change, or conventional vendor assessment.

What key questions should procurement ask vendors about data handling?

The most important question is whether the vendor uses customer data to train or fine-tune its models, and any 'yes' or 'not currently' answer needs a contractual no-training clause that survives termination. Other essentials include where data goes at inference time, specific retention windows for prompts and outputs, a current subprocessor list, and whether deletion propagates to the model provider's systems.

Do SOC 2 and ISO 27001 certifications cover AI-specific risks?

No, these certifications assess general security programs like access management and availability, not AI-specific issues such as fourth-party model providers, training on customer data, or algorithmic bias. They should be treated as necessary gates for initial screening, not as evidence that AI risks are actually managed.

Should procurement teams wait for EU AI Act deadlines before acting?

No, because the deadlines have shifted and created confusion, with high-risk obligations pushed to December 2027 while transparency rules remain due August 2026, and vendors may cite delays to avoid governance questions that are already relevant. Also, the company deploying an AI system remains legally accountable for it even when a vendor built or operates it, so buyer-side diligence shouldn't wait on regulators.

Sources & References

Michael C.

Michael C.

Founder & Principal Engineer, Selina Labs

Michael builds Selina, a privacy-first AI that remembers you across conversations. He ships security-sensitive AI in production — real attacks, real fixes, measured in minutes and dollars — and writes about privacy, security, and LLMs from that seat. Top Rated Plus and expert-verified on Upwork.

Learn more about Selina.ai