AI Vendor Risk: What to Review Before Renewing Enterprise Software
Enterprise software vendors are embedding AI into CRM, HR, IT, and productivity platforms. Learn how procurement and legal teams can protect corporate data, IP, and operational control.
Lewis Ho
Most companies license their core business software. Sales teams work in Salesforce. HR teams work in Workday. Finance, legal, operations, and knowledge workers depend on Microsoft, Oracle, ServiceNow, SAP, Adobe, and hundreds of specialized SaaS providers.
That model has always created procurement, cybersecurity, privacy, and vendor-management obligations. Artificial intelligence adds a new layer of complexity:
A company may acquire new AI capabilities without making a separate AI purchase.
The capability may arrive through a product update, an enabled feature, an add-on, a marketplace application, a new connector, or revised service documentation. An employee may discover that a familiar platform can now summarize records, generate content, retrieve internal data, recommend decisions, or execute workflows.
The enterprise may not have built the model. It may not have selected the underlying provider. It may not even have realized that the vendor’s product had become an AI system.
Yet the company may still be responsible for how the capability handles corporate information, customer data, confidential documents, employee records, and intellectual property. This changes the nature of AI governance.
The immediate risk is not only a software-development problem but a procurement and supply-chain problem.
The Enterprise AI Supply Chain is Already Here
AI risk can enter an organization through multiple channels:
a core SaaS platform;
a customer-service application;
an HR or recruitment tool;
a productivity suite;
an analytics product;
a cloud service;
an embedded chatbot;
an API integration;
a browser extension;
an acquired company’s software;
or a third-party contractor using an AI-enabled service.
The vendor may describe the feature as an assistant, copilot, insight, automation, recommendation, agent, or productivity enhancement. The label matters less than the system’s actual behavior.
Executives should ask:
What information does the feature access?
Which model or models process that information?
Is the data retained?
Is it used for training, evaluation, or product improvement?
Which subprocessors receive it?
Can the feature make decisions or take action?
Can the customer disable it?
Does it inherit existing user permissions?
What happens when the vendor changes the feature?
These are procurement questions because the answers may be determined by the vendor’s architecture, contract, service descriptions, privacy documentation, and change-management process.
NIST’s AI Risk Management Framework expressly addresses risks arising from third-party software, data, and other supply-chain relationships. Its guidance calls for supplier-risk assessments, inventories of third-party AI resources, contractual rights to evaluate vendor practices, and contingency processes for failures involving high-risk third-party AI systems.
The message for senior management is clear:
If a vendor adds AI to a system that already holds the company’s data, the enterprise has acquired a new risk surface, even if procurement did not open a new project.
AI Features Can Change the Risk Profile of Familiar Software
Enterprise leaders often think of vendors in categories: CRM, HR, productivity, finance, service management, or collaboration. AI cuts across those categories.
A CRM platform may generate sales summaries, prioritize leads, recommend next actions, or allow agents to interact with customer records. Salesforce’s current documentation describes Agentforce as a platform for autonomous agents that can reason, plan, and execute multi-step tasks across Salesforce and external systems. Its security documentation also explains that administrators remain responsible for configuring access, permissions, and agent-specific guardrails.
A productivity suite may retrieve information from email, documents, calendars, chats, and collaboration spaces. Microsoft states that Microsoft 365 Copilot’s data access is scoped to the signed-in user’s existing permissions and that it can use content the user is authorized to access through Microsoft Graph.
An HR platform may introduce AI features that analyze workforce data, generate recommendations, or support decisions affecting employees and candidates. Workday describes its AI agents as configurable through an agent system of record and says its AI is designed to augment human workers.
An IT service-management platform may add AI governance consoles, AI asset inventories, policy controls, usage analytics, and agentic capabilities. ServiceNow’s documentation describes governance tools intended to manage AI across its lifecycle and emphasizes the need to assess readiness before deploying generative or agentic AI.
These vendor statements are not evidence that the products are unsafe. They demonstrate a different point: the capabilities of ordinary enterprise platforms are expanding rapidly.
A vendor renewal that once focused on uptime, cybersecurity, service levels, and data processing may now need to address:
model providers;
training and retention;
prompt and output handling;
agent permissions;
data grounding;
external connectors;
automated actions;
auditability;
intellectual-property rights;
and unilateral feature changes.
The Hidden AI Problem is Often an Inventory Problem
Many companies maintain software inventories. Fewer maintain an inventory of AI capabilities embedded in those products. That distinction matters.
A software inventory may tell the CIO that the enterprise uses a particular CRM platform. It may not reveal that:
a generative-writing feature is enabled;
customer records are being used to ground responses;
a vendor has introduced an AI agent;
an external model provider is involved;
a new connector can retrieve information from another system;
employees can upload confidential files into an AI feature;
or the vendor has changed the terms governing prompts and outputs.
The first control is therefore visibility.
The enterprise should create an AI capability register covering material vendors and platforms. The register should identify:
vendor and product;
AI feature or service name;
business owner;
technical owner;
deployment status;
data categories involved;
model provider;
subprocessors;
user population;
internal, external, or public-facing use;
decision or action capability;
retention and training position;
geographic processing locations;
customer configuration options;
audit and logging capability;
contract documents;
and next renewal date.
The register should not be limited to products marketed primarily as AI. It should include any third-party system that can generate, infer, classify, recommend, retrieve, or act using enterprise information.
Corporate Intellectual Property Is Not Limited To Source Code
When executives hear “AI and intellectual property,” they may think first about source code or trade secrets. Those are important, but the exposure is broader. Corporate intellectual property may include:
source code and technical documentation;
product roadmaps;
engineering specifications;
pricing models;
customer lists;
sales strategies;
contract terms;
legal analysis;
research and development materials;
marketing plans;
proprietary methodologies;
internal policies;
investment and acquisition information;
employee-created materials;
and confidential business knowledge embedded in databases and documents.
AI features may process more than the user intentionally submits. A prompt can be grounded with account records, documents, messages, metadata, or retrieved context. An agent may also write information into logs, conversation histories, analytics systems, or vendor support environments.
The key procurement question is not simply:
“Does the vendor train its public model on our data?”
That question remains important, but it is incomplete.
The enterprise should also ask:
Is customer content used to train a private or global model?
Is it used for evaluation, safety testing, or service improvement?
How long are prompts, files, outputs, and telemetry retained?
Are human reviewers or support personnel able to access the content?
Can the vendor combine the data with information from other customers?
Are prompts and outputs treated as customer content under the contract?
Who owns generated outputs?
Does the vendor claim rights to use feedback?
Can the customer delete or export the relevant content?
What happens to the data after termination?
Vendor assurances can differ by product, edition, feature, model provider, and configuration. Salesforce, for example, provides product-specific information about Einstein data usage and explains that some features may involve global models, with customer controls that may allow opting out.
Workday states that it does not share customer data to train third-party public models and describes controls intended to provide customers with visibility into how data is used.
These statements should be reviewed carefully. They do not eliminate the need for enterprise diligence. They show why the relevant question is always feature-specific:
What happens to our data in this product, under this configuration, with this model provider, in this jurisdiction?
The Vendor’s AI terms May Not Match the Enterprise’s Risk Appetite
Enterprise contracts often contain general language covering confidentiality, security, data processing, and service providers. Those provisions may not address the operational realities of AI. An AI feature may introduce:
a new model provider;
a new subprocessor;
a new data flow;
a new category of telemetry;
a new retention period;
a new use of customer content;
a new automated-decision capability;
or a new ability to access connected systems.
The customer may learn about the change through release notes or updated online documentation rather than through a negotiated contract amendment.
That creates a governance question:
Can the vendor materially expand AI processing or functionality without giving the customer meaningful notice, objection rights, or an ability to disable the feature?
The answer may depend on the master agreement, order form, data-processing addendum, product terms, acceptable-use policy, privacy documentation, and service-specific terms.
A serious vendor review should examine the entire contractual package rather than relying on a sales presentation or a single AI addendum.
What Procurement Should Ask Before a Renewal
Before renewing a material enterprise software contract, procurement should require the vendor to complete an AI capability disclosure. The disclosure should cover five areas.
1. Capability
What AI features exist today? Which are planned? Which are enabled by default? Which can be activated by administrators or individual users?
The vendor should distinguish between:
generative features;
predictive models;
recommendation systems;
retrieval and search;
workflow automation;
autonomous agents;
and features that can make or execute decisions.
2. Data
What customer data does each feature access, infer, store, transmit, or generate?
The answer should identify:
structured and unstructured data;
prompts;
uploaded files;
retrieved context;
outputs;
metadata;
logs;
telemetry;
feedback;
and support materials.
The vendor should explain whether data remains within the customer’s environment, the vendor’s service boundary, or a third-party model provider’s environment.
3. Model and subprocessor chain
Who develops and operates the model?
The enterprise should understand:
the model provider;
hosting locations;
subprocessors;
cross-border transfers;
model versioning;
open-source components;
fine-tuning arrangements;
and the vendor’s right to change providers.
A vendor may present the application as a single service even though the underlying AI supply chain contains several entities.
4. Authority
What can the AI system do?
The review should distinguish between read access and action capability.
Can the feature:
retrieve confidential information;
change records;
send messages;
approve workflows;
create tickets;
trigger payments;
modify permissions;
execute code;
or call external APIs?
Salesforce’s documentation illustrates why this distinction matters: Agentforce agents are designed to execute multi-step tasks, while the platform’s security model depends on administrator configuration of access and guardrails.
5. Change management
How can the vendor change the AI feature?
The enterprise should ask:
Does a model change require notice?
Can new AI capabilities be activated automatically?
Can the vendor add a new subprocessor?
Is there a customer right to disable or reject material changes?
Does the customer have a termination right?
Are security and privacy documentation updated?
Are new AI capabilities subject to testing before release?
A system may remain contractually “the same product” while its practical behavior changes significantly.
The AI Vendor-Renewal Scorecard
A simple scorecard can help procurement, legal, security, privacy, and business owners apply a consistent standard.
This scorecard is not intended to replace technical testing or legal review. Its purpose is to prevent AI questions from disappearing inside a generic software-procurement checklist.
Contract provisions that deserve closer attention
The exact wording will depend on the transaction and applicable law, but enterprise buyers should consider whether the contract addresses the following issues.
Customer data and confidential information
The agreement should define customer content broadly enough to include prompts, uploaded materials, retrieved context, outputs, metadata, logs, and other information generated through AI use.
Purpose limitation
The vendor should use customer content only to provide, secure, support, and improve the contracted service to the extent expressly agreed. Any use for model training, benchmarking, or cross-customer product development should be clearly addressed.
Intellectual-property ownership
The contract should specify ownership and permitted use of:
customer inputs;
generated outputs;
fine-tuned models;
prompts and templates;
feedback;
derived data;
and vendor-created improvements.
The enterprise should not assume that a general “customer owns its data” clause resolves every AI-related ownership question.
Model and subprocessor transparency
The vendor should identify relevant model providers and give the customer notice of material changes. The agreement should address approval, objection, audit, and termination rights where appropriate.
Security and access controls
The vendor should describe how AI features enforce customer permissions, separate tenants, protect data, manage credentials, restrict tools, and log material actions.
Microsoft’s documentation, for example, states that Copilot access is constrained by the user’s existing permissions. That type of architecture-level detail is more useful to enterprise buyers than a general promise that the product is “secure.”
Incident response
The agreement should address incidents involving:
unauthorized disclosure;
inaccurate or harmful outputs;
model compromise;
prompt injection;
improper access;
data poisoning;
AI-generated code;
or automated actions outside approved scope.
Audit and evidence
The customer may need access to sufficient information to investigate an incident, assess compliance, and reconstruct material AI activity. This could include audit reports, model or feature documentation, logs, data-flow information, and incident records.
Disablement and termination
The enterprise should be able to disable a material AI feature, suspend an agent, or terminate a particular AI capability where the risk becomes unacceptable.
“No Training” Is Not the Finish Line
One of the most common procurement questions is whether the vendor uses customer data to train its models. That is the right question but it should be one question in a larger review.
A vendor may not train a public model on customer content while still:
retaining prompts and outputs;
using data for abuse monitoring;
allowing support access;
sharing information with subprocessors;
storing content in logs;
using content for evaluation;
creating derived insights;
or enabling employees to retrieve information through an AI interface.
The enterprise must distinguish among:
model training;
model evaluation;
service improvement;
safety monitoring;
analytics;
personalization;
retrieval;
and storage.
These uses can carry different IP, privacy, confidentiality, and security implications.
Procurement Should Test The Configuration, Not Just The Contract
Written terms are necessary. They are not sufficient.
A vendor may offer configuration controls that are disabled by default, limited to a particular product edition, or available only to administrators. A contractual promise may also depend on the customer properly configuring permissions, data spaces, retention, or feature settings.
Salesforce’s documentation describes governance controls across identity, data access, APIs, and AI interactions, while ServiceNow describes readiness assessments, data separation, and ongoing governance for AI deployments.
Enterprise buyers should therefore test the product in a controlled environment.
The review should confirm:
which data the feature can retrieve;
whether it respects existing permissions;
what happens when a user changes roles;
whether prompts and outputs appear in logs;
whether administrators can disable the feature;
whether agents can call external tools;
whether records can be changed;
whether sensitive data is masked;
and whether the customer can export or delete AI-related content.
The objective is to verify that the vendor’s contractual and technical descriptions match actual behavior.
What Buyers Can Do When Vendors Refuse Custom AI Terms
Large SaaS providers often rely on standardized contracts and may reject customer-specific AI addenda, particularly for mid-market customers. That does not mean the buyer has no leverage. It means risk mitigation must extend beyond contract negotiation.
The first step is to treat the vendor’s AI features as configurable capabilities rather than an all-or-nothing product decision.
Use administrator-level kill switches
Confirm whether administrators can disable:
generative AI features;
autonomous agents;
external connectors;
data grounding;
prompt and file uploads;
automated record updates;
model training or product-improvement features;
and user access to AI functionality.
These controls should be documented, assigned to named administrators, and tested periodically. A feature that can be disabled in theory but cannot be switched off quickly during an incident is not an effective control.
Restrict data at the API and integration layer
If the vendor cannot provide satisfactory contractual limits, reduce the information the AI feature can access.
Practical measures include:
limiting API scopes to the minimum required;
creating separate service accounts;
excluding confidential fields from API payloads;
masking personal or sensitive data;
blocking unrestricted exports;
restricting access to selected objects, records, or document libraries;
applying data-loss-prevention rules;
and separating high-value intellectual property from general business data.
The objective is to ensure that the vendor’s AI capability cannot retrieve information that it does not need for the approved business purpose.
Separate high-risk data from ordinary workflows
Do not assume that existing user permissions create an appropriate AI boundary. A user may legitimately access information for one business purpose without being authorized to expose that information to a vendor-hosted AI feature.
Where appropriate, create dedicated data spaces, restricted workspaces, separate tenants, or approved repositories for AI-enabled workflows. Keep source code, trade secrets, acquisition materials, legal strategy, highly sensitive employee data, and regulated information outside general-purpose AI retrieval environments unless the use case has received enhanced review.
Control connectors and outbound actions
Review every connector, plug-in, marketplace application, and external API connected to the SaaS platform. Disable integrations that are not essential. Where possible, use allowlists, transaction limits, approval gates, and read-only access.
For agentic functionality, distinguish clearly between:
retrieving information;
drafting an action;
requesting approval; and
executing the action.
A vendor’s default configuration should not be allowed to determine the enterprise’s risk appetite.
Create a compensating-control record
If the vendor will not amend its contract, document:
which requested protections were unavailable;
the resulting risk;
the technical and administrative controls adopted instead;
the business justification;
the residual risk owner;
and the conditions under which the feature must be disabled.
This record helps demonstrate that the enterprise identified the limitation and responded deliberately rather than accepting the vendor’s standard terms without review.
Use commercial leverage beyond the legal addendum
A buyer may have more leverage than it initially assumes through:
renewal timing;
expansion commitments;
product adoption decisions;
reference-customer participation;
security-review requirements;
procurement approval;
and the ability to exclude specific AI features from the order or implementation.
The buyer should request, at minimum, written confirmation of the vendor’s standard AI position, applicable configuration controls, model and subprocessor changes, data-use practices, and disablement procedures. Even where the vendor will not negotiate, the responses create an evidence trail for the procurement decision.
Establish a renewal trigger
AI functionality should be included in the vendor-renewal process rather than treated as a one-time review. A new model, agent, connector, data-use purpose, subprocessor, or automated action should trigger reassessment before activation.
The practical principle is:
When contract leverage is limited, reduce the system’s technical authority, restrict the data it can reach, and document the residual risk that management has accepted.
Standard vendor terms do not eliminate the buyer’s responsibility to configure, monitor, and govern the system. But disciplined configuration can significantly reduce exposure when bespoke contractual protections are unavailable.
A Practical Operating Model for Vendor AI Risk
A strong vendor AI review usually requires participation from:
procurement;
legal;
privacy;
information security;
enterprise architecture;
data governance;
records management;
intellectual-property counsel;
the business owner;
and, for high-impact uses, internal audit or executive risk leadership.
The business owner explains why the feature is needed. Procurement manages the commercial relationship. Legal evaluates rights and obligations. Security assesses architecture and controls. Privacy reviews personal-data use. Data governance examines access and retention. The executive owner decides whether residual risk is acceptable.
This is consistent with NIST’s lifecycle approach, which treats third-party AI risk as something to govern, map, measure, and manage throughout acquisition, deployment, operation, monitoring, and change.
The Questions Executives Should Ask at Renewal
Before approving a renewal involving material AI-enabled functionality, senior management should ask:
Which AI capabilities are embedded in the products we already use?
Which capabilities were introduced or materially changed since the last renewal?
What enterprise data can each capability access?
Is any customer content used for training, evaluation, service improvement, or cross-customer analytics?
Which model providers and subprocessors are involved?
Can the AI make recommendations only, or can it take action?
Can the enterprise disable the feature without abandoning the entire platform?
Do our contracts address prompts, outputs, derived data, model changes, and AI incidents?
Can we reconstruct what the AI accessed and did?
What happens to our data and intellectual property when the contract ends?
If management cannot answer these questions, the issue is not necessarily that the vendor is unacceptable.
The issue is that the enterprise does not yet understand the system it is buying.
Conclusion: Procurement is now part of AI governance
Enterprise AI risk does not begin when an internal developer trains a model.
It may begin when a familiar vendor adds an AI capability to a platform that already contains the company’s most valuable information.
That makes procurement a central AI-governance function.
The enterprise must know what vendors are adding, what data those features use, which parties process the information, what the AI can do, how the capability can change, and whether the company can control or exit the relationship.
NIST’s AI guidance recognizes that third-party software, data, models, and services can increase both the value and the opacity of an AI system. The appropriate response is not to reject every vendor-enabled AI feature. It is to establish a repeatable supplier-risk process that addresses data, intellectual property, security, authority, transparency, monitoring, and contingency planning.
The most important executive shift is conceptual:
AI governance is not only about what the enterprise builds. It is also about what the enterprise buys, renews, enables, and allows into its data environment.
The next time a vendor presents an AI enhancement as a routine product improvement, leadership should ask a more consequential question:
What new authority, data access, and intellectual-property exposure are we accepting by turning it on?
That is where responsible AI procurement begins.
1. What is an AI vendor-renewal scorecard?
An AI vendor-renewal scorecard is a practical review tool that helps procurement, legal, security, privacy, and business teams evaluate AI capabilities embedded in third-party software. It assesses data use, model providers, intellectual-property rights, access permissions, security, human oversight, change management, and the ability to disable or exit the service.
2. What should enterprises ask vendors before renewing AI-enabled software?
Enterprises should ask which AI features are available or enabled, what prompts and business data are processed, which model providers and subprocessors are involved, whether customer content is used for training or product improvement, who owns inputs and outputs, what actions the AI can perform, how activity is monitored, and how the customer can disable the feature or recover its data.
3. What should a company do if a SaaS vendor refuses a custom AI addendum?
If a vendor will not negotiate custom AI terms, the buyer should apply compensating controls. These may include disabling AI features at the administrator level, restricting data feeds through API permissions, masking sensitive fields, separating confidential intellectual property into restricted environments, limiting external connectors, requiring human approval for consequential actions, and documenting the remaining risk and its authorized owner.