You Can't Govern What You Can't See

The first time we ran the inventory tooling against our own platform, it found 6.9 gigabytes of model weights on disk that no registered system claimed.

Not malware. Not an intrusion. Just the ordinary sediment of a working platform: an experiment someone spun up, a model pulled for a test and never cleaned, a service that quietly outlived its purpose. Harmless-looking, every one. And collectively, a governance blind spot the size of a small language model — because you cannot apply a single control to a system you don’t know exists. Last time I argued that governance has to be technically enforced or it’s just a wish. This article is about the thing enforcement stands on. Before you can enforce anything, you have to see everything.

The inventory: one row per system, not per model

The unit of an AI inventory is the system — a thing that does a job for a user — not the model. One row per system, and the fields are chosen so that each one earns its place by answering a governance question:

• System ID, name, owner (team and individual). Accountability. Every system has a name attached to it, so “who owns this” is never a meeting.
• Business purpose and user population. Risk context. A tool ten internal analysts use is not the tool the whole internet talks to.
• Model(s): provider, version, hosting. The supply chain. Self-hosted or SaaS API, pinned version, and — for self-hosted — a hash.
• Data classifications touched. Privacy and exposure, using the same taxonomy the data-security function already maintains. Governance doesn’t invent its own data classes; it consumes theirs.
• Tools and actions exposed, from read-only to money-moving. This is the blast radius.
• Gateway key ID(s). The linkage to enforcement — the row in the registry ties to the actual credential that makes the system work.
• Risk tier and lifecycle status. Covered below.

On our platform this is ai-inventory.yml: eleven systems and six shared components, versioned in the repo, human-readable, and — critically — load-bearing. It isn’t documentation about the platform. It’s the thing the key-minting logic reads. Which is exactly why it stays current: a stale inventory is a broken deploy, not a stale doc.

The AI-BOM: the corpus is attack surface

A software bill-of-materials lists your dependencies. An AI bill-of-materials has to list a stranger set of things, because AI systems have components that classic SBOMs never imagined — and every one of them is a way in.

Each system carries a machine-readable AI-BOM, regenerated by CI, listing:

• Model artifacts — provider, version pin, hash if self-hosted, license, hosting, and the data-processing agreement reference if it’s a SaaS model.
• Embedding models — because they silently change what retrieval returns. Swap an embedding model and every answer your RAG system gives shifts, with no code change and no obvious signal. It belongs in the bill so the change is visible. (We enforce a single embedding standard, bge-m3 at 1024 dimensions, for exactly this reason.)
• Knowledge corpora — each collection with its source type, its curation-pipeline reference, its data classification, its document count. The corpus is in the bill of materials because the corpus is attack surface. A poisoned document in a retrieval store is a code injection with a friendlier face.
• Prompts and templates — versioned and hashed. A prompt change is a code change, and it gets reviewed like one.
• Tool contracts — the JSON schema and authorization mapping for every action the system can take. (Next article is entirely about these.)
• Evaluation assets — the test suites, including the injection suite, with the last passing run recorded.
• Conventional dependencies — the ordinary SBOM, including the version of any agent/MCP runtime.

The AI-BOM isn’t paperwork. It’s the precondition for a production key (no current bill, no key), the thing a nightly job matches against new model advisories, and the record that lets you answer “which systems used model X version Y over which corpora on which date” from history instead of from memory. The audit answer should be an artifact, not a memory.

Risk tiers: proportion is the whole game

Governing a read-only FAQ bot exactly as hard as a system that can execute trades is how you get a program everyone routes around. Control has to be proportional, and proportionality needs tiers. Ours are T0 through T3:

• T0 — isolated sandbox. A personal, air-gapped experiment. Scoped credential, and little else.
• T1 — internal, assistive. An internal knowledge-base chat where a human reviews every output. Add a budget, a rate limit, and an attributable trace.
• T2 — external or autonomous. A public-facing chat surface, or a scheduled agent that acts without a human in the loop each time. Now add named oversight, guardrails, and an evaluation gate.
• T3 — consequential. Anything that writes to a system of record or moves money. Add two-person approval on top of everything else.

The escalation is cumulative and, crucially, it’s executable — the mapping from tier to required controls isn’t a paragraph in a policy nobody reads, it’s a MATRIX{} structure in the code that generates the bill-of-materials. The tier is a field; the field drives the controls; the controls are checked in CI. A T3 system that’s missing its two-person approval isn’t out of policy in the abstract. It fails a gate.

