GOVERN 1.6 AI system inventory: requirements and evidence

What GOVERN 1.6 asks for and why an AI inventory is hard to keep

GOVERN 1.6 expects an organization to have mechanisms that inventory its AI systems, with those mechanisms resourced in line with its risk priorities. In practice, an assessor or customer will ask who keeps the inventory, how it is created, which systems it covers, and whether the people maintaining it have the time and authority to do so. The NIST AI RMF is voluntary and has no certification, so no one issues a pass for GOVERN 1.6. The evidence is whatever your organization can show: a defined inventory process, a named owner, a current register, and records that the register is reviewed and funded in proportion to the risk of the systems it lists.

Inventories decay for predictable reasons. Shadow AI appears when staff adopt external AI tools on their own accounts and nobody records them. AI embedded in purchased software is harder still, because the vendor adds features to an existing product and the organization may never see a new procurement event. Unowned pilots create a third gap: a proof of concept built by one team is left running after its sponsor moves on, and its data connections and users stay live without an owner. Each of these gaps is invisible to a register that only collects what someone chose to report.

Start by deciding what the inventory must capture before deciding how to collect it. Confirm with your legal, procurement and security teams where AI enters the environment, including SaaS contracts and internal builds, and assign a maintainer with the authority to require registration. The NIST AI RMF Playbook offers general suggestions for this step, such as recording system attributes and AI actor contacts, but it is not a checklist, so define the required fields for your own risk tiers. Then test the inventory against what is actually running, using discovery from existing asset and endpoint tooling where it applies, and treat every unregistered system you find as a finding to close.

Which AI systems, teams and third parties belong in the inventory

Most of the effort in a GOVERN 1.6 inventory comes from a handful of scoping choices made before anyone collects data. The cards below cover the decisions that change the work most: how broad the inventory is, how generative AI inside application software is treated, how third-party and pre-trained models are recorded, and which parts of the organization must report in.

Full coverage or high-risk tiers

The NIST AI RMF Playbook suggests inventorying all models and systems where possible, or at least the high-risk ones and those used in high-stakes settings. Full coverage means every model, including internal analytics scripts and vendor features, must be found and triaged, which is a discovery effort that recurs as teams adopt new tools. A tiered inventory starts smaller but depends on a risk classification that already works, which is the work of GOVERN 1.3. Ask which tier criteria the organization will use and who decides whether a borderline system is in scope.

Generative AI inside application software

Generative AI features now ship inside office suites, CRMs, ticketing tools and other applications the organization already runs. NIST AI 600-1 asks organizations to add generative AI systems to the inventory and to define any exemptions for generative AI embedded in application software. An exemption lowers the entry count but leaves a blind spot, so write it down with its reason, an owner and a review date. Check the vendor's release notes for newly enabled AI features in existing products.

Third-party AI and vendor-hosted models

Vendor systems that call a model the organization never trained still affect its risk. The inventory should record the provider, the contract or terms under which the system is used, the data sent to it and the business owner who approved it. Cover SaaS features, API integrations and browser extensions alongside procured platforms. Procurement records and expense reports often reveal use that IT never approved, so reconcile them against the inventory at least as often as the review cycle set under GOVERN 1.5.

Pre-trained and open-weight models

Models pulled from public hubs or fine-tuned from a base model are components of the system built on them, not stand-alone software. The inventory should record the model name, version, source, license, and the training or fine-tuning data where known, so that a later vulnerability or license change can be traced to affected systems. Where the organization cannot obtain the source information, record that gap as an open item. Confirm with each team which base models its applications call and where the weights are stored.

Business units that must report

An inventory built only from the central AI or data team misses shadow projects in business units. Set a reporting obligation for every unit that builds, buys, configures or deploys AI, and name an accountable contact in each. Those contacts are the AI actors the Playbook asks you to record, so their names and roles belong in the entry. Confirm that the reporting duty is written into team charters or procurement rules, not only into a memo.

Systems that span other inventories

Some AI capabilities run on infrastructure already tracked in an asset or configuration inventory. Decide whether the AI inventory references those records, duplicates them or links to them, and who keeps each field current. Hosts, containers and endpoints inventoried by tools such as GLPI or Wazuh can supply the infrastructure view, while the AI inventory holds the model, purpose and risk attributes. Agree on a single system identifier so the two records do not drift apart.

