What is an AI use case inventory?
By Nick Jang, founder of MINERVA Studio ·
The short answer
An AI use case inventory is a list of every place an organization uses AI, with one row per use rather than per tool: what the AI does, who owns that use, which model or vendor powers it, what data it reads, who it affects and how risky it is. It’s the starting point for AI governance, because you can’t assess, approve or monitor what you haven’t listed. US federal agencies must publish one every year under OMB memo M-25-21, and Canadian banks need the equivalent, the model inventory, under OSFI’s E-23 from 1 May 2027.
A use case, not a tool
The unit matters. One chatbot product can sit behind three use cases: answering customers’ questions about fees, drafting replies for complaint handlers, and summarising calls for the quality team. Each touches different people and data, and each carries a different risk. A list of tools would show one row and hide two decisions.
The reverse happens too. Two teams can use different products for the same job. Listing by use case shows the overlap and lets you choose one approved route.
A use case inventory and a model inventory aren’t rivals. The model inventory says what each model is and how it was validated; the use case inventory says where and how it’s used. Most organizations link the two, one model to many uses.
What to record
| Field | What goes in it |
|---|---|
| Use case ID and name | A stable reference and a plain name: "Complaint reply drafting". |
| Purpose | What decision or task the AI supports, in one or two sentences. |
| Business owner | One named person accountable for the use. |
| Model or system | The model, product or API behind it, with its ID in the model inventory. |
| Origin | Built in-house, bought from a vendor, or a feature inside software you already use. |
| Data | What it reads, including any personal or confidential information. |
| Who it affects | Customers, staff, the public; and whether a person reviews the output before it counts. |
| Risk rating | On your own scale, with the date it was set. |
| Status | Idea, pilot, in production, retired. |
| Approval | Who approved the use, when, and any conditions or limits. |
| Next review | The date it’s looked at again. |
OSFI’s E-23 sets a minimum for the model side: model ID, name and description, risk rating, owner, developer and origin for every identified model, and much more for models in the inventory, including approved uses and limitations. Our templates page has an E-23 model inventory template with those columns.
How to find the uses
- Ask every team, briefly and without blame: what AI do you use, for what, with what data?
- Read purchasing records and contracts for AI products and AI features added to existing ones.
- Check sign-in and network logs for AI services used with work accounts.
- Scan code for calls to model APIs.
- Ask your vendors which of their features use AI and whether your data trains them.
The first pass always finds uses nobody approved. That’s normal; see shadow AI. Add them to the inventory first, then decide: approve, replace or stop.
The US federal inventories
Most of the public examples come from US federal agencies. OMB memo M-25-21 (3 April 2025), which replaced M-24-10, tells each covered agency to inventory its AI use cases at least once a year, submit the inventory to OMB and post a public version on its website. Use cases that count as high-impact, broadly where the AI’s output is a principal basis for decisions with legal, material or significant effects on people’s rights or safety, are reported individually; others can be reported in consolidated form.
The published inventories (the Federal Reserve’s, the departments’, and the consolidated 2025 data OMB posts on GitHub) are a useful model for the columns and the level of detail, even outside government.
In Canadian banks
OSFI’s E-23 doesn’t use the phrase, but it asks for the same thing: identify every model in use, AI included, keep an inventory with approved uses and limitations, and rate each by risk. Federal departments have their own route: the Treasury Board’s Algorithmic Impact Assessment for automated decisions.
MINERVA keeps the model inventory with each model’s owner, origin, supplier, approved uses, limitations and risk rating on one record, so the inventory and the decisions about it stay together. See OSFI E-23 software.
Related questions
What is the difference between an AI use case inventory and an AI model inventory?
A model inventory has one row per model: what it is, who built it and how it was validated. A use case inventory has one row per use: where and how AI is applied. One model can support several use cases.
What should an AI use case inventory include?
An ID and name, purpose, business owner, the model or system behind it, origin (built, bought or embedded), data used, who it affects, risk rating, status, approval and next review date.
Who has to publish an AI use case inventory?
US federal agencies covered by OMB memo M-25-21 must inventory their AI use cases at least annually, submit them to OMB and post a public version. Private companies have no general duty to publish one, though regulators such as OSFI expect an internal inventory.
What is a high-impact AI use case?
Under OMB M-25-21, broadly one where the AI’s output serves as a principal basis for decisions or actions with a legal, material, binding or significant effect on rights or safety.
How often should an AI use case inventory be updated?
Continuously as uses are added or retired, with a full review at least once a year. Each use’s own review date should follow its risk rating.
Sources
- OMB — M-25-21, Accelerating Federal Use of AI through Innovation, Governance, and Public Trust (3 April 2025)
- OMB — 2025 Federal Agency AI Use Case Inventory (GitHub)
- Federal Reserve Board — AI Use Case Inventory
- OSFI — Guideline E-23, Model Risk Management (2027)
New answers are posted on MINERVA on LinkedIn. Follow along, or send the question you’d like answered next to minerva@minerva.studio.
A plain-language explanation, not legal advice. The regulator’s own text is the source; read it, and take advice on how it applies to your institution.