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):

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

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.

Onboarding scenarios — worked tables

The matrix above is the general scaffold. Onboarding a specific model, tool or system is its own governed event with a concrete lifecycle: intake → due diligence → security & data → build & guardrails → testing & red-teaming → approval → deploy & monitor. The three tables below work that lifecycle for three common cases, using the same four illustrative teams. interpretation

Across all three, the single A stays inside the deployer: KDM owns the governance, risk, legal and approval rows; CYBER owns the security, supply-chain and red-team rows; PROD owns the build, configuration, testing and monitoring rows; USER owns use. The provider roles (MDEV, PLAT, SYS, TOOL, VENDOR) only ever consult or are responsible within their remit — never accountable. Filter by phase; toggle providers on to see who supplies what.

Scenario A · external proprietary model

The model is a closed product (Claude / Claude Code, OpenAI / Codex, Gemini): you can’t inspect, retrain or independently validate it. So governance shifts from validate the model to constrain the deployment and bind the vendor — assurance is contractual (no-training-on-data, SLAs, liability, exit), configurational (tenancy, data residency, retention/DLP, guardrails) and monitoring-led (the vendor can silently change the model version, so version-drift monitoring is a first-class control). Red-teaming is black-box; fine-tuning only exists where the vendor offers it.

Scenario B · open-source / self-hosted model

With an open-weight model the organisation self-hosts (Llama, Mistral, Qwen, DeepSeek) there is no vendor SaaS or contract — it becomes the developer-deployer and owns almost the whole stack. That adds open-source licence clearance, model provenance & weights integrity (official source, checksums/signing, malware-/backdoor-scanning, an AI-SBOM), self-hosting infrastructure hardening, the full in-house model-risk and guardrail build (no vendor guardrails ship with the weights), and fine-tuning / adapter governance. The one risk that eases is data residency — prompts, embeddings and tuning data never leave the trust boundary. With no vendor, there is no one else to point to.

Scenario C · integrated agentic solution + tools

An integrated agentic solution bundles a model plus tools/connectors from several service providers (an agentic platform with MCP servers / APIs) — a layered, multi-provider chain inside one running agent. Due diligence becomes per-provider and per-tool; the dominant new risks sit at the seams — tool poisoning, identity/privilege abuse, insecure inter-agent communication, and cascading multi-agent failure. Control depends on tool/MCP allow-listing, least-privilege + just-in-time identities, sandboxing/containment (restrict third-party agents to their ecosystem), and chain-wide monitoring — with the deployer accountable for the whole chain.

Frameworks referenced (not IMDA). The onboarding activities draw on the NIST AI Risk Management Framework and its Generative AI Profile, ISO/IEC 42001, the OWASP Top 10 for LLM Applications (2025) and OWASP Agentic threats & mitigations, with model-risk discipline from SR 11-7. The financial-institution allocation of these same tables is in Topic 04.

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.