Vendor AI Risk Management: The Questions Your TPRM Program Is Not Asking Yet

Most organizations have a third-party risk management program.

They ask vendors about information security. They review privacy controls. They assess financial viability, business continuity, cybersecurity posture, incident history, subcontractors, insurance, and regulatory obligations. In stronger programs, they tier vendors by criticality, review contracts, track remediation, and revisit higher-risk suppliers on a defined cadence.

That discipline matters. But it is no longer enough.

AI changes the risk profile of third parties because vendors are no longer only storing data, processing transactions, or providing software. Increasingly, they are using AI to summarize, classify, recommend, generate, route, prioritize, monitor, score, approve, deny, and act. Some of that use is visible to the customer. Much of it is not.

The practical problem is simple: traditional TPRM programs were not designed to answer whether a vendor's AI system is making or influencing decisions, whether that system is monitored, whether its models or prompts change after onboarding, whether fourth-party AI providers are involved, whether human oversight is meaningful, or whether evidence exists to prove the controls are working.

Executives do not need to wait for a new regulation to see the exposure. The governance test is already here:

• Can we identify which critical vendors use AI on our data or in our workflows?
• Would we know if a vendor changed a model, prompt, or AI-enabled process after onboarding?
• Can we show evidence that vendor AI controls are operating?
• Do our contracts give us notice, audit, evidence, and recourse rights?
• Who is accountable if vendor AI influences a customer, employee, financial, or regulated outcome?

For executive teams, the question is not whether every vendor AI use case is high-risk. Many are not. The question is whether the organization can identify which vendor AI use cases matter, understand the controls, and produce credible evidence when a regulator, client, auditor, board committee, or incident review asks what governance was in place.

Why Traditional TPRM Is No Longer Enough

Traditional third-party risk management is built around a familiar set of risk domains: security, privacy, resilience, financial health, legal terms, service availability, compliance posture, and concentration risk. Those domains remain necessary. AI does not replace them. It adds a new layer of questions across them.

A vendor can have strong cybersecurity controls and still introduce unacceptable AI governance risk.

A vendor can pass a privacy review and still use customer data in an AI-enabled workflow that the customer does not understand.

A vendor can maintain excellent uptime and still change an underlying model, prompt structure, or automated decision workflow in a way that alters outcomes.

A vendor can provide a standard SOC report and still be unable to explain which AI systems affect the services being delivered.

Consider the ordinary vendor scenarios now appearing in mid-market environments. A customer support provider uses AI to prioritize complaints. A legal technology vendor uses AI to summarize sensitive documents. A procurement platform uses AI to score suppliers. A workflow platform introduces an agent that can update records or trigger tasks.

None of those scenarios is automatically unacceptable. But each changes the governance question. The issue is whether the customer understands the AI use, data boundary, decision influence, change process, evidence trail, and accountability model.

This is why simply adding "Do you use AI?" to a vendor questionnaire is not enough. That question is too broad to be useful and too easy to answer in a way that hides the real risk.

The better question is how AI affects the product, service, data flow, decision process, and control environment the customer relies on.

AI risk often enters through a side door. The enterprise may not have approved an internal AI system. It may not have built a model. It may not even have enabled a major AI platform. But if a vendor uses AI in a service that affects the enterprise's customers, employees, legal obligations, operational processes, or regulated decisions, the enterprise may still inherit governance exposure.

That is the central weakness in many current TPRM programs: they assess the vendor, but not the vendor's AI operating model.

The AI Governance Gap

The AI governance gap in third-party risk is not primarily a documentation problem. It is an accountability problem.

Traditional vendor reviews usually ask whether controls exist. AI vendor governance needs to ask whether the organization understands what the AI system is doing, what authority it has, what evidence it produces, and who is accountable when it changes or fails.

AI capabilities are increasingly embedded inside ordinary SaaS products. AI supply chains are layered through model providers, cloud AI services, workflow tools, and subcontractors. AI systems can change after onboarding through new model versions, prompts, retrieval sources, monitoring thresholds, and workflow integrations.

