That gap between the inventory as a governance artifact and the inventory as an accurate reflection of operational reality is worth understanding before your next federal conversation. The OMB AI use case inventory requirement, which has been generating compliance activity across civilian agencies since March 2024, is a provisioning problem wearing a reporting costume. And if you've spent any time in identity and access management, you've seen this exact failure mode before.
What OMB M-24-10 Actually Requires
OMB Memorandum M-24-10, "Advancing Governance, Innovation, and Risk Management for Agency Use of Artificial Intelligence," issued in March 2024, is the policy document your buyers are living under. It does several things simultaneously: it requires agencies to designate a Chief AI Officer with genuine authority, it mandates minimum risk management practices for rights-impacting and safety-impacting AI, and it requires agencies to maintain and publish AI use case inventories.
The inventory requirement is the most operationally concrete piece. Agencies must catalog their AI use cases — not just deployed systems, but use cases in development and those that have been retired — and publish those inventories publicly. The inventories are supposed to track the use case name, the stage of development, whether the use case involves rights-impacting or safety-impacting decisions, the responsible bureau or component, and the deployment status. Agencies publish these on ai.gov and on their own sites. Most CFO Act agencies have submitted at least one inventory cycle.
What the inventories actually contain varies considerably. A large civilian agency might list 80 to 150 use cases. A defense component might list fewer, with more redactions. The published inventories from 2024 show a consistent pattern: heavy representation of natural language processing for document processing and search, predictive analytics for fraud detection and benefits processing, and chatbot deployments for public-facing services. What they show less consistently is whether those use cases are current, who owns them now, and whether the responsible official listed is still in that role.
That last observation points to structure, not staffing.
Who Actually Owns the Inventory
The CAIO is nominally responsible. In practice, the ownership question is more complicated, and it's worth understanding the organizational texture because your buyers will be living inside it.
In agencies where the CAIO sits close to the CIO — or where the roles are combined — the inventory tends to live in the IT governance function, which means it connects, however imperfectly, to existing system-of-record processes. ATO documentation, system security plans, procurement records. The inventory isn't automatically fed by those systems, but at least the people maintaining it are in the same organizational vicinity as the people who know when a new system gets acquired.
In agencies where the CAIO is a newer position, often reporting to a deputy secretary or chief of staff rather than to the CIO, the inventory frequently lives in a policy or strategy function. These teams are good at the compliance narrative — they can write the use case descriptions, assign the risk tiers, hit the submission deadline. What they don't have is a systematic feed from procurement or IT operations. They find out about new AI deployments the same way anyone finds out about shadow IT: eventually, and often by accident.
The CAIO at a mid-sized regulatory agency described the situation in a GovCIO Media interview last fall with more candor than you usually hear from a political appointee: "We built the inventory by asking every bureau to tell us what they were using. We got back a list. We have no way to know if that list is complete, and we have no automated way to keep it current." (GovCIO Media, October 2024. The speaker requested that the agency not be identified by name.)
That's an infrastructure gap.
The Lifecycle That Nobody's Tracking
The operational sequence that should, in theory, feed an AI use case inventory runs like this. An agency component identifies a need. They go through some form of acquisition — maybe a task order against an existing vehicle, maybe a direct purchase under the micro-purchase threshold, maybe a pilot under an OTA agreement. The tool gets evaluated, possibly piloted, possibly granted an ATO or a provisional ATO. It gets deployed. At some point it gets decommissioned or replaced.
Every one of those transitions is an event that should update the inventory. Acquired: add the use case. ATO granted: update the deployment status. Decommissioned: mark it retired.
None of those events currently trigger an automatic inventory update at most agencies. The acquisition happens in one system. The ATO lives in another. The decommission, if it's documented at all, lives somewhere else. The inventory is maintained by a person who has to go find out what happened, usually on a quarterly or annual cycle, and update a spreadsheet or a lightweight database that has no live connection to any of those upstream systems.
The result is predictable to anyone who has managed a user directory without automated provisioning: drift. Use cases listed as "in development" that have been in production for eight months. Systems listed as "active" that were quietly sunset when the contract ended. Responsible officials who left the agency a year ago, still named as the accountable party for a system they haven't touched since their last day.
Orphaned AI use cases are structurally identical to orphaned accounts. The failure mode is the same. The audit risk is the same. The governance gap is the same.
The SCIM Analogy, and Where It Breaks
If you work in identity, you know what solved the orphaned account problem for users: automated provisioning, anchored to an authoritative source of truth, with lifecycle events that trigger directory updates. SCIM (the System for Cross-domain Identity Management protocol) standardized how that provisioning works across systems. HR fires an event when someone is hired; the identity provider creates the account. HR fires an event when someone is terminated; the account is deprovisioned. The directory stays current because it's connected to the system that knows what's true.
The AI use case inventory needs the same architecture. An authoritative source of truth for AI tool lifecycle (acquisition, deployment, status change, decommission) connected to the inventory via something that functions like a provisioning layer. Inventory entries get created when tools are acquired. Status fields update when ATOs are granted or expire. Use cases get marked retired when contracts end.
The analogy breaks in two places.
First: there's no authoritative source of truth for AI tool acquisition equivalent to an HR system. User identity has a clean anchor — employment status. AI tool lifecycle doesn't. Acquisitions happen through multiple vehicles at multiple threshold levels. Pilots happen under agreements that may not flow through central IT procurement at all. Teams acquire AI capabilities embedded in SaaS tools they were already using — a productivity suite adds an AI assistant, and suddenly there's an AI use case that nobody formally acquired. The provisioning model assumes a single upstream system that knows when a new principal enters the environment. For AI tools, that system doesn't exist.
Second: there's no SCIM for AI use case registries. SCIM is a mature standard with broad IdP support because the problem it solves — user provisioning across enterprise systems — is old enough and common enough that the industry built a standard around it. The AI use case inventory problem is new, agency-specific in its policy framing, and hasn't attracted the same standardization effort. There's no protocol that says: when an AI system receives an ATO, emit an event in this format, to this endpoint, so the inventory can update. Nobody has built that. The CAIO doesn't have the technical infrastructure to build it unilaterally, and the CIO's office, where that infrastructure would more naturally live, often isn't the one accountable for inventory compliance.
Okta's publicly announced work on AI agent discovery and governance is relevant here — it addresses the authentication and authorization layer for AI agents operating in enterprise environments, which is a real and adjacent problem. But agent authentication is not the same as use case enumeration. Knowing that an agent is authenticated to act doesn't tell you whether that agent's use case is in the inventory, what risk tier it's been assigned, or whether the responsible official has reviewed it in the last twelve months. The identity layer and the governance layer need to talk to each other, and right now they're not even in the same conversation.
What the Published Inventories Actually Show
The divergence between what agencies say their inventories represent and what the published inventories actually contain is itself a signal worth naming.
Agency AI strategies and CAIO public statements consistently describe the inventory as a living governance artifact — something that reflects the current state of AI deployment and enables ongoing risk management. The published inventories, when you read them, look more like a point-in-time snapshot assembled for a compliance deadline. Use case descriptions are often high-level to the point of being uninformative. Risk tier assignments are present but rarely explained. The "stage of development" field, which is supposed to distinguish between tools being evaluated and tools in production, is inconsistently applied across bureaus within the same agency.
This describes what happens when you ask an organization to maintain a directory without giving it a provisioning infrastructure. The snapshot is as accurate as the people who assembled it could make it at the time they assembled it. The moment it's published, it starts to drift.
The Question That Opens the Conversation
If you're selling into federal accounts and you're talking to a CAIO or a senior IT official who's accountable for inventory compliance, there's one question that will tell you more about the buyer's actual problem than any discovery framework you've been given.
Ask them: "When a new AI tool gets deployed in your agency, what's the workflow that gets it into the inventory — is there a trigger, or does someone have to remember?"
That question is a genuine diagnostic. The answer tells you whether the inventory problem is a compliance problem (they need help with the submission process) or an architecture problem (they have no systematic connection between the tool lifecycle and the governance record). Most of the time, you'll hear some version of: "We send out a survey to the bureaus." Which means it's an architecture problem wearing a compliance costume.
The architecture problem is harder to solve and more expensive to ignore. An inventory that depends on people remembering to report will always drift. It will drift faster as AI adoption accelerates — and federal AI adoption is accelerating, with the number of use cases in published inventories roughly doubling between the 2023 and 2024 submission cycles across CFO Act agencies, based on a comparison of ai.gov inventory data. Manual processes don't scale with that growth rate.
The identity infrastructure gap in federal AI governance is real, it's structural, and it's not being talked about in the terms that would make it solvable. The people who know how to solve provisioning and lifecycle management problems are in the CIO's office. The people who are accountable for the inventory are often in the CAIO's office. Those two conversations need to happen, and right now they mostly aren't.
That's the gap. And the question above is how you find out whether your buyer has started to see it.