Article 12, and what a log has to survive

This is a working engineer's reading of the obligation, not legal advice, and I am not a lawyer. It is written by someone who sells one piece of the answer, so the section on what you do not need me for is deliberately first.

What the obligation says

Article 12 requires high-risk AI systems to record events automatically across their lifetime — logs that allow the identification of situations where the system may present a risk, that support post-market monitoring, and that let someone reconstruct how the system was operating. Under Article 19, providers keep those logs for at least six months. Under Article 26, deployers keep the logs that are under their control.

Full application for high-risk systems began on 2 August 2026. Penalties for breaching high-risk obligations reach €15 million or 3% of worldwide annual turnover, whichever is higher.

Two points that catch teams out. First, buying the system does not move the obligation: a deployer of a high-risk system carries its own duties regardless of who built it. Second, high-risk is broader than people expect — CV screening and recruitment ranking, credit scoring, insurance pricing, and access to essential services all appear in Annex III.

Where ordinary logging falls short

Almost every team already logs. The obligation is not really about volume; it is about whether a record can be relied on later by someone who was not there. Three levels, in the order teams actually pass through them:

1. Nothing durable. Requests go to a model provider, responses come back, and no record of the inputs survives beyond a debugging window. If someone asks in eight months what was sent, there is no answer.
2. Application logs. Better, and where most compliant-looking teams are. But the logs sit in infrastructure the operator controls, and the operator is the party whose conduct is in question. They can be edited or deleted, and — more importantly — nobody can demonstrate that they were not.
3. Records that survive the operator. Append-only, independently timestamped, and checkable by someone who has no reason to trust the operator.

Regulators reading “appropriate to the intended purpose” in practice mean something at the third level for the parts that matter. The distance between level two and level three is small in engineering terms and large in evidentiary terms.

What you do not need a vendor for

Most of this you should build yourself, and it is cheap:

• Log the inputs, not just the outputs. Article 12 is about reconstructing how the system was operating; the prompt, the retrieved context and the source documents matter more than the completion.
• Hash-chain your own log. Each entry carries the hash of the previous one. Perhaps thirty lines of code, and it makes silent edits in the middle detectable.
• Timestamp your log digests for free. Submit the digest of a daily log segment to an OpenTimestamps calendar. Bitcoin anchoring, no account, no fee. This alone lifts you most of the way from level two to level three.
• Write down your retention period and actually enforce it. Six months is the floor, not the target.

If you do these four, you have addressed the substance of the record-keeping obligation without paying anyone. Do them first.

What stays hard

Two gaps remain that you cannot close from inside your own infrastructure.

You still sign your own homework. A hash chain you maintain proves the log has not been edited since you last published a digest — and you chose when to publish. The fix is that somebody else holds an older digest, so a divergence is detectable by them and not only by you.

External inputs are not yours to attest. If a decision depended on a page, a rate, a filing or an API response outside your systems, your log records what you say you fetched. When that becomes the disputed fact, an internal record cannot settle it.

Where Elucora fits, exactly

It seals what an external source served at the moment your system read it, into a public append-only log with an RFC 3161 timestamp and a Bitcoin anchor. Receipts verify offline against published keys, so an auditor checks them without contacting Elucora, and independent witnesses can co-sign the log head with keys Elucora never holds.

Said plainly: this is not a compliance product, and it does not produce your system's own logs. Nobody can sell you Article 12 compliance — it is a property of how you operate, assessed by people who do not read marketing pages. What this does is make one specific thing checkable by an outsider: what a source served, when, and that the record has not moved since.

A reasonable order of work

1. Establish whether your system is high-risk under Annex III, and whether you are provider, deployer, or both.
2. Start recording inputs alongside outputs, with a retention period you have written down.
3. Hash-chain the log and anchor daily digests to OpenTimestamps. Free, and it closes most of the gap.
4. Get an older digest into someone else's hands — a repository you do not control, a counterparty, an auditor.
5. For the external sources a decision actually turned on, seal them at read time, so the record of them is not yours either.

Only the last step needs anything from us, and the documentation is public if you would rather build it yourself. Verifying receipts requires no account at all.