Your AI inventory is a moving target

An inventory can list hundreds of AI systems and still give a misleading picture of exposure. The missing information is often simple. Where did the inventory look, and when did it last look there?

An asset count without those two answers invites false confidence. This post covers how to record coverage and freshness so the inventory can guide real decisions.

Record where the inventory looked and when it last looked. Those two facts decide how much weight the asset count deserves.

How AI enters a business

AI reaches a business through several routes.

• A team builds an application against a model API.
• An employee uses an AI assistant in a browser.
• A software supplier adds an AI feature to a product you already own.
• A developer installs an agent that can reach local files and tools.

No single discovery source necessarily sees all four. Each source has a vantage point, and each vantage point has edges. For two of these routes in detail, see our post on why shadow AI discovery has to reach browsers and endpoints.

Treat discovery coverage as a record

For each connected surface, document the collection method, the permissions it requires, the last successful update, and the known blind spots. This table shows how common sources differ.

The table is a starting point. Your sources and blind spots will differ, so write down your own.

Freshness changes the answer

An approved system can change without changing its name. Its model, connected tools, data sources, or permissions may differ from the version reviewed last month. A useful inventory retains that history and surfaces the changes that matter to the owner.

Changes worth surfacing to an owner include a new model, a new tool or connection, a new data source, a broader permission, and a new owner or business purpose. Updates outside that list can usually be recorded without opening a review.

Set an expected reporting interval for each source. A source that has not reported within its interval should show as stale, since an old record may describe a system that no longer exists in that form.

Changes that alter the basis of an approval belong in a review queue. Our post on when to review an AI system again explains how to scope that work.

Reconcile without losing provenance

Several discovery sources may observe the same system. A browser extension might see a team using an AI site, an endpoint source might see the same vendor's desktop app, and the identity provider might show sign-ins to the same product.

Merging those records should preserve each source and the approval history. Otherwise teams review duplicates while the real production asset stays unclear.

Match on stable identifiers such as a domain, an application identifier, or a repository, and keep the per-source evidence attached to the merged record. When two records cannot be matched with confidence, keep them separate and label the match as unresolved.

What each record should carry

A record that supports review needs a few fields beyond the asset's name.

• Owner. A named person or team who answers for the asset.
• Source. Which discovery sources observed it, and how.
• Confidence. How certain the match is, given how it was found.
• First seen and last seen. Dates that show whether the asset is still active.
• Classification. Whether it is sanctioned, monitored, blocked, shadow, or unknown.
• Connections. The models, tools, and data sources the asset can reach.

Run a small pilot first

Start with a manageable test. Select one business team and list the AI activity you already know about.

1. Write down the activity the team already knows about.
2. Connect the discovery sources available for that team.
3. List what each source found and what none of them found.
4. Investigate both the missing assets and the false matches.
5. Record the collection boundary in plain language.

Most pilots skip the last step. Record which managed devices and browsers reported and over what period. A small pilot supports a small claim, and the record should say so.

For example, suppose a finance team knows about a browser assistant and an AI feature in its reporting tool. After connecting a browser source and an endpoint source, the team might find a third assistant in a browser profile and a local runtime on one laptop. Each finding becomes a record with an owner to confirm, and each source that found nothing gets a line in the coverage notes.

Four questions for each review

Use these questions in the ongoing review.

1. Which surfaces are connected?
2. Which have stopped reporting?
3. Which assets lack an accountable owner?
4. Which changes require a new decision?

Those questions turn an inventory into an operating tool. They also give owners a short list to work from each week.

Give each count a denominator

An asset count becomes useful when it comes with a denominator. A statement such as "the managed devices in one department reported yesterday" tells a buyer more than an unexplained claim of total visibility.

Report coverage as a share of a defined population. For example, report the managed browsers that checked in during the last week out of the managed browsers enrolled. When the share drops, the inventory has become less reliable, and the report should say so.

How Halo helps

Halo's AI inventory classifies each asset as sanctioned, monitored, blocked, shadow, or unknown, and records the source and confidence behind it. Halo Browser (Chrome and Edge, plus Safari on macOS) and Halo Endpoint (macOS and Windows) add discovery from supported surfaces, and the inventory exports as an AI bill of materials in CycloneDX, JSON, and CSV. Rollout of browser and endpoint discovery is guided, so the covered device population is something you agree with our team during onboarding. Explore AI inventory and AI discovery, or read about shadow AI discovery and the AI bill of materials.