# Build an AI use inventory a regulator can read

How a utility builds a list of every AI use that a regulator can read. One row per use, with the decision it shapes, its safeguards and the evidence that they work.

Author: Murali Sid (https://linkedin.com/in/muralisid)
Source: https://www.agenticarchitectureskills.com/use-cases/ai-use-inventory
Published: 2026-09-19
Updated: 2026-10-15
Licence: CC BY-SA 4.0, https://creativecommons.org/licenses/by-sa/4.0/
Cite as: Murali Sid. Build an AI use inventory a regulator can read. Agentic Architecture Skills. https://www.agenticarchitectureskills.com/use-cases/ai-use-inventory

---


A regulator asks a utility to list every place it uses AI, and to show how each use is governed. Most utilities can name their headline projects. Few can list the AI inside vendor products, office tools and older analytics. This page gives a template for the list and the policies beside it. The short answer: build the list from the agent registry, not from a survey. A named person signs it, because it is a formal regulatory record.

## What regulators have asked [#what-regulators-have-asked]

On 17 September 2026 the New York Public Service Commission opened Case 26-M-0552. Twelve named utilities must file an inventory of their AI uses within 60 days, with the policies that govern them. The commission names seven risks: hallucinations, algorithmic biases, transparency, data privacy, misconfiguration, cybersecurity attacks and functional brittleness. Reports every six months follow, according to coverage that day. Arizona opened Docket AU-00000A-26-0060 on AI at energy and water utilities on 24 March 2026. A utility elsewhere can use the same list for its board and auditors.

## The systems involved [#the-systems-involved]

The list lives in the [governance, risk and sovereignty layer (R11)](/layers/r11-governance-risk-sovereignty). It draws on four other [layers](/layers).

| Layer                                                                              | Systems                                                                                                                                                   |
| ---------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [Governance, risk and sovereignty (R11)](/layers/r11-governance-risk-sovereignty)  | The risk and compliance tool, or GRC tool (ServiceNow IRM, Archer, Protecht). The obligations register of rules the utility must meet. The agent registry |
| [Agent platform (R07)](/layers/r07-agent-platform)                                 | Admin consoles of vendor products with AI built in. Agent builders                                                                                        |
| [Observability and FinOps (R12)](/layers/r12-observability-and-finops)             | Traces and logs that show each safeguard working. Software and cloud invoices                                                                             |
| [Systems of record (R04)](/layers/r04-systems-of-record)                           | Supplier contracts in the ERP. The records system that keeps each filing                                                                                  |
| [Productivity and collaboration (R08)](/layers/r08-productivity-and-collaboration) | Spreadsheets and email used today. Office assistants such as Microsoft 365 Copilot                                                                        |

## How it runs today [#how-it-runs-today]

Today the list is built by hand (typical, unsourced).

1. A risk lead emails a survey to each business unit.
2. Units answer in spreadsheets, naming their headline projects.
3. The lead emails suppliers to ask which products contain AI.
4. The lead merges the answers and checks them against the obligations register by hand.
5. A named executive signs the filing.

AI inside vendor products is often missed. Few rows link to evidence that a safeguard works. Each filing starts again from a stale spreadsheet.

## How agents run it [#how-agents-run-it]

The registry record feeds the inventory. Each agent gets one record in the registry at the register stage of the [agent lifecycle](/architecture/agent-lifecycle). The [registry record](/architecture/agent-lifecycle#the-registry-record) holds the owner, purpose, tools, [risk tier](/architecture/risk-profile), autonomy and highest data class. Most inventory columns are fields in that record.

1. **Draft one row per record.** Agent. It reads the registry and writes draft rows in the GRC tool.
2. **Find AI the registry misses.** Agent. It reads invoices, supplier contracts and network traffic to known AI services. It writes candidate rows marked "not registered".
3. **Confirm each candidate.** The owning team confirms or rejects it. A confirmed use gets a registry record first.
4. **Collect the evidence.** Agent. It asks the owning team for the record behind each safeguard. It checks the date and scope, and passes gaps to a reviewer.
5. **Review.** The compliance lead reviews the draft in the GRC tool.
6. **Attest.** A named person signs the filing. The inventory is a [formal regulatory record](/architecture/deterministic-zones#formal-regulatory-records), so the agent never files or signs.

The pattern is the same as [collecting compliance evidence](/use-cases/compliance-evidence).

## What counts as an AI use [#what-counts-as-an-ai-use]

We propose one test. Does a learned or generative model shape a decision, record, customer contact or physical action? Four groups are easy to miss. They are AI inside purchased products, older machine learning, staff use of assistants, and AI used by contractors. Fixed rules and thresholds are not AI uses.

## One row per use [#one-row-per-use]

Each row answers six questions. The [CSV template](/figures/use-cases/ai-use-inventory-template.csv) has every column.

| Question                       | What to record                                                                                              |
| ------------------------------ | ----------------------------------------------------------------------------------------------------------- |
| 1. What is it, and who owns it | A plain name, the business function, a named owner in the business, the status and its date, and the source |
| 2. What kind of AI is it       | The technique, the model and supplier, where it runs, its learning level, and who approves changes          |
| 3. What does it touch          | The information it reads, the systems it writes, any path to control systems, and where data is kept        |
| 4. What decision does it shape | The decision, the role of the output, the autonomy level, any zone touched, and the final decision maker    |
| 5. How is each risk handled    | A tested safeguard for each named risk, with the test and its date                                          |
| 6. Where is the evidence       | The evaluation, the logs, incidents since the last report, and the next review                              |

A regulator reads question 4 most closely, so record the decision, not the technology. Record the autonomy level as the use runs today, on the [autonomy contract](/architecture/autonomy-contract). The levels run from manual (A0) and assisted (A1) to delegated tasks (A2). Above those sit supervised autonomy (A3), managed autonomy (A4) and governed lights-out (A5). Learning runs from fixed (L0) through curated (L1) and reviewed (L2) to continuous learning inside limits (L3).

Note any of the four [deterministic zones](/architecture/deterministic-zones) the use touches: access, money, safety actuation or formal records. Say where each boundary is enforced. "The prompt tells the model not to" is not a control. A control is a rule, an approval step, or a system outside the model.

## Safeguards for the seven risks [#safeguards-for-the-seven-risks]

For each named risk, record a safeguard that can be tested, the test and its date. Good examples are answers from approved sources only, and outcomes compared across customer groups. Others are a tested rollback, and a manual fallback with the date it last ran. The [security practices](/security) cover prompt injection.

## The policies beside the list [#the-policies-beside-the-list]

The order asks for policies as well as the list. We propose eight, each with an owner and a review date. They cover acceptable use, intake and approval, procurement, and human oversight. They also cover deterministic boundaries, change control, incident response and records. The boundaries policy says models may take permission away, never grant it.

## Three worked rows [#three-worked-rows]

These rows illustrate proposed uses elsewhere in this guide. They are not deployed systems.

|                 | Vegetation inspection                          | Customer bill explanation                                                   |
| --------------- | ---------------------------------------------- | --------------------------------------------------------------------------- |
| Decision shaped | Which spans a planner inspects first           | What a customer is told about an approved bill                              |
| Autonomy        | Delegated tasks (A2)                           | Delegated tasks (A2) for answers, assisted (A1) for the rest                |
| Zone            | None. It does not approve cutting or switching | Money and formal records. It cannot change an account, bill or payment plan |
| Key safeguard   | Field inspection confirms every finding        | Answers limited to the customer's own records                               |

They follow the [vegetation inspection example](/use-cases/vegetation-inspection) and the [customer-service blueprint](/library/blueprints/departments/customer-service).

## Measure whether it works [#measure-whether-it-works]

Check coverage against an independent sample, such as supplier contracts. Track the share of rows with a tested safeguard, and the age of the oldest evaluation. Count the uses an audit finds that were not on the list.

## Evidence and limits [#evidence-and-limits]

This template follows the press release for Case 26-M-0552 and general governance practice. It was written before any utility filed. The order itself governs what a New York utility must file, and other commissions may ask different questions.

The autonomy levels and the deterministic zones are this guide's own terms. Explain them in plain words in a filing. The commission has not named its frameworks. The NIST AI Risk Management Framework and ISO/IEC 42001 are two common ones.

## Next step [#next-step]

Score each agent on [the risk profile](/architecture/risk-profile). Return to [utilities](/use-cases/utilities) for the worked examples.

<details>
  <summary>
    Explore this topic
  </summary>

  * [New York PSC launches inquiry into AI at utilities](https://dps.ny.gov/news/psc-launches-inquiry-use-artificial-intelligence-new-yorks-utilities), 17 September 2026, Case 26-M-0552. Accessed 19 September 2026.
  * [New York to begin monitoring utilities' use of AI](https://www.wskg.org/2026-09-17/new-york-to-begin-monitoring-utilities-use-of-ai), WSKG, 17 September 2026. The source for reports every six months. Accessed 19 September 2026.
  * [Arizona Corporation Commission opens an inquiry into AI at utilities](https://azcc.gov/lmarquezpeterson/news/2026/03/27/commissioner-lea-m%C3%A1rquez-peterson-opens-formal-inquiry-into-potential-use-of-artificial-intelligence-in-utilities--operations), 27 March 2026, Docket AU-00000A-26-0060. Accessed 19 September 2026.
  * [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework), 2023.
  * [Government guidance on integrating AI in operational technology](https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/4347041/nsa-cisa-and-others-release-guidance-on-integrating-ai-in-operational-technology/), December 2025.
</details>
