AI Vendor Risk: Contract, Data, Cyber, and Monitoring Questions to Ask

AI vendor risk is not the same as ordinary SaaS vendor risk.

A normal vendor review may ask:

• Is the vendor financially stable?
• Is the contract signed?
• Is security evidence current?
• Does the vendor process personal data?
• Are incident notification terms included?
• Is the vendor critical?
• Are open issues remediated before renewal?

Those questions still matter.

But AI vendors add new questions.

Can the vendor use our data for training?
Are prompts and outputs retained?
Who is the model provider?
Are subprocessors or model providers involved?
Can the vendor change the model without notice?
Is the AI output monitored?
Does the tool influence decisions about customers or employees?
What human oversight is required?
How are harmful, biased, inaccurate, or risky outputs handled?
What logs are available?
What happens when the vendor releases a new AI feature?
What evidence proves the vendor’s controls are operating?

AI vendor risk sits at the intersection of:

• third-party risk
• privacy
• cyber risk
• AI governance
• legal and contracts
• data governance
• model risk
• operational resilience
• evidence management
• issue remediation
• executive reporting

That is why AI vendor risk needs a connected review model.

A vendor may pass a security questionnaire and still create AI governance risk.
A vendor may have a strong SOC report but unclear AI training terms.
A vendor may support privacy commitments but retain prompts longer than expected.
A vendor may provide a useful AI feature but lack monitoring transparency.
A vendor may be approved for one product use but not for expanded AI functionality.

The goal is not to block AI vendors.

The goal is to ask better questions before approval, renewal, expansion, or production use.

What is AI vendor risk?

AI vendor risk is the risk created when a third party provides, hosts, powers, trains, integrates, monitors, or materially supports an AI system, AI model, AI-enabled product, or AI-assisted business workflow.

AI vendor risk may involve:

• contract terms
• data use
• prompt and output retention
• model training or improvement
• subprocessors
• model providers
• cyber controls
• privacy obligations
• system access
• AI performance
• human oversight
• monitoring
• incident reporting
• model changes
• regulatory exposure
• customer commitments
• evidence and audit rights
• remediation and risk acceptance

A traditional vendor record may show that a vendor is approved.

An AI vendor record should show whether the vendor is approved for the specific AI use case, data, model, scope, users, controls, monitoring, and risk tier.

That distinction matters.

A vendor approved for ordinary SaaS use may not be approved for AI processing of customer data.

A vendor approved for internal AI drafting may not be approved for customer-facing AI output.

A vendor approved for a pilot may not be approved for production.

AI vendor risk should be reviewed by use case.

Not only by vendor name.

Why AI vendor risk is different

AI vendors introduce new risk because AI changes what the vendor may do with data and how the business may rely on outputs.

AI vendors may:

• process prompts and outputs
• retain logs
• use customer data for model improvement
• rely on separate model providers
• change models over time
• use subprocessors
• generate inaccurate or harmful outputs
• influence decisions about people
• create transparency or disclosure obligations
• require human oversight
• require monitoring after approval
• create new incident types
• expand functionality inside already-approved tools

NIST’s AI RMF is helpful because it frames AI risk management as lifecycle-based and organized around governance, mapping, measuring, and managing risk. That means an AI vendor review should not stop at onboarding; it should continue through monitoring, change, incident response, and reassessment.  

Traditional vendor risk asks:

“Can we trust this vendor?”

AI vendor risk asks:

“Can we trust this vendor for this AI use case, using this data, under these contract terms, with these controls, monitoring, and evidence?”

That is a much more useful question.

AI Vendor vs AI Model Provider vs AI-Enabled SaaS

AI vendor risk becomes clearer when the roles are separated.

One AI use case may involve several of these roles.

Example:

A customer support platform adds AI summarization. The SaaS provider is the AI vendor. The underlying large language model may be provided by another model provider. The platform may rely on cloud infrastructure and subprocessors. Your organization is the deployer using the AI in customer support.

If the review only looks at the SaaS vendor, it may miss model-provider and subprocessor risk.

