Executive summary
2026 has been the year enterprise AI vendor risk stopped being a theoretical procurement checkbox and started showing up as headline events with real consequences. Illinois has legislated independent safety audits for frontier developers. The Future of Life Institute's Summer 2026 AI Safety Index gave every major lab a C+ or below. Apple is suing a frontier lab over alleged trade secret theft carried out by staff it hired away. A vendor supplying an employee survey tool exposed a decade of a household name's HR records. None of these events are exotic; each is a variant of the same underlying question enterprises have under-invested in answering: how much do we actually know about the AI vendors we depend on, versus how much do we assume because they are large, well-funded, or well-marketed. This paper sets out a due diligence framework built around five risk categories - model and data provenance, safety and security evidence, incident response and notification, concentration and continuity risk, and contractual and legal exposure - drawing on the vendor-risk stories we have tracked and advised on through the year.
The central argument is that AI vendor risk needs its own due diligence discipline, distinct from both traditional software vendor security review and traditional model-risk management, because it sits at the intersection of both and is currently, in most enterprises, fully owned by neither. Procurement and security teams review infrastructure controls; data science and AI platform teams review model performance; almost nobody is systematically reviewing whether a vendor's safety claims have been independently verified, whether their incident response can meet a notification timeline your own regulator expects of you, or how exposed you are if that one vendor has a bad quarter. This paper is written to close that gap.
1. Why 2026 changed the baseline
For several years, enterprise AI vendor due diligence was, in practice, a security questionnaire plus a look at the vendor's published model card. That was always a thin basis for trust, but it went largely untested because nothing forced the question. That changed this year on three fronts at once: regulators began requiring independent verification rather than self-attestation, most visibly through Illinois's Artificial Intelligence Safety Measures Act mandating third-party safety audits of frontier developers with real financial penalties attached; independent assessment bodies began publishing results that contradicted vendor marketing, with the AI Safety Index's uniformly poor grades being the clearest example; and a string of breaches and legal disputes, from a major professional services firm's exposed access keys to a household electronics brand's third-party HR platform breach, demonstrated that vendor risk in the AI supply chain behaves exactly like vendor risk anywhere else - it is only ever as strong as the least-scrutinised link. Enterprises that built their AI vendor governance around the old, thinner baseline are now visibly behind where the regulatory and evidentiary environment has moved.
2. Model and data provenance
Provenance risk asks a deceptively simple question: what actually went into the model you are relying on, and can the vendor demonstrate it rather than assert it. This covers training data lineage, the integrity of the model weights you are actually served, and whether fine-tuning or distillation steps introduce behaviour the vendor cannot fully account for. We recommend requiring vendors to disclose, at a minimum, whether model weights are cryptographically signed and verifiable end to end, what governance exists over training data sourcing and licensing, and how the vendor tracks provenance through any fine-tuning or distillation pipeline a model has passed through before reaching you. A vendor unable to answer these questions concretely is telling you something important about their own internal maturity, independent of what they say about yours.
3. Safety and security evidence, not safety and security marketing
The gap between a vendor's safety marketing and independently verified safety evidence has never been more visible than it was this year, with every major lab landing at a C+ or below on the AI Safety Index despite years of "responsible AI" messaging. We recommend separating two categories of evidence that vendors, and often enterprises themselves, routinely conflate: infrastructure security assurance, such as SOC 2 or ISO 27001, which says nothing about model behaviour; and model safety assurance, meaning independent red-teaming, evaluation against your own use case's failure modes, and, increasingly, the kind of externally verified audit Illinois now mandates for the largest developers. Ask directly whether any element of a vendor's safety claims has been reviewed by an evaluator with no financial relationship to them, and treat a vague or evasive answer as the answer.
4. Incident response and notification you can actually rely on
A vendor's incident response maturity is invisible until an incident happens, which is precisely why it needs to be assessed in advance rather than discovered live. The relevant test is not whether a vendor has a breach notification policy - nearly all do - but whether the gap between their plausible detection time and their contractual notification commitment to you is one you could defend to your own regulator or board if it played out publicly. A vendor that discovers an issue and takes eleven weeks to tell affected parties, even where that sits within a legal minimum, is setting an expectation you should not assume applies favourably to you as a business customer rather than a retail data subject. We recommend contracting for a notification commitment materially faster than any statutory floor, and testing it, where possible, against the vendor's own account of a past incident.
5. Concentration and continuity risk
The AI implementation market moved decisively this year toward a small number of very large, tightly linked players building dedicated deployment arms backed by major financial institutions, alongside a genuine geopolitical dimension as Chinese open-weight models took a growing share of enterprise inference traffic, drawing direct Congressional scrutiny in the process. Both trends raise the same underlying question for any enterprise standardising on a single AI vendor or model family for a critical function: what happens to your operations if that vendor's terms, availability, jurisdiction, or ownership change with little warning. We recommend treating meaningful AI dependency the way mature organisations already treat cloud concentration risk - with a documented exit or multi-vendor strategy, tested rather than theoretical, scaled to how business-critical the dependent function actually is.
Practical due diligence checklist
The following is deliberately concrete, because AI vendor risk principles that stay abstract rarely survive a procurement deadline.
- Require evidence of independent model safety verification, not vendor self-attestation, and treat evasive answers as a data point in themselves.
- Separate infrastructure security certifications from model behaviour assurance in every vendor review, and score them independently.
- Contract for an incident notification timeline materially faster than the statutory minimum in your sector, and ask the vendor to evidence past performance against it.
- Document a genuine exit or multi-vendor path for any AI function your organisation would consider business-critical, and test it rather than leaving it theoretical.
- Track which of your AI vendors will fall under emerging frontier-model regulation such as Illinois SB 315, and use their compliance posture as an external benchmark for smaller vendors too.
- Review model and training data provenance disclosures on the same cycle as security certifications, not as a one-off intake exercise.
- Give one accountable owner responsibility for AI vendor risk specifically, rather than leaving it split across procurement, security and the AI platform team by default.
Risks and how to manage them
The most common failure mode is treating AI vendor due diligence as a one-time intake gate rather than a standing discipline, so a vendor assessed favourably eighteen months ago is never revisited even as their safety posture, ownership or regulatory exposure changes materially. The remedy is a scheduled re-review cycle, not an annual afterthought. A second failure mode is scoring model safety and infrastructure security as a single combined number, which hides exactly the gap this paper is built around; keep them separate on any vendor scorecard. A third is assuming regulatory coverage equals safety, when in practice a regulation like SB 315 only fully bites from 2028 and only for the largest developers, leaving a real gap enterprises need to close through their own contractual terms in the meantime. The last is concentration risk masquerading as efficiency, where standardising on a single vendor is celebrated as simplification right up until that vendor has a bad quarter.
Executive summary of actions
For boards and executive teams, the headline is that AI vendor risk has moved from a hypothetical to a demonstrated category of enterprise risk in the space of a single year, and vendor governance built for the old, thinner baseline needs to be revisited now rather than at the next scheduled review. Begin by inventorying every AI vendor with access to material data or embedded in a critical workflow, and score each on the five categories in this paper rather than a generic security questionnaire alone.
Resolve ownership explicitly: AI vendor risk currently sits unclaimed between procurement, security and the AI platform function in most organisations we work with, and that gap is precisely where the incidents covered in this paper occurred. Build the standing review cycle, the exit strategy for concentrated dependencies, and the notification expectations into contracts now, ahead of the regulatory deadlines that will eventually force the issue anyway. Enterprises that treat this as a proactive discipline will spend materially less time managing vendor incidents reactively than those that wait for the next headline to prompt the review.
Talk to us about building an AI vendor risk framework for your organisation. Email sales@halfteck.com.