When an AI decision is challenged, can your system justify it?


Learn how to design AI systems that make decisions you can observe, explain, and stand behind in production.This book takes a systems view of responsibility, focusing on how decisions are shaped at runtime, not just how models are built or used.It brings together control, context, and ownership into a practical way of thinking about AI in real systems.

Coming soon..
Foundations for keeping
ai responsible

A Systems View of Responsibility in Production AI

Foundations for Keeping AI Responsible

A Systems Approach to Accountable Decisions

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 actually means

  • Chapter 3: Why Responsible AI needs to be designed

  • Interlude: How requests flow through the system

Part II — Designing for Responsibility

  • Chapter 4: Defining Responsibility: Context and Risk

  • Chapter 5: Binding Responsibility: Runtime Ownership

  • Interlude: The cost of enforcement

  • Chapter 6: Preserving Responsibility: Version Integrity

  • Chapter 7: Controlling Responsibility: Human-in-the-Loop

  • Chapter 8: Inspecting Responsibility: Decision Observability

Part III — System Behaviour

Checklist: Determine Your Role Under the EU AI Act


Before you look at obligations, first understand what role your system is actually playing.
These roles are not about ownership or job titles. They come from where you have control in the system.
If you can change how the system is built, what it outputs, or how it is used in a real workflow, you are defining its role.
A system can shift roles when:
- its purpose changes
- its behaviour is modified
- its usage moves into a different workflow


1. Provider
You are likely acting as a Provider if you bring an AI system into existence and put it into use under your name.
☐ Do you develop an AI system and place it on the market?☐ Do you put an AI system into service under your own name or trademark (including internal use)?☐ Do you commission a third party to build an AI system that you then use or sell under your name?☐ Do you embed AI into a product or service that you offer under your brand?☐ Do you use a general-purpose AI model (for example, an LLM) to create a specific application for a defined use case?☐ Do you substantially modify an existing AI system (beyond configuration or normal operation)?☐ Do you change the intended purpose of a system, especially moving it into a high-risk use?Important distinction
- Using an open-source or third-party model does not make you a Deployer by default.
- If you are the one putting the resulting system into service under your name for a specific purpose, you are acting as the Provider of that system.
GPAI note
- If you are building the general-purpose model itself, separate obligations apply under Article 53.
- If you are building an application on top of such a model, you are assessed as a Provider of an AI system.
If yes to any of these, you are operating as a Provider.2. Deployer
You are likely acting as a Deployer if you use the system under your authority.
☐ Are you using an AI system in a professional or organisational context?
☐ Is the system used as part of a business process, service, or operational workflow?☐ Do you control how the system is applied to real-world decisions or outputs?☐ Are you monitoring the system through logs, performance signals, or operational drift?If one or more apply, you are operating as a Deployer.3. Importer
You are likely acting as an Importer if you bring a non-EU system into the EU market.
☐ Are you established in the EU?☐ Are you placing an AI system on the EU market that is produced by a non-EU provider?☐ Are you the first entity making that system available in the EU?If yes, you are operating as an Importer.4. Distributor
You are likely acting as a Distributor if you make the system available without changing it.
☐ Are you part of the supply chain, but not the original provider or importer?☐ Are you making the system available (resale, licensing, distribution)?☐ Are you not modifying its behaviour, purpose, or design?If yes, you are operating as a Distributor.5. Authorised Representative
You are likely acting as an Authorised Representative if you act on behalf of a non-EU provider.
☐ Are you established in the EU?☐ Have you been formally appointed by a non-EU provider?☐ Do you act on their behalf for regulatory obligations and interactions?If yes, you are operating as an Authorised Representative.6. Scope Check
☐ Is the AI system placed on the EU market or put into service in the EU?
☐ Is the output of the system used in the EU?If yes, the Act can still apply, even if you are not based in the EU.Critical shift
A Deployer, Importer, or Distributor becomes the Provider if they:
- place the system under their own name or trademark
- substantially modify it
- change its intended purpose into a high-risk use
This is a legal shift, not a conceptual one. Full provider obligations apply.Substantial modification note
- Routine configuration, parameter tuning, or updates defined by the original provider usually do not count as substantial modification.
- Changes that alter system behaviour, performance characteristics, or intended purpose can trigger this shift.
Identifying the role is step one.
The risk category (prohibited, high-risk, limited, minimal) determines what obligations apply after that.


Regulation (EU) 2024/1689 (n.d.). Article 25. EU Artificial Intelligence Act. https://artificialintelligenceact.eu/article/25/