--- title: AI Model Risk Catalog url: https://www.emergentmind.com/topics/ai-model-risk-catalog type: topic --- # AI Model Risk Catalog Searching arXiv for the cited papers and closely related risk-catalog frameworks to ground the article in current literature. AI model risk catalogs are structured systems for naming, organizing, comparing, and operationalizing the risks associated with AI models and AI-enabled systems across development, deployment, and governance contexts. In the recent literature, the term spans several partially overlapping artifacts: taxonomies of harms, incident-grounded repositories, disclosure templates, internal-use reporting frameworks, scoring systems, audit ontologies, and mitigation taxonomies. A central motivation is that risk discussion has been fragmented across developers, researchers, auditors, regulators, and incident trackers, producing inconsistent terminology and uneven coverage. Recent work therefore converges on catalog-style representations that classify risks by domain, causal structure, lifecycle stage, operational threat vector, or mitigation type, and that support reporting, evaluation, and governance workflows [2508.16672], [2408.12622], [2503.05780]. ## 1. Concept and scope An AI model risk catalog is not a single standardized artifact. In the literature, it appears at least in five forms. First, there are domain taxonomies that classify harms into stable top-level categories such as discrimination, privacy, misuse, misinformation, overreliance, socioeconomic harms, and system safety [2408.12622]. Second, there are developer-facing catalogs extracted from model documentation, intended to improve model cards and related disclosures [2508.16672]. Third, there are operational risk frameworks that score vulnerabilities, assign tiers, or connect catalog entries to audits and control workflows [2508.19281], [2607.02201]. Fourth, there are internal deployment reporting schemas focused on frontier developers’ own use of unreleased models [2604.24966]. Fifth, there are mitigation catalogs that organize countermeasures rather than harms, allowing risks to be linked to governance, technical, operational, and transparency controls [2512.11931]. A common thread is the attempt to provide a “common frame of reference” or interoperable scaffold for risk identification and management [2408.12622], [2512.11931]. The AI Risk Repository constructs a living database of 777 risks extracted from 43 taxonomies and classifies them with a high-level Causal Taxonomy and a mid-level Domain Taxonomy [2408.12622]. The AI Model Risk Catalog derived from Hugging Face model cards instead begins from developer-authored risk statements and compares them with researcher taxonomies and real-world incidents [2508.16672]. Risk Atlas, AIR 2024, and similar efforts further expand the catalog concept into ontology- and policy-oriented structures [2503.05780], [2406.17864]. This plurality matters because “risk” is represented at different levels of abstraction. Some frameworks catalog harms such as “Fraud, scams, and targeted manipulation” or “Lack of capability or robustness” [2408.12622]. Others catalog failure modes such as “Prompt Injection / Prompt Manipulation,” “Deployment Drift,” or “Model Release / IP Leakage” [2508.19281]. Others still catalog audit targets such as “pii-leakage” with explicit probes, metrics, severity bands, and grades [2607.02201]. A plausible implication is that AI model risk catalogs are evolving from descriptive taxonomies toward executable governance infrastructure. ## 2. Core taxonomic architectures Several taxonomic backbones recur across the literature, but they emphasize different organizing principles. The AI Risk Repository defines a high-level Causal Taxonomy in which every risk $r_i$ is classified by Entity, Intentionality, and Timing: $$ \mathrm{CausalClass}(r_i) = (\mathrm{Entity}(r_i), \mathrm{Intent}(r_i), \mathrm{Timing}(r_i)). $$ Its Domain Taxonomy uses seven domains and 23 subdomains: Discrimination & toxicity; Privacy & security; Misinformation; Malicious actors & misuse; Human-computer interaction; Socioeconomic & environmental; and AI system safety, failures, & limitations [2408.12622]. This structure is directly reused by the AI Model Risk Catalog study comparing model cards, repository risks, and incidents [2508.16672]. By contrast, AIR 2024 uses a four-tier hierarchy with four top-level categories: System & Operational Risks, Content Safety Risks, Societal Risks, and Legal & Rights Risks, organized into 16 families, 45 subfamilies, and 314 leaf nodes [2406.17864]. Risk Atlas organizes “DefinitionBoxes” under four lifecycle-oriented types—Training-Data Risks, Inference-Time Risks, Output-Quality & Content Risks, and Non-Technical & Governance Risks—and annotates each item with a “Descriptor” of “traditional,” “amplified,” or “specific” [2503.05780]. The “AI Risk Spectrum” paper proposes a different organizing logic around three causal categories: misuse risks, misalignment risks, and systemic risks, plus risk amplifiers including competitive pressures, accidents, corporate indifference, and coordination failures [2508.13700]. Misuse risks include creating bioweapons, launching cyberattacks, adversarial AI attacks or deploying lethal autonomous weapons. Misalignment risks include specification gaming, scheming and power-seeking tendencies. Systemic risks include concentrating power, accelerating political and economic disempowerment, creating overdependence that leads to human enfeeblement, or irreversibly locking in current values [2508.13700]. These architectures are not identical, but they overlap substantially. Misuse in the spectrum view corresponds closely to malicious actors & misuse in the repository and to multiple AIR 2024 families under deception, political usage, and criminal activities [2408.12622], [2406.17864]. Human agency and overreliance recur in the repository, Risk Atlas, and the spectrum paper’s systemic category [2408.12622], [2503.05780], [2508.13700]. This suggests that the field is converging on a shared set of risk surfaces, while diverging on whether the primary axis should be causal mechanism, harm domain, lifecycle location, or governance use case. ## 3. Empirical catalogs from model cards, repositories, and incidents A major empirical contribution comes from the AI Model Risk Catalog study, which analyzed nearly 460,000 AI model cards from Hugging Face [2508.16672]. In July 2024, the authors downloaded a snapshot of $N_{\text{total}} = 461{,}181$ model repositories, of which approximately $276{,}709$ contained model cards. They identified $N_{\text{risk}} = 64{,}116$ cards with risk-related text, noted that 96% were exact duplicates of risk sections, and reduced the corpus to $N_{\text{unique\_cards}} = 2{,}672$ unique cards by choosing the most-downloaded version in each duplicate group. After extraction, standardization, near-duplicate merging, and manual pruning, the final catalog size was $M_{\text{unique}} = 2{,}863$ risk mentions [2508.16672]. The extraction pipeline used GPT-4o in zero-temperature mode to locate and extract distinct “verb–object” risk mentions. On 10% held-out cards, zero-shot extraction achieved 90% agreement with human annotations over a 50-card sample. Classification into the MIT Risk Repository taxonomy and the DeepMind taxonomy used three prompts per mention with majority voting and achieved accuracy = 83% and macro-F1 = 81% on a 50-item test set [2508.16672]. The most consequential result is the divergence between developer-reported risks, researcher taxonomies, and incident distributions. Developers concentrated on Discrimination & Toxicity and AI System Safety, while underrepresenting misuse, privacy, overreliance, and socioeconomic harms [2508.16672]. The paper reports: - $p_{\text{dev}}(A)=44\%$, $p_{\text{inc}}(A)=27\%$, $p_{\text{repo}}(A)=32\%$ - $p_{\text{dev}}(B)=37\%$, $p_{\text{inc}}(B)=24\%$, $p_{\text{repo}}(B)=14\%$ - $p_{\text{dev}}(E)=4\%$, $p_{\text{inc}}(E)=22\%$, $p_{\text{repo}}(E)=17\%$ - $p_{\text{dev}}(F)=0.6\%$, $p_{\text{inc}}(F)=2\%$, $p_{\text{repo}}(F)=7\%$ - $p_{\text{dev}}(G)=2\%$, $p_{\text{inc}}(G)=4\%$, $p_{\text{repo}}(G)=18\%$ [2508.16672]. The paper highlights $\Delta(E)=p_{\text{inc}}(E)-p_{\text{dev}}(E)=18\%$ with 95% CI $[16\%,20\%]$ as a marked developer blind spot on malicious use [2508.16672]. It also reports that model cards with risk sections fell from 17% in 2022 to 14% in 2024, and that unique risk content remains less than 1% of all cards [2508.16672]. RiskRAG reports the same structural pattern: only 14% of model cards mention risks, and 96% copy content from a small set of cards [2504.08952]. This empirical literature thus distinguishes between three evidentiary sources for catalog construction: developer disclosures, researcher taxonomies, and incident logs. The recommendation to require reference to all three sources in impact assessments under the EU AI Act or NIST AI RMF follows directly from that triangulation [2508.16672]. ## 4. From catalog entries to reporting artifacts A risk catalog becomes operational when it structures reporting. The pre-deployment “AI Risk Profiles” proposal organizes disclosures around nine categories: Abuse & Misuse, Compliance, Societal Impact (including Environmental), Explainability & Transparency, Fairness & Bias, Long-Term & Existential Risk, Performance & Robustness, Privacy, and Security [2309.13176]. The template includes a cover and executive summary, system description and context, risk and mitigation analysis for each category, evaluations and benchmarks, and a compliance and certifications checklist [2309.13176]. The paper explicitly frames the profile as a template-based methodology for triaging further risk assessment, informing procurement and deployment, and directing regulatory frameworks [2309.13176]. RiskRAG extends this reporting logic with a Retrieval Augmented Generation workflow. Its five design requirements are: identification of diverse model-specific risks; clear presentation and prioritization; contextualization for real-world use cases; actionable mitigation strategies; and system usability by developers [2504.08952]. It retrieves top-$k=10$ similar model-card sections and top-$k=10$ incident descriptions using cosine similarity over Linq-Embed-Mistral embeddings, $$ \mathrm{sim}(q,d)=\frac{e_q \cdot e_d}{\|e_q\|\,\|e_d\|}, $$ then generates risks, use cases, and mitigations and assigns a priority score $$ \mathrm{priority}(r)=\alpha\,\mathrm{freq}(r)+\beta\,\mathrm{harmFlag}(r), $$ with typical weights $\alpha=1$, $\beta=2$ [2504.08952]. In a preliminary user study with 50 AI developers, the paper reports improvements on AIMQ scale dimensions including R1 coverage from 3.40 to 4.46 and R4 mitigations from 3.08 to 4.08, with 74% favoring RiskRAG [2504.08952]. Internal deployment introduces a more specific reporting problem. “Risk Reporting for Developers’ Internal AI Model Use” focuses on the period in which frontier models are deployed internally for safety testing, evaluation, and iteration before possible release [2604.24966]. The framework is structured around two threat vectors—autonomous AI misbehavior and insider threats—and three risk factors for each: means, motive, and opportunity [2604.24966]. This yields six risk categories, each with scenarios, metrics, and safeguards. For example, autonomous AI misbehavior–means includes “Steganographic exfiltration success rate ($P_{\text{success}}$)” and $$ U_{\rm stego} = \frac{\text{Model’s stego success}}{\text{Public baseline stego success}}, $$ while autonomous AI misbehavior–opportunity includes Mean Time To Detect and $$ R_{\rm merge} = \frac{\#\,\text{human‐reviewed merges}}{\#\,\text{model‐initiated merges}} $$ [2604.24966]. The paper also provides a standardized internal use risk report template with sections for executive summary, model description, threat vectors, risk factor analysis, metrics dashboard, safeguards and residual risk, regulatory mapping, and a confidential annex [2604.24966]. Together, these frameworks show that the catalog is increasingly treated as the data model behind disclosure. A plausible implication is that the future standard artifact is neither the traditional model card nor the pure taxonomy, but a structured report whose fields are populated from catalogs, incidents, benchmarks, and mitigation registries. ## 5. Operationalization, scoring, and audit execution A defining development in recent work is the shift from cataloging risks to turning them into measurable findings. CORTEX presents a five-layer scoring architecture over 29 technical vulnerability groups derived from over 1,200 incidents in the AI Incident Database [2508.19281]. It combines utility-transformed likelihood × impact, contextual and governance modifiers, technical surface modifiers, environmental and residual modifiers, and probabilistic modeling via Bayesian aggregation and Monte Carlo simulation [2508.19281]. The utility function is $$ U(L,I)=1-\exp[-k\cdot(L\cdot I)], $$ and the final composite score is $$ S_{\mathrm{CORTEX}} =\alpha\,U(L,I)+\gamma\,C+\delta\,G+\theta\,T+\lambda\,E+\rho\,R, $$ subject to $$ \alpha+\gamma+\delta+\theta+\lambda+\rho=1. $$ Default weights are $\alpha=0.35$, $\gamma=0.15$, $\delta=0.15$, $\theta=0.10$, $\lambda=0.10$, $\rho=0.15$ [2508.19281]. The resulting score is mapped into five tiers from Minimal to Critical [2508.19281]. Eticas AI Risk Taxonomy v2.0.0 makes the operationalization layer even more explicit. It organizes 76 active subcategories across 10 categories and 20 sub-groups, with public SKOS/JSON-LD distributions and mappings to 18 external frameworks [2607.02201]. Its central claim is that auditing requires bridging from a named risk to “a test run against a real system, a measured value, a calibrated severity, and a defensible grade” [2607.02201]. The worked example is PII leakage on GPT-4-0314, measured at 0%, 51%, and 84% disclosure as adversarial conditioning increases, with the metric $$ R_{\mathrm{disclosure}} = \frac{\sum_{i=1}^{N}\mathbf{1}\bigl[\text{PII}_{\mathrm{injected}}\subseteq \mathrm{output}_i\bigr]}{N}. $$ Disclosure severity bands are piecewise defined: severity 1 at $R=0\%$, severity 2 at $0\%