How an assessor tests the AI system inventory

This table sets out each step an assessor takes to test GOVERN 1.6, the evidence requested for each step, and the findings that usually come up. Read it as a sequence: confirm the method and owners first, then sample systems from each source, then check that entries carry the attributes the organization chose. The main takeaway is that an inventory only passes if it matches what is actually running and is tied to how risk is tiered.

Test step	What the assessor checks	Evidence requested	Common finding
Documented method	A written procedure defines how AI systems are added to the inventory, how it is updated and what triggers an update	Inventory procedure, intake form, update triggers and version history of the procedure	No written method, or a procedure that describes a process nobody follows
Named maintainers	Specific people or teams are accountable for keeping the inventory current and resolving gaps	Ownership records, role descriptions and the RACI or equivalent for inventory upkeep	Maintainer named only as a team alias, or the named person has left the organization
Production sample	Systems running in production are traced back to an inventory entry, starting from a sample drawn from live environments	Production system list from monitoring or asset tooling, matched against inventory export	Production models or APIs with no inventory entry, often embedded in other applications
Procurement sample	AI systems bought or subscribed to, including SaaS features, appear in the inventory with an owner	Purchase orders, vendor contracts, subscription records and their matching inventory entries	Vendor AI features enabled by business units without a procurement or inventory record
Shadow and unsanctioned use	Tools that staff use outside approved channels are searched for and compared with the inventory	Network or endpoint discovery results, expense records and any exemption register with approvals	No discovery method exists, so the inventory has no way to surface unsanctioned tools
Attribute completeness	Each entry records the attributes the organization defined, such as documentation, source code links, incident response plans, data dictionaries and AI actor contacts	Inventory export with field definitions and a sample of complete versus incomplete entries	Required fields left blank, or attributes defined in policy but absent from the inventory schema
Change history	Updates, retirements and ownership changes are logged with dates and the person who made them	Audit trail, change log or versioned export showing changes over the review period	Entries overwritten without history, so the assessor cannot tell when a system changed
Link to risk tiering	Inventory entries carry a risk tier or priority that drives how much oversight each system receives	Risk tiering criteria, tier field in the export and records showing tier decisions	Inventory and risk register maintained separately, with systems in one but not the other
Review sign-off	Periodic reviews confirm the inventory is current and that gaps were resolved	Review minutes, sign-off records and the list of findings with closure dates	Reviews not performed, or signed off with known stale entries and no follow-up

How to build an AI inventory that survives an audit

This sequence turns GOVERN 1.6 from a policy statement into a working AI inventory with a named maintainer, an agreed attribute set, entries linked to risk tiers and a recurring reconciliation record that an assessor can test.

