The Starting Point
The AI vendor problem is no longer "which tools did procurement approve?" It is "what AI systems are already touching the business?"
Traditional vendor inventory assumes the company knows what it bought. AI breaks that assumption. Employees can adopt AI tools directly, teams can activate AI features inside existing SaaS products, developers can call model APIs, and agents can connect to data sources and action-taking tools without creating a clean procurement event.
Netskope's 2025 Generative AI Cloud and Threat Report found that 90% of organizations had users directly accessing GenAI apps such as ChatGPT, Gemini, and GitHub Copilot, while 98% had users accessing apps with GenAI-powered features.1 That second number is the inventory trap: many AI vendors do not look like AI vendors at all. They look like CRM, HR, design, collaboration, support, productivity, data, or developer tools with an AI feature turned on.
Torii's 2026 benchmark reported that the average enterprise runs more than 830 applications, with 61.3% of discovered applications qualifying as shadow IT and only 15.5% formally sanctioned.2 The AI version of that sprawl has a bigger blast radius because the tool may ingest proprietary content, call APIs, use OAuth scopes, retain prompts, train on inputs, route work to a subcontractor, or create outputs that enter business systems.
The goal of AI vendor inventory is not to freeze adoption. It is to make adoption observable enough to govern: known vendor, known product, known AI behavior, known owner, known data class, known contract posture, known permissions, known model route, known risk, known spend, and known evidence.
Annual questionnaires cannot keep up with AI tools, embedded features, browser extensions, model APIs, and agents.
A vendor is not risky in the abstract. Risk depends on account type, data class, permissions, usage, model route, and workflow.
The useful output is approve, restrict, replace, consolidate, monitor, educate, renegotiate, or remove.
Operating Model
The five-layer model for AI vendor inventory.
A useful AI vendor inventory is more than a list of company names. It is a graph that connects vendors to the AI work they support. Each layer answers a different question: what exists, what it does, what it touches, who owns it, and what decision should happen next.
NIST SP 800-161 Rev. 1 frames supply-chain risk as a visibility problem: organizations need to understand how acquired technology is developed, integrated, deployed, secured, and maintained.5 AI vendor inventory brings that same discipline to model providers, SaaS AI features, agent infrastructure, data connectors, and autonomous tools.
Find every AI surface
Normalize vendor and product
Data, model, action, risk
Assign accountable team
Approve, restrict, review
The model should be designed for change. A vendor record may start as "unknown AI app seen in browser traffic." Then it becomes "ChatGPT personal account used by Growth." Then it becomes "approved ChatGPT Enterprise workspace with DPA, SSO, disabled training, marketing copy only, no customer PII." The inventory system has to preserve that journey instead of overwriting the messy parts.
Finance knows there is spend, but not whether AI is enabled, used safely, or duplicated elsewhere.
Security knows the vendor passed a point-in-time review, but not how the product is being used today.
The record shows users, teams, AI features, models, data flows, permissions, costs, controls, and outcomes.
Scope
Count every AI surface, not only every AI-branded vendor.
Many organizations miss AI vendors because they search only for obvious AI brands. The actual inventory has to include both direct AI products and the AI surfaces embedded inside normal business software.
Netskope reported that it tracked 317 distinct GenAI apps across its customer base, while also noting that apps with GenAI features were even more widespread than direct GenAI apps.1 That distinction should shape the inventory taxonomy.
| Inventory Category | What To Capture | Why It Matters |
|---|---|---|
| Foundation model providers | OpenAI, Anthropic, Google, Meta, Mistral, Cohere, DeepSeek, cloud-hosted model endpoints, private deployments. | Model route determines data handling, cost, latency, region, capability, retention, and risk posture. |
| AI-native applications | Chatbots, coding assistants, writing tools, image/video generators, research assistants, meeting summarizers. | These are often adopted by employees before procurement, with personal accounts and unclear retention settings. |
| Embedded AI in SaaS | CRM copilots, HR summarizers, ticketing assistants, BI explainers, support automation, product analytics AI. | Existing vendors can become AI processors without a new purchase or a visible launch event. |
| Agent infrastructure | Agent platforms, orchestration frameworks, MCP servers, plugins, tool registries, workflow automation layers. | Agents expand the vendor record from "system that answers" to "system that can act." |
| Data and retrieval providers | Vector databases, document stores, knowledge bases, search indexes, feature stores, warehouses, third-party APIs. | Retrieval changes what data AI can use and whether outputs can expose restricted information. |
| Open-source and local models | Downloaded weights, local inference servers, container images, fine-tuned variants, benchmark and eval tooling. | Open-source does not eliminate vendor risk; it shifts it to provenance, patching, hosting, access, and lineage. |
| Extensions and connectors | Browser extensions, OAuth apps, Slack bots, plugins, API keys, service accounts, data syncs. | Small connectors can create large access paths into email, files, calendars, code, CRM, and customer data. |
Discovery
The best inventory programs combine procurement records with behavioral discovery.
Procurement data is necessary, but it is incomplete. The AI systems that create the most urgent governance questions are often the ones that never went through procurement: personal GenAI accounts, OAuth-connected AI apps, developer API keys, local models, browser extensions, team-purchased tools, and AI features inside existing systems.
Torii's 2026 report says traditional benchmarks based on contracts or SSO integrations miss real-world adoption, and describes discovery across browser activity, OAuth-connected apps, direct sign-ups, and AI-native tools.2 That is the right mental model: inventory should be assembled from multiple weak signals until they resolve into one strong record.
System Record
A vendor record should describe the AI system, not just the supplier.
The core object should be precise enough that security, legal, finance, data, engineering, and business owners can make decisions without reconciling separate spreadsheets. A single vendor may have multiple products, account types, model routes, data processors, regions, contracts, risk tiers, and owners.
ISO/IEC 42001 defines an AI management system as the policies, objectives, and processes an organization uses for responsible development, provision, or use of AI systems.6 NIST's AI Risk Management Framework is similarly intended to help organizations incorporate trustworthiness considerations into the design, development, use, and evaluation of AI products, services, and systems.11 A practical inventory record is the data structure that lets that management system operate.
| Record Field | Minimum Useful Detail | Decision It Enables |
|---|---|---|
| Vendor and product | Legal vendor, product, AI feature, model provider, subprocessor, version, deployment mode. | Resolve duplicates, subsidiaries, embedded features, and provider chains. |
| AI behavior | Summarization, generation, classification, coding, retrieval, recommendation, autonomous action, decision support. | Decide whether the product is low-risk assistance or a governed AI system. |
| Usage | Users, teams, business process, active sessions, prompts, uploads, API calls, agents, workflows. | Separate shelfware from operational dependency and shadow experimentation. |
| Data context | Data classes, PII, PHI, source code, customer content, secrets, retention, training rights, residency. | Route privacy, security, legal, data, and compliance review correctly. |
| Permissions | OAuth scopes, API keys, service accounts, write actions, admin rights, external destinations. | Control blast radius and detect excessive agency. |
| Governance status | Approved, pending, restricted, exception, deprecated, blocked, owner, next review date. | Turn inventory into a work queue rather than a static catalog. |
| Commercial posture | Contract, DPA, renewal date, pricing model, usage-based costs, license utilization, alternatives. | Consolidate spend and negotiate from observed adoption. |
| Evidence | Review packet, policy decision, approver, audit log, incidents, vendor documents, exceptions. | Answer customer, auditor, regulator, and internal review questions quickly. |
Risk Taxonomy
AI vendor risk is a combination of data, permissions, autonomy, maturity, and concentration.
The same AI vendor can be acceptable for one workflow and unacceptable for another. A writing assistant for public blog drafts is not the same risk as a personal account summarizing support transcripts. A read-only analytics assistant is not the same risk as an agent that can update CRM, create tickets, trigger incidents, or initiate payments.
OWASP's LLM guidance highlights supply-chain vulnerabilities, insecure plugin design, sensitive information disclosure, and excessive agency as distinct LLM application risks.7 Vendor inventory should make those risks queryable instead of leaving them as abstract categories.
Ownership
Every AI vendor needs a business owner, a technical owner, and a control owner.
Vendor inventory fails when "owner" means the person who bought the tool once. AI systems need operating ownership because model behavior, data access, cost, feature flags, and permissions can change after procurement. Ownership has to answer who benefits, who can change configuration, who approves risky use, who gets the alert, who pays, and who can shut it down.
IBM found that only 34% of breached organizations with AI governance policies performed regular audits for unsanctioned AI.4 That is an ownership problem as much as a policy problem. If no one is accountable for reviewing the long tail, the long tail becomes the risk surface.
Defines approved use cases, value, target users, alternatives, and whether the vendor should scale or retire.
Manages SSO, permissions, integrations, API keys, MCP servers, data connectors, model route, and quotas.
Defines review cadence, data controls, monitoring, exceptions, evidence, incident response, and deprecation criteria.
The owner model should follow lifecycle states. "Detected" means someone has to identify the vendor. "Pending" means review is in progress. "Approved" means there is a documented use boundary. "Restricted" means the vendor can be used only under specific conditions. "Deprecated" means the replacement path is known. "Blocked" means attempts still need to be tracked because demand has not disappeared.
Data and Permissions
Inventory has to capture what data the vendor can see and what the AI system can do.
The most important vendor question is not "is this company safe?" It is "what does this AI surface see, remember, transform, send, and change?" That requires linking vendor records to data classes, OAuth scopes, API keys, service accounts, model routes, regions, retention rules, training rights, and output destinations.
Netskope reported that the amount of data sent to GenAI apps in prompts and uploads increased more than 30-fold over a year, from 250 MB per month to 7.7 GB on average, with source code accounting for nearly half of observed data policy violations.1 Vendor inventory that ignores prompt and upload behavior is blind to the data movement that matters most.
Cisco's 2026 Data and Privacy Benchmark Study found that 90% of organizations said their privacy programs expanded because of AI, and 93% planned to allocate more resources into privacy and data governance over the next two years.8 AI vendor inventory is where that privacy work becomes operational: data category, purpose, location, retention, contract posture, and proof.
| Question | Inventory Field | Decision |
|---|---|---|
| Can the vendor train on our data? | Training use, retention, opt-out status, enterprise setting, contract clause. | Approve, require contract, disable feature, or restrict data class. |
| Can the AI access customer data? | Data class, source, access path, user group, workflow, row-level permissions. | Require DPA, security review, privacy review, DLP, and monitoring. |
| Can the AI write to systems? | Tool permissions, OAuth scopes, API endpoints, service account, approval requirement. | Set least privilege, human approval, quota, rollback, and alerting. |
| Can outputs leave the company? | Destination, recipient, public/private channel, customer impact, review state. | Require review, watermark, logging, retention policy, or external-send block. |
Agents and Tools
Agentic AI turns vendor inventory into dependency management.
Agentic AI changes inventory because the AI system is no longer just a product someone opens. It can be an actor that uses credentials, calls tools, reads data, writes records, and triggers downstream work. That means the vendor record has to show dependencies: which agents use which model, which MCP server exposes which tools, which data source is mounted, and which owner gets paged when something fails.
Okta's 2026 Businesses at Work research found that 91% of organizations reported using AI agents, but only 10% reported a well-developed strategy to manage them. It also reported 650% year-over-year growth in centrally managed service accounts and said access requests per company more than doubled in the past year.3 That is the inventory signal: AI vendors are now tied to non-human identities, not just human users.
Provider, version, context window, region, price, fallback route, approval state, and deprecation plan.
MCP server, transport, auth method, callable functions, quotas, uptime, owner, and version history.
Read, write, send, delete, pay, create, update, search, retrieve, trigger, or escalate with policy controls.
Without dependency inventory, agent risk becomes invisible. A vendor that looks like a safe summarization product can become a high-risk system if it gets a connector to source code, customer support transcripts, HR data, or payment operations. A tool that is harmless in a sandbox can be dangerous in production. A service account that was fine for one workflow can become over-privileged when reused by another agent.
Review
Procurement should become a routing system, not a bottleneck.
The wrong response to AI vendor sprawl is to force every AI-related request through the same heavyweight review. That drives teams back to personal accounts. The better approach is tiered routing: low-risk tools move quickly with standard conditions, medium-risk tools get targeted review, and high-risk tools require executive, security, legal, privacy, data, or model-risk approval.
The EU AI Act's deployer obligations for high-risk AI systems include using systems according to instructions, assigning competent human oversight, monitoring operation, managing input data, keeping logs, and informing providers and authorities of risks or incidents.9 Those obligations require an inventory that knows which systems are high-risk, who deploys them, where logs live, who monitors them, and what instructions apply.
| Review Tier | Typical Vendor Use | Expected Route |
|---|---|---|
| Fast-track | Approved vendor, enterprise account, public/internal data only, no write actions, standard contract. | Auto-approve within policy, attach owner, set review date, log evidence. |
| Targeted review | New AI feature, confidential data, broad read access, unmanaged integration, usage-based cost exposure. | Route to security, privacy, data owner, finance, or business approver based on detected condition. |
| High-risk review | Regulated data, customer-impacting decision support, autonomous action, high-risk AI Act use case, critical workflow. | Require model-risk review, human oversight plan, incident path, logs, rollback, and executive accountability. |
| Block or migrate | Personal account with sensitive data, prohibited vendor, unknown retention, excessive OAuth scopes, unsafe tool. | Block, coach, revoke, migrate to approved option, notify owner, preserve evidence. |
Cost and Consolidation
AI vendor inventory is also a finance control.
AI spend fragments across seats, add-ons, model APIs, token consumption, cloud inference, agents, data infrastructure, credits, pilots, and employee expense reports. Without inventory, finance sees invoices and procurement sees contracts, but no one sees whether the organization is paying for duplicate capabilities, idle licenses, uncontrolled token spend, or unmanaged vendor proliferation.
Torii's 2026 benchmark found that the average employee interacts with 40 applications and that large enterprises average 2,191 applications.2 AI makes that problem sharper because teams often buy overlapping tools for writing, summarization, coding, research, meeting notes, image generation, automation, analytics, and support.
Users, prompts, uploads, API calls, agents, workflow runs, seats, and dormant accounts by vendor and team.
Multiple vendors solving the same job, multiple account types for one product, parallel pilots, and unmanaged add-ons.
Consolidate to approved vendors, renegotiate from usage, deprecate low-value tools, and redirect demand.
The key is to connect spend to observed behavior. A vendor with high cost and high workflow depth may be worth expanding. A vendor with low usage, risky data handling, and overlapping functionality should be challenged. A blocked vendor with repeated attempted usage is not just a security issue; it is product feedback that approved alternatives may not be meeting the need.
Evidence
The inventory should answer audit questions without a scramble.
AI vendor inventory is increasingly part of customer trust, procurement, privacy, security, and regulatory readiness. Customers want to know what AI vendors touch their data. Security wants to know what access exists. Legal wants contracts and subprocessors. Privacy wants purpose and retention. Auditors want evidence that reviews happened. Executives want to know which risks remain open.
Stanford HAI's 2026 AI Index reports that documented AI incidents rose to 362 in 2025, up from 233 in 2024, and that organizations are formalizing responsible AI work while knowledge, budget, and regulatory uncertainty still slow implementation.10 Evidence is the bridge between responsible AI intent and operational proof.
| Question | Evidence The Inventory Should Produce |
|---|---|
| Which AI vendors process customer data? | Vendor, product, feature, data class, contract, DPA, subprocessor, region, retention, owner, review date. |
| Which AI systems can take action? | Agent, tool, MCP server, permission, OAuth scope, service account, quota, approval rule, audit log. |
| Which vendors are pending or restricted? | Status, reason, detected usage, owner, risk tier, review route, due date, compensating control. |
| Which systems are covered by customer review? | Evidence packets by framework, product, data class, business process, policy, control, and approver. |
| What changed since last quarter? | New vendors, new AI features, new model routes, new data sources, new tools, spend changes, incidents, deprecations. |
Common Mistakes
The failures are predictable, which means they are preventable.
- Starting with procurement only. Procurement sees approved contracts, not personal accounts, embedded AI features, free tiers, OAuth apps, developer keys, or local models.
- Treating vendor risk as one static score. AI risk changes by workflow, data class, account tier, feature flag, model route, and permission set.
- Ignoring embedded AI. Existing vendors can quietly activate AI features that change data handling, retention, subprocessors, and customer commitments.
- Inventorying apps but not agents. Agents require dependency maps: models, tools, MCP servers, data sources, identities, quotas, and action controls.
- Approving without owner and expiration. Every approval should have an owner, scope, review date, policy state, and evidence packet.
- Blocking without learning. Repeated blocked usage is demand data. It should trigger migration, education, approved alternatives, or product evaluation.
- Separating vendor, cost, and risk data. Finance, security, legal, and product teams need one shared operating record, not four reconcilable exports.
Proxon Approach
Proxon turns AI vendor inventory into a living operating record.
Proxon treats inventory as a product surface, not a compliance spreadsheet. The platform resolves AI work across models, MCP servers, tools, data sources, prompts, agents, vendors, owners, approval states, usage, cost, and policy. That lets teams govern the system they actually have, not the system procurement remembers approving.
In the Proxon demo, inventory is organized across Models, MCP Servers, Tools, Data Sources, and Prompts. Each record can show vendor or provider, owner team, status, shadow flag, usage volume, dependents, version history, quota, region, and governance actions such as approve, restrict, deprecate, set quota, or reassign owner.
| Vendor Inventory Question | How Proxon Answers It |
|---|---|
| What AI assets exist? | Search and filter models, MCP servers, tools, data sources, and prompts by name, owner, vendor, capability, status, and shadow state. |
| Which vendors are sanctioned, pending, restricted, or deprecated? | Every asset carries a governance status that can drive review, routing, approvals, restrictions, and deprecation plans. |
| Who owns each AI surface? | Records attach owner teams and give operators actions to approve, restrict, deprecate, set quota, or reassign ownership. |
| Which agents depend on a vendor or tool? | Expanded records show dependent agents, criticality, team, and call volume so teams can see the blast radius before changes. |
| What data or actions can an AI system reach? | Data sources track sensitivity, region, freshness, PII flag, and usage; tools track server, category, action, quota, and calls. |
| Where is shadow AI showing up? | Shadow flags surface untracked models, servers, tools, sources, and prompts so teams can approve, migrate, restrict, or remove. |
| How do we prove control? | Inventory connects to policy, alerts, approvals, audit logs, evidence packets, and customer review readiness across the platform. |
The practical result is faster AI adoption with less drift. Business teams get approved paths. Security gets visibility and enforcement. Legal gets contracts and subprocessors linked to actual usage. Finance gets spend and utilization. Data teams get sensitivity and access context. Executives get one picture of where AI vendors are creating value, risk, and leverage.
What good looks like
A new AI app appears in browser telemetry. Proxon resolves the vendor, detects that employees are using personal accounts, identifies the teams and data classes involved, opens a review path, routes sensitive usage to an approved alternative, assigns an owner, tracks repeated demand, and preserves the decision history. The inventory is not a list after the fact. It is the system that turns discovery into governance.
Sources
Research cited in this guide.
- Netskope, Cloud and Threat Report: Generative AI 2025.
- Torii, 2026 SaaS Benchmark Report announcement.
- Okta, Businesses at Work 2026: Closing the identity gap in the age of AI.
- IBM, Cost of a Data Breach Report 2025 announcement.
- NIST SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations.
- ISO/IEC 42001:2023, Artificial intelligence management system.
- OWASP, Top 10 for Large Language Model Applications.
- Cisco, 2026 Data Privacy Benchmark Study.
- EU AI Act Service Desk, Article 26 obligations of deployers of high-risk AI systems.
- Stanford HAI, 2026 AI Index Report: Responsible AI.
- NIST, AI Risk Management Framework.