Building an EU AI Act Evidence Register Mapped to Each High-Risk AI System Requirement

Treat the register as an engineered artifact

High-risk AI systems must meet the requirements of the relevant section of the Regulation, taking into account their intended purpose and the generally acknowledged state of the art. The requirement areas are risk management, quality and relevance of data sets, technical documentation and record-keeping, transparency and information to deployers, human oversight, and robustness, accuracy and cybersecurity. Most regulated enterprises can describe a control for each. Fewer can retrieve the proof for each one on request.

A register closes that gap only if it behaves like an engineered system rather than a spreadsheet of statements. Every row should resolve to something a reviewer can open: a log extract, a signed document, a ticket, a configuration record. The recitals tie record-keeping and technical documentation to traceability, compliance verification, operational monitoring and post-market monitoring. A row that says "we have a process" supports none of those purposes. A row that points to an artifact does.

The register should also state the organization's role for each system, provider or deployer, because registration and documentation duties differ between the two.

Define the register schema first

Fix the columns before collecting any evidence. Inconsistent columns are the main reason registers cannot be audited. The following schema works for every requirement area and keeps each row traceable from obligation to proof.

• Obligation and article reference: The requirement in plain terms, with the article or recital it comes from, and the version date of the Regulation text used for the mapping.
• Control: The specific organizational, technical or design measure that meets the obligation.
• Evidence type: Automatically generated record or curated document. This single field drives how the row is maintained and verified.
• Source system: The system of record from which the artifact is retrieved, such as a log store, document repository or ticketing tool.
• Owner and review cadence: A named role accountable for the artifact and a defined interval for review, plus triggers such as a substantial modification.
• Retention and verification method: The retention rule applied to the artifact and the test a reviewer runs to confirm it exists, is complete and is current.

Separate runtime evidence from organizational evidence

The Regulation requires high-risk AI systems to technically allow for automatic recording of events over the lifetime of the system, with traceability appropriate to the intended purpose. That points to one class of evidence generated automatically, as the system operates. Retention rules and coverage over the full system lifetime belong in those rows, along with a statement of which events are captured and for which traceability purpose.

The second class is produced outside the execution path. As a working inference rather than an explicit legal statement, the risk management file, data governance records, technical documentation and human-oversight design belong here. So does provider identification: the provider's name, trade name or mark, and contact address must appear on the system, its packaging or its accompanying documentation. These artifacts are curated by people, so their rows need stronger ownership and review cadence, because nothing regenerates them automatically.

Human oversight spans both classes. The requirement is that natural persons can effectively oversee the system through appropriate human-machine interface tools. The design of those tools is documentary evidence. Records showing how oversight was exercised in practice are a separate row, and they are only available if the system produces them.

Where runtime enforcement evidence fits, and where it does not

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. Each decision, whether allow, redact, block, rate limit or escalate for human approval, is enforced at runtime, not reviewed after the fact, and produces audit-ready evidence at the level of individual interactions and tool calls. In a register, that evidence is a candidate source for rows covering record-keeping and for rows showing that a human approval step was actually triggered. The evidence is mapped to the EU AI Act, and Trussed supports self-managed deployment in the customer cloud with configurable retention and data residency, which matters when the retention field has to match a specific rule.

The boundaries matter as much as the fit. Trussed does not provide model provenance, model lineage or dataset provenance, and it does not trace agentic workflows end to end. Rows for those items need their own sources or must be recorded as open gaps. Runtime evidence also does not replace the risk management file, the technical documentation or the human-oversight design. Those remain curated artifacts with human owners.

A register that is honest about this split is easier to defend. It shows a reviewer which claims rest on generated records and which rest on documents.