AI Inventory Design

An AI inventory is a maintained record of where AI is used, for what purpose, under whose responsibility and within which operating boundary. It must help the organisation answer an operational question: which uses are affected when a supplier changes a model, a data source loses approval or a business owner leaves?

A list of product names cannot answer that reliably. One purchased suite can contain several AI features; one feature can serve several business uses; a use can run in more than one configuration. The inventory needs relationships between these objects without forcing every reader to understand a technical database.

This guide is for Saudi governance, architecture, procurement and operations teams designing an inventory as part of AI governance setup. It provides an original record structure, discovery and reconciliation process, and an example involving embedded AI in an HR platform.

Decide which questions the inventory must answer

Start with decisions, not fields. Governance needs to find the owner, current permission and risk-review status. Operations needs the live configuration, support route and stop mechanism. Procurement needs the supplier, contract and change obligations. Privacy and security teams need the relevant data flows and access boundaries. Each view can draw from the same linked records.

Write a small set of acceptance queries. Examples include all live uses without a confirmed owner, all deployments relying on a changed supplier feature, and all permissions whose conditions have expired. If the proposed register cannot answer these questions, adding a description column will not solve the underlying design problem.

The NIST AI RMF Core includes mechanisms for inventorying AI systems. The schema here is an original operational proposal. Its completeness depends on the discovery and maintenance process, not on claiming that a spreadsheet has been filled once.

Separate product, feature, use case and deployment

A product is the purchased or built offering. A feature is a specific AI capability within it. A use case describes the business task and consequences. A deployment describes the actual configured instance or operating boundary. A model record describes a component where that information is available and relevant. Keep these distinct even if a simple implementation stores them in linked spreadsheet tabs.

Objects that an AI inventory should distinguish

Object	Example description	Why it needs its own identity
Product	Purchased HR software suite	Links supplier, contract and shared services
AI feature	Vacancy drafting or application ranking	Capabilities can change independently
Use case	Draft approved vacancy descriptions	Purpose, users and consequences determine review
Deployment boundary	Specific tenant configuration and authorised user group	Permissions and data handling may differ
Model component	Supplier-disclosed model family and version	Supports dependency and change analysis where known

Do not invent model details that the supplier has not disclosed. Record the information as unknown, unavailable or supplier-stated, with a date and evidence reference. A commercially branded “AI engine” is not proof of a stable model version. The inventory should represent that uncertainty rather than manufacture precision.

Choose a minimum record that supports ownership

For each use in a defined deployment boundary, record a stable identifier, purpose, business owner, technical owner, users, affected people, lifecycle state, supplier-feature references, data sources, output use and action capabilities. Link the review category, approval decision, conditions, relevant assessments and next review triggers.

Include provenance for the record itself: who supplied the information, when it was checked and which fields remain unverified. Distinguish a user report from a configuration inspection or contract statement. This helps reviewers interpret the inventory without assuming that every populated field has the same evidential strength.

Store controlled evidence references instead of raw personal data or complete prompts. The inventory may still contain sensitive business information, so give it appropriate access and editing rules. A broad discovery view can show that a use exists while detailed architecture or assessment material remains available only to authorised roles.

Use lifecycle states that correspond to reality

Separate proposed, under assessment, approved but not live, live within conditions, paused, retiring and retired. Adapt the labels to the operating model, but define their meaning. “Approved” is not a lifecycle state that proves deployment, and “inactive” should not hide whether data or an accessible account remains.

Record which event changes the state and who confirms it. A project manager may report that a pilot ended, while the system owner must confirm whether the integration was disabled. A retired record should retain the evidence and obligations needed to understand previous operation. Removing it entirely can break incident and supplier-dependency history.

Keep approval status and lifecycle status separate. A live use can have an unresolved approval problem; a fully reviewed proposal can remain unbuilt. Combining these into one green or red label makes discovery harder and encourages teams to adjust a status to avoid uncomfortable reporting.

Worked example: embedded ranking inside an HR suite

Consider a fictional organisation that inventories an HR suite as one product. Initially, teams use an AI feature to draft vacancy descriptions. Later, the supplier introduces a separate product feature that ranks applications. The product name and contract remain the same, but the activity and potential consequences have changed.