Define inventory scope and discovery method
Decide which models and systems the inventory covers, including in-house builds, vendor AI features, embedded generative AI in application software and shadow tools used by staff. NIST's Playbook suggests inventorying all models and systems where possible, or at least the high-risk ones and those in high-stakes settings, so record that choice and the reason for it. Then choose how items will be found: self-declaration through procurement and change requests, scans of code repositories and cloud accounts, and runtime sources. The output is a written scope decision with any exemptions named and justified, which NIST AI 600-1 specifically asks organizations to define for generative AI embedded in application software.
Assign a maintainer and accountable owner
Name one person or team who maintains the inventory day to day and a separate executive or governance owner who is accountable for its completeness. The Playbook suggests defining how inventories are created and who maintains them, and GOVERN 1.6 ties the mechanism to resourcing, so the maintainer needs time and tooling allocated in the operating plan. Record both roles, their escalation path and the AI actor contacts for each system. Done means the role assignments are approved in writing and appear in the inventory policy, so an assessor can trace who is responsible for a gap.
Agree the attribute set for each entry
Fix the fields every entry must carry before any data is collected, so entries are comparable across the portfolio. The Playbook suggests recording documentation references, source code links, incident response plans, data dictionaries and AI actor contacts. For generative AI, NIST AI 600-1 adds data provenance and known issues. Write a short attribute standard with a definition, an owner and a mandatory or optional flag for each field. The output is that standard, approved by the owner, and used as the template for every entry.
Populate the inventory from existing sources
Seed the inventory from procurement records, engineering repositories and runtime sources rather than relying on memory. Procurement contracts show purchased AI services, repositories show models and pipelines, and runtime sources show what is actually running. Open-source tools can help here. Wazuh Syscollector collects installed software, services and processes from endpoints, GLPI's Assets module can hold hardware and software records, and Langfuse traces show which LLM calls are made in a running application. Each tool only shows part of the picture, so confirm capabilities in each product's documentation before relying on it. The output is a seeded inventory where every entry states its source.
Link each entry to its risk tier and review cadence
Assign every entry the risk tier produced by the organization's risk tolerance process, and set a review cadence for that tier. This connects GOVERN 1.6 to GOVERN 1.3 and the risk-priority requirement in the outcome itself. High-risk and high-stakes systems should carry the most complete attribute set and the shortest review interval. Record the tier, the date of the last review and the next review date on each entry. The output is a set of risk-linked entries, and an assessor should be able to pick any high-risk system and find its documentation, owner and review history in one place.
Set a recurring reconciliation
Schedule a recurring comparison between the inventory and the sources used to seed it, such as new procurement records, repository changes, cloud resource listings and runtime telemetry. Anything found in a source but missing from the inventory is an unregistered system, and anything in the inventory that no longer appears in any source needs a decommissioning check under GOVERN 1.7. Set the frequency in the inventory policy, based on how quickly the organization adds AI, and confirm it with the accountable owner. Log each reconciliation with its date, sources checked, discrepancies found and who closed them. That reconciliation record is the evidence that the inventory stays current, and it is what an auditor is most likely to ask to see.

Evidence that shows the inventory is maintained between audits

An inventory is only as credible as its upkeep. The six artifacts below show an assessor how entries were created, who owns them, how they changed and how they connect to risk decisions. Each one should be produced on a schedule the organization sets and can defend, not captured once before an audit.

Inventory export with version date

A dated export of the full AI system inventory, stored with a version identifier and a record of who generated it. Assessors compare successive exports to see whether entries were added, updated or removed over time. Check that every export carries the same attribute set, so gaps in documentation are visible rather than hidden by changing columns. Set the export cadence in the inventory procedure and keep the prior versions, not only the latest.

Attribute standard

A written definition of the fields every entry must hold, such as system owner, purpose, model or data sources, documentation location, source code links, incident response plan, data dictionary and AI actor contacts. The Playbook suggests these attributes for GOVERN 1.6. Keep the standard versioned, and record which entries predate a change to it so reviewers can see where backfilling is still open.

Maintainer and owner assignments

Named individuals or roles responsible for keeping each entry accurate, plus the person accountable for the inventory as a whole. GOVERN 1.6 expects the organization to define who maintains the inventory, so a reviewer will look for a current assignment list and evidence that it was confirmed after staff changes. Record the review sign-off for each assignment, along with the date it was last confirmed.

Discovery and reconciliation logs

Records showing how the inventory was checked against what is actually running. Discovery sources can include cloud resource listings, software inventories from endpoint agents, and model registries or developer platforms. Wazuh Syscollector and GLPI Assets can help populate and reconcile asset records, though whether either captures AI-specific components must be confirmed in your environment. Log every unmatched item, whether it was added, retired or classed as an exemption.

Change records for added or retired systems

Tickets or change records for every new, modified or decommissioned AI system, each linked to the inventory entry it changed. Without these, a reviewer cannot tell whether an entry that disappeared was retired properly or simply forgotten. Tie retirements to the decommissioning process under GOVERN 1.7, including data retention and preserved artifacts. Confirm your ticketing tool can export the change history with timestamps.

Risk-tier linkage

Evidence that each inventory entry carries its risk tier and that the tier drives the depth of oversight, testing and monitoring applied to that system. Reviewers check whether high-risk and high-stakes systems have the most complete entries and the most frequent review. Keep a record of tier changes with the reason and the approver, so a downgrade from high to lower risk can be traced and questioned.

What meeting GOVERN 1.6 costs in money and effort

This table breaks down the cost components of building and keeping an AI system inventory under GOVERN 1.6, showing who is paid for each, whether it is one-time or recurring, and what moves it up or down. No prices are published in the supporting material, so use the table to shape a written quote and to ask the right questions of any vendor or partner.

