What is AI vendor risk management?
By Identra · Updated
AI vendor risk management is the ongoing process of assessing and controlling risk from third-party AI services and AI features added to existing software. It decides which uses are acceptable based on how providers handle company data, what access they receive and what actions their products can take.
How does AI vendor risk management work?
You review a specific product, feature, account tier and use. The vendor's name on an old approval doesn't carry over. Say your CRM passed review before it shipped an AI assistant. That assistant may send content to a model provider your review never looked at, under different retention terms, with new access to files.
Start from what people actually use: browsers, desktop apps, coding agents, connected business systems. Free trials and personal accounts count. A vendor register built from purchase orders never sees shadow AI.
Size the effort to the harm. A grammar checker on public copy gets a short review. An agent that can send mail from a sales rep's mailbox gets the long one.
What should you ask about data use and model providers?
Training and retention are two questions. A no-training commitment doesn't tell you whether prompts, files, outputs or logs are stored, or for how long. Ask about exceptions for abuse monitoring, support access and human review, for the exact tier you're buying. A free ChatGPT account and ChatGPT Enterprise come with different terms.
For the AI data privacy side, follow content from collection to deletion. Who receives it, where it's processed, whether a connector builds a search index. Ask whether the vendor can switch model providers and how you'd find out.
Read the scope of the SOC 2 report before leaning on it. It may cover the vendor's infrastructure and say nothing about how the AI feature handles your content.
Training and improvement
- What to pin down
- Whether content is used for training, evaluation or product improvement, and under which terms and settings
Retention and human access
- What to pin down
- What gets stored, for how long, who can view it and the exceptions
Downstream providers
- What to pin down
- Every party that receives content, including fallback routing
Deletion and exit
- What to pin down
- How uploads and indexes are removed, what copies remain and how you confirm it
How do connectors and agent permissions change vendor risk?
A standalone chat app sees what people paste in. A connected assistant can pull Gmail, Google Drive files, Jira tickets or GitHub code through standing access. An agent can also edit and send. Review each step up on its own.
For OAuth app risk, look at the grants actually issued in Entra ID or the Google Workspace admin console. Which scopes, who consented, and whether the access is delegated from a user or granted to the app itself. Ask for proof that retrieval still respects source permissions after someone's access is removed.
Apply least privilege to each connector. Read is one approval. Send and delete are another. Revoking a connector and deleting what it already copied are also separate steps.
What does a review look like in practice?
Say sales wants to switch on the AI assistant in the CRM you approved last year. It would summarize deals from CRM records and connected Gmail. The original approval covered customer records. Nobody looked at an email connector or the new model provider.
Security checks the requested scopes, then uses synthetic records to see whether one rep can pull another team's restricted deals. Legal and procurement pin down retention and downstream processing. The business owner decides whether summaries need a human check before a customer sees them.
One plausible outcome: the managed workspace and selected CRM objects are approved, email access and auto-send stay off, and the reasons are written down. Turning email on later means a new review.
What belongs on an AI vendor approval checklist?
Specific enough that an admin can configure it and an auditor can follow it. Tie it to an AI risk assessment of the intended use.
- The task, business owner, permitted data classes and what a wrong output or unauthorized action would cost.
- Applicable terms, data flow documents, model provider details and incident notification commitments.
- Managed account access, admin controls, logging, retention settings and connector scopes, checked in the live configuration.
- Tests of restricted-content retrieval, action approvals and access removal with synthetic data.
- Approval conditions, open risks, who decided, and what triggers a fresh review.
- An exit plan covering connector revocation, credential removal, data export and deletion requests.
When should an approved AI vendor be reviewed again?
On a schedule, and whenever something moves. A new model provider. Changed data terms. Wider scopes, new agent actions, an incident, more sensitive data going in. Someone has to own reading the vendor's change notices, or none of these get noticed.
AI governance ties each approval to its conditions. When they stop holding, narrow the use, pull a connector, suspend the feature or drop the vendor. Then confirm access actually ended and deletion actually happened.
How Identra thinks about it
Identra shows which AI apps and accounts people use in the browser, which AI tools run on endpoints and which connected apps hold company data. Connected apps are sorted by what they can reach, from admin rights to data access to sign-in only, and an analyst can revoke risky OAuth grants to keep vendor access in line with what was approved.
Go deeper: AI security, built on identity
Frequently asked questions
How is AI vendor risk management different from standard vendor review?
It adds AI-specific questions: model improvement use, prompt retention, downstream model providers, retrieved content, output reliability and what connected agents are allowed to do.
Does an existing software vendor need another review when it adds AI?
Yes, at least a focused one. Check whether data recipients, terms, permissions or available actions changed from what you approved.
Are no-training terms enough to approve an AI vendor?
No. They cover one use of your data. Retention, human access, downstream processing, connector scopes and deletion still need review.
Does revoking a connector delete the data it collected?
Don't assume it does. Confirm access has ended, then follow the vendor's deletion process for stored content and indexes, and ask what copies remain.
Who owns AI vendor risk management?
A business owner accountable for the intended use. Security, privacy, legal and procurement each review their part, and one named person tracks changes and keeps the approval conditions current.