Ask most IT leaders how many servers they run, and they’ll pull the number from a CMDB in seconds. Ask how many laptops are in circulation, and endpoint management has the answer. Ask how many AI systems are operating inside the business — models, copilots, embedded vendor features, agents with credentials — and the room goes quiet.
That silence is the problem. You cannot govern what you cannot see, and right now most organizations cannot see their AI.
The invisible estate
AI didn’t arrive in your environment through a single procurement decision. It seeped in through a dozen doors at once. A development team fine-tuned a model for claims triage. Marketing turned on an AI feature inside a SaaS platform nobody reviewed. Microsoft 365 Copilot rolled out to a pilot group that quietly became everyone. A vendor pushed an update that added “AI-powered insights” to a tool you’ve licensed for years. Someone in operations wired an agent to an API with a service account that can read half the file share.
Each of these is an AI system. Each one touches data, holds permissions, and makes or influences decisions. And in most organizations, no single record says they exist.
This is the defining blind spot of enterprise AI in 2026: not shadow IT in the old sense of unsanctioned apps, but unregistered capability — AI functioning inside sanctioned platforms, invisible precisely because it arrived inside something you already trusted.
AI is an asset-management problem, not a software problem
The instinct is to treat AI as a software governance question: review the app, approve the app, move on. That framing fails because AI systems don’t behave like static software. They change with model versions, drift with data, gain new capabilities through vendor updates, and act with delegated authority. A copilot with access to a mailbox is closer to a privileged account than to a spreadsheet macro.
The discipline that fits is the one IT has practiced for decades: asset management. Every AI system is an asset with an owner, a purpose, a lifecycle, a risk profile, and a decommissioning path. The moment you adopt that frame, the tooling and process questions answer themselves — because you already know how to do this. You’ve done it for hardware, for software licenses, for certificates, for service accounts. AI is the next asset class, and it belongs in the same operational machinery.
If you already run ServiceNow, extend the CMDB rather than standing up a parallel system. Model AI systems as configuration items with their own class, relationships to the data sources they consume, and dependencies on the platforms they run on. If your data governance program runs on Microsoft Purview, connect the registry to your data map so each AI asset’s data sources trace to classified, labeled data with known retention. If you’re building on Azure AI Foundry, its model catalog and project structure give you a natural system of record for custom builds — but only for what you build there. The registry has to reach further than any single platform can see.
What belongs in the registry
An AI registry is only useful if it captures the attributes that governance, audit, and incident response actually need. At minimum, every entry should track:
- Model and version. Which model backs the system — foundation model, fine-tune, or vendor black box — and how you’ll know when it changes. Vendor-embedded AI changes underneath you; version awareness is how you notice.
- Purpose and scope. What the system is for, in one or two sentences a compliance reviewer can understand. Purpose is the anchor for every downstream question about appropriate use.
- Permissions and identity. What the system can do. Which accounts it runs under, which APIs it can call, which actions it can take without a human in the loop. An agent’s permission set is its blast radius.
- Data sources and classification. What the system reads, retrieves, or was trained on — and the sensitivity of that data. For insurance workloads, this is where policyholder and claims data exposure gets caught before it becomes a breach notification.
- Retention and residency. Where prompts, outputs, and intermediate data live, for how long, and in which jurisdiction. Vendor AI features frequently have different retention terms than the host product; the registry is where that distinction gets recorded.
- Logging and observability. Whether the system produces an audit trail, where it lands, and who reviews it. An AI system with no logs is an asset you can inventory but never investigate.
- Ownership and lifecycle status. Business owner, technical owner, risk owner — the same triad every governed AI system needs — plus approval date, review cadence, and a decommissioning plan.
Inventory the AI you didn’t build
The hardest part of the registry is not your custom systems. Those have project records, repos, and deployment pipelines; they leave footprints. The hard part is embedded vendor AI — the capabilities that arrive inside products you already own.
This demands a process change: AI capability review becomes part of vendor management. When a vendor announces an AI feature, that’s a registry event. When a contract renews, the questionnaire asks what AI capabilities the product now includes, what data they process, and where that processing happens. When procurement evaluates new tools, embedded AI is assessed as its own line item, not bundled into the general security review.
Copilots deserve particular attention. They sit at the intersection of broad data access and broad user populations. A copilot grounded in your tenant’s content inherits every over-permissioned SharePoint site and every stale access grant in your environment. Registering it forces the questions: what can it reach, what should it reach, and who verified the difference?
The registry pays for itself at audit time
If this sounds like overhead, consider what the registry does when someone asks hard questions.
An auditor asks how AI-processed personal data is governed: you produce the registry entries, their data source mappings, and retention terms — instead of launching a three-week discovery exercise. A regulator introduces new AI transparency requirements: you filter the registry by purpose and data classification to scope the impact in an afternoon. An incident response team investigates anomalous data access: the registry tells them which AI systems held credentials to the affected store. A vendor deprecates a model: you know exactly which systems depend on it and who owns the migration.
Lifecycle management gets the same lift. AI systems accumulate like any other asset — pilots that never ended, agents whose sponsors left, integrations nobody remembers approving. A registry with review dates and named owners is how those systems get retired instead of lingering with live credentials. Every unregistered AI system is an unmanaged privileged actor in your environment; the registry converts unknowns into managed assets.
Where to start
Don’t wait for perfect tooling. Start with a structured list — even a governed spreadsheet beats nothing — and capture the ten AI systems you already know about. Then run discovery: survey application owners, review SaaS admin consoles for enabled AI features, audit service accounts and API keys for AI-platform endpoints, and check what Copilot and similar tools are already deployed. Expect the count to double. It usually does.
Then formalize: pick the system of record, define the required attributes, make registration a gate in the intake process for anything new, and put embedded-AI questions into vendor review. Assign owners to everything already in production, grandfathered or not.
The organizations that will govern AI well over the next five years are not the ones with the most sophisticated policies. They’re the ones that can answer the simplest question in the room: what AI do we have? Build the inventory now, while the estate is still small enough to count.
Schedule your free consultation.