RACI Responsibility Assignment

A template, not policy

The IMDA paper contains no RACI. This whole matrix is an interpretation — a starting-point template to accelerate your own roles-&-responsibilities definition, not a finished allocation.

Recalibrate every cell to your real org structure, your agents’ autonomy tier and risk materiality, and your build-vs-buy posture before use.

The one principle encoded throughout is paper-stated: “As deployers, organisations and humans remain accountable for the decisions and actions of agents.” §2.2.1, p.25

So every row has exactly one A (Accountable), and it always sits with the Deployer’s Key decision makers — accountability is not transferred upstream, even when an external party builds or runs the agent. interpretation

How to read the markers:

• Unmarked cells track the paper’s explicit team-responsibility or process text (the §2.2.1 team duties; the §§2.1–2.4 processes).
• Dotted (inferred) cells are where the paper names the activity but not that role’s RACI letter — mostly the external value-chain columns.
• The matrix as a whole is interpretation, since the paper has no RACI.

The four RACI roles

RACI is a general responsibility assignment matrix from project management — a tool separate from the IMDA framework, which itself prescribes no RACI. PMI’s PMBOK Guide defines a RACI chart as “a common type of responsibility assignment matrix that uses responsible, accountable, consult, and inform statuses to define the involvement of stakeholders in project activities.” Each activity’s involvement splits into four roles:

• R Responsible — the doers. Execute the work. A row may have several R’s, kept to a manageable number.
• A Accountable — the owner. Owns the outcome and signs off; delegates the work and can approve or reject it. Exactly one A per row — the golden rule this scaffold enforces.
• C Consulted — the advisor. Subject-matter experts whose input is sought before the work is finalised. Two-way communication; they shape the work but don’t do it.
• I Informed — the recipient. Kept up to date on progress and decisions. One-way communication; no contribution to the work itself.

On RACI itself (not IMDA): the canonical reference is PMI, A Guide to the Project Management Body of Knowledge (PMBOK Guide), which defines the RACI chart as a responsibility assignment matrix. See also the overview at Responsibility assignment matrix (Wikipedia).

The matrix

The columns use short codes for two groups, per §2.2.1 — the deployer’s four internal teams, and the value chain’s provider roles (external or in-house):

Those roles aren’t a flat list — they sit in a chain, and any of them can be procured externally or built in-house. Here’s where each matrix code maps onto the chain (from Topic 02):

VENDOR is not shown — an external agentic-AI provider isn’t a box in this chain; it’s a buy / third-party grouping that resolves to a system, platform or tooling provider. interpretation

Any provider role the organisation builds itself is played in-house: IMDA notes organisations “may play multiple overlapping roles across this value chain” — its example being an org that builds and deploys its own agents, which is “both the system provider and the deployer.” §2.2.1, p.25 So a provider role is external when procured, internal when built in-house — where it collapses into your own teams (e.g. SYS → PROD). interpretation

All dimensions1234

Show provider roles (external value-chain roles — mostly inferred)

Governance activity	KDM	PROD	CYBER	USER
1. Assess & bound the risks upfront §2.1
Define permitted use cases & data-access limits	A/R	C	C	I
Use-case risk assessment (incl. system complexity & third-party)	A	R	C	I
Threat modelling / taint tracing	A	C	R	I
Define agent limits — tools, autonomy, least-privilege	A	R	C	I
Define agent identity & authorisation	A	R	C	I
Evaluate & accept residual risk	A/R	C	C	I
2. Make humans meaningfully accountable §2.2
Allocate responsibilities across the value chain — contracts / T&Cs	A/R	C	C	I
Define significant approval checkpoints & action boundaries	A	R	C	C
Perform runtime human approvals	I	C	I	R
Audit oversight effectiveness (override rate, response time)	A	R	C	C/I
Develop internal capabilities for adaptive governance	A	R	R	R
3. Implement technical controls & processes §2.3
Design & implement technical controls (prefer structural over prompt-layer)	A	R	R	I
Pre-deployment testing (accuracy, policy, tool use, multi-agent)	A	R	C/R	C
Gradual / phased rollout	A	R	C	I
Continuous monitoring & incident response (deny-by-default, fallback)	A	R	R	I
Change management & version control	A	R	C	I
4. Enable end-user responsibility §2.4
End-user transparency (UI disclosure, range of actions, escalation)	A	R	I	C
End-user education & training	A	R	C	C/R
Maintain tradecraft / business continuity	A	C	I	R