The AI Vendor Risk Review Model

A practical AI vendor review has 12 areas:

1. Vendor identity and AI scope
2. Use case and business context
3. Data use and privacy
4. Contract and data-use terms
5. Model provider and subprocessors
6. Cybersecurity and system integration
7. Human oversight and decision impact
8. Performance, limitations, and testing
9. Monitoring and post-approval obligations
10. Incident response and notification
11. Evidence, audit rights, and assurance
12. Issues, exceptions, risk acceptance, and renewal

Each area should produce evidence.

Each gap should produce an issue or approval condition.

Each material residual risk should produce a risk acceptance decision.

1. Vendor Identity and AI Scope

Start with the basics.

The vendor record should show:

• legal vendor name
• product or service
• AI functionality
• business owner
• vendor owner
• contract owner
• AI use-case owner
• current vendor approval status
• AI approval status
• risk tier
• criticality
• renewal date
• deployment status
• approved scope
• business units using the vendor

Do not assume the AI feature is covered by the existing vendor approval.

Ask:

• Is this a new vendor?
• Is this an existing vendor with a new AI feature?
• Is the AI feature optional or already enabled?
• Which business units use it?
• Which AI use cases are tied to the vendor?
• Is it pilot, production, or expansion?
• Is the AI feature customer-facing?
• Is the AI feature used in internal decision support?
• Does it process personal, sensitive, regulated, or confidential data?
• Does it support a critical process?

A vendor can be approved for one use and unapproved for another.

That distinction should be visible.

Vendor identity checklist

2. Use Case and Business Context

AI vendor risk depends on how the vendor is used.

The same vendor can support:

• low-risk internal drafting
• moderate-risk support summarization
• high-risk employee analytics
• critical customer decisioning

The review should ask:

• What is the AI use case?
• What business process does it support?
• Who uses the AI output?
• Who could be affected by the AI output?
• Is the output internal, customer-facing, or public-facing?
• Does the AI influence decisions?
• Does it affect customers, employees, applicants, or vendors?
• Is human review required?
• Is the use case regulated?
• Is the vendor critical to the process?
• What would happen if the vendor failed or produced poor output?

This is where AI vendor review connects to AI risk tiering.

A vendor risk review without use-case context is incomplete.

Use case checklist

3. Data Use and Privacy

Data is often the biggest AI vendor risk.

The review should ask:

• What data will be sent to the vendor?
• Is personal data involved?
• Is sensitive personal data involved?
• Is customer data involved?
• Is employee data involved?
• Is confidential business data involved?
• Is source code involved?
• Are prompts stored?
• Are outputs stored?
• Are logs stored?
• Can the vendor use prompts, outputs, or customer data for training?
• Can the vendor use data for service improvement?
• Does the vendor create embeddings or derived data?
• Can data be deleted?
• Is data used only for documented instructions?
• Is a DPIA or PIA required?
• Is the data inventory updated?

GDPR Article 28 requires processors to process personal data only on documented instructions, ensure confidentiality, implement required security measures, manage subprocessors, assist with data subject rights and security obligations, delete or return personal data after services, and make information available to demonstrate compliance.  

For AI vendors, this means data-use terms must be reviewed carefully.

The vendor may not call something “training.”

It may call it:

• service improvement
• quality improvement
• model optimization
• product analytics
• abuse monitoring
• safety monitoring
• telemetry
• evaluation
• fine-tuning
• benchmarking

Ask directly.

Do not rely on assumptions.

Data and privacy checklist

4. Contract and Data-Use Terms

AI vendor contracts need special attention.

Standard SaaS terms may not address AI-specific risks.

Review contract terms for:

• permitted data use
• prohibited data use
• training restrictions
• service improvement rights
• prompt and output retention
• model provider involvement
• subprocessors
• data processing agreement
• confidentiality
• security obligations
• incident notification
• deletion or return
• audit or assurance rights
• customer data ownership
• output ownership
• IP rights
• liability and indemnity
• service levels
• regulatory cooperation
• model-change notification
• termination assistance
• data export
• cross-border transfers

