Your Vendors Are Deploying AI. Your Risk Program Hasn't Noticed.

Last Tuesday, you got a changelog email from your Tier 1 HR platform. Page one covered bug fixes. Page two had performance improvements. Buried on page three, a single line: "We've integrated AI-powered features to improve your experience."

That platform processes employee PII for 4,000 people. It touches health data. It feeds payroll. And now, somewhere in that product, an LLM is processing your regulated data through a model you didn't assess, hosted by a provider you haven't identified, trained on data you know nothing about.

Your last vendor assessment was 11 months ago. It didn't ask a single question about AI.

This is the new normal. Vendors aren't waiting for your next assessment cycle to deploy AI. They're shipping it now, in production, against your data. And most vendor risk programs are structured to notice it roughly never.

The Gap Between Vendor Innovation and Vendor Governance

Here's the math that should worry you.

The average enterprise has 300+ SaaS applications connected to its environment. In the last 18 months, the majority of major SaaS vendors have integrated AI capabilities, many powered by third-party model providers. Your VRM program probably reviews Tier 1 vendors annually and Tier 2 vendors semi-annually.

That's a 6- to 12-month blind spot where vendors can fundamentally change how they process your data, and your risk assessment won't reflect it.

This isn't a theoretical concern. It's a structural failure in how most organizations designed their VRM programs, built for a world where vendor capabilities changed slowly and predictably.

Why This Matters Right Now

Three forces are converging to make vendor AI risk a board-level issue in 2026.

EU AI Act Article 28 is live. If your vendor deploys an AI system and you're the deployer (meaning you use it on your data in your operations), you have obligations. You need to know what AI systems your vendors operate, what risk category they fall into, and whether the vendor meets the requirements. "We didn't know our vendor was using AI" is not a defense under the Act. The August 2026 compliance deadline is three months away.

NIST AI RMF MAP function requires supply chain visibility. The MAP function explicitly calls for organizations to identify AI systems across their supply chain. If you're aligning to NIST AI RMF (and your auditors will ask), you need an inventory of AI in your vendor ecosystem. Not just your own AI deployments.

Cyber insurers are asking. Underwriters have started including vendor AI exposure in their questionnaires. They want to know: do your critical vendors use AI to process your data? Have you assessed the risk? Can you demonstrate ongoing monitoring? If your answer to any of these is "we don't know," expect that to show up in your premium. Some carriers are already adding AI-specific exclusions for organizations that can't demonstrate vendor AI oversight. The coverage gap is real and growing.

Traditional VRM vs. AI-Era VRM

The core problem is that traditional VRM assessment frameworks were designed before AI entered the supply chain. Here's what the gap looks like:

That's eight dimensions where your existing questionnaire likely has zero coverage.

The Shadow AI Supply Chain Problem

You probably already know about shadow IT. Employees adopting SaaS tools without going through procurement. Cloud App Security catches most of it.

Shadow AI in the supply chain is different and harder to detect. This isn't your employees using unauthorized AI. This is your authorized, assessed, Tier 1 vendors embedding AI into products you've already approved.

The vendor didn't change. The product did. And your approval was based on the pre-AI version.

There are three patterns to watch for:

Embedded AI features. Your vendor adds "AI-powered" capabilities to an existing product. Sometimes it's cosmetic (better search). Sometimes it's material (automated decision-making on your data). The changelog might mention it. Or it might not.

Third-party model integration. Your vendor doesn't build their own AI. They integrate a model from OpenAI, Anthropic, Google, or a smaller provider. Your data now flows to a fourth party you've never assessed. Your vendor's SOC 2 doesn't cover the model provider's infrastructure.

AI in vendor operations. Your vendor uses AI internally for support, development, or data analysis. Customer data might be used in prompts, fine-tuning, or RAG pipelines. This is almost never disclosed proactively.

Fourth-Party Model Provider Risk

This deserves its own section because it changes the math on vendor risk dramatically.

When your vendor integrates a third-party model provider, you now have a four-layer supply chain:

Your Organization
    → SaaS Vendor (Tier 1, assessed)
        → AI Model Provider (fourth party, not assessed)
            → Cloud Infrastructure (fifth party, not assessed)

Your risk assessment covers layer one. Maybe. The model provider processes your data through inference APIs, stores prompts and responses (for how long? under what retention policy?), and may use interaction data to improve their models.

The model provider's security posture, data handling practices, and compliance status are all unknown to you. Your vendor may not even have a strong contractual relationship with the model provider, many are using standard API terms of service, not enterprise agreements with meaningful data processing terms.

