Building an AI Inventory That Survives a Regulator Visit

Building an AI Inventory That Survives a Regulator Visit

Every compliance framework touching AI right now, from the EU AI Act to the Colorado AI Act to the NIST AI RMF, converges on one surprisingly mundane requirement: know what AI you have. Not in a vague "we use some machine learning" way. In a documented, structured, auditable way. And yet, when regulators come knocking, this is where most organizations fall apart. Not because they lack AI governance principles, but because they never built the inventory that makes governance operational.

I've seen organizations with beautifully written AI ethics policies that cannot answer a basic question: how many AI systems are currently in production? If you can't answer that, the policy is decorative.

What Regulators Actually Want to See

The EU AI Act (Regulation 2024/1689), which entered into force in August 2024, requires deployers of high-risk AI systems to maintain logs, document intended purposes, and conduct fundamental rights impact assessments. Article 26 is explicit about deployer obligations, and the inventory is the backbone of meeting them. Colorado's SB 24-205, effective February 2026, requires deployers to maintain a public statement describing the types of high-risk AI systems they use. New York City's Local Law 144 already requires bias audits for automated employment decision tools, and you can't audit what you haven't cataloged.

The OCC, FDIC, and Federal Reserve issued joint guidance on model risk management back in 2011 (SR 11-7), and it remains the gold standard for financial services. That guidance treats any quantitative method as a "model" subject to inventory and validation. If your bank adopted an LLM-based customer service tool and it isn't in your model inventory, you have a finding waiting to happen.

In healthcare, OCR has signaled through its enforcement actions and the HHS Final Rule on AI transparency (effective in 2025) that covered entities need to identify and document AI tools used in clinical decision-making. The common thread across all of these: regulators expect a living, structured record of your AI footprint.

The Metadata That Matters

A spreadsheet with system names and vendor contacts is a start, but it won't hold up. Here's the metadata you should be capturing for each AI system, whether built in-house or procured from a vendor:

• System identification: Unique identifier, system name, version, vendor (if third-party), and deployment date. Sounds obvious, but version tracking is where most inventories go stale.
• Functional description: What does it do, in plain language? What decisions does it inform or automate? This is what regulators read first.
• Risk classification: Under the EU AI Act, this means mapping to Annex III categories. Under NIST AI RMF, it means documenting your risk tier. Under SR 11-7, it means Tier 1/2/3 model classification. You may need multiple classifications if you operate across jurisdictions.
• Data inputs and outputs: What data does the system consume? What does it produce? Does it process personal data, protected health information, or financial records? This connects your AI inventory to your data governance program.
• Intended use and known limitations: Document the boundary conditions. If a vendor's model was trained on U.S. English text and you're deploying it for multilingual support, that's a known limitation worth recording.
• Human oversight mechanism: Who reviews outputs? Is there a human-in-the-loop, human-on-the-loop, or fully automated decision? The EU AI Act's Article 14 requires meaningful human oversight for high-risk systems, and you need to document how you deliver it.
• Validation and testing history: Dates of last bias audit, performance evaluation, or adversarial test. Include results summaries, not just dates.
• Owner and accountability: A named individual (not a team alias) responsible for the system. Regulators want to know who they can talk to.
• Incident history: Any failures, complaints, or unexpected behaviors. This is the field most organizations leave blank, which is exactly why regulators ask about it.
• Regulatory mapping: Which specific regulations, standards, or internal policies apply to this system? A system processing employment decisions in New York City triggers Local Law 144. The same system used in the EU triggers AI Act obligations. Map them explicitly.

Shadow AI Is Your Biggest Inventory Gap

The hardest systems to inventory are the ones nobody asked permission to deploy. A marketing team signs up for an AI writing tool. A developer embeds an open-source model into a microservice. A business analyst builds a classification model in a Jupyter notebook that somehow ends up driving quarterly forecasting. Gartner estimated in 2023 that by 2026, more than 80% of enterprises will have used generative AI APIs or deployed GenAI applications, up from less than 5% in early 2023. That adoption curve means shadow AI is already in your environment.

Your inventory process needs a discovery mechanism. This can be technical (scanning for API calls to known AI services, reviewing cloud spend for AI-related line items) or procedural (requiring AI use declarations as part of procurement and software development workflows). Ideally both. The organizations that handle this well treat AI inventory the way mature security programs treat asset management: you assume you're missing something and build processes to continuously close the gap.

Maintenance Discipline

An inventory created once and never updated is almost worse than no inventory at all, because it creates false confidence. Here's what a sustainable maintenance cadence looks like:

• Quarterly reviews: System owners confirm that metadata is current. Has the model been retrained? Has the data pipeline changed? Has the use case expanded beyond the original scope?
• Trigger-based updates: Any material change to a system (new data source, new deployment context, vendor model update, regulatory change) should trigger an inventory update within a defined SLA. Thirty days is reasonable for most organizations.
• Annual attestation: A formal sign-off, ideally by someone at the VP level or above, that the inventory is complete and accurate. This creates an accountability record that matters during examinations.
• Integration with change management: If your AI inventory lives in isolation from your ITSM or change management processes, it will drift. New deployments, retirements, and modifications should flow into the inventory automatically or through a mandatory step in the change process.

One practical note: don't over-engineer the tooling at the start. I've seen organizations spend six months evaluating GRC platforms for AI inventory management while their actual inventory sat in someone's head. A well-structured SharePoint list with enforced fields and a review workflow beats a sophisticated tool that's perpetually in implementation.

Common Mistakes

A few patterns I see repeatedly. First, inventorying only "AI" and missing traditional models. If your organization has logistic regression models making credit decisions, those are in scope under SR 11-7 and likely under the EU AI Act depending on context. Don't let the hype around LLMs make you forget about the decision-making models that have been running for years.

Second, treating the inventory as an IT exercise. The business owner of the process the AI supports needs to be involved. IT can tell you the model runs on AWS. The business owner can tell you it's being used to triage insurance claims, which is the information the regulator actually cares about.

Third, failing to connect the inventory to your risk assessment process. The inventory is an input to risk assessment, not a substitute for it. Each entry should link to a corresponding risk evaluation, and high-risk systems should link to documented mitigation plans.

How FirmAdapt Addresses This

FirmAdapt's platform includes structured AI inventory capabilities designed around the metadata requirements of multiple regulatory frameworks simultaneously. Rather than maintaining separate inventories for EU AI Act compliance, NIST alignment, and sector-specific requirements like SR 11-7 or HIPAA, FirmAdapt lets you maintain a single inventory with regulatory mappings that surface the relevant obligations for each system based on its classification and deployment context.

The platform also supports the maintenance discipline side: automated review reminders, change-triggered update workflows, and attestation tracking. Because FirmAdapt is built for regulated industries, the inventory integrates with broader compliance workflows rather than existing as a standalone register. When a regulation changes or a new requirement takes effect, the platform flags which inventory entries are affected, so your team can respond with specificity rather than scrambling to figure out what's in scope.