Is this the same as a shadow AI detection guide?

Detection guides explain how to collect signals and identify activity. This checklist begins after those feeds run. It tests coverage and reconciles duplicate observations. It also assigns owners and data classes. Then it records dispositions and produces an accepted inventory. The separation keeps the team from mistaking continuous event collection for a completed governance decision.

How often should the inventory be reconciled?

Set a cadence based on organizational risk and the rate of change, then add event-driven review. Monthly review fits a rapidly changing rollout. Quarterly review may fit a stable and narrow deployment. A material supplier, route, capability, or acquisition should trigger review immediately. An evidence-feed failure should too. Preserve each signed version so investigators can reconstruct what the organization knew on a given date.

Can the inventory include unresolved blind spots?

Yes, if the blind spot is explicit and bounded. Record the missing source or path, affected population, likely exposure, compensating evidence, owner and expiry, plus a closure test. A concealed gap invalidates the inventory acceptance decision. A documented exception gives the approving authority a visible risk decision and the next reconciliation a concrete item to retest.

AI Discovery Checklist for Post-Deployment Inventory Acceptance

An AI discovery deployment can collect DNS events and OAuth grants, endpoint signals and expenses, plus application records while still leaving the organization without an accepted inventory. This AI discovery checklist starts after collection is running. The result is one signed register that covers observed services and use cases, with owners and dispositions for blind spots. I would reject a discovery project that ends with a vendor dashboard and no named person willing to sign it.

TL;DR

Use this worksheet after discovery tooling and data feeds are deployed, not as a guide for finding the first shadow AI signal.
Reconcile every observed service to an owner, use case, identity path, data class, destination and disposition.
Test blind spots with known activity instead of assuming each connector provides complete coverage.
Sign the accepted inventory with owners and dated exceptions. Set a scheduled reconciliation cycle.

Check 1: freeze the acceptance window and evidence set

Name the period under review and the included business units. Then list the expected evidence feeds. Record source health for DNS or proxy logs, endpoint telemetry, IdP and OAuth records, expenses, SaaS audit logs, cloud billing and code repositories, plus approved AI gateways. The shadow AI discovery framework covers collection; this checklist is for the resulting inventory.

Choose a stable cutoff, such as September 1 through September 30, 2026, plus a grace period for late records. Acceptance passes when the reviewer can reproduce the source set and account for failed feeds. The reviewer must also show the query or export behind the candidate inventory.

Check 2: deduplicate services, models and embedded features

One provider can be visible under a browser hostname, API hostname, a marketplace charge and an OAuth application, plus an embedded SaaS capability. Merge observations only after confirming they are the same governed service. Keep separate entries when access mode, contract, tenant, region and route, or data handling differs.

The NIST AI RMF says inventory mechanisms should reflect organizational risk priorities. The organization's register defines granularity. One "OpenAI" entry is too coarse when personal accounts differ from an enterprise tenant. A production API account also has different owners and rules.

Check 3: bind each entry to an owner and use case

Every row needs an accountable business owner and a technical owner. Add its purpose and user population. Also record the invoking application and production status. Include the supported decision or action. A charge-card owner can trace a subscription, but payment approval is not operational ownership.

Place unresolved rows on a printed exception sheet. A blank owner cell is visually uncomfortable. My view is simple: ownerless AI has no legitimate route into an accepted inventory. Pass when every active row has an authorized owner or a dated containment and investigation action.

Check 4: reconcile identity and access paths

Record each access path: enterprise SSO, personal account, API key, workload identity, shared credential and embedded supplier call, or agent delegation. Compare the expected path with observed evidence. An enterprise contract is weak assurance if half the users appear through personal accounts.

The five-source discovery pipeline explains how to generate those observations. This worksheet is for reconciling them. Acceptance passes when each path maps to a known population and credential owner. It also needs a permitted role and revocation method. Shared credentials need a remediation owner because they collapse several callers into one audit identity.

Check 5: attach data classes and destinations

For each use case, document data entering prompts and retrieval context, plus files and responses. Record the model endpoint, region, supplier tenant and retention setting, plus downstream recipients. Use observed classifications from the acceptance window. Policy text cannot prove what the deployed route handled.

NIST SP 800-53 CM-8 calls for an accurate component inventory at the granularity needed for accountability. Its control catalog also lists owner and version, plus machine name and network address, as useful accountability information for components. Apply that discipline to the AI service entry without claiming CM-8 defines a special AI inventory.

Check 6: run known-activity coverage tests

Create authorized test events across in-scope paths: a browser interaction, API request, embedded SaaS capability and workload identity, plus an approved-route call where applicable. Confirm which feeds see each event and how quickly it reaches the register.

A missing event is a measured blind spot. Record it with affected users, likely data classes, compensating evidence and owner, plus a closure date. The shadow AI detection guide describes DNS and request-shape signals, including identity-bound prompt signals. Acceptance requires an honest coverage map. A claim of universal visibility is not enough.

Check 7: assign a disposition to every active entry

Give every row one current decision: approved; approved with conditions; contract review; migration required; blocked; under investigation; or retired. Define the evidence required to leave a temporary state. "Review later" is not a disposition because it lacks an owner and decision date.

The NIST AI RMF Playbook says its actions are voluntary and the Playbook is neither a checklist nor a universal sequence. That official Playbook guidance matters here. This acceptance worksheet is an organizational artifact for a deployed discovery program, not a claim that NIST guidance is a certification procedure.

Check 8: sign the AI discovery checklist

The final record names the inventory version; acceptance window; included units; source set; entries; dispositions; blind spots; exceptions; reviewers; and approval date. Keep evidence exports behind stable links. A dashboard screenshot omits the queries and decisions behind the inventory.

Schedule the next reconciliation and its change triggers. A new provider, AI capability, model route, acquisition, or business unit should reopen review. A disabled feed should do the same. Acceptance passes when security and the accountable business authority sign the same version. Every exception also needs an expiry.

DeepInspect

DeepInspect contributes evidence for authenticated HTTP traffic routed between enterprise users or agents and LLM endpoints. It can attach application-supplied identity, request classification, model destination and policy version, plus the outcome, to a signed per-decision record. Those records can populate and test approved-route entries during inventory reconciliation.

Browser sessions, personal devices, embedded supplier inference, local models and expenses, plus OAuth grants, need their own discovery sources. The signed inventory combines those sources with DeepInspect records instead of pretending one request-path control sees the entire organization. Let's talk today.