Most companies already depend on a long list of outside providers. CRM platforms, accounting tools, help desks, HR systems, marketing platforms, agencies, contractors, and software vendors all help the business move faster. Now many of those providers are adding AI features, agents, copilots, summaries, recommendations, and automated workflows.
That can be useful. It can also change the company’s exposure without a new vendor contract or a deliberate security project. A feature that once stored records may now analyze them. A support platform may offer an AI agent that drafts or sends responses. A marketing vendor may connect AI to a shared drive. An outside agency may introduce its own AI tools while working with client data.
Why vendor AI changes the risk
Third-party AI risk is not only about whether a vendor is reputable. It is about the full chain of models, data, plugins, hosting, integrations, and people involved after an AI feature is switched on. OWASP notes that LLM supply-chain vulnerabilities can affect training data, models, deployment platforms, and third-party components. It also identifies unclear data terms and privacy policies as a path for sensitive data exposure. [1]
For a business leader, that means “our vendor has AI” is not enough information. Two vendors can offer the same kind of feature while handling data, permissions, retention, integrations, and incident response very differently. The risk gets higher when the feature connects to customer records, shared files, inboxes, calendars, internal knowledge bases, or a system that can take action.
The company may also have vendors using AI on its behalf. A marketing agency might use an AI writing tool with campaign information. A recruiting partner may use AI to screen resumes. A contractor may connect an assistant to project materials. Those workflows deserve the same visibility as internal AI use because the company’s data and reputation are still involved.
Questions to ask before an AI feature gains access
What business problem is the feature solving?
Ask for one concrete use case. “We want AI” is not a use case. “We want faster first drafts of internal help-center answers” is one. A narrow purpose makes it easier to decide what data and permissions are actually necessary.
What information will the feature receive?
Identify the records, files, prompts, attachments, and systems involved. Does the feature see customer data, employee data, contract details, financial information, credentials, strategy documents, or non-public communications? The data classification should guide the approval decision.
Can the feature take action, or only make a suggestion?
Find out whether the AI can send messages, modify records, publish content, create tickets, update calendars, or trigger automations. A read-only assistant creates a different risk profile than an agent that can act outside the company.
Where do the data and model terms stand today?
Review the vendor’s current privacy, retention, training, subcontractor, and security terms. Do not assume settings are unchanged because the core product has been in use for years. OWASP recommends vetting suppliers and their terms, confirming that operator policies align with the company’s data-protection expectations, and reviewing supplier posture over time. [1]
Who owns the connection and can it be removed?
Every approved AI feature needs a business owner, a technical owner, and a clear off switch. If the owner leaves, the agency relationship changes, or the feature no longer serves its purpose, the company should know who can revoke access and what data remains behind.
Five practical controls for third-party AI risk
1. Add AI to vendor review, not a separate afterthought
Build a few AI-specific questions into the existing purchase, renewal, and vendor-review process. That keeps the conversation connected to contracts, data handling, security, and business ownership rather than leaving it to a product demo.
2. Map vendor connections to high-value data
Focus first on vendors that can reach customer data, financial systems, internal documents, credentials, or public-facing communications. A simple map of what connects where will reveal where the highest-consequence exposure sits.
3. Approve capabilities, not just companies
Being an approved vendor should not mean every new AI feature is automatically approved. Review material changes such as new agent actions, expanded data access, new plugins, or a change in where the model is hosted.
4. Use contracts and settings to reinforce the decision
Where appropriate, confirm data-use limits, retention expectations, incident notification, subcontractor terms, and the right to disable access. Then verify that the account configuration and permissions reflect the decision. A contract is useful, but it does not fix an overly broad connection already in production.
5. Revisit the most important vendors on a schedule
CISA’s guidance on externally developed AI systems highlights the need for controls that protect, detect, and respond to malicious activity involving AI systems and their related data and services. [2] A recurring review of key AI-enabled vendors is a practical way to notice changed features, changed terms, or changed access before they become an incident.
A practical next step for a company without a vendor-risk team
Do not try to review every vendor at once. Start with the five relationships that hold the most sensitive information or connect most deeply to operations. Ask whether each vendor has an AI feature in use, what it can access, whether it can act, who owns the connection, and how it can be turned off.
That short exercise will give leadership a clear list of follow-ups. Some tools may need no change. Others may need a lower permission level, a revised setting, a business owner, or a conversation with the provider. The goal is not to avoid outside AI. It is to keep vendor innovation from quietly becoming unowned exposure.
Need a vendor AI inventory?