AI system inventory creation
Decide what inventory fields and ownership process make systems governable
When the organisation cannot reliably identify its AI systems and agents, this area becomes relevant. For the AI governance or platform inventory owner, the concern is specific: the register lists model names but omits the deployed workflows and accountable owners. The governance implementation design starts from that consequence and follows the relevant evidence through the customer workflow. Inventory should support a concrete decision such as review routing or change assessment. Record the deployed system, intended use, owner, data and action boundaries, and lifecycle state rather than treating a list of vendors as sufficient.
Connect the operating question to inspectable evidence
- AI governance or platform inventory owner
- Owns the bounded decision and the consequence of acting.
- Application registers
- Defines the starting context for the proposed work.
- Inventory completeness
- Exposes the first material uncertainty to examine.
- Maintenance ownership rules
- Carries unresolved conditions into an accountable next action.
Decision at stake
Decide what inventory fields and ownership process make systems governable
Make the decision explicit
- AI governance or platform inventory owner
- The organisation cannot reliably identify its AI systems and agents.
- Decision
- What inventory fields and ownership process make systems governable.
- Inventory completeness
- Use application registers to establish the relevant starting condition.
For the AI governance or platform inventory owner, this becomes relevant when the organisation cannot reliably identify its AI systems and agents. The immediate decision is what inventory fields and ownership process make systems governable. The scope should be narrow enough that the governance owners can identify a meaningful alternative, including continuing the current approach if the available evidence already supports it.
The practical failure to challenge is that the register lists model names but omits the deployed workflows and accountable owners. That concern gives the work a concrete direction: establish what the relevant boundary should do, inspect how it behaves or would operate, and identify the owner of any gap. It should not be diluted into a broad transformation exercise before the specific question has been answered.
Coverage
Examine inventory completeness alongside lifecycle status
Keep the review distinctions visible
- Inventory completeness
- Reconcile application and purchasing records to expose missing deployments.
- Lifecycle status
- Distinguish proposed, operating, paused and retired uses.
- Component and use-case relationships
- Link shared components to each use case and accountable owner.
Inventory completeness
For this scope, inventory completeness should be examined alongside application registers. Reconcile application, procurement, and deployment records with accountable owners. Treat discrepancies as discovery questions. The inventory should distinguish the deployed use from its underlying model or supplier, so a vendor list is not mistaken for a complete view of systems that affect the business.
Lifecycle status
For this scope, lifecycle status should be examined alongside procurement records. Define lifecycle states that help route decisions, such as proposed, piloting, operating, suspended, and retired. Test an actual state change against the maintenance process. The owner should be able to tell which records require review without inferring status from an old project description.
Component and use-case relationships
For this scope, component and use-case relationships should be examined alongside deployment and owner information. Represent relationships between workflows, agents, models, tools, data sources, and owners. A shared component change may affect several deployments. The proposed register should support that dependency question while avoiding unnecessary fields that nobody will maintain or use to make a decision.
Prerequisites
Start with application registers
Give each input a specific job
- Application registers
- Defines the operating boundary.
- Procurement records
- Examine lifecycle status.
- Deployment and owner information
- Shows conditions affecting component and use-case relationships.
- Policy or risk owner
- Confirm access and a reviewer who can resolve gaps.
The starting material is application registers, procurement records, and deployment and owner information. Review these together rather than assuming one document tells the whole story. A stated rule may differ from a configured behaviour, and a proposed responsibility may not yet have an available owner. Identify those differences before selecting the detailed work.
Participation should include an accountable policy or risk owner, relevant system owners, and qualified legal or domain reviewers when interpretation is needed. The customer should define which information and environments may be used. Synthetic or sanitised examples can support preparation when they preserve the relevant behaviour; if they omit a material dependency, record the limitation and agree how the missing evidence would be obtained.
How the work proceeds
Follow the requirement into an accountable operating practice
Follow the evidence through the work
- Inventory completeness
Use application registers to define the decision criteria.
- Lifecycle status
Inspect procurement records and retain observations that challenge the expected result.
- Component and use-case relationships
Use deployment and owner information to identify unresolved conditions and a responsible owner.
- Maintenance ownership rules
Link the recommendation to its evidence, remaining limits and next validation condition.
Design inventory relationships before collecting every possible field. One business system may use several models, tools, and agents, while one component may support several uses. The proposed register should preserve those relationships so a supplier change or new action can be traced to the deployments and owners that need review.
A practical first slice would focus on inventory completeness and then follow its consequences into lifecycle status. Keep component and use-case relationships visible as a separate review question rather than assuming it is satisfied by the first result. The governance owners should record observations, competing explanations, and changes to the original assumptions. A second reviewer can challenge whether the evidence supports the recommendation and whether an apparently successful example omitted the condition that matters most.
Indicative artefacts
Use maintenance ownership rules to make the next action explicit
Every artefact needs an operating use
Illustrative working format
- AI inventory model
- Boundary — application registers.
- Discovery and reconciliation plan
- Findings about lifecycle status.
- Maintenance ownership rules
- Action on component and use-case relationships.
Indicative outputs include AI inventory model, discovery and reconciliation plan, and maintenance ownership rules. Their form should follow the decision and the customer’s existing operating records. The first should establish the assessed boundary and relevant observations; the second should make material gaps or dependencies inspectable; the third should identify the action, owner, and evidence needed to revisit the decision.
Acceptance should be tested through use: can the responsible owner explain what was examined, identify an unresolved issue, and act on the next step without reconstructing the whole engagement? Findings should preserve counterevidence and limits. A polished document is insufficient if it does not help resolve the customer’s specific question.
Illustrative scenario
Scattered departmental agents: maintainable inventory
Examine the constructed decision boundary
Illustrative scenario
- Scattered departmental agents
Product and internal-application use lacks a shared AI inventory.
- Record reconciliation
Compare purchasing, deployment records and interviews; investigate mismatches.
- Maintainable inventory
Exercise a pilot-to-production update before treating initial collection as sufficient.
Consider an illustrative situation in which several departments use agents through software products and internal applications without a shared inventory. This is a constructed example, not a client engagement or an observed Softlander outcome.
For scattered departmental agents, an illustrative reconciliation would compare procurement records, deployment records, and interviews. Differences would become discovery questions rather than invented entries. Acceptance should include an update event, such as a system moving from pilot to production, to demonstrate that the inventory can remain useful after initial collection.
The useful learning would be the difference between the expected behaviour and the behaviour or responsibility actually demonstrated. If the exercise leaves component and use-case relationships unresolved, that should remain a named next step. A recommendation to narrow the scope, improve a prerequisite, or hold the decision can be appropriate when the example exposes a material dependency.
Scope and authority
Governance evidence supports decisions within defined professional limits
Keep analytical work separate from decision authority
- Operating requirements and evidence mapping
- Can include AI inventory model.
- Policy or risk owner
- Authorised policy owners decide; qualified specialists interpret professional requirements.
- Legal conclusions and certification decisions
- Cannot be inferred from discovery and reconciliation plan.
This work supports governance preparation and operating evidence. It does not provide legal advice, determine regulatory compliance, award certification, or replace a formal audit. Authorised customer owners retain policy, release, and residual-risk decisions.
Ways to engage
Related engagement scopes
AI Privacy Engineering Review
Trace personal data through your agent workflow. Examine collection, memory, retrieval, tool access and retention against your agreed requirements.
AI Governance Operating System
Make AI oversight part of daily operations. Connect inventories, accountable owners, change decisions and evidence into a workable governance process.
Continue exploring
Related insights and resources
Governing agent decisions
Governance becomes useful when it changes a decision. Connect each agent workflow to an accountable owner, explicit operating conditions, proportionate evidence and a practical route for exceptions and withdrawal.
Protecting agent data and memory
An agent's information footprint extends beyond the conversation. Map the copies, derived records and retrieval paths that influence future actions, then connect each to purpose, access, retention and verifiable handling.
AI agents in legal operations: assistance without invented authority
Legal agents can organize evidence and prepare work, but professional judgement, client authority and verified legal positions cannot be delegated by interface.