EU AI Act High-Risk Control Matrix Template: Mapping Requirements to Runtime Controls

Why the matrix has to be an engineering artifact

Regulation (EU) 2024/1689 sets requirements for high-risk AI systems across risk management, data set quality and relevance, technical documentation and record-keeping, transparency and information to deployers, human oversight, and accuracy, robustness and cybersecurity. Most regulated enterprises hold these requirements in legal or GRC documents. The technical controls that act on individual interactions are held somewhere else, and nothing connects the two.

A control matrix closes that gap. Each row states one obligation, the control that addresses it, who owns the control and what evidence shows it operated. The test is traceability: an auditor should be able to start at a provision, follow it to a control, see what the control did on a given interaction and open the record of that action.

The requirement family list above gives natural row groups. Compliance with these requirements must account for the system's intended purpose and the generally acknowledged state of the art, so the matrix should be scoped per system and not kept as a single enterprise-wide table.

The columns a matrix needs

This column set is an engineering design, not a regulatory format. It is the minimum that lets a row be traced end to end. Group the columns so that each row can be read and challenged quickly.

• Requirement trace: Requirement family, source provision, intended purpose or system scope, and the application date that applies to that system.
• Control definition: Control description, the enforcement point in the execution path, and the policy action: allow, redact, block, rate limit or escalate.
• Ownership: A named control owner, a named reviewer, and a reassessment trigger tied to intended purpose and state of the art.
• Evidence: The evidence artifact the control produces and the location where it is retained.
• Verification: How an auditor can confirm the control operated, such as sampling records for a given interaction and policy version.
• Coverage type: Runtime, pre-deployment, organisational or model-level. This column makes the boundary of runtime enforcement visible.

Sample rows and where each one is owned

The rows below show how different requirement families populate the matrix. Only some can be evidenced at runtime. The rest are listed deliberately so that they appear in the matrix with an owner instead of being left as silent gaps.

• Record-keeping (runtime): High-risk systems must technically allow automatic recording of events over their lifetime, with traceability appropriate to the intended purpose. Enforcement point: every model request, response and tool call. Evidence: a per-decision record with action, policy version, timestamp and identity. Check the recorded fields against the event categories in the full text before claiming coverage.
• Human oversight (runtime, partial): Systems must allow natural persons to oversee them effectively through human-machine interface tools. An escalate-for-approval action on selected tool calls is a candidate mechanism. Evidence: who approved or rejected, what they saw, and when. Whether this is effective oversight depends on the intended purpose and the oversight measures chosen.
• Accuracy, robustness, cybersecurity (runtime, partial): Performance must stay consistent across the lifecycle. Block, redact and rate limit actions produce per-event evidence of consistent behaviour. The metrics themselves are defined before deployment, so the row should point to those definitions.
• Risk management (organisational): A continuous, iterative lifecycle process with regular review. Runtime records can feed post-market monitoring under Article 72 and periodic risk review. They do not replace the process. Owner: risk function, with a set review cadence.
• Technical documentation (pre-deployment): Drawn up before the system is placed on the market or put into service, and kept up to date. Owned by the provider. Runtime evidence is not a substitute.
• Data governance and pre-market testing (pre-deployment): Data set quality and testing against prior defined metrics and probabilistic thresholds happen before placement. Owned by the data and model teams, with their own evidence.

Marking the boundary of runtime enforcement

Runtime enforcement acts on what happens when a system is in use. It can show that a policy was applied to a particular interaction or tool call, and that an action was taken. It cannot show that training data was suitable, that testing met its thresholds before market placement, or that the lifecycle risk process is working. Those obligations are described as design-time, pre-market or organisational activities, and the matrix should say so in the coverage type column.

Two practices keep this honest. First, give every out-of-path row its own owner and evidence artifact, so the matrix remains a complete map and not a list of what is convenient to automate. Second, record which existing GRC artifacts each row reuses. The regulation lets providers integrate testing, reporting and documentation into documentation already required under Union harmonisation legislation listed in Section A of Annex I, so existing procedures may already hold part of the evidence.

Avoid wording that implies runtime controls make a system compliant. The obligations extend to design, documentation, testing and data governance, and a matrix is evidence of coverage, not a conclusion of conformity.

Timing, review and where in-path enforcement fits

As of November 2026, Regulation (EU) 2026/1744, the Digital Omnibus on AI, has amended Regulation (EU) 2024/1689. The Commission states that the rules for high-risk AI systems apply from 2 December 2027, replacing the earlier date of 2 August 2026. The Council's announcement of the May 2026 provisional agreement gave 2 August 2028 for high-risk systems embedded in products. Record the applicable date against each system in the matrix and revisit it as standards and tools are confirmed. The Commission mandated CEN and CENELEC in 2023 to develop standards for the high-risk requirements, amended in June 2025, so row wording may need to be updated as those standards appear.

For the rows that runtime can evidence, the evidence has to come from somewhere reliable. Trussed enforces policy in the execution path across models, agents, tools and MCP servers, applying allow, redact, block, rate limit or escalate for human approval to individual interactions and tool calls. That enforcement generates audit-ready evidence, mapped to the EU AI Act among other frameworks, and it can be deployed self-managed in the customer cloud with configurable retention and data residency. In a matrix, this supplies the enforcement point, policy action and evidence artifact columns for the runtime rows. It does not supply the owners, the pre-deployment evidence or the judgement on intended purpose, which stay with the regulated enterprise.

A practical sequence is to select one high-risk system, fill the runtime rows first, then add the out-of-path rows with named owners, and finally run the five verification tests across every row. The gaps that remain are the work plan.