In brief
- The inventory also covers AI features in existing business software and active pilots.
- A product name is insufficient; purpose, configuration and data flow are what matter.
- Roles must cover decisions and operation, not just the project phase.
- Changes and retirement belong in the inventory alongside new approvals.
What belongs in the inventory?
The inventory is not limited to models built in-house. SaaS features, embedded copilots, APIs, automation and experimental agents can all affect relevant data or decisions.
- Production systems, pilots, experiments and planned purchases
- Purchased software with active or optional AI functions
- Custom applications, models, prompts and RAG components
- Agents and automation with access to tools or systems
- Retired systems while evidence or deletion remains outstanding
Minimum fields make an entry decision-ready
The inventory should not duplicate every technical detail. It links to existing documentation and contains the information needed for ownership, prioritisation and review.
| Inventory field | Filled example: CRM email copilot | Accountable role | Review trigger |
|---|---|---|---|
| Identity and status | CRM Copilot, vendor release 2026.2, limited pilot in Swiss sales | Product owner | Release, scope or status changes |
| Purpose and users | Draft follow-up emails for 18 account managers; no autonomous sending | Business owner | New user group, communication channel or automated action |
| Data and recipients | CRM notes and approved product facts; provider in EU region; no health or HR data | Data owner | New field, source, recipient, region or retention rule |
| Technology and operation | Hosted model, CRM connector, company SSO, review before send, quality dashboard | Technical and operations owners | Model, connector, permission, logging or support change |
| Risk and approval | Medium internal tier; approved for pilot with monthly quality review; next review 30 Sep 2026 | Business owner with required control functions | Incident, missed threshold, provider change or review date |
Accountability is multidimensional
One person may hold several roles, but no role should be unanswered. The business function owns purpose and domain quality; technology and operations own architecture, change and availability. Privacy and security advise or review according to risk.
- Business owner: need, value, process and acceptable errors
- Product or system owner: roadmap, configuration and change control
- Data owner: sources, quality, permissions and retention
- Technical owner: architecture, integration, tests and technical boundaries
- Operations owner: monitoring, support, incidents and recovery
- Control functions: privacy, security, legal, compliance or HR as relevant
Connect the inventory to real workflows
A spreadsheet requested once a year becomes stale. A better approach links the inventory to procurement, access provisioning, architecture review, release management and offboarding.
- Step 1
Register
Create an entry when a product or experiment is requested or purchased.
- Step 2
Review
Complete required fields, owners and conditions before pilot and production.
- Step 3
Update
Use model, data, feature and provider changes as review triggers.
- Step 4
Retire
Revoke access, export or delete data and document remaining dependencies.
Example: A copilot feature inside an existing SaaS product
A CRM release automatically enables a new summarisation function. The product is already known, but its data flow and model provider are new. The inventory therefore triggers a change review. The business and data owners confirm purpose and permitted fields, technology reviews regions and logs, and operations defines monitoring and support.
What to remember
Start with a small number of required fields and embed the inventory in procurement and operation. Completeness comes from processes, not a one-off survey.
Sources and further reading
These primary sources provide further detail on definitions, technical foundations or responsible use.
Content reviewed
Reviewed 17 July 2026. General information, not legal advice. The specific legal position and applicable scope must be assessed for each use case.