Cost component	Who is paid	One-time or recurring	What drives it up or down
Inventory tooling or licenses	Software vendor or hosting provider	Recurring (subscription or support), plus one-time setup if self-hosted	Up with the number of assets and users to license. Down when open-source tooling such as GLPI or Wazuh is self-hosted and an existing asset register is reused.
Discovery and integration engineering	Internal platform team or implementation partner	One-time, with later changes as new cloud accounts and model endpoints appear	Up with fragmented cloud accounts, undocumented model APIs and custom connectors. Down when discovery builds on existing CMDB, cloud and endpoint data.
Maintainer time for upkeep	Named internal owner, often from governance, risk or platform engineering	Recurring, tied to how often systems change	Up with shadow AI, frequent model swaps and vendor-embedded AI features. Down with a defined intake process that requires registration before deployment.
Documentation effort per entry	Product owners, data owners and AI actor contacts	Initial entry is one-time per system, updates are recurring	Up with the attributes recorded, such as data dictionaries, source links, incident response plans and data provenance. Down with a standard entry template and risk-based depth.
Risk-based scoping decisions	Governance lead and risk owners	One-time design, periodic review	Up when the organization insists on inventorying every model and system. Down when scope is limited to high-risk and high-stakes systems, with documented exemptions.
External review or testing, if used	Independent assessor or testing firm	Typically one-time per review cycle, recurring if reviews are scheduled	Up with the number of inventory entries sampled and the depth of technical checks. Down when entries are complete and traceable before the review starts.
Assessor sampling effort	Organization staff who answer requests, plus any external assessor	Recurring at each audit or customer review	Up when entries are scattered across tools or lack owners. Down when a single inventory exports the attributes an assessor asks for.
Written quote items to request	Implementation partner or internal budget holder	Stated separately as one-time and recurring	Ask for the systems and scope covered, deliverables, attribute list, hosting assumptions, handover owners and support terms. DeployOpen does not publish prices; quotes follow a written scope.

Self-hosted open-source tools that feed the inventory

GOVERN 1.6 asks for a register of AI systems, and most organizations already run tools that can populate parts of it. The four tools below each cover a different angle: the asset register, the host and software discovery layer, the runtime trace of generative AI calls, and the test record for language models. Each one produces evidence for an inventory entry, but none of them builds or maintains the inventory on its own.

GLPI asset register

GLPI's Assets module records computers, software, network equipment and racks, and entries can be typed in by hand or pushed automatically by the GLPI Agent. Use it as the register of the software that runs AI tools and the hosts they run on, so each inventory entry links to a managed asset. Before relying on it, confirm which AI applications your team will record as software items and who approves changes to those records. Entries only reflect what someone registers or what the agent detects.

Wazuh endpoint discovery

Wazuh's Syscollector module reports installed software, running processes, services, network interfaces and open ports from each monitored endpoint into the Wazuh indexer. Compare these results against the inventory to find AI tools that teams have installed without registering them, such as local model runtimes, browser extensions or desktop assistants. Confirm agent coverage across your fleet first, because unmonitored hosts will not appear in the results. Discovery finds unregistered tools, but someone must still classify each finding.

Langfuse runtime traces

Langfuse records traces of each request, including LLM calls, retrieval steps, tool executions, timing, token usage and metadata. These traces show which generative AI systems are active and which models and tools they call, which helps confirm that inventory entries match production behavior. Check that trace metadata includes a system identifier that matches the inventory record, and decide how long traces are kept and who can read prompts that contain personal data. Traces show use, not approval or ownership.

garak test reports

garak probes language models for hallucination, data leakage, prompt injection, misinformation, toxicity generation and jailbreaks. It writes a JSONL report of every attempt and evaluation, plus a hit log of attempts that found a vulnerability. Link these reports to the inventory entry for the model so a reviewer can see when the model was last tested and what failed. Confirm that the probe set matches the risks you mapped, since a clean run covers only the probes that were executed. A report is test evidence for one model version.

Who maintains the inventory and who outsources what

Your organization owns the AI inventory, its scope and the decisions about what goes into it. GOVERN 1.6 asks for mechanisms that inventory AI systems and are resourced in line with risk priorities, so the accountable owner must be a named role with budget and authority, usually someone in risk, governance or security leadership. Day-to-day upkeep depends on maintainers who know the systems, and these people are hard to outsource because the knowledge sits with your staff.