Contract review should answer:

• Can the vendor use our data for training?
• Can the vendor use our data for product improvement?
• Are prompts and outputs treated as confidential?
• Are outputs owned or licensed clearly?
• Does the contract address hallucinated or infringing outputs?
• Does the vendor disclose model providers?
• Are subprocessors listed?
• Can the vendor change model providers without notice?
• Does the vendor support deletion?
• Does the vendor provide audit or assurance information?
• Are incident notification timelines sufficient?

Contract exceptions should become issues or approval conditions.

They should not remain buried in legal comments.

Contract checklist

5. Model Provider and Subprocessor Risk

AI vendors often rely on model providers and subprocessors.

The AI vendor may provide the interface, but another provider may process prompts, generate outputs, retain logs, or operate the model.

Ask:

• Who is the underlying model provider?
• Does the model provider receive prompts?
• Does the model provider receive outputs?
• Does the model provider retain logs?
• Can the model provider use data for training?
• Are subprocessors listed?
• Are changes to subprocessors disclosed?
• Are model-provider changes disclosed?
• Do data processing terms flow down?
• Do security and confidentiality obligations flow down?
• Does the vendor remain liable for subprocessors?
• Can the organization object to subprocessor changes?
• Are geographic locations known?

GDPR Article 28 addresses subprocessor authorization and requires the same data protection obligations to be imposed on subprocessors by contract or legal act, with the initial processor remaining liable to the controller for subprocessor performance.  

For AI vendor risk, subprocessor and model-provider transparency is not optional.

It is part of understanding where data goes.

Model provider and subprocessor checklist

6. Cybersecurity and System Integration

AI vendor cyber review should include ordinary vendor security controls and AI-specific security questions.

Ask:

• Does the vendor have current security evidence?
• Does the tool integrate with production systems?
• Does it connect through API?
• Does it have read access?
• Does it have write access?
• Does it access customer data?
• Does it access employee data?
• Does it access source code or confidential files?
• Does it support SSO?
• Does it support role-based access?
• Does it provide logs?
• Are prompts and outputs logged?
• Is encryption used?
• How are vulnerabilities managed?
• How are prompt injection, data leakage, or abuse risks handled?
• Are tenant isolation controls documented?
• What incident response commitments exist?

NIST describes cyber supply-chain risk management as identifying, assessing, and mitigating risks throughout the ICT and OT product and service supply chain lifecycle, including acquisition, deployment, maintenance, and destruction.  

AI vendors are part of that supply chain.

Their cybersecurity risk should be reviewed as part of the AI governance workflow.

Cyber checklist

7. Human Oversight and Decision Impact

AI vendors may provide outputs that influence decisions.

The review should ask:

• What decisions could the AI output influence?
• Is the output advisory or automated?
• Who reviews the output?
• Can the human override it?
• Is review required before customer or employee impact?
• Are reviewers trained?
• Are overrides logged?
• Is the vendor’s interface designed to support oversight?
• Does the vendor provide explanations or confidence indicators?
• Does the vendor provide audit logs?
• Does the vendor provide documentation of limitations?
• Does the use case require disclosure?

The EU AI Act’s deployer obligations for high-risk systems include assigning human oversight to natural persons with competence, training, authority, and support. It also requires deployers to monitor operation based on instructions for use.  

Even outside formal high-risk AI Act contexts, the principle is practical:

If the AI output can affect people or important decisions, oversight must be defined and evidenced.

Oversight checklist

8. Performance, Limitations, and Testing

AI vendor review should ask whether the vendor provides enough information to understand performance and limitations.

Ask:

• What is the intended use?
• What are known limitations?
• What use cases are not supported?
• What data was used to evaluate performance?
• What performance metrics are provided?
• How is accuracy measured?
• Are hallucination, error, drift, or bias risks addressed?
• Does the vendor provide evaluation results?
• Does the vendor provide testing artifacts?
• Does the vendor support customer testing?
• Does performance vary by language, geography, population, or use case?
• How are failures reported?
• Are model updates tested before release?
• Can customers test changes before production?
• Is rollback available?

