You've completed ten lessons. This document doesn't summarize them — it organizes them into a structure you can use. The AI risk register is the chapter's synthesizing artifact: a framework for governing any AI deployment you encounter in a public sector account. Five columns. Four control disciplines. One document you can open before any CISO or CAIO conversation.
The Register Structure
1. System Inventory
System Inventory — A complete enumeration of every AI system in the deployment: vendor, architecture type, data inputs, and deployment environment.
When it comes up: Every governance conversation starts here. CAIOs who can't answer "what AI systems do you have running?" can't answer anything downstream. This is the first gate most agencies haven't passed.
Don't confuse with: A standard application inventory or software asset list. AI systems require additional fields: model provider, training data provenance, fine-tuning status, and whether the system takes autonomous action on behalf of users.
If you remember nothing else: You cannot govern what you haven't named. The register starts with a complete system list, not a risk assessment.
2. EU AI Act Classification
EU AI Act Tier — The risk classification assigned to each AI system under the Act's four-tier framework: Unacceptable, High, Limited, or Minimal Risk.
When it comes up: Any deployment touching EU data subjects, or any agency operating under EU-aligned procurement standards. High Risk triggers conformity assessment obligations before deployment — not after.
Don't confuse with: NIST AI RMF risk categories, which use different terminology and map to different obligations. The EU Act's "High Risk" designation is a legal classification with specific Annex III criteria, not a general severity rating.
If you remember nothing else: High Risk triggers conformity assessment before deployment. The compliance window for most Annex III categories closes August 2026.
Table 1 — EU AI Act Tier to Obligation
| Tier | Definition | Key Obligations | Enforcement Date |
|---|---|---|---|
| Unacceptable Risk | Prohibited applications: social scoring by public authorities; real-time biometric surveillance in public spaces; subliminal manipulation systems | Complete prohibition. No deployment path. | August 2, 2024 |
| High Risk | Annex III systems: critical infrastructure, education, employment, essential services, law enforcement, migration, democratic processes | Conformity assessment; technical documentation; human oversight; accuracy/robustness requirements; EU database registration | August 2, 2026 |
| Limited Risk | Chatbots, deepfake generators, AI-generated content | Transparency disclosure to users | August 2, 2026 |
| Minimal Risk | Spam filters, recommendation engines, AI-enabled productivity tools | No mandatory obligations; voluntary codes of conduct encouraged | No hard deadline |
3. Sector Regulation Applicability
Sector Regulation Map — The applicable regulatory regime(s) for each AI system, the specific constraints each imposes, and the evidence each requires.
When it comes up: Healthcare, financial services, and federal civilian deployments each carry obligations that layer on top of EU AI Act requirements. As you saw in Lesson 7, regimes stack — they don't substitute.
Don't confuse with: General data protection law (GDPR, CCPA). Sector regulations impose AI-specific constraints: HIPAA's minimum necessary standard applied to training data, GLBA's safeguards rule applied to model outputs, FedRAMP's continuous monitoring applied to AI inference infrastructure.
If you remember nothing else: Sector obligations stack. A healthcare AI system subject to HIPAA does not receive lighter EU AI Act treatment because of it. Both apply, independently.
4. OWASP LLM Top 10 Exposure Mapping
OWASP Exposure Map — For each AI system: the applicable categories from the OWASP LLM Top 10, the architectural condition creating the exposure, and the current mitigation in place.
When it comes up: Security reviews, penetration testing scopes, and vendor security questionnaires. CISOs who've read the OWASP LLM Top 10 will ask about specific categories by name. Know which ones apply to the architecture in front of you before you're in the room.
Don't confuse with: The OWASP Web Application Security Top 10. The LLM list is distinct — it covers prompt injection, insecure output handling, training data poisoning, model denial of service, and supply chain vulnerabilities that have no direct equivalent in web application security.
If you remember nothing else: Prompt injection (LLM01) cuts across every architecture that accepts external input. If the system ingests user-supplied text and acts on it, that exposure is present regardless of other controls.
5. Accountable Owner per Risk Category
Risk Ownership — Named individuals or roles accountable for each risk category in the register: Security, Privacy, Legal, and Regulatory.
When it comes up: Audit preparation, incident response planning, and any governance conversation where "who owns this?" is the real question. A register without named owners is a document, not a control.
Don't confuse with: Operational ownership of the AI system itself. The system owner is responsible for the deployment; risk owners are accountable for the control disciplines that govern it. These are frequently different people, and the distinction matters when something goes wrong.
If you remember nothing else: CISO owns security risk. CPO or DPO owns privacy risk. General Counsel owns liability. The compliance function owns regulatory. Any empty seat in that row is an open finding.
6. Cross-Chapter Architectural Mapping
Control Discipline Map — The connection between each risk category in the register and the specific control disciplines introduced across this chapter, mapped to the architectural layers introduced in Enterprise Deployment.
When it comes up: Any conversation where a buyer asks which team is responsible for a specific control, or where a security review needs to know which layer a mitigation lives at. The register is what makes that mapping retrievable.
Don't confuse with: A responsibility assignment matrix (RACI). The architectural mapping tells you where in the system a control operates, not just who owns it.
If you remember nothing else: The architectural layer determines which control discipline applies first. Security controls live at the inference and API layer. Privacy controls live at the data layer. Regulatory controls live at the system classification layer.
Table 2 — Risk Category to Control Discipline
| Risk Category | Control Discipline | Source Lessons | Architectural Layer (Enterprise Deployment) |
|---|---|---|---|
| Security | OWASP LLM Top 10 mitigations; prompt injection controls; output validation; supply chain review | Lessons 1–3 | Inference layer; API gateway; retrieval pipeline |
| Privacy | Data minimization; PII detection and redaction; retention controls; consent management | Lesson 4 | Data ingestion layer; vector store; logging infrastructure |
| Legal | IP ownership; liability allocation; contractual AI use restrictions; acceptable use policy | Lesson 6 | Model selection; vendor contracts; system prompt governance |
| Regulatory | EU AI Act conformity assessment; sector obligations (HIPAA, GLBA, FedRAMP, SOC 2); audit logging | Lessons 5, 7 | System classification layer; human oversight controls; audit infrastructure |
Vocabulary Collision Zone
Terms that surfaced across this chapter where IDAM intuition misleads. The Key Divergence column is where the learning lives.
Table 3 — Vocabulary Collision Zone
| AI Term | What It Means in AI | IDAM Equivalent | Key Divergence |
|---|---|---|---|
| Token | A subword unit processed by the LLM; the atomic unit of model input and output | OAuth access token; JWT bearer credential | An LLM token carries no authorization claims. Treating it as a credential boundary is a category error. |
| Session | The accumulated context window of an ongoing conversation | An authenticated interaction with defined lifetime and revocation path | AI sessions have no native revocation mechanism. Context persists until the window closes, not until policy says stop. |
| Context | The full input window available to the model, including injected system prompts and retrieved documents | Attributes used in an authorization decision: role, device posture, location | AI context is unverified by default. Injected content carries no provenance attestation. |
| Scope | Loosely, the domain or capability boundary of a model or agent | A formally declared permission set in an OAuth authorization request | AI "scope" is not machine-enforceable. No token is issued; no authorization server validates it. |
| Identity | The persona or role assigned to an agent via system prompt | A verified, persistent principal with credentials and a lifecycle | AI agent identity is asserted, not verified. No issuing authority, no credential rotation, no revocation. |
| Agent | An autonomous system that takes actions on behalf of a user or another system | Service account; non-person entity (NPE) | IDAM service accounts have fixed, auditable permissions. AI agents can acquire new capabilities mid-task through tool calls. |
One-Page Register Template
Complete one row per AI system in the deployment. Flag any row where the EU AI Act tier is High Risk and no conformity assessment is in progress. Flag any row where a Risk Ownership cell is empty. Those flags are your open items going into any governance conversation.
Table 4 — AI Risk Register: Working Template
| System Profile | EU AI Act Classification | Sector Regulation Map | OWASP Exposure Map | Risk Ownership |
|---|---|---|---|---|
| System name; vendor; architecture type (RAG / fine-tuned / API wrapper / agentic); deployment environment (cloud / on-prem / FedRAMP boundary); data inputs and outputs | Tier (Unacceptable / High / Limited / Minimal); Annex III category if High Risk; conformity assessment status; EU database registration status | Applicable regime(s) (HIPAA / GLBA / FedRAMP / SOC 2); specific constraint per regime; evidence required (audit log, DPIA, safeguards documentation) | Applicable OWASP LLM Top 10 categories; architectural condition creating each exposure; current mitigation; residual risk rating (High / Medium / Low) | Security Owner (CISO); Privacy Owner (CPO / DPO); Legal Owner (GC / CLO); Regulatory Owner (Compliance function) |
For More Information
| Topic | Source Lesson |
|---|---|
| AI system inventory and asset cataloging | Lesson 8: AI System Cataloging and Asset Management |
| EU AI Act risk tiers and compliance timeline | Lesson 5: The EU AI Act — Risk Tiers and Compliance Timeline |
| Sector-specific obligations: HIPAA, GLBA, FedRAMP, SOC 2 | Lesson 7: Sector-Specific Obligations |
| OWASP LLM Top 10 — categories, architecture, mitigations | Lessons 1–3: Security Vulnerabilities in AI Systems |
| Privacy controls and data minimization | Lesson 4: Privacy Controls in AI Deployments |
| Legal exposure and liability allocation | Lesson 6: Legal Risk in AI Deployments |
| Accountable owner framework and governance structures | Lesson 9: AI Governance Structures and Accountability |
| Architectural layers and control points | Enterprise Deployment Chapter, Lesson 3: Architectural Layers and Control Points |