Menu

Blog Learn Videos About Start learning

Episode 53 of 56 · Governance

An inventory of every AI system

A provider says one of your models shuts down next month. Which systems break? Sixteen AI systems, 55 system–model pairs checked by hand, and three sources scored against them: the documentation read by an AI found 51, a code scanner found 54 but listed 6 things it shouldn't have, and records of what actually ran were never wrong but covered 13. The first hand check missed a model too. Only 1 system of 16 saves the dated model version, and an AI-drafted registry missed that the email assistant sends email.

Lab 17 · Governance9 min read

Video transcript7:24· read along, or click a time to jump there

0:00Cold open

Imagine an AI provider tells us: one of our models shuts down next month.

Which of our systems would break? I couldn’t answer that.

So I tried three ways to find out. The documentation missed some models.

A code scanner listed things the systems never use.

And the records of what ran knew only one model in four.

Even my own careful list had a hole. So which one do you trust?

0:32Intro

Hands-on AI engineering: AI governance, part one.

Today: the inventory. What AI does a company actually run?

0:43Meet Grace

I’m Grace, the AI governance lead at Lantern Outfitters, a made-up outdoor gear shop.

Our teams built sixteen AI systems. You’ve met some in earlier videos, like the refund agent and the email assistant. They’re real code.

Think of a restaurant. It keeps a list of every ingredient in every dish.

When a supplier recalls an ingredient, the kitchen knows which dishes to pull.

An AI inventory is that list. Each system is a dish, and the AI models inside it are the ingredients.

Governing AI takes four things, and the list comes first. Today: the list.

1:3001 · The answer key

To grade each source, I needed the right answer first.

So I read every system’s code myself, and wrote down each model it uses.

Fifty-five in all, counting a model once for each system that uses it. The voice assistant alone uses ten.

That’s my answer key.

Then each source gets three scores.

Found: models it listed, and got right.

Wrong: things it listed that the system doesn’t use.

Missed: models it never listed.

2:0902 · The documentation

First source: the documentation. Every system has a README, a file that describes it.

I had an AI read all sixteen, and list the models each one uses.

It found fifty-one of the fifty-five.

What did it miss? Mostly the embedding model, in three systems.

That’s the model that turns text into numbers, so search can find similar text.

The READMEs don’t name it. Only the code does.

It also listed three models by mistake. Two READMEs mention extra runs on other models, but the code doesn’t normally call them.

Documentation only holds what someone remembered to write down.

2:5903 · A code scanner

Second source: a code scanner.

It searches the code for text that starts like a model name, such as gpt or tts.

It found fifty-four of fifty-five. Almost everything.

But it also listed six things that aren’t models in use.

Three are labels from a timing test, like “tts whole file”. They start with tts, so they look like a model.

Three more are names the code only compares against, to check which model it has. It never calls them.

And it missed CLIP, an image model whose name fits none of its patterns.

3:4304 · What actually ran

Third source: records of what actually ran. Saved answers and run logs that name the model.

Not one entry was wrong. They show what really happened.

But they found only thirteen of the fifty-five.

Only six of the sixteen systems save the model’s name when they run.

Accurate, but rare.

4:1105 · My own list

Now the surprise. My own careful list had a hole too.

The voice assistant uses ten models. By my own notes, my first answer key had only nine.

I’d missed tts-1, a backup voice it also asks when the main one is slow.

The scanner found it. So did the AI reading the READMEs.

I fixed my key, and every score here uses the fixed one.

So no source is the truth, not even a person checking by hand. You check them against each other.

4:4906 · Which version?

One more thing the list needs: which version of a model answered.

Back to the restaurant. For a recall, a label that just says “flour” isn’t enough. You need the batch number.

Model names work the same way. A name like gpt-5.4-nano can point to a newer model tomorrow.

A dated name, like gpt-5.4-nano-2026-03-17, never changes. That’s the batch number.