AI can also influence decisions without formally making them. A system that recommends, ranks, scores, routes, summarizes, flags, or drafts can materially shape human action. If the review only asks whether AI makes an automated decision, it may miss the influence layer.

Evidence is immature as well. Many vendors can describe policies and broad safeguards. Fewer can provide control evidence showing how AI use is inventoried, tested, monitored, escalated, and reviewed over time.

Finally, agentic AI introduces delegated execution. When AI systems can call tools, update records, trigger workflows, send messages, initiate tasks, or interact with other systems, the risk is no longer only output quality. It is authority boundaries.

That is a different governance problem from traditional software risk.

A Practical Diagnostic: The Seven Layers of AI Vendor Governance

AI vendor reviews need a lens more precise than "Does the vendor use AI?"

A practical review should test seven layers:

1. Service exposure: Where does AI appear in the product, service, workflow, or decision process we receive?
2. Decision influence: Does AI recommend, score, rank, route, approve, deny, draft, or otherwise shape material action?
3. Data boundary: What sensitive or regulated data enters the AI workflow?
4. Fourth-party dependency: Which model providers, AI infrastructure vendors, subcontractors, or managed services support the AI capability?
5. Change control: How are model, prompt, retrieval, monitoring, and workflow changes governed after onboarding?
6. Evidence quality: What artifacts prove that AI controls are designed, operating, reviewed, and escalated?
7. Contractual leverage: What rights exist if AI use changes, causes harm, or requires review?

This is the difference between AI vendor inventory and AI vendor governance.

Inventory tells the organization that a vendor uses AI. Governance tells the organization whether that use is understood, controlled, evidenced, monitored, and contractually addressable.

The Questions Most Vendor Reviews Fail To Ask

The following questions help an organization decide where deeper review is warranted.

1. Where is AI used in the service we actually receive?

Many vendor reviews ask whether the vendor uses AI in general. That is too imprecise.

The relevant question is where AI appears in the service, product, workflow, or decision process delivered to the customer. Is it used in customer-facing outputs, support workflows, triage, risk scoring, fraud detection, contract analysis, data enrichment, recommendations, software development, or security monitoring?

Not all AI use creates the same exposure. A vendor using AI to summarize internal meeting notes is different from a vendor using AI to classify complaints, recommend account actions, prioritize fraud alerts, or draft customer communications.

An effective review should require vendors to map AI use to the actual service boundary.

2. Does AI influence decisions, even if a human makes the final call?

Many governance programs focus on whether AI makes an automated decision. That is important, but incomplete.

AI can influence decisions through ranking, recommendations, scoring, summarization, risk flags, routing, and suggested actions. A human may technically make the final decision while relying heavily on AI-generated framing. In practice, the system may shape what the human sees, what they ignore, and what action appears reasonable.

Vendor review should ask whether AI influences material decisions, not only whether it executes them.

The follow-up questions matter: What decisions are influenced? Who reviews the output? Are overrides tracked? Is there evidence that human oversight changes outcomes when needed?

3. What customer data, employee data, or confidential information enters the AI workflow?

Privacy reviews often ask whether data is encrypted, stored, transferred, retained, and shared. AI workflows require more specific questions.

What data enters prompts, retrieval systems, model inputs, evaluation sets, logs, support workflows, or monitoring tools? Is data used to train or improve models? Is it retained by fourth-party model providers? Is sensitive data filtered before AI processing? Are customer-specific restrictions technically enforced or only contractually stated?

The issue is not only whether the vendor has a privacy policy. The issue is whether data boundaries are understood at the AI workflow level.

4. Which fourth parties support the vendor's AI capability?

AI vendor risk is often fourth-party risk.

A vendor may rely on a model provider, cloud AI service, embedding provider, vector database, data-labeling provider, AI monitoring service, prompt management tool, or outsourced human review process. Each dependency can introduce operational, privacy, resilience, intellectual property, regulatory, and concentration risk.