This is the fourth-party AI risk problem, and it's covered in detail in our dedicated post on fourth-party AI risk.

What Continuous Vendor AI Monitoring Actually Looks Like

"Continuous monitoring" has become a marketing term that often means "we check a rating score quarterly." That's not continuous. That's quarterly with a better label.

Real continuous monitoring for vendor AI risk requires multiple signal categories, correlated and acted on:

External security ratings. SecurityScorecard and BitSight provide ongoing security posture scores. A drop of more than 10 points on a Tier 1 vendor should trigger an alert and potential reassessment. Not a note for next quarter's review.

Breach intelligence. Monitoring breach databases (including HaveIBeenPwned) for vendor domains. If your Tier 1 vendor shows up in a breach, you need to know within hours, not months.

Financial health signals. D&B and Crunchbase data on vendor financial stability. A vendor in financial distress is more likely to cut security corners, lose key personnel, or get acquired (triggering a change of control review).

Compliance status tracking. SOC 2 and ISO 27001 certifications expire. If your vendor's SOC 2 Type II report is 14 months old and they haven't renewed, that's a signal. Kyudo's VRM module tracks expiry dates and alerts 90 days before lapse.

Microsoft ecosystem signals. For organizations running Microsoft 365, there's a category of signals that most VRM tools miss entirely. Defender for Cloud Apps risk scores on vendor applications, Entra ID anomalies (unusual sign-in patterns, privilege escalation on service principals), Sentinel alerts related to vendor integrations, and Purview DLP violations involving vendor data flows. These are first-party signals from your own environment about vendor behavior. They're more timely and more relevant than any third-party rating.

How Kyudo Approaches Vendor AI Risk

Kyudo's Vendor Risk Management module was built for the reality described above: vendors change faster than assessment cycles, AI creates new risk dimensions, and fourth-party visibility is non-negotiable.

Automated vendor discovery. Kyudo doesn't wait for procurement to tell it about vendors. It discovers them automatically from Microsoft 365 Cloud App Security (catching shadow IT), Entra ID (enterprise apps and service principals), Azure (third-party resource providers), expense systems, and contract management tools. If a vendor is touching your environment, Kyudo knows about it.

Risk-based tiering with AI signals. Kyudo's 4-tier categorization isn't based on a manual spreadsheet. It's driven by signals: Purview data classification labels (is the vendor touching sensitive data?), Entra privileged role assignments (does the vendor have admin access?), Defender for Cloud Apps risk scores, and Azure API access patterns. A vendor accessing PCI-scoped data with privileged Entra roles gets auto-classified as Tier 1, with quarterly assessments and continuous monitoring. A low-risk utility vendor gets Tier 4, with monitoring scaled accordingly.

Assessment orchestration. Kyudo supports SIG Lite, SIG Core, CAIQ, and custom questionnaire templates. The VRM Agent orchestrates the assessment lifecycle: initial due diligence, periodic reassessment based on tier, event-triggered reassessment (breach, ownership change, AI deployment), and audit-driven assessments. Questionnaires get intelligent pre-fill from public certifications, prior vendor responses, and industry benchmarks, so vendors aren't answering the same questions from scratch each cycle.

AI-assisted validation. Vendor self-reported answers are cross-checked against external signals. SecurityScorecard and BitSight data, Crunchbase financial information, and public certification databases. If a vendor claims SOC 2 compliance but their certification expired six months ago, Kyudo flags the discrepancy.

Knowledge Graph for vendor relationships. This is where Kyudo's architecture makes a structural difference. The Compliance Graph maps relationships between vendors, assessments, questionnaire responses, certifications, incidents, data sharing agreements, and owners. You can query it directly:

• "Which Tier 1 vendors access PCI data?"
• "Which vendors have SOC 2 expiring in 90 days?"
• "Which internal controls depend on Vendor X?"
• "Show me every vendor whose model provider had an incident in the last 30 days."

For fourth-party risk, the graph extends to sub-vendors and model providers. If your SaaS vendor uses OpenAI, and OpenAI's infrastructure runs on Azure, that chain is mapped. If OpenAI has an incident, Kyudo can trace which of your vendors (and which of your controls) are affected.