Shadow AI: five signals, none of them self-reporting

Everything so far governs the AI you put in the inventory. The harder problem is the AI that’s running and isn’t in it — the team that expensed a SaaS agent, the developer who dropped an SDK and a personal API key into a repo, the browser extension quietly shipping data to a model. You will never find shadow AI by asking people to self-report. You find it with signals they don’t control:

1. Egress telemetry — outbound traffic matched to a maintained feed of AI-provider endpoints. Traffic to a provider from a source that maps to no registered gateway key is a candidate. (Match on hostname and identity, not IP — the anycast lesson from the last article.)
2. Identity-layer audit — new OAuth grants and enterprise app registrations for AI scopes. When someone connects an unregistered AI app to your identity provider, that grant is a flare.
3. Code-level detection — CI scanning that flags AI SDK imports and provider-key patterns in repos whose systems aren’t in the registry.
4. Procurement and expense — a standing finance feed for AI-vendor charges. A card statement is the fastest shadow-AI detector ever built.
5. Endpoint inventory — managed-device extension and application inventories matched against known AI tools.

Each signal is deterministic and none depends on anyone volunteering the truth. When our own tooling first ran, alongside the orphan weights it surfaced three systems quietly using a master key and fourteen keys running with no budget or rate limit at all. That’s not an indictment of the team; it’s what the first honest look always finds.

The paved road has to be faster than the goat path

Here’s the part that separates governance from bureaucracy. When you find shadow AI, the instinct is to block it. Block-first is how you manufacture shadow AI — because most shadow AI is unmet demand, and demand you refuse to supply doesn’t evaporate, it hides.

So discovery opens a ticket, and the default disposition is sanction and migrate: register the system, issue it a scoped key, onboard it to the paved road — fast. Blocking is the exception, reserved for real exposure (customer PII, payment-adjacent data, credentials), and even then it’s paired with an incident process, not just a firewall rule. The governing principle is blunt: the paved road has to be faster than the goat path. If registering your AI system properly takes two weeks and a card-bought tool takes two minutes, you have chosen your shadow-AI problem. Supply is the durable fix. Every blocked tool still gets recorded — as a rejected inventory entry — so the same thing gets caught faster next time and the reasons never have to be re-litigated.

What didn’t work

Our first inventory was a wiki page, and it was a lie within a month. Hand-maintained inventories decay at exactly the rate the platform changes, which is to say constantly. The only inventory that stays true is one the system needs in order to function — when minting a key reads the inventory, the inventory can’t drift, because drift breaks deploys. Make your source of truth load-bearing or it will quietly become fiction.

We tried to classify data ourselves. For about a week the inventory had our own ad-hoc data labels, which promptly disagreed with the data-security team’s taxonomy and created two vocabularies for the same facts. Governance functions that annex adjacent mandates create exactly the confusion they exist to prevent. Now the inventory’s data-class fields consume the existing taxonomy. Own your control points; borrow everyone else’s classifications.

Takeaways you can use

1. Inventory systems, not models — one row per thing-that-does-a-job, owned by a named human.
2. Put the corpus and the embedding model in the AI-BOM. They’re the components a normal SBOM misses and an attacker loves.
3. Make the inventory load-bearing. If the platform doesn’t need it to run, it will rot. Tie key issuance to it.
4. Tier by consequence and make the matrix executable. Proportional control, checked in CI, not argued case by case.
5. Hunt shadow AI with signals people don’t control — egress, identity grants, code scans, expenses, endpoints. Never self-reporting.
6. Default to sanction-and-migrate, and make it fast. Block-first breeds the shadow AI you’re trying to kill.

Next

You can now see every AI system, know what each one is made of, and know how much it’s allowed to do. That last part — what it’s allowed to do — is where enforcement gets teeth. The next article is about the moment an AI tries to take an action, and the deterministic layer that decides whether it may: the model proposes, and the workflow disposes.

What would your first honest AI inventory turn up? In my experience the answer is never “nothing.” I’d genuinely like to know what you’d expect to find.

---

Paul Vilevac is the founder of Bleenq, with 31 years building secure, scalable production systems, now applied to AI/ML platforms and the way they’re governed. CISSP, CISA, AWS Solutions Architect. This is the second article in Governance That Bites, a series on making AI governance technically enforced rather than merely advisory — drawn from the governance model we run in the open on ai-homelab. If you want this built against your real systems, that’s what Bleenq does.