A Trustvice Product
Article 12 of the EU AI Act is short, and most of the engineering sits between its sentences. This post reads it the way a team running agents has to: as a requirement on a logging subsystem. It is engineering analysis, not legal advice. Whether your system is high-risk, and what your obligations are, is a question for counsel.
What the text asks#
Article 12 of Regulation (EU) 2024/1689 applies to high-risk AI systems. Three points matter to an engineer:
- The system must technically allow for the automatic recording of events (logs) over its lifetime. Automatic means logging is part of the system, not something an operator remembers to do.
- The logging must enable traceability appropriate to the system's purpose: events relevant to identifying situations that may result in risk or a substantial modification, to post-market monitoring, and to the deployer's monitoring of the system's operation.
- For some categories, such as remote biometric identification, the article lists minimum fields. We do not cover those here.
Retention sits elsewhere. Article 19 asks providers to keep the automatically generated logs under their control for a period appropriate to the purpose and at least six months, unless other law, data protection law in particular, says otherwise. Article 26(6) puts the same floor on deployers.
The article names no format, schema, signature scheme or storage medium. Application dates were still under discussion in late 2026, so check the current status before you plan around any date.
Why a fleet changes the question#
For one model behind an API, an event is a request and a response. For a fleet, one outcome is several agents acting on shared resources, each making tool calls, some waiting on a human. Two things follow.
Log at the boundary, not in the agent. If an agent is asked to write down what it did, you have a record of what the agent said it did. Recording belongs in code the agent passes through on its way to the world: the MCP gateway, the repository write gate, the credential broker. That is also where you can stop an action, not only note it.
Log refusals, not only actions. The write that was refused, the request that waited for a human, the agent that was quarantined: these are exactly the events "relevant to identifying situations that may result in risk". A record of only successes describes a system that does not exist.
What an agent's record should answer#
Article 12 gives no schema. For an agent fleet, we think the record should let you answer these questions months later:
| Question | What has to be recorded |
|---|---|
| Which agent acted? | A stable identity, such as a DID, not a display name |
| What did it try to do? | The resource and the verb, before the action |
| Was it allowed, and why? | The decision and a stable reason |
| Under which rules? | The version of the mandate in force |
| Did a human approve? | Who, when, for which actor, resource and verb |
| Was anything stopped? | Halts, quarantines and refusals, with reasons |
| Has the record changed since? |
Intramedial's admission flow writes most of this as a side effect of working. An agent declares an intent with its DID, the resource and the verb. Admission answers allow or deny with a stable reason, and the decision is recorded. A write without a confirmation token goes to the approval queue, where a named person decides. Mandates are versioned, so the rules in force at a moment can be named.
Why self-written logs are weak evidence#
A log written by the party that runs the system is evidence of what that party now says happened. Anyone with write access to the store can edit, delete or backdate a row, and an ordinary database shows no sign of it. An auditor cannot tell whether a row was written at the time or later.
"Tamper-evident" is used loosely. It breaks into properties that each close a different gap:
- Hash-chained. Each entry includes the hash of the one before. Editing, removing or reordering an entry in the middle breaks every link after it. A chain alone does not stop cutting off the tail.
- Sealed and signed. A signature over a range of the chain fixes its contents and its length at a moment. Removing the tail afterwards no longer goes unnoticed by whoever holds the seal.
- Externally timestamped. A time from a party you do not control bounds how far back the record could have been rewritten.
- Independently held. A copy of the seal sits somewhere the operator cannot alter.
None of this proves completeness. A code path that never passes the logger leaves no trace, and no cryptography changes that. Completeness comes from the architecture: enforcement points that every action must pass through.
Where Intramedial fits#
Against those properties, here is what the plane does today.
- Hash-chained: yes. The workspace audit chain hashes each entry's RFC 8785 canonical core with SHA-256 and links it to the previous entry. Anyone can check an export with no key.
- Sealed and signed: yes, on request.
ledger-bundles.snapshotseals a range of the audit chain into a Merkle-rooted bundle signed with Ed25519. Anyone with the public key can verify it offline. - Externally timestamped: partly. The bundle's
snapshotAtis our clock. A daily job is built to anchor bundle roots to Bitcoin through OpenTimestamps; until a block confirms it,otsProofstaysnull, and a pending time is never shown as confirmed. - Independently held: that part is yours. A bundle is a file. Keep a copy in a system you control.
For the Article 12 view itself there is an export, eu-ai-act-article-12. It is the workspace's complete audit trail over the range you choose, not a selected subset, with a manifest naming the standard. Each entry carries its hash-chain link. The download stays available for 30 days. You can request it through compliance.pack with the id art12; Article 12's export needs the paid compliance-exports entitlement.
compliance.pack also reports coverage: fourteen controls mapped to the EU AI Act and NIST AI RMF, each marked evidenced, partial or gap against what the workspace has actually recorded. Gaps are named, never dropped.
Retention and erasure#
Article 19 sets a floor. The GDPR says you may not keep personal data longer than you need it. The two meet in an append-only record.
A record of agent decisions names agents, resources, decisions and approvers, so treat it as personal data under your own retention rules. When a workspace is deleted, Intramedial's erasure purges the tables that can be erased and keeps the append-only trails, with the reason each was kept recorded. Keep personal data out of free-text fields such as labels and reasons: once it is in an append-only chain, it stays there.
Whether a given entry is personal data, and how long you must keep it, are legal questions. The engineering point is to decide them before the first entry is written.
What this does not do#
This is the part to take to your assessor.
- It does not make a system compliant. Article 12 is a property of the high-risk system: the capability to log, over its lifetime, with the traceability its purpose needs. A tamper-evident record helps you show that. The scope, the review process and the risk management remain yours.
- It does not prove an agent did what it declared. The record holds the intent and the decision. Whether the action happened is for detection and your own systems to say.
- It does not see agents that go around it. An agent that never calls the plane, or reaches a resource with no enforcement point in front of it, leaves no entry.
- It is not a certification. We map evidence to controls. We do not certify conformity, and
compliance.packrefuses text that claims otherwise.
The guide to an EU AI Act style record walks through the same flow end to end, from an agent's first intent to the bundle an auditor verifies. What a ledger bundle proves, and what it does not states the limits of the seal in detail.
