Really Simple AI Risk Framework
Really Simple AI Risk Framework is your go to tool to identify and mitigate AI/ML-specific risks. The AI Risk Register of this framework is carefully curated based on various sources and internal incident learnings of our clients.
AI Lifecycle
Every AI initiative moves through lifecycle stages such as Development, Deployment, Use, and Monitoring. Not every organization develops AI models, but all AI initiatives involve Deployment and Use. Gaps in Monitoring and shadow Deployments are common sources of risk.
- Development: You design or materially change AI behavior (for example, selecting data, training, tuning, evaluation).
- Deployment: You do not build the model, but you integrate, configure, and release AI components into production workflows.
- Use: You consume a deployed AI solution in business operations and make decisions or actions based on its outputs (via chat, CLI, or another interface).
- Monitoring: You track risk, quality, and incidents over time; this is continuous and should run across all other stages.
How to use this framework?
- Check which lifecycle stages are applicable for your initiative. If unclear, run a discovery session with your technical team.
- For the stage(s) your initiative is currently in, consult the register.csv. Stage tags in the risk register indicate where each risk is typically introduced or first exploitable. Several risks span more than one stage and are tagged accordingly.
- For every risk that applies to your system, record: likelihood, impact, an owner, and a mitigation or control. Reference risks by their AIR## ID in your project’s risk log, security review, or audit so findings stay traceable back to this register. “AIR” stands for AI Risk.
Re-check the register at each stage transition (e.g., moving from Development to Deployment) — a risk that was out of scope earlier may now apply.
The AI Risk Register (AIRs)
Treat risk register as a living list: if you identify a risk not represented in register.csv, propose it by creating an issue in this repository, your contribution may help other teams.
Filter by typical lifecycle stage:
| ID | Risk | Lifecycle Stage(s) | Description |
|---|---|---|---|
| AIR01 | Shadow AI Deployments | Deployment Use | Undocumented/unapproved AI tool deployments by internal teams. |
| AIR02 | Supply Chain Vulnerabilities | Development Deployment | Vulnerability risks from dependency libraries, or third-party tools (e.g., a compromised open-source package or a poisoned pre-trained model pulled from a public model hub). |
| AIR03 | Data Leakage | Development Use | Sensitive data exposed through third-party tools & API calls. |
| AIR04 | Cross-Border Data Transfer | Deployment Use | Data processed across risky jurisdictions. |
| AIR05 | No Validation / Improper Output | Use | Unsafe or misleading model outputs executed without proper validation. |
| AIR06 | Insecure Deployment Pipelines | Deployment | Weaknesses in CI/CD or model deployment processes. |
| AIR07 | Critical 3rd-party Dependency | Development Deployment | Vulnerabilities related to critical dependencies on third-party libraries or frameworks (e.g., an unpatched CVE in a core ML framework, or an outage/breaking change at a foundation-model API provider). |
| AIR08 | Excessive Agency / Over-Reliance on AI | Use | Decisions made without sufficient oversight or validation. |
| AIR09 | Model Poisoning | Development | Malicious data injected during training to manipulate model behavior. |
| AIR10 | Model Inversion / Membership Inference | Use | Attackers reconstruct or identify training data from model outputs. |
| AIR11 | Poor Monitoring | Monitoring | No mechanisms to track model performance, bias, usage, or anomalies or absence of regular Audit. |
| AIR12 | Feedback Loop Contamination | Use Monitoring | Feedback loops when model outputs influence future inputs. |
| AIR13 | Alert Fatigue | Monitoring | Alert systems can fail to notify or can overwhelm operators. |
| AIR14 | Insider Threats | Development Deployment Use | Malicious or negligent actions by employees or contractors. |
| AIR15 | Adversarial Attacks | Use | A type of attack in which an attacker deliberately alters input data to mislead the model (e.g., prompt injection to bypass safety filters, or imperceptible image perturbations that fool a vision classifier). |
| AIR16 | Model Drift | Use Monitoring | Performance degradation due to changing data distributions. |
| AIR17 | Implicit Bias in Outputs | Development Use | Skewed results due to biased training data or model design (implicit only). |
| AIR18 | Critical Unintended Consequences | Development Deployment Use | Harmful side-effects the model produces without explicit intent or anticipation by its designers (e.g., blackmail-like manipulation to avoid shutdown, or circumvention of its own safety safeguards during testing, poor pipeline design without proper validation for the outcomes). |
| AIR19 | Censorship/Guardrail interference | Use | Model safety mechanisms interfere with valid outputs. |
| AIR20 | Deployment misfit | Deployment Use | The data distribution differs from training or model is not suitable for the deployment context. |
| AIR21 | Lack of Explainability | Development Use | Inability to interpret or justify model decisions. |
| AIR22 | No Accountability | Development Deployment Monitoring | Unclear who is responsible for the failures. |
| AIR23 | Unclear Model Ownership/IP | Development | In case of custom development and deployment Legal risks may arise. |
| AIR24 | Output Integrity Tampering | Use | Model outputs are intercepted or altered in transit/storage so a downstream system acts on a manipulated result while believing it’s genuine (e.g., a man-in-the-middle attack altering a fraud-score before it reaches a decision engine). |
| AIR25 | System Prompt / Instruction Leakage | Use | Confidential system prompts, internal instructions, or embedded credentials are extracted by end users via crafted queries, exposing business logic or guardrail design. |
| AIR26 | RAG / Vector Store Vulnerabilities | Development Use | Weaknesses in embedding generation, storage, or retrieval (e.g., cross-tenant access to a shared vector database, embedding inversion revealing source documents, or poisoned documents injected into a retrieval corpus). |
| AIR27 | Unbounded Consumption | Use Monitoring | Uncontrolled or excessive inference requests degrade availability or generate runaway compute costs (e.g., oversized prompts or high-volume requests exhausting GPU capacity or inflating API billing), also known as Denial of Wallet/Service. |
No risks match the selected stage — try a different filter.
How to use?
Start
Check which lifecycle stages are applicable for your initiative. If unclear, run a discovery session with your technical team.
For the stage(s) your initiative is currently in, consult
register.csv. Stage tags indicate where each risk is typically introduced or first exploitable; several risks span more than one stage.For every risk that applies to your system, record: likelihood, impact, an owner, and a mitigation or control. Reference risks by their AIR## ID so findings stay traceable.
Missing risk in register.csv?
- YesCreate a repository issue with the missing risk.
- NoContinue.
Any new stage transition or newly in-scope risk?
- Yes↶ Back to step 1.
- NoEnd.
End