EU AI Act RACI Template: Who Owns Each High-Risk Obligation Across Provider and Deployer Teams

Start with the legal capacity, not the org chart

Regulation (EU) 2024/1689 sets out obligations for providers and deployers of high-risk AI systems, along with other parties, in a dedicated section. A RACI for it is only as reliable as the role classification underneath it. Recital 79 states that a specific natural or legal person, the provider, should take responsibility for placing a high-risk system on the market or putting it into service, regardless of whether that person designed or developed it. The provider role therefore follows who answers for placing the system on the market, not who wrote the code.

In practice, keep a system register with a named provider entity for every high-risk system, the capacity your enterprise holds (provider, deployer, or both), and the basis for classification as high-risk. One route to that classification is use as a safety component of a product, or as a product itself, covered by the Union harmonisation legislation listed in Annex I. Record which route applies, because it determines which obligations you are mapping.

Where one enterprise is both provider and deployer, for example a business that builds a system in one division and operates it in another, give each capacity its own rows. A single combined row is where duties go unowned or get duplicated. The same person may be responsible in both rows, but the accountability and the evidence should be recorded separately.

Provider RACI: obligations and evidence outputs

The rows below follow the provider duties in the brief for this guide. Each lists responsible (R), accountable (A), consulted (C) and informed (I) roles, plus the evidence artifact the row should produce. Treat the role assignments as a starting template. Adjust them to your structure, but keep one accountable role per row, and cite the exact article from the current consolidated text in your own version.

• Risk management and data governance: R: Engineering and data teams. A: System product owner. C: Compliance, Security. I: Legal. Evidence: risk register with review history, data governance records.
• Technical documentation: R: Engineering. A: System product owner. C: Legal, Compliance. I: Business owner. Evidence: documentation file versioned against each release.
• Record-keeping and transparency to deployers: R: Engineering for logging capability, Product for instructions. A: System product owner. C: Security, Legal. I: Compliance. Evidence: log specification, instructions issued to deployers.
• Human oversight design: R: Engineering and Product. A: System product owner. C: Compliance, Business owner. I: Deployer customers. Evidence: oversight design specification, documented intervention and override mechanisms.
• Accuracy and robustness: R: Engineering and Security. A: Head of Engineering. C: Compliance. I: Product. Evidence: test results, declared performance levels, security assessment.
• Conformity assessment: R: Compliance. A: Chief compliance officer. C: Legal, Engineering. I: Executive sponsor. Evidence: assessment record and the supporting declaration file.

Deployer RACI: obligations and evidence outputs

Deployer rows sit mostly with the business unit that operates the system and the security function that monitors it. Compliance and legal act as consulted or accountable where external notification is involved. One step to include is the deployer notification of assessment results to the market surveillance authority, using the prescribed template, once the relevant assessment has been performed.

• Use per instructions: R: Business owner. A: Head of business unit. C: Product, Compliance. I: Security. Evidence: documented intended use, approved use register.
• Human oversight assignment: R: Business owner names the reviewers. A: Head of business unit. C: Compliance, Legal. I: Security. Evidence: assignment records, reviewer training records, escalation procedure.
• Input data relevance: R: Data owner and Engineering. A: Business owner. C: Compliance. I: Legal. Evidence: input data review mapped to the system's intended purpose.
• Monitoring and incident reporting: R: Security and operations. A: CISO. C: Legal, Compliance. I: Business owner, provider. Evidence: monitoring reports, incident register, notification records.
• Log retention: R: Security and IT. A: CISO. C: Legal, Compliance. I: Business owner. Evidence: retention schedule, storage configuration, access records.
• Informing affected persons and authority notification: R: Legal and Compliance. A: Chief compliance officer. C: Business owner. I: Security. Evidence: notice copies, completed template and submission record.

Reclassification checkpoints and cross-team handoffs

A deployer can take on provider obligations. The scenarios named in the brief are modifying a system and putting your own name on it. Add a checkpoint row to the RACI that is triggered by each: a change request that alters the system's behaviour, a rebranding or white-labelling decision, and any proposal to use the system differently from its documented intended purpose. Make Legal accountable for the determination, Product and Engineering responsible for surfacing the change, and require a written outcome before release. Confirm the exact conditions against the official text for the article that governs this, since the checkpoint is only as good as the criteria behind it.

Handoffs are the second weak point. The recitals describe a fair sharing of responsibilities along the AI value chain, with certain providers cooperating closely with the providers of the relevant high-risk systems. In your matrix this becomes a handoff row between upstream and downstream parties, plus internal handoffs: Engineering to Compliance for documentation, Product to the business unit for instructions for use, Security to Legal for incidents.

For each handoff, define the artifact, the sender, the receiver, and where the artifact is stored. If a handoff has no artifact, it is a conversation, and a conversation cannot be shown to an auditor. Fragmented evidence, spread across teams with no single retrieval path, is the most common practical failure in this area.

Where runtime enforcement supports specific rows

Some rows depend on what happens while the system is in use, rather than on documents prepared beforehand. Human oversight and record-keeping are the clearest examples. A written oversight procedure shows intent. It does not show that a reviewer was actually asked to approve a particular action, or what the system was permitted to do at that moment.

Trussed enforces policy in the execution path of models, agents, tools and MCP servers. For individual interactions and tool calls, it can allow, redact, block, or escalate for human approval, enforced at runtime, not reviewed after the fact. That enforcement generates continuous audit-ready evidence, mapped to the EU AI Act among other frameworks. In the RACI, this can support the deployer oversight assignment row, where an escalation routes a specific action to a named reviewer, and the record-keeping and log retention rows, where each enforcement decision leaves a durable record. Retention and data residency are configurable, and deployment is self-managed in the customer cloud.

The scope is deliberately narrow. This evidence covers individual interactions and tool calls. It does not address model or dataset provenance, and it does not trace agentic workflows end to end. It does not replace risk management, technical documentation, conformity assessment, or the other rows above. Use it as one evidence source for the rows it touches, and keep the RACI valid without it.

Putting the template into operation

Begin with a register of high-risk systems and the capacity held for each. Populate provider and deployer rows per system, then name the accountable role and review each evidence artifact for retrievability: who stores it, in which system, and for how long. Mark the rows that depend on runtime behaviour, since those need controls in place before an audit, not documents written afterward.

Tie the matrix to a specific version of the regulatory text. The consolidated version of Regulation (EU) 2024/1689 most recently dated is 27 July 2026, as of November 2026, so keep a change log and re-review the rows whenever a new consolidation is published. Review the matrix again at each system release, each rebranding decision and each change of owner, because those are the moments when roles drift.