Standard subcontractor disclosures may not identify which fourth parties support AI delivery. A useful review should ask who provides the model, who hosts it, who can access data, who monitors outputs, who supports tuning, and who receives logs.

For General Counsel, this is a contract governance issue as much as a diligence issue. If the agreement does not identify AI subcontractors, model-provider dependencies, data-use limits, audit rights, change notice, incident notification, and evidence obligations, the customer may lack leverage when vendor AI use becomes material.

5. How are model, prompt, and workflow changes governed after onboarding?

Vendor risk reviews often happen before contract execution, then again at renewal or on a periodic schedule. AI systems can change in between.

A vendor may update model versions, modify prompts, alter retrieval sources, introduce AI features, expand use of customer data, change monitoring thresholds, or connect AI to new workflow tools. These changes can alter performance, explainability, risk, and control expectations.

The vendor review should ask what change governance exists for AI components. Which changes require approval, notice, retesting, documentation, or rollback?

6. What evidence proves that AI controls are operating?

Many vendors can provide policy statements. Fewer can provide evidence.

Evidence might include AI system inventories, risk classifications, approval records, system cards, evaluation results, monitoring logs, incident records, exception reports, human review samples, drift indicators, vendor attestations, and control testing results.

The point is not to demand every artifact from every vendor. The point is to match evidence to risk. For AI workflows that affect customers, regulated decisions, financial outcomes, or operational continuity, a policy statement is not sufficient.

This is where governance architecture matters. In a mature program, policy obligations connect to vendor controls, controls generate evidence artifacts, evidence creates monitoring signals, exceptions trigger escalation, and reporting supports executive oversight. TrustLayer-style thinking is useful here not as a software claim, but as an architectural pattern for evidence, monitoring, attestation, and assurance.

7. What happens when the AI system is wrong?

Traditional vendor reviews often ask about security incidents, privacy incidents, and business continuity events. AI failure modes are broader.

An AI system may generate inaccurate advice, misclassify a case, hallucinate a customer response, recommend an unfair outcome, expose confidential information, fail silently, or take an unauthorized workflow action.

The vendor review should ask how AI-related incidents are detected, classified, escalated, documented, remediated, and reported to the customer.

The key issue is whether the vendor treats AI failures as governable incidents, not merely product defects.

8. Who is accountable for AI governance inside the vendor?

Vendor AI governance should have owners.

That does not mean every vendor needs a dedicated AI governance officer. It does mean the vendor should be able to identify who owns AI risk decisions, control approval, change governance, data-use restrictions, incident escalation, and customer disclosures.

An effective review should identify who owns AI governance and whether those owners have decision rights and evidence.

9. Can the vendor explain the system well enough for our oversight obligations?

Explainability is not always about opening the model. It is about whether the customer can understand the system well enough to govern its use.

For some use cases, technical explainability may matter. For many executive reviews, the practical question is whether the vendor can explain the AI system's purpose, limitations, data dependencies, validation approach, monitoring controls, human oversight, and escalation process.

If the customer cannot understand the vendor's AI system at a governance level, it cannot confidently assign risk, set controls, brief executives, or respond to audit and regulatory questions.

10. What contractual rights exist if AI use changes or causes harm?

Many vendor contracts were not written with AI-specific changes in mind.

They may not address AI feature notice, opt-out rights, data-use restrictions, fourth-party model providers, audit rights, evidence access, incident notification, human review, model change notification, prohibited uses, or indemnity.

These are not legal decoration. They are operating rights. Notice rights help the customer understand when AI functionality changes. Evidence rights support audit and assurance. Data-use limits define what can enter the AI workflow. Subcontractor provisions clarify model-provider exposure. Incident clauses determine when the customer learns something went wrong.

What Strong AI Vendor Governance Looks Like

Strong AI vendor governance does not mean treating every vendor as high-risk. That would be slow, expensive, and difficult to sustain.

It means building a risk-tiered approach.