A — Accountable (one per row)R — ResponsibleC — ConsultedI — Informeddotted = inferred

Select a cell for its meaning and basis. Every row has exactly one A, always the Deployer’s Key decision makers — the framework’s anchor that accountability is not transferred upstream.

The four internal teams (KDM, PROD, CYBER, USER) are grounded in §2.2.1’s illustrative team responsibilities. The provider roles (MDEV, PLAT, SYS, TOOL, VENDOR) carry mostly inferred letters — the paper addresses them only through the generic “outside the organisation” duties; built in-house, a role collapses into your own teams. Toggle them on for the build-vs-buy view.

How to calibrate

This is a template, not an answer. Before use:

1. Map the columns to your real org. §2.2.1 calls its four-team split “an illustration” and notes “each organisation is structured differently.” Rename or merge KDM / PROD / CYBER / USER to your actual functions — and add what’s missing (a dedicated AI Governance Office, Legal/Compliance, or DPO). The PwC breakdown (Use-case owner / Technology Risk Management / AI Factory / End users) is a ready alternative column set. §2.2.1, pp.26–28

2. Calibrate to the agent’s autonomy tier and risk materiality. The paper’s case studies are explicitly tiered — copy the pattern that matches your risk appetite:

   • Dayos — three tiers scored on severity × reversibility × feasibility of human oversight.
   • MSD — five levels of agency with a runtime policy-enforcement gateway before higher autonomy.
   • OCBC — bounding agent autonomy in source-of-wealth analysis.

   As autonomy and materiality rise, pull more cells toward human approval (USER = R) and add A-level sign-off gates. §2.1

3. Set the build-vs-buy posture — it drives the external columns.

   • Build in-house: the company “would play both the role of the system provider and the deployer” — so SYS collapses into PROD. §2.2.1, p.25
   • Buy / third-party: populate VENDOR and contractually pin obligations (security, performance, data protection; scoped API keys, per-agent identity tokens, tool-call logging). Where features are lacking, scope down or bring in-house.
   • Whatever the posture, the A never leaves the deployer.

4. Re-run on every material change. §2.3.3 robust change management warns that “small modifications can cascade into larger impact.” A material change re-triggers this matrix — the four dimensions are an iterative loop, not a one-pass checklist. §2.3.3, p.45

Open decisions — where the paper is silent

The framework leaves these to the organisation. Decide them explicitly rather than inheriting this scaffold’s defaults: interpretation

• A/R split for testing & controls — the paper gives PROD testing and CYBER secure-by-design/red-team, but not who is A when they overlap. Default: single A = KDM; PROD = R for functional/agentic testing, CYBER = R for security/red-team; co-sign before go-live.
• Which function runs oversight-effectiveness analytics (override rate, response time, outlier-human detection, §2.2.2) — the owner is unspecified. Default: R to PROD for instrumentation, C to CYBER; consider a standing AI-governance / internal-audit owner.
• External-vendor accountability mechanism — §2.2.1 mandates contractual clarity but prescribes no liability model. Default: VENDOR is C/R within contract terms only; A stays with KDM; where gaps exceed risk tolerance, don’t deploy.
• RACI letters for the provider roles — MDEV / PLAT / SYS / TOOL are named in the value chain but given no explicit RACI; all are inferred, and the SYS letters assume a third-party build (in-house collapses SYS into PROD).
• Not even in the paper — the VENDOR column. IMDA’s value-chain figure has no “external agentic-AI provider” box; VENDOR is a convenience grouping for buy / third-party postures, so its whole column is interpretation, resolving in the formal value chain to a system / platform / tooling provider.
• Roles beyond the illustrative four (Legal, Compliance, DPO, Internal Audit, AI Governance Office) — in a regulated FI context a Compliance column will likely take C on most rows and possibly A on use-case approval.

---

Next — Topic 04: a financial-institution calibration. This scaffold uses the framework’s four illustrative teams. Topic 04 calibrates the same matrix to a real FI — splitting those teams across three lines of defence and distributing the single A to whoever has the most control.