How to Create an AI Inventory
Step-by-step method for building an AI inventory: the fields to capture, four discovery methods, a template table and a six-stage lifecycle.
By AI Compliance Tool editorial team · Published 2026-10-14 · Reviewed 2026-10-14 · Reviewer: Pending independent review · 9 min read
Key takeaways
- An AI inventory is the foundation record: almost every legal duty (notice, assessment, vendor accountability, retention) attaches to a specific system you must first be able to name.
- Capture twelve fields per entry, including affected people, decision authority, human oversight and, for agents, the permissions they hold.
- Discovery takes four passes: a staff survey, expense reports, SSO and admin logs, and a browser-extension audit. Each finds tools the others miss.
- Give every entry a lifecycle state (Draft, Review Required, Approved, Active, Suspended, Retired) so the inventory records decisions, not just existence.
- Review the inventory quarterly and on any material change; a stale inventory is nearly as risky as none.
An AI inventory is a list of every AI system, feature and agent your business uses, with enough detail to decide what each one needs. It is the first artefact a regulator, auditor, insurer or enterprise customer will ask for, and it is the record every other governance step depends on.
This guide gives you the fields, four discovery methods that catch what a survey alone misses, a template you can copy and a lifecycle that turns the inventory into a decision record.
Why the inventory comes first
Consider what the rules actually ask you to do:
- Screen every use against the EU AI Act Art. 5 prohibitions (applying since 2 February 2025) and classify employment, credit and other Annex III uses as high-risk ahead of 2 December 2027.
- Complete a privacy impact assessment under Quebec Law 25 s. 3.3 for any project to acquire or develop an information system involving personal information.
- State in Ontario job postings that AI screens applicants (ESA s. 8.4, employers with 25 or more employees).
- Give notice at the point of interaction and keep records for three years under Colorado SB 26-189 from 1 January 2027.
- Remain accountable for personal information transferred to processors under PIPEDA Principle 4.1.3.
Every one of those duties attaches to a specific system. If you cannot name the system, you cannot evidence the duty. Voluntary frameworks say the same thing: the NIST AI RMF Govern function expects an inventory of AI systems, and ISO/IEC 42001 Annex A controls assume you know your AI system lifecycle.
The twelve fields to capture
| Field | What to record | Why |
|---|---|---|
| Name | Product and feature (e.g. “Helpdesk X, AI reply drafts”) | Features hide inside products |
| Vendor | Company, contract owner, plan tier (consumer vs business) | Terms differ by tier |
| Owner | Named person responsible internally | Accountability |
| Purpose | One sentence on what it does for you | Purpose limitation under privacy law |
| Data categories | Public, internal, customer personal, employee personal, sensitive (health, financial, biometric) | Drives consent, safeguards, PIA/DPIA |
| Affected people | Customers, applicants, employees, public, none | Triggers notice and automated-decision rules |
| Jurisdictions | Where affected people are, where data is stored | EU, Canada federal/provincial, US state rules |
| Decision authority | None / recommends / decides with human sign-off / decides alone | Quebec s. 12.1, GDPR Art. 22, Colorado ADMT |
| Human oversight | Who reviews outputs, how often, how to override | EU Art. 14 and 26; general good practice |
| Lifecycle status | Draft, Review Required, Approved, Active, Suspended, Retired | Makes the inventory a decision record |
| Review date | Next scheduled review | Keeps it current |
| Agent permissions | For agents: systems it can read, write, send to, spend from; approval gates | Agents act, so permissions are the risk |
Two fields deserve extra care. Decision authority is where most legal exposure concentrates: a tool that “recommends” which applicants to interview is, in practice, deciding if nobody reads the rejected pile. Record what actually happens, not what the vendor brochure says. Agent permissions is new for most businesses; if a tool can send email, update CRM records or trigger payments without a person clicking, write down exactly which permissions it holds.
Four discovery methods
No single method finds everything. Run all four the first time.
1. Staff survey
Send a five-question form: Which AI tools or features do you use for work? On which account (personal or company)? What do you paste into them? Do any of them act on your behalf (send, post, update)? Who else uses them? Keep it blame-free; the point is to find shadow use, not punish it.
Expect under-reporting. People forget that their note-taking app summarises meetings or that their email client drafts replies.
2. Expense reports and card statements
Pull twelve months of software charges. Look for AI product names, “Pro” or “Plus” subscriptions on consumer AI services, API usage charges and marketplace add-ons. This catches tools individuals bought on personal cards and expensed, which are often on consumer terms.
3. SSO, identity and admin-console logs
If you use Google Workspace, Microsoft 365 or an SSO provider, export the list of third-party apps that have been granted access to company accounts. Then open the admin console of each core product (CRM, helpdesk, HR system, accounting) and check which AI features are switched on and for whom. Vendors frequently enable AI features by default in a release.
4. Browser-extension audit
Ask each person to export or screenshot their installed browser extensions, or use your device-management tool to pull the list. Writing assistants, meeting recorders and “AI for LinkedIn” tools often live here, with broad permissions to read page content.
Worked example: Brightmoor Property Management, a 28-person firm in Calgary, believed it used “two AI tools”. The survey found four. Expense reports found a consumer AI subscription on three personal cards. The Google Workspace app list showed nine third-party apps with mailbox access, three of them AI tools. The extension audit found a meeting recorder on 11 laptops. Final inventory: 19 entries, including a CRM assistant with write access to tenant records that nobody had reviewed.
Template table
Copy this into a spreadsheet; one row per system or feature.
| Name | Vendor / tier | Owner | Purpose | Data categories | Affected people | Jurisdictions | Decision authority | Human oversight | Status | Review date | Agent permissions |
|---|---|---|---|---|---|---|---|---|---|---|---|
| CRM assistant, “auto-follow-up” | CRM vendor, business plan | Sales lead | Drafts and sends follow-up emails to leads | Customer personal | Customers, prospects | AB, BC, ON; some EU leads | Decides alone (sends without review) | None currently | Review Required | 2026-11-01 | Read contacts, send email, update lead stage |
| Meeting recorder extension | Extension vendor, consumer | (unassigned) | Transcribes and summarises calls | Customer and employee personal; occasionally health details | Customers, employees | AB | None | Each user | Review Required | 2026-10-28 | Read audio, read calendar |
| Drafting assistant | Model vendor, team plan | Marketing lead | Drafts marketing copy from public inputs | Public, internal | None | n/a | None | Owner reviews all output | Approved | 2027-01-15 | None |
The lifecycle: six states
Each entry has exactly one state. State changes are the decisions your inventory records.
- Draft. Someone has proposed or discovered the tool. Fields may be incomplete.
- Review Required. Fields are complete enough to assess. A risk screen (prohibited-practice check, data categories, decision authority) is pending. Discovered shadow tools enter here, not at Active.
- Approved. The owner and the governance lead have signed off, with conditions recorded (for example “no customer personal data” or “human reviews every send”).
- Active. In use, with oversight and review date set. Only Approved entries can become Active.
- Suspended. Paused because of an incident, a vendor change, a failed review or a regulatory trigger. EU high-risk deployers will be required to suspend use where a system may present a risk (Art. 26(5), from 2 December 2027); suspending is a normal, recorded action, not a failure.
- Retired. No longer used. Record the date, data deletion confirmation from the vendor and where the logs are archived.
Put the transitions in your governance policy: who can move an entry from Review Required to Approved, who can Suspend (make this easy, and let more than one person do it), and what evidence closes a Retired entry.
Keeping it current
- Quarterly review. The governance owner re-runs the SSO app export and the expense scan, and confirms each Active row’s owner, purpose and review date.
- Change triggers. A vendor announces a new model or new data-use terms; a tool gains write or send permissions; a tool starts touching a new data category; you start hiring in Ontario, Illinois or New York City; you start serving EU customers. Any of these moves an entry back to Review Required.
- Regulatory calendar. Note the dates that change what the inventory must support: 2 December 2026 (EU new prohibitions and end of the marking grace period), 1 January 2027 (Colorado ADMT; California CCPA ADMT requirements), 2 December 2027 (EU Annex III high-risk, including employment uses), 2 August 2028 (EU Annex I).
A ten-row inventory that is reviewed every quarter and shows real state changes is worth more than a hundred-row inventory nobody has opened since the day it was built.
Sources
- EU AI Act, Regulation (EU) 2024/1689 (Art. 5, Art. 26, Annex III): https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng
- Digital Omnibus on AI, Regulation (EU) 2026/1744: https://eur-lex.europa.eu/eli/reg/2026/1744/oj/eng
- GDPR Art. 22: https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng#art_22
- PIPEDA Schedule 1 (Principle 4.1): https://laws-lois.justice.gc.ca/eng/acts/P-8.6/page-7.html
- Quebec P-39.1 (s. 3.3, s. 12.1): https://www.legisquebec.gouv.qc.ca/en/document/cs/P-39.1
- Ontario ESA, 2000 s. 8.4: https://www.ontario.ca/laws/statute/00e41
- Colorado SB 26-189: https://leg.colorado.gov/bills/sb26-189
- California CCPA ADMT regulations: https://cppa.ca.gov/regulations/ccpa_updates.html
- NIST AI RMF 1.0: https://www.nist.gov/itl/ai-risk-management-framework
- ISO/IEC 42001:2023: https://www.iso.org/standard/42001
Frequently asked
- Do features inside software we already use count as AI systems?
- Yes. A summarisation feature inside your helpdesk, an AI assistant inside your CRM and a transcription feature inside your meeting tool are all inventory entries. Record them under the parent product with the feature named.
- How detailed does the inventory need to be for a 10-person firm?
- A single spreadsheet with the twelve fields is enough. The discipline is in completeness and review dates, not in software. Expect 10 to 30 rows for a small business once hidden features are included.
- Is an inventory legally required?
- No law we track says 'keep an AI inventory' in those words. But Quebec Law 25 PIAs, EU AI Act prohibited-practice screening, Ontario ESA posting disclosure, Colorado's three-year record-keeping and PIPEDA accountability are all impossible to evidence without one.
- Who should own the inventory?
- The same person who is accountable for AI governance overall, usually the operations lead. Individual tool owners update their rows; the governance owner runs the quarterly review.
This guide is general information, not legal advice. Laws and dates are drawn from our verified regulatory dataset and link to official sources; check them for changes after the review date.