Before extending an AI pilot to more departments, ask for a clear system record: what is its specific purpose, which data does it use, who is accountable for operating it, and where do its permissions end? If these answers cannot be assembled, the scaling decision rests on a description of the pilot rather than an operational picture that can be reviewed.

This article proposes an inventory and a record for each use of AI. They help AI leaders, technology teams and business owners identify what needs review before expansion. The fields and examples are practical recommendations, not an official template, compliance certificate or authorization to operate a system.

Define the inventory scope

Record the system as used by the organization, not only the model name. Two departments may use the same model for different purposes, with different data, permissions and risks. Give each use a stable identifier linked to its service or process and operating environment. Reference shared components rather than maintaining uncontrolled copies of their details.

The proposed scope includes internally developed systems, purchased services, AI embedded in applications and restricted pilots. Distinguish a pilot, limited operation, internally authorized operation and a stopped use. These are proposed organizational statuses. Being registered does not mean that a use is accepted or that its assessment is complete.

GOVERN 1.6 in the NIST AI Risk Management Framework addresses mechanisms for inventorying AI systems. Its Playbook describes an inventory as an organized collection of system-related information and artifacts. The framework is voluntary, not Saudi legislation. [1, 2] This direction can inform the work without presenting the following fields as a NIST requirement.

Build a record for an actual decision

Make each field verifiable. Internal data is an inadequate description when inputs include personal data or restricted documents. Human oversight also needs detail: who reviews, what can they see, and can they stop an action before execution? Link evidence to its owner and date. Do not place passwords or access keys in a broadly accessible record.

A proposed system record connects purpose, data, ownership, use boundaries and review.

Distinguish the business owner from the supplier

A supplier can provide model documentation and performance limitations, but does not alone determine whether a use is acceptable within the organization’s process. The business owner explains the intended effect and affected groups. The technical lead confirms components, versions and integrations. Specialists review matters within their remit. The organization identifies who can authorize operation and within what scope; the inventory creates no new approval authority.

SDAIA’s AI Ethics Principles associate accountability with identifiable responsible parties and human oversight across the lifecycle. Its transparency provisions also address documenting system information and decisions. [3] A record should therefore identify actual responsibility, not merely name a department. Specialists determine how national and sector-specific controls apply. The proposed record does not replace that assessment.

Test the expansion boundary with a concrete example

In a hypothetical example, not a reported project or customer case, a department uses an assistant to draft responses from approved internal documents. An employee reads each draft before sending it. The record states that the system cannot send directly, determine beneficiary eligibility or use documents outside its permitted scope. It links tests on representative cases, known errors and a reporting route.

Another team proposes connecting beneficiary data and enabling automatic sending. Updating the user count alone is insufficient. Changes in purpose, data or permissions reopen impact, privacy, security and testing reviews as applicable. Preserve what changed, who requested it, new evidence and the decision owner. Do not transfer the pilot’s findings automatically to the expanded scope.

Where personal data is processed, Article 19 of the PDPL Implementing Regulation requires collection and retention of the minimum personal data necessary for the processing purpose. [4] This is a legal obligation distinct from the proposed record format. Describe data categories, purposes and references to processing decisions; do not copy people’s data into the inventory. Specialists assess legal basis, transfers, retention and any required impact assessment for the case. An inventory alone does not establish compliance.

Update the record when operation changes

Define events that reopen review: a new model version, an additional data source, an integration enabling an operational action, use for a new group, or a material complaint or incident. Record the change date, reason, effect and unresolved issues. A supplier update is not necessarily minor just because the product name is unchanged.

A proposed review cycle revisits the inventory when purpose, data, model or permissions change before a scaling decision.

Assign someone to maintain inventory completeness and updates, while each system owner remains accountable for the accuracy of their record. The AI office can coordinate with existing asset, data and risk registers. Use shared identifiers and references instead of conflicting copies. Review frequency depends on organizational risk and change; this article specifies no universal interval or official passing score.

Use the inventory in the scaling meeting

Start with the current record and identify what would be added and how it differs from the tested scope. Present evidence, limitations and open issues. Record a decision with clear boundaries: a restricted expansion subject to documented conditions, further review, or stopping the proposed use. These are recommended operating options, not automatic outcomes of completing fields.

RMG’s pages describe AI governance and AI office services, including frameworks, policies, risk management and capability building. [5, 6] A discussion with RMG can start with a sample of organizational AI uses and one completed record to define inventory scope, responsibilities and reviews. The aim is to connect information to a traceable operating decision, without promising to eliminate risk or authorize every system merely by registering it.