Six of our systems save which model answered.

Only one saves the dated version: the HR documents assistant.

5:3307 · An AI-drafted registry

Last step: turn the list into a registry. That’s one record card per system, with its purpose, its data, and who owns it.

Writing sixteen by hand is slow, so I had an AI draft them from the READMEs.

It filled seven of the card’s twelve boxes for every system, like its purpose and its users. Filled isn’t the same as right.

Here’s the email assistant. The draft says it takes no actions.

But in use, it sends emails for an employee. That’s an action.

Its README describes how it was tested, not what it does at work.

And I left five fields for people on purpose, like the owner, the risk level, and the review dates. An AI can’t decide those.

6:26Back to Grace

So, back to that warning. A model shuts down next month. Which of our systems use it?

Say it’s gpt-4o-mini. The scanner and the records both point to the same two systems: the email assistant and the HR documents assistant.

The scanner finds almost everything.

Records of what ran check its list. Most systems keep none, so I’d turn them on, or read the provider’s usage logs.

Every answer should save the dated model version.

And each owner fills in what only they can decide.

Next, we sort the list by risk. Which of our systems would Europe’s AI law call high-risk?

7:14Summary

Every source misses something.

The list is right only when the sources check each other.Grace: Checked twice.

Key takeaways

✓An AI inventory is a company's ingredient list: each system is a dish, and the models inside it are the ingredients. When a provider retires a model, the list tells you which systems to fix. Governing AI takes four things (a list, a launch gate, an incident procedure, a review of every provider), and the list comes first.
✓The documentation, read by gpt-5.4-mini, found 51 of 55 (93%). It missed models only the code names (the embedding model in three systems, a reranker in one) and listed 3 models that two READMEs mention from side tests the code doesn't run by default.
✓A code scanner that looks for text starting like a model name found 54 of 55 (98%), plus 6 look-alikes: three timing-test labels that start with tts, and gpt-5 and gpt-4o, names the code only compares against. It missed CLIP, whose name fits none of its patterns.
✓Records of what ran (saved answers and run logs) were never wrong, but found 13 of 55 (24%): only 6 of 16 systems save the model's name, and none records its embedding calls. My own first answer key missed tts-1, a backup voice; the scanner found it. No source is the truth: check them against each other.
✓A plain name like gpt-5.4-nano can point to a newer model tomorrow; a dated name like gpt-5.4-nano-2026-03-17 never changes. 6 of 16 systems save which model answered; only 1, the HR documents assistant, saves the dated version.
✓An AI drafted one registry card per system from the READMEs and filled 7 of 12 fields for all 16. On "does it act" and "does it affect a person" it agreed with our labels 27 of 32 times, and called the email assistant, which sends email, a system that takes no actions. Owner, business unit, risk level and review dates are left for people.

A provider tells you one of your models shuts down next month. Which of your systems would break? This chapter builds the list that answers that: an inventory of every AI system a company runs, and the models inside each one. It tries three ways to build it, scores each against a hand check of the code, and then drafts the registry that turns the list into one record card per system.

The source is Lab 17 (Governance), script 01_inventory.py, recorded in October 2026; the video uses the recorded results, no new calls. The company, Lantern Outfitters, is made up. Its 16 AI systems are real code: the earlier labs in this course, like the refund agent and the email assistant from earlier chapters. The README readings and registry drafts are recorded calls to gpt-5.4-mini. This is the first of four chapters on governance: next come risk levels, a launch checklist, and incident response.

What an inventory is

Think of a restaurant. It keeps a list of every ingredient in every dish, so when a supplier recalls an ingredient, the kitchen knows which dishes to pull. An AI inventory is that list: each system is a dish, and the AI models inside it are the ingredients.

Governing AI takes four things kept up to date: a list of every system, a gate before launch, a procedure for incidents, and a review of every outside provider. The list comes first, because the other three work from it.

The answer key