Low-risk AI vendor usage typically involves internal productivity or administrative support where AI does not process sensitive customer data, influence material decisions, affect regulated outcomes, or interact with customer systems. These vendors may require disclosure and light attestation.

Moderate-risk AI vendor usage appears when AI is embedded in the service, processes customer or employee data, supports operational workflows, or produces outputs staff may rely on. These vendors usually require a system description, data-use restrictions, evidence of controls, human review expectations, and change notice.

High-risk AI vendor usage appears when AI influences customer, employee, financial, legal, security, safety, or regulated outcomes. These vendors require enhanced diligence, evidence review, contractual protections, incident notification, executive visibility, and reassessment.

Agentic scenarios require the highest scrutiny. If a vendor's AI can call tools, update records, trigger workflows, send communications, approve steps, deny requests, or initiate actions, the review must test delegated authority, permissions, audit trails, rollback, escalation, and accountability.

Once AI use is tiered, evidence should scale with risk. The higher the decision influence, data sensitivity, fourth-party dependency, change velocity, or operational impact, the stronger the evidence expectation should be.

Strong programs also connect vendor AI risk to the broader AI governance operating model. Material vendor AI exposure should be visible to legal, compliance, risk, security, privacy, technology, operations, internal audit, and executive governance forums.

The reporting should be practical. Executives do not need a hundred-line vendor AI inventory. They need visibility into critical vendors using AI, sensitive data exposure, decision influence, fourth-party dependencies, unresolved control gaps, incidents, exceptions, and risk decisions requiring approval.

That is the difference between a one-time enhanced vendor review and a durable AI vendor risk program. A review asks better questions once. A program creates repeatable intake, tiering, evidence, contract, monitoring, escalation, and reporting practices.

A Practical First 30 Days

Organizations do not need to rebuild TPRM from scratch. They need to extend it deliberately.

The first 30 days should produce a working view of material exposure, not a perfect enterprise inventory.

In week one, select three to five vendors where AI use is likely to matter. Prioritize critical vendors, vendors with sensitive data, vendors embedded in customer or employee workflows, and vendors already marketing AI-enabled functionality.

In week two, run an enhanced AI exposure review. Ask where AI is used, what data enters the workflow, whether AI influences decisions, which fourth parties support the capability, how changes are governed, what evidence exists, and what contractual rights apply.

In week three, classify vendors by risk tier. Separate low-risk internal productivity use from moderate-risk embedded AI, high-risk decision influence, and agentic delegated-action scenarios. Identify which vendors require evidence requests, contract review, executive visibility, or remediation.

In week four, turn the findings into governance action. Assign ownership across procurement, legal, compliance, risk, security, technology, and internal audit. Update intake and renewal questions. Define evidence expectations by tier. Identify contract playbook gaps. Establish triggers for monitoring, including AI feature changes, new model providers, expanded data use, incidents, renewals, and high-risk workflow changes.

The first month should end with a practical decision record: vendors reviewed, AI uses identified, risk tiers assigned, evidence gaps found, contract gaps flagged, issues escalated, and standard questions approved for future intake and renewal.

That exercise is often enough to reveal whether the organization has an AI vendor governance program or only a traditional TPRM process with an AI question attached.

Executive Conclusion

Third-party risk management is not obsolete. It is incomplete.

AI does not remove the need for security, privacy, resilience, financial viability, or contractual discipline. It adds new questions about decision influence, delegated authority, model and workflow change, fourth-party dependencies, control evidence, monitoring, explainability, incident handling, and accountability.

For executive teams, the risk is not that every vendor AI feature is dangerous. The risk is that the organization cannot tell which vendor AI use cases matter, prove what controls exist, or explain who is accountable when the system changes or fails.

That is where qualified governance work begins.

The organizations that handle this well will not have the longest questionnaires. They will have clear risk tiers, evidence expectations, contract terms, executive reporting, and an operating model that connects vendor AI use to enterprise accountability.

The question for most organizations is not whether they have a TPRM program.

They do.

The question is whether that program is asking the questions AI now requires.