An AI policy can say all the right things and still miss the tool someone switched on inside an existing application. Before writing another page of rules, I would start with a simpler question: where are we actually using AI, and what can each use do?
An AI inventory is a maintained register of AI systems and use cases. A useful entry identifies an owner, a purpose, the data involved and the actions the system can take. It is not just a list of vendor names—and adding a system to it does not mean the system is approved.
Start with a use case, not a brand
“We use an AI assistant” is too broad to govern. Drafting public website copy and summarizing restricted documents may use the same product but involve different data, users and controls. Record them separately when those boundaries differ.
Likewise, a familiar application may contain multiple AI features. Include built-in assistants, meeting summarizers, search features, custom integrations, experiments and systems supplied by vendors. If you are unsure whether something is AI, mark it needs classification rather than treating a marketing label as evidence.
What NIST recommends
NIST’s Generative AI Profile includes GOVERN 1.6: “Mechanisms are in place to inventory AI systems and are resourced according to organizational risk priorities.” On printed page 16, its suggested actions include adding organizational generative-AI systems to the inventory and defining any exemptions for AI embedded in application software.
It also suggests considering data origins, known issues, human oversight responsibilities, special rights or sensitive-data considerations, and underlying models, versions and access modes. This is voluntary risk-management guidance, not a blanket law requiring every small organization to use the same spreadsheet.
The starter below is my practical adaptation of that guidance. The field names and 30-minute exercise are editorial recommendations, not an official NIST template.
A starter inventory you can copy
| Field | What to record | Evidence to check |
|---|---|---|
| Use-case ID and purpose | A stable ID and the specific job it performs. | A workflow description or demonstration. |
| Accountable owner | A named business owner and technical contact. | The owner confirms responsibility. |
| Product, model and access mode | Vendor, feature, model/version if disclosed, and app/API/local access. | Admin settings, documentation or version record; use “not disclosed” where necessary. |
| Users and status | Who uses it; proposed, pilot, active, suspended or retired. | Assignments, enabled settings or an owner walkthrough. |
| Data in and out | Data categories, sources, destinations and retention conditions. | Configuration and relevant vendor terms—not a generic marketing promise. |
| Actions and permissions | Read, draft, send, modify, delete or execute; which systems it can reach. | Connector scopes and actual permissions. |
| Human oversight | Who approves, monitors, reviews and stops the workflow. | Approval settings and a tested stop/escalation procedure. |
| Risk and open issues | Potential harm, known limitations and unresolved questions. | Assessments, incident records and validation findings. |
| Approval and review | Approval status, restrictions, last verification date and next review. | A linked decision record and review owner. |
Keep this register access-controlled. Record categories such as “customer contact details,” not copies of those details. Link to protected evidence rather than pasting confidential prompts, credentials or documents into the inventory.
A real audit shows why verification matters
In a February 2024 audit, the U.S. Government Accountability Office found that one of two cybersecurity use cases in DHS’s inventory had been incorrectly characterized as AI. The point is not that an inventory is useless. It is that an unverified inventory can confidently describe the wrong thing.
The follow-up matters: as checked September 9, 2026, GAO marks the inventory-verification recommendation “Closed – Implemented.” Its update describes guidance DHS developed in October 2024, including review responsibilities and consultation with people who understand the use cases. The original finding is a historical lesson, not a claim that the same deficiency remains open today.
The underlying GAO framework is useful because it connects the register to ongoing governance, data quality, performance measurement and monitoring. A tool being listed tells you it was found; it does not establish that it works reliably.
A 30-minute discovery session
- Minutes 0–5: set the boundary. Choose one team and one workflow. Agree what counts as in scope, including embedded features and pilots.
- Minutes 5–15: ask about actual use. Ask which tools draft, summarize, classify, recommend or take actions. Include free tools and existing subscriptions—not just purchased standalone AI products.
- Minutes 15–25: verify the important entries. Have owners demonstrate the workflow and inspect approved admin records. Check data access and action permissions first.
- Minutes 25–30: assign follow-ups. Give each unknown an owner and due date. Record unresolved classification and approval questions explicitly.
Thirty minutes is a starting exercise, not a promise of complete discovery. A complex organization will need repeated sessions, technical discovery and checks against procurement, access-management and application records.
Illustrative example: one product, two entries
Imagine a team using the same assistant for two jobs. One entry covers drafting public announcements with no connected data sources and human review before posting. Another covers summarizing internal documents through a connected repository. That second entry needs its own record of repository access, permitted data, retention and reviewer responsibilities.
Neither entry should say “safe because enterprise.” Record the actual configuration and evidence. If permissions or intended use change, review the entry again.
Keep it alive
My recommendation is to update the inventory when a system is introduced, changes model or permissions, connects a new data source, changes owner, has a significant incident or is retired. Set a periodic review cadence proportionate to the risk; do not rely on a once-a-year cleanup to catch operational changes.
Then connect each entry to a clear human-oversight arrangement. Discovery tells you what exists. Ownership and evidence tell you what to do about it.
FAQ
Can I start in a spreadsheet?
Yes. A controlled spreadsheet can be a useful starting point if it has stable IDs, ownership, review dates and links to evidence. The workflow matters more than the format.
Do built-in AI features count?
Include them in discovery. NIST specifically recommends defining any inventory exemptions for embedded generative AI in organizational policy; do not silently ignore those features.
Does an inventory replace an AI policy or risk assessment?
No. It supplies the facts those controls need. Listing, approving and evaluating a system are different activities.
Sources and recommendation statuses checked September 9, 2026. Hero: original conceptual artwork generated with GPT‑Image‑2.5 Flare through Higgsfield; not an actual system screenshot.