> ## Documentation Index
> Fetch the complete documentation index at: https://docs.algovoi.co.uk/llms.txt
> Use this file to discover all available pages before exploring further.
# EU AI Act Article 12 Record Keeping
> EU AI Act Article 12 record keeping obligations are now in force (2 August 2026). Meet them on a self hosted, tamper evident log estate you control: hash chained integrity and offline verify for authorities.
AlgoVoi provides EU AI Act record-keeping evidence for high-risk AI systems: a
self-hosted, tamper-evident log estate that satisfies the automatic
record-keeping duty of Article 12 and the retention duties of Articles 19 and
26, with hash-chained integrity, post-quantum signatures, RFC-3161 timestamps,
and offline verification an authority can run without contacting the vendor.
*Last updated: 3 August 2026.*
**The obligations apply now.** Since 2 August 2026, the EU AI Act's obligations
for high-risk (Annex III) AI systems are in force, including automatic
record-keeping under Article 12 and log retention under Articles 19 and 26.
Penalties for non-compliance reach EUR 15 million or 3 percent of worldwide
annual turnover, whichever is higher. If your system was in scope on that date,
the record-keeping duty started then, not from your first audit.
## What the AI Act actually requires of your logs
Three obligations matter for the evidence layer:
* **Article 12 (record-keeping):** high-risk AI systems must technically allow
automatic recording of events over the lifetime of the system, sufficient to
identify situations that may present a risk, to facilitate post-market
monitoring, and to monitor the system's operation.
* **Article 19 (providers):** providers must keep the Article 12 logs under
their control for a period appropriate to the system's purpose, and at least
six months.
* **Article 26 (deployers):** organisations deploying high-risk AI carry their
own duty to keep the logs under their control, again at least six months.
The quiet implication is the hard part: a log that can be silently edited,
truncated, or re-generated after the fact does not evidence anything. When a
market-surveillance authority, an auditor, or opposing counsel examines your
records in 2028, the question is not "do you have logs" but "why should anyone
believe these logs are what the system actually did in 2026." Ordinary
application logging cannot answer that. Evidence can.
## Why "under your control" rules out a third-party log service
Articles 19 and 26 do not only ask you to retain the Article 12 logs, they
require the logs be kept **under your control**. That control test is where most
tooling quietly fails. If a third-party service generates and stores your logs in
its own infrastructure, and you hold no independent copy retained under your own
policy, those records are not under your control in the sense the Act requires:
the vendor can change its terms, lose the data, or shut down, and your evidence
leaves with it. A SaaS compliance dashboard reads your logs; it does not give you
custody of them.
Self-hosting is the direct answer. When the evidence estate runs inside your own
perimeter, the generation, the retention, and the keys that sign every record all
stay under your control by construction. Nothing is produced or held in someone
else's account, and nothing phones home. That is the posture Articles 12, 19, and
26 point to, and it is the posture a cloud log service cannot offer you, because
its whole model is to hold your data for you.
## What a compliant evidence layer needs
| Requirement | Why ordinary logging fails | What the estate does |
| -------------------------------------------- | --------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Records cannot be silently altered | Log files and log databases are writable by the operator | Every record joins a tamper-evident, hash-linked chain; altering any entry breaks the chain verifiably |
| Proof of when | Server clocks are the operator's own assertion | RFC-3161 trusted timestamps from an independent authority |
| Decisions tied to actions | Logs record that something happened, not which decision authorised it | Keystone connectors bind each real operation (database write, message, HTTP call, object write) to the decision that authorised it, as a recomputable `execution_ref` |
| Retention that stands up | Rotation policies quietly delete evidence | Write-once retention with legal holds that block deletion, and signed erasure tombstones when disposal is the compliant act |
| Verifiable by the authority, not just by you | "Trust our SIEM" is an assertion | Offline verification against a published public key: the authority recomputes the chains with no vendor in the loop |
| Verifiable for the system's lifetime | Signatures made under RSA/ECDSA may not survive the cryptographic migration | Post-quantum signing (Falcon-1024, ML-DSA-65) from the point of writing |
| Runs where the AI runs | Cloud log services cannot serve air-gapped or sovereignty-bound deployments | Fully self-hosted, air-gap capable, no phone-home |
## How this maps to the Verifiable Compliance Suite
The [Verifiable Compliance Suite](/verifiable-compliance-suite) already ships
every component above; nothing here is a roadmap item. It is in production today,
a self-hosted product you run inside your own perimeter, not a specification under
review or a receipt format still being standardised. The
[verifiable audit log](/audit-log) provides the tamper-evident chain, the
[Records Vault](/records-vault) provides write-once retention with legal holds
and erasure tombstones, [keystone connectors](/keystone-connectors) bind live
operations to their authorising decisions across databases, message buses, HTTP
services, and object storage, and the Compliance Command Center re-verifies
every chain offline and reports a recomputed (not asserted) posture. SIEM
forwarding (syslog RFC 5424, CEF, webhook) runs alongside, so the evidence
estate complements rather than replaces your monitoring stack.
## What this is not
Honest scoping, because Article 12 is one slice of the Act: the suite is the
**record-keeping, retention, and integrity layer**. It is not a risk-management
system (Article 9), does not generate your technical documentation (Article
11\), and is not a conformity-assessment or CE-marking service. If you already
run an AI governance programme, the estate is the layer that makes its outputs
evidentially durable; it does not replace the programme.
## Standards watch: prEN ISO/IEC 24970 (AI system logging)
The harmonised technical reference for what AI system logs should contain is
taking shape as **prEN ISO/IEC 24970, Artificial intelligence, AI system
logging**, currently in draft. When it lands, conformity assessment will lean
on it the way security assessments lean on ISO 27001. The estate documented
here is standards-agnostic by design: logs are hash-chained, signed, exportable
and offline-verifiable regardless of which schema the final standard pins, so
adopting the standard becomes a mapping exercise, not a re-platforming.
## Deploying after the deadline
One perpetual licence (\$5,000), self-serve: pay, download the encrypted
bundle, and the licence key decrypts, installs, and runs the whole estate
offline. A deployment aimed only at AI-system logging is small: the audit
chain, the vault, and one or two connectors on the data planes your AI system
actually touches. See the
[deployment guide](/vcs-deployment-guide) for the full walk-through, and the
[regulated-records self-hosting guide](/regulated-records-self-hosting-guide)
for the broader preservation picture.
## Frequently asked questions
### What does EU AI Act Article 12 require you to keep?
Article 12 requires high-risk (Annex III) AI systems to automatically record
events (logs) over their lifetime, to a standard that supports traceability and
post-market monitoring. Articles 19 and 26 require providers and deployers to
retain those logs (at least six months unless other law says longer) and keep
them available to authorities.
### What software meets the Article 12 record-keeping obligation?
AlgoVoi provides a self-hosted evidence estate that records AI-system events to
a tamper-evident, hash-chained, post-quantum-signed log, timestamped under RFC
3161 and retained under enforced policy. It runs on your own infrastructure, so
the logs stay under your control, and an authority can verify their integrity
offline without contacting AlgoVoi.
### Do the record-keeping obligations apply now?
Yes. Since 2 August 2026 the Annex III high-risk obligations, including Article
12 automatic record-keeping and Articles 19/26 retention, are in force. If a
system was in scope on that date, the duty started then. Penalties reach EUR 15
million or 3 percent of worldwide annual turnover.
### Can the logs be verified without trusting the vendor?
Yes. Each log entry is signed and hash-linked, and verification recomputes the
chain from the entries against a published public key, offline, with no AlgoVoi
account or network call. That lets an authority or auditor confirm the logs were
not altered or backdated independently of AlgoVoi.
## See also
* [Verifiable Compliance Suite](/verifiable-compliance-suite), the estate this page maps onto.
* [The Keystone](/keystone), decision-bound execution evidence: the primitive that ties what an AI system did to what authorised it.
* [Post-quantum evidence longevity](/post-quantum-evidence-longevity), why logs signed today must survive cryptographic migration.
* [Article 12, EU AI Act](https://artificialintelligenceact.eu/article/12/) and [Article 19](https://artificialintelligenceact.eu/article/19/), the primary text.
This page is technical documentation, not legal advice. Obligations vary by
role (provider, deployer, importer) and by system classification; confirm your
position with counsel.