EU AI Act Record-Keeping and Evidence: The Verification Layer | CORTHEM
EU AI Act · Article 12 · Article 19 · Article 72

The EU AI Act requires records of AI in operation. Records mean evidence, not logs.

Article 12 requires high-risk AI systems to automatically record events throughout their lifetime. Articles 19 and 26 require providers and deployers to retain those records. Article 72 requires active, systematic monitoring of the system after it is placed on the market.

CORTHEM is Continuous Governance Verification Infrastructure: the evidence layer that satisfies the proof half of the Act. CORTHEM continuously verifies that machine action remained within policy and produces audit-grade evidence bound to the verification chain, retained as systems act and re-verifiable as policy changes.

For enterprises deploying high-risk AI in the European Union. Deploys inside customer environments, never SaaS.

The Regulatory Moment

The deadline moved. The obligation did not.

In July 2026, the Digital Omnibus on AI entered into force. Standalone high-risk obligations now apply from December 2, 2027. High-risk AI embedded in regulated products follows in August 2028. Other provisions were not deferred and apply on their original schedule.

Original Deadline
2 August 2026
Annex III high-risk obligations under the original AI Act.
Deferred To
2 December 2027
Digital Omnibus on AI, in force July 2026.

Regulators and every major legal advisory are saying the same thing: the extension exists because standards were not ready, not because the requirements changed. Enterprises are expected to use the runway to build. Evidence infrastructure is not assembled the week an auditor asks for it. Proof accumulates, or it does not exist.

What the Act Actually Requires

Three obligations. One architectural conclusion.

The Act does not tell enterprises how to build their evidence layer. It tells them what that layer must be capable of proving.

Article 12

Record-keeping

High-risk AI systems must technically allow the automatic recording of events over their lifetime, sufficient to identify risk and trace the system's functioning. A record that cannot demonstrate which policy was in force, or whether the action was within it, identifies nothing. The article describes decision-linked evidence, not an activity log.

Articles 19 & 26

Log retention

Providers must keep the automatically generated logs of their high-risk systems. Article 26 places the same retention duty on the deploying enterprise. Retention is only as valuable as the integrity of what was retained. Evidence that cannot be shown to be complete and unaltered proves nothing when it matters most.

Article 72

Post-market monitoring

Providers must actively and systematically collect and analyze data on the system's performance throughout its lifetime. Continuous monitoring is a verification obligation, not a review cycle. A quarterly look at last quarter's logs is not systematic analysis of a system that acted every hour in between.

The conclusion is architectural, not legal: these obligations cannot be satisfied by raw logs assembled after the fact.

Why Logs Cannot Satisfy an Evidence Requirement

A log can tell you what happened. It cannot prove it was governed.

A log records activity. It does not verify that the action was within policy at the moment it occurred, under the policy actually in force, in the context that actually existed. When the question comes from a regulator, auditor, customer, insurer, board, or legal team, activity is not the question. Governed operation is the question.

There is a second problem, and it is the one frozen records can never answer: policy changes and detection improves. A record written once and never re-examined can only tell you what passed yesterday. The Act's monitoring obligation runs across the lifetime of the system, and so does CORTHEM's verification.

Decision drift

Would this decision still be permitted under current policy? CORTHEM replays historical decisions against the policy now in force and classifies every drift event across four deterministic axes.

Detection drift

Would this reasoning still pass as clean under current detection? CORTHEM re-verifies historical reasoning chains as detection improves, surfacing contamination that was invisible when it happened. Trace binding ties every reasoning chain to the evidence record it produced.

Every governed action produces signed, decision-linked, audit-grade evidence bound to the verification chain. When policy changes, CORTHEM re-verifies history under the policy now in force. That is what record-keeping means when machines act.

Where CORTHEM Sits

The verification layer for machine action across time.

CORTHEM operates as the continuous verification and evidence layer for agentic systems, deployed inside the customer environment.

At the Moment of Action

Decision-linked evidence

Every governed action produces a record of what was requested, what policy applied, what outcome occurred, and why. Signed, tamper-evident, and verifiable offline. Article 12 record-keeping as evidence, not as activity capture.

In Retention

One verification chain

Evidence is bound to a single verification chain. Completeness and integrity are demonstrable properties of the record, not assertions about it. Articles 19 and 26 retention duties, discharged with proof that what was kept is whole and unaltered.

Across the Lifetime

Verification across time

CORTHEM continuously replays decisions and reasoning chains under current policy and current detection, classifying decision drift and detection drift across four axes. Article 72 post-market monitoring as a live verification state, not a review cycle.

This is not a compliance product. The EU AI Act is the forcing function. Proof that machine action remained governed is the requirement your enterprise carries either way.

The Other Half of the Obligation

Proof is half the Act. Enforcement is the other half.

The EU AI Act also requires effective human oversight of AI systems while in use: the ability to intervene and to interrupt before consequences exist. That is an authorization problem, not a verification problem. It is addressed by a sibling category, in a sibling venture inside the Hartstone Institute portfolio.

Runtime Authority Control

Authorizes execution

The pre-execution layer. Every machine-initiated action is verified and authorized before it happens. Article 14 human oversight, Article 9 runtime risk mitigation, Article 26 deployer control.

CORTHEM

Verifies governance held

Continuous Governance Verification Infrastructure. Continuous, decision-linked evidence that machine action remained within policy across time. Article 12 record-keeping, Articles 19 and 26 retention, Article 72 post-market monitoring.

RAC enforces. CORTHEM proves. Two obligations, two architectural answers, one portfolio. CORTHEM stands on its own: it remains valuable wherever agentic systems operate, whether enforcement is native, external, partial, or absent.

Read the RAC EU AI Act Page →
Founding Member Release · By Invitation

Build the evidence layerthe Act requires.

Enterprises deploying AI in Europe now hold a sixteen-month window before the deferred high-risk deadline. Founding Member briefings include live console walkthroughs, the four-axis drift framework, and architecture review against your EU deployment context.

Request Founding Member Access

For enterprise operators, security leaders, compliance teams, and integration partners.

CORTHEM, Runtime Authority Control, and RAC are trademarks of Hartstone Institute LLC, and the technologies they describe are the subject of pending patent applications.