Accountable owner: A named executive or manager who signs off the inventory's purpose, scope and resourcing, and who answers for it to the board or regulator.
Named maintainers: Staff who keep the register current, check entries on a set cycle and close gaps when systems change.
Business unit submitters: Application and product owners who register new AI systems, including generative AI features embedded in software they already run.
Scope sign-off: A written decision on which models and systems are in scope, how high-risk systems are prioritized and what exemptions apply.
Decision rights: Clear rules for who may add, change or retire an entry, and where those rules are recorded.

Before any partner starts, check that the accountable owner and maintainers are named in writing and that the scope decision exists as an approved document.

Where AI inventories usually fall short and how to close each gap

An AI inventory that exists on paper but misses systems, owners and context does little for GOVERN 1.6. The gaps below tend to appear together, and each one weakens the inventory's use for risk tiering, resourcing and assessor testing. The fixes are written so an internal team or an implementation partner can check them against the organization's own environment.

No named owner for the inventory

An inventory that no one maintains goes stale within a few release cycles. GOVERN 1.6 expects the organization to define how inventories are created and who keeps them current, so an assessor will ask for the named role, not a team alias. Fix it by assigning one accountable owner, writing a short procedure that states how new systems enter the register, and setting a review step tied to change approvals. Confirm the owner can actually see deployments and vendor purchases.

Shadow AI and embedded generative AI missing

Teams often adopt generative AI through browser tools, SaaS features or plug-ins that never reach procurement or architecture review. The NIST AI 600-1 actions under GOVERN 1.6 ask organizations to add generative AI systems to the inventory and to define any exemptions for generative AI embedded in application software. Fix it by writing the exemption rules explicitly, running discovery through expense records and network or identity logs, and recording each exemption with its rationale.

Entries without documentation or response links

A register entry that names a model but omits its documentation, source code location, incident response plan or data dictionary cannot support investigation or handover. The Playbook suggests recording these attributes for each entry. Fix it by making these fields mandatory for in-scope systems, and by checking that each link resolves to a current document. Ask whether an on-call engineer could find the incident plan from the entry within minutes.

Inventory not tied to risk tiers

When the inventory lists systems but not their risk level, the organization cannot show that high-risk systems receive more oversight or budget. GOVERN 1.6 links the inventory to resourcing in line with risk priorities. Fix it by adding a risk tier attribute populated from the GOVERN 1.3 scoring, then filtering reviews, testing and monitoring budgets by tier. Illustrative check: a tier-one system with no testing record is a gap to escalate.

No reconciliation with procurement or runtime data

A manually maintained register drifts from what is actually running. Asset tools, cloud logs and procurement records often show AI services that the register does not. Fix it by reconciling the inventory on a fixed schedule against purchase orders, cloud or endpoint inventories and application telemetry, and by logging each discrepancy with an owner and a closure date. Open-source asset and endpoint inventories can supply part of this data, but confirm which AI services they actually detect in your environment.

Third-party and pre-trained models lacking contacts

Models pulled from public hubs or supplied by vendors are often recorded by name and version alone. When a model is withdrawn or a vulnerability is disclosed, nobody knows whom to contact. The AI actor contacts recorded for each entry are part of what the Playbook suggests for GOVERN 1.6. Fix it by requiring a vendor or maintainer contact, the license, the version and the date of the last reviewed update for every third-party model, and by linking each entry to the contract or license record.

How much work and cost does an AI system inventory take?

How long does it take to build an AI system inventory?

The duration depends mainly on scope, the number of systems and the discovery sources available, so no fixed timeline applies to every organization. A narrow inventory covering only high-risk or high-stakes systems can be scoped and finished far sooner than one that tries to capture every model, vendor feature and experiment across the business. Start by asking any implementation partner to break the work into discovery, entry design, population and upkeep, and to state the assumptions behind each phase. NIST's Playbook suggests inventorying all models and systems where possible, or at least the high-risk ones, so that choice is the first driver of effort.

What drives the cost of an AI inventory up or down?