Vendor claims should not be accepted without evidence when the use case is material.

For high-risk or people-impacting AI, vendor performance evidence should be reviewed carefully.

Performance and testing checklist

9. Monitoring and Post-Approval Obligations

AI vendor risk does not end at approval.

Ask:

• What monitoring does the vendor perform?
• What monitoring must the organization perform?
• What metrics are available?
• What logs are available?
• What thresholds are supported?
• Does the vendor notify customers of model changes?
• Does the vendor notify customers of security incidents?
• Does the vendor notify customers of serious AI incidents?
• Does the vendor provide performance reports?
• Does the vendor provide service-level reports?
• Does the vendor provide drift, bias, or error reporting?
• Does the vendor support customer monitoring dashboards?
• Can the organization export monitoring evidence?
• Are monitoring obligations in the contract?

For high-risk AI systems, the EU AI Act requires providers to establish and document post-market monitoring systems that actively and systematically collect, document, and analyze relevant performance data throughout the system’s lifetime.  

For deployers, the AI Act also requires monitoring the operation of high-risk AI systems on the basis of the instructions for use and reporting serious incidents to relevant parties.  

In practical terms:

AI vendor review should define who monitors what.

The vendor may monitor the model.

The organization must monitor business use, output impact, human oversight, incidents, and whether the AI remains within approved scope.

Monitoring checklist

10. Incident Response and Notification

AI vendors can create or contribute to incidents.

Ask:

• What is an AI incident under the vendor’s process?
• What is a security incident?
• What is a privacy incident?
• What notification timelines apply?
• What serious incidents must be reported?
• Does the vendor notify customers of harmful outputs?
• Does the vendor notify customers of model failures?
• Does the vendor notify customers of data exposure?
• Does the vendor notify customers of subprocessor incidents?
• What evidence does the vendor provide?
• What remediation support does the vendor provide?
• How are incidents escalated?
• Are customer responsibilities defined?

AI incidents may include:

• harmful output
• biased output
• unsafe recommendation
• privacy exposure
• unauthorized data use
• model provider incident
• security compromise
• data leakage
• hallucinated output causing harm
• system outage affecting critical process
• prompt injection attack
• unexpected retention of sensitive data

Incident terms should be aligned across legal, privacy, cyber, vendor risk, and AI governance.

Incident checklist

11. Evidence, Audit Rights, and Assurance

AI vendor risk management depends on evidence.

Ask:

• What evidence does the vendor provide?
• Is security evidence current?
• Is privacy evidence current?
• Is AI governance evidence available?
• Is model documentation available?
• Is testing evidence available?
• Is monitoring evidence available?
• Are logs available?
• Are audit rights sufficient?
• Are independent assurance reports available?
• Are certifications relevant?
• Are customer-specific controls evidenced?
• Can evidence be used for audits, regulators, and customer assurance?
• Does evidence cover the AI feature, or only the general SaaS platform?

This last question is critical.

A SOC report may cover the platform but not the AI feature.

A privacy review may cover ordinary processing but not AI training or prompts.

A security document may cover infrastructure but not model-provider risk.

Evidence should match the AI use case.

SmartSuite’s AI Governance page describes storing evidence, model documentation, testing artifacts, review logs, audit trails, version history, and linked records across models, risks, controls, and frameworks.  

That is the evidence model AI vendor risk needs.

Evidence checklist

12. Issues, Exceptions, Risk Acceptance, and Renewal

AI vendor gaps should not sit in review notes.

They should become issues, exceptions, approval conditions, or risk acceptances.

Common AI vendor issues include:

• contract does not restrict training
• prompt and output retention unclear
• model provider unknown
• subprocessor list incomplete
• security evidence expired
• privacy evidence missing
• monitoring unavailable
• human oversight unsupported
• model-change notice missing
• data deletion unsupported
• incident notification terms weak
• performance limitations not disclosed
• AI feature enabled before review
• vendor renewal due with open AI issues