Continuous monitoring signal correlation. Individual signals are useful. Correlated signals are actionable. Kyudo's monitoring engine doesn't just collect data points in isolation; it correlates across categories to surface compound risk events that no single signal would catch. For example, if a vendor's SecurityScorecard drops 12 points in the same month their SOC 2 certification lapses and Defender for Cloud Apps flags a permission change on their service principal, those three signals individually might each warrant a note. Together, they indicate a vendor whose security posture is actively degrading while they retain access to your sensitive data. Kyudo surfaces that pattern as a single compound alert with full context: the vendor's tier, what data they access, which controls depend on them, and a recommended action (immediate reassessment, access review, or escalation to the vendor owner). This is the difference between a dashboard full of amber lights and an operating system that tells your team exactly where to focus. The AI Governance module extends this correlation to AI-specific signals, tracking model provider changes, new AI feature deployments, and training data policy shifts across your entire vendor portfolio.

Vendor offboarding. When a vendor relationship ends, Kyudo doesn't just remove them from a spreadsheet. The offboarding workflow starts 90 days before contract expiry with automated warnings, then moves through access review, data retrieval, purge verification, and evidence archival with 7-year retention.

Trust Center and Vendor Portal. Kyudo's Trust Center auto-populates outbound questionnaire responses from the Knowledge Graph and bundles evidence automatically, so when your customers assess you, you're not scrambling. The Vendor Portal lets your vendors self-serve questionnaire updates, upload SOC 2 reports, and notify you of incidents without email chains and shared drives.

"We'll Just Add AI Questions to Our Existing Questionnaire"

This is the most common response I hear, and it's not wrong. It's just insufficient.

Yes, you need AI-specific questions in your vendor assessments. Questions about AI system inventory, model provider identity, training data governance, sub-processor AI usage, and AI incident notification are all necessary.

But questions alone won't close the gap. Here's why:

Assessments are point-in-time. As we explore in The Annual Vendor Questionnaire Is Dead, you ask the question once. The vendor deploys AI two months later. You won't know until the next cycle.

Self-reported answers need verification. Vendors fill out questionnaires with their best foot forward. Without external signals to cross-check (security ratings, breach intelligence, certification status), you're taking their word for it.

Discovery has to be continuous. If a new vendor application appears in your Entra ID tenant or Cloud App Security detects a new SaaS tool, that's a vendor you haven't assessed. Adding questions to an annual questionnaire doesn't help if you don't know the vendor exists.

Fourth-party visibility requires structured data. Knowing that "Vendor X uses AI" is one level. Knowing that "Vendor X uses OpenAI GPT-4 via API, with data sent to US-East inference endpoints, under standard API terms, with no opt-out from training data usage" is what you actually need. That requires a data model built for the problem, not a text field on a questionnaire.

Assessment frequency has to match risk velocity. Annual assessment cycles were designed for a world where vendors changed slowly. A vendor that deploys AI features quarterly needs more than an annual check-in. Kyudo's tier-based assessment cadence (quarterly for Tier 1, semi-annual for Tier 2, annual for Tier 3, as-needed for Tier 4) calibrates the frequency to the risk, not to the calendar.

Adding AI questions to your questionnaire is a necessary first step. It's just not the last step. For a deeper look at how governance needs to move beyond static documents, see AI Governance Beyond the Policy PDF.

Your Monday Morning Checklist

You don't need to overhaul your entire VRM program by Friday. But you can start closing the gap this week.

1. Audit your Tier 1 vendor list for AI exposure. Take your top 10 vendors by data sensitivity. Check their product changelogs and release notes from the last 12 months. Count how many have added AI features. Compare that count to how many of your vendor assessments include AI-related questions.

2. Check your assessment templates. Open your current SIG or custom questionnaire. Search for "AI," "machine learning," "model," "automated decision." If you get zero hits, your assessment framework has a blind spot the size of the entire AI supply chain.

3. Map your fourth-party model providers. For any vendor that uses AI, ask: who provides the model? Where does inference happen? Is customer data used for training? What are the data retention terms? Most vendors won't have clean answers. That tells you something.

4. Review your monitoring signals. Are you getting SecurityScorecard or BitSight alerts on vendor score drops? Are you tracking SOC 2 expiry dates? Are you correlating Defender for Cloud Apps risk scores with your vendor risk tiers? If your monitoring is limited to an annual questionnaire, you have 11 months of blind spot per year.

5. Talk to your procurement team. New vendor onboarding should include AI-specific due diligence. If procurement doesn't know to ask, the gap starts before the vendor even enters your environment.

---

Your vendors are deploying AI whether your risk program is ready or not. The question isn't whether to adapt. It's whether you adapt before the next changelog email buries something you should have known about on page three.

Governance that runs. Not governance that waits.

<a href="/product/vendor-risk" className="cta-button">Try the AI risk assessment</a>