A comprehensive Responsible AI knowledge base covering traditional ML, Generative AI, and Agentic AI. Rather than functioning as a reference encyclopedia, it is structured as a control plane: content flows through a consistent chain so any risk can be traced from principle to proof:
PRINCIPLES → RISKS → REQUIREMENTS → CONTROLS → TEST/EVALUATE → EVIDENCE → ASSURANCE
applied across the AI lifecycle, across AI types (Gen AI, Agentic AI), and across stakeholders, jurisdictions, and sectors. See 00-navigation-and-methodology/knowledge-map.md for the full model, including a worked example tracing one risk end-to-end through every section below.
Companion repository: OASIS methodology — primarily Chapter 19 — Security and Responsible AI Engineering and Chapter 20 — Governance, Compliance and Regulatory Engineering.
Fairness, transparency, safety, and accountability are easy to agree on and hard to operationalize. This repository treats AI Ethics, Responsible AI, AI Governance, and AI Assurance as four distinct, connected layers rather than synonyms: ethics asks what ought to be done (the normative layer); Responsible AI asks how those expectations become concrete practice (the operational layer, most of this repository); governance asks how that practice is made consistent, enforceable, and auditable across the organization (the structural layer); assurance asks how you prove it actually worked (the evidence layer). A system can be ethically well-intentioned but operationally irresponsible, have good practices applied inconsistently for lack of governance, or have governance on paper with no assurance it's followed — each layer is necessary and none is sufficient alone. See 01-foundations/responsible-ai-vs-ai-ethics.md.
Every principle in this repository resolves to something testable: Principle → Risk → Requirement → Control → Test/Evaluate → Evidence → Assurance. A weakness anywhere upstream weakens the final assurance conclusion — a control can't be meaningfully assured if the requirement behind it was vague, the control itself was never defined, the test was inadequate, or the evidence was never retained. This chain is what keeps Responsible AI from staying aspirational ("we believe AI should be fair") and turns it into something an engineering team can actually build against and an auditor can actually verify.
The first question is not "which model should we use" but "should this use case exist, and what impact and risk does it create" — which means Responsible AI review begins at opportunity definition, not after a model is already built. That review carries across 02-ai-lifecycle's nine stages (opportunity, requirements, data, model development, evaluation, deployment, monitoring, incident response, retirement) as checkpoints rather than a single gate, and a material change — a new base model, a changed retrieval source, a new tool, expanded permissions, increased autonomy — re-enters the lifecycle rather than shipping as a quiet patch. See 02-ai-lifecycle/opportunity-and-use-case.md and 02-ai-lifecycle/incident-and-remediation.md.
05-responsible-ai-principles organizes Responsible AI around eight pillars — fairness and non-discrimination, transparency and explainability, privacy and data protection, safety and security, accountability and human oversight, robustness and reliability, accessibility and human-centered design, and sustainability — but the same principle creates different risk depending on the system. Traditional ML concentrates risk around training data, classification, and fairness; Generative AI adds hallucination, prompt injection, copyright, and grounding (see 06-generative-ai/genai-risk-landscape.md); Agentic AI adds autonomy, tool access, credentials, planning, and memory (see 07-agentic-ai/agentic-risk-landscape.md). One Responsible AI foundation, adapted controls per technology type — see the eleven-category 01-foundations/risk-taxonomy.md that all three technology sections trace back to.
Governance effort should scale with actual risk, not apply uniformly — a use case is tiered from Tier 0 (prohibited: social scoring, manipulative AI exploiting vulnerabilities) through Tier 1 (high risk: hiring, credit, medical, autonomous agents with consequential authority — full governance board approval and documented evidence) down to Tier 3 (low risk: internal drafting assistance — self-certification). Putting every AI system through the same central committee creates bottlenecks and teaches teams to route around governance entirely. See 03-ai-governance/risk-management.md for the tiering questions and 03-ai-governance/ai-governance-framework.md for the structural components a governance program needs: a cross-functional governance board, a living AI inventory (you cannot govern a system you don't know exists), a policy layer, a risk-tiered review workflow, and monitoring that feeds findings back to the board.
Governance answers what must happen; assurance answers how you know it actually happened and worked. The assurance chain runs Principles → Risks → Requirements → Controls → Testing → Evidence → Assurance, and assurance independence should scale with risk tier — self-assessment for Tier 3, internal independent review for Tier 2, external assessment or certification for Tier 1 and regulatory-mandated conformity — rather than defaulting to maximum or minimum rigor everywhere. Assurance is also continuous, not a one-time launch gate: a system responsible at launch can become problematic through model change, data drift, or new threats, which is why 04-ai-assurance treats monitoring, re-evaluation, and audit as recurring obligations, not a closed checkbox.
Generative AI gets its own control layer rather than inheriting traditional model governance wholesale, covering hallucination and grounding, prompt injection, jailbreaking, copyright and provenance, synthetic content, and fine-tuning governance (see 06-generative-ai). RAG deployments carry their own failure mode worth calling out explicitly: indexing documents with mixed permission levels into one vector store without enforcing document-level access control at query time, so a user sees content from documents they were never authorized to read — a security boundary that has to be a hard filter at retrieval time, not an instruction to the model. This is where Compass's policy layer meets Forge's engineering discipline directly: Compass's RAG-governance.md sets the access-control and groundedness requirements a retrieval system must satisfy, and Forge's grounding and context-quality sections are where those requirements get engineered and measured.
An LLM generating text and an agent taking actions are different risk categories — agents plan, choose tools, hold credentials, modify records, and cause persistent consequences, so agentic governance has to reason about authority and action, not only content (see 07-agentic-ai/agentic-risk-landscape.md). autonomy-and-control.md defines a five-level scale from suggest through fully autonomous, matched to risk tier and action reversibility, backed by approval gates, least-privilege scoped permissions, tested circuit breakers, and rate/scope limits; identity, memory, and multi-agent delegation each get their own governance treatment because more agents does not remove accountability, it increases the importance of explicit authority boundaries (see identity-and-authorization.md, memory-and-state-risk.md, multi-agent-governance.md). Meaningful human oversight is the other half of this picture — blanket approval-on-everything produces rubber-stamping and false assurance, not safety — and this is where Compass's policy requirement hands off to Loom's deeper workflow-engineering method: Compass says oversight must be risk-based and genuinely meaningful, Loom's Workflow Blueprint and progressive-autonomy ladder are how that requirement gets designed and operated.
No single control layer is sufficient by itself: design-time (architecture, data, risk assessment), build-time (testing, evaluation), deployment-time (release gates, approval), runtime (guardrails, authorization, monitoring), human-layer (approval, escalation, contestability), and governance-layer (policy, audit) controls all have to hold together. 08-controls-and-techniques/guardrails-and-controls.md treats a system-prompt instruction like "do not perform unauthorized actions" as useful but not a security control — the runtime layer needs independent input, output, and (for agents) action guardrails that fail closed on high-stakes actions, precisely because a successful jailbreak against the primary model shouldn't automatically defeat the check meant to catch it. 14-ai-security extends this into a dedicated AI security discipline — adversarial ML, model theft, supply-chain risk, tool abuse, and AI-specific incident response — because Responsible AI and AI security are one connected concern, not two departments that happen to both care about the same system.
Buying AI doesn't outsource accountability for its use: 13-implementation-playbooks/vendor-third-party-ai-assessment.md governs vendor, model-provider, data-usage, and audit-rights questions the same way an internally built system would be governed. 10-regulations-and-standards turns legal text into the same chain everything else runs through — regulation → obligation → requirement → control → evidence → assurance — because handing an engineering team a statute and asking them to "comply" is not actionable, while a control they can implement and test is. Risk also varies by sector and affected population, which is why 11-sector-specific-ai layers sector context onto the same core control structure rather than replacing it, and law, standard, framework, guidance, and internal policy are kept explicitly distinguishable throughout so a recommended best practice never gets presented as a legal mandate, or vice versa (see 00-navigation-and-methodology/terminology-and-glossary.md).
Responsible AI can't assume controls prevent every incident: a mature operating model detects, contains, classifies, investigates, corrects, documents, and re-evaluates, and every incident or near-miss should update the risk assessment, controls, evaluations, and training that follow it (see 02-ai-lifecycle/incident-and-remediation.md and 14-ai-security/security-incident-response.md). A practical program runs on a compact artifact set that makes all of this auditable rather than aspirational: AI policy, AI inventory, a risk-tiering method, impact and risk assessments, a control matrix, requirements traceability, evaluation evidence, model/system cards, human-oversight design, security assessments, third-party assessments, assurance records, incident records, monitoring plans, and retirement plans. 13-implementation-playbooks turns each of these into a working checklist rather than a template to fill in once and forget.
A Responsible AI program typically moves from principle-based (commitments as policy statements) through checklist-based, risk-based governance, engineering-integrated controls, to continuous assurance, where evidence is captured automatically and governance adapts to system behavior and regulatory change as it happens rather than on a review cycle. The goal throughout is the same: an organization using this repository should be able to answer what Responsible AI principles apply to a given system, what risks threaten them, what controls address those risks, who owns those controls, how they were tested, what evidence proves they work, and what happens when the system changes or fails — the transformation from principle to proof that gives this repository its control-plane structure.
New to this repository? Read 00-navigation-and-methodology/how-to-use-this-repository.md, which routes you to the right section based on your role and task.
Three ways to navigate, depending on what you already know:
| You know... | Use |
|---|---|
| The section (e.g. "I need 06-generative-ai") | The repository structure below, or browse the folders directly |
| The topic, not the section (e.g. "privacy," "security") | 00-navigation-and-methodology/topic-index.md, which groups files across sections by theme |
| Nothing yet, want to scan everything | INDEX.md — every file in the repository, one flat list |
Every file also carries a breadcrumb (Home › Section › ...) at the top so you always know where you are and can jump back out.
Every file in the repository, grouped by section: the same listing as INDEX.md, kept here so the structure is visible without leaving the README. If this list and INDEX.md ever drift, INDEX.md is the source of truth.
- Framework Map
- How to Use This Repository
- Knowledge Map
- Source and Evidence Policy
- Terminology — Key Distinctions
- Topic Index
- AI Ethics
- Human Rights and AI
- Core Principles
- Responsible AI vs. AI Ethics vs. AI Governance vs. AI Assurance
- Risk Taxonomy
- Stakeholder Roles
- What is Responsible AI
- Stage 3: Data & Data Governance
- Stage 6: Deployment & Release
- Stage 5: Evaluation & Validation
- AI Incident Response
- AI Lifecycle Overview
- Stage 4: Model Development
- Stage 7: Monitoring & Observability
- Stage 1: Opportunity & Use Case
- Stage 2: Requirements & Design
- Stage 9: Retirement & Decommissioning
- AI Assurance (Governance Pointer)
- RACI — AI Governance Activities
- AI Governance Board
- AI Governance Framework
- Governance Models
- Policy Management
- Risk Tiering
- Roles and Responsibilities
- Third-Party AI Governance
- AI Impact Assessment
- AI Risk Assessment
- AI Assurance — Overview
- Assurance Reporting
- AI Audit
- Conformity Assessment
- Documentation Artifacts
- Independent Assessment
- Model Validation
- Red-Teaming
- Accountability and Human Oversight
- Fairness and Bias
- Privacy and Data Protection
- Robustness and Reliability
- Safety and Security
- Sustainability
- Transparency and Explainability
- RAG-Specific Considerations
- Content Provenance and Authenticity
- Copyright and IP Considerations
- Data Leakage (Generative AI)
- Fine-Tuning Governance
- Generative AI Evaluation
- Generative AI — Specific Risks
- Hallucination and Grounding
- Jailbreaking
- Prompt and Output Safety
- Prompt Injection
- Synthetic Content
- Agent Incident Response
- Agent Observability
- Agentic Evaluation
- Agentic AI — Risk Landscape
- Autonomy and Control
- Human-Agent Interaction
- Identity and Authorization for Agents
- Memory and State Risk
- Multi-Agent Governance
- Planning and Reasoning Risk
- Tool Use and Permissions
- Controls and Techniques
- Guardrails and Runtime Controls
- evaluation-and-benchmarking/
- explainability/
- fairness-testing/
- monitoring-and-observability/
- privacy-techniques/
- robustness-testing/
- ISO/IEC 23894
- ISO/IEC 42001
- MITRE ATLAS
- NIST AI Risk Management Framework (AI RMF)
- OECD AI Principles
- OWASP Top 10 for LLM Applications
- UNESCO Recommendation on the Ethics of AI
- Commercial / Vendor Platforms
- Evaluation Frameworks
- Framework Comparison
- Governance Platforms
- Observability Tools
- Open-Source Tools
- Security Tools
- Tool Selection Matrix
- Sector-Specific AI
- Critical Infrastructure
- Education
- Financial Services
- Healthcare
- Human Resources
- Insurance
- Manufacturing
- Public Sector
- Retail
- Case Study Template
- agentic-failures/
- bias-and-discrimination/
- failures/
- good-practices/
- hallucination-and-reliability/
- privacy-incidents/
- regulatory-actions/
- security-incidents/
- Playbook: Agentic AI Deployment Checklist
- Playbook: Conducting an AI Risk Assessment
- Playbook: Gen AI App Launch Checklist
- Playbook: Model / System Card Template
- Playbook: Vendor / Third-Party AI Assessment
- AI Security
- AI Threat Model
- Securing Agentic AI
- Securing Generative AI
- Securing Traditional ML
- AI Security Incident Response
- Security Metrics and Reporting
- Security Testing Program
- AI Supply Chain Security
Not sure which section has what you need? topic-index.md groups the same files by theme instead of by section.
- Ethics ≠ Responsible AI ≠ Governance ≠ Assurance: four different layers, not synonyms. See 01-foundations/responsible-ai-vs-ai-ethics.md.
- Law ≠ Standard ≠ Framework ≠ Guidance: different legal weight, kept in separate sections (10 vs. 09). See 00-navigation-and-methodology/terminology-and-glossary.md.
- Lifecycle ≠ Governance: lifecycle is when; governance is who decides. Kept as separate sections (02 vs. 03).
Start with 01-foundations for shared vocabulary and principles. Building with Gen AI or Agentic AI? Read the relevant technology section (06 or 07) alongside 02-ai-lifecycle for checkpoints and 13-implementation-playbooks as your working checklist. Reviewing or approving a use case? Go to 03-ai-governance for process and 04-ai-assurance for what evidence to demand. In legal/compliance? 10-regulations-and-standards is binding law; 09-tools-and-frameworks is voluntary, so don't conflate them.
This is a living document. See CONTRIBUTING.md for how to propose updates as regulations, tools, and practices evolve, and 00-navigation-and-methodology/source-and-evidence-policy.md for how claims should be sourced.
Compass is the OASIS companion for Chapter 19 (Security and Responsible AI Engineering) and Chapter 20 (Governance, Compliance and Regulatory Engineering). See the Companion Repository Index for how the other Part III chapters map to their own companions.
-
Forge (Chapter 15, Data and Knowledge Engineering): Compass's 06-generative-ai/RAG-governance.md sets the access-control and groundedness requirements a retrieval system must meet; Forge's grounding and context-quality sections are where those requirements get engineered and measured. Compass owns the policy requirement, Forge owns the engineering discipline behind it.
-
Loom (Chapter 16, Human–AI Workflow and Experience Engineering): Compass's 07-agentic-ai/autonomy-and-control.md requires that oversight be risk-based and genuinely meaningful, not blanket approval; Loom's Workflow Blueprint and progressive-autonomy ladder are the deeper method for designing and operating that requirement.
-
Verity (Chapter 18, Evaluation and Reliability): Compass's 14-ai-security content defines the threat categories and control expectations, and Verity's adversarial-and-red-team-evaluation.md is where those controls get measured. Verity owns the evaluation methodology; Compass owns the policy and control catalog behind it.
-
Helm (Chapters 17/18/19/21/26, Deployment and AgentOps): Helm's agentic-threat-model.md covers runtime containment for a deployed agent, and Compass's AI-security section is the upstream policy layer that threat model has to satisfy.
-
Fulcrum, the economics/FinOps companion (Chapter 22): a use case's compliance obligations here (10-regulations-and-standards) often carry cost implications Fulcrum's unit-economics tracking should account for.
-
Nexus, the opportunity catalog: a candidate use case's risk tier is set against this repository's principles and regulations sections before it moves into engineering.
This repository provides general guidance and educational content. It is not legal advice. Regulatory sections (10) summarize publicly available law as of their last review date and are in an area that changes quickly, so always confirm current requirements with legal/compliance counsel before relying on them for a specific decision.
Licensed under CC BY-SA 4.0. Reuse and adaptation are welcome with credit to KnowledgeTrails-OASIS, a link to the license, an indication of changes, and release of adaptations under the same license.
Shripadraj Mujumdar is an Agentic AI & Automation Strategist, Advisor, and Responsible AI Expert with 28+ years of experience in enterprise architecture and AI-driven transformation, including deep hands-on work in Agentic AI, Generative AI, and enterprise data and knowledge platforms. His practice spans designing multi-agent systems, knowledge-graph and RAG architectures, accelerated delivery capabilities, and Responsible AI governance frameworks aligned to global regulatory standards. This methodology ecosystem distills that practitioner experience (architecture, delivery, evaluation, governance, and economics) into a single, reusable body of work.
Ankit Mirajkar is a Data & AI Architect and technology consultant specializing in modern data platforms, enterprise data architecture, and Agentic AI. His expertise spans scalable data engineering, AI-ready data platforms, Generative AI, and cloud technologies, with a strong focus on turning complex data challenges into practical, production-ready solutions. He also works at the intersection of architecture, technology strategy, and innovation to help organizations build intelligent, scalable data ecosystems.