# Building a Complete AI System Inventory, October 2026

> Discover how to create an AI risk register covering full inventory, risk tiers, and compliance gaps. October 2026 edition.

Published: 2026-10-30

Shadow AI is the part of your AI risk register that isn't in it yet. Models get deployed through data science teams, product integrations, and off-the-shelf tools without ever going through a formal intake process, and the register you're maintaining may only reflect the systems that came through official channels. What follows is a practical walkthrough of how to build a register that captures your full AI inventory, including the systems that never volunteered themselves for documentation.

**TLDR:**

- An AI risk register tracks behavioral risk beyond infrastructure: a loan model can drift into bias with no error thrown.
- EU AI Act [Article 9](https://www.openlayer.com/blog/eu-ai-act-risk-management-system-requirements) requires continuous risk management, making static spreadsheets non-compliant for high-risk systems by August 2026.
- Risk tiering scores four dimensions independently: impact scope, failure severity, observability, and regulatory exposure, on a 1-4 scale.
- Shadow AI enters through three channels: unregistered fine-tuned models, third-party LLM APIs added without review, and off-the-shelf tools processing regulated data.
- Openlayer connects register entries to CI/CD gates and LLM Gateway traffic capture, so a system that fails recertification cannot promote to production.

## What an AI Risk Register Is {#what-an-ai-risk-register-is}

An AI risk register is a structured, living inventory of every AI system an organization operates, documenting the risks, obligations, and controls tied to each one. The distinction from a generic IT risk register matters: where an IT register tracks servers, software versions, and access controls, an AI risk register tracks behavioral risk. A loan scoring model can drift into demographic bias weeks after deployment without throwing a single error. A content generation tool can begin leaking PII without any infrastructure alert firing. Those failure modes require a different class of documentation.

Each entry in the register captures:

- System identifier and model version, traceable to the model registry entry that records training data provenance and the approval event authorizing deployment
- Named owner: the individual accountable for deployment decisions and regulatory compliance, not a team label
- Intended use and affected population, including the decisions the system informs or makes
- Risk tier under the applicable framework (EU AI Act Annex III, NIST AI RMF), citing the specific provision that produced the classification
- Regulatory obligations attached to the system, with current compliance status and any open gaps named and owned
- Lifecycle stage (development, testing, production, retirement)
- Monitoring status, named metrics, and current thresholds
- Last evaluation date and next scheduled review, linked to the evaluation record in the audit trail

The register connects deployed AI to governance obligations. Without it, compliance teams cannot answer the most basic audit question: what AI systems do we operate, who owns them, and are they monitored? A blank field in any entry is not a neutral omission. Auditors treat an incomplete record as evidence the control was never in place.

## The MIT AI Risk Repository and Why It Matters {#the-mit-ai-risk-repository-and-why-it-matters}

The [MIT AI Risk Repository](https://airisk.mit.edu), maintained by researchers at MIT, is a structured catalog of AI failure modes drawn from incident reports, academic literature, and regulatory frameworks. It organizes risk into domains: safety failures, fairness and discrimination, security vulnerabilities, privacy violations, and broader societal harms. Each domain contains subcategories with concrete examples: a hiring algorithm that systematically scores down candidates from certain zip codes sits under fairness; a RAG pipeline that reproduces private documents in its outputs sits under privacy.

Organizations use it as a starting taxonomy in place of a blank page. Building a risk classification scheme internally from scratch takes months and still risks missing categories regulators care about. The MIT repository gives compliance teams a defensible, peer-reviewed vocabulary they can map directly to register fields, one that, in most practitioners' experience, is easier to defend to auditors than a homegrown scheme with no external validation behind it.

The practical translation looks like this: when registering a credit scoring model, pull the repository's fairness subcategories to pre-populate the risk exposure fields, then layer in jurisdiction-specific obligations such as EU AI Act Annex III classification and EEOC adverse impact thresholds. The repository doesn't replace regulatory mapping, but it closes the gap between a blank inventory template and a register that actually reflects how AI systems fail.

## Regulatory Drivers Making an AI Risk Register Mandatory {#regulatory-drivers-making-an-ai-risk-register-mandatory}

Three frameworks now treat a maintained AI system inventory as a hard compliance artifact.

The EU AI Act moves fastest. GPAI provider obligations, including technical documentation and system-level risk management, became enforceable in August 2025. High-risk system obligations covering credit scoring, fraud detection, and insurance pricing carry an August 2026 deadline. Article 9 requires an [EU AI Act risk management system](https://www.openlayer.com/blog/eu-ai-act-risk-management-system-requirements) that runs continuously across the AI lifecycle, not a one-time pre-deployment assessment. That continuous requirement is what makes a static spreadsheet insufficient: the register must reflect current monitoring status, thresholds, and ownership, not the state of the system at launch.

NIST AI RMF, documented at [nist.gov/itl/ai-risk-management-framework](https://www.nist.gov/itl/ai-risk-management-framework), organizes governance across four functions: GOVERN, MAP, MEASURE, and MANAGE. Without an inventory, MAP has no subject matter, MEASURE has no scope, and MANAGE has no baseline.

ISO 42001 requires a formal AI management system with asset tracking as a structural component, similar to how ISO 27001 requires an information asset inventory. Organizations already holding ISO 27001 certification can reach ISO 42001 compliance faster because the asset-tracking discipline transfers directly.

All three frameworks share a common requirement: a named system, a named owner, and a documented risk profile. Gaps in any of those fields are gaps in regulatory coverage, not administrative oversights.

## Core Fields Every AI Risk Register Entry Must Contain {#core-fields-every-ai-risk-register-entry-must-contain}

Every field in a register entry is load-bearing. The table below covers the minimum required set.

| Field | What It Must Contain |
| --- | --- |
| System identifier | Unique, persistent ID traceable across the model registry, audit trail, and deployment logs |
| Owner | Named individual with role title and contact, not a team label |
| Use case and business purpose | Plain-language description of what the system decides or informs, and which population it affects |
| AI type and origin | Vendor-built, internal, embedded-in-SaaS, or research; determines vendor risk review requirements |
| Deployment environment and data sources | Where the system runs and what data it processes, including regulated data categories |
| Risk tier | Classification under applicable framework, with the specific provision cited |
| Regulatory obligations | Each obligation listed as a discrete item with current compliance status and any open gaps named and owned |
| Lifecycle stage | Development, testing, production, or retirement |
| Last review date and next scheduled review | Linked to the evaluation record in the audit trail, never a bare date string |
| Approval status | Named approver, approval date, and any conditions or exceptions attached |

Leave any of these blank and the record fails its audit function. An auditor reviewing an empty "regulatory obligations" field will not conclude the field was skipped at data entry; they will conclude the assessment was never done.

## How to Risk-Tier AI Systems in Your Register {#how-to-risk-tier-ai-systems-in-your-register}

Risk tiering starts with four dimensions assessed independently before any composite score is calculated.

- Impact scope: how many people the system affects, and whether those effects are direct decisions or informing inputs
- Failure severity: whether harm is reversible (a flagged resume can be re-reviewed) or irreversible (a denied loan under automated adverse action)
- Observability: whether failures surface before they cause harm, or only after downstream consequences have already propagated
- Regulatory exposure: whether the system falls under EU AI Act Annex III high-risk classification, NIST AI RMF high-impact tiers, or sector-specific obligations like the NAIC Model Bulletin for insurance AI

Each dimension scores on a 1 to 4 scale with documented rationale as part of a broader [AI risk scoring model](https://www.openlayer.com/blog/ai-risk-scoring-model-guide). The composite score determines which governance tier applies: low-scoring systems (composite scores of 1 to 2 across all four dimensions) get periodic review and standard monitoring; high-scoring systems (scores of 3 to 4 across one or more dimensions, or a composite average of 3 or above) get pre-deployment fairness testing, demographic parity gates, and mandatory approval workflows before any material change, consistent with an internal [AI risk tiering](https://www.openlayer.com/blog/ai-governance-internal-risk-tiers) structure.

The classification is not permanent. A system that scored moderate risk at launch may cross into high-risk territory when its user base expands from internal staff to external customers, when a new regulatory obligation attaches to its use case, or when the underlying model is updated with new training data. Each of those events should trigger an automatic re-scoring workflow. Changes in deployment scope, model version, data sources, or applicable regulatory classification each constitute a re-tiering event that produces a new composite score and, where the tier changes, routes the system through the appropriate approval gate before it continues operating.

## The Shadow AI Problem: Surfacing Unregistered Systems {#the-shadow-ai-problem-surfacing-unregistered-systems}

Unregistered AI enters organizations through three channels, and none of them involve a formal intake process, a pattern often described as [shadow AI governance](https://www.openlayer.com/blog/unauthorized-ai-governance) failure.

A data science team fine-tunes a model to automate a manual review step and never registers it. A product team connects a third-party LLM API under time pressure, skipping risk review entirely. A business unit deploys an off-the-shelf generative tool that processes customer records without compliance sign-off. By the time an audit surfaces any of them, the model may have been running for months with no behavioral baseline on record.

[A dark, atmospheric digital illustration showing three shadowy pathways converging into a corporate network infrastructure. Each pathway represents a different entry point: a data science lab with glowing neural network nodes, a product team workspace with API connection cables, and a business office with off-the-shelf software icons. The paths flow like invisible streams into a central server hub that has no monitoring sensors attached. The overall color palette uses deep blues and purples with faint amber highlights on the unmonitored central hub, conveying the concept of undetected AI systems entering an organization unregistered and unmonitored.](https://cdn.sanity.io/images/m9qfap23/production/e5c30e9101267a40170d172374529bd97adc01ca-1537x1023.png?w=1400&fit=max&auto=format)

Discovery requires active mechanisms, not periodic surveys. Three approaches cover most of the gap:

- LLM gateway traffic capture intercepts all inference requests routed through a centralized API layer, surfacing models and endpoints that never appeared in any intake form
- CASB and DLP integration ingests signals from network proxy and data-loss prevention tools, identifying AI SaaS tools accessing regulated data outside the governance perimeter
- Native integration auto-population pulls system metadata directly from connected enterprise platforms, matching deployed agents against the existing registry without manual entry

A register populated only through voluntary submission will always lag actual deployment, which is why [continuous AI risk monitoring](https://www.openlayer.com/blog/continuous-ai-risk-assessment-guide) matters more than a periodic snapshot. That gap between when a system starts running and when it appears in the inventory is where EU AI Act Article 9 risk management obligations and NIST AI RMF accountability requirements go unmet. Unregistered models cannot be monitored for drift, cannot be mapped to regulatory obligations, and cannot be pulled from production quickly when a failure surfaces. Discovery mechanisms close the gap; without them, the register documents intent instead of reality.

## AI System Lifecycle Stages and Stage-Gate Governance {#ai-system-lifecycle-stages-and-stage-gate-governance}

Each lifecycle stage in the register carries its own entry criteria, exit criteria, and named approvers. Treating a stage transition as an administrative status change and not a governance gate is where compliance gaps accumulate quietly.

[A sleek, modern diagram showing an AI system lifecycle pipeline with five sequential stages flowing left to right: a blueprint/design phase with circuit board patterns, a laboratory testing phase with microscope and data charts, a rocket launch representing production deployment, a radar/dashboard screen representing active monitoring, and a sunset horizon representing retirement and archiving. Each stage is connected by glowing directional arrows. The overall color palette uses deep navy blues, electric blues, and amber accents on a dark background, conveying a structured, governed, enterprise technology workflow with stage gates between each phase.](https://cdn.sanity.io/images/m9qfap23/production/e57f4ecc6442670e2858e4dea5bb8399055f7131-1537x1023.png?w=1400&fit=max&auto=format)

### Development

Entry: a completed intake form with system identifier, owner, use case, and preliminary risk tier. Exit: a design review confirming intended use aligns with approved scope.

### Validation

Entry: evaluation results covering accuracy, fairness, and safety on held-out data. Exit: named sign-off from the Model Owner confirming thresholds are met, plus Governance Lead confirmation that regulatory obligations are mapped. For high-risk systems, this gate requires multi-reviewer approval before any inference runs against real user data, mirroring the rigor expected in an [EU AI Act conformity assessment](https://www.openlayer.com/blog/eu-ai-act-conformity-assessment-requirements-process-guide).

### Production

Entry: a CI/CD gate passing all pre-deployment tests, including demographic parity within the approved threshold and groundedness scores above the deployment floor. Exit criteria are event-triggered, not scheduled: drift beyond a defined threshold, a failed recertification, or a material change in model version, data sources, or deployment scope each reopen the gate.

### Monitoring

Active production monitoring is its own stage. The register entry for a live system must name the specific metrics under surveillance, the threshold value triggering each alert, and the date those thresholds were last reviewed. A field listing "monitored" without named metrics is not a monitoring record.

### Retirement

Retirement requires four documented actions: status changed to retired in the registry, inference access removed and logged with a timestamp, evaluation and incident records archived with a named retention period, and any downstream systems that consumed the model's outputs notified and updated.

## Maintaining the Register: Recertification, Drift, and Stale Entries {#maintaining-the-register-recertification-drift-and-stale-entries}

A register accurate at intake but never revisited projects false confidence to auditors while actual system behavior drifts away from what the documentation says.

Recertification should fire on time-based triggers. Annual reviews are a floor. High-risk systems under EU AI Act Annex III warrant quarterly cycles, particularly where the model touches credit decisions, hiring screens, or clinical outputs, supported by [drift detection and compliance monitoring](https://www.openlayer.com/blog/high-risk-ai-drift-detection-annex-iv-monitoring). Each recertification event produces a dated audit record, effectively an [AI risk assessment report](https://www.openlayer.com/blog/ai-risk-assessment-report-guide), noting who reviewed, what metrics were checked, whether thresholds still reflect current risk appetite, and whether the regulatory obligation mapping remains current.

Stale entries need automated detection. Any entry exceeding its recertification window should surface in the governance dashboard with an escalation owner and a deadline. An overdue entry that sits unresolved routes to the Governance Lead and Model Owner automatically. Silence is not a passing grade.

Production monitoring data belongs in the register. When a drift signal crosses its threshold, that event writes back to the register entry and flags the system for re-review. When an incident record is generated, it attaches to the registry entry. The register is the system of record; monitoring telemetry feeds it.

Mid-lifecycle scope changes are the most commonly missed re-tiering trigger. A low-risk internal summarization tool redeployed to a customer-facing workflow processes a different population under different regulatory exposure. That change requires a new risk assessment, new approvals, and updated monitoring thresholds before the expanded deployment begins. The register entry should log the scope change, the prior tier, the new composite score, and the approval event authorizing the transition.

## Connecting the Register to Runtime Controls {#connecting-the-register-to-runtime-controls}

A register entry that documents risk without connecting to what the system actually does at inference time is a policy artifact, not a control. The connection between the inventory and runtime behavior is where governance either holds or collapses.

Risk tier drives guardrail configuration. A [high-risk EU AI Act system](https://www.openlayer.com/blog/high-risk-ai-systems-eu-ai-act-guide) should have a different enforcement profile than an internal summarization tool scored low across all four dimensions. That profile specifies which guardrails apply, what thresholds trigger blocking versus logging, and whether outputs route to a human reviewer before delivery. When a system's risk tier changes, its enforcement configuration should update before its next inference run, not at the next scheduled review.

CI/CD deployment gates should query register status before promotion. A model attempting to move from validation to production against an incomplete or unapproved register entry should fail the gate. That blocking step is what separates enforcement from observation. A deployment pipeline that checks evaluation scores but ignores register status allows a system with unresolved compliance gaps to ship as long as its accuracy metrics pass.

Audit evidence generated at inference time flows back to the register entry. When a guardrail blocks an output, that event carries the agent ID, metric score, policy rule triggered, and timestamp. When a threshold breach fires a drift alert, that record attaches to the registry entry for the affected system. The register is not a static intake document; it is a continuously updated compliance record, populated by enforcement events the system itself generates.

## Multi-Agent and Agentic System Entries in a Risk Register {#multi-agent-and-agentic-system-entries-in-a-risk-register}

Agentic systems don't fit cleanly into the single-model entry format and demand their own [agent governance](https://www.openlayer.com/blog/ai-agent-governance-guide) approach. A single-model API has one risk tier, one output type, one owner. An agent has a tool allowlist, external write access, multi-step decision chains, and potentially other agents it coordinates with. Each of those dimensions requires its own register field.

The additional fields an agentic entry must contain:

- Authorized tool allowlist: the specific tools the agent is permitted to invoke, versioned and named at the level of the tool ID, not the tool category
- External write scope: which external systems the agent can modify, including databases, APIs, and third-party services, with explicit notation of any write access to production data
- Human oversight checkpoints: where in the workflow a human reviewer must approve or override before execution continues, and what triggers escalation
- Audit trail specification: what decision chain data is captured at each step, sufficient to reconstruct the full execution path after the fact

Multi-agent architectures complicate this further. Each agent in a pipeline may carry a different risk tier. A routing agent that delegates to a document retrieval agent and a database write agent inherits some portion of the risk from both. The register entry for the workflow needs a composite risk score for the full execution chain, beyond individual component scores alone. Listing each sub-agent at its own tier without aggregating obscures where the actual exposure sits.

Tool-calling failures and unauthorized tool invocations are first-class risk events. An agent invoking a tool outside its registered allowlist is a control failure that belongs in the incident record attached to the register entry. The same applies to tool-calling errors that produce downstream state changes before the failure surfaces. These events need a formal home in the register, with the same severity classification and owner accountability that applies to model output incidents.

## How Openlayer Puts the AI Risk Register Into Practice {#how-openlayer-puts-the-ai-risk-register-into-practice}

For a post covering the full register-to-runtime arc (intake, lifecycle stage gates, agentic system entries, and shadow AI discovery), it is worth being precise about where governance platforms currently draw their boundaries. Credo AI covers policy documentation, model cards, and risk assessments, but currently stops at the governance layer: it does not monitor live model outputs or enforce behavioral thresholds at inference time. IBM watsonx.governance provides AI governance and data governance within the Watson ecosystem, with model inventory and bias detection capabilities, but its runtime enforcement is currently bounded by that ecosystem and does not extend to arbitrary third-party or custom-built models. Openlayer covers the full span: intake and inventory, continuous production monitoring, and enforcement gates that block deployment when compliance conditions are unmet, across any model architecture and beyond those built on a specific vendor stack.

Openlayer's governance intake interface lets compliance teams register AI systems, collect structured metadata, and route submissions through role-based approval workflows without writing code. Submissions follow defined review queues; approvals are logged with named reviewers and timestamps.

Shadow AI discovery runs through the LLM Gateway, which captures traffic from all inference requests routed through the centralized API layer. Systems that never appeared in an intake form surface in the gateway dashboard and can be routed directly into the registration workflow.

Risk scores recalculate dynamically when a system's user base expands, a new regulatory obligation attaches, or a model version changes. A system that fails recertification cannot promote to production; the gate blocks the build, not the reviewer's calendar.

Register entries map to five built-in frameworks: EU AI Act, NIST AI RMF, ISO 42001, AIUC-1, and the Openlayer Governance Framework. Compliance status against each is exportable as an audit-ready evidence package on demand.

## Final Thoughts on Turning an AI Risk Register Into a Real Governance Control {#final-thoughts-on-turning-an-ai-risk-register-into-a-real-governance-control}

A register that captures every deployed system, ties each one to a named owner, and updates automatically when monitoring thresholds breach is genuinely different from a static intake document that reflects the state of your stack at launch. The MIT AI risk repository gives your taxonomy a peer-reviewed foundation, but the register earns its audit value through continuous updates, automated discovery of shadow AI, and enforcement gates that block deployment when compliance fields are incomplete. Those connections are what move governance from observation to control. [Talk to our team](https://www.openlayer.com/contact) to see how that wiring works in practice.

## FAQ {#faq}

### How does an AI use case get registered, risk-assessed, and continuously monitored from end to end?

Registration starts with a structured intake form that captures system identifier, named owner, use case, risk tier, and regulatory obligations, routed through role-based approval workflows with logged reviewer decisions. Once approved, the system enters lifecycle stage management where each transition (development to validation to production) requires named sign-offs and passing CI/CD evaluation gates. In production, monitoring runs continuously against named metrics and thresholds, with drift events and guardrail triggers writing back to the registry entry automatically so the record reflects current system behavior, not its state at launch alone.

### How should multi-agent systems be registered in an AI risk register when each agent in a pipeline carries a different risk tier?

Each agent in the pipeline needs its own register entry covering authorized tool allowlist, external write scope, and human oversight checkpoints, but the workflow also requires a composite risk score for the full execution chain, extending beyond individual component scores. A routing agent that delegates to a database write agent inherits exposure from both; listing each sub-agent at its own tier without aggregating the pipeline risk obscures where the actual liability sits. Tool invocations outside a registered allowlist are first-class incidents that belong in the audit record attached to the registry entry, with the same severity classification and owner accountability as model output incidents.

### How do I build a governance process that makes AI evaluation mandatory across all teams, regardless of framework?

The mechanism is a CI/CD deployment gate that queries register status before promotion: a model attempting to move from validation to production against an incomplete or unapproved register entry fails the build, not a reviewer's calendar. That blocking step, beyond flagging the gap, is what separates enforcement from observation. Paired with a framework-agnostic evaluation layer (covering custom agents, non-LangChain RAG, and traditional ML) and a no-code governance intake interface that compliance teams can operate without developer mediation, evaluation becomes a shared platform service instead of a per-team configuration exercise.

### What is the MIT AI Risk Repository and how does it relate to building an AI risk register?

The MIT AI Risk Repository is a peer-reviewed catalog of AI failure modes described in the body section above. Teams use it as a starting taxonomy to pre-populate risk exposure fields in their register entries. For example, when registering a credit scoring model, they pull the repository's fairness subcategories and then layer in jurisdiction-specific obligations like EU AI Act Annex III classification and EEOC adverse impact thresholds. It does not replace regulatory mapping, but it closes the gap between a blank inventory template and a register that reflects how AI systems actually fail.

### How do you surface shadow AI systems that were never registered through a formal intake process?

Three active discovery mechanisms cover most of the gap (LLM gateway traffic capture, CASB and DLP integration, and native integration auto-population), each described in detail in the Shadow AI section above. A register populated only through voluntary submission will always lag actual deployment. That gap between when a system starts running and when it appears in the inventory is where EU AI Act Article 9 risk management obligations and NIST AI RMF accountability requirements go unmet.