An AI risk register is a decision-routing tool. Its job is to ensure that when something goes wrong with an AI deployment — and something will — the organization already knows who owns the problem, what controls were supposed to prevent it, and what the regulatory exposure looks like. Every field in the register exists to answer one of those three questions.
This recap synthesizes the chapter's ten articles into a single working structure. It references what you read; it does not re-teach it. If an entry here is unfamiliar, go to the source article.
The Five Required Fields
These are the fields every register entry must contain. The logic for each traces directly to the chapter.
EU AI Act Tier Classification — The risk tier assigned under Articles 6–51 of the EU AI Act: Unacceptable, High, Limited, or Minimal. When it comes up: Any customer operating in the EU, or any US company with EU data subjects, will be asked this question during procurement. You need the answer before the meeting. Don't confuse with: NIST AI RMF risk categories, which are voluntary and framework-based, not statutory. The EU Act tier is a legal classification; the RMF category is an internal governance choice.
AI System Name and Deployment Scope — The specific model or AI system, including version, deployment context (internal tool, customer-facing, automated decision), and data domains it touches. When it comes up: Vendor assessment conversations. Customers want to know whether you've inventoried your own AI surface before you help them inventory theirs. Don't confuse with: The vendor's product name. A single product can contain multiple AI systems with different risk profiles.
Applicable Sector Regulations — The regulatory frameworks that govern the data or decisions the AI system handles: HIPAA for health data, FFIEC guidance for financial services, FERPA for education, SOC 2 Type II for SaaS broadly. When it comes up: Regulated industry accounts. The EU AI Act tier tells you the baseline; sector regulations tell you the floor for that specific customer. Don't confuse with: General data privacy law (GDPR, CCPA). Those apply to data handling broadly. Sector regulations impose additional obligations specific to the AI use case.
OWASP LLM Top 10 Exposures and Current Mitigations — Which of the ten LLM-specific risks apply to this system, and what controls are currently in place. An exposure without mitigation belongs in the findings column, not the field definition. When it comes up: Security review conversations and RFP responses. Customers with mature security programs will ask which OWASP LLM risks you've assessed. "We're aware of them" is not an answer. Don't confuse with: The OWASP Web Application Security Top 10. The LLM list is a separate framework addressing model-specific attack surfaces — prompt injection, training data poisoning, excessive agency — that the web application list does not cover.
Accountable Owner per Risk Category — A named role (not a team) responsible for each risk category in the register. Model risk, data risk, identity and access risk, regulatory compliance risk, operational risk, and third-party risk each need a single accountable owner. When it comes up: Governance conversations with CISOs and GRC teams. The question is always "who do we call?" The register answers it before the incident. Don't confuse with: Responsible party. Accountability means the owner answers for outcomes. Responsibility means they do the work. One person is accountable; multiple people may be responsible.
If you remember nothing else: EU AI Act tier classification is the first field because it determines which other fields are mandatory. A High-risk system under the Act requires conformity assessment documentation, human oversight mechanisms, and audit logging. A Minimal-risk system does not. The tier is the gate.
Risk Category Taxonomy
Six categories cover the register's scope. Each maps to control disciplines from the chapter and to architectural layers from the Enterprise Deployment article.
| Risk Category | Definition |
|---|---|
| Model Risk | Risks arising from model behavior: hallucination, bias, adversarial manipulation, output integrity |
| Data Risk | Risks in training data, inference data, and RAG stores: provenance, poisoning, privacy exposure |
| Identity and Access Risk | Risks from how AI agents authenticate, what they're authorized to do, and how credentials are managed across task lifecycles |
| Regulatory Compliance Risk | Risks of violating applicable law or regulation through AI system behavior or outputs |
| Operational Risk | Risks to availability, reliability, and performance: model DoS, dependency failures, monitoring gaps |
| Third-Party / Supply Chain Risk | Risks from foundation model providers, plugins, connectors, and fine-tuning vendors |
If you remember nothing else: The register tracks who owns the answer when something goes wrong — not a catalog of hypothetical failures.
Mapping Table 1: Risk Categories → Control Disciplines
| Risk Category | Primary Control Discipline | Chapter Source | Key Control Mechanism |
|---|---|---|---|
| Model Risk | Security Testing | OWASP LLM Top 10; Prompt Injection article | Red-teaming, adversarial input testing, output validation |
| Data Risk | Data Management | Training Data Risk article | Provenance documentation, differential privacy, data lineage |
| Identity and Access Risk | Identity and Access Management | AI Agent Identity article | Agent credential lifecycle management, least-privilege scoping, session binding |
| Regulatory Compliance Risk | Governance | EU AI Act article; NIST AI RMF article | Conformity assessment, risk documentation, human oversight controls |
| Operational Risk | Incident Response | AI Incident Response article | Monitoring, alerting thresholds, rollback procedures |
| Third-Party / Supply Chain Risk | Vendor Management | Third-Party AI Risk article | Vendor assessment questionnaires, contractual AI use restrictions, model provenance verification |
Mapping Table 2: Risk Categories → Architectural Layers
| Risk Category | Primary Architectural Layer | Secondary Layer | Control Point |
|---|---|---|---|
| Model Risk | Model Layer | Orchestration Layer | Output filtering, guardrails, confidence thresholds |
| Data Risk | Data Layer | Orchestration Layer | RAG store access controls, context window sanitization |
| Identity and Access Risk | Identity Layer | Integration Layer | Agent authentication tokens, OAuth scopes, credential expiration enforcement |
| Regulatory Compliance Risk | Monitoring Layer | Identity Layer | Audit logging, decision traceability, human-in-the-loop checkpoints |
| Operational Risk | Monitoring Layer | Model Layer | Latency alerting, fallback routing, rate limiting |
| Third-Party / Supply Chain Risk | Integration Layer | Model Layer | API gateway controls, plugin sandboxing, model version pinning |
Vocabulary Collision Table: AI Terms vs. IDAM Equivalents
These are the terms where your existing IDAM vocabulary will mislead you if you don't check the divergence.
| AI Term | What It Means in AI | IDAM Equivalent | Key Divergence |
|---|---|---|---|
| Agent | An autonomous AI process that takes actions, calls tools, and makes decisions across a multi-step task | Service account or non-human principal | An IDAM service account has a static credential and a defined permission set. An AI agent dynamically determines which tools to call and in what sequence — the "permission set" is effectively decided at runtime, not at provisioning time. |
| Trust | A model's confidence score in its own output, or the degree to which one system accepts another's outputs without verification | Federation trust, PKI trust chain | In IDAM, trust is a structural relationship established before runtime. In AI, "trust" often describes a runtime inference about output reliability. These are not the same thing and should not be governed the same way. |
| Scope | The domain of data or actions an AI system is permitted to access during a task | OAuth scope, permission boundary | OAuth scopes are explicit, enumerated, and static per token. AI task scope is often inferred from the prompt and can expand mid-task through tool-calling chains. The absence of explicit enumeration is the risk. |
| Principal | The entity whose identity is being asserted in an AI interaction (user, agent, or model) | Principal in access control (user, group, role) | In IDAM, a principal is a well-defined entity with a managed identity. In agentic AI, the "principal" may be a chain of models, each acting on behalf of the last, with no persistent identity binding across the chain. |
If you remember nothing else: When a customer says "trust," find out which layer they mean before you answer. The word is doing different work in AI architecture than it does in federation, and conflating them in a customer conversation will cost you credibility with their security team.
AI Risk Register Template
Applicable to any enterprise AI deployment. Populate one row per AI system. Review cadence: quarterly for High-risk EU AI Act tier; annually for Limited and Minimal.
| Field | Entry |
|---|---|
| AI System Name | [System name, version, vendor] |
| Deployment Scope | [Internal / Customer-facing / Automated decision / Hybrid] |
| EU AI Act Tier | [Unacceptable / High / Limited / Minimal] |
| Conformity Assessment Required | [Yes — Article 43 / No] |
| Applicable Sector Regulations | [List: HIPAA / FFIEC / FERPA / SOC 2 / Other] |
| OWASP LLM Exposures | [List applicable LLM01–LLM10 identifiers] |
| Current Mitigations per Exposure | [One line per exposure: control in place or "No mitigation — open finding"] |
| Model Risk Owner | [Named role] |
| Data Risk Owner | [Named role] |
| Identity and Access Risk Owner | [Named role] |
| Regulatory Compliance Risk Owner | [Named role] |
| Operational Risk Owner | [Named role] |
| Third-Party / Supply Chain Risk Owner | [Named role] |
| Architectural Layers in Scope | [Model / Orchestration / Integration / Data / Identity / Monitoring] |
| Last Review Date | [Date] |
| Next Review Date | [Date] |
| Open Findings | [Count and brief description, or "None"] |
Not covered above, but worth knowing: The register template above does not include a field for AI system lineage — the chain of foundation model, fine-tuning, and RAG configuration that produced the deployed system. In production, this field matters for supply chain risk and for regulatory documentation under the EU AI Act's technical documentation requirements (Annex IV). Add it.
For More Information
| Recap Entry | Source Article | Section |
|---|---|---|
| EU AI Act tier classification | EU AI Act: What the Risk Tiers Actually Require | Risk Classification Framework |
| OWASP LLM Top 10 exposures | OWASP LLM Top 10: A Field Guide for Enterprise Teams | Exposure Definitions; Mitigation Mapping |
| Sector regulations (HIPAA, FFIEC, FERPA) | AI in Regulated Industries: Sector-by-Sector Compliance Map | Per-Sector Obligations |
| Architectural layers | Enterprise AI Deployment: Architecture and Control Points | Layer Definitions; Control Point Mapping |
| NIST AI RMF vs. EU AI Act | NIST AI RMF: Mapping the Framework to Your Stack | Framework Comparison |
| Prompt injection; adversarial attacks | Prompt Injection and Adversarial Attacks: The Threat Model | Attack Taxonomy; Detection Controls |
| Training data provenance and poisoning | Training Data Risk: Provenance, Privacy, and Poisoning | Risk Categories; Control Mechanisms |
| Agent credential lifecycle | AI Agent Identity: The Credential Problem Nobody Has Solved | Identity Binding; Credential Expiration |
| Third-party and vendor assessment | Third-Party AI Risk: Vendor Assessment in the LLM Era | Assessment Framework; Contractual Controls |
| Incident response for AI systems | AI Incident Response: When Your Model Misbehaves | Response Playbook; Escalation Logic |