Third-party involvement in breaches jumped 60% in the past year and now sits behind 48% of all incidents, according to Verizon’s 2026 Data Breach Investigations Report. At the same time, the share of employees regularly using unapproved “shadow AI” tools at work tripled from 15% to 45%. Put those two numbers together and the picture is clear: the fastest-growing category of vendor risk in most organizations isn’t a vendor anyone signed a contract with.
That’s the uncomfortable truth about AI supply chains. A model provider you approved in January may ship a materially different model in June. A SaaS platform your team already trusts can quietly turn on an embedded AI feature that starts sending data to a fourth party nobody reviewed. Traditional vendor risk management was built for software that behaves the same way today as it did at signing. AI vendors don’t hold still, and most due diligence programs haven’t caught up.
Most vendor risk programs were designed around a simple cadence: assess before signing, reassess at renewal, done. That cadence made sense when the product underneath the contract stayed largely fixed between reviews. It doesn’t work for a vendor whose core product is a model that can change behavior overnight, without a version bump anyone outside the vendor’s own engineering team would notice. Closing that gap doesn’t require throwing out existing vendor risk processes — it requires recognizing which assumptions in those processes no longer hold once AI is involved.
Below are five signals that your AI vendor risk process is still treating model providers like static software vendors — and what CISOs and risk leaders should be asking instead.
Your vendor’s model changed and nobody told you
Traditional vendor risk management runs on point-in-time snapshots: a security questionnaire, a SOC 2 report, an annual renewal review. That model assumes the product you approved is the product you’re still running a year later. AI breaks that assumption.
A foundation model can be retrained, fine-tuned, or swapped for a newer version with no meaningful notice to downstream customers, and each of those changes can shift the system’s behavior, bias profile, and data handling in ways a static contract review never catches. This is the first, and arguably the most consequential, signal that a vendor risk program still assumes AI behaves like ordinary software: it treats the review at signing as the review that matters, rather than the first of many.
Point-in-time assessments miss continuous model updates
The core failure mode is treating a model like code that doesn’t change once it ships. It isn’t. A model that passed evaluation in January can drift by June simply because the underlying architecture, weights, or training pipeline were updated behind an API that looks identical from the outside. Vendor risk programs that rely on an annual review have no mechanism to catch a change that happens in March. Most of this infrastructure also sits on cloud platforms your vendor doesn’t fully control either, which is exactly the kind of shared responsibility gap cloud security posture management is designed to continuously monitor rather than assess once a year.
Sub-processor sprawl multiplies exposure fast
AI agents compound the problem by calling other services on your behalf. An agent that queries one API, which calls another model provider, which routes to a third-party data enrichment service, creates a chain of sub-processors that traditional vendor discovery tools simply don’t surface. This is the same blind spot non-human identity gaps in IAM create inside your own environment, except now it’s happening inside a vendor’s stack where you have no visibility at all. Every hop in that chain is a vendor risk decision nobody explicitly made.
A practical fix is to ask every AI vendor for a current sub-processor list as a standing contractual requirement, not a one-time disclosure at signing. Vendor risk teams that already require this for traditional data processors should extend the same discipline to model providers and the agent frameworks built on top of them — the chain is longer, but the underlying obligation to know who’s touching your data hasn’t changed.
Nobody can trace where the training data came from
Ask most AI vendors a simple question — where did the data that trained this model come from — and you’ll get a vague answer about “publicly available sources” or a flat refusal to elaborate. That’s no longer good enough. Data provenance has moved from an ethics footnote to a contractual and regulatory requirement, and vendor risk teams that can’t get a straight answer are signing up for liability they can’t see. This signal is easy to spot once you’re looking for it: a vendor risk review that accepts “we can’t disclose our training data” as a final answer, instead of a starting point for further questions, isn’t really a review.
Provenance gaps are now a contractual liability, not just an ethics question
If a foundation model provider trained on data it didn’t have rights to, or scraped personal information without a lawful basis, that exposure doesn’t stay contained to the vendor. As a deployer, you inherit it. TrustArc’s guidance on AI supply chain risk frames this well: liability doesn’t stop at the foundation model provider — if a violation happens upstream, you inherit the artifacts of that negligence the moment you deploy the output. Vendor risk questionnaires that stop at “do you have a privacy policy” aren’t asking the question that matters anymore.
The EU AI Act ties data governance directly to Article 11 documentation
Regulation is catching up to this gap. High-risk provisions under the EU AI Act are set to become enforceable on August 2, 2026, and Article 11 specifically requires providers to document data governance and management practices, including provenance tracking, for systems that fall into scope.
Holland & Knight’s analysis of the August 2026 deadline is a useful reminder that this obligation doesn’t stop at the EU border — a U.S. company whose AI output reaches EU users can fall into scope even without a European office, and noncompliant providers face fines of up to €15 million or 3% of global annual turnover. Vendor risk assessments need to confirm a provider can actually produce this documentation, not just attest that they intend to.
This is where a lot of vendor risk questionnaires quietly fall short: they ask whether a vendor has a data governance policy, not whether that policy produces documentation a regulator or an auditor would actually accept. The gap between “we have a policy” and “we can show you the lineage” is exactly where AI supply chain risk hides, and it’s a distinction worth writing directly into renewal criteria rather than leaving to a vendor’s own self-attestation.
Shadow AI is already inside your vendor stack
Here’s the part most vendor risk programs miss entirely: you don’t need to sign a new contract to take on new AI vendor risk. The SaaS tools already sitting in your approved vendor list are quietly turning on AI features, and employees are adopting standalone AI tools faster than security teams can review them. That combination means a meaningful share of AI vendor risk is entering the organization through vendors that have already passed review — just not the version of the product they’re running today.
Employees adopt AI tools three times faster than security teams can review them
The Verizon DBIR’s finding that shadow AI usage tripled from 15% to 45% of employees in a single year isn’t a training problem — it’s a governance gap. Marketing wants a copy generator, engineering wants a coding assistant, and by the time a formal review happens, the tool has already been processing company data for months. A vendor risk program that only evaluates tools procurement has heard about is reviewing a fraction of the actual AI surface area.
Embedded AI features turn every SaaS renewal into a fresh risk review
The subtler version of this problem is the CRM, HR platform, or productivity suite you approved two years ago that just shipped an AI copilot as a feature update. Nothing about your original vendor risk review anticipated that the tool would start sending prompts — and potentially customer data — to an underlying model provider you never evaluated. Terms-of-service updates for existing vendors now need the same scrutiny as a net-new AI procurement request, which is a meaningful shift in how often vendor risk reviews need to happen. It’s the same dynamic driving broader interest in AI agents across software delivery workflows more generally — the tooling is spreading faster than the governance built to review it.
Treating this purely as a policy problem — “employees shouldn’t use unapproved tools” — misses the point. Shadow AI adoption is a signal that sanctioned tools aren’t meeting a real need fast enough, and a vendor risk program that only says no doesn’t make the underlying demand disappear. The more durable fix is a fast, lightweight intake path for low-risk AI tools, so the vendor risk conversation happens before adoption instead of being discovered after the fact during an incident review.
Model provenance has no cryptographic backbone
Even when a vendor is willing to answer questions about model lineage, most organizations have no way to independently verify the answer. A model card can claim whatever the vendor wants it to claim. Without cryptographic verification, vendor risk teams are taking provenance claims on faith — and the industry is finally building the tooling to close that gap. Until recently, that gap between what a vendor claims and what a vendor risk team can actually verify was simply accepted as a cost of doing business with AI providers.
Sigstore-backed signing is becoming the baseline vendors are expected to meet
Google’s Open Source Security Team worked with the Open Source Security Foundation to build the OpenSSF Model Signing specification and integrate it into major model hubs, including Kaggle and NVIDIA’s NGC. As OpenSSF’s case study on the Kaggle rollout puts it, the goal is a simple discipline: sign the model when you train it, verify it every time you use it. Each signing event lands in a public transparency log, so a vendor’s provenance claim becomes something you can independently check instead of something you have to trust.
AI SBOMs give buyers a checklist instead of a leap of faith
Cryptographic signing pairs with a second development: a standardized way to document what’s actually inside a model. In June 2026, CISA and G7 partners across Europe and Asia released joint guidance defining minimum elements for an AI-specific software bill of materials, organized into seven clusters covering everything from model lineage to dataset provenance to infrastructure dependencies.
Morgan Lewis’s analysis of the guidance notes that while it’s voluntary, this kind of guidance tends to become a de facto procurement expectation well before it becomes law — much the way SBOM requirements under the Cyber Resilience Act moved from best practice to deadline-driven obligation. Vendor risk teams that start asking for an AI SBOM now will be ahead of the requests that become standard in the next procurement cycle.
Neither signing nor an AI SBOM eliminates vendor risk on its own — a signed model can still be biased, and a complete AI SBOM can still describe a supply chain full of unpinned dependencies. What they do is convert a vendor risk conversation from “trust me” into “verify this,” which is the same shift that made conventional software supply chain security tractable a decade ago. Vendor risk teams that ask for both, and actually check what comes back, are working from evidence instead of a vendor’s marketing copy.
Your due diligence checklist still treats AI vendors like static software
Everything above points to the same conclusion: AI supply chains need a different operating model than traditional software vendor risk, not just a longer questionnaire. The GLACIS AI Supply Chain Security Guide puts a number on the scale of the problem — 97% of AI projects analyzed contained at least one vulnerable dependency, and 80% of organizations deploying AI rely on third-party models they didn’t build and can’t fully audit. A checklist built for annual review cycles isn’t equipped for a vendor risk landscape that changes this fast.
Continuous monitoring triggers replace the annual review
The fix isn’t more paperwork at signing — it’s monitoring that runs continuously after signing. That means setting explicit triggers: a model version change, a new sub-processor added to the chain, a regulatory enforcement action against the vendor. The same observability discipline that platform teams use to catch drift and anomalies in production systems applies directly here, and it’s worth borrowing the mindset from teams that have already built AI-aware monitoring into their own observability practice. A vendor risk program that only looks at a provider once a year will always be a year behind the provider’s actual risk profile.
A tiered intake process keeps governance from becoming a bottleneck
None of this works if every AI request routes through the same heavyweight review. The practical fix is tiering: a fast lane for low-risk, no-personal-data internal tools, and a deeper review for anything touching sensitive data or making consequential decisions about people. Centralizing intake — one front door for every AI procurement request, regardless of which team is asking — is what makes continuous vendor risk monitoring sustainable instead of a permanent backlog.
Getting this right is less about adding headcount to the vendor risk function than about redesigning when review happens. A tiered process that clears low-risk requests in days, instead of routing everything through a six-week review, is what actually gets adoption of the fast lane — and without adoption, shadow AI just moves further underground instead of going away.
None of these five signals require a bigger vendor risk team to catch. They require treating AI vendors as what they are: living systems that keep changing after the contract is signed, sitting on top of infrastructure decisions that deserve the same scrutiny as zero trust principles already bring to your own network. The organizations that get ahead of this aren’t the ones with the longest procurement questionnaire — they’re the ones who’ve built a process that keeps asking the question after the ink is dry.
Every signal above points back to the same underlying shift: vendor risk used to be a gate you passed through once, and now it’s a discipline you practice continuously for as long as the vendor relationship lasts. That’s a bigger operational change than most vendor risk teams have budgeted for, but it’s a smaller one than absorbing the cost of a breach that traces back to a sub-processor nobody knew existed.
If your team is still mapping what “continuous” vendor risk monitoring should actually look like for your AI stack, Fyld’s security team can help you build the process.
