Skip to content
AIAssuranceLabs
Menu

Traceability matrix template

The traceability matrix takes a role, a classification tier, the establishment flag and the Art. 27(1) flag, entered on the page or passed in the address by the classifier. The matrix returns one row per requirement element of every obligation in the matching profiles: the element, its kind, the protocol that addresses it, the evidence record, the application date from the regulation data In force, and an evidence status. The matrix runs in the browser and nothing is sent. The CSV export is a working document for the provider's own file.

How the result is built

The four inputs are the same questions the obligation tracker asks, so a classifier result opens the matrix with the answers already set. The role and tier select the matching profile from the profiles file. Flag-driven profiles add rows on top of the base one: a provider established outside the Union with a high-risk tier receives the Art. 22 authorised representative row, a general-purpose AI model provider established outside the Union receives Art. 54, a deployer within Art. 27(1) with an Annex III tier receives Art. 27, and the systemic-risk tier receives Art. 51, Art. 52 and Art. 55 in addition to Art. 53. The profile marked for every role adds the Art. 4 AI literacy row. An article that two profiles both name appears once.

Each article in the selected profiles expands into rows according to the traceability logic file. For an article with an obligation page, every testable element of its record in the obligation data becomes a row of kind test. The Test column of such a row names the first protocol in the record's procedures list that covers the article. The Evidence column names an artifact from the record's list of what an assessor asks for, taken in list order; the provider replaces it with the reference of the file that holds the result. Every documentation element becomes a row of kind document and every process element a row of kind process record; the Test column of both names PR-11-DOC v1.0, and the Evidence column repeats the element, since the element itself names the record. An article without an obligation page, such as Art. 16, Art. 43, Art. 49 or Art. 72, becomes one document row that carries the provision label and the evidence "Record that answers the provision". Row ids follow the pattern TM-<article number>-<row number>, assigned at generation, so TM-15-03 is the third row of Art. 15.

The Applies from column renders from the regulation entry the profile names for the article, never from a typed date, so a change made through the regulation change log reaches every row at the next build. The Art. 27 row renders the entry of the FRIA timing point, whose label marks a working reading rather than a settled date. The Evidence status column offers four values from the logic file, Missing, Draft, Ready and Recorded as not applicable, starts at Missing, and is kept in the browser only. The download writes one CSV file with the columns id, system, article, requirement, kind, test, evidence, applies from and status; the test cell carries the protocol id with its version and the applies-from cell carries the date of the entry. The methodology index lists the protocols the Test column can name.

What the result is not

The matrix is a structure for the provider's own evidence file. The matrix is not a classification decision under Art. 6, which rests on the provider's assessment and, for the Art. 6(3) route, on the record the provider keeps under Art. 6(4). The matrix is not a conformity assessment under Art. 43; a row set to Ready records only that a file exists, and whether a test passed or a notified body accepted the file is shown by the file itself. The evidence name on a test row is a placeholder from the record's artifact list until the provider replaces it with the file reference and its location in the technical documentation under Art. 11. The page is not legal advice; the disclaimer states the limits, and the compliance decision remains with the provider or deployer, their notified body and their counsel.

Where the output goes next

The same four answers open the obligation tracker, which lists the documentation and process elements with a per-obligation status, and the test checklist generator, which keeps the test rows only and adds items by system type. The templates page holds the evidence pack index and the Annex IV outline that the evidence column and the technical file location refer to. The technical documentation service delivers the same matrix as a specified deliverable under PR-11-DOC v1.0, within the limits stated on what we cannot do; the deliverable specification adds the coverage summary per article and the change log of the matrix keyed to system versions, which the browser tool does not produce.

Questions

How does the matrix relate to an EU AI Act risk classifier and compliance checker?

The classifier on this site returns a reasoned technical assessment of role and tier for discussion with counsel. The matrix takes the classifier result through the page address and lists, per obligation element of the tier, the protocol or document that addresses it and the evidence record it needs. No tool on this site decides whether a system conforms: a status of Ready records that a file exists, and the conformity assessment under Art. 43 stays with the provider, its notified body and its counsel.

Is the matrix an EU AI Act risk classification assessment template?

No. The classification assessment is the record a provider keeps under Art. 6(4) when an Annex III system is treated as not high-risk, or the reasoning behind a high-risk determination under Art. 6(1) or Art. 6(2). The matrix starts after the classification assessment and lists the evidence each obligation element of the chosen tier needs. For the not-high-risk tier the matrix carries the Art. 6(4) record and the Art. 49(2) registration data set as two document rows.

Every inquiry receives a reply within 24 hours. Scope and availability are discussed per request.

Ask about scopehello@aiassurancelabs.com