Each issue should include:

• owner
• severity
• affected AI use case
• affected data
• affected contract
• remediation plan
• due date
• evidence
• validation
• renewal impact
• risk acceptance, if needed

Risk acceptance may be needed when the business wants to proceed despite unresolved vendor AI risk.

Risk acceptance should include:

• residual risk
• business rationale
• approver
• evidence
• conditions
• expiration
• monitoring
• dashboard visibility

Renewal should not proceed blindly when AI vendor issues remain open.

Issues and renewal checklist

AI Vendor Risk Questions by Category

Use this summary as the practical review checklist.

AI Vendor Risk Dashboard

An AI vendor risk dashboard should show:

The dashboard should not only show vendor approval status.

It should show AI-specific vendor risk.

Example: AI Customer Support Vendor

Use case:

Vendor AI tool drafts support responses from customer tickets.

Key risks:

• customer data
• prompts and outputs
• potential customer-facing output
• vendor training terms
• human review
• monitoring
• retention
• complaints
• vendor security evidence

Questions to ask:

• Does the vendor retain prompts?
• Does the vendor retain outputs?
• Can the vendor train on customer support content?
• Can support agents send AI output directly to customers?
• What human review is required?
• What monitoring metrics are available?
• Are customer complaints linked to AI output?
• Can data be deleted?
• Does the contract cover model provider access?

Possible approval:

Approved for limited pilot. Human review required before customer response. Vendor may not train on prompts or outputs. Prompt/output retention terms must be documented before production expansion. Monitoring required for output accuracy, complaints, and override rate.

Example: AI HR Analytics Vendor

Use case:

Vendor AI tool analyzes employee data to identify retention risk.

Key risks:

• employee data
• people-impacting recommendations
• fairness and bias
• legal and HR exposure
• vendor model provider
• human oversight
• transparency
• monitoring

Questions to ask:

• What employee data is used?
• Does the output influence employment decisions?
• What fairness or bias testing exists?
• Is human oversight meaningful?
• Can employees be affected by automated recommendations?
• Does the vendor disclose model limitations?
• What monitoring is available?
• Can the organization audit or challenge outputs?
• Are contract terms sufficient for employee data?

Possible approval:

Not approved for individual employment decisions. Approved only for aggregate analytics pending legal, privacy, HR, and AI governance review. Human oversight, monitoring, and vendor evidence required before any expanded use.

Example: AI Code Assistant Vendor

Use case:

Engineering uses AI coding assistant.

Key risks:

• source code
• secrets or credentials
• vendor training on code
• IP ownership
• insecure code suggestions
• repository integration
• developer misuse
• monitoring

Questions to ask:

• Can vendor train on company code?
• Are prompts and generated code retained?
• Is source code used for model improvement?
• Are enterprise terms different from consumer terms?
• Can secrets be detected or blocked?
• Does tool integrate with repositories?
• Are insecure code suggestions monitored?
• Who owns generated code or output?
• What developer guidance is required?

Possible approval:

Approved for enterprise account only. Vendor training on company code prohibited. Secrets and customer data prohibited in prompts. Developer guidance and monitoring required. Legal and cyber review required before expansion.

Common AI Vendor Risk Mistakes

Mistake 1: Assuming existing vendor approval covers AI

A vendor may be approved for SaaS use but not for AI processing.

AI features can change data, contract, monitoring, and risk requirements.

Mistake 2: Not asking about training

Vendors may use customer data for training, product improvement, or evaluation unless prohibited.

Ask directly.

Mistake 3: Ignoring prompts and outputs

Prompts and outputs can contain personal, confidential, regulated, or sensitive data.

They need retention and deletion terms.

Mistake 4: Ignoring model providers

The SaaS vendor may not be the model provider.

Model-provider involvement should be documented.

Mistake 5: Treating security evidence as enough