To grade each source you need the right answer first. The lab read every system's code by hand and wrote down each model it calls with its default settings: 55 entries, counting a model once for each system that uses it. The voice assistant alone uses 10.

Each source then gets three scores:

Found: models it listed, and got right.
Wrong: things it listed that the system doesn't use.
Missed: models it never listed.

Three sources

Source	Found (of 55)	Wrong	Missed
The documentation (READMEs read by `gpt-5.4-mini`)	51 (93%, 83–97%)	3	4
A code scanner	54 (98%, 90–100%)	6	1
Records of what actually ran	13 (24%, 14–36%)	0	42

The documentation. Every system has a README. An AI read all sixteen and listed the models each one uses. It missed the embedding model (the model that turns text into numbers, so search can find similar text) in three systems, and a reranker in one: the READMEs don't name them, only the code does. It also listed three models by mistake: two READMEs mention extra runs on other models that the code doesn't call by default. Documentation only holds what someone remembered to write down.

A code scanner. A search of the code for quoted text that starts like a model name, such as gpt or tts, or a Hugging Face name with a known model family:

# inventory.py
MODEL_LITERAL = re.compile(
    r"""["']((?:gpt|o[134]|chatgpt|text-embedding|whisper|tts|claude|gemini)[-\w.]*"""
    r"""|[\w.-]+/[\w.-]*(?:Qwen|Llama|llama|Mistral|mistral|gemma|Gemma|Phi|phi|deberta|bge|MiniLM|e5|SmolLM)[\w.-]*)["']""")

It found almost everything, and six things it shouldn't have. Three are labels from a timing test in the voice assistant, like "tts_whole_file": they start with tts, so they look like a model. Three more are gpt-5 (twice) and gpt-4o, names the code only compares against to check which model it has. It never calls them. And it missed CLIP (openai/clip-vit-base-patch32), an image model whose name fits none of its patterns.

What actually ran. Saved answers and run logs that name the model. Not one entry was wrong: they show what really happened. But only 6 of the 16 systems save the model's name when they run, and none records its embedding calls. Accurate, but rare.

Switch between the sources and see what each got wrong, system by system:

Try it · Three ways to list a company's AILab 17 · script 01 · 16 systems, 55 pairs

Source:

gpt-5.4-mini read each system's README and listed the models it uses.

Found (of 55)

51

Wrong: listed, not used

3

Missed: never listed

4

It missed the models only the code names (the embedding model in three systems, the reranker in one) and listed models two READMEs mention from side tests the code doesn't run by default.

found+ wrong− missed

System	Models, by this source
Help assistant + SQL tool	gpt-5.4-minigpt-5.4-nanotext-embedding-3-small− cross-encoder/ms-marco-MiniLM-L-6-v2
Answer grader	gpt-5.4-minigpt-5.4-nano− text-embedding-3-small
Chat with memory	gpt-5.4-nanotext-embedding-3-small+ gpt-4o-mini+ gpt-5.4-mini
Employee assistant	gpt-5.4-nano+ gpt-5.4-mini
Self-hosted models	Qwen/Qwen3-0.6BQwen/Qwen3-1.7BQwen/Qwen3-4BQwen/Qwen3-8Bgpt-5.4-minigpt-5.4-nano− text-embedding-3-small
Hardened refund agent	gpt-5.4-minigpt-5.4-nano− text-embedding-3-small

The answer key is a hand check of each system's code. Its first version missed tts-1 in the voice assistant; the scanner found it, and these scores use the fixed key.

My own list had a hole too

The voice assistant uses ten models. By the author's notes, the first answer key had only nine: it missed tts-1, a backup voice the assistant also asks when the main one (gpt-4o-mini-tts) is slow. The scanner found it, and so did the AI reading the READMEs. The key was fixed, and every score here uses the fixed one.

So no source is the truth, not even a person checking by hand. You check them against each other.

A model shuts down next month

