One AI Use Inventory That Satisfies NIST RMF and TRAIGA

Two compliance asks are landing on the same desk this year, and most companies are treating them as two separate projects. One is voluntary: the NIST AI Risk Management Framework, and specifically its Map function, which has become the default reference architecture examiners and enterprise customers point to when they ask "how do you know what AI you're running." The other is mandatory for a large slice of businesses that touch Texas residents: the Texas Responsible Artificial Intelligence Governance Act, known as TRAIGA, which took effect January 1, 2026. Build the underlying document once, and it does both jobs. Build it twice, and you've created two inventories that will drift out of sync within a quarter, which is worse than having neither.

I've built this artifact for clients across pharma, professional services, and manufacturing, and the pattern holds regardless of industry: the companies that struggle with AI governance almost never lack policy. They lack a current, accurate list of what AI they're actually running, who owns it, and why it exists. That list — done right — is the single artifact both frameworks are asking for.

What an AI Use Inventory Actually Is

An AI use inventory is not an IT asset list with "AI" typed into a column. An asset inventory tells you what software exists. A use inventory tells you what a system does, who it affects, and what would go wrong if it failed or was misused. Those are different questions, and answering only the first one is why so many companies think they're covered when they aren't.

A real AI use inventory documents, at minimum: the system's name and vendor, its business purpose, the type of AI involved (predictive model, generative model, biometric matching, automated decisioning), who is affected by its output, what data feeds it, who inside the company owns it, and when it was last reviewed. That's the skeleton. What makes it satisfy two different regulatory frameworks is which additional fields you attach to that skeleton, and I'll walk through those below.

What NIST AI RMF's Map Function Is Actually Asking For

NIST AI RMF 1.0, published January 26, 2023, organizes AI risk management into four functions — Govern, Map, Measure, and Manage — and Map is the only one of the four built entirely around a system-by-system inventory. You cannot execute Map from a policy document. You execute it from a list of actual systems, each one worked through a set of questions NIST groups into five categories:

• MAP 1 establishes context: what is the system's intended purpose, who are the stakeholders, and what does success look like.
• MAP 2 categorizes the system: what type of AI is it, and where does it sit in your operations.
• MAP 3 documents capabilities, intended usage, and the benefits and costs against realistic benchmarks — not marketing claims from the vendor.
• MAP 4 maps risks and benefits across every component, including third-party models, APIs, and data your vendor supplies rather than your own team.
• MAP 5 characterizes impacts to individuals, groups, and society — the category most compliance teams skip because it requires naming who could be harmed, not just what could break.

None of this is exotic. It's the discipline of writing down, per system, what NIST's own Playbook calls "suggested actions" for establishing and documenting context. The reason so many companies stall here isn't the questions — it's that nobody has assigned ownership of answering them for every system already running in production, half of which were adopted by a department head without a procurement review.

What Texas TRAIGA Actually Requires

TRAIGA is Texas House Bill 149. The legislature passed it May 31, 2025, Governor Abbott signed it June 22, 2025, and it took effect January 1, 2026, making Texas the third state, after Colorado and Utah, to enact a comprehensive AI governance statute. It is narrower than the original Colorado model in one important way that changes how you should build your inventory: TRAIGA does not impose a blanket private-sector duty to file AI impact assessments for every system. Instead, it ties liability to intent. The statute prohibits AI systems intentionally developed or deployed for specific harmful purposes — manipulation that incites self-harm or unlawful acts, unlawful discrimination against a protected class, generating child sexual abuse material, certain deepfakes, and capturing biometric identifiers without consent for identification purposes — and it layers detailed transparency and human-oversight duties on top of that for government agencies using AI in eligibility decisions, public services, and clinical contexts.

Enforcement sits exclusively with the Texas Attorney General. TRAIGA creates no private right of action, which means the risk isn't a flood of lawsuits — it's a state investigation, and the statute gives an accused party 60 days from notice to cure a violation, explain the cure, and describe the policy change that prevents recurrence. Penalties range from $10,000 to $12,000 per curable violation, $80,000 to $200,000 per uncurable violation, and $2,000 to $40,000 per day for a violation that continues.

Here is the fact that should drive how you build your inventory: a 60-day cure window is only useful to a company that can answer, on day one of the inquiry, what the system does, who built it, and what it was designed to accomplish. If that answer takes three weeks of internal archaeology to assemble, you've burned half your cure period finding the facts instead of fixing the problem. Texas state agencies face an additional, more explicit documentation duty: Senate Bill 1964 requires a public AI inventory, and House Bill 3512 requires DIR-certified annual AI training for employees who spend a quarter or more of their duties on AI-touching systems. If you sell into Texas state government, both of those apply on top of TRAIGA, and your vendor-facing inventory should be built to hand over, not just to hold internally.

Why the Same Document Can Do Both Jobs

Lay the two frameworks side by side and the overlap is larger than it first looks. Both are, at their core, asking you to name the system, name its purpose, name who it affects, and name who's accountable for it. NIST asks these questions to manage risk before it happens. TRAIGA asks a narrower version of the same questions to establish, after the fact, that you didn't build or knowingly permit a prohibited use. The evidentiary posture is different — one is proactive risk management, the other is a defensive record — but the underlying facts you need on file are close to identical.

