The Library.

The library in numbers

• 48named risks, severity-scored
• 22mapped controls
• 14frameworks and regulations
• 4downloadable tools
• 120glossary terms

• Risks Individually assessed AI risks, scored by severity and mapped to controls and framework clauses.
• Controls Practical AI controls, each mapped back to the risks it addresses by effectiveness.
• Frameworks The regulations and standards the library is mapped to, clause by clause.
• Tools Checklists, templates and working documents, free to download.
• Glossary AI governance, compliance and security terminology, cross-referenced to the library.
• Resources An annotated library of primary sources, plus platform governance briefings.

48 risks across nine categories, anchored to 14 standards and regulations. The pillar tags are what each pillar page's "Risks and controls in this domain" section queries live.

Model & Application SecuritySecurity

Attacks against the model or the application wrapped around it: prompt injection, insecure output handling, excessive agency.

Adversarial ML & Model IntegritySecurity · Engineering

Attacks against the model artefact itself, and the operational discipline that catches them: evasion, extraction, backdoors, and the testing coverage that finds them before an adversary does.

Data Protection & PrivacyCompliance

Lawful basis, minimisation, and the automated-decision safeguards that keep an AI system inside UK GDPR, not just inside what the model technically allows.

Fairness, Bias & ImpactGovernance · Compliance

Disparate outcomes across groups, and the impact-assessment discipline that catches them before deployment, not after a complaint.

Governance & AccountabilityGovernance

Who owns an AI system, who signs off on it, and whether that accountability is documented or assumed.

Third-Party & Supply ChainGovernance

Vendor and model provenance risk — carries the third-party lens (see below) and is the category most closely tied to SS2/21.

Operational ResilienceEngineering

Whether AI is mapped into your important-business-service inventory, has an impact tolerance, and has been tested to fail — the SS1/21 lens applied to AI specifically.

Transparency & ExplainabilityGovernance · Compliance

Whether an AI system’s outputs and decisions can actually be explained to the person affected by them, not just logged.

Prohibited & High-Risk PracticesCompliance

The EU AI Act's Article 5 bans — social scoring, real-time public biometric ID, manipulative systems. Deliberately thin on mapped controls: the correct response to a legal prohibition is not building it, not a technical control.

Consistent across every risk, whatever its category: severity is about harm potential, not about how technically interesting the risk is.

Critical

Realistic potential for material regulatory, financial, or safety harm if unmitigated — the risks that would stop a launch.

High

Significant harm potential, but bounded — usually mitigable with a defined, achievable control set rather than a redesign.

Medium

Real but contained harm potential, often already partially addressed by controls built for other purposes.

Low

Limited harm potential on its own — worth tracking and mapping, rarely worth a dedicated control in isolation.

Three separate mapping relationships, not one flat list of tags.

Risk → control, by effectiveness

Every risk–control mapping in the library is tagged primary, supporting, or compensating — not a flat "this control addresses this risk" list. A primary control is the main line of defence; a supporting control reduces likelihood or impact without fully addressing the risk; a compensating control is a fallback where the primary control isn’t feasible.

Risk → framework clause

Where a risk is cited by a specific regulatory or standards clause — an EU AI Act article, an ISO/IEC 42001 Annex A control, an SS1/21 or SS2/21 expectation — that citation is a direct reference, not an inferred theme match.

Risk → domain, resource, and lens

The v4 taxonomy adds facets on top of the original category: which of the four pillars a risk belongs to (a risk can span more than one), which industry it’s specific to, and whether it carries the third-party lens — see the taxonomy spec for the full mechanism.

The 14 regulations and standards the library is mapped to. Where a framework has its own page, the mapping is read the other way round: clause by clause, with the risks each clause maps to and the controls that address them.

How many risk categories does the Axiom Verity Risk Library use?

Nine: Model & Application Security, Adversarial ML & Model Integrity, Data Protection & Privacy, Fairness/Bias & Impact, Governance & Accountability, Third-Party & Supply Chain, Operational Resilience, Transparency & Explainability, and Prohibited & High-Risk Practices.

What severity levels does the Risk Library use?

Four: Critical (realistic potential for material regulatory, financial, or safety harm), High (significant but bounded harm potential), Medium (real but contained harm, often already partially addressed), and Low (limited harm potential on its own).

Why do the EU AI Act Article 5 prohibited-practice risks have so few mapped controls?

Deliberately: the correct response to a legal prohibition is not building the system, not a technical control that manages the risk of building it anyway.

What does it mean for a control to be "primary," "supporting," or "compensating"?

A primary control is the main line of defence against a risk; a supporting control reduces its likelihood or impact without fully addressing it; a compensating control is a fallback used where the primary control isn't feasible.

Is risk a separate pillar alongside Governance, Compliance, Security, and Engineering?

No — it's the cross-cutting spine that runs through all four. A prompt-injection risk, for instance, is genuinely both a Security and an Engineering concern; treating risk as a fifth pillar would force an artificial split rather than reflecting how risk actually spans the other four.