Back to the question. Say the model being retired is gpt-4o-mini. The scanner and the records both point to the same two systems: the email assistant and the HR documents assistant. The README reading adds a third, the chat assistant with memory, whose README only mentions the model. Try other models:

Try it · A model shuts down next monthLab 17 · script 01 · recorded run

The provider is retiring a model. Which of our systems would break?

Source	Says these systems use it
Answer key (by hand)	Email assistantHR documents assistant
The documentation	Email assistantHR documents assistant+ Chat with memory
A code scanner	Email assistantHR documents assistant
What actually ran	Email assistantHR documents assistant

The scanner and the records agree on the same two systems. The README reading adds a third that only mentions the model.

The pattern holds across them: the scanner gives coverage, the records confirm what really ran where they exist, and the README reading is the one that knows about CLIP.

Which version answered?

For a recall, a label that just says "flour" isn't enough; you need the batch number. Model names work the same way. A name like gpt-5.4-nano can point to a newer model tomorrow. A dated name, like gpt-5.4-nano-2026-03-17, never changes: that's the batch number. The code asks for the name; only the reply says which dated version answered.

	Systems (of 16)
Save which model answered	6
Save the dated version	1, the HR documents assistant (`gpt-4o-mini-2024-07-18`, `gpt-5.4-mini-2026-03-17`, `gpt-5.4-nano-2026-03-17`)

The other 15 can say "gpt-5.4-nano" at best, which is the name of whatever the provider serves today. Chapter 52 showed why the reply's dated name is the one to log.

An AI-drafted registry

The last step turns the list into a registry: one record card per system, with its purpose, its data, who uses it, and who owns it. The lab's card has 12 fields. Writing sixteen by hand is slow, so gpt-5.4-mini drafted them from the READMEs:

It filled 7 of the 12 fields for every system: purpose, users, data it reads, data sensitivity, whether it affects a specific person, whether it takes actions, and known weaknesses.
The other 5 were left for people on purpose, by the prompt: owner, business unit, risk level, and the last and next review dates. An AI can't decide those.
Filled isn't the same as right. On the two fields that decide risk most, "does it take actions?" and "does it affect a specific person?", the draft agreed with our labels on 27 of 32 judgments (84%, 68–93%).

The clearest miss is the email assistant. The draft says it takes no actions; at work, it sends emails for an employee. Its README describes how it was tested (guardrails against attacks), not what it does at work, so the draft reads like a test report. The draft registry is about 2,100 words, roughly 10 minutes to read.

Try it · An AI drafts the registryLab 17 · script 01 · recorded gpt-5.4-mini drafts

One record card per system, drafted from its README. The two fields that matter most for risk are “does it take actions?” and “does it affect a specific person?”. The draft and our labels disagreed on 5 of 32. Pick one:

