When an AI decision is challenged, can your system justify it?
In production, an AI decision depends on more than a model. Workflows, configuration, human reviews, and other services all affect the outcome. Each component can work as intended, yet the final decision can still be hard to explain.Foundations for Keeping AI Responsible approaches this as a software design problem. It introduces the RAIMO framework and the AI Passport as ways to make responsibility visible in the design and in the decisions the system makes.Using an AI-assisted lending workflow, the book explores what it takes to know which rules applied, who was responsible, and whether a decision was allowed to go ahead.
Foundations for Keeping AI Responsible
A Systems Approach to Accountable Decisions In production
Table Of Content
Part I — When Responsibility Breaks
Chapter 1: Why Responsibility in AI Is a Systems Problem
Chapter 2: What Changes When Responsibility Is Enforced
Reference: Mapping Responsible AI Principles to the Five Pillars
Reference: Mapping the Five pillars to the EU AI Act
Interlude: What Meaningful Human Oversight Requires
Part II — Designing for Responsibility
Chapter 3: Why Responsible AI needs to be designed
Reference: Mapping the Five Pillars to System Capabilities
Interlude: Different Frameworks, Different Jobs
Reference: What Does a Good Decision Record Look Like?
Interlude: How Requests Flow Through the System
The Next Five Chapters
Chapter 4: Defining Responsibility: Context boundaries
Chapter 5: Binding Responsibility: Runtime Ownership
Interlude: The cost of enforcement
Chapter 6: Preserving Responsibility: Runtime Integrity
Chapter 7: Controlling Responsibility: Execution contraints
Chapter 8: Inspecting Responsibility: Decision Observability
Part III — System Behavior
Chapter 9: Responsibility In A Multi-decision Workflow
Closing note
AI Passport and decision record templates
Reference: Reviewing Responsibility in System Design
Reference: EU AI Act Role Triage for Engineering Teams
Reference: Reviewing EU AI Act Risk in System Design
Reference: Who Owns What at a Decision Point