Security evidence is important, but it may not answer AI data-use, model, monitoring, or output-risk questions.

Mistake 6: Approving without monitoring

AI vendor risk changes after approval.

Monitoring and reassessment should be part of the approval.

Mistake 7: Letting contract exceptions stay in legal notes

Contract gaps should become issues, approval conditions, or risk acceptances.

Mistake 8: Renewing AI vendors with open issues

Renewal should consider AI-specific open risk.

30-Day AI Vendor Risk Improvement Plan

Days 1–5: Identify AI vendors

Start with:

• vendors with AI features
• vendors processing sensitive data
• vendors supporting high-risk AI use cases
• existing SaaS vendors with embedded AI
• model providers
• AI tools used in pilots

Days 6–10: Add AI vendor fields

Capture:

• AI functionality
• AI use cases
• data used
• model provider
• prompt/output retention
• training rights
• monitoring availability
• contract status
• evidence status
• issues

Days 11–15: Review high-risk vendors

Prioritize vendors that:

• process personal or sensitive data
• affect customers or employees
• provide customer-facing AI
• support regulated processes
• have unclear contract terms
• have unknown model providers
• lack monitoring evidence

Days 16–20: Create issues and conditions

Create issues for:

• missing data-use terms
• missing training restrictions
• unknown prompt/output retention
• expired security evidence
• missing monitoring
• unknown model provider
• weak incident notification

Days 21–25: Connect to approvals and renewals

Link AI vendor issues to:

• AI use case approvals
• vendor renewals
• contract negotiations
• risk acceptances
• production launch decisions

Days 26–30: Build dashboard

Show:

• AI vendors by risk tier
• open AI vendor issues
• sensitive data exposure
• contract gaps
• monitoring gaps
• renewals with open risk
• decisions needed

This creates a practical AI vendor risk foundation quickly.

How Connected GRC Improves AI Vendor Risk

Connected GRC improves AI vendor risk by linking:

• AI use case
• vendor
• model provider
• contract
• data inventory
• privacy review
• cyber review
• legal review
• risk tier
• controls
• evidence
• monitoring
• incidents
• issues
• remediation
• validation
• risk acceptance
• renewal
• dashboard
• decisions

In a disconnected model, AI vendor risk is split across procurement, legal, privacy, cyber, AI governance, vendor risk, and business teams.

In a connected model, each team works from the same source records.

That is how the organization avoids approving an AI vendor while missing the data-use, monitoring, or contract risk that matters most.

A Practical Test for One AI Vendor

Pick one AI vendor.

Ask whether your GRC model can show:

• vendor owner
• contract owner
• AI use cases supported
• business processes affected
• data categories processed
• model provider
• subprocessors
• prompt and output retention
• training rights
• privacy review
• cyber review
• legal review
• vendor evidence
• monitoring capabilities
• human oversight support
• AI incidents
• open issues
• approval conditions
• risk acceptance
• renewal impact
• dashboard status

If answering those questions requires vendor files, contract notes, privacy assessments, AI intake records, cyber tickets, spreadsheets, emails, and meetings, AI vendor risk is not connected enough.

That is common.

It is also the opportunity.

Final Thought

AI vendor risk is not just vendor risk with a new label.

AI vendors can affect data use, model behavior, prompts, outputs, training, monitoring, human oversight, contracts, cyber exposure, incidents, and business decisions.

That is why AI vendor review needs better questions.

What data is used?
Can the vendor train on it?
Who is the model provider?
Are prompts and outputs retained?
What contract terms apply?
What cyber controls exist?
What monitoring is available?
What happens when the model changes?
What incidents must be reported?
What evidence proves the vendor’s controls?
What issues remain open?
What risk is accepted?
Should renewal proceed?

Connected GRC makes those questions operational.

It links the AI vendor to the AI use case, data inventory, contract, privacy review, cyber review, legal review, controls, evidence, monitoring, issues, remediation, risk acceptance, renewal, dashboard, and decisions.

That is how AI vendor risk becomes visible, reviewable, and governable.