The organisation records two use cases: vacancy-description drafting and application ranking. Drafting is planned for authorised teams in two distinct operating configurations, with one already live, while ranking is proposed only in the second configuration. This produces three use-case-to-deployment records: drafting in A, drafting in B and proposed ranking in B. It does not mean that the organisation owns three separate products or three distinct models.

Illustrative linked records for one HR product

Binding	Purpose and state	Important distinction
Drafting in configuration A	Live, within approved source and reviewer conditions	Its permission applies to A's defined users and inputs
Drafting in configuration B	Approved but not yet enabled	Approval is separate from operational activation
Ranking in configuration B	Proposed, awaiting consequence and authority review	The drafting decision does not authorise ranking

The supplier's model information is recorded at the feature level where known, with the evidence date. If the model version is not disclosed, the field says so. The organisation can still govern purpose, permissions, human use and supplier obligations; it cannot claim a model-level change history it does not possess.

When the ranking feature is discovered, the inventory links it to an intake and review case. If the feature is already enabled, the record should say that and route the actual exposure for a decision. It must not present a live capability as merely proposed to make the register look orderly.

Discover AI through several evidence channels

Use procurement records, software ownership lists, architecture reviews, change tickets, approved-tool catalogues and staff declarations. Each channel has blind spots. A purchase register can miss a new embedded feature; a self-declaration can miss a centrally enabled capability; a technical scan can identify a connection without explaining its business purpose.

Reconcile signals rather than treating one channel as the complete truth. Ask product owners to review supplier release information and confirm which features are enabled in their environment. Ask business owners what staff actually do with the feature. Maintain a route for reporting a newly discovered use without requiring the reporter to know every technical detail.

Discovery activities should use appropriate permissions and established organisational processes. Do not turn inventory work into uncontrolled collection of employee prompts or confidential content. Often the relevant first evidence is the existence, owner and operating purpose of the use, followed by a scoped review of necessary detail.

Reconcile records without double-counting the estate

Set counting rules before publishing dashboard totals. Count products when discussing supplier exposure, uses when discussing business decisions and deployments when discussing operating configurations. Label the unit. A single “number of AI systems” can change dramatically depending on whether embedded features and regional configurations are counted separately.

Use stable identifiers and relationships to detect possible duplicates. Similar names can describe different uses, while different project names can refer to the same deployed capability. Merge only after checking purpose, users, data and configuration. Preserve aliases and historical references so existing decisions and tickets do not become orphaned.

Report unknown coverage honestly. An inventory can be well maintained for declared uses while discovery of embedded capabilities remains incomplete. Separate record completeness from estate coverage. A dashboard showing every listed record has an owner does not prove that every AI use has been listed.

Link the inventory to decisions and changes

The inventory should point to the controlling approval decision, its scope and open conditions. Store the decision identifier and current applicability rather than copying a summary that can drift from the authoritative record. If a permission expires, the inventory should expose the affected live uses and owner actions.

Maintain dependency links to data sources, supplier features and important shared components. When one changes, the organisation can identify affected uses and determine which evidence needs review. The change-trigger design supplies the rules; the inventory supplies the map of where those rules apply.

Connect incidents and exceptions without turning the inventory into a full case-management system. A record can show that a live use has an active exception or an unresolved incident, with controlled links to details. Avoid duplicating sensitive narratives across multiple tools solely to make a dashboard look complete.

Assign maintenance to events and accountable owners

Make updates part of normal work: intake creates the initial record, approval links the decision, release confirms the live configuration, change management updates dependencies and retirement records the final state. Periodic attestation then checks whether reality still matches the record rather than recreating it from scratch.

Assign a data steward for the inventory's structure and quality, but keep factual ownership with the relevant business and technical roles. The steward can flag missing information; they should not guess whether a feature is live. A complete-looking record populated by inference can be less reliable than one that visibly identifies the owner of an unknown.

Define escalation for overdue confirmation and departed owners. Transfer open obligations during role changes. The responsibility map should identify who maintains each category of information and who resolves disagreement between a product owner and a business user about actual operation.

Test the inventory with an impact query

Simulate a supplier announcing a change to the ranking feature. Can the team find every related use, its deployment boundary, owner, current permission and required review? Then simulate a data-source restriction and a retired owner. These exercises test whether the relationships are usable, not merely whether fields can be exported.