What it does at work (the owner's line)

An email assistant that reads an employee's mail, calendar and files and sends emails on their behalf.

Field	AI draft, from the README	Our label
Purpose	Measures what guardrails actually stop and what they cost against public attacks on PII, prompt injection, secret leakage, lethal-trifecta email agents, and MCP tool supply-chain changes.	·
Users	Lab users / practitioners running the scripts in this lab	·
Data sensitivity	personal	·
Takes actions	no	yes
Affects a person	no	no
Owner	left for a person
Business unit	left for a person
Risk level	left for a person
Last review	left for a person
Next review	left for a person

Our reason: an email agent that sends email for its user. The README describes the lab's experiments, not what the system does at work, so the draft reads like a test report.

Not shown: data read and known weaknesses, also drafted for all 16. The card has 12 fields; the AI filled 7 for every system, and the prompt left the 5 people fields empty on purpose.

Also in the lab

Where to start with 200 repositories. The lab's answer: the code scanner, for coverage, checked against runtime records from an API gateway or the provider's usage reports. Those also catch AI no repository mentions: a spreadsheet plugin, a feature someone switched on in a software-as-a-service tool, staff using public chatbots (visible in expense reports, sign-in logs and network traffic, not code).
The registry the lab ships. Script 06 writes deliverables/ai_system_registry.md from the data: models from the code (not the draft), the dated version where one was recorded, the risk levels from the next chapter, and "owner" in every field a person has to fill. A system with a blank owner field fails the launch gate (chapter 55).

What to do

Build the list from the code, with a scanner, and read its matches: some will be look-alikes.
Check it against records of what ran. Turn them on where they're off, or read your provider's usage logs.
Use the documentation for what code can't say: why the system exists and who it's for.
Save the dated model version with every answer.
Let an AI draft the registry, then have each owner correct it, starting with "does it act?" and "does it affect a person?".
Fill the people fields: an owner, a business unit, a risk level, review dates.

Caveats

The company is a course. Its 16 systems are labs; their READMEs describe experiments, which is part of why the drafts read like test reports. A real company's documentation may be closer to use, or further.
The answer key is a judgment. It lists models called with default settings; a side test run with another model doesn't count. Its first version was wrong once.
The scanner is a quick one. A better pattern list would catch CLIP and skip the timing labels; the point is that every scanner has a pattern list, and its misses are names that don't fit.
Runtime evidence depends on what was run. The records come from the labs' data folders, which exist only where a lab was run and saved its answers.
Small numbers. 55 pairs and 32 judgments: the ranges in brackets are wide.

The checklist

Run a scanner over every repository and review each match.
Collect what ran: gateway logs, provider usage reports, saved answers with the model's name.
Compare the two lists and chase every difference.
Record the dated model version on every call.
Draft one registry card per system, and have its owner confirm "acts" and "affects people".
Fill owner, business unit, risk level and review dates, by people.
When a provider retires a model, query the list, and keep it up to date as systems change.

Practice: score the inventory

Write the scanner, score a source against the answer key, find the systems that use a retiring model, tell a dated version from a plain name, and list the registry fields left for people. The tests use the lab's answer key and what each source listed, and expect its numbers: 51, 3 and 4; 54, 6 and 1; 13, 0 and 42; and the same two systems for gpt-4o-mini.

Try it · Practice in PythonRuns in your browser · ⌘/Ctrl + Enter to run

inventory_practice.py72 lines

"""
Practice: build an AI inventory the way Lab 17's script 01 does. Three sources say which models
each system uses (the README read by an AI, a code scanner, records of what ran), and a hand check
of the code is the answer key. You'll write the scanner, score each source against the key, ask
"which systems use this model?", spot a dated model version, and list the registry fields an AI
draft leaves for people.

Fill in the TODOs, then run the tests:
    pytest test_inventory_practice.py        (locally)
or press "Run tests" on the chapter page.
"""
import re

# The lab's scanner pattern: a quoted string that starts like a model name (gpt, tts, whisper, ...),
# or an org/name on Hugging Face with a known model family in it.
MODEL_LITERAL = re.compile(
    r"""["']((?:gpt|o[134]|chatgpt|text-embedding|whisper|tts|claude|gemini)[-\w.]*"""
    r"""|[\w.-]+/[\w.-]*(?:Qwen|Llama|llama|Mistral|mistral|gemma|Gemma|Phi|phi|deberta|bge|MiniLM|e5|SmolLM)[\w.-]*)["']""")

def canonical(name: str) -> str:
    """Compare names the way a reviewer would: lowercase, without an 'openai/' or 'mlx-community/'
    prefix or a 4-bit/8-bit tag, and with 'Qwen3-0.6B' the same as 'Qwen/Qwen3-0.6B'. (Given.)"""
    n = name.strip().lower()
    if not n.startswith("openai/clip"):
        n = n.removeprefix("openai/")
    n = re.sub(r"[-_@](4|8)-?bit$", "", n).removeprefix("mlx-community/")
    return {"qwen3-0.6b": "qwen/qwen3-0.6b", "qwen3-1.7b": "qwen/qwen3-1.7b", "qwen3-4b": "qwen/qwen3-4b",
            "qwen3-8b": "qwen/qwen3-8b"}.get(n, n)

def scan(code: str) -> set[str]:
    """Every model-like string literal in a piece of code (use MODEL_LITERAL)."""
    # TODO
    raise NotImplementedError

def score(listed: list[str] | None, truth: list[str]) -> dict:
    """Score one source for one system against the answer key, comparing canonical names.
    listed is None when the source has no record of this system at all (then it missed everything).
    Return {"found": count listed and right, "wrong": sorted canonical names listed but not in the key,
            "missed": sorted canonical names in the key but not listed}."""
    # TODO
    raise NotImplementedError

def totals(source: dict, key: dict) -> dict:
    """source: system -> list of models (or None); key: system -> list of models.
    Add up score() over every system in the key: {"found": n, "wrong": n, "missed": n}."""
    # TODO
    raise NotImplementedError

def systems_using(source: dict, model: str) -> list[str]:
    """The systems a source says use this model (canonical match), sorted. A model is shutting down:
    which systems break?"""
    # TODO
    raise NotImplementedError

def is_dated(name: str) -> bool:
    """True for a dated model version like 'gpt-5.4-nano-2026-03-17' (ends in -YYYY-MM-DD),
    False for a plain name like 'gpt-5.4-nano', which the provider can point at a new version."""
    # TODO
    raise NotImplementedError

def left_for_people(entry: dict) -> list[str]:
    """The fields of a drafted registry entry that are still empty (None, "" or []), sorted."""
    # TODO
    raise NotImplementedError

↓ inventory_practice.py ↓ test_inventory_practice.py ↓ inventory_solution.py

Quiz

Try it · Check your understanding0 of 6 answered

1.What is an AI inventory for, in the restaurant picture?
2.The documentation, read by an AI, found 51 of 55. What did it miss, and why?
3.The code scanner found 54 of 55. What were its 6 wrong entries?
4.Records of what ran were never wrong. Why not use only them?
5.Why does the inventory need the dated model version, not just the name?
6.An AI drafted the registry from the READMEs. What should you trust it for?

Check your understanding

Try each question before opening its answer.

What is an AI inventory, and why does it come first?

A list of every AI system the company runs and the models inside each one, like a restaurant's ingredient list. The launch gate, the incident procedure and the provider reviews all start from knowing what you run.

What does each of the three sources miss?

The documentation misses what nobody wrote down (the embedding model in three systems) and adds models from side tests. The scanner adds look-alikes (timing labels, names used only in checks) and misses names that fit no pattern (CLIP). Records of what ran are accurate but exist for only 6 of 16 systems.

Your hand-checked answer key disagrees with the scanner. Who's right?

Look at the code. In the lab the first key missed tts-1, and the scanner was right. No source is the truth; differences between them are where to look.

Why save gpt-5.4-nano-2026-03-17 and not just gpt-5.4-nano?

The plain name can point to a newer model tomorrow; the dated one never changes. It's the batch number in a recall. Only 1 of the 16 systems saved it.

An AI drafted every registry card. What do you still do?

Have each owner check it, especially "does it take actions?" and "does it affect a person?" (the draft missed that the email assistant sends email), and fill the five fields only people can: owner, business unit, risk level, last and next review.

A provider retires gpt-4o-mini. How do you answer "which systems use it?"

Query the inventory: the scanner and the records both point to the email assistant and the HR documents assistant. Where a system keeps no records, turn them on or read the provider's usage logs to confirm.

Next up: Chapter 54 sorts the list by risk: risk levels under the EU AI Act, and which of these systems Europe's AI law would call high-risk.

Learning something useful?

New labs, articles, and videos on evaluating and testing AI systems come out regularly. Follow along so you don't miss the next one.

Subscribe on YouTube