Cost follows the number of systems, how many teams hold AI assets, and how much of the inventory can be collected automatically. Organizations that already run an asset management or endpoint inventory tool can reuse some of that data, while AI features embedded in third-party software usually need manual review. Recurring cost comes from keeping entries current as systems change, which is often larger than the one-time build. Ask for the quote to separate the initial population from ongoing maintenance and to state which discovery sources are included.

Can an organization build its AI inventory in-house?

Yes. NIST's framework is voluntary and has no certification, so an organization can define its own inventory process, owners and attributes without outside help. The usual constraint is capacity and independence: the people who build the AI systems are often the least able to list every shadow deployment. Many teams keep ownership internal and bring in outside help for discovery, tooling setup or a one-time population exercise, then maintain the register themselves. Whichever path you choose, the organization remains responsible for the inventory's accuracy.

What does the inventory work need from engineering, procurement and business units?

Each group holds part of the data that a complete entry needs. Engineering supplies technical attributes such as documentation, source code links, data dictionaries and incident response plans. Procurement identifies AI capabilities bought from vendors, including contract terms and the third parties that supply models or data. Business unit leads confirm the intended purpose, the people who use each system and its decision impact. Without named contacts in each group, entries go stale quickly, so assign an owner for each attribute before collection starts.

Is there a certification for the NIST AI RMF inventory?

No. There is no AI RMF certification. NIST does not validate or endorse any individual organization or its approach to using the AI RMF, and its framework materials describe no certification, accreditation or conformity assessment program. Any vendor or consultant who claims to certify your AI RMF inventory is making a claim NIST does not support. If a customer or regulator asks for evidence, ask what form of documented assessment they expect, since that is a question of contractual or regulatory requirement, not a certificate.

Do open-source tools remove licence spend from an AI inventory?

Open-source tools can remove licence fees for the software itself, but they do not remove the work of designing the register, collecting attributes and keeping them current. For example, GLPI's Assets module, which is licensed under GPL-3.0-or-later, can manage hardware, software and other assets and can be fed by its agent, and Wazuh's Syscollector, licensed under GPL-2.0-only, collects installed software and services from endpoints. Neither tool records AI-specific attributes such as intended purpose or model documentation out of the box, so confirm how each would be extended. Check the licence terms with your legal team before deployment.

What should be in a quote for an AI inventory project, and what will the auditor do?

A quote should list the in-scope systems and teams, the discovery sources used, the attribute schema, the tools to be configured, the handover format and the ongoing support model, all in writing before work starts. Ask for deliverables and acceptance criteria rather than a lump sum. An independent auditor or assessor, where one is involved, will review the evidence and test whether the inventory exists and operates as described, but will not build the inventory, select attributes or fill in entries. DeployOpen prepares systems and evidence for assessments and does not issue audit reports or certifications.

How DeployOpen scopes and builds an AI inventory

DeployOpen treats the GOVERN 1.6 inventory as a working register that the organization owns and maintains, built on self-hosted open-source platforms inside the client's own infrastructure. We scope the inventory in writing, build the collection and record-keeping around it, and hand over the documented process so the client's own owners can keep it current.

How we scope

Agree in writing which AI systems, models and generative AI tools fall inside the inventory boundary before work starts.
Record which entries are required for all systems and which apply only to high-risk or high-stakes systems, with the criteria stated.
Name the inventory owner and maintainers in the scope so accountability is written down rather than assumed.

How we build

Configure a self-hosted asset register, such as GLPI's Assets module, to hold AI system records alongside existing hardware and software inventory.
Set up automated discovery of software and services on endpoints with Wazuh Syscollector, then review results against the AI register.
Add fields for documentation links, source code references, incident response plans, data dictionaries and AI actor contacts to each entry.

How we hand over

Deliver a written procedure that defines how entries are created, reviewed, updated and retired, with named roles for each step.
Provide a sample of completed inventory entries, with the attribute set and any inventory exemptions documented for the client to approve.
Walk the client's maintainers through the register and reports so they can run the process without DeployOpen involved.

How we support

Offer ongoing support, upgrades and continuous testing of the inventory tooling as a retainer, scoped separately from the initial work.
Adjust the register when new generative AI systems or third-party models are added, under the change process agreed in the scope.
Confirm with your own assessors which evidence they expect for GOVERN 1.6, since DeployOpen prepares evidence but does not issue assessments or certifications.