Your Regulator Will Ask for Your AI Inventory. Do You Have One?

A colleague at a Top 15 bank got a request from OCC examiners last year: produce a complete inventory of every AI and machine learning model in production, including data lineage, approval records, and performance metrics. His team needed three weeks and four all-hands sprints to assemble something presentable. Three weeks. For a list of what they already owned. If that sounds familiar, you have a governance gap that no policy document will fix.

The AI Inventory Problem Is Worse Than You Think

Most enterprises I've worked with can tell you how many servers they run. They can tell you how many applications are in production. They can produce a software license audit in 48 hours. But ask them to list every AI model, every ML pipeline, every fine-tuned LLM, and every RPA bot with a decision-making component? Silence.

A 2025 survey by MIT Sloan found that 67% of large enterprises could not produce a complete AI asset inventory within five business days. At banks, where regulatory scrutiny is constant, that number was still 54%. More than half of regulated financial institutions cannot quickly account for the AI systems making or influencing decisions about customers, risk, and capital.

The problem compounds because AI doesn't live in one place. Data science teams build models in Jupyter notebooks. Business units buy SaaS tools with embedded ML. Developers integrate third-party APIs from OpenAI, Anthropic, or Google. Operations teams deploy RPA bots that include decision logic. Marketing uses predictive scoring tools. Nobody owns the full picture because nobody was asked to.

This is not a technology problem. It is an organizational design failure. And regulators have noticed.

What Regulators Actually Want (And When They Want It)

The OCC, Federal Reserve, and FDIC have all published guidance since 2023 on model risk management that explicitly includes AI and ML. SR 11-7, the Fed's model risk management guidance, was written before the current AI wave, but examiners are applying it to every production AI system. The OCC's 2024 update to the Comptroller's Handbook on Model Risk Management made this even more explicit.

Here is what examiners expect you to produce: a registry of every model in production with its business purpose, owner, approval date, validation status, and last review date. They want data lineage for training sets. They want documentation of known limitations. They want evidence that someone tested for bias and fairness before deployment. And they want performance monitoring logs showing the model still works as intended.

For third-party AI (any vendor tool with embedded ML), they expect you to document what the model does, what data it accesses, what decisions it influences, and how you validated the vendor's claims. 'We bought it from a reputable vendor' is not a sufficient answer. I watched an examiner reject that exact response during a 2024 exam.

The timeline matters too. Examiners typically give 5 to 10 business days for inventory production requests. If your answer is 'we need a month,' you've already signaled a control weakness. That finding goes in the report.

The Four-Layer AI Inventory Framework

I've built AI inventory programs at two banks. Both times, the framework that worked had four layers. Not because four is a magic number, but because AI assets cluster into four distinct categories that require different tracking approaches.

Layer 1: Internally Built Models. These are the models your data science and engineering teams build and deploy. They live in your infrastructure. You control the code, the data, and the deployment pipeline. This is usually the easiest layer to inventory because these teams already use model registries like MLflow or SageMaker. The gap is usually that the registry exists but is not connected to your governance process. Fix that connection and you cover 30 to 40% of your AI footprint.

Layer 2: Embedded Vendor AI. This is the hardest layer. Your CRM has predictive lead scoring. Your fraud platform uses ML for transaction monitoring. Your HR system uses AI for resume screening. These models are buried inside products you bought for other reasons. Identifying them requires a vendor-by-vendor review. I recommend adding a mandatory AI disclosure question to your vendor management questionnaire. At the last bank where I implemented this, we discovered 23 AI components we did not know existed across 11 vendor platforms.

Layer 3: API-Integrated AI. These are direct integrations with AI services like OpenAI, Anthropic, Google Vertex, or AWS Bedrock. Your developers are calling these APIs from your applications. They are easier to find than embedded vendor AI because they show up in API gateway logs and cloud billing. Run a query against your API management platform for known AI provider domains. You will likely find integrations that were never formally approved.

Layer 4: Shadow AI. Employees using ChatGPT, Claude, Copilot, or other AI tools on their own devices or through personal accounts. You cannot inventory what you cannot see, but you can estimate exposure. A 2025 Gartner study found that 68% of knowledge workers at large enterprises used generative AI tools that were not provisioned by IT. Your inventory should acknowledge this layer exists and document what controls (DLP, acceptable use policy, network monitoring) you have in place. Examiners do not expect you to have eliminated shadow AI. They expect you to know it is happening and have a plan.

Building the Registry in 30 Days, Not 6 Months

The biggest mistake I see is treating the AI inventory as a massive data collection project. Teams build elaborate spreadsheets with 50 fields per model, then spend months trying to fill them in. By the time they finish, the inventory is already outdated.

Start with 12 fields. That is it. Model name, business unit, owner, business purpose, model type (classification, regression, generative, rules-based), data sources, deployment date, last validation date, risk tier (high, medium, low), production status, vendor or internal, and known limitations. Twelve fields. You can add more later. Getting 12 fields populated for every AI asset in 30 days is achievable. Getting 50 fields populated for every asset takes a year and never actually finishes.

Week 1: Send a structured survey to every business unit head and technology team lead. Ask two questions: what AI tools does your team use, and what AI tools are embedded in the platforms your team relies on. Give them five business days. You will get 60 to 70% of your inventory from this step alone.

Week 2: Cross-reference survey responses with three data sources. Your cloud billing (look for AI service charges), your API gateway logs (look for calls to AI provider endpoints), and your vendor contracts (search for terms like 'machine learning,' 'artificial intelligence,' 'predictive,' and 'automated decision'). This catches what the surveys missed.

Week 3: Classify each asset by risk tier. High risk means the model directly affects customer outcomes, regulatory compliance, or financial decisions. Medium risk means it influences internal processes with indirect customer impact. Low risk means it is used for internal productivity with no customer or compliance implications. Risk tier determines how much governance each asset needs going forward.

Week 4: Load everything into a registry tool and assign owners. This does not need to be expensive software. I have seen banks use Confluence, SharePoint, or even a well-structured Airtable for the first version. The tool matters less than the process. Every model gets an owner. Every owner gets a review cadence based on risk tier: quarterly for high, semi-annually for medium, annually for low.

Keeping the Inventory Alive After Day 30

An inventory that is accurate on day 30 and stale on day 90 is worse than no inventory at all. It gives you false confidence and gives examiners evidence that your controls are not sustained.

The mechanism that works is tying inventory updates to existing approval gates. No AI model goes to production without a registry entry. No vendor contract with an AI component gets signed without a registry entry. No API integration with an AI provider gets approved without a registry entry. You are not adding a new process. You are adding one step to three processes that already exist.

At one bank, we added a single checkbox to the change management ticket template: 'Does this change involve an AI or ML component?' If checked, the ticket could not be closed without a registry entry confirmation. That one checkbox caught 14 unregistered AI deployments in the first quarter.

Assign a quarterly attestation cycle. Every model owner confirms their registry entries are current. Every business unit head confirms their unit's inventory is complete. This takes less than an hour per quarter per person, and it creates the audit trail regulators want to see. It also creates accountability. When someone attests that the inventory is complete and an examiner finds a gap, that is a different conversation than discovering nobody was responsible at all.

Actionable Takeaway