Check a sample of records against independent operating evidence. Confirm enabled features, actual user groups and decision references. Investigate mismatches and the process that created them. A one-off cleanup may repair the sampled records while leaving the maintenance failure untouched.

Test permissions too: users who only need a portfolio view should not automatically obtain detailed personal-data examples or restricted security design. Ensure that exports and notifications preserve the intended access boundary. The inventory should make governance more visible without creating a new uncontrolled disclosure route.

Design identifiers and relationships for reliable change queries

Use separate stable identifiers for the objects the inventory must connect. A product identifier should remain unchanged when its display name changes. A use-case identifier should remain linked to its decision history even if the project is renamed. A deployment identifier should identify the configured boundary, not merely the supplier's brand. Human-readable names remain useful, but they should not be the only basis for joining records.

For the HR example, one product reference can link to the drafting and ranking feature records. Each use-case record links to the relevant feature and its operating bindings. An approval reference belongs to the scope it actually covers. If one decision covers drafting in configuration A only, it should not be attached at product level in a way that makes ranking in configuration B appear approved.

Relationship checks for the HR inventory example

Check	Defect it can reveal
Every live binding has a use-case owner	A configured feature exists without business accountability
Every approval link matches the binding scope	A product-level permission is being overextended
Every feature has a current supplier-information status	A stale model statement is presented as current fact
Every retired binding retains its relevant history	Earlier decisions become impossible to reconstruct

Allow many-to-many relationships where the reality requires them. A use may rely on more than one model or source, and a shared component may support several uses. Forcing these into a single text cell makes impact queries depend on fragile keyword searches. Even a spreadsheet can use a separate relationship sheet with controlled identifiers and an owner responsible for correcting invalid links.

Validate relationships during import and editing. Flag missing referenced records, duplicate identifiers and approval links whose target has been superseded. Do not silently drop a relationship because an imported name differs slightly. The organisation needs to know whether the discrepancy is a spelling issue, a new object or a material change in the operating boundary.

Run a discovery-to-register reconciliation without overwriting uncertainty

Maintain a reconciliation queue for new signals from procurement, product owners and operating teams. Each signal should identify its source, observed date, candidate product or use and the question that remains. The reviewer decides whether to link it to an existing record, create a new one or retain it as unresolved. This is more reliable than automatically converting every software mention into an AI system.

In the HR example, a release note mentioning application ranking is a signal that the product offers a capability. It does not by itself prove the capability is enabled in the organisation. A tenant configuration check and the business owner's account of actual use can establish a different state. Preserve those evidence distinctions so discovery does not become a source of false positives or false reassurance.

When two sources conflict, retain both observations with dates while assigning resolution. Procurement may report that the feature is not purchased, while an administrator sees a trial capability enabled. Neither should be silently overwritten to match the other. The resulting review can determine what is available, what has been used and which decision is needed for the actual exposure.

Close a reconciliation item with a reason and evidence reference. If it is not an AI use within the inventory's defined scope, record the basis sufficiently to avoid repeated rediscovery. If it remains unknown, keep it visible with an owner and next action. This separates discovery effort from verified inventory coverage and gives leadership a more useful account of what the organisation actually knows.

Use periodic samples to test the reconciliation process itself. Select recent software changes and check whether relevant AI features reached the queue, whether owners responded and whether records changed appropriately. This tests the channels that sustain coverage, not just the completeness of the records already inside the register.

Choose tooling after the information model is clear

A controlled spreadsheet can support a small estate if identifiers, access, ownership and version history are manageable. A workflow or governance platform can support more complex relationships and automation. The decision depends on the operating needs, integration and maintenance burden, not the appeal of a dashboard.

Before buying, test import, export, relationship preservation and evidence portability using representative records. Ask how the tool distinguishes a product from a use case and how it handles unknown model details, changing owners and retired deployments. A tool that forces these distinctions into free text may recreate the same problem with a more expensive interface.

Discuss AI inventory design with Open for AI using your software list, known AI uses and the change questions your teams struggle to answer. The deliverable should be a maintainable linked record system with tested discovery and ownership, not simply a larger catalogue of product names.