Built this way, the inventory does a third job almost for free: it satisfies ISO/IEC 42001:2023 clause 6.1.4's requirement for an AI system impact assessment, which matters if a management-system certification is anywhere on your roadmap. I've written separately about why that combination matters for regulated manufacturers in our piece on ISO 42001 for pharma AI governance, but the underlying lesson generalizes past pharma: one well-built document, reused across three separate compliance asks, beats three shallow documents that each satisfy none of them well.

Building the Inventory: A Practical Sequence

Step 1 — Discover what's actually running. This is where most inventories fail before they start. Survey department heads directly rather than relying on IT's software list, because a marketing team using a generative tool through a browser extension, or a sales team piping leads through a third-party scoring API, often never shows up in a procurement record. Ask the blunt question: "what tool answers a question, writes something, scores something, or decides something for you, without a human doing that work by hand?" That question surfaces more shadow AI than any license audit.

Step 2 — Classify by type and role. For each system found, record whether it's generative, predictive, biometric, or decisioning, and whether your company built it, customized a third-party model, or simply deployed someone else's product unmodified. That developer/deployer distinction is not academic under TRAIGA — the statute's duties differ by role, and getting it wrong on your own inventory means you've misjudged your own exposure.

Step 3 — Tie each system to a stated purpose and an affected population. Write the purpose in one sentence a non-technical reader can verify against what the system actually does — not the vendor's marketing description. Then name who the output touches: employees, job applicants, patients, Texas consumers, minors. This single field does double duty: it's MAP 1 and MAP 5 for NIST, and it's the fact base that establishes intent, or the absence of it, for TRAIGA.

Step 4 — Assign an accountable owner, not a department. "Marketing" is not an owner. A named person who can answer questions inside a 60-day cure window is an owner. If nobody can be named, that's itself a finding — flag it and escalate, don't leave the field blank.

Step 5 — Set a review cadence and log every change. A snapshot from eighteen months ago is not evidence of a functioning governance program; it's evidence you had one once. Quarterly review for anything customer-facing or biometric, annual for low-risk internal tools, and an update triggered any time a vendor changes the underlying model — which happens more often than most contracts disclose.

If your organization hasn't done a structured pass across all five steps yet, that's precisely the gap our AI readiness assessment is built to close before you build anything further on top of an incomplete inventory.

Common Failure Modes

The most common failure I see isn't a missing framework — it's a spreadsheet built once for an audit and never touched again. The second is scope: teams inventory the AI IT procured and miss the AI employees adopted on their own, which is exactly the population TRAIGA's prohibited-use provisions are most likely to catch first, since nobody was watching how it got used. The third is treating "owner" as a mailbox alias instead of a person, which turns a 60-day cure window into a scavenger hunt for who actually knows how the system works.

A fourth failure is subtler: building the inventory around systems instead of around uses. The same underlying model might power three different applications inside a company — one low-risk internal tool, one that touches hiring decisions, one that touches biometric verification. If your inventory has one row for "the vendor's platform" instead of three rows for three distinct uses, you've collapsed exactly the distinction both NIST and TRAIGA are asking you to draw. Impact and intent are properties of a use, not properties of a vendor's product.

Keeping It Alive

An inventory that satisfies both frameworks on the day you build it and fails a year later isn't a compliance asset — it's a liability with a delay timer on it. The governance discipline that keeps it current matters more than the initial build: a named owner per system, a quarterly trigger to check for new tools, and a change log that survives personnel turnover. That governance layer is usually where organizations need outside structure, which is the gap our AI transformation consulting work is built around — not building the spreadsheet, but building the process that keeps the spreadsheet honest.

Frequently Asked Questions

Does TRAIGA legally require a written AI inventory? Not by that name, and not as a blanket private-sector mandate — TRAIGA's core liability standard is intent-based, tied to prohibited uses, rather than a universal documentation requirement. But Texas state agencies face an explicit public inventory duty under Senate Bill 1964, and any private company that wants to use its 60-day cure window effectively needs the same facts on hand in practice, whether or not the statute uses the word "inventory."

Is an AI use inventory the same thing as an IT asset inventory? No. An asset inventory tracks what software exists. A use inventory tracks what a system does, who it affects, and who's accountable for it — the facts both NIST's Map function and TRAIGA's intent standard actually turn on.

How often should the inventory be updated? Quarterly for anything customer-facing, biometric, or used in employment or eligibility decisions; at least annually for low-risk internal tools; and immediately whenever a vendor changes the underlying model, since that changes the facts your last review was based on.

Who should own the inventory inside a company? A named individual, not a department. NIST's Govern function and TRAIGA's cure-response clock both assume someone specific can answer for a system, and "the marketing team" is not a name the Attorney General's office can write a letter to.

Does this same inventory help with ISO 42001 certification? Yes. The fields that satisfy NIST's Map function and TRAIGA's evidentiary needs largely overlap with what ISO/IEC 42001:2023 clause 6.1.4 requires for an AI system impact assessment, which is worth building toward now if certification is a future goal rather than a current one.

Last updated: 2026-08-11